[Pharo-project] Fwd: Recherche des ingénieurs en développement Smalltalk
reply to y...@gconsept.com Original Message Subject: Recherche des ingénieurs en développement Smalltalk Date: Thu, 26 Aug 2010 16:42:27 +0200 From: Yohan CHOQUER y...@gconsept.com To: herve.ver...@univ-savoie.fr herve.ver...@univ-savoie.fr Bonjour Monsieur Verjus, Je suis à la recherche d’ingénieurs en développement Smalltalk et à la lecture de différents forums et sites, je me suis aperçu que vous connaissiez bien ce langage. Peut-être avez-vous dans votre entourage ou relations scolaires/professionnelles des personnes pouvant être intéressées par cette demande. N’hésitez pas à revenir vers moi. Restant à votre disposition, Cordialement. * * *Yohan Choquer* Ingénieur Commercial *___* GroupeConsept Informatique - Bureau d'Etudes Assistance Technique - Conseil - Ingénierie - Formation ZAC Les Hauts de Couëron, Rue des forgerons, 44220 Couëron, France Plan d'accès http://maps.google.fr/maps?f=qhl=frgeocode=q=rue+des+forgerons+44220+cou%C3%ABronsll=47.15984,2.988281sspn=14.049346,26.411133ie=UTF8ll=47.238875,-1.668248spn=0.006847,0.012896z=16iwloc=addr Tél : +33 (0)2 51 83 03 00 Mob : +33 (0)6 03 18 60 82 Fax : +33 (0)2 51 83 03 01 www.gconsept.com http://www.gconsept.com/ *___* ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b3.
2010/8/27 John M McIntosh john...@smalltalkconsulting.com On 2010-08-26, at 11:52 AM, Mariano Martinez Peck wrote: A difference I found with Eliot VM and your previous ones is shortcuts. In eliot image, to select words, I do shift + ctrl + narrow, or shift + command + narrow. In yours, I only can do shift + command + narrow. And if I do shift + ctrl + narrow the mouse cursos doesn't even move. cheer What is the 'narrow' key? sorry I eant arrow, left, right http://bit.ly/coumEn thanks -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 'foo' asTime
johan thanks Now get the reflex to create an issue else we get flooded of information. I will integrate them now. Stef On Aug 26, 2010, at 2:34 PM, Johan Brichau wrote: On 26 Aug 2010, at 04:47, Guillermo Polito wrote: And now, because of fixing IntegerreadFrom:, 'foo' asTime throws an exception and we all are a bit happier :D. Indeed. thanks. And just to make sure that we keep being happy, I added some unit tests to verify that in the KernelTests package ;-) Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] About webclient.ppm.73
hi philippe I wanted to integrate it in 1.2 but I have 5 conflicts. Should I juste load? Is it for 1.2? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] about ValueAdapter
Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b3.
That's a bug, well actually apple changed something between 10.5 and 10.6 I've a fix pending. On 2010-08-27, at 12:42 AM, Mariano Martinez Peck wrote: 2010/8/27 John M McIntosh john...@smalltalkconsulting.com On 2010-08-26, at 11:52 AM, Mariano Martinez Peck wrote: A difference I found with Eliot VM and your previous ones is shortcuts. In eliot image, to select words, I do shift + ctrl + narrow, or shift + command + narrow. In yours, I only can do shift + command + narrow. And if I do shift + ctrl + narrow the mouse cursos doesn't even move. cheer What is the 'narrow' key? sorry I eant arrow, left, right http://bit.ly/coumEn thanks -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] hasInstanceVariableNamed: hasClassVariableNamed:
what about ClassDescriptionchooseInstVarThenDo: aBlock ClassDescriptionchooseInstVarAlphabeticallyThenDo: aBlock ClassDescriptionchooseClassVarName should I really comment I will fix them. On Aug 26, 2010, at 4:08 PM, Stéphane Ducasse wrote: I tend to agree but not quite :) Size is not the only criteria. Consistency is another really important one. And also tested code because there are plenty of methods that are not that difficult to rewrite all the time in client code but you want to use them because another guys spent time to write them and test them. And yes I started to read Class and Behavior and I want to clean that. As soon as Opal gets into pharo we will clean, clean, clean. Stef i remember writing a code like: class allInstVarNames includes: somevar, multiple times, but i can't tell that i miss the above methods too much. I'd vote to add them, only if we , in exchange, find the other two(or more) methods to remove. A class protocol is heavily bloated, and adding even more on top of that, even if its userful, could be lost in a jungle of many others. Stef ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [SPAM] About webclient.ppm.73
I could have a look, if you tell me where I can find it... On 27 Aug 2010, at 10:22, stephane ducasse wrote: hi philippe I wanted to integrate it in 1.2 but I have 5 conflicts. Should I juste load? Is it for 1.2? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] class API question
We are not consistent: do we want renameInstVar:to: or removeInstVarName: I prefer that. We have addInstVarName: - should be addInstVarNamed: from my taste Now we want to have first class instance variable in the near future so I would like to have addInstVar: aVariable addInstVarNamed: aString What do you think? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [SPAM] About webclient.ppm.73
this is in the inbox Stef On Aug 27, 2010, at 10:47 AM, Sven Van Caekenberghe wrote: I could have a look, if you tell me where I can find it... On 27 Aug 2010, at 10:22, stephane ducasse wrote: hi philippe I wanted to integrate it in 1.2 but I have 5 conflicts. Should I juste load? Is it for 1.2? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] hasInstanceVariableNamed: hasClassVariableNamed:
On Aug 27, 2010, at 10:31 AM, Stéphane Ducasse wrote: what about ClassDescriptionchooseInstVarThenDo: aBlock ClassDescriptionchooseInstVarAlphabeticallyThenDo: aBlock ClassDescriptionchooseClassVarName should I really comment I will fix them. This should not be in ClassDescription... the only client is SystemNavigation. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] hasInstanceVariableNamed: hasClassVariableNamed:
for example we have addClassVarName: classVarNamed: classVarNamed:put: removeClassVarName: I will rename addClassVarName: removeClassVarName: to be addClassVarNamed: removeClassVarNamed: consistency Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] class API question
On Aug 27, 2010, at 11:02 AM, Stéphane Ducasse wrote: We are not consistent: do we want renameInstVar:to: or removeInstVarName: I prefer that. We have addInstVarName: - should be addInstVarNamed: from my taste Now we want to have first class instance variable in the near future so I would like to have addInstVar: aVariable addInstVarNamed: aString What do you think? Yes! -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b3.
On 26 Aug 2010, at 21:44, Sven Van Caekenberghe wrote: I hope the linux VM is equally fast. Is the COG VM capable of running headless on Linux ? s...@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak -version 3.9-7 #2 Wed Aug 18 19:45:40 GMT 2010 gcc 4.1.2 Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.26] Linux cern 2.6.18-194.8.1.el5PAE #1 SMP Fri Jul 2 10:18:13 CEST 2010 i686 i686 i386 GNU/Linux plugin path: /home/sven/Smalltalk/coglinux/lib/squeak/3.9-7/ [default: /home/sven/Smalltalk/coglinux/lib/squeak/3.9-7/] s...@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak -vm-display-null -vm-sound-null seaside3.lr.cog.image This doesn't seem to work, no errors to be seen anywhere. Can I enable some debugging output ? This same image runs perfectly well with a display, as in s...@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak seaside3.lr.cog.image Thx, Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] hasInstanceVariableNamed: hasClassVariableNamed:
*Cough* deprecate *cough* ;) Cheers, Henry On Aug 27, 2010, at 10:51 44AM, Stéphane Ducasse wrote: for example we have addClassVarName: classVarNamed: classVarNamed:put: removeClassVarName: I will rename addClassVarName: removeClassVarName: to be addClassVarNamed: removeClassVarNamed: consistency Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] could we fix MorphicModel
gary? Do you have surgeon knife? Because I do not see why slider need to depend on that wonderfully designed code. use: cachedSelector orMakeModelSelectorFor: selectorBody in: selectorBlock | selector | model ifNil: [^ nil]. cachedSelector ifNil: [Make up selector from slotname if any selector := (slotName ifNil: [selectorBody] ifNotNil: [slotName , selectorBody]) asSymbol. (model class canUnderstand: selector) ifFalse: [(self confirm: 'Shall I compile a null response for' , Character cr asString , model class name , '' , selector) ifFalse: [self halt]. model class compile: (String streamContents: [:s | selector keywords doWithIndex: [:k :i | s nextPutAll: k , ' arg' , i printString]. s cr; nextPutAll: 'Automatically generated null response.'. s cr; nextPutAll: 'Add code below for appropriate behavior...'.]) classified: 'input events' notifying: nil]] ifNotNil: [selector := cachedSelector]. ^ selectorBlock value: selector ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] class API question
done :) I could not let that like that. Stef On Aug 27, 2010, at 11:11 AM, Marcus Denker wrote: On Aug 27, 2010, at 11:02 AM, Stéphane Ducasse wrote: We are not consistent: do we want renameInstVar:to: or removeInstVarName: I prefer that. We have addInstVarName: - should be addInstVarNamed: from my taste Now we want to have first class instance variable in the near future so I would like to have addInstVar: aVariable addInstVarNamed: aString What do you think? Yes! -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] hasInstanceVariableNamed: hasClassVariableNamed:
*Cough* deprecate *cough* ;) what you got a flu :) Of course this is done and I would like to have a refactoring called renameDeprecate :) Lukas? :) Stef Cheers, Henry On Aug 27, 2010, at 10:51 44AM, Stéphane Ducasse wrote: for example we have addClassVarName: classVarNamed: classVarNamed:put: removeClassVarName: I will rename addClassVarName: removeClassVarName: to be addClassVarNamed: removeClassVarNamed: consistency Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] class API question
I think it would be beneficial to adapt the protocol of the refactoring browser. It especially spells out all the names: #addInstanceVariable: #allInstanceVariableNames #instanceVariableNames Lukas On 27 August 2010 11:50, Stéphane Ducasse stephane.duca...@inria.fr wrote: done :) I could not let that like that. Stef On Aug 27, 2010, at 11:11 AM, Marcus Denker wrote: On Aug 27, 2010, at 11:02 AM, Stéphane Ducasse wrote: We are not consistent: do we want renameInstVar:to: or removeInstVarName: I prefer that. We have addInstVarName: - should be addInstVarNamed: from my taste Now we want to have first class instance variable in the near future so I would like to have addInstVar: aVariable addInstVarNamed: aString What do you think? Yes! -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] class API question
Yep, It would be much better to sell out the names. On Fri, Aug 27, 2010 at 11:53 AM, Lukas Renggli reng...@gmail.com wrote: I think it would be beneficial to adapt the protocol of the refactoring browser. It especially spells out all the names: #addInstanceVariable: #allInstanceVariableNames #instanceVariableNames Lukas On 27 August 2010 11:50, Stéphane Ducasse stephane.duca...@inria.fr wrote: done :) I could not let that like that. Stef On Aug 27, 2010, at 11:11 AM, Marcus Denker wrote: On Aug 27, 2010, at 11:02 AM, Stéphane Ducasse wrote: We are not consistent: do we want renameInstVar:to: or removeInstVarName: I prefer that. We have addInstVarName: - should be addInstVarNamed: from my taste Now we want to have first class instance variable in the near future so I would like to have addInstVar: aVariable addInstVarNamed: aString What do you think? Yes! -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Jorge Ressia www.jorgeressia.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12115
12115 - - Issue 2825: [[true] whileTrue] fork cannot be interrupted. Thanks Henrik Johanssen. - Issue 2860: make Dictionary at:ifAbsent use ifNil:ifNotNil. Thanks Marcus Denker - Issue 2570: Removed implicit conversion of DateAndTime equality-testing argument. Thanks Chris Mueller. We will have to address the isKindOf in DateAndTime= - Issue 2873: adding hasClassVarNamed: hasInstVarNamed: and cleaned the API. I feel better - Stephane Ducasse Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] class API question
I think it would be beneficial to adapt the protocol of the refactoring browser. It especially spells out all the names: #addInstanceVariable: #allInstanceVariableNames #instanceVariableNames Lukas I thought about it too but since we will add first class instances variables then I preferred to use named: for now and like that we can have both interfaces in the future for compatibility. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 'foo' asTime
err, yes it actually still is this one: http://code.google.com/p/pharo/issues/detail?id=2854 :-) On 27 Aug 2010, at 10:16, Stéphane Ducasse wrote: johan thanks Now get the reflex to create an issue else we get flooded of information. I will integrate them now. Stef On Aug 26, 2010, at 2:34 PM, Johan Brichau wrote: On 26 Aug 2010, at 04:47, Guillermo Polito wrote: And now, because of fixing IntegerreadFrom:, 'foo' asTime throws an exception and we all are a bit happier :D. Indeed. thanks. And just to make sure that we keep being happy, I added some unit tests to verify that in the KernelTests package ;-) Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 'foo' asTime
Ok normally this is integrated now. On Aug 27, 2010, at 12:11 PM, Johan Brichau wrote: err, yes it actually still is this one: http://code.google.com/p/pharo/issues/detail?id=2854 :-) On 27 Aug 2010, at 10:16, Stéphane Ducasse wrote: johan thanks Now get the reflex to create an issue else we get flooded of information. I will integrate them now. Stef On Aug 26, 2010, at 2:34 PM, Johan Brichau wrote: On 26 Aug 2010, at 04:47, Guillermo Polito wrote: And now, because of fixing IntegerreadFrom:, 'foo' asTime throws an exception and we all are a bit happier :D. Indeed. thanks. And just to make sure that we keep being happy, I added some unit tests to verify that in the KernelTests package ;-) Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Sprint at esug
On 26 août 2010, at 16:04, Alexandre Bergel wrote: Hi! I just created an entry in the google site: http://code.google.com/p/pharo/wiki/PharoSprints It is scheduled for Sunday 12, as part of the Camp Smalltalk. Good! I'll be there :-) Please, add yourself if you wish to join. It seems to require some access rights I don't have. Noury ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] what about putting RBengine in pharo1.2 core?
marcus like that we do not have to load it all the time. I could esaily update scriptloader to make sure that we do not save these packages. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] what about putting RBengine in pharo1.2 core?
I wouldn't pre-load it. There is really no point for many deployed applications to have it in there. Lukas On 27 August 2010 13:33, Stéphane Ducasse stephane.duca...@inria.fr wrote: marcus like that we do not have to load it all the time. I could esaily update scriptloader to make sure that we do not save these packages. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] what about putting RBengine in pharo1.2 core?
On Fri, Aug 27, 2010 at 1:41 PM, Lukas Renggli reng...@gmail.com wrote: I wouldn't pre-load it. There is really no point for many deployed applications to have it in there. You can unload it in #cleanUpForRelease or #cleanUpForProduction. But I wouldn't pre-load it neither i think (I am not sure) Lukas On 27 August 2010 13:33, Stéphane Ducasse stephane.duca...@inria.fr wrote: marcus like that we do not have to load it all the time. I could esaily update scriptloader to make sure that we do not save these packages. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about ValueAdapter
Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.duca...@free.fr] Sent: Friday, August 27, 2010 4:28 AM To: Pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] about ValueAdapter Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] what about putting RBengine in pharo1.2 core?
sure this is just that during the unstable phase we need better tools. We want to run SmallLint. The problem is that generate a new image every 20 min when I integrate and I do not want to spend my time load ob and rb. After we will unload it. And yes I should work on a configuration of pharo and rebuild the scriptloader infrastructure on it :( Stef On Aug 27, 2010, at 1:41 PM, Lukas Renggli wrote: I wouldn't pre-load it. There is really no point for many deployed applications to have it in there. Lukas On 27 August 2010 13:33, Stéphane Ducasse stephane.duca...@inria.fr wrote: marcus like that we do not have to load it all the time. I could esaily update scriptloader to make sure that we do not save these packages. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about ValueAdapter
there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. Stef On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.duca...@free.fr] Sent: Friday, August 27, 2010 4:28 AM To: Pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] about ValueAdapter Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12116
12116 - merging webclient pmm 73 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About webclient.ppm.73
On 08/27/2010 10:22 AM, stephane ducasse wrote: hi philippe I wanted to integrate it in 1.2 but I have 5 conflicts. Should I juste load? Is it for 1.2? No, it's not. Do you have WebClient already in 1.2 and are trying to merge against it? If so I can have a look at it. Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12116
On 27 Aug 2010, at 15:16, Stéphane Ducasse wrote: 12116 - merging webclient pmm 73 It seems that every time I upgrade 1.2a using SystemSoftware Update, the version of WebClient-Test reverts as well. As I told you, your (older) version gives more unit test errors ;-) Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] what about putting RBengine in pharo1.2 core?
On Fri, Aug 27, 2010 at 3:06 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: sure this is just that during the unstable phase we need better tools. We want to run SmallLint. The problem is that generate a new image every 20 min when I integrate and I do not want to spend my time load ob and rb. Hudson isn't your friend for this ? Laurent After we will unload it. And yes I should work on a configuration of pharo and rebuild the scriptloader infrastructure on it :( Stef On Aug 27, 2010, at 1:41 PM, Lukas Renggli wrote: I wouldn't pre-load it. There is really no point for many deployed applications to have it in there. Lukas On 27 August 2010 13:33, Stéphane Ducasse stephane.duca...@inria.fr wrote: marcus like that we do not have to load it all the time. I could esaily update scriptloader to make sure that we do not save these packages. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about ValueAdapter
Stef, Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - aGG! :) Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 9:07 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. Stef On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.duca...@free.fr] Sent: Friday, August 27, 2010 4:28 AM To: Pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] about ValueAdapter Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why is Stack extending from LinkedList?
On Thu, 26 Aug 2010, Bart Gauquie wrote: Hi list, is there a specific reason Stack is extending from LinkedList, instead of using a LinkedList internally? To me, it seems that the protocol that LinkedList, SequenceableCollection, ... provides is not the protocol you expect from a Stack? Any thoughts on this? Originally it used encapsulation, but for some reason it was changed to use inheritance, probably for a cleaner system. IMHO the changes should be reverted. Levente Kind regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why is Stack extending from LinkedList?
Good thinking, remove Stack then? On Thu, Aug 26, 2010 at 1:33 PM, Lukas Renggli reng...@gmail.com wrote: I wonder why there is the need for a stack class at all? OrderedCollection is the class designed to do Stacks and Queues efficiently and portably, see #addFirst:, #addLast:, #first, #last, #removeFirst, #removeLast. Lukas 2010/8/26 Bart Gauquie bart.gauq...@gmail.com: Hi list, is there a specific reason Stack is extending from LinkedList, instead of using a LinkedList internally? To me, it seems that the protocol that LinkedList, SequenceableCollection, ... provides is not the protocol you expect from a Stack? Any thoughts on this? Kind regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why is Stack extending from LinkedList?
In my machine: o := OrderedCollection new: 1000. 1 to: 1000 do: [ :each | o add: each ]. [ 10 timesRepeat: [ o addFirst: o removeLast ] ] timeToRun. == 12842 o := LinkedList new: 1000. 1 to: 1000 do: [ :each | o add: each ]. [ 10 timesRepeat: [ o addFirst: o removeLast ] ] timeToRun. == 5603 On Fri, Aug 27, 2010 at 1:35 PM, Levente Uzonyi le...@elte.hu wrote: On Thu, 26 Aug 2010, Lukas Renggli wrote: I wonder why there is the need for a stack class at all? OrderedCollection is the class designed to do Stacks and Queues efficiently and portably, see #addFirst:, #addLast:, #first, #last, #removeFirst, #removeLast. If so, then there are some problems: o := OrderedCollection new: 1000. 1 to: 1000 do: [ :each | o add: each ]. [ 10 timesRepeat: [ o addFirst: o removeLast ] ] timeToRun. === 11660 Levente Lukas 2010/8/26 Bart Gauquie bart.gauq...@gmail.com: Hi list, is there a specific reason Stack is extending from LinkedList, instead of using a LinkedList internally? To me, it seems that the protocol that LinkedList, SequenceableCollection, ... provides is not the protocol you expect from a Stack? Any thoughts on this? Kind regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why is Stack extending from LinkedList?
On Thu, 26 Aug 2010, Lukas Renggli wrote: I wonder why there is the need for a stack class at all? OrderedCollection is the class designed to do Stacks and Queues efficiently and portably, see #addFirst:, #addLast:, #first, #last, #removeFirst, #removeLast. If so, then there are some problems: o := OrderedCollection new: 1000. 1 to: 1000 do: [ :each | o add: each ]. [ 10 timesRepeat: [ o addFirst: o removeLast ] ] timeToRun. === 11660 Levente Lukas 2010/8/26 Bart Gauquie bart.gauq...@gmail.com: Hi list, is there a specific reason Stack is extending from LinkedList, instead of using a LinkedList internally? To me, it seems that the protocol that LinkedList, SequenceableCollection, ... provides is not the protocol you expect from a Stack? Any thoughts on this? Kind regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why is Stack extending from LinkedList?
2010/8/27 Levente Uzonyi le...@elte.hu: On Thu, 26 Aug 2010, Lukas Renggli wrote: I wonder why there is the need for a stack class at all? OrderedCollection is the class designed to do Stacks and Queues efficiently and portably, see #addFirst:, #addLast:, #first, #last, #removeFirst, #removeLast. If so, then there are some problems: o := OrderedCollection new: 1000. 1 to: 1000 do: [ :each | o add: each ]. [ 10 timesRepeat: [ o addFirst: o removeLast ] ] timeToRun. === 11660 Levente OrderedCollection could be implemented differently, like for example having a circular array and maintaining a firstIndex and size instead of lastIndex. The main drawback would be that fast copy/replace would have to be split in two parts. Nicolas Lukas 2010/8/26 Bart Gauquie bart.gauq...@gmail.com: Hi list, is there a specific reason Stack is extending from LinkedList, instead of using a LinkedList internally? To me, it seems that the protocol that LinkedList, SequenceableCollection, ... provides is not the protocol you expect from a Stack? Any thoughts on this? Kind regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why is Stack extending from LinkedList?
On Fri, 27 Aug 2010, Nicolas Cellier wrote: 2010/8/27 Levente Uzonyi le...@elte.hu: On Thu, 26 Aug 2010, Lukas Renggli wrote: I wonder why there is the need for a stack class at all? OrderedCollection is the class designed to do Stacks and Queues efficiently and portably, see #addFirst:, #addLast:, #first, #last, #removeFirst, #removeLast. If so, then there are some problems: o := OrderedCollection new: 1000. 1 to: 1000 do: [ :each | o add: each ]. [ 10 timesRepeat: [ o addFirst: o removeLast ] ] timeToRun. === 11660 Levente OrderedCollection could be implemented differently, like for example having a circular array and maintaining a firstIndex and size instead of lastIndex. This issue is already fixed in Squeak 4.1. I tried the OrderedCollection with a circular array just like you suggested, but it was a bit slower than Squeak's OrderedCollection. Also note that this is an edge case. Levente The main drawback would be that fast copy/replace would have to be split in two parts. Nicolas Lukas 2010/8/26 Bart Gauquie bart.gauq...@gmail.com: Hi list, is there a specific reason Stack is extending from LinkedList, instead of using a LinkedList internally? To me, it seems that the protocol that LinkedList, SequenceableCollection, ... provides is not the protocol you expect from a Stack? Any thoughts on this? Kind regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why is Stack extending from LinkedList?
On Fri, 27 Aug 2010, Guillermo Polito wrote: In my machine: o := OrderedCollection new: 1000. 1 to: 1000 do: [ :each | o add: each ]. [ 10 timesRepeat: [ o addFirst: o removeLast ] ] timeToRun. == 12842 o := LinkedList new: 1000. 1 to: 1000 do: [ :each | o add: each ]. [ 10 timesRepeat: [ o addFirst: o removeLast ] ] timeToRun. == 5603 LinkedList should be used this way if you want to use it as a Queue: o := LinkedList new: 1000. 1 to: 1000 do: [ :each | o add: each ]. [ 10 timesRepeat: [ o addLast: o removeFirst ] ] timeToRun. === 119 Levente On Fri, Aug 27, 2010 at 1:35 PM, Levente Uzonyi le...@elte.hu wrote: On Thu, 26 Aug 2010, Lukas Renggli wrote: I wonder why there is the need for a stack class at all? OrderedCollection is the class designed to do Stacks and Queues efficiently and portably, see #addFirst:, #addLast:, #first, #last, #removeFirst, #removeLast. If so, then there are some problems: o := OrderedCollection new: 1000. 1 to: 1000 do: [ :each | o add: each ]. [ 10 timesRepeat: [ o addFirst: o removeLast ] ] timeToRun. === 11660 Levente Lukas 2010/8/26 Bart Gauquie bart.gauq...@gmail.com: Hi list, is there a specific reason Stack is extending from LinkedList, instead of using a LinkedList internally? To me, it seems that the protocol that LinkedList, SequenceableCollection, ... provides is not the protocol you expect from a Stack? Any thoughts on this? Kind regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12118
12118 - Enhancing method reference with benjamin. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b3.
On Fri, Aug 27, 2010 at 1:59 AM, Sven Van Caekenberghe s...@beta9.bewrote: On 26 Aug 2010, at 21:44, Sven Van Caekenberghe wrote: I hope the linux VM is equally fast. Is the COG VM capable of running headless on Linux ? We routinely run it headless on linux using -vm-display-null. s...@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak -version 3.9-7 #2 Wed Aug 18 19:45:40 GMT 2010 gcc 4.1.2 Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.26] Linux cern 2.6.18-194.8.1.el5PAE #1 SMP Fri Jul 2 10:18:13 CEST 2010 i686 i686 i386 GNU/Linux plugin path: /home/sven/Smalltalk/coglinux/lib/squeak/3.9-7/ [default: /home/sven/Smalltalk/coglinux/lib/squeak/3.9-7/] s...@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak -vm-display-null -vm-sound-null seaside3.lr.cog.image This doesn't seem to work, no errors to be seen anywhere. Can I enable some debugging output ? Try -sendtrace, e.g. ./coglinux/bin/squeak -vm-display-null -vm-sound-null -sendtrace seaside3.lr.cog.image This same image runs perfectly well with a display, as in s...@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak seaside3.lr.cog.image What does your image do? Does it depend on any additional plugins or shared objects? Are these also present in your Cog installation? HTH Eliot Thx, Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Why has MethodFinder a fixed list of results?
Dear list, I was showing off Pharo to a colleague today and was surprised that. My quick introduction of adding new methods on existing system classes StringfirstLetter ^self copyFrom: 1 to: 1 - extension on String worked immediately. But that: in the MethodFinder evaluating: 'tried'.'t' did not return my method I just added :-( Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods. What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )? Kind Regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Running Pharo on a headless Ubuntu server
Hello, When I run squeakvm directly it works! Thanks for the tip. Jan. On Thu, Aug 26, 2010 at 11:37 PM, Sven Van Caekenberghe s...@beta9.bewrote: Jan, On 26 Aug 2010, at 22:42, Jan van de Sandt wrote: Hello, I am trying to run a Pharo Seaside image on an Ubunbtu 10.04 server. When I start the image like this squeak -mmap 256m -vm-sound-null -vm-display-null seaside3.0rc.image I get the following errors: found gettext in path /srv/seaside libasound.so.2: cannot open shared object file: No such file or directory squeak: could not find any display driver /usr/bin/squeak: line 277: 7499 Aborted $VM $1 $2 Does anybody know the minimal set of packages I need to install before I can run a headless image? Jan. The command line options are OK and should work. You could try running the squeak-vm directly (/usr/bin/squeak is a shell script). On Ubuntu it is in /usr/lib/squeak/4.0.3-2202/squeakvm (or some other version). I installed these on Ubuntu 10.04.1, but I am not sure they are needed (I just did to get rid of the warnings). sudo apt-get install libsm6 sudo apt-get install libaudio2 sudo apt-get install libpulse0 sudo apt-get install libglu1-mesa On a server they are not really needed. HTH, Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Jan van de Sandt gsm: +31 (0)6 3039 5998 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why has MethodFinder a fixed list of results?
On Aug 27, 2010, at 8:59 PM, Bart Gauquie wrote: Dear list, I was showing off Pharo to a colleague today and was surprised that. My quick introduction of adding new methods on existing system classes StringfirstLetter ^self copyFrom: 1 to: 1 - extension on String worked immediately. But that: in the MethodFinder evaluating: 'tried'.'t' did not return my method I just added :-( Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods. What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )? The rational is that the MethodFinder would, if it would not have a positive list, quite likely call methods that do bad things to the state of the system. Remember that is just calls all methods to check if some leads to the return value that you gave! e.g. Smalltalk.true. takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list. It would of course be nice to be able to not need a positive list. The question of how to control side-effects (and how to realize a secure yet reflective language in general) is of course a very interesting one... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About webclient.ppm.73
On Aug 27, 2010, at 3:45 PM, Philippe Marschall wrote: On 08/27/2010 10:22 AM, stephane ducasse wrote: hi philippe I wanted to integrate it in 1.2 but I have 5 conflicts. Should I juste load? Is it for 1.2? No, it's not. Do you have WebClient already in 1.2 and are trying to merge against it? If so I can have a look at it. yes we have it in 1.2 and sven merged your changes but it would be great if you can have a look Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12116
On Aug 27, 2010, at 3:46 PM, Sven Van Caekenberghe wrote: On 27 Aug 2010, at 15:16, Stéphane Ducasse wrote: 12116 - merging webclient pmm 73 It seems that every time I upgrade 1.2a using SystemSoftware Update, the version of WebClient-Test reverts as well. Strange where is the other tests packages? in the inbox? As I told you, your (older) version gives more unit test errors ;-) Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why has MethodFinder a fixed list of results?
2010/8/27 Bart Gauquie bart.gauq...@gmail.com: Dear list, I was showing off Pharo to a colleague today and was surprised that. My quick introduction of adding new methods on existing system classes StringfirstLetter ^self copyFrom: 1 to: 1 - extension on String worked immediately. But that: in the MethodFinder evaluating: 'tried'.'t' did not return my method I just added :-( Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods. What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )? Kind Regards, Bart Suppose you feed MethodFinder with Array and #() just to check whether #new is found. Will you be happy after MethodFinder has tried if ever Array removeFromSystem just wouldn't return #() ? Nicolas ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] what about putting RBengine in pharo1.2 core?
Hudson isn't your friend for this ? no when I batch fixes I cannot wait for something that start and can take 15 min. I prefer to update often to separate commit for tracebility so speed in making new image is important. It is already so slow. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about ValueAdapter
On Aug 27, 2010, at 4:46 PM, Schwab,Wilhelm K wrote: Stef, Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - aGG! :) Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? what will survive? You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. My suggestion is the following. Show us that this is cool with a nice example. Code is a good value for not native english speakers. Stef Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 9:07 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. Stef On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.duca...@free.fr] Sent: Friday, August 27, 2010 4:28 AM To: Pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] about ValueAdapter Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why is Stack extending from LinkedList?
On Aug 27, 2010, at 6:32 PM, Levente Uzonyi wrote: On Thu, 26 Aug 2010, Bart Gauquie wrote: Hi list, is there a specific reason Stack is extending from LinkedList, instead of using a LinkedList internally? To me, it seems that the protocol that LinkedList, SequenceableCollection, ... provides is not the protocol you expect from a Stack? Any thoughts on this? Originally it used encapsulation, when where? but for some reason it was changed to use inheritance, probably for a cleaner system. IMHO the changes should be reverted. I was not aware that Stack was a subclass of linkedList, it looks again subclassing versus subtyping. And subtyping is better. Stef Levente Kind regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why has MethodFinder a fixed list of results?
Now what we should do is probably to get a more dynamic way to tag methods because not methodFinder has a huge baglog of selectors and it is probably not in sync with the system We were thinking about using pragma to tag methods that should not be executed but we need a proof of concept. Stef On Aug 27, 2010, at 8:59 PM, Bart Gauquie wrote: Dear list, I was showing off Pharo to a colleague today and was surprised that. My quick introduction of adding new methods on existing system classes StringfirstLetter ^self copyFrom: 1 to: 1 - extension on String worked immediately. But that: in the MethodFinder evaluating: 'tried'.'t' did not return my method I just added :-( Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods. What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )? Kind Regards, Bart ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why has MethodFinder a fixed list of results?
Smalltalk.true. takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list. Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way. Just look at the lists and how many methods you find that have been removed years ago... It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12116
On 27 Aug 2010, at 21:19, Stéphane Ducasse wrote: Strange where is the other tests packages? in the inbox? No, I mean the latest version in Andreas' WebClient repo. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why has MethodFinder a fixed list of results?
2010/8/27 Marcus Denker marcus.den...@inria.fr On Aug 27, 2010, at 8:59 PM, Bart Gauquie wrote: Dear list, I was showing off Pharo to a colleague today and was surprised that. My quick introduction of adding new methods on existing system classes StringfirstLetter ^self copyFrom: 1 to: 1 - extension on String worked immediately. But that: in the MethodFinder evaluating: 'tried'.'t' did not return my method I just added :-( Turns out that MethodFinder has a class side Set of Approved and AddAndRemove methods. What is the rationale of this? Should we not allow any method, but exclude some tricky ones (doesNotUnderstand:, ... )? The rational is that the MethodFinder would, if it would not have a positive list, quite likely call methods that do bad things to the state of the system. Remember that is just calls all methods to check if some leads to the return value that you gave! e.g. Smalltalk.true. takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list. It would of course be nice to be able to not need a positive list. The question of how to control side-effects (and how to realize a secure yet reflective language in general) is of course a very interesting one... I'd love for someone to try and implement MethodFinder using simulation. If one used something based on ContextPart runSimulated: to execute the tests the simulation could maintain the set of objects that get instantiated as execution proceeds and only allow writes to these objects. Any attempt to write an object outside the set would cause an error and abandon exploring that alternative. This *might* be fast enough for use, but the experiment would show whether this was the case or not. best Eliot Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why has MethodFinder a fixed list of results?
2010/8/27 Marcus Denker marcus.den...@inria.fr Smalltalk.true. takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list. Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way. Just look at the lists and how many methods you find that have been removed years ago... It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example. So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation. best, Eliot Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b3.
It works now: I tried closing all open windows in the image and now it runs headless. I thought that wasn't necessary with other VMs but maybe I always did so without thinking about it. Thanks for answering, Eliot. Sven On 27 Aug 2010, at 20:46, Eliot Miranda wrote: On Fri, Aug 27, 2010 at 1:59 AM, Sven Van Caekenberghe s...@beta9.be wrote: On 26 Aug 2010, at 21:44, Sven Van Caekenberghe wrote: I hope the linux VM is equally fast. Is the COG VM capable of running headless on Linux ? We routinely run it headless on linux using -vm-display-null. s...@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak -version 3.9-7 #2 Wed Aug 18 19:45:40 GMT 2010 gcc 4.1.2 Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.26] Linux cern 2.6.18-194.8.1.el5PAE #1 SMP Fri Jul 2 10:18:13 CEST 2010 i686 i686 i386 GNU/Linux plugin path: /home/sven/Smalltalk/coglinux/lib/squeak/3.9-7/ [default: /home/sven/Smalltalk/coglinux/lib/squeak/3.9-7/] s...@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak -vm-display-null -vm-sound-null seaside3.lr.cog.image This doesn't seem to work, no errors to be seen anywhere. Can I enable some debugging output ? Try -sendtrace, e.g. ./coglinux/bin/squeak -vm-display-null -vm-sound-null -sendtrace seaside3.lr.cog.image This same image runs perfectly well with a display, as in s...@bladerunner:~/Smalltalk$ ./coglinux/bin/squeak seaside3.lr.cog.image What does your image do? Does it depend on any additional plugins or shared objects? Are these also present in your Cog installation? HTH Eliot Thx, Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] could we fix MorphicModel
Indeed, one of the more beautiful bits of Etoys... Regards, Gary Sent from my iPad On 27 Aug 2010, at 10:29, stephane ducasse stephane.duca...@free.fr wrote: gary? Do you have surgeon knife? Because I do not see why slider need to depend on that wonderfully designed code. use: cachedSelector orMakeModelSelectorFor: selectorBody in: selectorBlock | selector | model ifNil: [^ nil]. cachedSelector ifNil: [Make up selector from slotname if any selector := (slotName ifNil: [selectorBody] ifNotNil: [slotName , selectorBody]) asSymbol. (model class canUnderstand: selector) ifFalse: [(self confirm: 'Shall I compile a null response for' , Character cr asString , model class name , '' , selector) ifFalse: [self halt]. model class compile: (String streamContents: [:s | selector keywords doWithIndex: [:k :i | s nextPutAll: k , ' arg' , i printString]. s cr; nextPutAll: 'Automatically generated null response.'. s cr; nextPutAll: 'Add code below for appropriate behavior...'.]) classified: 'input events' notifying: nil]] ifNotNil: [selector := cachedSelector]. ^ selectorBlock value: selector ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why has MethodFinder a fixed list of results?
Eliot, I think the simulation path is good suggestion. Did a quick test for instance on: ContextPart classtrace: aBlock on: aStream and modified ^ thisContext sender runSimulated: aBlock contextAtEachStep: [:current | (current receiver == Smalltalk) added ifTrue: [self error: 'you cant do this ...']. added Sensor anyButtonPressed ifTrue: [^ nil]. and then evaluate: ContextPart trace: ['test' perform: #firstLetter]. = works fine, just prints the trace, ContextPart trace: [Smalltalk printString]. = throws the error. and with a nested piece of code that is also to be illegal : StringillegalFirstLetter Smalltalk printString. ^self copyFrom: 1 to: 1 ContextPart trace: ['test' perform: #illegalFirstLetter]. = also throws the error :-). Meaning if we keep a negative list of combinations of receiver / or messages, (instead of just the (current receiver == Smalltalk) added ifTrue: [self error: 'you cant do this ...']. added) it is possible to throw errors on nested code that is not be executed ... . Something to try out ... Kind Regards, Bart 2010/8/27 Eliot Miranda eliot.mira...@gmail.com 2010/8/27 Marcus Denker marcus.den...@inria.fr Smalltalk.true. takes a while, but it does not try to call #quitPrimitive. Which it would if Methodfinder would not be based on a positive list. Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way. Just look at the lists and how many methods you find that have been removed years ago... It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example. So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation. best, Eliot Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why has MethodFinder a fixed list of results?
Ok if I understand you mean you interpret everything on the copy of the inputs and you run until you either get an ok primitives or you stop on not ok one. Could be a nice way to stress runSimulated: :) Stef Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way. Just look at the lists and how many methods you find that have been removed years ago... It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example. So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation. best, Eliot Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12116
Ah ok! I just took the one in your repo because I was not sure about the other. I will do that tomorrow. Stef On Aug 27, 2010, at 9:36 PM, Sven Van Caekenberghe wrote: On 27 Aug 2010, at 21:19, Stéphane Ducasse wrote: Strange where is the other tests packages? in the inbox? No, I mean the latest version in Andreas' WebClient repo. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why is Stack extending from LinkedList?
On Fri, 27 Aug 2010, Stéphane Ducasse wrote: On Aug 27, 2010, at 6:32 PM, Levente Uzonyi wrote: On Thu, 26 Aug 2010, Bart Gauquie wrote: Hi list, is there a specific reason Stack is extending from LinkedList, instead of using a LinkedList internally? To me, it seems that the protocol that LinkedList, SequenceableCollection, ... provides is not the protocol you expect from a Stack? Any thoughts on this? Originally it used encapsulation, when where? In Pharo 1.0 (and Squeak of course). Levente but for some reason it was changed to use inheritance, probably for a cleaner system. IMHO the changes should be reverted. I was not aware that Stack was a subclass of linkedList, it looks again subclassing versus subtyping. And subtyping is better. Stef Levente Kind regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein However beautiful the strategy, you should occasionally look at the results. - Sir Winston Churchill It's not enough that we do our best; sometimes we have to do what's required. - Sir Winston Churchill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about ValueAdapter
Stef, Re survival, I might have been concerned about possible poor behavior of the methods you mention, or that you might soon remove then in cleaning. I really don't remember. I will indeed present the adapters as part of a larger whole. That will take time to evolve though. I think some of what we see in Squeak is the result of a failure to separate the related problems into pieces with clear responsibilities. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 3:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter On Aug 27, 2010, at 4:46 PM, Schwab,Wilhelm K wrote: Stef, Got it - I thought you might have meant something completely different. For example, I had a really cool #printOn: method that I had to suppress because the inspector was parsing the text and changing things as a result - aGG! :) Re other methods in the image. My goal was to be as data driven (off of the format) as possible and to get specific things working quickly. Mostly the latter; I just needed a few types of date and time conversions to work, and to work the same way they did when the code ran in Dolphin. Even if I had looked around, there are always questions: does it work at all, does it work well, will it survive the next sprint? what will survive? You are doing a wonderful job, so please don't take that as anything negative. Of course, more tests will allow you to clean freely and immediately note that something was critical to the adpaters. Another thing to note, we are under the ValueAdapter thread, but dates and times really fall under type converters. Of course, converters and adapters often work together. A model understands #bodyWeight; a text editor understands #value, and a converter can sit between them to turn the editor's (text) value into a float for the model. It is nice pluggable/serializable stuff that probably makes the most sense in the context of view resources, whether they are saved in binary or not. The 30k ft view is probably to encourage composition rather than to force inheritance. Closures help us. Doing our graphics in Smalltalk can help or hurt, because we can freely change the widgets as needed, which is both valuable freedom and a crutch that can compensate for inflexible design. My suggestion is the following. Show us that this is cool with a nice example. Code is a good value for not native english speakers. Stef Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, August 27, 2010 9:07 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about ValueAdapter there are a lot of methods to print time and date as well as number and I thought that your adaptor would benefit from them. Stef On Aug 27, 2010, at 1:49 PM, Schwab,Wilhelm K wrote: Stef, I generally spend most of my time trying to avoid having the RB do what you are describing, but it should be that simple, right? As you have noticed, the adapters are very crude, but tests are certainly a good idea. One thing that I miss is a good place to put package comments; I tend to write them more than class comments (they not only identify the important classes, but which ones to use and how, all in one place - who then need class comments?), and then relentlessly comment methods as they evolve. That said, I could probably force out a few class comments. What do you mean by checking padded printOn? What are they, and how (and for what) would I check them? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.duca...@free.fr] Sent: Friday, August 27, 2010 4:28 AM To: Pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] about ValueAdapter Bill I scanned the code. Could you - reformat your code? put space after : align on the first tab - get some more tests? - I could not see the class comments but if there are none then please adde something. - did you check the padded printon methods and others? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Why has MethodFinder a fixed list of results?
On Fri, Aug 27, 2010 at 1:30 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Ok if I understand you mean you interpret everything on the copy of the inputs and you run until you either get an ok primitives or you stop on not ok one. Right, /and/ you stop whenever an attempt is made to write to an object not created during the simulation. So one has to trap primitives new, new: shallowCopy and collect the results along with the copies of the initial arguments. These objects are safe to write to because they were created as one simulates. Anything else is an error. Could be a nice way to stress runSimulated: :) Interesting to see if this is useful because runSimulated: is probably at least 100 times slower than executing. An alternative would be to have an execution primitive that entered a special mode that did a GC, installed a page fault handler, advanced the allocation pointer to the next page boundary and then write-protected the entire heap. The error handler would unprotect the entire heap and cause a callback that would raise an exception. So one would run until a write into the heap other than to new space. But this alternative requires lots of VM work and is super tricky. Fingers crossed runSimulated: will work :) cheers Eliot Stef Ah, and a negative list was I think not used as it is too dangerous wrt. to completenes. If the positive list is incomplete, you miss a hit. If the negative list is incomplete, you woud crash in some nasty way. Just look at the lists and how many methods you find that have been removed years ago... It's not just methods like #quitPrimitive. In general, with the image based nature you could end up modifying state of objects in the image by accident, and realize it weeks later. e.g. this means one would very carefully protect the reflective model, to not accidentally modify the methodDictionary, for example. So if someone did try my simulation approach above the only lists needed would be a positive list of those primitives that were safe to apply to any object and a positive list of those primitives it would be safe to apply to the objects allocated during the simulation. best, Eliot Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
