Euruko 2003 (1st European Ruby Conference) Over 
Author Message
 Euruko 2003 (1st European Ruby Conference) Over

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://www.*-*-*.com/ )

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



Fri, 09 Dec 2005 06:53:21 GMT  
 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


Quote:

> 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



Fri, 09 Dec 2005 15:41:50 GMT  
 Euruko 2003 (1st European Ruby Conference) Over

Quote:

> 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.

recently I started adding such documentation here:
http://www.rubygarden.org/ruby?RubyApi

I hope many more of the common used function will find thier way to these
pages. At the moment its more a user-manual to the extension/embedding
API, than it is a reference-manual.

I would like comments on this:  
* what should such site contain ?
* what is the most common extension/embedding functions ?
* how should it be presented to the user ?
* how much text should be written about each function ?

How can the links be improved. Example:
[/RbClassNewInstance rb_class_new_instance(argc, argv, class)]
How do I get rid of '/RbClassNewInstance', so it doesn't show up in the
link ?

--
Simon Strandgaard



Fri, 09 Dec 2005 17:17:08 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Euruko 2003 (1st European Ruby Conference) news

2. EuRuKo: European Ruby conference

3. Ruby Conference 2003 pre-registration

4. Reminder: Pre-registration for Ruby Conference 2003 is open

5. Ruby Conference 2003 pre-registration now open!

6. International Lisp Conference 2003 (ILC 2003)

7. International Lisp Conference 2003 (ILC 2003)

8. International Lisp Conference 2003 (ILC 2003)

9. International Lisp Conference 2003 (ILC 2003)

10. International Lisp Conference 2003 (ILC 2003)

11. International Lisp Conference 2003 (ILC 2003)

12. International Lisp Conference 2003 (ILC 2003)

 

 
Powered by phpBB® Forum Software