- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update] #10241

by StÃ©phane Ducasse

I tried again and got another stop not at the same place in paragraphEditor The key problem right now is that this crappy compiler does not raise exception but open pops.... Stef On Feb 22, 2009, at 2:00 PM, StÃ©phane Ducasse wrote: > I added a trace in condenseChanges > > > PluggableTabBarMorph > PluggableTabButtonMorph > PluggableTextAttribute > PluggableTextEditorMorph > PluggableTextFieldMorph > PluggableTextMorph > (and is Undeclared) (See is Undeclared) (Unless is Undeclared) > (works is Undeclared) (Portions is Undeclared) (Copyright is > Undeclared) > > > > Stef > > On Feb 22, 2009, at 1:50 PM, StÃ©phane Ducasse wrote: > >> I tried >> - to recompile the method licenseString on Smalltalk >> - remove it completely from the system >> >> I still get the same problem >> >> Stef >> >> On Feb 22, 2009, at 12:21 PM, StÃ©phane Ducasse wrote: >> >>> Adrian in 10241 when i did Smalltalk condenseChanges >>> >>> I got a ClassDescription >>> >>> syntax error on the license >>> >>> >>> " >>> use and modification subject to a liberal open source license. See >>> the main Squeak website for details. Unless stated to the contrary, >>> works submitted for incorporation into or for distribution with >>> Squeak >>> shall be presumed subject to the same license. >>> >>> Portions of Squeak are: >>> >>> Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. >>> Copyright (c) 1997-2001 Walt Disney Company, and/or >>> Copyrighted works of many other contributors. >>> All rights reserved. >>> ' >>> >>> " >>> >>> I think that fixing the condensing is the next key items since now >>> we >>> cannot work with Moose anymore. The changeset is getting too close >>> to >>> the limit. >>> >>> Stef >>> >>> >>> On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: >>> >>>> #10241 >>>> >>>> Issue 167: >>>> - Traits implementation refactoring (no sharing of compiled methods >>>> and source) >>>> - New tests for Traits MOP >>>> >>>> >>>> Since this changes the handling of sources, the following issues >>>> with >>>> condensing changes may be resolved: >>>> http://code.google.com/p/pharo/issues/detail?id=466 >>>> http://code.google.com/p/pharo/issues/detail?id=470 >>>> >>>> Can somebody check these issues? >>>> >>>> Adrian >>>> ___________________ >>>> http://www.adrian-lienhard.ch/ >>>> >>>> >>>> _______________________________________________ >>>> 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 >

Feb. 22, 2009

Re: [Pharo-project] [update] #10241

by StÃ©phane Ducasse

I added a trace in condenseChanges PluggableTabBarMorph PluggableTabButtonMorph PluggableTextAttribute PluggableTextEditorMorph PluggableTextFieldMorph PluggableTextMorph (and is Undeclared) (See is Undeclared) (Unless is Undeclared) (works is Undeclared) (Portions is Undeclared) (Copyright is Undeclared) Stef On Feb 22, 2009, at 1:50 PM, StÃ©phane Ducasse wrote: > I tried > - to recompile the method licenseString on Smalltalk > - remove it completely from the system > > I still get the same problem > > Stef > > On Feb 22, 2009, at 12:21 PM, StÃ©phane Ducasse wrote: > >> Adrian in 10241 when i did Smalltalk condenseChanges >> >> I got a ClassDescription >> >> syntax error on the license >> >> >> " >> use and modification subject to a liberal open source license. See >> the main Squeak website for details. Unless stated to the contrary, >> works submitted for incorporation into or for distribution with >> Squeak >> shall be presumed subject to the same license. >> >> Portions of Squeak are: >> >> Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. >> Copyright (c) 1997-2001 Walt Disney Company, and/or >> Copyrighted works of many other contributors. >> All rights reserved. >> ' >> >> " >> >> I think that fixing the condensing is the next key items since now we >> cannot work with Moose anymore. The changeset is getting too close to >> the limit. >> >> Stef >> >> >> On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: >> >>> #10241 >>> >>> Issue 167: >>> - Traits implementation refactoring (no sharing of compiled methods >>> and source) >>> - New tests for Traits MOP >>> >>> >>> Since this changes the handling of sources, the following issues >>> with >>> condensing changes may be resolved: >>> http://code.google.com/p/pharo/issues/detail?id=466 >>> http://code.google.com/p/pharo/issues/detail?id=470 >>> >>> Can somebody check these issues? >>> >>> Adrian >>> ___________________ >>> http://www.adrian-lienhard.ch/ >>> >>> >>> _______________________________________________ >>> 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 >

Feb. 22, 2009

Re: [Pharo-project] [update] #10241

by StÃ©phane Ducasse

I tried - to recompile the method licenseString on Smalltalk - remove it completely from the system I still get the same problem Stef On Feb 22, 2009, at 12:21 PM, StÃ©phane Ducasse wrote: > Adrian in 10241 when i did Smalltalk condenseChanges > > I got a ClassDescription > > syntax error on the license > > > " > use and modification subject to a liberal open source license. See > the main Squeak website for details. Unless stated to the contrary, > works submitted for incorporation into or for distribution with Squeak > shall be presumed subject to the same license. > > Portions of Squeak are: > > Copyright Nothing more expected ->(c) 1996 Apple Computer, Inc. > Copyright (c) 1997-2001 Walt Disney Company, and/or > Copyrighted works of many other contributors. > All rights reserved. > ' > > " > > I think that fixing the condensing is the next key items since now we > cannot work with Moose anymore. The changeset is getting too close to > the limit. > > Stef > > > On Feb 21, 2009, at 3:10 PM, Adrian Lienhard wrote: > >> #10241 >> >> Issue 167: >> - Traits implementation refactoring (no sharing of compiled methods >> and source) >> - New tests for Traits MOP >> >> >> Since this changes the handling of sources, the following issues with >> condensing changes may be resolved: >> http://code.google.com/p/pharo/issues/detail?id=466 >> http://code.google.com/p/pharo/issues/detail?id=470 >> >> Can somebody check these issues? >> >> Adrian >> ___________________ >> http://www.adrian-lienhard.ch/ >> >> >> _______________________________________________ >> 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 >

Feb. 22, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by Bruce O'Neel

Hi, I downloaded Ian's image/changes bundle named unix-3.10-4.vmm.tar.gz from http://www.squeakvm.org/unix/ and looked into it a bit. In ObjectMemory biasToGrow it looks like the problem is biasToGrow | growSize | growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock) self growObjectMemory: growSize there are no '.'s after the lines. Shouldn't it look like: biasToGrow | growSize | growSize := growHeadroom*3/2 - (self sizeOfFree: freeBlock). self growObjectMemory: growSize. that? It looks like the slang interpreter/translater must be coughing a bit on what is basically slight invalid syntax, right? I guess that next up I have to figure out how to actually run vm maker :-) cheers bruce On Fri, Feb 20, 2009 at 12:32:52PM +0100, Bruce O'Neel wrote: > > Hi, > > Um, yes, I know you've discussed this before, but.... > > I'm not sure it's just a gcc 4.3.2 problem. > > I downloaded and poked at the tar file of 3.10-4's source. I got this from > http://squeakvm.org/unix/. > > The error message comes from uxGrowMemoryBy, but, I think it comes from > being called (two frames higher) in incrementalGC. > > The code is (from the gnu-interp.c file, though interp.c is the same): > > if (((((usqInt) ((longAt(foo->freeBlock)) & AllButTypeMask))) < (((usqInt) foo->growHeadroom))) && (foo->gcBiasToGrow > 0)) { > /* begin biasToGrow */ > /* begin growObjectMemory: */ > foo->statGrowMemory += 1; > limit = sqGrowMemoryBy(foo->memoryLimit, growSize); > if (!(limit == foo->memoryLimit)) { > foo->memoryLimit = limit - 24; > initializeMemoryFirstFree(foo->freeBlock); > } > weDidGrow = 1; > } > > So we call sqGrowMemoryBy with growSize which is used to calculate newDelta in uxGrowMemoryBy. > > A search of incrementalGC though shows that growSize, a sqInt is declared it's never set. > It turns out that with my system (Debian Lenny ppc, with gcc 4.3.2) growSize is zeroed. > Maybe that's the 'problem' with gcc 4.3.2? > > If I set it to some number, say, 100000, then a print statement just before > sqGrowMemoryBy comes out and squeak grows its memory, and, volia, no crash. > > Now, this might just be bypassing the real problem, but, it's unclear to me how > an uninitialized growSize would be a good idea. > > This also explains why my previous workaround, using the flag -memory on the command line, > caused the problem to not occur. > > cheers > > bruce > > On Thu, Feb 19, 2009 at 09:18:49AM -0800, John M McIntosh wrote: > > look in the archive and on the vm-dev list I think people agree this > > is a gcc 4.3 issue. > > > > On 19-Feb-09, at 4:15 AM, Bruce O'Neel wrote: > > > > > Hi, > > > > > > Is it possible this error? > > > > > > sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0` failed. > > > Aborted > > > > > > I get this following the procedure below on a Debian Lenny PPC > > > system with Squeak 3.10-4. > > > Gcc is 4.3.2. I do not get this on a Ubuntu hardy ppc system with > > > the same version of squeak. > > > Gcc is slightly older at 4.2.3. > > > > > > I've worked around this, for the moment, by adding -memory 200m to > > > the squeak > > > command line. > > > > > > I spent some weekend debugging this, but, I didn't find where the > > > problem it is comes > > > from. > > > > > > cheers > > > > > > bruce > > > > -- > > = > > = > > = > > ======================================================================== > > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > > 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

Feb. 22, 2009

Re: [Pharo-project] Question about Morphic

by Igor Stasenko

2009/2/22 Alexandre Bergel <alexandre(a)bergel.eu>: >> Canvas has the clipping capabilities. >> So, you can send a command to render a rectangle (-1000 @ -1000) >> corner: (10000 @10000) >> but depends on canvas clipping area, it will render only part of it. >> >> Also, for displaying morphs withing area with scrolling - use a >> TransformMorph to apply clipping & sroll in view. >> There are another morphs , ready for use , like ScrollPane > > I exactly use a ScrollBar. Here is a code excerpt: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > | window pane | > window := SystemWindow labelled: 'Mondrian Canvas'. > window model: self. > window extent: 640 @ 480. > pane := ScrollPane new. > > canvas := MOCanvas on: self root. > pane scroller addMorph: canvas. > window > addMorph: pane > frame: (0 @ 0 corner: 1 @ 1). > window openInWorld. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > MOCanvas is a subclass of Morph that is resized on some point. > > Apparently, this incantation does not activate this clipping. > Well, i'm not sure how to use ScrollPane properly.. look for examples of it in other morphs. > Alexandre > >> >> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> 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 >>> >> >> >> >> -- >> 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 >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 22, 2009

Re: [Pharo-project] Shadow in Watery2

by Gary Chambers

Yeah, the ordinary drop shadow was quite simple to implement. Hand-grabbed drop shadows are altogether much nastier! Not impossible but would require some evil hacking. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, February 21, 2009 1:58 PM Subject: Re: [Pharo-project] Shadow in Watery2 > 2009/2/21 Marcus Denker <denker(a)iam.unibe.ch>: >> Gary, >> >> Watery2 looks better and better :-) Great! >> >> One question regarding the shadow: Now the active window has >> a translucent shadow (like macos), very nice. >> >> But it's turned off and replaced with the hard non-translucend >> Morphic shadow while moving the window. >> Would it be possible to render the same shadow, even wen picking >> up windows? This would result in a much smoother apperance, and I >> think it even would feel faster. >> > Good luck with that.. For shadow when picking up responds the hand morph.. > There is quite sophisticated logic which caching the morph appearance > when its in hand.. along with shadow. > I tried to reproduce this effect on my GLCanvas, but found it > impossible to do without support of render buffers extension :) > >> Marcus >> >> -- >> Marcus Denker -- denker(a)acm.org >> http://www.marcusdenker.de >> >> >> _______________________________________________ >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 22, 2009

Re: [Pharo-project] Question about Morphic

by Igor Stasenko

2009/2/22 Alexandre Bergel <alexandre(a)bergel.eu>: > Thanks to all of you for your prompt answer. > >> You could test before drawing if the shape is visible at all, however >> in my experience you do not gain any speed because the graphic engine >> is much faster at performing such tests. At some points I also >> experimented with R- and Generalized Search Trees, but I figured out >> that in most cases it is not worth the troubles. For Mondrian >> visualization the whole dataset is normally displayed anyway. These >> kind of trees only bring speed improvement, if typically only a >> fraction of a huge amount of data is visible, like this is the case in >> a game world or a CAD application. > > This is also what I would expect. But Apparently, displaying a lot of > nodes outside the window slow the whole thing down. > > I get this profiling: http://bergel.eu/Picture1.png > For this window being displayed: http://bergel.eu/Picture2.png > > I think I will try to the display boxes that I am sure they are > contained in the visible part of the window. The polymorph extension > seem to ease this. > you can test whether you drawing primitive is visible on the screen: canvas isVisible: aRectangle > Thanks again, > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 22, 2009

Re: [Pharo-project] Automatic focus on column upon moose enter

by Gary Chambers

Just to make clear... Polymorph introduced a MouseWheelEvent class, instances of which are generated from the HandMorph if the key combination matches what the VM currently passes (ctrl+up/down). These new events are handled based on mouse pointer location and not keyboard focus so providing mouse scrolling without disturbing the keyboard focus. Of course, should the VM's change to generate "proper" wheel events, much of Morphic handling is now already in place. So, with mouseClickForKeyboardFocus enabled the Gnome behaviour should apply, barring morphs deliberately changing keyboard focus without regard for that setting ;-) (which is where this all started...) Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, February 21, 2009 1:20 PM Subject: Re: [Pharo-project] Automatic focus on column upon moose enter > Gary, > > Of course :) You guys are doing a great job! I just replied to Sig, > emphasizing the Gnome/Windows split on scrolling based on cursor position > while leaving the focus alone. Gnome has it right. However, I would give > priority to consistent focus before worrying about sending the wheel input > where it belongs. Sounds like we need to add wheel events to the VM; then > it should be easy to handle both (control-up/down for older vms, and wheel > events doing exactly what is desired by the user). > > Bill > > > ---- > Wilhelm K. Schwab, Ph.D. > bschwab AT anest DOT ufl DOT edu > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Gary Chambers > [gazzaguru2(a)btinternet.com] > Sent: Saturday, February 21, 2009 8:02 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Automatic focus on column upon moose enter > > Which is handled in Polymorph of course. > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 21, 2009 3:59 AM > Subject: Re: [Pharo-project] Automatic focus on column upon moose enter > > >> Concerning keyboard focus and mouse scroll. >> (sorry, if it was already noted in this discussion, i didn't read it >> fully). >> >> VM does not have a mouse wheel events. Instead, it generates ctrl-up / >> ctrl-down key combinations. >> I think that this hack is the root of all problems: >> - if focus doesn't following the mouse, you need additional hacks in >> image to treat ctrl-up / ctrl-down keys to generate scroll events for >> morph which is currently under the mouse, not the morph which is >> currently having an active keyboard input focus. >> >> >> >> -- >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 22, 2009

Re: [Pharo-project] Question about Morphic

by Alexandre Bergel

Thanks to all of you for your prompt answer. > You could test before drawing if the shape is visible at all, however > in my experience you do not gain any speed because the graphic engine > is much faster at performing such tests. At some points I also > experimented with R- and Generalized Search Trees, but I figured out > that in most cases it is not worth the troubles. For Mondrian > visualization the whole dataset is normally displayed anyway. These > kind of trees only bring speed improvement, if typically only a > fraction of a huge amount of data is visible, like this is the case in > a game world or a CAD application. This is also what I would expect. But Apparently, displaying a lot of nodes outside the window slow the whole thing down. I get this profiling: http://bergel.eu/Picture1.png For this window being displayed: http://bergel.eu/Picture2.png I think I will try to the display boxes that I am sure they are contained in the visible part of the window. The polymorph extension seem to ease this. Thanks again, Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 22, 2009

Re: [Pharo-project] Question about Morphic

by Alexandre Bergel

> Canvas has the clipping capabilities. > So, you can send a command to render a rectangle (-1000 @ -1000) > corner: (10000 @10000) > but depends on canvas clipping area, it will render only part of it. > > Also, for displaying morphs withing area with scrolling - use a > TransformMorph to apply clipping & sroll in view. > There are another morphs , ready for use , like ScrollPane I exactly use a ScrollBar. Here is a code excerpt: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | window pane | window := SystemWindow labelled: 'Mondrian Canvas'. window model: self. window extent: 640 @ 480. pane := ScrollPane new. canvas := MOCanvas on: self root. pane scroller addMorph: canvas. window addMorph: pane frame: (0 @ 0 corner: 1 @ 1). window openInWorld. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= MOCanvas is a subclass of Morph that is resized on some point. Apparently, this incantation does not activate this clipping. Alexandre > > >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 >> > > > > -- > 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 22, 2009