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

Re: [Pharo-project] Package management info

by keith

> You can have a look at dale henrichs web page > > http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-f… > > you can also have a look at Moose, mondrian .... on squeaksource. > They are managed with metacello and we stress it :) > > Stef My first look at metacello to appraise it. It looks like a copy of Sake/Packages. S/P stores package definitions in methods of a class, so does Metacello. Metacello doesnt layer the dependency mechanism so that it can be used for other things. Sake/Packages is layered on top of Sake. Metacellos appears declarative and only declarative, whereas S/P can execute arbitrary tasks or code. Metacello's metadata fields appear fixed S/P's is not. As far as I can see S/P had most of the functionality of Metacello, a year before and it supports unloading. I am not saying that S/P is perfect, it is not as "controlled" and constrained as the Metacellos approach. There are small improvements that S/P could add to make it equivalent. For example each package definintion loads a single package in S/P in Metacello a single package definition can load multiple packages which makes for a more concise library. It would be a trivial change to include. enjoy Keith

Dec. 16, 2009

Re: [Pharo-project] [squeak-dev] Re: [BUG] [ :a | ] value: 1

by Stephen Pair

On Wed, Dec 16, 2009 at 1:24 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > I like Peter's response. How about making it a preference? ;) ;) What I > mean is we replace the code by something that compiles code that either > raises an error or answers nil. y default the preference is set to generate > the error code. Then we force people to write [:arg| nil] because [:arg| ] > will generate a run-time error (with a verbose and helpful explanatory > comment). Then in a few months, years, decades we'll be in a position to > remove the preference and generate code that answers nil because all the > uses will have been caught. > > I can imagine wanting to keep the preference and turning it on when > importing code from other dialects for error checking. > > The downside to this approach is that empty blocks with arguments will > include the "nil" noise. But that;s very easy to remove automatically once > the putsch is stable. > Egads! I thought it was a really good joke at first, but now I realize you are half serious. Make it work right, fix all the code in the base image, maybe write something that can reveal places where this is done in a particular class or package, then publish it while reminding people of: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. - Stephen

Dec. 16, 2009

[Pharo-project] Fwd: [BUG] [ :a | ] value: 1

by Lukas Renggli

---------- Forwarded message ---------- From: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2009/12/16 Subject: Re: [BUG] [ :a | ] value: 1 To: Lukas Renggli <renggli(a)gmail.com> Cc: Dan Ingalls <Dan.Ingalls(a)sun.com>, "L. Peter Deutsch" <lpd(a)major2nd.com>, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org>, Pharo Development <pharo-project(a)lists.gforge.inria.fr> On Wed, Dec 16, 2009 at 9:44 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > > :) :) Â This is funny. Â VisualWorks has exactly the same bug^H^H^Hfeature. > > Â And if you look at the ANSI standard (ok, this is from the draft, but it is > > essentially the actual document) there is an exception for precisely this > > case, Â See the last sentence in section 3.4.4 Blocks: > > > > If a block has no <block body> or no <statements> in its <block body> then > > the value of the block is undefined. > > Ok, I did not check that document. I somehow expected that all empty > blocks would return nil. As do we all, which is why this is so horribly broken :) Â The sad thing is, we've been living with it for thirty years. > > > Which allows [] to be implemented as e.g. [Random new next]. Â In fact both > > VisualWorks and Squeak answer the last argument: > > [:a ] value: 1 1 > > [:a :b|] value: 1 value: 2 2 > > [:a :b :c :d :e :f :g :h| ] valueWithArguments: (1 to: 8) 8 > > [:a | nil] value: 1 nil > > [:a :b| nil] value: 1 value: 2 nil > > At least it is consistent whether the block is inlined or not ;) > > 1+2 ifNotNil: [:arg|] 3 > > It as ever been so. > > Thank you for the additional insight. I learned something new on the > Smalltalk semantics today :-) > > I will fix my code then. > > > P.S. Â I'm caught between wanting to fix it and wanting to let sleeping dogs > > lie. Â I'd like to know what all the other dialects do. Â If a substantial > > majority have the same curio I think we have to live with this, uh, > > ornament. Â Just to be clear, making it a preference is a sick joke on my > > part. > > I think we'd better let it sleep. In my image I have 61 empty blocks > with one or more argument. Some of them might depend on that hidden > behavior. > I like Peter's response. Â How about making it a preference? ;) ;) What I mean is we replace the code by something that compiles code that either raises an error or answers nil. Â y default the preference is set to generate the error code. Â Then we force people to write [:arg| nil] because [:arg| ] will generate a run-time error (with a verbose and helpful explanatory comment). Â Then in a few months, years, decades we'll be in a position to remove the preference and generate code that answers nil because all the uses will have been caught. I can imagine wanting to keep the preference and turning it on when importing code from other dialects for error checking. The downside to this approach is that empty blocks with arguments will include the "nil" noise. Â But that;s very easy to remove automatically once the putsch is stable. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 16, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Stuff

by Nicolas Cellier

2009/12/16 Igor Stasenko <siguctua(a)gmail.com>: > 2009/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I will reply because this situation is silly and keith has some good points. >> > > Yes, silly, by fact that currently there are two groups of people each > putting improvements over > different places of merely same thing, duplicating an effort(s). > But anyways, its better than sitting and waiting for Great New Thing > (c) to be released by someone. > I just hope, that at some day both forks will adopt DeltaStreams to > make our life a bit easier in respect of sharing the code. > Sometimes it's good to see two different solutions. It makes you think twice. Nicolas > >> ---------- Forwarded message ---------- >> From: keith <keith_hodges(a)yahoo.co.uk> >> Date: 2009/12/16 >> Subject: Re: [squeak-dev] Stuff >> To: The general-purpose Squeak developers list >> <squeak-dev(a)lists.squeakfoundation.org> >> >> >>> So the question is, has ever been considered to simply build the bridge >>> between >>> communities and to use the PharoCore image as the base for Squeak? >> >> This wouldn't work for the same reasons that it wouldn't work to use a >> Squeak-trunk image as the basis for Pharo. You should propose that at >> some point just to see what kind of reaction you get ;-) >> >> Cheers, >> Â Â - Andreas >> >> Yes please propose it. That is an excellent idea. Lets use the PharoCore >> image as the base for future Squeak releases! It would work excellently, it >> might require some humility from Andreas. In my opinion it is the only >> sensible way forward. >> Let me divulge a little secret here, the biggest reason that we kept the >> original 3.11 development always said to be about "process" and not about >> the actual release image, is that with a decent image building and testing >> process in place it would then have been possible to build and test a future >> squeak release pilot on top of some of the pharo-core packages. For us Pharo >> was simply a pilot project moving the core forward that we could borrow the >> best bits from it as appropriate. By adopting pharo in carefully integrated >> pieces we would perhaps of stood a chance of keeping the community together. >> The annoying thing was that Pharo team seemed to be insisting on diverging >> far more than was necessary and consistently refused to adopt any shared >> values or code that would have made this approach easier, we really need as >> a starting point, shared code loading tools, package management tools, and >> shared testing tools at the very least. i.e. Installer, and MC1.5/6 were >> developed with this in mind, and so was SUnit-improved, but the Pharo team >> refused to touch either of these projects. >> The more that the squeak-core image changes (i.e. in trunk) without tracking >> pharo's core packages the more diverse and impossible future integration >> will become. The old 3.11 effort was about having the tools to enable >> packages to be developed and tested in both Pharo and Squeak and all other >> forks, and then extending this to suggest common core packages as a way >> forward for everyone. >> So now that our to-be carefully planned evolution of squeak-core, using >> pharo for inspiration, has been trashed by random hacking on trunk, adopting >> PharoCore as a base image is probably the viable way forward for this >> community to remain viable. >> You already know that I don't see the squeak community as viable, since it >> eats its young. >> Sooner or later the board or someone will realize this, they will get >> elected to the board, and all those of you who have been working hard on >> trunk will discover that all your contributions have been wasted. Never mind >> eh. >> Keith >> >> >> >> >> >> -- >> 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

Dec. 16, 2009

Re: [Pharo-project] [newbee] How do I save the contents of a Workspace?

by Levente Uzonyi

On Wed, 16 Dec 2009, StÃ©phane Ducasse wrote: > > Hi levente > >>> >> What prevents you from copying the workspace text, open your favorite >> text editor, paste text there and save it in a file? >>> >>> r >>> >> >> Or use the File Browser, that's why it's there, even though it's a bit >> broken in pharo. > > can you explain what is broken? > => open a bug entry For example: right click on a text file in the upper right panel, the first 3 menuitems are the same "compress file". (And I'm missing the zip viewer which was super cool IMO) Levente > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 16, 2009

Re: [Pharo-project] Fwd: [BUG] [ :a | ] value: 1

by Nicolas Cellier

Also, more recently reported by Gilad http://bugs.squeak.org/view.php?id=5793 2009/12/16 Lukas Renggli <renggli(a)gmail.com>: > ---------- Forwarded message ---------- > From: L Peter Deutsch <lpd(a)major2nd.com> > Date: 2009/12/16 > Subject: Re: [BUG] [ :a | ] value: 1 > To: eliot.miranda(a)gmail.com > Cc: renggli(a)gmail.com, Dan.Ingalls(a)sun.com, > squeak-dev(a)lists.squeakfoundation.org > > > Good Heavens. Â To think that that something like this would surface after > all these years.... > > I agree with Lukas. Â The block should return nil. Â The ANSI standard is > broken -- the fewer special cases a standard has, the better. > > I didn't write the Smalltalk source-to-bytecode compiler, and if I had, I > would have made it return nil if I had had my wits about me. > > OTOH, Dan may know of a historical reason why things were done this way -- > perhaps there's some fairly common usage pattern that I've forgotten that > makes the return-the-last-argument definition worthwhile. > > I agree that changing this is likely to break code. Â All the same, I am > somewhat in favor of changing it in the ANSI standard. Â If that is done, I > would hope someone would create a tool to do a pass over Smalltalk source > code and browse any occurrences of the problematic construct. Â (Fixing them > automatically might not be a good idea, since the value that the block > returns might not actually be used, and if not, no fix would be needed.) > Fortunately, this is an example where it's easy, if a little unsightly, to > write code so that it will work under either interpretation (by explicitly > include the desired return value in the block). > > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â L Peter Deutsch > > P.S. Writing standards is really very tricky. Â If one writes a standard too > early, it's likely to get something important wrong simply from not enough > experience; but if you write it too late, it may be impossible to get > implementations to follow it, or the standard may have to compromise on > quality to conform to the implementations. Â A depressing example of this is > HTML5, where I'm told the standards committee pretty much caved to whatever > the major browsers had actually done, regardless of how poorly designed it > was. > ---------------------------------------------------------------- > > > > -- > 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 >

Dec. 16, 2009

Re: [Pharo-project] [squeak-dev] Re: [BUG] [ :a | ] value: 1

by StÃ©phane Ducasse

lukas can you open an issue on the pharobug tracker. Because I still dream about a nice and clean world so we could start to slowly spot the place and rewrite slowly. 61 is that many :) Stef On Dec 16, 2009, at 6:44 PM, Lukas Renggli wrote: >> :) :) This is funny. VisualWorks has exactly the same bug^H^H^Hfeature. >> And if you look at the ANSI standard (ok, this is from the draft, but it is >> essentially the actual document) there is an exception for precisely this >> case, See the last sentence in section 3.4.4 Blocks: >> >> If a block has no <block body> or no <statements> in its <block body> then >> the value of the block is undefined. > > Ok, I did not check that document. I somehow expected that all empty > blocks would return nil. > >> Which allows [] to be implemented as e.g. [Random new next]. In fact both >> VisualWorks and Squeak answer the last argument: >> [:a ] value: 1 1 >> [:a :b|] value: 1 value: 2 2 >> [:a :b :c :d :e :f :g :h| ] valueWithArguments: (1 to: 8) 8 >> [:a | nil] value: 1 nil >> [:a :b| nil] value: 1 value: 2 nil >> At least it is consistent whether the block is inlined or not ;) >> 1+2 ifNotNil: [:arg|] 3 >> It as ever been so. > > Thank you for the additional insight. I learned something new on the > Smalltalk semantics today :-) > > I will fix my code then. > >> P.S. I'm caught between wanting to fix it and wanting to let sleeping dogs >> lie. I'd like to know what all the other dialects do. If a substantial >> majority have the same curio I think we have to live with this, uh, >> ornament. Just to be clear, making it a preference is a sick joke on my >> part. > > I think we'd better let it sleep. In my image I have 61 empty blocks > with one or more argument. Some of them might depend on that hidden > behavior. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch >

Dec. 16, 2009

[Pharo-project] Fwd: [BUG] [ :a | ] value: 1

by Lukas Renggli

---------- Forwarded message ---------- From: L Peter Deutsch <lpd(a)major2nd.com> Date: 2009/12/16 Subject: Re: [BUG] [ :a | ] value: 1 To: eliot.miranda(a)gmail.com Cc: renggli(a)gmail.com, Dan.Ingalls(a)sun.com, squeak-dev(a)lists.squeakfoundation.org Good Heavens. Â To think that that something like this would surface after all these years.... I agree with Lukas. Â The block should return nil. Â The ANSI standard is broken -- the fewer special cases a standard has, the better. I didn't write the Smalltalk source-to-bytecode compiler, and if I had, I would have made it return nil if I had had my wits about me. OTOH, Dan may know of a historical reason why things were done this way -- perhaps there's some fairly common usage pattern that I've forgotten that makes the return-the-last-argument definition worthwhile. I agree that changing this is likely to break code. Â All the same, I am somewhat in favor of changing it in the ANSI standard. Â If that is done, I would hope someone would create a tool to do a pass over Smalltalk source code and browse any occurrences of the problematic construct. Â (Fixing them automatically might not be a good idea, since the value that the block returns might not actually be used, and if not, no fix would be needed.) Fortunately, this is an example where it's easy, if a little unsightly, to write code so that it will work under either interpretation (by explicitly include the desired return value in the block). Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â L Peter Deutsch P.S. Writing standards is really very tricky. Â If one writes a standard too early, it's likely to get something important wrong simply from not enough experience; but if you write it too late, it may be impossible to get implementations to follow it, or the standard may have to compromise on quality to conform to the implementations. Â A depressing example of this is HTML5, where I'm told the standards committee pretty much caved to whatever the major browsers had actually done, regardless of how poorly designed it was. ---------------------------------------------------------------- -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 16, 2009

Re: [Pharo-project] Package management info

by StÃ©phane Ducasse

On Dec 16, 2009, at 6:47 PM, GeertClaes wrote: > > I tried to search for more info about the "Package management system" > mentioned to be part of the next 1.1 Pharo milestone. Can someone point me > to more info about this package management system? well there is not that much. But indeed we would like to push the use of metacello to manage external packages as a start. Our philosophy is let us try and learn, fix and may be rewrite but from concrete case. > I also could not find that much info about MetaCello either. Any links to > papers, presentation and/or video much appreciated. You can have a look at dale henrichs web page http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-f… you can also have a look at Moose, mondrian .... on squeaksource. They are managed with metacello and we stress it :) Stef > -- > View this message in context: http://n2.nabble.com/Package-management-info-tp4176930p4176930.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 16, 2009

Re: [Pharo-project] Package management info

by Dale Henrichs

These are two places to get started with Metacello: http://code.google.com/p/metacello/ http://groups.google.com/group/metacello If you have questions, join the mailing group and ask away. Dale ----- "GeertClaes" <geert.wl.claes(a)gmail.com> wrote: | I tried to search for more info about the "Package management system" | mentioned to be part of the next 1.1 Pharo milestone. Can someone | point me | to more info about this package management system? | | I also could not find that much info about MetaCello either. Any | links to | papers, presentation and/or video much appreciated. | -- | View this message in context: | http://n2.nabble.com/Package-management-info-tp4176930p4176930.html | Sent from the Pharo Smalltalk mailing list archive at Nabble.com. | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 16, 2009