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

Re: [Pharo-project] [Vm-dev] Fwd: is it possible to know the memory occupation (bytes) of an object?

by David T. Lewis

On Wed, Apr 28, 2010 at 11:26:54AM -0700, Andreas Raab wrote: > > BTW, SpaceTally>>spaceForInstancesOf:withInstanceCount: has the correct > computation (except for 64 bit :-) Somebody should do something about that one of these days, so I put it on Mantis: http://bugs.squeak.org/view.php?id=7518 Dave

April 29, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Mariano Martinez Peck

On Wed, Apr 28, 2010 at 11:28 PM, Alexandre Bergel < alexandre.bergel(a)inria.fr> wrote: > It is a bit more subtle than that. > > If I take a Core 1.1, and doit: ConfigurationOfPharo project lastVersion > load > Then I get a warning coming from OBSearchBrowser class related to the world > menu registration. > > Yes, I noticed that. > At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. > > Doing twice a proceed resume the loading. > It then blocks on SHWorkspace, for the very same reason. > > yes.. > After having manually fixed the Nile problem (isInMemory), Pharo loads > well. ProfStef is open. > > I did the same... > OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means that > OmniBrowser is loaded twice. Is this the intended behavior? > > I saw directly the final versions: 469 and 116. I didn't notice it was first trying to load 458 and 112. I know that in such conflict, Metacello will load the last one, but I didnt know that it actually LOADS also the previous versions. I thought that it only loads the final version, not both of them. In such case, I think it is a metacello bug. See this link: http://groups.google.com/group/metacello/browse_thread/thread/e8a08b3ed1a9b… Dale, can you help us? Thanks Mariano > Alexandre > > > > On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote: > > >> >> On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel <alexandre(a)bergel.eu> >> wrote: >> Hi! >> >> I am now trying to make ConfigurationOfPharo load the last version of >> OmniBrowser. >> If I do in a fresh core: ConfigurationOfPharo project lastVersion load >> >> Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. >> >> >> No. If you take a PharoCore 1.0 OR 1.1 and evaluate ConfigurationOfPharo >> project lastVersion load >> >> It installs OmniBrowser-lr.469 and OB-Morphic-lr.116 >> which are correct as those are defined in ConfigurationOfOmniBrowser >> version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB. >> >> >> The loading blocks on the deprecated warning (yes, the registration in the >> World menu). >> In ConfigurationOfPharo>>version11: I have >> >> spec >> project: 'PharoNonCorePackages' with: >> '1.1.0'; >> project: 'NewInspector' with: '1.1'; >> project: 'Shout' with: '1.0'; >> project: 'Shout Tests' with: '1.0'; >> project: 'OCompletion' with: '1.1'; >> project: 'OCompletion Tests' with: '1.1'; >> project: 'OB Dev' with: '1.1.3'; >> project: 'OB Dev Tests' with: '1.1.3'; >> ... >> >> I therefore assume that the version 1.1.3 of OmniBrowser is loaded. >> 1.1.3 is indeed the last version specified in ConfigurationOfOmniBrowser: >> ConfigurationOfOmniBrowser project lastVersion >> => ~1.1.3 [ConfigurationOfOmniBrowser] >> >> But I evaluate: ConfigurationOfOmniBrowser project lastVersion load >> Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and >> OmniBrowser-lr.469 are loaded. >> >> >> Exactly. And that's correct. Those are the versions that are defined in >> ConfigurationOfOmnibrowser 1.1.3 >> >> I find it is very hard to keep track of what is actually loaded. >> >> >> I don't understand your problem. Everything seems to work as exepected. >> >> >> I haven't closely followed the evolution of Metacello, but there is not a >> way to say: >> spec project: 'OB Dev' with: 'lastestVersion' >> >> Yes. Don't put any version. If you don't define a version, metacallo will >> load the last one. >> >> project: 'OB Dev'; >> >> or even remove that line from the version method. Even more, if you want >> ALL the last, you can load the baseline instead of the version. In such >> case, as you don't specify any version, it will download all the last ones. >> >> Cheers >> >> Mariano >> >> >> Or Something? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> 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 >

April 28, 2010

Re: [Pharo-project] ConfigurationOfPharo

by Mariano Martinez Peck

Torsten: I saw you changed version 1.0 of ConfigurationOfOmniBrowser to change the version of OmniBrowser package. However, I don't think this is a good thing. When a version is released, it should be "modifieded". For any reason. The good behavior, from my point of view, in this case is to put bless the 1.0 version as broken and create a new version 1.0.1 with such change/fix What do you think ? Cheers Mariano On Tue, Apr 27, 2010 at 11:41 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Apr 27, 2010 at 7:15 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Hi Mariano, >> >> now he complains about "OmniBrowser-DamineCassou.462" >> (which comes from 1.0 of ConfigurationOfAutomaticMethodCategorizer >> which loads 1.0 of ConfigurationOfOmniBrowser >> which loads OmniBrowser-DamienCassou.462) >> >> Looks like this conflicts with "OmniBrowser-lr.469" >> which is noted in version 1.1.3 of ConfigurationOfOmniBrowser >> >> Looks like a conflict: >> You now use 1.1.3 of ConfigurationOfOmniBrowser, but the >> ConfigurationOfAutomaticMethodCategorizer that you use in >> ConfigurationOfPharo still points to 1.0 of ConfigurationOfOmniBrowser. >> >> > Yes, but it doesn't matter. In such situation (conflict), Metacello will > load the latest version, in this case, 1.1.3. > I cannot mantain all configurations. If you think > ConfigurationOfAutomaticMethodCategorizer should have 1.1.3 instead of 1.0, > just do it. > > > >> Lesson learned: take care when you edit configs since you may break other >> peoples code. >> > > I do take care, but I cannot test all configurations. Even more, when they > are not stable releases. > In addition, I didn't break anything: > > OmniBrowser-DamienCassou.462 > > existed at the point I did the configuration. Now, if I browse the > repository http://source.wiresong.ca/ob > I don't see it. So, maybe Colin removed that version and put Lukas ones and > that's why it is failing. > Colin, do you know if this was what happened ? > > >> So I would not call this a reproducable Pharo 1.0 Release ;) >> >> > I don't understand. Pharo 1.0 is completly reproducable. I take a PharoCore > 1.0 I avaluate: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfPharo'; > load. > > ((Smalltalk at: #ConfigurationOfPharo) project version: '1.0-10517') > perform: #silently: with: true; perform: #load. > > > And I have the PharoDev 1.0 stable release in perfect state and without any > problem. > > Cheers > > Mariano > > > >> >> Just try in a clean 1.0 core image: >> >> -------------------------- >> Gofer new >> squeaksource: 'MetaSource'; >> package: 'ConfigurationOfMetaSource'; >> load. >> >> ((Smalltalk at: #ConfigurationOfMetaSource) project version: '1.0-alpha1') >> load >> -------------------------- >> -- >> 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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

April 28, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Henrik Sperre Johansen

On 28.04.2010 23:39, Alain Plantec wrote: > Henrik Sperre Johansen a Ã©crit : >> >> PS. I actually like the Squeak preference pragma. In 99% of the >> cases, it is sufficient, and you can place it directly as metadata in >> an existing accessor method, rather than having to define a new >> method simply for defining a method whose only difference from 30 >> others is what variable it stores into and reads from. > no, a package can group all its setting declarations in one method. > Alain I know :) My point was rather the pragmas in Squeak are more closely coupled with the point it is actually defined, in that you defined the pragma itself in the accessor method for the variable, rather than having 1-N declarations in a single method, pointing to 1-N places where those settings values can actually be found. Cheers, Henry

April 28, 2010

Re: [Pharo-project] status of i18n for Pharo

by Henrik Sperre Johansen

On 28.04.2010 23:08, StÃ©phane Ducasse wrote: > if you extract the code from Etoy .... > we are open you know :) > > On Apr 28, 2010, at 10:35 PM, Hilaire Fernandes wrote: > >> I was thinking more about something like the Gettext support as found in Etoys. >> >> Hilaire I *think* I remember Bert mentioning interest in extracting the code for inclusion in Squeak some time ago, not 100% sure though. There hasn't been a mention of it on the Pharo list so far though, so I wouldn't sit around and wait for someone else to port it if I really wanted it... :) i.e. The main reason it's not in Pharo is probably more of a lack of interest than anything against having such functionality. Cheers, Henry

April 28, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Alain Plantec

Henrik Sperre Johansen a Ã©crit : > > PS. I actually like the Squeak preference pragma. In 99% of the cases, > it is sufficient, and you can place it directly as metadata in an > existing accessor method, rather than having to define a new method > simply for defining a method whose only difference from 30 others is > what variable it stores into and reads from. no, a package can group all its setting declarations in one method. Alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 28, 2010

Re: [Pharo-project] "The World of Smalltalk" launch

by Julian Fitzell

On Wed, Apr 28, 2010 at 10:01 PM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > Seeing a -4 reminded me of the dreadful GSOC voting debacle so I am glad it > has nothing to do with that. > :) Nice work Geert... that's a very attractive site with just a nice minimal set of information cleanly presented. Julian

April 28, 2010

Re: [Pharo-project] Virtual Pharo sprints

by Henrik Sperre Johansen

On 28.04.2010 21:11, StÃ©phane Ducasse wrote: > tell us how what would help you? > I thought about logging on the irc channel and mentioning who is fixing what. > We will start from around 13h. > > Stef I won't be available that early, I'm afraid :( I'll join after work though. Thought mostly of the possibility of online pair programming, and in that regard what software would need to be installed up front. If it's more of an "here's a list of issues in prioritized order, go fix" event, I'm ok with that :) Cheers, Henry

April 28, 2010

Re: [Pharo-project] ConfigurationOfPharo and OmniBrowser

by Alexandre Bergel

It is a bit more subtle than that. If I take a Core 1.1, and doit: ConfigurationOfPharo project lastVersion load Then I get a warning coming from OBSearchBrowser class related to the world menu registration. At that moment, OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. Doing twice a proceed resume the loading. It then blocks on SHWorkspace, for the very same reason. After having manually fixed the Nile problem (isInMemory), Pharo loads well. ProfStef is open. OmniBrowser-lr.469 and OB-Morphic-lr.116 are loaded. This means that OmniBrowser is loaded twice. Is this the intended behavior? Alexandre On 28 Apr 2010, at 11:40, Mariano Martinez Peck wrote: > > > On Wed, Apr 28, 2010 at 3:22 PM, Alexandre Bergel > <alexandre(a)bergel.eu> wrote: > Hi! > > I am now trying to make ConfigurationOfPharo load the last version > of OmniBrowser. > If I do in a fresh core: ConfigurationOfPharo project lastVersion load > > Then OmniBrowser-lr.458 and OB-Morphic-lr.112 are loaded. > > > No. If you take a PharoCore 1.0 OR 1.1 and evaluate > ConfigurationOfPharo project lastVersion load > > It installs OmniBrowser-lr.469 and OB-Morphic-lr.116 > which are correct as those are defined in ConfigurationOfOmniBrowser > version 1.1.2. And ConfigurationOfPharo 1.1 has 1.1.2 of OB. > > > The loading blocks on the deprecated warning (yes, the registration > in the World menu). > In ConfigurationOfPharo>>version11: I have > > spec > project: 'PharoNonCorePackages' with: > '1.1.0'; > project: 'NewInspector' with: '1.1'; > project: 'Shout' with: '1.0'; > project: 'Shout Tests' with: '1.0'; > project: 'OCompletion' with: '1.1'; > project: 'OCompletion Tests' with: > '1.1'; > project: 'OB Dev' with: '1.1.3'; > project: 'OB Dev Tests' with: '1.1.3'; > ... > > I therefore assume that the version 1.1.3 of OmniBrowser is loaded. > 1.1.3 is indeed the last version specified in > ConfigurationOfOmniBrowser: > ConfigurationOfOmniBrowser project lastVersion > => ~1.1.3 [ConfigurationOfOmniBrowser] > > But I evaluate: ConfigurationOfOmniBrowser project lastVersion load > Then the version OB-Morphic-lr.116, OB-Standard-lr.463 and > OmniBrowser-lr.469 are loaded. > > > Exactly. And that's correct. Those are the versions that are defined > in ConfigurationOfOmnibrowser 1.1.3 > > I find it is very hard to keep track of what is actually loaded. > > > I don't understand your problem. Everything seems to work as > exepected. > > > I haven't closely followed the evolution of Metacello, but there is > not a way to say: > spec project: 'OB Dev' with: 'lastestVersion' > > Yes. Don't put any version. If you don't define a version, metacallo > will load the last one. > > project: 'OB Dev'; > > or even remove that line from the version method. Even more, if you > want ALL the last, you can load the baseline instead of the version. > In such case, as you don't specify any version, it will download all > the last ones. > > Cheers > > Mariano > > > Or Something? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 28, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Henrik Sperre Johansen

On 28.04.2010 21:57, Hannes Hirzel wrote: > On 4/28/10, Henrik Sperre Johansen<henrik.s.johansen(a)veloxit.no> wrote: >> On 28.04.2010 17:47, Brent Pinkney wrote: >>> Hi all,+ >>> >>> Could those in the know comment on how this<...> proposal is (or is not) >>> consistent with the fundamental Smalltalk principles >>> that: >>> >>> 1. "an object is send a message and responds with an object" >>> 2. there is no other "magic" in the system. >>> >> Take 15 mins to read the code dealing with Pragma preferences, and you'd >> have your answer. >> The short answer is no, they just provide a different way of dynamically >> deciding what message you want to send. >> The closest equivalent would be the logic used to decide which >> ImageReadWriter subclass to actually use. >> >> Cheers, >> Henry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > Henry > > I took your piece of advice of using 15 minutes to check out what > Pharo pragma/method annotation wise and below is what I discovered. > You might want directly to jump to the end for 3 questions > > --Hannes > > OK, 15 minutes > > 1. *snip* > 8) Yes, sorry I didn't specify which images, I assumed you knew where they were :( (The age of the discussion can tell you one more thing: 1.0 was in beta a looooooong time :) ) The 15 minutes were meant for understanding how using pragmas adds no magic (at least not in the Smalltalk sense). In: http://forum.world.st/Fix-2329-Default-MC-Directory-Setting-td2019559.html#… , I wrote exactly where to find the code dealing with pragma discovery in both Pharo 1.1 and Squeak 4.1. > C. How do you want to handle the menus with pragmas? (It seems that > Pharo is not much further advanced in this area). > They are handled exactly the same way Preferences is handled. A PragmaCollector is told to find pragmas with a specific keyword. (#systemsettings or #worldmenu respectively for Settings and the World menu (currently the only dynamic menu in Pharo 1.1). For the methods discovered, you then: - for preferences: Pass in a preference builder to the method, which can then construct its preferences. - for menus: Pass in a menu builder to the method, which can then construct the menu items it needs. To the argument "But a builder decoupled from the method provides resistance to further change!" I say: How is that different from any of the many methods currently expecting as argument an instance of a class in base? If the base classes does indeed change, what would you rather see happening? a) An MNU or deprecated warning when trying to invoke the (now) invalid code? b) The code simply not doing what you expect it to? (ie. not adding menu items etc.) Yes, in b) you can still import old code and run it with no errors. That does not necessarily mean it does what you wanted it to do though. Cheers, Henry PS. I actually like the Squeak preference pragma. In 99% of the cases, it is sufficient, and you can place it directly as metadata in an existing accessor method, rather than having to define a new method simply for defining a method whose only difference from 30 others is what variable it stores into and reads from.

April 28, 2010