Sockets in Pharo CollaborActive Book

The description of sockets at http://book.pharo-project.org/book/networking/Socket/ is:

Socket is one of the main networking classes. You can create a new TCP socket with the message #newTCP.

This example creates a TCP socket and puts it into listening mode. After a client has connected, it reads data from the socket.

| server client |
server := Socket newTCP.
server listenOn: 12345 backlogSize: 4.
server waitForConnectionFor: 600.
client := server accept.
client receiveData

Huh?!  It looks like half the code in this snippet belongs on the server, and the other half on the client.  I tried:
  Server doit:
    server := Socket newTCP.
    server listenOn: 12345 backlogSize: 4.
    server waitForConnectionFor: 600.
  Client doit:
    server := Socket newTCP.
    server listenOn: 12345 backlogSize: 4.
    server waitForConnectionFor: 600.
    client := server accept.
    client receiveData.
but the server just hung forever.

After flopping around for a while, and checking the swiki, it seemed to be listenOn:backlogSize: that was the problem.  Everything went well with:
  Server DoIt:
    server := Socket newTCP.
    server listenOn: 8080.
    server waitForConnectionFor: 600.
    server sendData: 'Hello from the server'
  Client PrintIt:
    client := Socket newTCP.
    client connectTo: (NetNameResolver localHostAddress) port: 8080.
    client receiveData.

Anyway, I'd like to have this be clearer, but my knowledge is very basic.  Also, the class comment for socket reads "...Sockets are the lowest level of networking object in Squeak and are not normally used directly..." so is this where we want to direct people first?

Thanks.
Sean

Sean,

IMHO, you are correct to be unhappy.  In fairness, not only is half of the code "on the client" - half of it IS the client :)  It's just that the example is not very practical; no data are sent for the client to read.  The vast majority of (good) sockets programming is handling errors and non-responsive peers.

The most consistent story I have gotten is that ConnectionQueue is the preferred way to create a server; last I looked, it was broken, at least in Pharo.  It also offers no way, out of the box, to specify on which interface the server should be listening - that's kind of important.  Sadly, it polls for connections rather than blocking (just one Process, of course) until an event is generated as a client tries to connect.  It screams for some serious cleanup.  I have yet to look at what happens when, whether by socket or socket stream (which was not in the stream hierarchy and hence missing important protocol), the other side is non-responsive.  I doubt it will be ideal, which is to block only the Process attempting the connection.  Ditto that for DNS activity; only the process attempting it should suffer if the server is slow or completely unresponsive.  

IMHO, sockets should not have timeouts; they should simply block only the thread that initiates activity so that everything else moves along as expected.  On a server, a separate process can look for inactivity and terminate offending connections; on a client, either a similar watchdog or the user can make the call as to when to give up.  An event/announcement should be triggered off of a socket when its peer closes to enable timely cleanup.

Testing some of this stuff requires establishing lengthy I/O and powering off hubs at strategic times.  Until a system can survive that without hanging more than a calling thread, it's not ready.

Bill


testLocalServerAndClientNoThread
        "11-09 - try a server and a client in the same image.  Try without the separate read thread."

                | server port client serverSocket serverSocketStream text read |

        port := 4900.

        "11-09 - gag the prompter below"
        serverSocket := nil.

        server := ConnectionQueue portNumber:port queueLength:5.
        [
                client := SocketStream openConnectionToHostNamed:'localhost' port:port.
                [ serverSocket isNil ] whileTrue:[
                        serverSocket := server getConnectionOrNil.
                ].

                serverSocketStream := SocketStream on:serverSocket.
                text := 'Long live Tux!'.
                serverSocketStream nextPutAll:text; flush.

                read := client nextMany:text size.

                self should:[ read = text ].
                Transcript nextPutAll:'Just to make the point, we read: '; nextPutAll:read; cr; flush.

        ] ensure:[
                server destroy.
                serverSocketStream close.
                client close.
        ].

        "11-09 - no prompts"
        serverSocket := serverSocket.
        client := client.
        serverSocketStream := serverSocketStream.

        "
                NetworkSmokeTestCase prod:#testLocalServerAndClientNoThread.
        "


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Sean P. DeNigris [[hidden email]]
Sent: Sunday, August 29, 2010 5:05 PM
To: [hidden email]
Subject: [Pharo-project] Sockets in Pharo CollaborActive Book

The description of sockets at
http://book.pharo-project.org/book/networking/Socket/ is:

Socket is one of the main networking classes. You can create a new TCP
socket with the message #newTCP.
Huh?!  It looks like half the code in this snippet belongs on the server,
and the other half on the client.  I tried:
  Server doit:
    server := Socket newTCP.
    server listenOn: 12345 backlogSize: 4.
    server waitForConnectionFor: 600.
  Client doit:
    server := Socket newTCP.
    server listenOn: 12345 backlogSize: 4.
    server waitForConnectionFor: 600.
    client := server accept.
    client receiveData.
but the server just hung forever.

After flopping around for a while, and checking the swiki, it seemed to be
listenOn:backlogSize: that was the problem.  Everything went well with:
  Server DoIt:
    server := Socket newTCP.
    server listenOn: 8080.
    server waitForConnectionFor: 600.
    server sendData: 'Hello from the server'
  Client PrintIt:
    client := Socket newTCP.
    client connectTo: (NetNameResolver localHostAddress) port: 8080.
    client receiveData.

Anyway, I'd like to have this be clearer, but my knowledge is very basic.
Also, the class comment for socket reads "...Sockets are the lowest level of
networking object in Squeak and are not normally used directly..." so is
this where we want to direct people first?

Thanks.
Sean
--
View this message in context: http://forum.world.st/Sockets-in-Pharo-CollaborActive-Book-tp2399361p2399361.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi,

I'm currently working on a chapter about Sockets for the Pharo by example book.
I'm half way, though there is more material than what is on the pharo collabor-active book.
It's a pitty, that pharo by example and the collaborative book aren't linked.

Any way, I'll be happy ot send what I have written to anyone who request it.

Noury

On 29 août 2010, at 23:05, Sean P. DeNigris wrote:

Noury



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Noury,

I would like a copy.

Bill

bschwab AT anest DOT ufl DOT edu

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Noury Bouraqadi [[hidden email]]
Sent: Monday, August 30, 2010 9:41 AM
To: [hidden email]
Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book

Hi,

I'm currently working on a chapter about Sockets for the Pharo by example book.
I'm half way, though there is more material than what is on the pharo collabor-active book.
It's a pitty, that pharo by example and the collaborative book aren't linked.

Any way, I'll be happy ot send what I have written to anyone who request it.

Noury

On 29 août 2010, at 23:05, Sean P. DeNigris wrote:

Noury



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stef, Noury,

Thanks for doing this, and for the preview!

Sometimes being a good friend means getting tough, and it's time for that.  You are doing a great job of writing up how to create poorly designed socket applications.  They are poorly designed because of what we inherit from Squeak.  Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server.  Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user.  Nothing should block in either case except the calling Smalltalk Process.  If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread.

IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works.  At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options.

Bill



________________________________________
From: stephane ducasse [[hidden email]]
Sent: Monday, August 30, 2010 2:50 PM
To: Schwab,Wilhelm K
Subject: Fwd: [Pharo-project] Sockets in Pharo CollaborActive Book

Begin forwarded message:

> From: Stéphane Ducasse <[hidden email]>
> Date: August 29, 2010 11:09:50 PM GMT+02:00
> To: DeNigris Sean <[hidden email]>
> Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Stef, Noury,
>
> Thanks for doing this, and for the preview!
>
> Sometimes being a good friend means getting tough, and it's time for that.  You are doing a great job of writing up how to create poorly designed socket applications.  They are poorly designed because of what we inherit from Squeak.  Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server.  Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user.  Nothing should block in either case except the calling Smalltalk Process.  If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread.

John pointed us to a kind of socket that raises events on data.
Our problem is that we do not have manpower for that.

> IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works.  At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options.

Noury and luc started to rewrite sockets using Alien and people can help.
Nothing will happen magically :)


>
> Bill

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

My english sucks :P.

It's "How can I help with that?" xD



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stef,

Where does one go to sign up?  I am not certain that Alien is appropriate or necessary to make a solid socket foundation, but I am certain that the existing code is very sub-optimal and needs a real jolt.  If we are serious about fixing it (Linux, Windows and Mac), I am serious about helping.  

Bill


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
Sent: Monday, August 30, 2010 4:09 PM
To: [hidden email]
Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book

> Stef, Noury,
>
> Thanks for doing this, and for the preview!
>
> Sometimes being a good friend means getting tough, and it's time for that.  You are doing a great job of writing up how to create poorly designed socket applications.  They are poorly designed because of what we inherit from Squeak.  Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server.  Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user.  Nothing should block in either case except the calling Smalltalk Process.  If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread.

John pointed us to a kind of socket that raises events on data.
Our problem is that we do not have manpower for that.

> IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works.  At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options.

Noury and luc started to rewrite sockets using Alien and people can help.
Nothing will happen magically :)


>
> Bill

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Your English does not suck as bad as Squeak's sockets framework :)  I'm in too.  I can't do it all, but I can help and I can certainly set a high bar by ensuring that it works across Linux and Windows and does not lock when the network hardware loses power.  Sockets are sufficiently fundamental that we should document how to use them properly AND make Pharo work that way.



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Guillermo Polito [[hidden email]]
Sent: Monday, August 30, 2010 4:16 PM
To: [hidden email]
Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book

My english sucks :P.

It's "How can I help with that?" xD

On Mon, Aug 30, 2010 at 5:15 PM, Guillermo Polito <[hidden email]<mailto:[hidden email]>> wrote:


On Mon, Aug 30, 2010 at 5:09 PM, Stéphane Ducasse <[hidden email]<mailto:[hidden email]>> wrote:

> Stef, Noury,
>
> Thanks for doing this, and for the preview!
>
> Sometimes being a good friend means getting tough, and it's time for that.  You are doing a great job of writing up how to create poorly designed socket applications.  They are poorly designed because of what we inherit from Squeak.  Servers should not listen for a time period; they need to listen until told otherwise, and trigger events (notifications if preferred) when a client tries to connect, at which point a dedicated process accepts the connection - that process more or less is the server.  Clients should try to connect and read until told otherwise, either by a watchdog thread or by a user.  Nothing should block in either case except the calling Smalltalk Process.  If a client program does not hang because of a non-responsive server, an interacting user has the opportunity to hit a cancel button and put an end to wasted effort, or a watchdog can run and similarly #erminate the offending thread.

John pointed us to a kind of socket that raises events on data.
Our problem is that we do not have manpower for that.

> IMHO, we should not direct energy at documenting the current state of sockets; we should do the few remaining things to get something that really works.  At the same time, we should try as much as possible to allow IrDA and OpenSSL to appear as options.

Noury and luc started to rewrite sockets using Alien and people can help.
Nothing will happen magically :)

How should I help with that (a little)?

Cheers,
Guille

>
> Bill

_______________________________________________
Pharo-project mailing list
[hidden email]<mailto:[hidden email]>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi,

it just so happens I wrote that section on the colab wiki 1) primarily
to play around with the wiki engine 2) I was debugging Magma socket
issues and I could not find decent cookbook / snippets to illustrate
some simple examples and how to test it outside of Pharo itself.  I
just thought as an exercise i would write it down....

so in response to this entire thread, huh?

The example

>
> | server client |
> server := Socket newTCP.
> server listenOn: 12345 backlogSize: 4.
> server waitForConnectionFor: 600.
> client := server accept.
> client receiveData

is only server side. If you follow the sections, you can see I used
netcat as the client and illustrated some simple cmd line debugging
techniques.  the code above whilst it could of course contains bugs
and not use the right API is consistent in what it tries to do.

>so is this where we want to direct people first?

well, no, but sockets are fundamental and should be explained.  I had
only imagined it the seed for something bigger. the colab book will
not expand unless people start somewhere. It is a work in progress as
well, remember that...

I agree it would be great if there could be some synergy between all
the documentation efforts. I saw the colab book as a fairly free form
area to write stuff down in a simple manner that was hosted on a wiki
like space.  PBE is a more coherent, dedicated and managed publishing
effort. I had imagined the colab wiki could be a feeder for PBE but
time will tell.  It requires significant effort to produce something
of the quality of PBE.

cheers,
Mike

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael Roberts-2 wrote

The example
<snip>
is only server side. If you follow the sections, you can see I used
netcat as the client and illustrated some simple cmd line debugging
techniques.  the code above whilst it could of course contains bugs
and not use the right API is consistent in what it tries to do.

Ah, okay.  Now I got it.  The client temporary variable, along with the fact that this snippet is a section to itself confused me and I didn't keep reading.

>so is this where we want to direct people first?

Michael Roberts-2 wrote

well, no, but sockets are fundamental and should be explained.  I had
only imagined it the seed for something bigger. the colab book will
not expand unless people start somewhere. It is a work in progress as
well, remember that...

Cool, I appreciate you getting the ball rolling - I am trying to push it further! (and I don't know too much about sockets)

Sean

The deeper question is whether we want to document how things are, or they they *should be* - which is VERY much different from the eventless and timeout ridden design that we have now.  It desperately needs to be redesigned.




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Sean P. DeNigris [[hidden email]]
Sent: Tuesday, August 31, 2010 10:41 PM
To: [hidden email]
Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book

Michael Roberts-2 wrote:
>
> The example
> <snip>
> is only server side. If you follow the sections, you can see I used
> netcat as the client and illustrated some simple cmd line debugging
> techniques.  the code above whilst it could of course contains bugs
> and not use the right API is consistent in what it tries to do.
>
Ah, okay.  Now I got it.  The client temporary variable, along with the fact
that this snippet is a section to itself confused me and I didn't keep
reading.

>so is this where we want to direct people first?

Michael Roberts-2 wrote:
>
> well, no, but sockets are fundamental and should be explained.  I had
> only imagined it the seed for something bigger. the colab book will
> not expand unless people start somewhere. It is a work in progress as
> well, remember that...
>
Cool, I appreciate you getting the ball rolling - I am trying to push it
further! (and I don't know too much about sockets)

Sean
--
View this message in context: http://forum.world.st/Sockets-in-Pharo-CollaborActive-Book-tp2399361p2402542.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

El mar, 31-08-2010 a las 23:59 -0400, Schwab,Wilhelm K escribió:
> The deeper question is whether we want to document how things are, or they they *should be* - which is VERY much different from the eventless and timeout ridden design that we have now.  It desperately needs to be redesigned.
>

Maybe it needs someone to lead the effort. Why don't you begin with
this? It appears that you know a lot about sockets. Certainly the pharo
community will be grateful of your efforts.
But saying again and again that sockets sucks doesn't fix it for
anybody, including you.

So, as Stef says, less saying, more coding. Very respectfully, show us
your code :)

Cheers

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I am certainly willing to help with the work, and while I am by no means an expert on sockets, I have seen some good code.  As we stand now, it is all but impossible to do things correctly; that will become clear by contrast, but only if people are willing to challenge their ideas.  Timeouts are bad (unless provided by helper methods so they are explicitly requested); errors are helpful (silent failures are toxic); events are essential.

It sounds like there are at least four of us who have strong interest in getting this right.  We probably should have some discussion here, then describe a plan on the wiki and finally start coding.

Bill

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Miguel Enrique Cobá Martínez [[hidden email]]
Sent: Wednesday, September 01, 2010 12:10 AM
To: [hidden email]
Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book

El mar, 31-08-2010 a las 23:59 -0400, Schwab,Wilhelm K escribió:
> The deeper question is whether we want to document how things are, or they they *should be* - which is VERY much different from the eventless and timeout ridden design that we have now.  It desperately needs to be redesigned.
>

Maybe it needs someone to lead the effort. Why don't you begin with
this? It appears that you know a lot about sockets. Certainly the pharo
community will be grateful of your efforts.
But saying again and again that sockets sucks doesn't fix it for
anybody, including you.

So, as Stef says, less saying, more coding. Very respectfully, show us
your code :)

Cheers

--
Miguel Cobá
http://miguel.leugim.com.mx


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi all!

Two notes (no, haven't read all posts on this subject):

1. IMHO for almost 99% of your needs you would use SocketStream and not
Socket directly to write a socket client. I wrote the current
SocketStream implementation and I have written several clients using it
- like the latest StompProtocol on SS etc. Please, please, use
SocketStream in your introduction to socket client programming!

2. I haven't looked at Andreas' new WebServer but I presume it is a
"standard" forking server just like the old Comanche/KomHttpServer
codebase is. A while back I wrote Blackfoot - a SimpleCGI implementation
and then I extracted the essential "forking Socket server" code from
KomHttpServer so that it can be easily understood and reused. I tend to
point to Blackfoot as a very good "example" to use in this regard. We
could even split out the generic part as a "standard class" to use. In
fact, Stephen Pair did this with the TcpServices library a long time ago
when he rewrote Comanche into KomHttpServer BUT... I think it got a bit
overengineered and would instead point to Blackfoot as a good candidate
for such a "SocketServer" class.


regards, Göran

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>>
> Cool, I appreciate you getting the ball rolling - I am trying to push it
> further! (and I don't know too much about sockets)

no worries. I have found this guide really useful:   http://beej.us/guide/bgnet/

Even if you don't read C, there are lots of comments throughout.

cheers
Mike

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

please continue :)

On Sep 1, 2010, at 1:17 AM, Michael Roberts wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Sep 1, 2010, at 8:58 AM, Göran Krampe wrote:

> Hi all!
>
> Two notes (no, haven't read all posts on this subject):
>
> 1. IMHO for almost 99% of your needs you would use SocketStream and not Socket directly to write a socket client. I wrote the current SocketStream implementation and I have written several clients using it - like the latest StompProtocol on SS etc. Please, please, use SocketStream in your introduction to socket client programming!

Yes this is the missing section in noury/luc chapter :)

> 2. I haven't looked at Andreas' new WebServer but I presume it is a "standard" forking server just like the old Comanche/KomHttpServer codebase is. A while back I wrote Blackfoot - a SimpleCGI implementation and then I extracted the essential "forking Socket server" code from KomHttpServer so that it can be easily understood and reused. I tend to point to Blackfoot as a very good "example" to use in this regard. We could even split out the generic part as a "standard class" to use. In fact, Stephen Pair did this with the TcpServices library a long time ago when he rewrote Comanche into KomHttpServer BUT... I think it got a bit overengineered and would instead point to Blackfoot as a good candidate for such a "SocketServer" class.

sound cool do you have a little 2 pages intro to blackfoot?

Stef

>
>
> regards, Göran
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

would be cool to get inspired and produce material for smalltalkers.


On Sep 1, 2010, at 9:03 AM, Michael Roberts wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project