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

Re: [Pharo-project] [ANN] 10412

by Adrian Lienhard

OK, I can take a look to merge or remove it this week. Maybe its a good idea to have this functionality in the image instead of an external package (like this is will be easier to do license audits in the future). Adrian On Aug 9, 2009, at 22:13 , StÃ©phane Ducasse wrote: > Adrian > > if the behavior in MethodAuthorship is better we can just removed what > I integrated. > There is no problem. > Let me know. > > Stef > > > On Aug 9, 2009, at 5:17 PM, Adrian Lienhard wrote: > >>> - Issue 1054: Cuis code author CUIS code author checking code >>> SystemNavigation default contributorsNotSignatories >>> SystemNavigation default allContributors >>> SystemNavigation default contributionsOf: ... >> >> Stef, what is the difference to the Methodauthorships package that >> we've use for the license cleaning [1]? It seems that now we have a >> duplicated and obsolete list of signatories in the image. Or did you >> merge? >> >> Cheers, >> Adrian >> >> http://code.google.com/p/pharo/wiki/LicenseCleanEffort >> >> _______________________________________________ >> 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

Aug. 10, 2009

Re: [Pharo-project] Issue 1058 - Merge of BlockContext and BlockClosure

by Adrian Lienhard

sorry, I somehow missed the second part of your mail before replying ;) Not sure if this is a good idea as it looks a bit like a monkey patch... Would it actually work with MC? Because the class name from the class definition of MC would still return 'BlockClosure', I assume. Adrian On Aug 10, 2009, at 08:42 , Adrian Lienhard wrote: > BlockContext is not used anymore but is kept in the image for backward > compatibility for a while (so that packages like Seaside still load as > they define extension methods on BlockContext). > > If there are missing methods in BlockClosure let us know. > > Adrian > > On Aug 10, 2009, at 08:24 , Miguel Enrique CobÃ¡ Martinez wrote: > >> El lun, 10-08-2009 a las 01:19 -0500, Miguel Enrique CobÃ¡ Martinez >> escribiÃ³: >>> http://code.google.com/p/pharo/issues/detail?id=1058 >>> >>> Can this two classes be merged (the share 80% or more than methods >>> and >>> several are identical, maybe were copied) and then (assuming that >>> the >>> BlockClosure will be the enduring): >>> >>> Smalltalk at: #BlockContext put: BlockClosure >>> >>> This way several packages that extend BlockContext will work in the >>> new >>> closure vm, for example Magma. >>> >>> What are the pros/cons of this change? >>> >>> If feasible, will be marked as Milestone-1.0? >> >> Ramiro Diaz Trepat and Mariano MartÃnez Peck commented on the magma >> mailing list that they successfully loaded magma on a pharo image by >> copying the extensions added by magma to BlockContext to the class >> BlockClosure. It appear that the code worked ok. Maybe with this >> change >> it wouldn't be necessary to modify magma (Chris Muller should speak >> about this). That can be the case for a lot of packages and will ease >> the integration and "certification" of several packages on pharo. >> >> See: >> >> http://lists.squeakfoundation.org/pipermail/magma/2009-July/ >> 001321.html >> >> >> _______________________________________________ >> 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

Aug. 10, 2009

Re: [Pharo-project] Issue 1058 - Merge of BlockContext and BlockClosure

by Adrian Lienhard

BlockContext is not used anymore but is kept in the image for backward compatibility for a while (so that packages like Seaside still load as they define extension methods on BlockContext). If there are missing methods in BlockClosure let us know. Adrian On Aug 10, 2009, at 08:24 , Miguel Enrique CobÃ¡ Martinez wrote: > El lun, 10-08-2009 a las 01:19 -0500, Miguel Enrique CobÃ¡ Martinez > escribiÃ³: >> http://code.google.com/p/pharo/issues/detail?id=1058 >> >> Can this two classes be merged (the share 80% or more than methods >> and >> several are identical, maybe were copied) and then (assuming that the >> BlockClosure will be the enduring): >> >> Smalltalk at: #BlockContext put: BlockClosure >> >> This way several packages that extend BlockContext will work in the >> new >> closure vm, for example Magma. >> >> What are the pros/cons of this change? >> >> If feasible, will be marked as Milestone-1.0? > > Ramiro Diaz Trepat and Mariano MartÃnez Peck commented on the magma > mailing list that they successfully loaded magma on a pharo image by > copying the extensions added by magma to BlockContext to the class > BlockClosure. It appear that the code worked ok. Maybe with this > change > it wouldn't be necessary to modify magma (Chris Muller should speak > about this). That can be the case for a lot of packages and will ease > the integration and "certification" of several packages on pharo. > > See: > > http://lists.squeakfoundation.org/pipermail/magma/2009-July/ > 001321.html > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2009

Re: [Pharo-project] [ANN] Updating a Pharo image is now possible

by stan shepherd

Hi Damien, it gives the same error on 'Morphic-adrian_lienhard.345.mcz'. And it seems **very** slow, ie running for hours. Is that expected? Cheers, ...Stan 2009/8/8 Damien Cassou <damien.cassou(a)gmail.com>: > Please remove this file from the package-cache directory and try again. > > 2009/8/8 stan shepherd <stan.shepherd414(a)gmail.com>: >> Hi, I get Error: can't find EOCD position, during load of >> 'System-Support-stephane_ducasse.28.mcz' >> >> eocdPosition = 0 >> >> >> Full walkback is attached. >> >> Cheers, Â ...Stan >> >> 2009/8/8 Damien Cassou <damien.cassou(a)gmail.com>: >>> Hi, >>> >>> just wanted to say that updating a Pharo image seems to work ok now. >>> I've removed the overrides in some packages. >>> >>> However, remember that the update mechanism only updates Core >>> packages, not packages listed in >>> http://code.google.com/p/pharo/wiki/Packages. This could be possible >>> but has not been done yet. What do you think about that? >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Lambdas are relegated to relative obscurity until Java makes them >>> popular by not having them." James Iry >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 10, 2009

Re: [Pharo-project] Issue 1058 - Merge of BlockContext and BlockClosure

by Miguel Enrique CobÃ¡ Martinez

El lun, 10-08-2009 a las 01:19 -0500, Miguel Enrique CobÃ¡ Martinez escribiÃ³: > http://code.google.com/p/pharo/issues/detail?id=1058 > > Can this two classes be merged (the share 80% or more than methods and > several are identical, maybe were copied) and then (assuming that the > BlockClosure will be the enduring): > > Smalltalk at: #BlockContext put: BlockClosure > > This way several packages that extend BlockContext will work in the new > closure vm, for example Magma. > > What are the pros/cons of this change? > > If feasible, will be marked as Milestone-1.0? Ramiro Diaz Trepat and Mariano MartÃnez Peck commented on the magma mailing list that they successfully loaded magma on a pharo image by copying the extensions added by magma to BlockContext to the class BlockClosure. It appear that the code worked ok. Maybe with this change it wouldn't be necessary to modify magma (Chris Muller should speak about this). That can be the case for a lot of packages and will ease the integration and "certification" of several packages on pharo. See: http://lists.squeakfoundation.org/pipermail/magma/2009-July/001321.html

Aug. 10, 2009

[Pharo-project] Issue 1058 - Merge of BlockContext and BlockClosure

by Miguel Enrique CobÃ¡ Martinez

http://code.google.com/p/pharo/issues/detail?id=1058 Can this two classes be merged (the share 80% or more than methods and several are identical, maybe were copied) and then (assuming that the BlockClosure will be the enduring): Smalltalk at: #BlockContext put: BlockClosure This way several packages that extend BlockContext will work in the new closure vm, for example Magma. What are the pros/cons of this change? If feasible, will be marked as Milestone-1.0?

Aug. 10, 2009

Re: [Pharo-project] a process to maintain non core package

by Miguel Enrique CobÃ¡ Martinez

El dom, 09-08-2009 a las 21:01 +0100, Keith Hodges escribiÃ³: > Keith Hodges wrote: > > Adrian Lienhard wrote: > > > >> Hi, > >> > >> I really think we need a package management system and a process to > >> maintain it. > >> > >> The goal is that loading and using non-core packages "just > >> works" > Same goal as for Sake/Packages, and it works for me. > > >> (unlike for instance SqueakMap, where loading more often fails > >> than succeeds because there are a lot of obsolete packages and a > >> dependency mechanism is missing). > >> > >> - There should be a responsible maintainer for each package > >> > Not a realistic proposition. Better to be open to all to maintain on > behalf of the community. Why not, the debian project use this model since 1996 or something like that. The same package system the use report packages not maintained anymore (orphans and waiting for mantainer) > >> - For each package there should be a known way to discuss and report > >> problems > >> > That's just arbitrary metadata in the package definition, for more > general topics we use the packages(a)squeakfoundation.org mailing list > >> - A gate keeper includes and removes packages from the set depending > >> on their status > >> > Probably too complicated to be practical. > >> This limits the set of included packages (at least initially) but > >> would increase the quality and hence the user experience. > >> > >> Maybe there could be two sets, a stable and an unstable set. New > >> > Sake/Packages supports a stable and a beta release of each package. > >> packages would first go to the unstable set and then move up to the > >> stable set after a while. > >> > >> An automated build process could load packages into new builds and > >> report the result of the tests. > >> > Bob does that. > >> The package management system does not need to be very sophisticated, > >> > Sake is as simple as possible for defining actions with dependencies. > >> but it should manage dependencies and have a simple GUI (to search for > >> packages and see what is already loaded). > >> > Sake/Packages uses the class browser as is, no extra GUI is required. > > Packages provided explore > > shows you what is loaded, and this should be merged into > PackageOrganization. > > Keith Keith, it really appear that you have built the platform to bring this dream a reality, but somehow (the details are not relevant now) you haven't materialized a "steve jobs" kind of show off of it. I believe your words, based on your other projects that I use. What do you need, as Stephan said, to bring a complete, working, and as simple to understand for all of us of your tools. This is my proposal: I think that if you can put a working example (minimal, a couple of packages, and the core) using Pharo, the pharo community happily will support you. No more fights, no more angry mails, just the working full simple demo. I offer to you access to a server with a homologated IP to install (I can help you here too) to setup the repositories to test your tools. If the community agree to use your tools and process I can also buy and donate the domain to host this infrastructure. In the beginning I will host it, if someday it grows more than I can support (bandwidth mainly, the space isn't problem) then we will discuss with the community to migrate the repos to a bigger servers or to ask for donations or some other party that can host it (maybe the folks of seasidehosting). We'll see in that moment. But, Keith, we need to see to believe and support you. Indeed, Pharo needs a real proccess to not get to the same point that squeak. Cheers, Miguel CobÃ¡ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2009

[Pharo-project] Expected failures/errors on SUnit

by Hernan Wilkinson

There is a tool we are writing that needs to stop running the tests of a test suite if there is an error or a failure (as a performance improvement)To my surprise, using failuresCount and errorsCount made the tool run slower than faster and the reason is because of the expected failures and errors... asking for the failuresCount and the errorCounts goes through all the failures and error selecting only those that should not pass... anyway, it is a slow implementation. I'm not sure if this is the right list to ask this for, but does somebody know why is it implemented that way? could this be changed? who is the responsible for maintaining/changing SUnit? Thanks, Hernan.

Aug. 10, 2009

Re: [Pharo-project] Display depth on Linux

by Mariano Martinez Peck

2009/8/9 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > On linux, when setting Display Depth to something else than 32, it is > impossible to recongnize something on the screen. > We did some research with Juan Vuletich on this and it sounds like an error > on the VMnot the Smalltalk code > We try it on Ubuntu 9.04, 64 bits. Is this a known bug? > Do you have Compiz activated? > > Hernan > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 10, 2009

[Pharo-project] Issue 1053: Transcript updates from foreground process not displayed in Transcript window

by Dale Henrichs

Ready for review: http://code.google.com/p/pharo/issues/detail?id=1053

Aug. 10, 2009