Re: [Pharo-project] fixing underscores in a trivial manner thanks to SmalllintChecker and Lukas!
http://book.pharo-project.org/book/TipsAndTricks/FixingUnderscores/
:)
On Apr 12, 2010, at 12:51 AM, Fernando olivero wrote:
> Hi all, i just wanted to re post the fix underscore code Lukas posted a while
> ago.
>
> I've just imported Connectors package into pharo, (i'm trying to get a
> minimal version working ), and stumbled upon the problem of the underscores..
> but now thanks to SmallInt rules it was easy and fast to overcome this
> problem!
>
> Thanks
>
> Fernando
>
>
> pd: From previous mail from lukas.
>
>
> 1. Load the code:
>
> Gofer new
> squeaksource: 'rb';
> package: 'AST-Core';
> package: 'Refactoring-Core';
> load.
>
> 2. Select the code (packages) you want to fix:
>
> environment := BrowserEnvironment new
> forPackageNames: #('Connectors-Base' 'Connectors-Lines and Curves').
>
> 3. Create the transformation rule:
>
> rule := RBUnderscoreAssignmentRule new.
>
> 4. Perform the search:
>
> SmalllintChecker runRule: rule onEnvironment: environment.
>
> 5. Perform the transformation:
>
> change := CompositeRefactoryChange new.
> change changes: rule changes.
> change execute
> ___
> 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] fixing underscores in a trivial manner thanks to SmalllintChecker and Lukas!
It would be good to hardcode the version numbers and to tell that a
Pharo 1.0 image has to be used:
Gofer new
squeaksource: 'rb';
version: 'AST-Core-lr.67';
version: 'Refactoring-Core-lr.122';
load.
Pharo 1.1 won't be able to load underscore assignments anymore.
Lukas
On 12 April 2010 09:09, Stéphane Ducasse wrote:
> http://book.pharo-project.org/book/TipsAndTricks/FixingUnderscores/
>
> :)
>
>
> On Apr 12, 2010, at 12:51 AM, Fernando olivero wrote:
>
>> Hi all, i just wanted to re post the fix underscore code Lukas posted a
>> while ago.
>>
>> I've just imported Connectors package into pharo, (i'm trying to get a
>> minimal version working ), and stumbled upon the problem of the underscores..
>> but now thanks to SmallInt rules it was easy and fast to overcome this
>> problem!
>>
>> Thanks
>>
>> Fernando
>>
>>
>> pd: From previous mail from lukas.
>>
>>
>> 1. Load the code:
>>
>> Gofer new
>> squeaksource: 'rb';
>> package: 'AST-Core';
>> package: 'Refactoring-Core';
>> load.
>>
>> 2. Select the code (packages) you want to fix:
>>
>> environment := BrowserEnvironment new
>> forPackageNames: #('Connectors-Base' 'Connectors-Lines and Curves').
>>
>> 3. Create the transformation rule:
>>
>> rule := RBUnderscoreAssignmentRule new.
>>
>> 4. Perform the search:
>>
>> SmalllintChecker runRule: rule onEnvironment: environment.
>>
>> 5. Perform the transformation:
>>
>> change := CompositeRefactoryChange new.
>> change changes: rule changes.
>> change execute
>> ___
>> 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] Canvas transform bug when rendering text?
Henrik, all, thanks for your help with this. I've been away from the codeface for a while and haven't yet tried all of the fixes. I did get things rendering well by caching the form canvas and redrawing that when required (just as the HandMorph does - as I said, the rendering while dragging is always OK). Relevant code below: drawOn: aCanvas super drawOn: aCanvas. cachedCanvas isNil ifTrue: [ cachedCanvas := (aCanvas allocateForm: self bounds extent) getCanvas. self drawContentsOn: cachedCanvas. ]. aCanvas translucentImage: cachedCanvas form at: self bounds origin. Best David -- David Harvey www.teamsandtechnology.com www.cateams.com @david_harvey On 7 April 2010 12:45, David Harvey wrote: > Hi list, > > I'm writing a little charting morph, and while playing with rotating text > for axis labels came across something which I've noted in Morphs text > handling a couple of times. > > If I apply a transform in a drawing operation, rotated text _appears_ to be > drawn twice, slightly offset, giving a scrappy bold look. It seems only to > do this when drawing on a form canvas that's backed onto the display: if you > pick and drag the morph, the text is rendered beautifully. > > The test morph attached isolates the problem. The transcript logging is an > attempt to see what might be happening: looking at the output it appears > that there are circumstances in which the during: block is invoked twice. > > Any thoughts? > > David > > -- > David Harvey > www.teamsandtechnology.com > www.cateams.com > @david_harvey > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] fixing underscores in a trivial manner thanks to SmalllintChecker and Lukas!
done. It is pier so everybody can edit it :) Stef On Apr 12, 2010, at 9:32 AM, Lukas Renggli wrote: > Gofer new > squeaksource: 'rb'; > version: 'AST-Core-lr.67'; > version: 'Refactoring-Core-lr.122'; > load. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Inserting halts using pragmas?
Hi, can we inserts halt's into methods without modifying source code, using pragmas maybe? Has there been work on this? Thanks, Fernando ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Inserting halts using pragmas?
> Hi, can we inserts halt's into methods without modifying source code, using > pragmas maybe? This has nothing to do with pragmas. Pragmas do not change execution behavior of a compiled method. Also pragmas are in the source code, so you cannot add them without changing the source. There was some work on annotations by Marcus, this goes more into the direction you are looking for. What I would do is to replace a compiled method with a custom object that implements #run:with:in: and that opens a debugger at the right place. Lukas -- 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] Inserting halts using pragmas?
On Mon, Apr 12, 2010 at 11:11 AM, Lukas Renggli wrote: > > Hi, can we inserts halt's into methods without modifying source code, > using pragmas maybe? > > This has nothing to do with pragmas. Pragmas do not change execution > behavior of a compiled method. Also pragmas are in the source code, so > you cannot add them without changing the source. > > There was some work on annotations by Marcus, this goes more into the > direction you are looking for. > > What I would do is to replace a compiled method with a custom object > that implements #run:with:in: and that opens a debugger at the right > place. > Yes, that's more or less how VisualAge does it. See DbgBreakpointedMethod, a variable Subclass of CompiledMethod. -- Cheers, Peter > Lukas > > -- > 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] news about 1.0
On Apr 11, 2010, at 11:26 03PM, Stéphane Ducasse wrote: > Hi guys > > mariano, marcus and adrian got some push to get 1.0 out. I was just on cc: > I think that we made a mistake not to roll that publicly via the mailing-list > (we will do that for 1.1). > Now this is holidays time here, mariano is going to get married and adrian > just moved so no > internet connection. > Tomorrow I will sync with marcus to know if I can help to get this 1.0 > version out. > If I remember the mails I saw, marcus was looking for the > BitBltPluging binaries for the one click image on other platforms than > mac os. > > Stef Hum, aren't they usually built as internal? In that case, the only reason for including plugin binaries would be if there's been bug fixes to it since the vm was shipped... Which would probably mean you're providing a too old VM in the first place. IIRC, On Windows, 3.11.8 / 4.0.2 would both include updated plugins, the main difference being 4.0.2 providing support for old image segment loading, but requiring in-image handling of quit events. Not sure about linux, since I don't use it. Seems to be in a state of updating at the moment, with 5-6 commits over the weekend, so might be worth waiting for. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [ANN] Pharo Windows VM 4.0.2
There is a new 4.0.2 Pharo VM for Windows available (see [1]) based on the same Squeak VM release. If you want to build it yourself just use [2]. There was no official announcement from Andreas on 4.0.2 on vm-dev list but according to the logs ([3]) sound recording should work again with this release. Note that the 4.0x VM's redirect the window close event to the image (see discussion in [4]) Therefore this 4.0.2 VM is mainly useful for people who base their work on Pharo 1.1. Core Alpha (as of today image nr #11312) since the Pharo 1.1 image already includes the support to handle the window close event directly from within the image. When you want to use Pharo core 1.0 (currently image #10517) with this VM you have to use SHIFT+ALT+F4 to close the image. Therefor it is better to use 3.11.8 VM (see 5) with the 1.0 images. Bye T. [1] https://gforge.inria.fr/frs/download.php/26814/PharoVM-Win32-4.0.2-bin.zip [2] https://gforge.inria.fr/frs/download.php/26815/PharoVM-Win32-4.0.2-src.zip [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148560.html [4] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-April/024677.html [5] https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Inserting halts using pragmas?
There was a break on enter code somewhere. Does anybody remember? I remember some code of igor to do that. Would be good to resurrect that. Stef On Apr 12, 2010, at 10:27 AM, Fernando olivero wrote: > Hi, can we inserts halt's into methods without modifying source code, using > pragmas maybe? > > Has there been work on this? > > Thanks, > Fernando > ___ > 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] Inserting halts using pragmas?
I see, thanks Lukas for the info. My wish for the new editor i'm developing is to able to insert halts, into the code just as any other IDE. By selecting the statement and indicating by some means to insert a halt ( called breakpoint in non-proccess reified languages). Would be nice to get that code, if not i'll implement my own debugging wrapper. Fernando On Apr 12, 2010, at 11:11 AM, Lukas Renggli wrote: >> Hi, can we inserts halt's into methods without modifying source code, using >> pragmas maybe? > > This has nothing to do with pragmas. Pragmas do not change execution > behavior of a compiled method. Also pragmas are in the source code, so > you cannot add them without changing the source. > > There was some work on annotations by Marcus, this goes more into the > direction you are looking for. > > What I would do is to replace a compiled method with a custom object > that implements #run:with:in: and that opens a debugger at the right > place. > > Lukas > > -- > 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 getting HashedCollection (another dream happening)
Oh.. again.. @Ralph: if you don't want sets with nils, just don't put them there. Why this isn't obvious for you? Take a Squeak , which already supporting nils in sets. Have you seen ANY reported breakage of existing code because of this? On 12 April 2010 05:25, Levente Uzonyi wrote: > On Sun, 11 Apr 2010, Ralph Boland wrote: > >>> Hi levente/igor >> >>> this hashedCollection is still on my radar. Now I was wondering if I >>> should > work first on Set with nil or HashedCollection. >>> Any idea/suggestion? >> >>> Stef >> >> I think moving Dictionary out from under Set is a great idea. >> However I am not convinced having a class HashedCollection >> to share common code between Set and Dictionary is worth it. >> I would just tolerate the code duplication because these classes >> are so important. Given that Squeak is going to support > > I don't see your point here. In Squeak that would mean duplicating 17 + 9 > methods (instance/class side) + the two instance variables for no reason. > >> HashedCollection though, I would hate to see yet another difference >> between Pharo and Squeak. I expect that the difference is unlikely >> to break code shared between Pharo and Squeak though. >> >> I was always against allowing the addition of nil to sets. >> This change means that every time I accidentally add nil to a set >> the error will go undetected and will be difficult to track down once >> the problem is discovered. > > Collections are still not ment to be bug detectors... Btw, do you notice if > you add nil as a key to a Dictionary? (or add nil to an OrderedCollection?) > >> My solution to escape this change in my code will be to subclass >> Set and any of its subclasses that I use and add code in the subclasses >> to test for addition of nil and report an error when it happens. >> This will allow bugs to show up sooner. > > You can (ab)use PluggableSet if you really need this by adding the nil check > to the hashBlock. > >> An alternative is just to modify Set itself by adding a test for >> adding nil to a set and then reporting an error. This change will break >> down of course once there are instances of actually adding nil to a set >> in Squeak/Pharo. >> Are there any such occurrences is Squeak 4.1? > > Who knows, nil can be everywhere: #(1 2 nil) asSet. > >> Now that this feature will be in Squeak 4.1, however, we again have >> the problem of divergence of code between Pharo and Squeak. The >> problem won't be there immediately but eventually this feature >> will actually be used in Squeak. >> Of course the issue here is how often it is useful to allow >> addition of nil to a Set. For the approximately 100,000 lines of >> code I have written in Smalltalk the answer is 0 explaining my >> opposition to this change. For some others though the answer >> must be different. >> For me this change will delay my moving my code from Squeak >> 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). >> Note that I use Sets and Dictionaries a lot. When my Squeak project >> runs 80% of the time is spent on Set/Dictionary operations. > > You could have added nil as a key to a Dictionary and that went > undetected... > > > Levente > >> >> Regards, >> >> Ralph Boland >> >> ___ >> 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 > -- 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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko wrote: > Oh.. again.. > @Ralph: if you don't want sets with nils, just don't put them there. > Why this isn't obvious for you? > Take a Squeak , which already supporting nils in sets. > Have you seen ANY reported breakage of existing code because of this? > > On 12 April 2010 05:25, Levente Uzonyi wrote: > > On Sun, 11 Apr 2010, Ralph Boland wrote: > > > >>> Hi levente/igor > >> > >>> this hashedCollection is still on my radar. Now I was wondering if I > >>> should > work first on Set with nil or HashedCollection. > >>> Any idea/suggestion? > >> > >>> Stef > >> > >> I think moving Dictionary out from under Set is a great idea. > >> However I am not convinced having a class HashedCollection > >> to share common code between Set and Dictionary is worth it. > >> I would just tolerate the code duplication because these classes > >> are so important. Given that Squeak is going to support > > > > I don't see your point here. In Squeak that would mean duplicating 17 + 9 > > methods (instance/class side) + the two instance variables for no reason. > > > >> HashedCollection though, I would hate to see yet another difference > >> between Pharo and Squeak. I expect that the difference is unlikely > >> to break code shared between Pharo and Squeak though. > >> > >> I was always against allowing the addition of nil to sets. > >> This change means that every time I accidentally add nil to a set > >> the error will go undetected and will be difficult to track down once > >> the problem is discovered. > > > > Collections are still not ment to be bug detectors... Btw, do you notice > if > > you add nil as a key to a Dictionary? (or add nil to an > OrderedCollection?) > > > >> My solution to escape this change in my code will be to subclass > >> Set and any of its subclasses that I use and add code in the subclasses > >> to test for addition of nil and report an error when it happens. > >> This will allow bugs to show up sooner. > > > > You can (ab)use PluggableSet if you really need this by adding the nil > check > > to the hashBlock. > > > >> An alternative is just to modify Set itself by adding a test for > >> adding nil to a set and then reporting an error. This change will break > >> down of course once there are instances of actually adding nil to a set > >> in Squeak/Pharo. > >> Are there any such occurrences is Squeak 4.1? > > > > Who knows, nil can be everywhere: #(1 2 nil) asSet. > > > >> Now that this feature will be in Squeak 4.1, however, we again have > >> the problem of divergence of code between Pharo and Squeak. The > >> problem won't be there immediately but eventually this feature > >> will actually be used in Squeak. > >> Of course the issue here is how often it is useful to allow > >> addition of nil to a Set. For the approximately 100,000 lines of > >> code I have written in Smalltalk the answer is 0 explaining my > >> opposition to this change. For some others though the answer > >> must be different. > >> For me this change will delay my moving my code from Squeak > >> 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). > >> Note that I use Sets and Dictionaries a lot. When my Squeak project > >> runs 80% of the time is spent on Set/Dictionary operations. > > > > You could have added nil as a key to a Dictionary and that went > > undetected... > > > > > > Levente > > > >> > >> Regards, > >> > >> Ralph Boland > >> > >> ___ > >> 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 > > > > > > -- > 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 > Heh, well I understand Ralph's point quite well, since I know that in the project I'm working on there are places in the code that depend on the fact that sets can't contain nil. So the following would break if VisualAge added that possibility: #( 1 2 3 4 nil 6 7 nil) asSet asArray => #(1 2 3 4 6 7) I'm not deciding one way or the other which way is right, just adding an observation. -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] fixing underscores in a trivial manner thanks to SmalllintChecker and Lukas!
On Apr 12, 2010, at 12:51 AM, Fernando olivero wrote: > Hi all, i just wanted to re post the fix underscore code Lukas posted a while > ago. > > I've just imported Connectors package into pharo, (i'm trying to get a > minimal version working ), excellent! I'm interesting in a mini version of that ;) > and stumbled upon the problem of the underscores.. > but now thanks to SmallInt rules it was easy and fast to overcome this > problem! > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Inserting halts using pragmas?
On Apr 12, 2010, at 1:30 PM, Stéphane Ducasse wrote: > There was a break on enter code somewhere. > Does anybody remember? > Yes, but this is *very* simplistic: it just recompiled the method with a self halt at the beginning. (silently, so it does not end up in the log/changeset/MC). I nearly removed it as it's not really used 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 getting HashedCollection (another dream happening)
2010/4/12 Peter Hugosson-Miller : > > > On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko wrote: >> >> Oh.. again.. >> @Ralph: if you don't want sets with nils, just don't put them there. >> Why this isn't obvious for you? >> Take a Squeak , which already supporting nils in sets. >> Have you seen ANY reported breakage of existing code because of this? >> >> On 12 April 2010 05:25, Levente Uzonyi wrote: >> > On Sun, 11 Apr 2010, Ralph Boland wrote: >> > >> >>> Hi levente/igor >> >> >> >>> this hashedCollection is still on my radar. Now I was wondering if I >> >>> should > work first on Set with nil or HashedCollection. >> >>> Any idea/suggestion? >> >> >> >>> Stef >> >> >> >> I think moving Dictionary out from under Set is a great idea. >> >> However I am not convinced having a class HashedCollection >> >> to share common code between Set and Dictionary is worth it. >> >> I would just tolerate the code duplication because these classes >> >> are so important. Given that Squeak is going to support >> > >> > I don't see your point here. In Squeak that would mean duplicating 17 + >> > 9 >> > methods (instance/class side) + the two instance variables for no >> > reason. >> > >> >> HashedCollection though, I would hate to see yet another difference >> >> between Pharo and Squeak. I expect that the difference is unlikely >> >> to break code shared between Pharo and Squeak though. >> >> >> >> I was always against allowing the addition of nil to sets. >> >> This change means that every time I accidentally add nil to a set >> >> the error will go undetected and will be difficult to track down once >> >> the problem is discovered. >> > >> > Collections are still not ment to be bug detectors... Btw, do you notice >> > if >> > you add nil as a key to a Dictionary? (or add nil to an >> > OrderedCollection?) >> > >> >> My solution to escape this change in my code will be to subclass >> >> Set and any of its subclasses that I use and add code in the subclasses >> >> to test for addition of nil and report an error when it happens. >> >> This will allow bugs to show up sooner. >> > >> > You can (ab)use PluggableSet if you really need this by adding the nil >> > check >> > to the hashBlock. >> > >> >> An alternative is just to modify Set itself by adding a test for >> >> adding nil to a set and then reporting an error. This change will >> >> break >> >> down of course once there are instances of actually adding nil to a set >> >> in Squeak/Pharo. >> >> Are there any such occurrences is Squeak 4.1? >> > >> > Who knows, nil can be everywhere: #(1 2 nil) asSet. >> > >> >> Now that this feature will be in Squeak 4.1, however, we again have >> >> the problem of divergence of code between Pharo and Squeak. The >> >> problem won't be there immediately but eventually this feature >> >> will actually be used in Squeak. >> >> Of course the issue here is how often it is useful to allow >> >> addition of nil to a Set. For the approximately 100,000 lines of >> >> code I have written in Smalltalk the answer is 0 explaining my >> >> opposition to this change. For some others though the answer >> >> must be different. >> >> For me this change will delay my moving my code from Squeak >> >> 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). >> >> Note that I use Sets and Dictionaries a lot. When my Squeak project >> >> runs 80% of the time is spent on Set/Dictionary operations. >> > >> > You could have added nil as a key to a Dictionary and that went >> > undetected... >> > >> > >> > Levente >> > >> >> >> >> Regards, >> >> >> >> Ralph Boland >> >> >> >> ___ >> >> 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 >> > >> >> >> >> -- >> 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 > > Heh, well I understand Ralph's point quite well, since I know that in the > project I'm working on there are places in the code that depend on the fact > that sets can't contain nil. So the following would break if VisualAge added > that possibility: > #( 1 2 3 4 nil 6 7 nil) asSet asArray #( 1 2 3 4 nil 6 7 nil) asSet in squeak before adding sets-with-nils you won't see such code , because this will throw an error. And so, nobody used it in that way before. I mean, there is no code in old squeak codebase which putting nils into sets intentionally. So, either you intentionally puting nils there - and its completely OK, or you intentionally do not putting them (as all old code does) - which is also , completely OK. > =
[Pharo-project] browse hierarchyImplementors raise an error
Hello, In a Pharo-1.0-10515-rc3 image, In the standard class browser, when you click on the green arrow at the left of a method, to browse hierarchyImplementor, an error occur. I opened an issue: http://code.google.com/p/pharo/issues/detail?id=2305 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Inserting halts using pragmas?
On 12 April 2010 14:30, Stéphane Ducasse wrote: > There was a break on enter code somewhere. > Does anybody remember? > > I remember some code of igor to do that. > Would be good to resurrect that. > well, i still having that code somewhere. the problem with using #run:with:in: that you can't put a breakpoint inside an arbitrary place in method. You can break on entering a method (or leaving it). But this is not the main problem. Main problem is UI. It should be made convenient enough for use, because if its not accessible from UI, its no matter how highly advanced/cool implementation is, since nobody will use it anyway :) > Stef > > On Apr 12, 2010, at 10:27 AM, Fernando olivero wrote: > >> Hi, can we inserts halt's into methods without modifying source code, using >> pragmas maybe? >> >> Has there been work on this? >> >> Thanks, >> Fernando >> ___ >> 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 > -- 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
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On Mon, Apr 12, 2010 at 2:06 PM, Igor Stasenko wrote: > 2010/4/12 Peter Hugosson-Miller : > > > > > > On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko > wrote: > >> > >> Oh.. again.. > >> @Ralph: if you don't want sets with nils, just don't put them there. > >> Why this isn't obvious for you? > >> Take a Squeak , which already supporting nils in sets. > >> Have you seen ANY reported breakage of existing code because of this? > >> > >> On 12 April 2010 05:25, Levente Uzonyi wrote: > >> > On Sun, 11 Apr 2010, Ralph Boland wrote: > >> > > >> >>> Hi levente/igor > >> >> > >> >>> this hashedCollection is still on my radar. Now I was wondering if I > >> >>> should > work first on Set with nil or HashedCollection. > >> >>> Any idea/suggestion? > >> >> > >> >>> Stef > >> >> > >> >> I think moving Dictionary out from under Set is a great idea. > >> >> However I am not convinced having a class HashedCollection > >> >> to share common code between Set and Dictionary is worth it. > >> >> I would just tolerate the code duplication because these classes > >> >> are so important. Given that Squeak is going to support > >> > > >> > I don't see your point here. In Squeak that would mean duplicating 17 > + > >> > 9 > >> > methods (instance/class side) + the two instance variables for no > >> > reason. > >> > > >> >> HashedCollection though, I would hate to see yet another difference > >> >> between Pharo and Squeak. I expect that the difference is unlikely > >> >> to break code shared between Pharo and Squeak though. > >> >> > >> >> I was always against allowing the addition of nil to sets. > >> >> This change means that every time I accidentally add nil to a set > >> >> the error will go undetected and will be difficult to track down once > >> >> the problem is discovered. > >> > > >> > Collections are still not ment to be bug detectors... Btw, do you > notice > >> > if > >> > you add nil as a key to a Dictionary? (or add nil to an > >> > OrderedCollection?) > >> > > >> >> My solution to escape this change in my code will be to subclass > >> >> Set and any of its subclasses that I use and add code in the > subclasses > >> >> to test for addition of nil and report an error when it happens. > >> >> This will allow bugs to show up sooner. > >> > > >> > You can (ab)use PluggableSet if you really need this by adding the nil > >> > check > >> > to the hashBlock. > >> > > >> >> An alternative is just to modify Set itself by adding a test for > >> >> adding nil to a set and then reporting an error. This change will > >> >> break > >> >> down of course once there are instances of actually adding nil to a > set > >> >> in Squeak/Pharo. > >> >> Are there any such occurrences is Squeak 4.1? > >> > > >> > Who knows, nil can be everywhere: #(1 2 nil) asSet. > >> > > >> >> Now that this feature will be in Squeak 4.1, however, we again have > >> >> the problem of divergence of code between Pharo and Squeak. The > >> >> problem won't be there immediately but eventually this feature > >> >> will actually be used in Squeak. > >> >> Of course the issue here is how often it is useful to allow > >> >> addition of nil to a Set. For the approximately 100,000 lines of > >> >> code I have written in Smalltalk the answer is 0 explaining my > >> >> opposition to this change. For some others though the answer > >> >> must be different. > >> >> For me this change will delay my moving my code from Squeak > >> >> 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). > >> >> Note that I use Sets and Dictionaries a lot. When my Squeak project > >> >> runs 80% of the time is spent on Set/Dictionary operations. > >> > > >> > You could have added nil as a key to a Dictionary and that went > >> > undetected... > >> > > >> > > >> > Levente > >> > > >> >> > >> >> Regards, > >> >> > >> >> Ralph Boland > >> >> > >> >> ___ > >> >> 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 > >> > > >> > >> > >> > >> -- > >> 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 > > > > Heh, well I understand Ralph's point quite well, since I know that in the > > project I'm working on there are places in the code that depend on the > fact > > that sets can't contain nil. So the following would break if VisualAge > added > > that possibility: > > #( 1 2 3 4 nil 6 7 nil) asSet asArray > > #( 1 2 3 4 nil 6 7 nil) asSet > in squeak before adding sets-with-nils you won't see such code , > because this will throw an erro
[Pharo-project] Inserting halts using pragmas?
On 12 April 2010 14:30, Stéphane Ducasse wrote: > There was a break on enter code somewhere. > Does anybody remember? Maybe you mean: http://map.squeak.org/package/07469ced-289a-4b6f-bd17-27ec567e681a/autoversion/1 -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Inserting halts using pragmas?
On Apr 12, 2010, at 2:12 PM, Igor Stasenko wrote: > On 12 April 2010 14:30, Stéphane Ducasse wrote: >> There was a break on enter code somewhere. >> Does anybody remember? >> >> I remember some code of igor to do that. >> Would be good to resurrect that. >> > well, i still having that code somewhere. > the problem with using #run:with:in: > that you can't put a breakpoint inside an arbitrary place in method. > You can break on entering a method (or leaving it). You could just store the AST in your fake method, put the halt as an annotation, then interpret the AST with a special interpreter that checks for the annotation. Phillippe did a evaluation-visitor for the RB AST, and the RB AST allows for properties to be set on any node. The code is in the Reflectivity package (part of the Persephone "JIT"), so we would have already large parts of the needed infrastructure. 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] Automatic generation of abstract methods
Hello, Would it be difficult to generate automatically superclass-abstract methods (with an empty contents) when creating a new subclass? For example, imagine I want to make my own subclass of Collection. As there is a lot of methods in this class and probably abstract methods, it would be cool to see them directly in my subclass without having to look to Collection method one by one (?). I'm probably not the first to ask this question, but in case it is, that's done:) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Inserting halts using pragmas?
On Apr 12, 2010, at 2:16 PM, Torsten Bergmann wrote: > On 12 April 2010 14:30, Stéphane Ducasse wrote: >> There was a break on enter code somewhere. >> Does anybody remember? > > Maybe you mean: > > http://map.squeak.org/package/07469ced-289a-4b6f-bd17-27ec567e681a/autoversion/1 Yes, I added this to Squeak 3.6 or 3.7 or 3.8 (don't remember). It never got too much use... partly because the UI parts are not that nicely done, partly because it can only break at the beginning of a method. 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] Automatic generation of abstract methods
On 12 avr. 2010, at 14:26, Cyrille Delaunay wrote: > Hello, > > Would it be difficult to generate automatically superclass-abstract methods > (with an empty contents) when creating a new subclass? > For example, imagine I want to make my own subclass of Collection. As there > is a lot of methods in this class and probably abstract methods, it would be > cool to see them directly in my subclass without having to look to Collection > method one by one (?). > I'm probably not the first to ask this question, but in case it is, that's > done:) Normally there is already a refactoring for that. Context menu>refactor class>realize -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Connectors minimal version into pharo
Great! Once i have something working i'll post the package in squeaksource. I will try to remove the fsm dependency and try to avoid having so many extensions, and have a minimal functionality. Connectors is a full blown system, i just need to draw simple constrained connection between morphs without the graph support. Fernando On Apr 12, 2010, at 2:00 PM, Stéphane Ducasse wrote: > > On Apr 12, 2010, at 12:51 AM, Fernando olivero wrote: > >> Hi all, i just wanted to re post the fix underscore code Lukas posted a >> while ago. >> >> I've just imported Connectors package into pharo, (i'm trying to get a >> minimal version working ), > > excellent! > I'm interesting in a mini version of that ;) > >> and stumbled upon the problem of the underscores.. >> but now thanks to SmallInt rules it was easy and fast to overcome this >> problem! >> > > > ___ > 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] BrowserEnvironment>>forPackages: aCollection
Lukas, i've noticed that PackageEnvironment instance variable packages is an ordered collection. Could we make it a Set, so when iterating we reduce iterating the same packages twice, Of course just in case a duplicated package was passed as an argument ( which was my case) Which leads to iterate possibly multiple times through the classes of packages, which significantly increases time to run when using the whole system. Fernando ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] browse hierarchyImplementors raise an error
This problem has been fixed a while ago. Lukas 2010/4/12 Cyrille Delaunay : > Hello, > > In a Pharo-1.0-10515-rc3 image, > > In the standard class browser, when you click on the green arrow at the > left of a method, to > browse hierarchyImplementor, an error occur. > > I opened an issue: http://code.google.com/p/pharo/issues/detail?id=2305 > > ___ > 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] BrowserEnvironment>>forPackages: aCollection
Sure, that seems to be a good idea: Name: Refactoring-Core-lr.123 Author: lr Time: 12 April 2010, 3:28:11 pm UUID: e30a9d78-bd6e-4da0-9d85-ba99270925a4 Ancestors: Refactoring-Core-lr.122 - made packages a set On 12 April 2010 15:15, Fernando olivero wrote: > Lukas, i've noticed that PackageEnvironment instance variable packages is an > ordered collection. > > Could we make it a Set, so when iterating we reduce iterating the same > packages twice, > > Of course just in case a duplicated package was passed as an argument ( which > was my case) > Which leads to iterate possibly multiple times through the classes of > packages, which significantly increases time to run when using the whole > system. > > Fernando > ___ > 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] #recreateSpecialObjectsArray woes
Hello, i attempted to load Alien-Core package into trunk image, and it failed. One of the problem is override of recreateSpecialObjectsArray method.. I wonder, maybe we should design a nicer API for extending/reserving slots in special objects array, so it won't require overriding this method by every package which needs to extend special objects, like FFI or Alien. Another aspect of replacing this method is , that it makes problematic to unload such package, in case one wants to unload it. So, my proposal is to add a simple API to SmalltalkImage class, and in order to install additional special objects one should do like: MyClass class>>initialize Smalltalk registerSpecialObject: myObject at: 55. Smalltalk registerSpecialObject: myObject at: 56. ... or: Smalltalk registerSpecialObjects: #( x y z) startingAt: 56. upon package unload, a reverse scheme should be supported: MyClass class>>unload Smalltalk unregisterSpecialObjectAt: 55. Smalltalk unregisterSpecialObjectAt: 56. ... or: Smalltalk unregisterSpecialObjects: 3 startingAt: 56. what you think? -- 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] pharo on sparc solaris
Hi, I would need to run a Pharo RC4 image on a Sparc Solaris station. Looking on the www.squeakvm.org/unix/, I see that there is no VM for such a station, only for Intel Solaris. Unfortunately, I also do not have access to any compiling tools on this machine (it's a server). Can anyone help me with this issue? The machine says it is: $ uname -a SunOS ejpdxa9017 5.10 Generic_142900-03 sun4v sparc SUNW,SPARC-Enterprise-T5220 Cheers, Doru -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen." ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] #recreateSpecialObjectsArray woes
On Apr 12, 2010, at 4:17 11PM, Igor Stasenko wrote: > Hello, > > i attempted to load Alien-Core package into trunk image, and it failed. > > One of the problem is override of recreateSpecialObjectsArray method.. > > I wonder, maybe we should design a nicer API for extending/reserving > slots in special objects array, > so it won't require overriding this method by every package which > needs to extend special objects, like FFI or Alien. > > Another aspect of replacing this method is , that it makes problematic > to unload such package, in case one wants to unload it. > > So, my proposal is to add a simple API to SmalltalkImage class, and in > order to install additional special objects one should do like: > > MyClass class>>initialize > > Smalltalk registerSpecialObject: myObject at: 55. > Smalltalk registerSpecialObject: myObject at: 56. > ... > > or: > > Smalltalk registerSpecialObjects: #( x y z) startingAt: 56. > > upon package unload, a reverse scheme should be supported: > > > MyClass class>>unload > > Smalltalk unregisterSpecialObjectAt: 55. > Smalltalk unregisterSpecialObjectAt: 56. > ... > > or: > > Smalltalk unregisterSpecialObjects: 3 startingAt: 56. > > > what you think? > > -- > Best regards, > Igor Stasenko AKA sig. > +1 for the overall idea. Implementation-wise, I'd also vote for raising errors in registerSpecialObject:at: if something other than myObject is already registered, changing to unregisterSpecialObject: at: in order to not unintentionally unregistering something else, and disallow unregisterSpecialObjects:startingAt: ;) Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] #recreateSpecialObjectsArray woes
Good idea! I had a similar idea when initially worked on Alien loader. I think that what is needed also is remove the dependency with the array, i mean explicitly calling the indexes make the image crash if you didn't had the assumed special object array size. For example: Smalltalk registerSpecialObject: myObject with: aName And later you reference that special object by aName instead of an index to the array. So it would be easier to load/unload the packages that extend the special objects array, because there would be no explicit dependency to indexes. Fernando On Apr 12, 2010, at 4:17 PM, Igor Stasenko wrote: > Hello, > > i attempted to load Alien-Core package into trunk image, and it failed. > > One of the problem is override of recreateSpecialObjectsArray method.. > > I wonder, maybe we should design a nicer API for extending/reserving > slots in special objects array, > so it won't require overriding this method by every package which > needs to extend special objects, like FFI or Alien. > > Another aspect of replacing this method is , that it makes problematic > to unload such package, in case one wants to unload it. > > So, my proposal is to add a simple API to SmalltalkImage class, and in > order to install additional special objects one should do like: > > MyClass class>>initialize > > Smalltalk registerSpecialObject: myObject at: 55. > Smalltalk registerSpecialObject: myObject at: 56. > ... > > or: > > Smalltalk registerSpecialObjects: #( x y z) startingAt: 56. > > upon package unload, a reverse scheme should be supported: > > > MyClass class>>unload > > Smalltalk unregisterSpecialObjectAt: 55. > Smalltalk unregisterSpecialObjectAt: 56. > ... > > or: > > Smalltalk unregisterSpecialObjects: 3 startingAt: 56. > > > what you think? > > -- > 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
Re: [Pharo-project] #recreateSpecialObjectsArray woes
On 12 April 2010 17:43, Fernando olivero wrote: > Good idea! I had a similar idea when initially worked on Alien loader. > > I think that what is needed also is remove the dependency with the array, i > mean explicitly calling the indexes make the image crash if you didn't had > the assumed special object array size. > > > For example: > Smalltalk registerSpecialObject: myObject with: aName > > And later you reference that special object by aName instead of an > index to the array. > > > So it would be easier to load/unload the packages that extend the special > objects array, because there would be no explicit dependency to indexes. > Yeah, that would be nice. But this will require VM changes.. and therefore is doomed :) Also, this could impact the VM speed significantly, because its using special object quite frequently. Imagine replacing a simple index-based lookup with name(string) based. > > Fernando > > On Apr 12, 2010, at 4:17 PM, Igor Stasenko wrote: > >> Hello, >> >> i attempted to load Alien-Core package into trunk image, and it failed. >> >> One of the problem is override of recreateSpecialObjectsArray method.. >> >> I wonder, maybe we should design a nicer API for extending/reserving >> slots in special objects array, >> so it won't require overriding this method by every package which >> needs to extend special objects, like FFI or Alien. >> >> Another aspect of replacing this method is , that it makes problematic >> to unload such package, in case one wants to unload it. >> >> So, my proposal is to add a simple API to SmalltalkImage class, and in >> order to install additional special objects one should do like: >> >> MyClass class>>initialize >> >> Smalltalk registerSpecialObject: myObject at: 55. >> Smalltalk registerSpecialObject: myObject at: 56. >> ... >> >> or: >> >> Smalltalk registerSpecialObjects: #( x y z) startingAt: 56. >> >> upon package unload, a reverse scheme should be supported: >> >> >> MyClass class>>unload >> >> Smalltalk unregisterSpecialObjectAt: 55. >> Smalltalk unregisterSpecialObjectAt: 56. >> ... >> >> or: >> >> Smalltalk unregisterSpecialObjects: 3 startingAt: 56. >> >> >> what you think? >> >> -- >> 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 > -- 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
Re: [Pharo-project] #recreateSpecialObjectsArray woes
On Apr 12, 2010, at 5:16 PM, Igor Stasenko wrote: > On 12 April 2010 17:43, Fernando olivero wrote: >> Good idea! I had a similar idea when initially worked on Alien loader. >> >> I think that what is needed also is remove the dependency with the array, i >> mean explicitly calling the indexes make the image crash if you didn't had >> the assumed special object array size. >> >> >> For example: >>Smalltalk registerSpecialObject: myObject with: aName >> >>And later you reference that special object by aName instead of an >> index to the array. >> >> >> So it would be easier to load/unload the packages that extend the special >> objects array, because there would be no explicit dependency to indexes. >> > Yeah, that would be nice. > But this will require VM changes.. and therefore is doomed :) > Also, this could impact the VM speed significantly, because its using > special object quite frequently. > Imagine replacing a simple index-based lookup with name(string) based. > Hi Igor, i wasn't speaking of an on-image API change. For example if you introduced the API you mentioned we could replace Utilities>> initializeClosures "Eliminate the prototype BlockContext from the specialObjectsArray. The VM doesn't use it. This paves the way for removing BlockCOntext altogether and merging ContextPart and MethodContext into e.g. Context." (Smalltalk specialObjectsArray at: 38) class == BlockContext ifTrue:[Smalltalk specialObjectsArray at: 38 put: nil]. With Utilities>> initializeClosures .. (Smalltalk hasSpecialObjectNamed: #BlockContext) ifTrue:[ Smalltalk unregisterSpecialObjectNamed: #BlockContext ]. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] #recreateSpecialObjectsArray woes
+ 1 for that. Stef On Apr 12, 2010, at 4:42 PM, Henrik Johansen wrote: > On Apr 12, 2010, at 4:17 11PM, Igor Stasenko wrote: > >> Hello, >> >> i attempted to load Alien-Core package into trunk image, and it failed. >> >> One of the problem is override of recreateSpecialObjectsArray method.. >> >> I wonder, maybe we should design a nicer API for extending/reserving >> slots in special objects array, >> so it won't require overriding this method by every package which >> needs to extend special objects, like FFI or Alien. >> >> Another aspect of replacing this method is , that it makes problematic >> to unload such package, in case one wants to unload it. >> >> So, my proposal is to add a simple API to SmalltalkImage class, and in >> order to install additional special objects one should do like: >> >> MyClass class>>initialize >> >> Smalltalk registerSpecialObject: myObject at: 55. >> Smalltalk registerSpecialObject: myObject at: 56. >> ... >> >> or: >> >> Smalltalk registerSpecialObjects: #( x y z) startingAt: 56. >> >> upon package unload, a reverse scheme should be supported: >> >> >> MyClass class>>unload >> >> Smalltalk unregisterSpecialObjectAt: 55. >> Smalltalk unregisterSpecialObjectAt: 56. >> ... >> >> or: >> >> Smalltalk unregisterSpecialObjects: 3 startingAt: 56. >> >> >> what you think? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > +1 for the overall idea. > Implementation-wise, I'd also vote for raising errors in > registerSpecialObject:at: if something other than myObject is already > registered, changing to unregisterSpecialObject: at: in order to not > unintentionally unregistering something else, and disallow > unregisterSpecialObjects:startingAt: ;) > > Cheers, > Henry > > > ___ > 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] [ANN] Pharo Windows VM 4.0.2
On Mon, 12 Apr 2010, Torsten Bergmann wrote: There is a new 4.0.2 Pharo VM for Windows available (see [1]) based on the same Squeak VM release. If you want to build it yourself just use [2]. There was no official announcement from Andreas on 4.0.2 on vm-dev list but according to the logs ([3]) sound recording should work again with this release. Note that the 4.0x VM's redirect the window close event to the image (see discussion in [4]) Therefore this 4.0.2 VM is mainly useful for people who base their work on Pharo 1.1. Core Alpha (as of today image nr #11312) since the Pharo 1.1 image already includes the support to handle the window close event directly from within the image. When you want to use Pharo core 1.0 (currently image #10517) with this VM you have to use SHIFT+ALT+F4 to close the image. Or just hold shift while you're clicking the X. Levente Therefor it is better to use 3.11.8 VM (see 5) with the 1.0 images. Bye T. [1] https://gforge.inria.fr/frs/download.php/26814/PharoVM-Win32-4.0.2-bin.zip [2] https://gforge.inria.fr/frs/download.php/26815/PharoVM-Win32-4.0.2-src.zip [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148560.html [4] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-April/024677.html [5] https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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 getting HashedCollection (another dream happening)
igor peter snippets was just a dull example. Peter mentioned that some people fix consequences instead of causes 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] Open Pharo debugger from a Seaside wallback
Lukas, It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. But I test it on the same machine with Squeak 4.1 RC4 and it go very very fast to open de smalltalk debugger. Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note that too or it's only my sensations? Thanks for your attention. Facundo On Sun, Apr 11, 2010 at 6:35 PM, Lukas Renggli wrote: > I don't have windows, so I cannot help. It would be cool if some > Windows/Firefox user could figure out a permanent solution for our > side, as this problem keeps on reappearing. > > Luas > > 2010/4/11 Facundo Vozzi : > > Yes, it's seems to be that issue but its solution didn't repair my > problem. > > I > > think that the problem is relationated with a network configuration issue > so > > i will > > continue trying in that way. > > Thank you Lukas. > > Facundo > > On Sun, Apr 11, 2010 at 5:24 PM, Lukas Renggli > wrote: > >> > >> This seems to be a known problem: > >> > >> > >> > http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.seaside/20959 > >> > >> Lukas > >> > >> 2010/4/11 Facundo Vozzi : > >> > Hi people, > >> > I'm using Pharo RC2 with Seaside 2.8.4 version and it's very slow when > >> > I trying to debugging a seaside application. In other words, I press > the > >> > debug link on the seaside application walback and it take to Pharo > over > >> > 40 > >> > seconds to open de imagen debugger. I tried with Seaside 3 developer > >> > image > >> > and it was the same situation. > >> > I'm using pharo on 32 bits Windows 7 in a Core 2 Duo and 2 GB ram > >> > memory. > >> > Has anybody experimented the same problem or behavior? > >> > Tranks, > >> > Facundo > >> > ps: Please, excuse my poor english. > >> > > >> > ___ > >> > 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 > > > > > > > > -- > > Facundo Vozzi > > InfOil S.A. > > Project Leader > > (+54-11) 4542- x108 > > fvo...@infoil.com.ar > > > > ___ > > 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 > -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542- x108 fvo...@infoil.com.ar ___ 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 getting HashedCollection (another dream happening)
On Mon, 12 Apr 2010, Peter Hugosson-Miller wrote: Sig, I agree with you! My example was of some code that would not survive the transition: using a asSet as a cheap way to get rid of the *possible* nils in a collection. (ab)using asSet this way is bad practive (if it works at all in VA). #(1 2 3 4 nil 6 7 nil) reject: #isNil and #(1 2 3 4 nil 6 7 nil) select: #notNil (or the corresponding versions with block arguments) are the way to do it. Levente In fact, I think I'm going to take a look at our code and do something about it now, just in case... Thanks for the heads-up -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] #recreateSpecialObjectsArray woes
On 12 April 2010 18:30, Fernando olivero wrote: > > > > On Apr 12, 2010, at 5:16 PM, Igor Stasenko wrote: > >> On 12 April 2010 17:43, Fernando olivero wrote: >>> Good idea! I had a similar idea when initially worked on Alien loader. >>> >>> I think that what is needed also is remove the dependency with the array, i >>> mean explicitly calling the indexes make the image crash if you didn't had >>> the assumed special object array size. >>> >>> >>> For example: >>> Smalltalk registerSpecialObject: myObject with: aName >>> >>> And later you reference that special object by aName instead of an >>> index to the array. >>> >>> >>> So it would be easier to load/unload the packages that extend the special >>> objects array, because there would be no explicit dependency to indexes. >>> >> Yeah, that would be nice. >> But this will require VM changes.. and therefore is doomed :) >> Also, this could impact the VM speed significantly, because its using >> special object quite frequently. >> Imagine replacing a simple index-based lookup with name(string) based. >> > > > > Hi Igor, i wasn't speaking of an on-image API change. > > For example if you introduced the API you mentioned we could replace > > Utilities>> initializeClosures > "Eliminate the prototype BlockContext from the specialObjectsArray. > The VM doesn't use it. This paves the way for removing BlockCOntext > altogether and merging ContextPart and MethodContext into e.g. Context." > (Smalltalk specialObjectsArray at: 38) class == BlockContext > ifTrue:[Smalltalk specialObjectsArray at: 38 put: nil]. > > With > > Utilities>> initializeClosures > .. > (Smalltalk hasSpecialObjectNamed: #BlockContext) > ifTrue:[ Smalltalk unregisterSpecialObjectNamed: #BlockContext > ]. > > Ah you mean associating indexes with corresponding names, so code can use a nice-looking names instead of bare indexes? But then who is responsible for providing these associations? Somewhere you have to put things like: BlockContextIndex := 38. so, then later you can do nice: Smalltalk unregisterSpecialObjectNamed: #BlockContextIndex The problem is, that we don't know these names beforehead. So, should a newly loaded package also define a new index names then? Like Smalltalk registerSpecialObjectIndex: 55 named: #MyName. and then to register an object, it should do: Smalltalk specialObjectAt: #MyName put: MySpecialObject. ? > ___ > 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
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > Lukas, > It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. > > But I test it on the same machine with Squeak 4.1 RC4 and it go very very > fast > to open de smalltalk debugger. > Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note that > too or it's only my sensations? > Did you check with Pharo 1.1? https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, but Pharo 1.1 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 getting HashedCollection (another dream happening)
On Apr 12, 2010, at 5:33 42PM, Stéphane Ducasse wrote: > igor > > peter snippets was just a dull example. Peter mentioned that some people fix > consequences instead of causes > > > Stef Or their application may have different expectations for what methods are ok to return collections with duplicated/nils in them. In which case (in VW) mySourcesWithoutNilsOrDuplicates |myColl| myColl := List new. myColl addAll: self aSourceWithNils. myColl addAll self aSourceWithDuplicates. ^myColl asSet might have been an entirely legit use, which is sure to cause headaches if ported to a dialect which allows nils. Not that that's a common occurrence, or something we should account for, just sayin' Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > >> Lukas, >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. >> >> But I test it on the same machine with Squeak 4.1 RC4 and it go very very >> fast >> to open de smalltalk debugger. >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note that >> too or it's only my sensations? >> > > Did you check with Pharo 1.1? > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, but > Pharo 1.1 > My theory for your bug is that it's this: http://code.google.com/p/pharo/issues/detail?id=860 We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed to be released "very soon". 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] [ANN 1.1] pre-built core image #11312
https://gforge.inria.fr/frs/download.php/26817/PharoCore-1.1-11312-UNSTABLE.zip -- 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] Open Pharo debugger from a Seaside wallback
Yes we have to kick our asses more often... but squeak is that for that :) Stef On Apr 12, 2010, at 5:54 PM, Marcus Denker wrote: > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > >> >> On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: >> >>> Lukas, >>> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. >>> >>> But I test it on the same machine with Squeak 4.1 RC4 and it go very very >>> fast >>> to open de smalltalk debugger. >>> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note that >>> too or it's only my sensations? >>> >> >> Did you check with Pharo 1.1? >> >> >> https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip >> >> In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, but >> Pharo 1.1 >> > > My theory for your bug is that it's this: > > http://code.google.com/p/pharo/issues/detail?id=860 > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed to > be released > "very soon". > > 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] Open Pharo debugger from a Seaside wallback
On Apr 12, 2010, at 5:54 59PM, Marcus Denker wrote: > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > >> >> On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: >> >>> Lukas, >>> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. >>> >>> But I test it on the same machine with Squeak 4.1 RC4 and it go very very >>> fast >>> to open de smalltalk debugger. >>> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note that >>> too or it's only my sensations? >>> >> >> Did you check with Pharo 1.1? >> >> >> https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip >> >> In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, but >> Pharo 1.1 >> > > My theory for your bug is that it's this: > > http://code.google.com/p/pharo/issues/detail?id=860 > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed to > be released > "very soon". > > Marcus It can still be slow in 1.1, depending on where the log is written to. F.ex. I opened an image on Windows under Parallells, which decided it wanted to write to somewhere in the mounted OSX home directory, took a few good seconds for the debugger to open. Cheers, Henry ___ 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] Re: #recreateSpecialObjectsArray woes
On 12 April 2010 19:32, Andreas Raab wrote: > On 4/12/2010 7:17 AM, Igor Stasenko wrote: >> >> what you think? > > I think "no, no, no". Two reasons: 1) the extension of the splObjs implies a > hardcoded contract with the VM; having it externally settable makes it look > as if one could just stick in stuff for fun. By 'For fun', you mean writing a plugin, which needs own a special objects to work? I wanted to add a special objects couple of times in plugins, but then i had to step back , knowing that it will require overriding the #recreateSpecialObjects method, which is tedious and error prone, because you never know if people who may use your plugin could also use FFI, Alien or something else. By keeping things intact, we're having a bottleneck which doesn't allows developers to use a special objects array in their plugins for own purposes (i guess you're not assuming that FFI and Alien are the only exceptional plugins which having an ultimate right to touch a special objects array). > 2) The recreation of the > splObjs implies specific knowledge about which values should be added and > which values should be removed. > Sure, each part of a system knows wery well which objects should be there and at what place. But there is no need to recreate an array (unless it needs to grow) , and it could be done automatically, by copying old objects into a new, bigger array, while revoking the #recreateSpecialObjects from system completely. For replacing an object(s) in array there is a simple as #at:put: Ensuring an array size doesn't means automatically that it should be rebuilt from scratch, in same way as OrderedCollection doesn't forcing you to add all items from scratch into it, once it needs to grow. > In any case, there are only two packages that have ever made mods to the > splObjs array (FFI and Alien) for *very* specialized reasons. We should just > add these definitions manually and remove the patch from the Alien package. > I think you are mixing the cause and consequence here. As to me, the reason, why there's only two plugins who extending a special objects array is because its very tedious and error prone. Mostly because of conflicting overrides by different packages! Anyways, if you don't like playing with special objects array. Please, can we think of a scheme which at least allows us to avoid overrides of a very same method by different packages? > Cheers, > - Andreas > -- 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
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
Marcus, I can't install Seaside on Pharo 1.1(*) but then i'll try again at home. It isn't my point to compare Pharo to Squeak performance but I used Squeak to test this particular situation. Thank you, Facu (*) it's very slow to write the log taking minutes to complete the instalation On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker wrote: > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > >> Lukas, > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. > >> > >> But I test it on the same machine with Squeak 4.1 RC4 and it go very > very fast > >> to open de smalltalk debugger. > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note > that too or it's only my sensations? > >> > > > > Did you check with Pharo 1.1? > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, > but Pharo 1.1 > > > > My theory for your bug is that it's this: > >http://code.google.com/p/pharo/issues/detail?id=860 > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed > to be released > "very soon". > >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 > -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542- x108 fvo...@infoil.com.ar ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] browse hierarchyImplementors raise an error
Yes, sorry it was fixed but I don't remember if I opened a ticketin case I dind', sorry. But don't worry it will be fixed for the next Pharo image. And if it is not, please let us know. cheers mariano 2010/4/12 Cyrille Delaunay > Hello, > > In a Pharo-1.0-10515-rc3 image, > > In the standard class browser, when you click on the green arrow at the left > of a method, to > browse hierarchyImplementor, an error occur. > > > I opened an issue: http://code.google.com/p/pharo/issues/detail?id=2305 > > > ___ > 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] [squeak-dev] Re: #recreateSpecialObjectsArray woes
On 4/12/2010 10:43 AM, Igor Stasenko wrote: On 12 April 2010 19:32, Andreas Raab wrote: On 4/12/2010 7:17 AM, Igor Stasenko wrote: what you think? I think "no, no, no". Two reasons: 1) the extension of the splObjs implies a hardcoded contract with the VM; having it externally settable makes it look as if one could just stick in stuff for fun. By 'For fun', you mean writing a plugin, which needs own a special objects to work? You don't need special objects. Their use in FFI and Alien is a historical accident. What you'd do today is register the classes directly with your plugin instead of sticking them into splObjs. I wanted to add a special objects couple of times in plugins, but then i had to step back , knowing that it will require overriding the #recreateSpecialObjects method, which is tedious and error prone, because you never know if people who may use your plugin could also use FFI, Alien or something else. Precisely. All of these are good reasons why you shouldn't modify splObjs to begin with. What you do instead is to provide a primitive in your plugin that accepts the classes / objects you intend to use. This wouldn't work in the past because you had no way of handling GC correctly. Today, you can give your plugin an array of your own special objects that is used by your plugin, registered with the VM as a GC root and there's no need to modify splObjs. Cheers, - Andreas By keeping things intact, we're having a bottleneck which doesn't allows developers to use a special objects array in their plugins for own purposes (i guess you're not assuming that FFI and Alien are the only exceptional plugins which having an ultimate right to touch a special objects array). 2) The recreation of the splObjs implies specific knowledge about which values should be added and which values should be removed. Sure, each part of a system knows wery well which objects should be there and at what place. But there is no need to recreate an array (unless it needs to grow) , and it could be done automatically, by copying old objects into a new, bigger array, while revoking the #recreateSpecialObjects from system completely. For replacing an object(s) in array there is a simple as #at:put: Ensuring an array size doesn't means automatically that it should be rebuilt from scratch, in same way as OrderedCollection doesn't forcing you to add all items from scratch into it, once it needs to grow. In any case, there are only two packages that have ever made mods to the splObjs array (FFI and Alien) for *very* specialized reasons. We should just add these definitions manually and remove the patch from the Alien package. I think you are mixing the cause and consequence here. As to me, the reason, why there's only two plugins who extending a special objects array is because its very tedious and error prone. Mostly because of conflicting overrides by different packages! Anyways, if you don't like playing with special objects array. Please, can we think of a scheme which at least allows us to avoid overrides of a very same method by different packages? Cheers, - Andreas ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] pharo on sparc solaris
On Mon, Apr 12, 2010 at 11:42 AM, Tudor Girba wrote: > Hi, > > I would need to run a Pharo RC4 image on a Sparc Solaris station. Looking > on the www.squeakvm.org/unix/, I see that there is no VM for such a > station, only for Intel Solaris. > > Unfortunately, I also do not have access to any compiling tools on this > machine (it's a server). not even gcc or cmake ? weird > Can anyone help me with this issue? > > Maybe you can cc vm mailing list ? cheers mariano > The machine says it is: > $ uname -a > SunOS ejpdxa9017 5.10 Generic_142900-03 sun4v sparc > SUNW,SPARC-Enterprise-T5220 > > > Cheers, > Doru > > -- > www.tudorgirba.com > > "To lead is not to demand things, it is to make them happen." > > > > > ___ > 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] add #next:putAll:startingAt: to SocketStream
On 11.04.2010 21:46, Levente Uzonyi wrote: > On Sun, 11 Apr 2010, Philippe Marschall wrote: > >> Hi >> >> While I was optimizing some Seaside code I found out that SocketStream >> does not understand #next:putAll:startingAt: [1]. It's quite a helpful >> method that allows one to write a subcollection of a collection to a >> stream without making a copy. In our case it would allow the codec to >> directly write to the socket stream. >> >> Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) >> >> [1] http://code.google.com/p/pharo/issues/detail?id=2292 > > FYI: http://code.google.com/p/pharo/issues/detail?id=2244 Oops, sorry. The merged code is a bit different, it's oriented more towards the current #nextPutAll: - it answers self like #nextPutAll: and not the collection passed in. ANSI says it's unspecified and current implementations are not conclusive, most answer the collection but not all. That probably means we should change #nextPutAll: as well. - it explicitly checks for n = 0 as a guarding clause. That's certainly discussable, I found algorithms easier to write when I don't have to check for n = 0 at the send site. - it had an off by one error - like #nextPutAll: it does type conversion based on the mode. To sum up: - #nextPutAll: and #next:putAll:startingAt: should probably be changed to answer the collection and fix other implementations. - if the type conversion is needed (I believe so) then SocketStream should do it - the n = 0 guarding clause is discussable - IMO consistency with #nextPutAll: is important 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] [squeak-dev] Re: #recreateSpecialObjectsArray woes
On 12 April 2010 20:49, Andreas Raab wrote: > On 4/12/2010 10:43 AM, Igor Stasenko wrote: >> >> On 12 April 2010 19:32, Andreas Raab wrote: >>> >>> On 4/12/2010 7:17 AM, Igor Stasenko wrote: what you think? >>> >>> I think "no, no, no". Two reasons: 1) the extension of the splObjs >>> implies a >>> hardcoded contract with the VM; having it externally settable makes it >>> look >>> as if one could just stick in stuff for fun. >> >> By 'For fun', you mean writing a plugin, which needs own a special >> objects to work? > > You don't need special objects. Their use in FFI and Alien is a historical > accident. What you'd do today is register the classes directly with your > plugin instead of sticking them into splObjs. > >> I wanted to add a special objects couple of times in plugins, but then i >> had to >> step back , knowing that it will require overriding the >> #recreateSpecialObjects >> method, which is tedious and error prone, because you never know if people >> who may use your plugin could also use FFI, Alien or something else. > > Precisely. All of these are good reasons why you shouldn't modify splObjs to > begin with. What you do instead is to provide a primitive in your plugin > that accepts the classes / objects you intend to use. This wouldn't work in > the past because you had no way of handling GC correctly. > > Today, you can give your plugin an array of your own special objects that is > used by your plugin, registered with the VM as a GC root and there's no need > to modify splObjs. > Looks like i missed something. HOW? Suppose a primitive needs to answer an instance of a special class, known by it. How it can instantiate it, if it having no any clues, where its invoked from, and it can't rely on a receiver, nor any of method's arguments? > Cheers, > - Andreas > >> -- 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
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > Marcus, > I can't install Seaside on Pharo 1.1(*) but then i'll try again at home. > > It isn't my point to compare Pharo to Squeak performance but I used Squeak to > test this particular situation. > > Thank you, > > Facu > > (*) it's very slow to write the log taking minutes to complete the instalation which log? Stef > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker > wrote: > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > >> Lukas, > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. > >> > >> But I test it on the same machine with Squeak 4.1 RC4 and it go very very > >> fast > >> to open de smalltalk debugger. > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note > >> that too or it's only my sensations? > >> > > > > Did you check with Pharo 1.1? > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, but > > Pharo 1.1 > > > > My theory for your bug is that it's this: > >http://code.google.com/p/pharo/issues/detail?id=860 > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed to > be released > "very soon". > >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 > > > > -- > Facundo Vozzi > InfOil S.A. > Project Leader > (+54-11) 4542- x108 > fvo...@infoil.com.ar > ___ > 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] add #next:putAll:startingAt: to SocketStream
On Apr 12, 2010, at 7:53 PM, Philippe Marschall wrote: > On 11.04.2010 21:46, Levente Uzonyi wrote: >> On Sun, 11 Apr 2010, Philippe Marschall wrote: >> >>> Hi >>> >>> While I was optimizing some Seaside code I found out that SocketStream >>> does not understand #next:putAll:startingAt: [1]. It's quite a helpful >>> method that allows one to write a subcollection of a collection to a >>> stream without making a copy. In our case it would allow the codec to >>> directly write to the socket stream. >>> >>> Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) >>> >>> [1] http://code.google.com/p/pharo/issues/detail?id=2292 >> >> FYI: http://code.google.com/p/pharo/issues/detail?id=2244 > > Oops, sorry. > > The merged code is a bit different, it's oriented more towards the > current #nextPutAll: > - it answers self like #nextPutAll: and not the collection passed > in. ANSI says it's unspecified and current implementations are not > conclusive, most answer the collection but not all. That probably means > we should change #nextPutAll: as well. > - it explicitly checks for n = 0 as a guarding clause. That's certainly > discussable, I found algorithms easier to write when I don't have to > check for n = 0 at the send site. > - it had an off by one error > - like #nextPutAll: it does type conversion based on the mode. > > To sum up: > - #nextPutAll: and #next:putAll:startingAt: should probably be changed > to answer the collection and fix other implementations. nicolas did the inverse in squeak > - if the type conversion is needed (I believe so) then SocketStream > should do it > - the n = 0 guarding clause is discussable > - IMO consistency with #nextPutAll: is important do you have some code? Because it seems that you have more knowledge than me on that :) 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] #recreateSpecialObjectsArray woes
On 4/12/2010 10:57 AM, Igor Stasenko wrote:
On 12 April 2010 20:49, Andreas Raab wrote:
Today, you can give your plugin an array of your own special objects that is
used by your plugin, registered with the VM as a GC root and there's no need
to modify splObjs.
Looks like i missed something. HOW?
Suppose a primitive needs to answer an instance of a special class, known by it.
How it can instantiate it, if it having no any clues, where its
invoked from, and it can't rely on a receiver, nor any of method's arguments?
You make it work just like splObjs, i.e.,
FooPlugin>>primitiveSetSplObjs
"Sets the special objects for my plugin"
splObjs := interpreterProxy stackObjectValue: 0.
"... should have sanity checks ..."
interpreterProxy addGCRoot: (self cCode: '&splObjs').
FooPlugin>>instantiateNewBar
"Instantiates a new Bar (at index 2 in the splObjs)"
"... should have sanity checks ..."
foo := interpreterProxy instantiateClass: (interpreterProxy
fetchPointer: 2 ofObject: splObjs) indexableSize: 0.
interpreterProxy pop: 1 thenPush: foo.
then you use it like here:
Foo class>>startUp: resuming
"Install my special objects on system startup"
resuming ifTrue:[
self primitiveSetSplObjs: {Foo. Bar. DukeNukem. 42}.
].
Foo class>>newBar
^self primitiveNewBar
The "trick" is that your plugin can register whatever it wants for GC
tracing (in fact you should probably set the variable to nilObj and call
addGCRoot from initialiseModule exactly once and release it via
shutdownModule). This removes the need for abusing splObjs to stick in
stuff that you'd like to preserve between prim calls.
Cheers,
- Andreas
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
Another difference maybe the tools that are loaded in Squeak and Pharo. I am not aware what is loaded in Squeak images, but in PharoDev you have OB, OCompletion, RefactoringBrowser, TrueType fonts, Shout, etc. Some of these tools make Pharo a bit more slower than the PharoCore. If they Squeak image you are using doesn't have all those tools, then you should compare to a PharoCore image, not Dev. Pharo core images doesn't have all the dev tools. Cheers Mariano On Mon, Apr 12, 2010 at 3:05 PM, Stéphane Ducasse wrote: > > On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > > > Marcus, > > I can't install Seaside on Pharo 1.1(*) but then i'll try again at home. > > > > It isn't my point to compare Pharo to Squeak performance but I used > Squeak to test this particular situation. > > > > Thank you, > > > > Facu > > > > (*) it's very slow to write the log taking minutes to complete the > instalation > > which log? > > Stef > > > > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker > wrote: > > > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > > > >> Lukas, > > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. > > >> > > >> But I test it on the same machine with Squeak 4.1 RC4 and it go very > very fast > > >> to open de smalltalk debugger. > > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note > that too or it's only my sensations? > > >> > > > > > > Did you check with Pharo 1.1? > > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, > but Pharo 1.1 > > > > > > > My theory for your bug is that it's this: > > > >http://code.google.com/p/pharo/issues/detail?id=860 > > > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed > to be released > > "very soon". > > > >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 > > > > > > > > -- > > Facundo Vozzi > > InfOil S.A. > > Project Leader > > (+54-11) 4542- x108 > > fvo...@infoil.com.ar > > ___ > > 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] [squeak-dev] Re: #recreateSpecialObjectsArray woes
On 12 April 2010 21:08, Andreas Raab wrote:
> On 4/12/2010 10:57 AM, Igor Stasenko wrote:
>>
>> On 12 April 2010 20:49, Andreas Raab wrote:
>>>
>>> Today, you can give your plugin an array of your own special objects that
>>> is
>>> used by your plugin, registered with the VM as a GC root and there's no
>>> need
>>> to modify splObjs.
>>>
>> Looks like i missed something. HOW?
>> Suppose a primitive needs to answer an instance of a special class, known
>> by it.
>> How it can instantiate it, if it having no any clues, where its
>> invoked from, and it can't rely on a receiver, nor any of method's
>> arguments?
>
> You make it work just like splObjs, i.e.,
>
> FooPlugin>>primitiveSetSplObjs
> "Sets the special objects for my plugin"
> splObjs := interpreterProxy stackObjectValue: 0.
> "... should have sanity checks ..."
> interpreterProxy addGCRoot: (self cCode: '&splObjs').
>
> FooPlugin>>instantiateNewBar
> "Instantiates a new Bar (at index 2 in the splObjs)"
>
> "... should have sanity checks ..."
> foo := interpreterProxy instantiateClass: (interpreterProxy
> fetchPointer: 2 ofObject: splObjs) indexableSize: 0.
> interpreterProxy pop: 1 thenPush: foo.
>
> then you use it like here:
>
> Foo class>>startUp: resuming
> "Install my special objects on system startup"
> resuming ifTrue:[
> self primitiveSetSplObjs: {Foo. Bar. DukeNukem. 42}.
> ].
>
> Foo class>>newBar
> ^self primitiveNewBar
>
> The "trick" is that your plugin can register whatever it wants for GC
> tracing (in fact you should probably set the variable to nilObj and call
> addGCRoot from initialiseModule exactly once and release it via
> shutdownModule). This removes the need for abusing splObjs to stick in stuff
> that you'd like to preserve between prim calls.
>
Ah, that's cool.. Except that most recent SVN repository
sqVirtualMachine.h (revision 1955) having no addGCroot: defined in
InterpreterProxy struct.
I am using wrong SVN repository?
http://squeakvm.org/svn/squeak/trunk/
After some research i found another file in plugins/IA32ABI/, which
includes new proxy functions, but its not used by builder.
> Cheers,
> - Andreas
>
>
--
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
Re: [Pharo-project] #recreateSpecialObjectsArray woes
On 4/12/2010 11:46 AM, Igor Stasenko wrote: Ah, that's cool.. Except that most recent SVN repository sqVirtualMachine.h (revision 1955) having no addGCroot: defined in InterpreterProxy struct. I am using wrong SVN repository? http://squeakvm.org/svn/squeak/trunk/ Err, weird. The code is in VMMaker but it seems as if SVN hasn't been updated. It should include this: #if VM_PROXY_MINOR > 7 /* New methods for proxy version 1.8 */ /* callbackEnter: Re-enter the interpreter loop for a callback. Arguments: callbackID: Pointer to a location receiving the callback ID used in callbackLeave Returns: True if successful, false otherwise */ sqInt (*callbackEnter)(sqInt *callbackID); /* callbackLeave: Leave the interpreter from a previous callback Arguments: callbackID: The ID of the callback received from callbackEnter() Returns: True if succcessful, false otherwise. */ sqInt (*callbackLeave)(sqInt callbackID); /* addGCRoot: Add a variable location to the garbage collector. The contents of the variable location will be updated accordingly. Arguments: varLoc: Pointer to the variable location Returns: True if successful, false otherwise. */ sqInt (*addGCRoot)(sqInt *varLoc); /* removeGCRoot: Remove a variable location from the garbage collector. Arguments: varLoc: Pointer to the variable location Returns: True if successful, false otherwise. */ sqInt (*removeGCRoot)(sqInt *varLoc); #endif Cheers, - Andreas ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Regex Chapter for PBE 2 is now online
The draft chapter on Regular Expressions in Pharo planned for Pharo by Example 2 is now available online for review: https://gforge.inria.fr/frs/download.php/26818/Regex.pdf Please send feedback to the discussion list for SBE and PBE: https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion Thanks, - on ___ 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] Re: #recreateSpecialObjectsArray woes
On 12 April 2010 21:52, Andreas Raab wrote: > On 4/12/2010 11:46 AM, Igor Stasenko wrote: >> >> Ah, that's cool.. Except that most recent SVN repository >> sqVirtualMachine.h (revision 1955) having no addGCroot: defined in >> InterpreterProxy struct. >> I am using wrong SVN repository? >> http://squeakvm.org/svn/squeak/trunk/ > > Err, weird. The code is in VMMaker but it seems as if SVN hasn't been > updated. It should include this: > Yes. I remember seeing that code before. This is twice strange that its not in SVN repo. [snip] > > Cheers, > - Andreas > > -- 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
Re: [Pharo-project] [squeak-dev] Re: #recreateSpecialObjectsArray woes
It's in the Alien directory. somehow it never got promoted to the cross platform directory. So check the sqVirtualMachine.h You may need to adjust it. On 2010-04-12, at 12:01 PM, Igor Stasenko wrote: > On 12 April 2010 21:52, Andreas Raab wrote: >> On 4/12/2010 11:46 AM, Igor Stasenko wrote: >>> >>> Ah, that's cool.. Except that most recent SVN repository >>> sqVirtualMachine.h (revision 1955) having no addGCroot: defined in >>> InterpreterProxy struct. >>> I am using wrong SVN repository? >>> http://squeakvm.org/svn/squeak/trunk/ >> >> Err, weird. The code is in VMMaker but it seems as if SVN hasn't been >> updated. It should include this: >> > > Yes. I remember seeing that code before. > This is twice strange that its not in SVN repo. > > [snip] > >> >> Cheers, >> - Andreas >> >> > > > > -- > 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 -- === John M. McIntoshTwitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
Marcus, it's took to me over 20 minutes complete the Seaside 2.8 instalation and the problem persist. It takes 15 seconds to open the smalltalk debugger from the seaside wallback page. Facu On Mon, Apr 12, 2010 at 12:41 PM, Marcus Denker wrote: > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > Lukas, > > It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. > > > > But I test it on the same machine with Squeak 4.1 RC4 and it go very very > fast > > to open de smalltalk debugger. > > Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note > that too or it's only my sensations? > > > > Did you check with Pharo 1.1? > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, but > Pharo 1.1 > >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 > -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542- x108 fvo...@infoil.com.ar ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
Stef, It took to me over 20 minutes to complete the Seaside 2.8 installation and when I interrupted it the debugger opened when the system was writting the pharoXXX.changes always but I couldn't check what is happening. I will check it again. Facu ps: I refered to pharoXXX.changes as "log" because of Visual Smalltalk where the "changes" are called changes.log, excuse me. On Mon, Apr 12, 2010 at 3:05 PM, Stéphane Ducasse wrote: > > On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > > > Marcus, > > I can't install Seaside on Pharo 1.1(*) but then i'll try again at home. > > > > It isn't my point to compare Pharo to Squeak performance but I used > Squeak to test this particular situation. > > > > Thank you, > > > > Facu > > > > (*) it's very slow to write the log taking minutes to complete the > instalation > > which log? > > Stef > > > > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker > wrote: > > > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > > > >> Lukas, > > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. > > >> > > >> But I test it on the same machine with Squeak 4.1 RC4 and it go very > very fast > > >> to open de smalltalk debugger. > > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note > that too or it's only my sensations? > > >> > > > > > > Did you check with Pharo 1.1? > > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, > but Pharo 1.1 > > > > > > > My theory for your bug is that it's this: > > > >http://code.google.com/p/pharo/issues/detail?id=860 > > > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed > to be released > > "very soon". > > > >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 > > > > > > > > -- > > Facundo Vozzi > > InfOil S.A. > > Project Leader > > (+54-11) 4542- x108 > > fvo...@infoil.com.ar > > ___ > > 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 > -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542- x108 fvo...@infoil.com.ar ___ 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] Re: #recreateSpecialObjectsArray woes
Okay, then i propose to: 1. fix the interpreterProxy spec, so all VMs will include addRoot() & friends 2. create a single and _final_ version of #recreateSpecialObjectsArray 3. remove overrides of this method from both FFI and Alien packages. 4. Optionally, rewrite plugins to use own special objects at initialization, so they no longer need extending specialObjectsArray, and hence use of #recreateSpecialObjectsArray -- 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
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
Mariano, I don't what is loaded in Squeak because I only open it to check this particular problem but Squeak 4.1 RC4 looks like Pharo. I used it because it was easy to me load seaside and discard a network connection problem on the operative system level. Cheers, Facu 2010/4/12 Mariano Martinez Peck > Another difference maybe the tools that are loaded in Squeak and Pharo. I > am not aware what is loaded in Squeak images, but in PharoDev you have OB, > OCompletion, RefactoringBrowser, TrueType fonts, Shout, etc. > > Some of these tools make Pharo a bit more slower than the PharoCore. If > they Squeak image you are using doesn't have all those tools, then you > should compare to a PharoCore image, not Dev. Pharo core images doesn't have > all the dev tools. > > Cheers > > Mariano > > > On Mon, Apr 12, 2010 at 3:05 PM, Stéphane Ducasse < > stephane.duca...@inria.fr> wrote: > >> >> On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: >> >> > Marcus, >> > I can't install Seaside on Pharo 1.1(*) but then i'll try again at home. >> > >> > It isn't my point to compare Pharo to Squeak performance but I used >> Squeak to test this particular situation. >> > >> > Thank you, >> > >> > Facu >> > >> > (*) it's very slow to write the log taking minutes to complete the >> instalation >> >> which log? >> >> Stef >> >> > >> > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker >> wrote: >> > >> > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: >> > >> > > >> > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: >> > > >> > >> Lukas, >> > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and >> Pharo. >> > >> >> > >> But I test it on the same machine with Squeak 4.1 RC4 and it go very >> very fast >> > >> to open de smalltalk debugger. >> > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you >> note that too or it's only my sensations? >> > >> >> > > >> > > Did you check with Pharo 1.1? >> > > >> > > >> https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip >> > > >> > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, >> but Pharo 1.1 >> > > >> > >> > My theory for your bug is that it's this: >> > >> >http://code.google.com/p/pharo/issues/detail?id=860 >> > >> > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was >> supposed to be released >> > "very soon". >> > >> >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 >> > >> > >> > >> > -- >> > Facundo Vozzi >> > InfOil S.A. >> > Project Leader >> > (+54-11) 4542- x108 >> > fvo...@infoil.com.ar >> > ___ >> > 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 > -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542- x108 fvo...@infoil.com.ar ___ 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] Re: #recreateSpecialObjectsArray woes
On Apr 12, 2010, at 9:49 PM, Igor Stasenko wrote: > Okay, then i propose to: > > 1. fix the interpreterProxy spec, so all VMs will include addRoot() & friends > 2. create a single and _final_ version of #recreateSpecialObjectsArray > 3. remove overrides of this method from both FFI and Alien packages. > 4. Optionally, rewrite plugins to use own special objects at initialization, > so > they no longer need extending specialObjectsArray, and hence use of > #recreateSpecialObjectsArray 5. Add a **large comment** stating how it should be done. For example using the example andreas used. Stef > > -- > 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
Re: [Pharo-project] Regex Chapter for PBE 2 is now online
Thanks!!! Stef (we have some more in preparation). On Apr 12, 2010, at 8:55 PM, Oscar Nierstrasz wrote: > > The draft chapter on Regular Expressions in Pharo planned for Pharo by > Example 2 is now available online for review: > > https://gforge.inria.fr/frs/download.php/26818/Regex.pdf > > Please send feedback to the discussion list for SBE and PBE: > > https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion > > Thanks, > - on > > > ___ > 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] Open Pharo debugger from a Seaside wallback
This is really strange. Can you describe your setup? Do you have an antivirus? And with Squeak you do not have that behavior? We are loading larger code than seaside in Pharo and we do not have this problem. So I would really like to understand. Could you post your image somewhere? Stef On Apr 12, 2010, at 9:27 PM, Facundo Vozzi wrote: > Stef, > It took to me over 20 minutes to complete the Seaside 2.8 installation and > when I interrupted it the debugger opened when the system was writting the > pharoXXX.changes always but I couldn't check what is happening. > > I will check it again. > > Facu > > ps: I refered to pharoXXX.changes as "log" because of Visual Smalltalk where > the "changes" are called changes.log, excuse me. > > On Mon, Apr 12, 2010 at 3:05 PM, Stéphane Ducasse > wrote: > > On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > > > Marcus, > > I can't install Seaside on Pharo 1.1(*) but then i'll try again at home. > > > > It isn't my point to compare Pharo to Squeak performance but I used Squeak > > to test this particular situation. > > > > Thank you, > > > > Facu > > > > (*) it's very slow to write the log taking minutes to complete the > > instalation > > which log? > > Stef > > > > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker > > wrote: > > > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > > > >> Lukas, > > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. > > >> > > >> But I test it on the same machine with Squeak 4.1 RC4 and it go very > > >> very fast > > >> to open de smalltalk debugger. > > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note > > >> that too or it's only my sensations? > > >> > > > > > > Did you check with Pharo 1.1? > > > > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, > > > but Pharo 1.1 > > > > > > > My theory for your bug is that it's this: > > > >http://code.google.com/p/pharo/issues/detail?id=860 > > > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed > > to be released > > "very soon". > > > >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 > > > > > > > > -- > > Facundo Vozzi > > InfOil S.A. > > Project Leader > > (+54-11) 4542- x108 > > fvo...@infoil.com.ar > > ___ > > 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 > > > > -- > Facundo Vozzi > InfOil S.A. > Project Leader > (+54-11) 4542- x108 > fvo...@infoil.com.ar > ___ > 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] [squeak-dev] Re: #recreateSpecialObjectsArray woes
On 4/12/2010 12:49 PM, Igor Stasenko wrote: Okay, then i propose to: 1. fix the interpreterProxy spec, so all VMs will include addRoot()& friends 2. create a single and _final_ version of #recreateSpecialObjectsArray 3. remove overrides of this method from both FFI and Alien packages. 4. Optionally, rewrite plugins to use own special objects at initialization, so they no longer need extending specialObjectsArray, and hence use of #recreateSpecialObjectsArray +1. Cheers, - Andreas ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
Stef, I'm using Pharo 1.0 RC2 with Seaside 2.8.4 and all is fine but it took over 15 seconds open a smalltalk debugger from a Seaside wallback. It was the reason of my first mail. I tried with Squeak 4.1 RC4, to discard a network configuration problem at operative system level, and i don't have the problem. It takes 1 second to open the debugger. Then, Marcus ask to me if i had the same problem with "PharoCore-1.1-11301-UNSTABLE", at that time I download it, installed Seaside and try again. To Install Seaside took to me over 20 minutes but I had been instaled it on Pharo 1.0 and was been fine. Is it more clear now ?. Please, sorry for my poor English. Facu On Mon, Apr 12, 2010 at 5:03 PM, Stéphane Ducasse wrote: > This is really strange. Can you describe your setup? Do you have an > antivirus? And with Squeak you do not have that behavior? > We are loading larger code than seaside in Pharo and we do not have this > problem. > So I would really like to understand. Could you post your image somewhere? > > Stef > > On Apr 12, 2010, at 9:27 PM, Facundo Vozzi wrote: > > > Stef, > > It took to me over 20 minutes to complete the Seaside 2.8 installation > and when I interrupted it the debugger opened when the system was writting > the pharoXXX.changes always but I couldn't check what is happening. > > > > I will check it again. > > > > Facu > > > > ps: I refered to pharoXXX.changes as "log" because of Visual Smalltalk > where the "changes" are called changes.log, excuse me. > > > > On Mon, Apr 12, 2010 at 3:05 PM, Stéphane Ducasse < > stephane.duca...@inria.fr> wrote: > > > > On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > > > > > Marcus, > > > I can't install Seaside on Pharo 1.1(*) but then i'll try again at > home. > > > > > > It isn't my point to compare Pharo to Squeak performance but I used > Squeak to test this particular situation. > > > > > > Thank you, > > > > > > Facu > > > > > > (*) it's very slow to write the log taking minutes to complete the > instalation > > > > which log? > > > > Stef > > > > > > > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker < > marcus.den...@inria.fr> wrote: > > > > > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > > > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > > > > > >> Lukas, > > > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and > Pharo. > > > >> > > > >> But I test it on the same machine with Squeak 4.1 RC4 and it go very > very fast > > > >> to open de smalltalk debugger. > > > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you > note that too or it's only my sensations? > > > >> > > > > > > > > Did you check with Pharo 1.1? > > > > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > > > > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 > speed-wise, but Pharo 1.1 > > > > > > > > > > My theory for your bug is that it's this: > > > > > >http://code.google.com/p/pharo/issues/detail?id=860 > > > > > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was > supposed to be released > > > "very soon". > > > > > >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 > > > > > > > > > > > > -- > > > Facundo Vozzi > > > InfOil S.A. > > > Project Leader > > > (+54-11) 4542- x108 > > > fvo...@infoil.com.ar > > > ___ > > > 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 > > > > > > > > -- > > Facundo Vozzi > > InfOil S.A. > > Project Leader > > (+54-11) 4542- x108 > > fvo...@infoil.com.ar > > ___ > > 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 > -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542- x108 fvo...@infoil.com.ar ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
On Apr 12, 2010, at 10:18 PM, Facundo Vozzi wrote: > Stef, > I'm using Pharo 1.0 RC2 with Seaside 2.8.4 and all is fine but it took over > 15 seconds open a smalltalk debugger from a Seaside wallback. It was the > reason of my first mail. > I tried with Squeak 4.1 RC4, to discard a network configuration problem at > operative system level, and i don't have the problem. It takes 1 second to > open the debugger. > Then, Marcus ask to me if i had the same problem with > "PharoCore-1.1-11301-UNSTABLE", at that time I download it, installed Seaside > and try again. To Install Seaside took to me over 20 minutes but I had been > instaled it on Pharo 1.0 and was been fine. ok so with 1.1 this is working? There were a **lot** of changes in 1.1. We will release shortly after 1.0 and much much faster :) > Is it more clear now ?. Please, sorry for my poor English. Don;t worry. write simple sentences and we will understand you. > > Facu > > > On Mon, Apr 12, 2010 at 5:03 PM, Stéphane Ducasse > wrote: > This is really strange. Can you describe your setup? Do you have an > antivirus? And with Squeak you do not have that behavior? > We are loading larger code than seaside in Pharo and we do not have this > problem. > So I would really like to understand. Could you post your image somewhere? > > Stef > > On Apr 12, 2010, at 9:27 PM, Facundo Vozzi wrote: > > > Stef, > > It took to me over 20 minutes to complete the Seaside 2.8 installation and > > when I interrupted it the debugger opened when the system was writting the > > pharoXXX.changes always but I couldn't check what is happening. > > > > I will check it again. > > > > Facu > > > > ps: I refered to pharoXXX.changes as "log" because of Visual Smalltalk > > where the "changes" are called changes.log, excuse me. > > > > On Mon, Apr 12, 2010 at 3:05 PM, Stéphane Ducasse > > wrote: > > > > On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > > > > > Marcus, > > > I can't install Seaside on Pharo 1.1(*) but then i'll try again at home. > > > > > > It isn't my point to compare Pharo to Squeak performance but I used > > > Squeak to test this particular situation. > > > > > > Thank you, > > > > > > Facu > > > > > > (*) it's very slow to write the log taking minutes to complete the > > > instalation > > > > which log? > > > > Stef > > > > > > > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker > > > wrote: > > > > > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > > > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > > > > > >> Lukas, > > > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. > > > >> > > > >> But I test it on the same machine with Squeak 4.1 RC4 and it go very > > > >> very fast > > > >> to open de smalltalk debugger. > > > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note > > > >> that too or it's only my sensations? > > > >> > > > > > > > > Did you check with Pharo 1.1? > > > > > > > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > > > > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, > > > > but Pharo 1.1 > > > > > > > > > > My theory for your bug is that it's this: > > > > > >http://code.google.com/p/pharo/issues/detail?id=860 > > > > > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed > > > to be released > > > "very soon". > > > > > >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 > > > > > > > > > > > > -- > > > Facundo Vozzi > > > InfOil S.A. > > > Project Leader > > > (+54-11) 4542- x108 > > > fvo...@infoil.com.ar > > > ___ > > > 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 > > > > > > > > -- > > Facundo Vozzi > > InfOil S.A. > > Project Leader > > (+54-11) 4542- x108 > > fvo...@infoil.com.ar > > ___ > > 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 > > > > -- > Facundo Vozzi > InfOil S.A. > Project Leader > (+54-11) 4542- x108 > fvo...@infoil.com.ar >
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
It continues taking longer 15 seconds on 1.1 too, there isn't change. I will try to compare with Squeak looking for the possible problem and its solution. nobody has the same problem? Thank you, Facu On Mon, Apr 12, 2010 at 5:28 PM, Stéphane Ducasse wrote: > > On Apr 12, 2010, at 10:18 PM, Facundo Vozzi wrote: > > > Stef, > > I'm using Pharo 1.0 RC2 with Seaside 2.8.4 and all is fine but it took > over 15 seconds open a smalltalk debugger from a Seaside wallback. It was > the reason of my first mail. > > I tried with Squeak 4.1 RC4, to discard a network configuration problem > at operative system level, and i don't have the problem. It takes 1 second > to open the debugger. > > Then, Marcus ask to me if i had the same problem with > "PharoCore-1.1-11301-UNSTABLE", at that time I download it, installed > Seaside and try again. To Install Seaside took to me over 20 minutes but I > had been instaled it on Pharo 1.0 and was been fine. > > ok so with 1.1 this is working? > There were a **lot** of changes in 1.1. We will release shortly after 1.0 > and much much faster :) > > > Is it more clear now ?. Please, sorry for my poor English. > > Don;t worry. write simple sentences and we will understand you. > > > > Facu > > > > > > On Mon, Apr 12, 2010 at 5:03 PM, Stéphane Ducasse < > stephane.duca...@inria.fr> wrote: > > This is really strange. Can you describe your setup? Do you have an > antivirus? And with Squeak you do not have that behavior? > > We are loading larger code than seaside in Pharo and we do not have this > problem. > > So I would really like to understand. Could you post your image > somewhere? > > > > Stef > > > > On Apr 12, 2010, at 9:27 PM, Facundo Vozzi wrote: > > > > > Stef, > > > It took to me over 20 minutes to complete the Seaside 2.8 installation > and when I interrupted it the debugger opened when the system was writting > the pharoXXX.changes always but I couldn't check what is happening. > > > > > > I will check it again. > > > > > > Facu > > > > > > ps: I refered to pharoXXX.changes as "log" because of Visual Smalltalk > where the "changes" are called changes.log, excuse me. > > > > > > On Mon, Apr 12, 2010 at 3:05 PM, Stéphane Ducasse < > stephane.duca...@inria.fr> wrote: > > > > > > On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > > > > > > > Marcus, > > > > I can't install Seaside on Pharo 1.1(*) but then i'll try again at > home. > > > > > > > > It isn't my point to compare Pharo to Squeak performance but I used > Squeak to test this particular situation. > > > > > > > > Thank you, > > > > > > > > Facu > > > > > > > > (*) it's very slow to write the log taking minutes to complete the > instalation > > > > > > which log? > > > > > > Stef > > > > > > > > > > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker < > marcus.den...@inria.fr> wrote: > > > > > > > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > > > > > > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > > > > > > > >> Lukas, > > > > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and > Pharo. > > > > >> > > > > >> But I test it on the same machine with Squeak 4.1 RC4 and it go > very very fast > > > > >> to open de smalltalk debugger. > > > > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you > note that too or it's only my sensations? > > > > >> > > > > > > > > > > Did you check with Pharo 1.1? > > > > > > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > > > > > > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 > speed-wise, but Pharo 1.1 > > > > > > > > > > > > > My theory for your bug is that it's this: > > > > > > > >http://code.google.com/p/pharo/issues/detail?id=860 > > > > > > > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was > supposed to be released > > > > "very soon". > > > > > > > >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 > > > > > > > > > > > > > > > > -- > > > > Facundo Vozzi > > > > InfOil S.A. > > > > Project Leader > > > > (+54-11) 4542- x108 > > > > fvo...@infoil.com.ar > > > > ___ > > > > 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 > > > > > > > > > > > > -- > > > Facundo Vozzi > > > InfOil S.A. > > > Project Leader > > > (+54-11) 4542- x108 > > > fvo...@inf
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
On Apr 12, 2010, at 10:46 PM, Facundo Vozzi wrote: > It continues taking longer 15 seconds on 1.1 too, there isn't change. I will > try to compare with Squeak looking for the possible problem and its solution. > > nobody has the same problem? No and this is strange because 1.1 got a lot of the stream changes that made squeak faster. > > Thank you, > Facu > > On Mon, Apr 12, 2010 at 5:28 PM, Stéphane Ducasse > wrote: > > On Apr 12, 2010, at 10:18 PM, Facundo Vozzi wrote: > > > Stef, > > I'm using Pharo 1.0 RC2 with Seaside 2.8.4 and all is fine but it took over > > 15 seconds open a smalltalk debugger from a Seaside wallback. It was the > > reason of my first mail. > > I tried with Squeak 4.1 RC4, to discard a network configuration problem at > > operative system level, and i don't have the problem. It takes 1 second to > > open the debugger. > > Then, Marcus ask to me if i had the same problem with > > "PharoCore-1.1-11301-UNSTABLE", at that time I download it, installed > > Seaside and try again. To Install Seaside took to me over 20 minutes but I > > had been instaled it on Pharo 1.0 and was been fine. > > ok so with 1.1 this is working? > There were a **lot** of changes in 1.1. We will release shortly after 1.0 and > much much faster :) > > > Is it more clear now ?. Please, sorry for my poor English. > > Don;t worry. write simple sentences and we will understand you. > > > > Facu > > > > > > On Mon, Apr 12, 2010 at 5:03 PM, Stéphane Ducasse > > wrote: > > This is really strange. Can you describe your setup? Do you have an > > antivirus? And with Squeak you do not have that behavior? > > We are loading larger code than seaside in Pharo and we do not have this > > problem. > > So I would really like to understand. Could you post your image somewhere? > > > > Stef > > > > On Apr 12, 2010, at 9:27 PM, Facundo Vozzi wrote: > > > > > Stef, > > > It took to me over 20 minutes to complete the Seaside 2.8 installation > > > and when I interrupted it the debugger opened when the system was > > > writting the pharoXXX.changes always but I couldn't check what is > > > happening. > > > > > > I will check it again. > > > > > > Facu > > > > > > ps: I refered to pharoXXX.changes as "log" because of Visual Smalltalk > > > where the "changes" are called changes.log, excuse me. > > > > > > On Mon, Apr 12, 2010 at 3:05 PM, Stéphane Ducasse > > > wrote: > > > > > > On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > > > > > > > Marcus, > > > > I can't install Seaside on Pharo 1.1(*) but then i'll try again at home. > > > > > > > > It isn't my point to compare Pharo to Squeak performance but I used > > > > Squeak to test this particular situation. > > > > > > > > Thank you, > > > > > > > > Facu > > > > > > > > (*) it's very slow to write the log taking minutes to complete the > > > > instalation > > > > > > which log? > > > > > > Stef > > > > > > > > > > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker > > > > wrote: > > > > > > > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > > > > > > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > > > > > > > >> Lukas, > > > > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and > > > > >> Pharo. > > > > >> > > > > >> But I test it on the same machine with Squeak 4.1 RC4 and it go very > > > > >> very fast > > > > >> to open de smalltalk debugger. > > > > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you > > > > >> note that too or it's only my sensations? > > > > >> > > > > > > > > > > Did you check with Pharo 1.1? > > > > > > > > > > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > > > > > > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 > > > > > speed-wise, but Pharo 1.1 > > > > > > > > > > > > > My theory for your bug is that it's this: > > > > > > > >http://code.google.com/p/pharo/issues/detail?id=860 > > > > > > > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was > > > > supposed to be released > > > > "very soon". > > > > > > > >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 > > > > > > > > > > > > > > > > -- > > > > Facundo Vozzi > > > > InfOil S.A. > > > > Project Leader > > > > (+54-11) 4542- x108 > > > > fvo...@infoil.com.ar > > > > ___ > > > > 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
[Pharo-project] [update 1.1] #11313
11313 - - Issue 2292: add #next:putAll:startingAt: to SocketStream - Issue 2291: Morph>> showActions ends up with a DNU - Issue 2304: compileSilently: without classified: is more practical for tests - Issue 2303: CompledMethodTrailerTest -> CompiledMethodTrailerTest and other fixes 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] Open Pharo debugger from a Seaside wallback
As Stef said...do you have some anti-virus program like nod-32 or something like that ? in such case you should exclude the directory where you have your Pharo image. On Mon, Apr 12, 2010 at 5:52 PM, Stéphane Ducasse wrote: > > On Apr 12, 2010, at 10:46 PM, Facundo Vozzi wrote: > > > It continues taking longer 15 seconds on 1.1 too, there isn't change. I > will try to compare with Squeak looking for the possible problem and its > solution. > > > > nobody has the same problem? > > No and this is strange because 1.1 got a lot of the stream changes that > made squeak faster. > > > > > Thank you, > > Facu > > > > On Mon, Apr 12, 2010 at 5:28 PM, Stéphane Ducasse < > stephane.duca...@inria.fr> wrote: > > > > On Apr 12, 2010, at 10:18 PM, Facundo Vozzi wrote: > > > > > Stef, > > > I'm using Pharo 1.0 RC2 with Seaside 2.8.4 and all is fine but it took > over 15 seconds open a smalltalk debugger from a Seaside wallback. It was > the reason of my first mail. > > > I tried with Squeak 4.1 RC4, to discard a network configuration problem > at operative system level, and i don't have the problem. It takes 1 second > to open the debugger. > > > Then, Marcus ask to me if i had the same problem with > "PharoCore-1.1-11301-UNSTABLE", at that time I download it, installed > Seaside and try again. To Install Seaside took to me over 20 minutes but I > had been instaled it on Pharo 1.0 and was been fine. > > > > ok so with 1.1 this is working? > > There were a **lot** of changes in 1.1. We will release shortly after 1.0 > and much much faster :) > > > > > Is it more clear now ?. Please, sorry for my poor English. > > > > Don;t worry. write simple sentences and we will understand you. > > > > > > Facu > > > > > > > > > On Mon, Apr 12, 2010 at 5:03 PM, Stéphane Ducasse < > stephane.duca...@inria.fr> wrote: > > > This is really strange. Can you describe your setup? Do you have an > antivirus? And with Squeak you do not have that behavior? > > > We are loading larger code than seaside in Pharo and we do not have > this problem. > > > So I would really like to understand. Could you post your image > somewhere? > > > > > > Stef > > > > > > On Apr 12, 2010, at 9:27 PM, Facundo Vozzi wrote: > > > > > > > Stef, > > > > It took to me over 20 minutes to complete the Seaside 2.8 > installation and when I interrupted it the debugger opened when the system > was writting the pharoXXX.changes always but I couldn't check what is > happening. > > > > > > > > I will check it again. > > > > > > > > Facu > > > > > > > > ps: I refered to pharoXXX.changes as "log" because of Visual > Smalltalk where the "changes" are called changes.log, excuse me. > > > > > > > > On Mon, Apr 12, 2010 at 3:05 PM, Stéphane Ducasse < > stephane.duca...@inria.fr> wrote: > > > > > > > > On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > > > > > > > > > Marcus, > > > > > I can't install Seaside on Pharo 1.1(*) but then i'll try again at > home. > > > > > > > > > > It isn't my point to compare Pharo to Squeak performance but I used > Squeak to test this particular situation. > > > > > > > > > > Thank you, > > > > > > > > > > Facu > > > > > > > > > > (*) it's very slow to write the log taking minutes to complete the > instalation > > > > > > > > which log? > > > > > > > > Stef > > > > > > > > > > > > > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker < > marcus.den...@inria.fr> wrote: > > > > > > > > > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > > > > > > > > > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > > > > > > > > > >> Lukas, > > > > > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and > Pharo. > > > > > >> > > > > > >> But I test it on the same machine with Squeak 4.1 RC4 and it go > very very fast > > > > > >> to open de smalltalk debugger. > > > > > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did > you note that too or it's only my sensations? > > > > > >> > > > > > > > > > > > > Did you check with Pharo 1.1? > > > > > > > > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE.1.zip > > > > > > > > > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 > speed-wise, but Pharo 1.1 > > > > > > > > > > > > > > > > My theory for your bug is that it's this: > > > > > > > > > >http://code.google.com/p/pharo/issues/detail?id=860 > > > > > > > > > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was > supposed to be released > > > > > "very soon". > > > > > > > > > >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 > > > > > > > > > > > > > > > > > > > > -- > > > > > Facundo Vozzi > > >
[Pharo-project] about sorted
Hi levente may be I did a mistake when I integrated some of your changes. I did not look at Squeak before posting (because I'm dead). Now in latest 1.1 several tests for sorted failed because nil is valued while it should not. I read the code and I do not really like the aBlockOrNil. I would prefer to have block all the time. I was wondering if your original idea was to use nil and if this is the case why you thought it was better than just passing a block. sorted "Return a new sequenceable collection which contains the same elements as self but its elements are sorted in ascending order using the #'<=' operator." ^self sorted: [:a :b| a <= b ] 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] pharo on sparc solaris
Hi Tudor, It's been years since I've used them, but you may try a "free" Solaris shell account at http://www.polarhome.com/ or installing your own Solaris Appliance on a VMWare Server : http://wotho.ethz.ch/ESX_solaris/Install_Solaris_on_ESX.html http://blogs.sun.com/exoteric/entry/installing_solaris_10_5_08 Cheers, Hernán 2010/4/12 Tudor Girba : > Hi, > > I would need to run a Pharo RC4 image on a Sparc Solaris station. Looking on > the www.squeakvm.org/unix/, I see that there is no VM for such a station, > only for Intel Solaris. > > Unfortunately, I also do not have access to any compiling tools on this > machine (it's a server). Can anyone help me with this issue? > > The machine says it is: > $ uname -a > SunOS ejpdxa9017 5.10 Generic_142900-03 sun4v sparc > SUNW,SPARC-Enterprise-T5220 > > > Cheers, > Doru > > -- > www.tudorgirba.com > > "To lead is not to demand things, it is to make them happen." > > > > > ___ > 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 sorted
On Mon, 12 Apr 2010, Stéphane Ducasse wrote: Hi levente may be I did a mistake when I integrated some of your changes. I did not look at Squeak before posting (because I'm dead). Now in latest 1.1 several tests for sorted failed because nil is valued while it should not. I read the code and I do not really like the aBlockOrNil. aBlockOrNil is a bit misleading, because it can be anything that understands #value:value: or it can be nil. This means that the following binary selectors can be used (if you integrated my changes) instead of blocks: #<= #>= #< #> (or whatever you define :)). Using nil is not my idea, I took it from SortedCollection. I would prefer to have block all the time. I was wondering if your original idea was to use nil and if this is the case why you thought it was better than just passing a block. nil is only used for better performance. Since most of the time you only want to sort by <=. Here is a simple benchmark which do the same thing, but uses 3 different "sortBlocks": | array | array := (1 to: 10) asArray shuffle. [ array sorted: nil ] bench "===> 4.782781984854524 per second.". [ array sorted: [ :a :b | a <= b ] ] bench "===> 1.496445940890385 per second.". [ array sorted: #<= ] bench "===> 2.740262282247015 per second." Levente sorted "Return a new sequenceable collection which contains the same elements as self but its elements are sorted in ascending order using the #'<=' operator." ^self sorted: [:a :b| a <= b ] 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] Fwd: Scamper
Thank you John ! Commit what you want :) I forward to pharo mailing list, people may be interested. http://www.squeaksource.com/LaurentLSandbox.html Cheers, Laurent Laffont -- Forwarded message -- From: John McKeon Date: Tue, Apr 13, 2010 at 4:45 AM Subject: Scamper To: laurent.laff...@gmail.com Hello Laurent I hope you won't mind, I made a change to Scamper and posted it to your repository. I set the testWrap: method to return true. Its seems to give a big improvement to the readability of most pages that I have visited with it. Thanks for your work on it, it is working quite well Warm regards John McKeon -- http://jmck.seasidehosting.st ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
