- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 84

by Eliot Miranda

2010/9/12 Michael Roberts <mike(a)mjr104.co.uk> > > Sort of like > > Progressor progressDuring:[:bar | > ... > Progressor progressDuring:[:bar | > ... > Progressor progressDuring:[:bar | > > at different levels in the stack rather than letting the exception find the > notifier each time you would do it explicitly. Perhaps there is a reason > why that wouldn't work. > Simply because the progress indications occur in unrelated methods, not in a single method, so they can't be written this way. The issue is, when wanting to show a progress bar for some activity, whether there already exists an open progress bar in some outer activation. Essentially a signal is the most convenient way to do this if one wants to search the stack (a signal is an abstraction over stack searching). The other approach is to use a per-process variable (thread-local variable). Squeak uses the former style. But there's no reason why one can't cache the lookup of the first signal. I don't see any need for sending the signal on each increment of the progress indicator or each activation of the action block. cheers Eliot > > Cheers mike > > On 13 Sep 2010, at 00:26, Michael Roberts <mike(a)mjr104.co.uk> wrote: > > When I looked through the code I imagined one could implement the nesting > by just maintaining a stack on the progress initiator sort of like > > ... > > > On 11 Sep 2010, at 16:45, Eliot Miranda < <eliot.miranda(a)gmail.com> > eliot.miranda(a)gmail.com> wrote: > > Hi Ralph, > > On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland < <rpboland(a)gmail.com><rpboland(a)gmail.com> > rpboland(a)gmail.com> wrote: > >> > Hi, i don't know why things are done the way they are... >> > Is your question how the exception mechanism works, or why it is >> > needed to be done with an exception? as opposed to say doing it >> > some other way? >> >> > The direct answer to your question is that given it is implemented in >> > terms of exceptions, the signal is needed to trigger the >> > defaultAction, or to allow someone higher up in the stack to trap it >> > and redirect the notification. >> >> > cheers, >> > Mike >> >> >> I am no expert on Exceptions but I do understand this. >> What I don't understand is WHY ProgressInitiationException >> is used and why a signal is sent to its instance to get the ball rolling. >> >> Could not SystemProgressMorph be modified to handle this? >> >> Alternatively, could not some other new (non-exception) class handle >> the logic where an instance of that class is created and gets the ball >> rolling without sending a signal to itself? For me, currently, this >> is the more intuitive way to do things. Why use signals when they >> are not needed? (Or are they needed for some reason unknown to me?) >> >> The modifications I am planning to make to the ProgressDisplay >> package look easier if I get rid of the signal handling. >> But I don't know what I will be breaking or what functionality will >> be lost if I get rid of the signal handling. >> So I need to know WHY? >> > > I tried to answer your question the first time round but as I looked at the > code I found that I didn't understand it, and so gave up on my explanation > :). It seemed to me that the reason for using a signal was to handle > nesting. One raises the progress initiation signal in the wrapper to the > action block to get progress to display in the right progress bar. If the > signal is uncaught then its defaultAction would open up a new progress bar > with one progress strip and initiate processing of the progress block, > providing a handler for the progress initiation signal. If the signal is > caught (by the handler provided at the first level) then the existing > progress bar is extended with a new progress strip for the nested progress. > At least that's how I thought it worked but I couldn't work out how the > handler worked. > > If I were writing it I would still use the signal to find if the progress > was nested but I /would not/ put the code in the defaultAction. Instead the > signal would answer if it was nested and all the code would be at the point > where the signal is raised. For this one can use a simple Notification, > using its tag to disambiguate it e.g. > > [Notification new tag: #progressBar; signal] > on: Notification > do: [:ex| > ex tag == #progressBar ifTrue: [ex resume: true]. > ex pass] true > > So e.g. > > outerBarOrNil := Notification new tag: #progressBar; signal. > ... if nested add to the existing bar otherwise create a new bar ... > [actionBlock value: bar] > on: Notification > do: [:ex| > ex tag == #progressBar ifTrue: [ex resume: bar]. > ex pass] > > my 2Â¢ > > If you can make the tests pass with simpler code then go for it! > > best > Eliot > > > >> Regards, >> >> Ralph Boland >> >> > On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland < <rpboland(a)gmail.com><rpboland(a)gmail.com> >> rpboland(a)gmail.com> wrote: >> > > I posted the following earlier to the Squeak list but didn't get a >> responce. >> > > Hopefully someone on the Pharo list can help me. ?I need this >> information >> > > so I can make some planned changes to the ProgressDisplay package I >> released >> > > a while back. >> > > >> > > >> ----------------------------------------------------------------------------------------------------------------- >> > > >> > > A SystemProgressMorph is used to display progress while some >> computation >> > > is being done. ?Furthermore the progress bars can be stacked to show >> progress >> > > of component computations within a computation. >> > > This I understand and understand most of the code. >> > > But not All. >> > > What I have trouble with is understanding why a >> ProgressInitiationException >> > > is needed. ?In particular, String>>displayProgressAt:from:to:during: >> > > does: >> > > >> > > ProgressInitiationException >> > > >> display: self >> > > at: aPoint >> > > from: minVal >> > > to: maxVal >> > > during: workBlock. >> > > >> > > >> > > This method sets a few variables and then does: >> > > >> > > ^self signal >> > > >> > > This signal is caught where upon a SystemProgressMorph is started or >> > > extended with >> > > an additional progress bar. >> > > >> > > But I don't understand why sending a signal to a >> ProgressInitiationException >> > > is needed to get the ball rolling, >> > > >> > > Can someone please explain why things are done the way they are? >> > > >> > > >> > > Regards, >> > > >> > > Ralph Boland >> >> _______________________________________________ >> Pharo-project mailing list >> <Pharo-project(a)lists.gforge.inria.fr><Pharo-project(a)lists.gforge.inria.fr> >> Pharo-project(a)lists.gforge.inria.fr >> <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project><http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > <Pharo-project(a)lists.gforge.inria.fr>Pharo-project(a)lists.gforge.inria.fr > <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 13, 2010

Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 84

by Michael Roberts

Sort of like Progressor progressDuring:[:bar | ... Progressor progressDuring:[:bar | ... Progressor progressDuring:[:bar | at different levels in the stack rather than letting the exception find the notifier each time you would do it explicitly. Perhaps there is a reason why that wouldn't work. Cheers mike On 13 Sep 2010, at 00:26, Michael Roberts <mike(a)mjr104.co.uk> wrote: > When I looked through the code I imagined one could implement the > nesting by just maintaining a stack on the progress initiator sort > of like > > ... > > > On 11 Sep 2010, at 16:45, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Ralph, >> >> On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland <rpboland(a)gmail.com> >> wrote: >> > Hi, i don't know why things are done the way they are... >> > Is your question how the exception mechanism works, or why it is >> > needed to be done with an exception? as opposed to say doing it >> > some other way? >> >> > The direct answer to your question is that given it is >> implemented in >> > terms of exceptions, the signal is needed to trigger the >> > defaultAction, or to allow someone higher up in the stack to trap >> it >> > and redirect the notification. >> >> > cheers, >> > Mike >> >> >> I am no expert on Exceptions but I do understand this. >> What I don't understand is WHY ProgressInitiationException >> is used and why a signal is sent to its instance to get the ball >> rolling. >> >> Could not SystemProgressMorph be modified to handle this? >> >> Alternatively, could not some other new (non-exception) class handle >> the logic where an instance of that class is created and gets the >> ball >> rolling without sending a signal to itself? For me, currently, this >> is the more intuitive way to do things. Why use signals when they >> are not needed? (Or are they needed for some reason unknown to me?) >> >> The modifications I am planning to make to the ProgressDisplay >> package look easier if I get rid of the signal handling. >> But I don't know what I will be breaking or what functionality will >> be lost if I get rid of the signal handling. >> So I need to know WHY? >> >> I tried to answer your question the first time round but as I >> looked at the code I found that I didn't understand it, and so gave >> up on my explanation :). It seemed to me that the reason for using >> a signal was to handle nesting. One raises the progress initiation >> signal in the wrapper to the action block to get progress to >> display in the right progress bar. If the signal is uncaught then >> its defaultAction would open up a new progress bar with one >> progress strip and initiate processing of the progress block, >> providing a handler for the progress initiation signal. If the >> signal is caught (by the handler provided at the first level) then >> the existing progress bar is extended with a new progress strip for >> the nested progress. At least that's how I thought it worked but I >> couldn't work out how the handler worked. >> >> If I were writing it I would still use the signal to find if the >> progress was nested but I /would not/ put the code in the >> defaultAction. Instead the signal would answer if it was nested >> and all the code would be at the point where the signal is raised. >> For this one can use a simple Notification, using its tag to >> disambiguate it e.g. >> >> [Notification new tag: #progressBar; signal] >> on: Notification >> do: [:ex| >> ex tag == #progressBar ifTrue: [ex resume: true]. >> ex pass] true >> >> So e.g. >> >> outerBarOrNil := Notification new tag: #progressBar; signal. >> ... if nested add to the existing bar otherwise create a new bar ... >> [actionBlock value: bar] >> on: Notification >> do: [:ex| >> ex tag == #progressBar ifTrue: [ex resume: bar]. >> ex pass] >> >> my 2Â¢ >> >> If you can make the tests pass with simpler code then go for it! >> >> best >> Eliot >> >> >> >> Regards, >> >> Ralph Boland >> >> > On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland >> <rpboland(a)gmail.com> wrote: >> > > I posted the following earlier to the Squeak list but didn't >> get a responce. >> > > Hopefully someone on the Pharo list can help me. ?I need this >> information >> > > so I can make some planned changes to the ProgressDisplay >> package I released >> > > a while back. >> > > >> > > >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> --- >> -------------------------------------------------------------------- >> > > >> > > A SystemProgressMorph is used to display progress while some >> computation >> > > is being done. ?Furthermore the progress bars can be stacked to >> show progress >> > > of component computations within a computation. >> > > This I understand and understand most of the code. >> > > But not All. >> > > What I have trouble with is understanding why a >> ProgressInitiationException >> > > is needed. ?In particular, >> String>>displayProgressAt:from:to:during: >> > > does: >> > > >> > > ProgressInitiationException >> > > >> display: self >> > > at: aPoint >> > > from: minVal >> > > to: maxVal >> > > during: workBlock. >> > > >> > > >> > > This method sets a few variables and then does: >> > > >> > > ^self signal >> > > >> > > This signal is caught where upon a SystemProgressMorph is >> started or >> > > extended with >> > > an additional progress bar. >> > > >> > > But I don't understand why sending a signal to a >> ProgressInitiationException >> > > is needed to get the ball rolling, >> > > >> > > Can someone please explain why things are done the way they are? >> > > >> > > >> > > Regards, >> > > >> > > Ralph Boland >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2010

Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 84

by Michael Roberts

When I looked through the code I imagined one could implement the nesting by just maintaining a stack on the progress initiator sort of like ... On 11 Sep 2010, at 16:45, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Ralph, > > On Sat, Sep 11, 2010 at 1:05 AM, Ralph Boland <rpboland(a)gmail.com> > wrote: > > Hi, i don't know why things are done the way they are... > > Is your question how the exception mechanism works, or why it is > > needed to be done with an exception? as opposed to say doing it > > some other way? > > > The direct answer to your question is that given it is implemented > in > > terms of exceptions, the signal is needed to trigger the > > defaultAction, or to allow someone higher up in the stack to trap it > > and redirect the notification. > > > cheers, > > Mike > > > I am no expert on Exceptions but I do understand this. > What I don't understand is WHY ProgressInitiationException > is used and why a signal is sent to its instance to get the ball > rolling. > > Could not SystemProgressMorph be modified to handle this? > > Alternatively, could not some other new (non-exception) class handle > the logic where an instance of that class is created and gets the ball > rolling without sending a signal to itself? For me, currently, this > is the more intuitive way to do things. Why use signals when they > are not needed? (Or are they needed for some reason unknown to me?) > > The modifications I am planning to make to the ProgressDisplay > package look easier if I get rid of the signal handling. > But I don't know what I will be breaking or what functionality will > be lost if I get rid of the signal handling. > So I need to know WHY? > > I tried to answer your question the first time round but as I looked > at the code I found that I didn't understand it, and so gave up on > my explanation :). It seemed to me that the reason for using a > signal was to handle nesting. One raises the progress initiation > signal in the wrapper to the action block to get progress to display > in the right progress bar. If the signal is uncaught then its > defaultAction would open up a new progress bar with one progress > strip and initiate processing of the progress block, providing a > handler for the progress initiation signal. If the signal is caught > (by the handler provided at the first level) then the existing > progress bar is extended with a new progress strip for the nested > progress. At least that's how I thought it worked but I couldn't > work out how the handler worked. > > If I were writing it I would still use the signal to find if the > progress was nested but I /would not/ put the code in the > defaultAction. Instead the signal would answer if it was nested and > all the code would be at the point where the signal is raised. For > this one can use a simple Notification, using its tag to > disambiguate it e.g. > > [Notification new tag: #progressBar; signal] > on: Notification > do: [:ex| > ex tag == #progressBar ifTrue: [ex resume: true]. > ex pass] true > > So e.g. > > outerBarOrNil := Notification new tag: #progressBar; signal. > ... if nested add to the existing bar otherwise create a new bar ... > [actionBlock value: bar] > on: Notification > do: [:ex| > ex tag == #progressBar ifTrue: [ex resume: bar]. > ex pass] > > my 2Â¢ > > If you can make the tests pass with simpler code then go for it! > > best > Eliot > > > > Regards, > > Ralph Boland > > > On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland <rpboland(a)gmail.com> > wrote: > > > I posted the following earlier to the Squeak list but didn't get > a responce. > > > Hopefully someone on the Pharo list can help me. ?I need this > information > > > so I can make some planned changes to the ProgressDisplay > package I released > > > a while back. > > > > > > > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > --- > -------------------------------------------------------------------- > > > > > > A SystemProgressMorph is used to display progress while some > computation > > > is being done. ?Furthermore the progress bars can be stacked to > show progress > > > of component computations within a computation. > > > This I understand and understand most of the code. > > > But not All. > > > What I have trouble with is understanding why a > ProgressInitiationException > > > is needed. ?In particular, > String>>displayProgressAt:from:to:during: > > > does: > > > > > > ProgressInitiationException > > > > display: self > > > at: aPoint > > > from: minVal > > > to: maxVal > > > during: workBlock. > > > > > > > > > This method sets a few variables and then does: > > > > > > ^self signal > > > > > > This signal is caught where upon a SystemProgressMorph is > started or > > > extended with > > > an additional progress bar. > > > > > > But I don't understand why sending a signal to a > ProgressInitiationException > > > is needed to get the ball rolling, > > > > > > Can someone please explain why things are done the way they are? > > > > > > > > > Regards, > > > > > > Ralph Boland > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2010

[Pharo-project] Updated http://isqueak.org/PlatformVMAPI

by John M McIntosh

I spent a few hours this morning and updated the VM Platform API documentation at http://isqueak.org/PlatformVMAPI To capture the details of the OS-X Cocoa work. (Squeak macintosh VM 5.x) For the most part the iPhone & OS-X implementation share a common Objective-C code base because Apple uses OSX as the foundation for both devices which shares most of the functionality except for the UI components. Thus for the most part I could say see iPhone implementation details. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 12, 2010

Re: [Pharo-project] update to OCompletion

by Francisco Ortiz PeÃ±aloza

On Sun, Sep 12, 2010 at 5:08 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> This is because when you have a line split into multiple lines, I want Enter to mean new line, not complete. This is particularly the case when you have pseudo-domain specific languages like in Glamour or Mondrian. > > A bit hard to get used to it, but I agree. Ok, you've got a good point. Thanks to point me out. > >> Nevertheless, I would say that once I pressed the down arrow, my focus is to the completion, and thus enter should mean selection of the completion. > > +1 I totally agree on this one. Francisco > > Alexandre > >> >> >> >> On 12 Sep 2010, at 01:30, Francisco Ortiz PeÃ±aloza wrote: >> >>> Hi, i'm trying the latest version cause i's tired of waiting for the >>> switch to the longer list of suggestions. But i don't understand the >>> following change >>> >>> -removed enter to insert a completion >>> >>> am i missing something? why do u ppl make this change? >>> >>> Cheers, >>> Francisco Ortiz PeÃ±aloza >>> >>> On Wed, Aug 4, 2010 at 8:20 PM, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >>>> I shall definitely give that a read - especially now i have an example to >>>> think back on. >>>> >>>> By the way - these chapters that people keep writing, are a great help (the >>>> monticello one certainly took away a huge load of frustrations I was having) >>>> - so thanks to everyone that keeps chipping away at them! >>>> >>>> tim >>>> >>>> On 4 Aug 2010, at 18:44, Mariano Martinez Peck wrote: >>>> >>>>> I am glad I helped. You can also take a look to the Metacello draft we >>>>> wrote for Pharo By Example 2. I attach it. >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow." >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 12, 2010

[Pharo-project] Improving generate accessors for refactoring browser

by Bart Gauquie

Dear list, I've noticed that when I'm using the generate accessors refactoring, I'm always adapting the generated code for the mutator: number: anObject number := anObject to: number: aNumber number := aNumber So I've adapted the refactoring code a bit so that it automatically generates this correctly. Anybody also thinks this is useful? If so, I will create a bug/improvement and a slice for it. Kind regards, Bart

Sept. 12, 2010

Re: [Pharo-project] Compiling the VM for MacOSX

by StÃ©phane Ducasse

> > > The instructions seems to target building a VM from April of 2009. Lots has changed since then to make the > process of building a Cocoa OS-X VM to match a distributed pre-built VM version more of a one-step process. > > Otherwise it's just too hard to mesh the pieces together between an arbitrary squeak image, vmmaker, and > the source from squeakvm.org which is a bit sad. Because we cannot run an hudson srever to automatically build vms. I do not really understand why this would not be possible. Stef > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 12, 2010

Re: [Pharo-project] Alien and multi-threading

by Mariano Martinez Peck

2010/9/12 Eliot Miranda <eliot.miranda(a)gmail.com> > Hi Noury, > > likely there will be, as I'm currently working on threading Cog for > callouts, callbacks et al. But currently I believe there is no > multi-threading of Alien. > Wasen't that the work of the GSoC project? > > best, > Eliot > > On Sun, Sep 12, 2010 at 9:31 AM, Noury Bouraqadi <bouraqadi(a)gmail.com>wrote: > >> Hi, >> >> Is there any possibility for multi-threading with Alien? >> >> Noury @ ESUG 2010 - Barcelona :-) >> --- >> 18th International Smalltalk Joint Conference, September 13 -17 2010 >> Barcelona, Spain. >> http://www.esug.org/Conferences/2010 >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 12, 2010

[Pharo-project] [ANN] Seaside 3.0 released

by Michael Davies

The Seaside core developers are pleased to announce the release of Seaside 3.0 - see http://seaside.st/seaside30 for more information. The changes in 3.0 are intended to make using and extending Seaside faster and easier. Useful Links: Full Release Announcement http://seaside.st/seaside30 Seaside 3.0 Detailed Release Notes http://seaside.st/community/development/seaside30 Seaside One-Click Experience 3.0 (runs with one-click on Mac, Windows and Linux) http://www.seaside.st/distributions/Seaside-3.0-final.app.zip Seaside 3.0 Developer Image 3.0 (for Pharo developers) http://www.seaside.st/distributions/Seaside-3.0-final.zip Seaside 3.0 SqueakSource Repository http://www.squeaksource.com/Seaside30.html

Sept. 12, 2010

Re: [Pharo-project] Alien and multi-threading

by Eliot Miranda

Hi Noury, likely there will be, as I'm currently working on threading Cog for callouts, callbacks et al. But currently I believe there is no multi-threading of Alien. best, Eliot On Sun, Sep 12, 2010 at 9:31 AM, Noury Bouraqadi <bouraqadi(a)gmail.com>wrote: > Hi, > > Is there any possibility for multi-threading with Alien? > > Noury @ ESUG 2010 - Barcelona :-) > --- > 18th International Smalltalk Joint Conference, September 13 -17 2010 > Barcelona, Spain. > http://www.esug.org/Conferences/2010 > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 12, 2010