From: MikkelFJ Date: 2003-06-23T16:54:07+09:00 Subject: Externsion specifications, was Re: Euruko 2003 (1st European Ruby Conference) Over * formal specification of Ruby necessary? There need to be a specification of the C-API for extension developers. This should include levels of support such that e.g. new 1.8 functions is in a different class. Doing this would allow other interpreters / compilers to be written and still take advantage of the existing extensions. At the same time extension writers can decide whether they really need function rb_xxx since it might unnecessarily require a more advanced API. Ultimately this would also make it possible to take Ruby extensions and sometimes use them in a non-ruby enviroment. Mikkel "Mauricio Fern�ndez" wrote in message news:20030622225318.GA23266@student.ei.uni-stuttgart.de... > > 2nd day and conference over > > Stefan's Brainstorming :-) > ====================== > Planning an Intro to Ruby on Windows. Aim: have people see what they can > get, let them type in code, not overload w/ Ruby concepts, only > introduce as needed. > > Talks > ===== > * Beyond vi -- Marcus Denker > Ruby took some good ideas from Smalltalk . But it ignored the > environment completly that made Smalltalk so powerfull. Using Squeak as > an example, this talk will give an introduction some advanced tools in > the Smalltalk world (Refactoring Browser, StarBrowser, SLint, ...). > > * Resource management for Appliances using Ruby: rconf -- Alexander Bokovoy > This talk will present an attempt to develop full-fledged resource > management application for use in various appliances like firewalls, > NAS and SAN: modularization, configuration tracking, transactions, > independent multi-GUI, and security ideas will be discussed > > * Ruby-Wise -- Kero van Gelder > Wise, a WIdget SEt for Ruby. overview, demo > (more info in http://httpd.chello.nl/k.vangelder/ruby/wise/ ) > > > Discussions > ----------- > > We only had one large discussion today: "Ruby & the rest of > the world (technical)". We were all quite tired, so the discussion > didn't follow a clear track, and in the end, as people were leaving, it > became a tough head to head daydreaming contest :-) No winners nor > losers, but I can say I dreamed a lot :) > > The usual quick & dirty summary (this disc. took around 2H IIRC): > Introductory question: what can we make to make Ruby play nicer w.r.t. > the rest of the world? > > * interface w/ Java. Approaches: > * RMI: needs deserializing Java objects. However code should be > available (in Java) Cons: hard, objects have to be mapped (attr, > etc), needs server code on the Java side. Pro: as easy to use as > druby (essentially the same thing, communicating w/ java on the > server side) > * JNI: map the reflection API from Java through JNI into Ruby. Then > access all of Java through that "pipe". I failed to see the merit of > this at first but now I believe it's probably *the* idea of the day. > Should be easier to implement. Already done in Dolphin Smalltalk: > www.metagnostic.org (that was our starting point). > Pro: *all* of Java accessible after a couple man-days!! Cons: at > first, some convenience lost (if I got it right the API would look > like ext/Win32API) > * do we want to port things from Smalltalk? hehe, the Java through JNI > thing :-) Things that would help > - become: not really, not used a lot (only a dozen times in a live > Dolphin Smalltalk image) > - multiple blocks: convenience, forget proc { } > - serialization of *everything*. Right now problems with > * IO: it's OK, files are closed in Smalltalk on image save > (actually impl. dependent) > * Proc: the problem is not procs, it's *code* (the AST) > => bytecode helps, we want Rite :-) > * rule-driven systems � la Prolog > - backtracking: w/ continuations (?) > > From this point on we lost a little bit the track :) and started > discussing whatever came through > > * formal specification of Ruby necessary? > - Rubicon > - C interpreter is specification. If somebody reimplements Ruby he > could say "I match 1.6.8" > - who's reimplementing Ruby anyway? > - specification as guarantee for the programmer: example of Python. > - however, if incompatible changes happen (as in Python), does a spec. > buy you anything, instead of just seeing the code break? Why care? > You have to keep the old thing anyway. > * has any language ever been implemented following TDD? > * how hard is creating a compiler anyway? => not really > * yet getting AST from Ruby isn't widely done as of now > <= node types in eval.c and no documentation on that > * Ruby object model ~~ Smalltalk Object model > Objective C ~~ Smalltalk + C and types > what about Ruby <=> Objective C? > > * Embedding: what do we want to script? > - everything: � la WSH > - strategies: > * per app, add Ruby interpreter and/or map existent object model to > Ruby. OpenOffice (UNO), kparts, bonobo > * globally: intelligent proxying X server that sends events to > script apps. HARD > > * Graphic output > - gnuplot: 3 bindings in RAA yet nothing satisfactory > - generating PS: easy, similar to generation of Tcl/Tk in Rconf (see > talk above) > - SVG and/or flash: seriously cool > > We had implemented all of the above, but unfortunately the source code > got lost in the black hole as we collapsed ;-) > > -- > _ _ > | |__ __ _| |_ ___ _ __ ___ __ _ _ __ > | '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ > | |_) | (_| | |_\__ \ | | | | | (_| | | | | > |_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_| > Running Debian GNU/Linux Sid (unstable) > batsman dot geo at yahoo dot com > > To kick or not to kick... > -- Somewhere on IRC, inspired by Shakespeare >