November 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] HostWindows rewrite

by Igor Stasenko

2008/11/24 Bill Schwab <BSchwab(a)anest.ufl.edu>: > I agree: it would be useful to control host windows in some way, whether > as described below, or via Wx, etc. The native windows/controls have > their uses, though they are not (IMHO) the panacea that many believe > them to be. So, it would be very nice to be able to mix native and > emulated GUI elements. > > Bill > I just thought, that having multiple native windows can help great in debugging graphics (Morphic) code. Currently, if you got a bug in morphic code, there's a big chance in complete loss the display and no way to see anything or debug it. With multiple host windows, you can spawn a new host window with debugger, and then step through the drawing routines and see what is happening and how your code drawing things. > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > >>>> antony.blakey(a)gmail.com 11/9/2008 4:35 PM >>> > > On 09/11/2008, at 10:17 PM, Igor Stasenko wrote: > >> What you'll never see in new plugin: >> - native widgets support or any kind of dealing with native widgets/ > >> controls. > > Notwithstanding this, IMO a really good feature would be the ability > to create and manage native views within windows, where e.g. a Morph > could be 'backed' by a native view. This feature alone is enough to > later allow native controls (such as WebKit) to mix with 'light' > controls with correct z-ordering/clipping/event handling etc. > > Of course one could retrofit such a feature, but using native views > from the start would encourage any Morphic mods (or other widget set) > > to use native views and hence be ready for better integration. > > Antony Blakey > -------------------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > Human beings, who are almost unique in having the ability to learn > from the experience of others, are also remarkable for their apparent > > disinclination to do so. > -- Douglas Adams > > > > _______________________________________________ > 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 > -- Best regards, Igor Stasenko AKA sig.

Nov. 24, 2008

Re: [Pharo-project] 10164 Image freezing

by StÃ©phane Ducasse

Ok thanks I will continue to improve the tests with traits so we will see if the bug show up again. In that case I will save the image if I can with the debugger. stef On Nov 24, 2008, at 3:48 PM, David RÃ¶thlisberger wrote: > >> I cannot predictably reproduce the bug. >> It happens really when editing class having traits with OB. >> We tried with >> TCloneTest -{#foo} >> and it did not break (we though that if we put a wrong selector >> this could be the problem >> but this was not). I breaks when you put a real selector >> corresponding to a compiled method > > What I can tell from your debugger picture is that it searches for a > selector in SymbolTest that does not exist. > Probably what happens is that you remove a trait method in the class > definition, then the browser updates, but still refers to that > removed trait method which is actually not present anymore. So the > browser model is not in sync with the system model in this case. > But the strange thing is that the browser always asks the class > organizer for the methods, so maybe it's the organizer that does not > reflect the change to the class (yet). > So I don't know whether the browser is to blame or not. > > What I did now is to check first whether the class indeed defines a > particular method before accessing it. This should avoid the > problem, but maybe the real problem lies somewhere else. > > David > > >> My hypothesis was that may be the compiled get a methodClass but >> this is strange that it does not >> understand this message I have the impression that we get a nil >> somehwere ;-/ >> Stef >> On Nov 21, 2008, at 4:16 PM, Adrian Lienhard wrote: >>> If you can reproduce the problem, can you go back to an earlier >>> image version to see if it exists there too? >>> Could you provide an explanation of how to reproduce the problem? >>> >>> Adrian >>> >>> On Nov 21, 2008, at 16:04 , Marcus Denker wrote: >>> >>>> >>>> On 21.11.2008, at 15:30, StÃ©phane Ducasse wrote: >>>> >>>>> Hi all >>>>> >>>>> I loaded >>>>> OB >>>>> shout >>>>> ecompletion >>>>> >>>>> and we were apply coding with damien. >>>>> And the image froze (deeply) when we redefined a class. >>>>> >>>>> So the thread changes may be a problem. >>>> >>>> The only change done was to add one variable to Process (at the >>>> end)... I don't think this is the problem. >>>> What else could it be? >>>> The only other large change was >>>> >>>> a) ifNotNil with argument, but that was already earlier >>>> b) OldSocket removal. >>>> >>>> anything else? >>>> >>>> Marcus >>>> >>>> >>>> -- >>>> Marcus Denker -- denker(a)iam.unibe.ch >>>> http://www.iam.unibe.ch/~denker >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> 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 >

Nov. 24, 2008

Re: [Pharo-project] New sensor code

by StÃ©phane Ducasse

I saw signs of that problem in the recent past. stef On Nov 24, 2008, at 12:25 PM, Gary Chambers wrote: > Perhaps two processes are *writing* to the change log at the same > time then (shudders). > > Regards, Gary. > > ----- Original Message ----- From: "Marcus Denker" <denker(a)iam.unibe.ch > > > To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, November 24, 2008 11:13 AM > Subject: Re: [Pharo-project] New sensor code > > > > On 24.11.2008, at 12:09, Gary Chambers wrote: > >> Unexplained SyntaxErrors are often, in my experience, a sign of >> multiple processes concurrently trying to access the changes >> file... Have the improvements we supplied for RemoteString been >> applied? >> > > Yes. > > Marcus > >> Regards, Gary. >> >> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com >> > >> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Saturday, November 22, 2008 6:20 PM >> Subject: Re: [Pharo-project] New sensor code >> >> >>> and looks like >>> InputEventFetcher>>eventLoop contains syntax errors, a window >>> variable >>> shown in red color by my browser. :) >>> >>> >>> 2008/11/22 Igor Stasenko <siguctua(a)gmail.com>: >>>> 2008/11/22 Igor Stasenko <siguctua(a)gmail.com>: >>>>> I just loaded your changeset and have something to report :) >>>>> >>>>> It looks like it having bigger poll periods than old sensor, or >>>>> works slower. >>>>> An overall performance feels a bit more sluggish comparing to old >>>>> implementation. >>>>> Just open a window with long text and hold down the up/down key >>>>> and >>>>> see the difference. >>>>> Or try to resize browser window - you can notice its not so >>>>> smooth as >>>>> in old image. >>>>> >>>> >>>> ... which can be fixed easily by reducing poll period from 100ms >>>> to 10ms in >>>> InputEventPollingFetcher>>eventLoop >>>> >>>>> 2008/11/22 Michael Rueger <m.rueger(a)acm.org>: >>>>>> StÃ©phane Ducasse wrote: >>>>>>> >>>>>>> so how do we proceed? >>>>>>> We try to load it, play with it then? >>>>>>> integrate it into pharo and you continue hacking and fixing? >>>>>> >>>>>> this version is really meant to be smoke tested, it needs some >>>>>> work on the >>>>>> comments and on the user interrupt handling. >>>>>> >>>>>> So please load it into your images, make sure you always have >>>>>> backups and >>>>>> see how it holds up. If it turns out to be reasonably stable >>>>>> we can push it. >>>>>> >>>>>> >>>>>>> 1- Here I have a question >>>>>>> =================== >>>>>>> in this comment EventSensor = InputEventSensor? >>>>>> >>>>>> the comment is only a copy from EventSensor, needs to be >>>>>> rewritten. >>>>>> If somebody has a better suggestion for naming this class I'm >>>>>> open to >>>>>> suggestions. >>>>>> >>>>>>> 2- I saw a method defined on Controller >>>>>>> But there are no reference to this class in pharo. So we could >>>>>>> remove >>>>>>> Controller I imagine >>>>>> >>>>>> It is superclass of other classes, so I'm not sure. >>>>>> >>>>>>> 3- could you tell me >>>>>>> what kind of code we would have to change? >>>>>> >>>>>> Not sure what you mean? For now no code in the image needs to >>>>>> be changed. >>>>>> >>>>>> >>>>>> Michael >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>>> project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> -------------------------------------------------------------------------------- >> >> >>> _______________________________________________ >>> 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 > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > 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 >

Nov. 24, 2008

Re: [Pharo-project] HostWindows rewrite

by Bill Schwab

I agree: it would be useful to control host windows in some way, whether as described below, or via Wx, etc. The native windows/controls have their uses, though they are not (IMHO) the panacea that many believe them to be. So, it would be very nice to be able to mix native and emulated GUI elements. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> antony.blakey(a)gmail.com 11/9/2008 4:35 PM >>> On 09/11/2008, at 10:17 PM, Igor Stasenko wrote: > What you'll never see in new plugin: > - native widgets support or any kind of dealing with native widgets/ > controls. Notwithstanding this, IMO a really good feature would be the ability to create and manage native views within windows, where e.g. a Morph could be 'backed' by a native view. This feature alone is enough to later allow native controls (such as WebKit) to mix with 'light' controls with correct z-ordering/clipping/event handling etc. Of course one could retrofit such a feature, but using native views from the start would encourage any Morphic mods (or other widget set) to use native views and hence be ready for better integration. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 24, 2008

Re: [Pharo-project] 10164 Image freezing

by David RÃ¶thlisberger

> I cannot predictably reproduce the bug. > It happens really when editing class having traits with OB. > > We tried with > TCloneTest -{#foo} > > and it did not break (we though that if we put a wrong selector this > could be the problem > but this was not). I breaks when you put a real selector corresponding > to a compiled method What I can tell from your debugger picture is that it searches for a selector in SymbolTest that does not exist. Probably what happens is that you remove a trait method in the class definition, then the browser updates, but still refers to that removed trait method which is actually not present anymore. So the browser model is not in sync with the system model in this case. But the strange thing is that the browser always asks the class organizer for the methods, so maybe it's the organizer that does not reflect the change to the class (yet). So I don't know whether the browser is to blame or not. What I did now is to check first whether the class indeed defines a particular method before accessing it. This should avoid the problem, but maybe the real problem lies somewhere else. David > My hypothesis was that may be the compiled get a methodClass but this is > strange that it does not > understand this message I have the impression that we get a nil > somehwere ;-/ > Stef > > On Nov 21, 2008, at 4:16 PM, Adrian Lienhard wrote: > >> If you can reproduce the problem, can you go back to an earlier image >> version to see if it exists there too? >> Could you provide an explanation of how to reproduce the problem? >> >> Adrian >> >> On Nov 21, 2008, at 16:04 , Marcus Denker wrote: >> >>> >>> On 21.11.2008, at 15:30, StÃ©phane Ducasse wrote: >>> >>>> Hi all >>>> >>>> I loaded >>>> OB >>>> shout >>>> ecompletion >>>> >>>> and we were apply coding with damien. >>>> And the image froze (deeply) when we redefined a class. >>>> >>>> So the thread changes may be a problem. >>> >>> The only change done was to add one variable to Process (at the >>> end)... I don't think this is the problem. >>> What else could it be? >>> The only other large change was >>> >>> a) ifNotNil with argument, but that was already earlier >>> b) OldSocket removal. >>> >>> anything else? >>> >>> Marcus >>> >>> >>> -- >>> Marcus Denker -- denker(a)iam.unibe.ch >>> http://www.iam.unibe.ch/~denker >>> >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 24, 2008

Re: [Pharo-project] SUnit: history support and OB icons

by David RÃ¶thlisberger

> David there is a OB 257 for you in the inbox. Great, I committed this as version OB-Enhancements-dr.255 to the OB repo. David >>> I will let david integrate them. >> >> ok, I integrated OB-Enhancements-simon_denier.254.1.cs into >> OB-Enhancements-dr.254. Thanks, Simon! >> >> Concerning running of a single test method: I think it would be very >> useful if you could only update the results of this method without >> erasing the other results. I mean technically this should be possible >> to implement, it just a little bit complicate. Because the usability >> suffers a lot when all other test methods of a test case lose their >> results upon the run of new test method. >> >> Cheers, >> David >

Nov. 24, 2008

Re: [Pharo-project] ob list?

by Lukas Renggli

Yes, "OmniBrowser developers" <ob-dev(a)wiresong.ca>. http://mail.wiresong.ca/mailman/listinfo/ob-dev On Mon, Nov 24, 2008 at 12:40 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > Does anybody knows if there is a OB specific discussion list? > I'm having some issues with latest OBPackageBrowser implementation > (OBTreeColumn) and I want to discuss/understand the implementation... > > Thanks, > Esteban > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 24, 2008

[Pharo-project] ob list?

by Esteban Lorenzano

Hi, Does anybody knows if there is a OB specific discussion list? I'm having some issues with latest OBPackageBrowser implementation (OBTreeColumn) and I want to discuss/understand the implementation... Thanks, Esteban

Nov. 24, 2008

Re: [Pharo-project] New sensor code

by Gary Chambers

Perhaps two processes are *writing* to the change log at the same time then (shudders). Regards, Gary. ----- Original Message ----- From: "Marcus Denker" <denker(a)iam.unibe.ch> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Monday, November 24, 2008 11:13 AM Subject: Re: [Pharo-project] New sensor code On 24.11.2008, at 12:09, Gary Chambers wrote: > Unexplained SyntaxErrors are often, in my experience, a sign of multiple > processes concurrently trying to access the changes file... Have the > improvements we supplied for RemoteString been applied? > Yes. Marcus > Regards, Gary. > > ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> > To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, November 22, 2008 6:20 PM > Subject: Re: [Pharo-project] New sensor code > > >> and looks like >> InputEventFetcher>>eventLoop contains syntax errors, a window variable >> shown in red color by my browser. :) >> >> >> 2008/11/22 Igor Stasenko <siguctua(a)gmail.com>: >>> 2008/11/22 Igor Stasenko <siguctua(a)gmail.com>: >>>> I just loaded your changeset and have something to report :) >>>> >>>> It looks like it having bigger poll periods than old sensor, or works >>>> slower. >>>> An overall performance feels a bit more sluggish comparing to old >>>> implementation. >>>> Just open a window with long text and hold down the up/down key and >>>> see the difference. >>>> Or try to resize browser window - you can notice its not so smooth as >>>> in old image. >>>> >>> >>> ... which can be fixed easily by reducing poll period from 100ms to >>> 10ms in >>> InputEventPollingFetcher>>eventLoop >>> >>>> 2008/11/22 Michael Rueger <m.rueger(a)acm.org>: >>>>> StÃ©phane Ducasse wrote: >>>>>> >>>>>> so how do we proceed? >>>>>> We try to load it, play with it then? >>>>>> integrate it into pharo and you continue hacking and fixing? >>>>> >>>>> this version is really meant to be smoke tested, it needs some work >>>>> on the >>>>> comments and on the user interrupt handling. >>>>> >>>>> So please load it into your images, make sure you always have backups >>>>> and >>>>> see how it holds up. If it turns out to be reasonably stable we can >>>>> push it. >>>>> >>>>> >>>>>> 1- Here I have a question >>>>>> =================== >>>>>> in this comment EventSensor = InputEventSensor? >>>>> >>>>> the comment is only a copy from EventSensor, needs to be rewritten. >>>>> If somebody has a better suggestion for naming this class I'm open to >>>>> suggestions. >>>>> >>>>>> 2- I saw a method defined on Controller >>>>>> But there are no reference to this class in pharo. So we could >>>>>> remove >>>>>> Controller I imagine >>>>> >>>>> It is superclass of other classes, so I'm not sure. >>>>> >>>>>> 3- could you tell me >>>>>> what kind of code we would have to change? >>>>> >>>>> Not sure what you mean? For now no code in the image needs to be >>>>> changed. >>>>> >>>>> >>>>> Michael >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 24, 2008

Re: [Pharo-project] New sensor code

by Marcus Denker

On 24.11.2008, at 12:09, Gary Chambers wrote: > Unexplained SyntaxErrors are often, in my experience, a sign of > multiple processes concurrently trying to access the changes file... > Have the improvements we supplied for RemoteString been applied? > Yes. Marcus > Regards, Gary. > > ----- Original Message ----- From: "Igor Stasenko" > <siguctua(a)gmail.com> > To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, November 22, 2008 6:20 PM > Subject: Re: [Pharo-project] New sensor code > > >> and looks like >> InputEventFetcher>>eventLoop contains syntax errors, a window >> variable >> shown in red color by my browser. :) >> >> >> 2008/11/22 Igor Stasenko <siguctua(a)gmail.com>: >>> 2008/11/22 Igor Stasenko <siguctua(a)gmail.com>: >>>> I just loaded your changeset and have something to report :) >>>> >>>> It looks like it having bigger poll periods than old sensor, or >>>> works slower. >>>> An overall performance feels a bit more sluggish comparing to old >>>> implementation. >>>> Just open a window with long text and hold down the up/down key and >>>> see the difference. >>>> Or try to resize browser window - you can notice its not so >>>> smooth as >>>> in old image. >>>> >>> >>> ... which can be fixed easily by reducing poll period from 100ms >>> to 10ms in >>> InputEventPollingFetcher>>eventLoop >>> >>>> 2008/11/22 Michael Rueger <m.rueger(a)acm.org>: >>>>> StÃ©phane Ducasse wrote: >>>>>> >>>>>> so how do we proceed? >>>>>> We try to load it, play with it then? >>>>>> integrate it into pharo and you continue hacking and fixing? >>>>> >>>>> this version is really meant to be smoke tested, it needs some >>>>> work on the >>>>> comments and on the user interrupt handling. >>>>> >>>>> So please load it into your images, make sure you always have >>>>> backups and >>>>> see how it holds up. If it turns out to be reasonably stable we >>>>> can push it. >>>>> >>>>> >>>>>> 1- Here I have a question >>>>>> =================== >>>>>> in this comment EventSensor = InputEventSensor? >>>>> >>>>> the comment is only a copy from EventSensor, needs to be >>>>> rewritten. >>>>> If somebody has a better suggestion for naming this class I'm >>>>> open to >>>>> suggestions. >>>>> >>>>>> 2- I saw a method defined on Controller >>>>>> But there are no reference to this class in pharo. So we could >>>>>> remove >>>>>> Controller I imagine >>>>> >>>>> It is superclass of other classes, so I'm not sure. >>>>> >>>>>> 3- could you tell me >>>>>> what kind of code we would have to change? >>>>> >>>>> Not sure what you mean? For now no code in the image needs to be >>>>> changed. >>>>> >>>>> >>>>> Michael >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 24, 2008