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

Re: [Pharo-project] Why a package management system

by GÃ¶ran Krampe

Hi! GermÃ¡n Arduino wrote: > Hi GÃ¶ran: > > Sorry by my intromision here, but want to say somethings :) > > 2010/2/23 GÃ¶ran Krampe <goran(a)krampe.se <mailto:goran@krampe.se>> [SNIP] > What I have seen so far in Metacello is indeed nothing new - the > senarios and discussions about dependencies etc go loooong way back. > > > I'm on Squeak from old 3.2 times. And yes, a lot of discussions about > packages, > etc, but only discussions on most of cases. I think Metacello solves the > dependencies > questions very well and the other tools not (with exception of Universes > probably, but > abandoned now). Also Metacello provides all the features explained on > the excellent > mail of Torsten, assuring that the configurations will work with the > time not breaking > stuffs. > > The solution of using Metacello+Monticello is, imho, very simple, easy > and productive > and is here, available to us. :) I never claimed otherwise! I am just saying that there is nothing new - and frankly, though I admit not having read carefully, I didn't find the example so... impressive. Perhaps I need to read it again. Again though - I am not saying anything negative about Metacello. [SNIP] > Anyway, "common exchange mechanism" - I am working on Deltastreams which > I even presented at Brest, though unfortunately colliding with the > Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY > this problem (fork interchange), and it was born in 2007: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.h… > > I and Igor are the ones working on it - and after Brest we have had very > little time to move it forward. I still think it is a very important > piece of the puzzle though. > > But Deltastreams are ready to use on production systems? Nope, not yet, although very close. But since the topic came up I wanted to mention it. But AFAIK there is no other tool/project aimed at that use case. Again, I may be wrong :) regards, GÃ¶ran

Feb. 23, 2010

Re: [Pharo-project] Why a package management system

by Mariano Martinez Peck

> IMHO, this is the biggest difference between Squeak and Pharo I've seen. > Sure, you can now unload Etoys from Squeak, your image will still > contain code like ImageSegment>>findRogueRootsAllMorphs: though. > Of course....and an infinitive number of Smalltalk at: #XXX ifPresent:

Feb. 23, 2010

Re: [Pharo-project] Why a package management system

by Henrik Johansen

Den 23.02.2010 13:00, skrev GÃ¶ran Krampe: > Hi! > > Torsten Bergmann wrote: > >>> So you are educating them.... >>> Frankly I stopped trying long time ago. >>> >> No, I just tell them what I think is necessary to move forward. >> Other may be more educated here, it is just sharing MHO so others >> can to form an own opinion. >> > Right, discussion is good. And believe me - the squeak-dev community is > NOT oblivious to the needs of a package system. I mean, come on, > Monticello, SqueakMap, Universes etc etc - it all was around before > Pharo was born. > > What I have seen so far in Metacello is indeed nothing new - the > senarios and discussions about dependencies etc go loooong way back. > > BUT... that *doesn't* mean I am passing any judgment on Metacello - IMHO > all efforts are good per definition! :) I haven't formed an opinion myself. > > No system is going to perfectly fulfill everyones perception of what would be "The Best Way"(tm), but as long as the need for functionality provided by a system is real, actually deciding on one, IS important. >From what I've seen in archive discussion, that seems to have been the biggest showstopper for noticeable progress in the Squeak community. Paradoxically, existing systems which clearly contain lousy code, are left in (or replacements objected to) on the basis of backwards-compatability... IMHO, this is the biggest difference between Squeak and Pharo I've seen. Sure, you can now unload Etoys from Squeak, your image will still contain code like ImageSegment>>findRogueRootsAllMorphs: though. Sure, you can new add Preferences with pragmas now, you still have a class with a Dictionary accessed and stored into by the entire system, and 1223 accessors for things local to specific packages though. Metacello is nothing new for sure, but contrary to other systems, it seems to have reached wide acceptance in Pharo. Understandably, many here feel it'd be nice if the "classic" Squeak-community decided to use it as well. Personally, I doubt it will happen (for any PMS really, as evidenced by Sake/Packages, as well as all the other previous attempts), yet I appreciate Torsten's and others effort to at least correct the plain-out misconceptions some people seem to have about deficiencies of Metacello. Pretty sure noone would argue Monticello is a perfect system either, achieving critical mass was though. >> Meanwhile the Pharo community has grown with new members and many people >> dont care about old discussions. >> >> Let's use our energy to move forward and (if possible) share as much >> knowledge and code as long as parts of our communities overlap. >> > Yes, exactly. > +1. > Anyway, "common exchange mechanism" - I am working on Deltastreams which > I even presented at Brest, though unfortunately colliding with the > Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY > this problem (fork interchange), and it was born in 2007: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.h… > > I and Igor are the ones working on it - and after Brest we have had very > little time to move it forward. I still think it is a very important > piece of the puzzle though. > > regards, GÃ¶ran I've been meaning to make system-change notifications for Pharo so the recording-part could work there too, but I never seem to get around to it :( Part of the problem is of course my own personal "The Best Way"(tm), which f.ex. would include Announcements. Since I'd like the ability to have Weak subscriptions, I'd first have to deoptimize the Announcement-package Levente made a bit to make it "prettier", make it a strict superset of what if found in Core already, fix WeakRegistry so each resource registered for an object actually gets finalized, which again means... etc... Oh, and hope it'd end up good enough that it'd warrant inclusion:) Cheers, Henry

Feb. 23, 2010

Re: [Pharo-project] Why a package management system

by GermÃ¡n Arduino

Hi GÃ¶ran: Sorry by my intromision here, but want to say somethings :) 2010/2/23 GÃ¶ran Krampe <goran(a)krampe.se> > Hi! > > Torsten Bergmann wrote: > >> So you are educating them.... > >> Frankly I stopped trying long time ago. > > > > No, I just tell them what I think is necessary to move forward. > > Other may be more educated here, it is just sharing MHO so others > > can to form an own opinion. > > Right, discussion is good. And believe me - the squeak-dev community is > NOT oblivious to the needs of a package system. I mean, come on, > Monticello, SqueakMap, Universes etc etc - it all was around before > Pharo was born. > > What I have seen so far in Metacello is indeed nothing new - the > senarios and discussions about dependencies etc go loooong way back. > I'm on Squeak from old 3.2 times. And yes, a lot of discussions about packages, etc, but only discussions on most of cases. I think Metacello solves the dependencies questions very well and the other tools not (with exception of Universes probably, but abandoned now). Also Metacello provides all the features explained on the excellent mail of Torsten, assuring that the configurations will work with the time not breaking stuffs. The solution of using Metacello+Monticello is, imho, very simple, easy and productive and is here, available to us. :) > I therefore would really like to see a common exchange mechanism used > > on both sides. > > > > I'm sure I'm not able to convince one or the other to use package > > systems like Metacello but at least I hope to make them think about > > the need of a more modular system. > > Ehm, "a more modular system" has been on the table since... hell, way > back to Squeak 3.3! And yeah, even earlier of course - you can probably > track it back to PARC if you try hard. :) :) > hehe, I remember the 3.3 modules breaking almost all the things coming from 3.2. > > Anyway, "common exchange mechanism" - I am working on Deltastreams which > I even presented at Brest, though unfortunately colliding with the > Seaside tutorial. Deltas and Deltastreams are indeed focused on EXACTLY > this problem (fork interchange), and it was born in 2007: > > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.h… > > I and Igor are the ones working on it - and after Brest we have had very > little time to move it forward. I still think it is a very important > piece of the puzzle though. > > But Deltastreams are ready to use on production systems? Cheers. GermÃ¡n.

Feb. 23, 2010

Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now

by Miguel Enrique CobÃ¡ Martinez

El mar, 23-02-2010 a las 14:12 +0100, GÃ¶ran Krampe escribiÃ³: > > Sidenote: SqueakMap actually caches all URLs used for versions and if > the original URL fails an SHA check it falls back on the cached file on > the SqueakMap server. > > In that way it was meant to handle original URLs going stale or > disappearing. > Does that mean that everything pushed to squeakmap can never be deleted? If that isn't true, then the problem is just pushed one step further. > regards, GÃ¶ran > Thanks -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Feb. 23, 2010

Re: [Pharo-project] Pharo by Example is back on Lulu

by Alexandre Bergel

Glad to hear this! Good job! Alexandre On 23 Feb 2010, at 09:46, Oscar Nierstrasz wrote: > > Hi Folks, > > After much pain, PBE is back on Lulu: > > http://www.lulu.com/content/paperback-book/pharo-by-example/7522128 > > The problem seems to have been caused by embedded PDF figures, which > messed up the fonts on several pages. By turning all th efigures > into embedded PNGs, the problem finally went away. > > Cheers, > - on > > > _______________________________________________ > 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. 23, 2010

[Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now

by Torsten Bergmann

>make sure that we can get metacello configuration working in 3/5 years from now. We should also think about - mirroring. Currently in Metacello you give the repo hard coded in the baseline. Maybe it would be better to have an alias there and define the repo elsewhere (for instance in #versionXXX method). - offline work where on is working offline, behind a closed proxy. There are also companies that want to have an internal server. They do not want to rely on a public server even when it is 24*7. Did I already ask if we have the infrastructure/resources to run an own server (PharoSource, ...)? Bye T. c -- NEU: Mit GMX DSL Ã¼ber 1000,- Â¿ sparen! http://portal.gmx.net/de/go/dsl02

Feb. 23, 2010

Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now

by GÃ¶ran Krampe

Miguel Enrique CobÃ¡ Martinez wrote: > El mar, 23-02-2010 a las 11:14 +0100, stephane ducasse escribiÃ³: > I was thinking about this problem yesterday in the light of the packages > moved by Lukas. > We have a problem with the packages referenced by a ConfigurationOfXXX. > The can disappear anytime. The repository can disappear anytime. > > So I thought that we need a dedicated hosting server where: > > - We have all the ConfigurationOfXXX (in the MetacelloRepository repo, > just as now) > - We copy there *all* the packages that conform a giver > ConfigurationOfXXX>>versionXX: from the original repo to this dedicated > repo. > - There is *no way* to delete anything. This is a *write only, read > always, delete never* repository. Sidenote: SqueakMap actually caches all URLs used for versions and if the original URL fails an SHA check it falls back on the cached file on the SqueakMap server. In that way it was meant to handle original URLs going stale or disappearing. regards, GÃ¶ran

Feb. 23, 2010

Re: [Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now

by Miguel Enrique CobÃ¡ Martinez

El mar, 23-02-2010 a las 11:14 +0100, stephane ducasse escribiÃ³: I was thinking about this problem yesterday in the light of the packages moved by Lukas. We have a problem with the packages referenced by a ConfigurationOfXXX. The can disappear anytime. The repository can disappear anytime. So I thought that we need a dedicated hosting server where: - We have all the ConfigurationOfXXX (in the MetacelloRepository repo, just as now) - We copy there *all* the packages that conform a giver ConfigurationOfXXX>>versionXX: from the original repo to this dedicated repo. - There is *no way* to delete anything. This is a *write only, read always, delete never* repository. So maybe we need a modified squeaksource image there that disables delete/rename/move packages. Or maybe the metasource from Torsten (is that the name of the new app designed for Metacello) can add this requirement. Besides, the app can scan all the ConfigurationOfXXX and check for what ones are affected by a deletion of a package before permiting delete of the package. This way we can delete packages but also see what that will affect and correctly promptly. The point is, we need an independent, mostly never breaking metacello repository. Other idea will be to use google or github versioned repositories and from them build the published repo, so that when a package is deleted by accident or by mistake, it can be restored quickly. But I like more the previous version. What do you think? -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Feb. 23, 2010

Re: [Pharo-project] Browse classes with shortcut in merge

by Gary Chambers

In the latest Widgets/DiffTools on SqueakSource now. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 23, 2010 9:16 AM Subject: Re: [Pharo-project] Browse classes with shortcut in merge > Will happen in the next update :) > > On Feb 22, 2010, at 7:19 PM, Gary Chambers wrote: > >> Certainly possible. Needs an update for Polymorph as well as the Diff >> tools. >> Will only be available when the "changes tree" has keyboard focus, >> also... >> >> Will do cmd+n for senders, cmd+m for implementors and cmd+v for versions >> while at it. >> Also, I'll update the menu items to indicate shortcuts. >> >> Regards, Gary >> ----- Original Message ----- >> From: Mariano Martinez Peck >> To: Pharo Development >> Cc: Gary Chambers >> Sent: Friday, February 19, 2010 2:57 PM >> Subject: Browse classes with shortcut in merge >> >> Hi Gary: It would be cool to be able to browse a class (when selected) >> using the shortcut (cmd + b). Right now you only can browse it using >> right button -> Browse class >> >> Cheers >> >> Mariano >> _______________________________________________ >> 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

Feb. 23, 2010