- Pharo-dev - lists.pharo.org

[Pharo-project] [update] #10238

by Marcus Denker

#10238 --------------------------------------- Issue 425: TransferMorph eats events (Mantis #7251) Issue 585: Add floatAt:bigEndian: in order to read IEEE 32 bits single precision float in byte arrays Issue 515: lowSpaceWatcher causes DNU interruptName:preemptedProcess: Kernel-AlexandreBergel.260: the menu in pluggabletext editor has been extended with tallyIt ScriptLoader-david_roethlisberger.761: fixed #loadOBAlpha and #loadSuperOB in ScriptLoader System-david_roethlisberger.221 Tools-david_roethlisberger.141: extended SystemNavigation and ToolSet to browse implementors and senders in dedicated browsers instead of showing them in a generic message list browser Traits-damiencassou.261: Implements TraitBehavior>>poolDictionaryNames for polymorphic use with classes -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Feb. 19, 2009

Re: [Pharo-project] Question about Universes

by Ramon Leon

> I don't think it is fair to use code critics as an argument. I think it's perfectly fair, be it code critic or lint, if it finds bad code then it finds bad code. It's not like you don't know about code critics and Lint is already in Squeak, so it's your choice if you choose not to avail yourself of tools that point out badly written code. He writes about the tools he's working on at his blog http://www.lukas-renggli.ch/blog which is easily subscribed to. There's no reason anyone can say they're unaware of what he's doing unless they're choosing to be unaware. Ramon Leon http://onsmalltalk.com

Feb. 19, 2009

Re: [Pharo-project] Incompatibility between Pharo and Seasidehosting

by John M McIntosh

look in the archive and on the vm-dev list I think people agree this is a gcc 4.3 issue. On 19-Feb-09, at 4:15 AM, Bruce O'Neel wrote: > Hi, > > Is it possible this error? > > sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0` failed. > Aborted > > I get this following the procedure below on a Debian Lenny PPC > system with Squeak 3.10-4. > Gcc is 4.3.2. I do not get this on a Ubuntu hardy ppc system with > the same version of squeak. > Gcc is slightly older at 4.2.3. > > I've worked around this, for the moment, by adding -memory 200m to > the squeak > command line. > > I spent some weekend debugging this, but, I didn't find where the > problem it is comes > from. > > cheers > > bruce -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Feb. 19, 2009

Re: [Pharo-project] Question about Universes

by Keith Hodges

Lukas Renggli wrote: >> You are wrong about Sake I think. >> > > I know Sake. I've written a generator for builder.seaside.st. The > result (or a modified version of it) is included with the Sake > distribution as Seaside29Builder. > > >> Sake can declare a universe of >> known-to-work-together packages. Just take a class, declare the sake >> tasks you know work together in the image you target and things will >> be as in universe. >> > > Sure, you can use Sake to build something very similar to a Universe. > However tasks are not declarative, but instead use a script to perform > some actions. In most cases they call Installer to find and load an > appropriate version (what is already scary in itself). > Why? They are "mostly" declarative, following feedback from Andreas. If the default script is used it simply analyses the url data given, which is the case for 99% of packages. > I understand that Package Universe is too restrictive for some cases, > however I wouldn't dare to replace it with Sake. Sake depends on a > stack of hacks, it even uses its own compiler to allow uppercase > method names. No it doesnt. It doesn't depend upon that compiler hack. That hack provides the ability to put textual data in as an appendix to a method. It is an entirely independent facility that could be perhaps better included as a trait for those that want it. I use it when I want to use methods to be a mini database, in the Mantis package, and for Bob to be able to manages build scripts in the image without having to enclose in quotes and escape quotes. > In the small codebase Code Critics finds 14 serious bugs > like non existing inst-variable references and message sents that are > I don't think it is fair to use code critics as an argument. To me it appears that you have developed all of these tools for your own use. I have never even seen you announce their existence to squeak-dev. Where is the documentation? > not implemented anywhere. Of course there is not a single test. What are you talking about: Sake-Tests. > The > way Sake calculates dependencies is totally strange, I am not sure if > it is even correct. > Again, what do you mean? There are two algorithms in use. The first is lifted directly from rake. The second is stolen directly from universes. Keith

Feb. 19, 2009

Re: [Pharo-project] Incompatibility between Pharo and Seasidehosting

by Adrian Lienhard

I tried what Lukas suggested. What happens is that Squeak starts up but then hogs the CPU and does not draw the GUI. However, an old version of Pharo, #10130, still works. Version #10172 does not work either, which suggests that its not Poymorph. My best guess is that its FreeType. I commented out the two startUp: methods of FreeTypeFontProvider and FreeTypeSettings, but without success. How could FreeType be disabled? Adrian On Feb 19, 2009, at 14:42 , Lukas Renggli wrote: >>> sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0` >>> failed. >>> Aborted >> >> I don't think so because seasidehosting would print an error message >> in the system logs and it is not the case. > > I can only guess, but maybe the font-enumeration at startup causes the > VM to hang. Seaside Hosting uses quite an old and modified version of > the Unix VM. Maybe Adrian can verify that this is/is not the problem, > by opening a Pharo image on seasidehosting.st within an X session? > > Cheers, > Lukas > > -- > Lukas Renggli > http://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

Feb. 19, 2009

Re: [Pharo-project] Question about Universes

by Lukas Renggli

The only problem i see is that it is not cleanly possible to support dependencies. If you want to install A and B that both depend on C, C will presumabely loaded twice. This does not happen with Sake and Universes. On 2/19/09, Alexandre Bergel <Alexandre.Bergel(a)inria.fr> wrote: > Thanks Lukas for sharing your experience with us. > I have a naive question. Personally, I like the way packages get > installed using class side methods on ScriptLoader. I have similar > scripts for Mondrian and other projects. > Is there something not convenient in that? > > Cheers, > Alexandre > > > On 19 Feb 2009, at 14:38, Lukas Renggli wrote: > >>> You are wrong about Sake I think. >> >> I know Sake. I've written a generator for builder.seaside.st. The >> result (or a modified version of it) is included with the Sake >> distribution as Seaside29Builder. >> >>> Sake can declare a universe of >>> known-to-work-together packages. Just take a class, declare the sake >>> tasks you know work together in the image you target and things will >>> be as in universe. >> >> Sure, you can use Sake to build something very similar to a Universe. >> However tasks are not declarative, but instead use a script to perform >> some actions. In most cases they call Installer to find and load an >> appropriate version (what is already scary in itself). >> >> I understand that Package Universe is too restrictive for some cases, >> however I wouldn't dare to replace it with Sake. Sake depends on a >> stack of hacks, it even uses its own compiler to allow uppercase >> method names. In the small codebase Code Critics finds 14 serious bugs >> like non existing inst-variable references and message sents that are >> not implemented anywhere. Of course there is not a single test. The >> way Sake calculates dependencies is totally strange, I am not sure if >> it is even correct. >> >> Lukas >> >> -- >> Lukas Renggli >> http://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 >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 > -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 19, 2009

Re: [Pharo-project] Question about Universes

by StÃ©phane Ducasse

thanks lukas Stef On Feb 19, 2009, at 2:38 PM, Lukas Renggli wrote: >> You are wrong about Sake I think. > > I know Sake. I've written a generator for builder.seaside.st. The > result (or a modified version of it) is included with the Sake > distribution as Seaside29Builder. > >> Sake can declare a universe of >> known-to-work-together packages. Just take a class, declare the sake >> tasks you know work together in the image you target and things will >> be as in universe. > > Sure, you can use Sake to build something very similar to a Universe. > However tasks are not declarative, but instead use a script to perform > some actions. In most cases they call Installer to find and load an > appropriate version (what is already scary in itself). > > I understand that Package Universe is too restrictive for some cases, > however I wouldn't dare to replace it with Sake. Sake depends on a > stack of hacks, it even uses its own compiler to allow uppercase > method names. In the small codebase Code Critics finds 14 serious bugs > like non existing inst-variable references and message sents that are > not implemented anywhere. Of course there is not a single test. The > way Sake calculates dependencies is totally strange, I am not sure if > it is even correct. > > Lukas > > -- > Lukas Renggli > http://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 >

Feb. 19, 2009

Re: [Pharo-project] Question about Universes

by Alexandre Bergel

Thanks Lukas for sharing your experience with us. I have a naive question. Personally, I like the way packages get installed using class side methods on ScriptLoader. I have similar scripts for Mondrian and other projects. Is there something not convenient in that? Cheers, Alexandre On 19 Feb 2009, at 14:38, Lukas Renggli wrote: >> You are wrong about Sake I think. > > I know Sake. I've written a generator for builder.seaside.st. The > result (or a modified version of it) is included with the Sake > distribution as Seaside29Builder. > >> Sake can declare a universe of >> known-to-work-together packages. Just take a class, declare the sake >> tasks you know work together in the image you target and things will >> be as in universe. > > Sure, you can use Sake to build something very similar to a Universe. > However tasks are not declarative, but instead use a script to perform > some actions. In most cases they call Installer to find and load an > appropriate version (what is already scary in itself). > > I understand that Package Universe is too restrictive for some cases, > however I wouldn't dare to replace it with Sake. Sake depends on a > stack of hacks, it even uses its own compiler to allow uppercase > method names. In the small codebase Code Critics finds 14 serious bugs > like non existing inst-variable references and message sents that are > not implemented anywhere. Of course there is not a single test. The > way Sake calculates dependencies is totally strange, I am not sure if > it is even correct. > > Lukas > > -- > Lukas Renggli > http://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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 19, 2009

Re: [Pharo-project] Incompatibility between Pharo and Seasidehosting

by Lukas Renggli

>> sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0` failed. >> Aborted > > I don't think so because seasidehosting would print an error message > in the system logs and it is not the case. I can only guess, but maybe the font-enumeration at startup causes the VM to hang. Seaside Hosting uses quite an old and modified version of the Unix VM. Maybe Adrian can verify that this is/is not the problem, by opening a Pharo image on seasidehosting.st within an X session? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 19, 2009

Re: [Pharo-project] Question about Universes

by Lukas Renggli

> You are wrong about Sake I think. I know Sake. I've written a generator for builder.seaside.st. The result (or a modified version of it) is included with the Sake distribution as Seaside29Builder. > Sake can declare a universe of > known-to-work-together packages. Just take a class, declare the sake > tasks you know work together in the image you target and things will > be as in universe. Sure, you can use Sake to build something very similar to a Universe. However tasks are not declarative, but instead use a script to perform some actions. In most cases they call Installer to find and load an appropriate version (what is already scary in itself). I understand that Package Universe is too restrictive for some cases, however I wouldn't dare to replace it with Sake. Sake depends on a stack of hacks, it even uses its own compiler to allow uppercase method names. In the small codebase Code Critics finds 14 serious bugs like non existing inst-variable references and message sents that are not implemented anywhere. Of course there is not a single test. The way Sake calculates dependencies is totally strange, I am not sure if it is even correct. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 19, 2009