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

Re: [Pharo-project] [Pharo-users] Breakpoints in Pharo

by Mariano Martinez Peck

Thanks for this feature, is really useful. I've just checked latest OB where this should be integrated. I saw a "toogle breakpoint". You area talking about, aren't you? In addition, it would be nice to have such think also in the context menu in the code panel. So you don't need to go to the method and right click there. cheers Mariano On Mon, Sep 20, 2010 at 8:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Did you see that there was a breakPoint class and BreakPointManager? > > Stef > > On Sep 20, 2010, at 12:14 PM, S Krish wrote: > > > > http://skrishnamachari.wordpress.com/2010/09/20/debugger-point-in-pharo-cod… > > > > Unit tests from the browser do this automatically for now.. > > > > Any corrections and inputs are welcome.. it will help in becoming that > bit more productive on Pharo.. > > > > -Skrish > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Sept. 27, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Levente Uzonyi

On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: > IF you take a 1.1 core and just load OCompletion: > > MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907 > > If you load OCompletion and the rest of the dev image: > > MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137 > > > However, IN pharo dev 1.0 it is > > MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405 > > > sooo.... ???? > > something has changed? As I said, SortedCollection is not suitable for this kind of usage. If you have n classes in the system, the method takes O(n^2) time. I have already fixed this, though it's not available yet. Using the Pharo 1.1 OneClick image I get these values for [ECContextTest new testUntypedVarsOnly] timeToRun : Old: 28227 New: 1241 Levente > > cheers > > Mariano > > > On Mon, Sep 27, 2010 at 9:30 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> In a plain ECompletion image the code >> >>> [ Smalltalk environment keysDo: >>> [ :each | >>> selectors add: (ECGlobalEntry >>> contents: each >>> type: #globalVar) ]. >> >> takes around 30 milliseconds to evaluate. >> >> Lukas >> >> On 27 September 2010 16:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >>> mariano can you open a bug entry. >>> >>> Stef >>> On Sep 26, 2010, at 6:21 PM, Mariano Martinez Peck wrote: >>> >>>> Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev >> image. If I just take a core image, load OCompletion and run tests, they >> take a lot of time, not acceptable. >>>> >>>> Now....if I build a Dev image (with OB, RB, etc) and at the end I try to >> run OCompletion tests, the tests takes HOURS. The image seems frozen, but >> actually is working. If I interrupt I see the problem is in >>>> >>>> ECUntypedModel >> initializeSelectors >>>> >>>> the part of >>>> >>>> >>>> [ Smalltalk environment keysDo: >>>> [ :each | >>>> selectors add: (ECGlobalEntry >>>> contents: each >>>> type: #globalVar) ]. >>>> >>>> >>>> takes a lot of time >>>> >>>> and it seems related to "ECPreferences caseSensitive" and >> "ECUntypedModel >> resetSelectors" >>>> >>>> I don't know what else to say. To reproduce, take a PharoCore 1.1 and >> evaluate: >>>> >>>> Gofer new >>>> squeaksource: 'MetacelloRepository'; >>>> package: 'ConfigurationOfOCompletion'; >>>> load. >>>> >>>> (ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests' >>>> >>>> Then, run all the tests inside OCompletionTests. You will see that after >> running some threads....it will look like frozen. There, do an interrupt and >> analize. >>>> >>>> IF you do that for a Dev image, it takes muuuuch more. I guess this is >> because "Smalltalk environment keys" will have muuuuuch more elements than a >> simple core. >>>> >>>> Anyway, help is appreciated. >>>> >>>> Cheers >>>> >>>> Mariano >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> 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 >> >

Sept. 27, 2010

Re: [Pharo-project] After loading a package...all changes with "revision changed"

by Mariano Martinez Peck

Gary, BWT, it would be nice to have a way to filter (hde) all those methods as "revision changed" when seeing the changes. After that, I am able to see only the really changed methods :) On Mon, Sep 27, 2010 at 10:42 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > 2010/9/26 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > > We had a similar problem in squeaknos package, but just for some kind of >> classes. It was caused by having an initialize class method in classes >> derived from ExternalStructure, maybe it's because of the same reason? look >> there, you may get some answers. >> >> > Thanks. It is good to know I am not the only one. This bug is REAAAAALY > annoying since you cannot see your changes. > > I've checked and I have no #initialize at class level :( > > The only thing I found is class side #new implementd something like: > > new > > ^super new initialize. > > can this be the problem? > > where could I put a halt to see the problem ? > > thanks in advance > > mariano > > > >> regards, >> javier. >> >> 2010/9/26 Norbert Hartl <norbert(a)hartl.name> >> >> FYI I encountered the same problem in gemstone. The only thing I know is >>> that all loaded packages were created in pharo that showed this behaviour. >>> It didn't show up in a reproducable manner and some packages were clean >>> again after a few package updates. And for some month now I didn't see it. >>> >>> Norbert >>> >>> >>> Am 25.09.2010 um 21:12 schrieb Mariano Martinez Peck < >>> marianopeck(a)gmail.com>: >>> >>> >>> >>> On Sat, Sep 25, 2010 at 9:02 PM, StÃ©phane Ducasse <<stephane.ducasse(a)inria.fr> >>> stephane.ducasse(a)inria.fr> wrote: >>> >>>> >>>> On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote: >>>> >>>> > Hi. I am having a probem with Glorp and I really have no idea what can >>>> be. The problem is that I load the package Glorp and just after loading, I >>>> do a "changes" in the MC Browser and I see a lot of classes with a lot of >>>> changes and all of them like "revison changed". This is annoying since it >>>> doesn't let me easily see what I have really changed. >>>> > >>>> > To reproduce: >>>> > >>>> > - Load the package "Glorp" from >>>> <http://www.squeaksource.com/SqueakDBX> >>>> http://www.squeaksource.com/SqueakDBX >>>> > - Open a MC Browser, select Glorp package and press the "Changes" >>>> button agains the ss repo. And you will see :) >>>> >>>> May be the image used to save the package got a problem and changed the >>>> timestamp of the methods. >>>> So when you merge you get changed methods. >>>> >>> >>> I've just tried commiting and load them in a clean image...same problem. >>> >>> And if it were what you say...is there a solution? >>> >>> thanks >>> >>> mariano >>> >>> >>>> >>>> > >>>> > Any help is really appreaciated. >>>> > >>>> > Thanks >>>> > >>>> > Mariano >>>> > _______________________________________________ >>>> > Pharo-project mailing list >>>> > <Pharo-project(a)lists.gforge.inria.fr> >>>> Pharo-project(a)lists.gforge.inria.fr >>>> > <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> <Pharo-project(a)lists.gforge.inria.fr> >>>> Pharo-project(a)lists.gforge.inria.fr >>>> <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Sept. 27, 2010

Re: [Pharo-project] After loading a package...all changes with "revision changed"

by Mariano Martinez Peck

2010/9/26 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > We had a similar problem in squeaknos package, but just for some kind of > classes. It was caused by having an initialize class method in classes > derived from ExternalStructure, maybe it's because of the same reason? look > there, you may get some answers. > > Thanks. It is good to know I am not the only one. This bug is REAAAAALY annoying since you cannot see your changes. I've checked and I have no #initialize at class level :( The only thing I found is class side #new implementd something like: new ^super new initialize. can this be the problem? where could I put a halt to see the problem ? thanks in advance mariano > regards, > javier. > > 2010/9/26 Norbert Hartl <norbert(a)hartl.name> > > FYI I encountered the same problem in gemstone. The only thing I know is >> that all loaded packages were created in pharo that showed this behaviour. >> It didn't show up in a reproducable manner and some packages were clean >> again after a few package updates. And for some month now I didn't see it. >> >> Norbert >> >> >> Am 25.09.2010 um 21:12 schrieb Mariano Martinez Peck < >> marianopeck(a)gmail.com>: >> >> >> >> On Sat, Sep 25, 2010 at 9:02 PM, StÃ©phane Ducasse <<stephane.ducasse(a)inria.fr> >> stephane.ducasse(a)inria.fr> wrote: >> >>> >>> On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote: >>> >>> > Hi. I am having a probem with Glorp and I really have no idea what can >>> be. The problem is that I load the package Glorp and just after loading, I >>> do a "changes" in the MC Browser and I see a lot of classes with a lot of >>> changes and all of them like "revison changed". This is annoying since it >>> doesn't let me easily see what I have really changed. >>> > >>> > To reproduce: >>> > >>> > - Load the package "Glorp" from >>> <http://www.squeaksource.com/SqueakDBX> >>> http://www.squeaksource.com/SqueakDBX >>> > - Open a MC Browser, select Glorp package and press the "Changes" >>> button agains the ss repo. And you will see :) >>> >>> May be the image used to save the package got a problem and changed the >>> timestamp of the methods. >>> So when you merge you get changed methods. >>> >> >> I've just tried commiting and load them in a clean image...same problem. >> >> And if it were what you say...is there a solution? >> >> thanks >> >> mariano >> >> >>> >>> > >>> > Any help is really appreaciated. >>> > >>> > Thanks >>> > >>> > Mariano >>> > _______________________________________________ >>> > Pharo-project mailing list >>> > <Pharo-project(a)lists.gforge.inria.fr> >>> Pharo-project(a)lists.gforge.inria.fr >>> > <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> <Pharo-project(a)lists.gforge.inria.fr> >>> Pharo-project(a)lists.gforge.inria.fr >>> <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Igor Stasenko

On 27 September 2010 22:10, Levente Uzonyi <leves(a)elte.hu> wrote: > On Mon, 27 Sep 2010, Johan Brichau wrote: > >> >> On 27 Sep 2010, at 14:37, Schwab,Wilhelm K wrote: >> >>> "Works fine" is a value judgment that can cut both ways: one could also >>> argue that VW lacks a useful optimization of literals. Â Non-literal strings >>> should do what you want. >> >> I wonder how useful the optimization is, actually. >> Probably not many (if any) methods will use the same literal multiple >> times and count on the compiler to optimize them into the same literal. > > I think this is from the 80's or 90's where this could save some memory. > According to my calculations in Squeak 4.2 with some extra packages loaded > it saves at least 36591 bytes (object size + 1 slot in the literal array), > which is only 0.79 bytes / method. > Well, you can save a bit more, if you scan a whole image literals and unify them. This could be userful for tidying up the image size. > > Levente > >> >> Inversely, I have never run into that issue myself either, until I was >> just testing those little snippets for the students. Or... at least, I think >> I never have :-) >> >> Johan >> _______________________________________________ >> 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.

Sept. 27, 2010

[Pharo-project] pharo sprint / moose dojo - october 23-24, bern

by Tudor Girba

Hi, We will organize a joint Pharo sprint / Moose dojo during October 23-24, in Bern (at the Software Composition Group, University of Bern). Some action points are mentioned on the dedicated page (of course, other ideas and interests are welcome as well): http://www.moosetechnology.org/events/2010-10-22-dojo For planning purposes, please let me know if you will attend. Cheers, Doru p.s. In case it is of interest, on October 22, we also have CHOOSE Forum 2010 in Bern, an event on the topic of Domain-Specific Engineering where, among others we'll learn about the role of Smalltalk :) http://choose.s-i.ch/events/forum2010 -- www.tudorgirba.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Sept. 27, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Mariano Martinez Peck

IF you take a 1.1 core and just load OCompletion: MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907 If you load OCompletion and the rest of the dev image: MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137 However, IN pharo dev 1.0 it is MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405 sooo.... ???? something has changed? cheers Mariano On Mon, Sep 27, 2010 at 9:30 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > In a plain ECompletion image the code > > > [ Smalltalk environment keysDo: > > [ :each | > > selectors add: (ECGlobalEntry > > contents: each > > type: #globalVar) ]. > > takes around 30 milliseconds to evaluate. > > Lukas > > On 27 September 2010 16:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > mariano can you open a bug entry. > > > > Stef > > On Sep 26, 2010, at 6:21 PM, Mariano Martinez Peck wrote: > > > >> Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev > image. If I just take a core image, load OCompletion and run tests, they > take a lot of time, not acceptable. > >> > >> Now....if I build a Dev image (with OB, RB, etc) and at the end I try to > run OCompletion tests, the tests takes HOURS. The image seems frozen, but > actually is working. If I interrupt I see the problem is in > >> > >> ECUntypedModel >> initializeSelectors > >> > >> the part of > >> > >> > >> [ Smalltalk environment keysDo: > >> [ :each | > >> selectors add: (ECGlobalEntry > >> contents: each > >> type: #globalVar) ]. > >> > >> > >> takes a lot of time > >> > >> and it seems related to "ECPreferences caseSensitive" and > "ECUntypedModel >> resetSelectors" > >> > >> I don't know what else to say. To reproduce, take a PharoCore 1.1 and > evaluate: > >> > >> Gofer new > >> squeaksource: 'MetacelloRepository'; > >> package: 'ConfigurationOfOCompletion'; > >> load. > >> > >> (ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests' > >> > >> Then, run all the tests inside OCompletionTests. You will see that after > running some threads....it will look like frozen. There, do an interrupt and > analize. > >> > >> IF you do that for a Dev image, it takes muuuuch more. I guess this is > because "Smalltalk environment keys" will have muuuuuch more elements than a > simple core. > >> > >> Anyway, help is appreciated. > >> > >> Cheers > >> > >> Mariano > >> _______________________________________________ > >> 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 > > > > > > -- > 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 >

Sept. 27, 2010

Re: [Pharo-project] About installing NativeBoost in Linux

by Igor Stasenko

On 27 September 2010 17:36, Fernando olivero <fernando.olivero(a)usi.ch> wrote: > Hi Igor, great news that NativeBoost is available in Linux. > > In the installation page, in steps 1 and 2 you specify how to create a plugin/vm . > The outcome is the vm for linux with NativeBoost support? > Its not a full instruction how to build a vm. First, you must download the sources and have an image with vmmaker. This is described on http://squeakvm.org/unix/devel.html page. Then you need to download small patch from NB site svn checkout http://nativeboost.googlecode.com/svn/trunk/ nativeboost-read-only and copy patched files to unix platform-specific sources. In image with VMMaker, you can load NBInstaller , and then do NBInstaller installPlugin. Before generating VM/plugins source code in vmmaker, don't forget about setting target platform for plugin: NativeBoostPlugin setTargetPlatform: (NativeBoostConstants linux32PlatformId). Now open VMMaker, include NativeBoostPlugin into internal plugins list, and you ready to build a VM. Yes, building VM is somewhat tedious procedure, but once you have everything set up, it don't takes much time anymore. > Is there a prebuilt vm for linux available? > Yes, on my PC :) but i don't know how to package it. > Fernando > > > pd: When would it be available for Mac OSX? How can we help? > Well, since i don't have Mac right now, i can't build & test VM and plugin. I just added a necessary patch to platforms/Mac OS/sqMacMemory.c in plugin's svn source at google code, which is needed to make plugin execute native code. (Make sure that you building plugin with Mac platform id). The rest of stuff should be done at image level: - create a subclass of NativeBoost, like NativeBoostMac32 and implement missing functionality. You can use NativeBoostLinux32 as a guide to follow. I think that for someone, who knows mac platforms well, it could take maybe a day to make a working port. > > > _______________________________________________ > 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.

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Sean P. DeNigris

Johan Brichau-2 wrote: > > where did I say that? > I thought that's what you meant by "imho the optimization yields a wrong semantics." If there is no guarantee on whether or not two strings with the same value are the same object, what is wrong with the result you observed? Sean -- View this message in context: http://forum.world.st/a-a-true-tp2715066p2716156.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Alexandre Bergel

> I think this is from the 80's or 90's where this could save some memory. According to my calculations in Squeak 4.2 with some extra packages loaded it saves at least 36591 bytes (object size + 1 slot in the literal array), which is only 0.79 bytes / method. Wow! Thanks Levente for sharing this with us. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 27, 2010