October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Hashed collection improvements: Some code

by Andres Valloud

(note that I mentioned Magma just for the sake of illustration for my argument... I do not know whether either approach will affect it) Nicolas Cellier wrote: > 2009/10/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> Martin >> >> are these changes related to the graphs you sent? >> I will have a look after my hospital check. >> Andres? Nicolas? >> Any feedback? >> Martin I imagine that I can package the changes :) >> >> >> Stef >> >> > > This has been pretty well explained by Martin and Andres. > The decision you have to make is : > > - choose Martin change, make speed improvment for most senders of > #identityHash, but eventually break a few senders and let package > maintainers fix it (example Magma) > - choose Andres change, assure 100% compatibility, let the > responsibility to package maintainers to use new message for improving > speed. > > In both cases, package maintainer might have to maintain different > branch for Squeak and Pharo, but I guess the solution would be adopted > soon in Squeak/trunk. > > I would tend to be conservative, but I recently took the opposite path > with #keys and #selectors in trunk, so I just can't give you my > personal preference, it's 50-50... > Whatever the choice, #identityHash usage is worth a review by package > maintainers anyway. > > Note that this is closely related to > http://bugs.squeak.org/view.php?id=1876 and > http://code.google.com/p/pharo/issues/detail?id=213 > Amazing the issue is still there when workarounds are known for so > long... So please do something! > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Oct. 30, 2009

Re: [Pharo-project] Hashed collection improvements: Some code

by Andres Valloud

Nicolas, Would you like Martin's approach better if the selector was #basicIdentityHash instead of #primIdentityHash? Is it a matter of naming only, or is there something else? Andres. Nicolas Cellier wrote: > After-thoughts: my opinion is: > Martin solution is more pragmatical : it is tailored for getting most > improvment with minimal change in system. > But formally, I prefer Andres design for it's clarity. > - I do not like the idea that #identityHash and #primIdentityHash do > behave differently > - #scaledIdentityHash does clearly express itself on the contrary > But that turns into german discussions ;) > > Nicolas > > 2009/10/29 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > >> 2009/10/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>> Martin >>> >>> are these changes related to the graphs you sent? >>> I will have a look after my hospital check. >>> Andres? Nicolas? >>> Any feedback? >>> Martin I imagine that I can package the changes :) >>> >>> >>> Stef >>> >>> >> This has been pretty well explained by Martin and Andres. >> The decision you have to make is : >> >> - choose Martin change, make speed improvment for most senders of >> #identityHash, but eventually break a few senders and let package >> maintainers fix it (example Magma) >> - choose Andres change, assure 100% compatibility, let the >> responsibility to package maintainers to use new message for improving >> speed. >> >> In both cases, package maintainer might have to maintain different >> branch for Squeak and Pharo, but I guess the solution would be adopted >> soon in Squeak/trunk. >> >> I would tend to be conservative, but I recently took the opposite path >> with #keys and #selectors in trunk, so I just can't give you my >> personal preference, it's 50-50... >> Whatever the choice, #identityHash usage is worth a review by package >> maintainers anyway. >> >> Note that this is closely related to >> http://bugs.squeak.org/view.php?id=1876 and >> http://code.google.com/p/pharo/issues/detail?id=213 >> Amazing the issue is still there when workarounds are known for so >> long... So please do something! >> >> Nicolas >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > . > >

Oct. 30, 2009

Re: [Pharo-project] Segmentation fault when starting pharo 1.0rc1 on Ubuntu 64bit server

by HernÃ¡n Morales Durand

Paul, You may verify if your Linux distribution has core dumping enabled: # ulimit -c unlimited and check if the directory where the VM resides is writeable. Once you run again the VM and see "Segmentation fault (core dumped)", You may search the dumped core with "file core" and run a gdb on it: $ gdb squeakvm core Inside gdb, the bt command will display a stack trace to see or mail out detailed information about your SIGSEGV. Cheers, HernÃ¡n 2009/10/29 Paul DeBruicker <pdebruic(a)gmail.com> > Hi - > > Has anyone successfully run a newer version of Pharo on either Ubuntu > 9.04 or Ubuntu 9.10 64 bit server? When I try to start the command > line simply says "Segmentation fault" and does not emit a stack > trace. The UUIDPlugin is named UUIDPlugin.bak. I am attempting to > use the latest versions of pharo, pharo sources and both the pharo vm > or squeak 3.11 vm from the pharo-project.org site. I have installed > ia32-libs and I do know that the latest pharo runs on Ubuntu Desktop > 9.04. > > If you have gotten it running, will you please send me the output of > > dkpg -l > > or a description of whatever you did to get it started? Thanks > > > Also, I'd be happy to attempt other solutions or provide more > information as I've tried what I know how to do and checked what I > know to check. > > Thanks > > Paul > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 29, 2009

Re: [Pharo-project] Segmentation fault when starting pharo 1.0rc1 on Ubuntu 64bit server

by Alain Plantec

Hi Paul, I'm using ubuntu 9.10 rc 64 (desktop version) since 7 days without any problem. Pharo run out of the box. I send my dpkg -l result to you in private. Cheers Alain Paul DeBruicker a Ã©crit : > Hi - > > Has anyone successfully run a newer version of Pharo on either Ubuntu > 9.04 or Ubuntu 9.10 64 bit server? When I try to start the command > line simply says "Segmentation fault" and does not emit a stack > trace. The UUIDPlugin is named UUIDPlugin.bak. I am attempting to > use the latest versions of pharo, pharo sources and both the pharo vm > or squeak 3.11 vm from the pharo-project.org site. I have installed > ia32-libs and I do know that the latest pharo runs on Ubuntu Desktop > 9.04. > > If you have gotten it running, will you please send me the output of > > dkpg -l > > or a description of whatever you did to get it started? Thanks > > > Also, I'd be happy to attempt other solutions or provide more > information as I've tried what I know how to do and checked what I > know to check. > > Thanks > > Paul > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Oct. 29, 2009

[Pharo-project] Segmentation fault when starting pharo 1.0rc1 on Ubuntu 64bit server

by Paul DeBruicker

Hi - Has anyone successfully run a newer version of Pharo on either Ubuntu 9.04 or Ubuntu 9.10 64 bit server? When I try to start the command line simply says "Segmentation fault" and does not emit a stack trace. The UUIDPlugin is named UUIDPlugin.bak. I am attempting to use the latest versions of pharo, pharo sources and both the pharo vm or squeak 3.11 vm from the pharo-project.org site. I have installed ia32-libs and I do know that the latest pharo runs on Ubuntu Desktop 9.04. If you have gotten it running, will you please send me the output of dkpg -l or a description of whatever you did to get it started? Thanks Also, I'd be happy to attempt other solutions or provide more information as I've tried what I know how to do and checked what I know to check. Thanks Paul

Oct. 29, 2009

Re: [Pharo-project] Abstract classes

by Alexandre Bergel

>> - SUnit will still have to implement its own #isAbstract to decide if >> a class should be runnable or just provide test templates. >> - Pier will still have to implement its own #isAbstract to decide >> if a >> class should show up in the GUI. >> - Magritte will still have to implement its own #isAbstract to decide >> if an arbitrary class can be instantiated from the GUI. >> - ... > NB, I am making this injection in the hope to disentangle to issue > of method > naming from the issue of the exact implementation of a general > #isAbstract > method (on which I agree with Lukas that it should be chosen > carefully). For now, I used #isAbstractClass Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 29, 2009

Re: [Pharo-project] Abstract classes

by Adrian Kuhn

Lukas Renggli <renggli@...> writes: > > In that case, we could have isAbstractClass or something else. I feel > > this information is important. > > What would be your isAbstract be useful for? > > - SUnit will still have to implement its own #isAbstract to decide if > a class should be runnable or just provide test templates. > - Pier will still have to implement its own #isAbstract to decide if a > class should show up in the GUI. > - Magritte will still have to implement its own #isAbstract to decide > if an arbitrary class can be instantiated from the GUI. > - ... Looks to me like these are application specific definitions of abstractness. Why not name them #isAbstractTest, #isAbstractComponent et cetera? While in the same time, there is a system-wide notion of abstract classes for which the generic #isAbstract should be reserver. NB, I am making this injection in the hope to disentangle to issue of method naming from the issue of the exact implementation of a general #isAbstract method (on which I agree with Lukas that it should be chosen carefully). cheers, AA

Oct. 29, 2009

Re: [Pharo-project] PhExample, because well designed tests expand on one another (Sneak Preview)

by Adrian Kuhn

George Herolyants <george.herolyants@...> writes: > 2009/10/29 Dennis Schetinin <chaetal@...>: > > Using symbols (i.e. "almost" constants) instead of explicitly telling what > > is happenning (sending a message)Â is more clean?! :) Ok then... (Not sure > > what you mean by "declarative" here) > > The message "given:" tells that to you. And by "declarative" I meant > the way you specify dependencies between your tests. If it was done > your way, test would be performed twice. If you use symbol, you don't > have to do it (haven't seen the library yet, just guessing :). Genau. By the principle of least surprise (of which I am also a big supporter) one would expect to just being able to call the perquisites. However in our case we need (and want) declarative dependencies, such that the framework may interfere between "producing" and "consuming" test. If tests would directly call one an other, as suggested, we cannot interfere. Being able to interfere "calls" between tests allows the framework to control of how tests are executed. We use this to skip tests that depend on failed tests. Eg, if you introduce a failure in ForExampleStack >> #shouldPush, what you get are not 4 failures but 1 failure and 3 expected failures! Also, interfering "calls" between tests allows the framework to choose a strategy for multiple dependencies. If two or more tests depend on the same produce we can: a) run the producer n times or b) run the producer once, cache the result and clone it n times. Currently we simply rerun the tests, but for the future it should be possible to choose between these two strategies. My experience from JExample is that rerunning is often faster, since initializing objects is much faster then cloning them, I expect this tradeoff might differ in Smalltalk though :) cheers, AA

Oct. 29, 2009

[Pharo-project] Author = TestRunner

by StÃ©phane Ducasse

apparently there is a bad interaction between the test runner and the author because from time to time I get author = TestRunner Probably the runner code is not robust enough in case of failure capture or something like that. runCase Author useAuthor: 'TestRunner' during: [ [self setUp. self performTest] ensure: [ self tearDown. self cleanUpInstanceVariables ] ]

Oct. 29, 2009

Re: [Pharo-project] some Announcements related questions

by Lukas Renggli

This concern was already raised elsewhere, but AXAnnoucnements is a port of the original announcement implementation and likely a copyright violation of the owners. The announcements in Pharo are a minimal clean room MIT implementation coming from OmniBrowser. Cheers, Lukas 2009/10/29 Igor Stasenko <siguctua(a)gmail.com>: > 2009/10/29 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: >> Hi Igor, >> I'm not sure but I think the annoucment version that will be included is >> there :Â http://source.lukas-renggli.ch/announcements >> Cheers, >> > And packages in that repository is already present in pharo-core image. > But if you look at AXAnnouncements, you can see the difference - > there are classes for subscriptions and > registry, apart from the 'AX' naming prefix. > >> 2009/10/29 Igor Stasenko <siguctua(a)gmail.com> >>> >>> Hello, i loaded the >>> Announcements package from SqS/AXAnnouncements, >>> >>> there are some tests failing because they explicitly comparing block >>> closures class to be a BlockContext. >>> But since new closure compiler, it should be BlockClosure instead. >>> What is a proper test you think? >>> isClosure or isBlock? >>> >>> And next question, that Pharo-core having a classes in >>> Announcements-Core category, >>> and comparing to AXAnnouncements Â there just very basic stuff and its >>> quite useless. >>> As i remember pharo is going to adopt announcements in base image, so >>> the question, is AXAnnouncements Â is right >>> thing to load, or there something made specifically for Pharo, but not >>> loaded in core image? >>> >>> -- >>> 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 >> >> >> >> -- >> CÃ©drick >> >> _______________________________________________ >> 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 -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 29, 2009