April 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Inserting halts using pragmas?

by Marcus Denker

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.

April 12, 2010

Re: [Pharo-project] fixing underscores in a trivial manner thanks to SmalllintChecker and Lukas!

by StÃ©phane Ducasse

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! >

April 12, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by Peter Hugosson-Miller

On Mon, Apr 12, 2010 at 1:43 PM, Igor Stasenko <siguctua(a)gmail.com> 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 <leves(a)elte.hu> 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(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)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

April 12, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by Igor Stasenko

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 <leves(a)elte.hu> 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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 12, 2010

Re: [Pharo-project] Inserting halts using pragmas?

by Fernando olivero

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 12, 2010

Re: [Pharo-project] Inserting halts using pragmas?

by StÃ©phane Ducasse

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 12, 2010

[Pharo-project] [ANN] Pharo Windows VM 4.0.2

by Torsten Bergmann

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.ht… [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

April 12, 2010

Re: [Pharo-project] news about 1.0

by Henrik Johansen

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

April 12, 2010

Re: [Pharo-project] Inserting halts using pragmas?

by Peter Hugosson-Miller

On Mon, Apr 12, 2010 at 11:11 AM, Lukas Renggli <renggli(a)gmail.com> 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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 12, 2010

Re: [Pharo-project] Inserting halts using pragmas?

by Lukas Renggli

> 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

April 12, 2010