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

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

by Dale Henrichs

----- "Torsten Bergmann" <astares(a)gmx.de> wrote: | 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. Torsten, Just for the record. I truly look forward to the day when a better package management system comes along. If Metacello spurs some folks with "obviously better ideas" to produce a Package Management system that we can all use, then it will have been worth the effort:) Until the better mousetrap appears, I will continue to slog along on Metacello. Dale

Feb. 24, 2010

Re: [Pharo-project] hex

by Nicolas Cellier

The main reason for not using lowercase in squeak was Dan extension of number with radix plus exponent. 16r8e7 -> 16r8 * (16 raisedTo: 7) and the Float variations... If you decided to abandon this notation, then go with either upper or lower. But a bit of consistency could help... Nicolas 2010/2/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Ok thanks. > > " > The UUID spec (RFC 4122) allows both upper and lower case hex digits, so I don't see a reason not to. > > " > Bert > > > On Feb 23, 2010, at 10:43 PM, Eliot Miranda wrote: > >> >> >> On Tue, Feb 23, 2010 at 1:25 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> in pharo >> >> #[122 43 213 7] hex = '7A2BD507' >> >> in squeak >> >> #[122 43 213 7] hex = '7a2bd507' >> >> do you think that it makes a difference? >> >> >> Much of the "rest of the world" (e.g. gdb, md5sum) uses lower case. Â Personally I find lower-case much easier to read because I find the lower-case letters visually more different from the digits than the upper case letters. Â For these two reasons I prefer lower-case. Â I haven't always been this way. Â I used to prefer upper case because I think the upper case letters look neater, having the same height as the digits. Â But now I prefer legibility over neatness. >> >> 2Â¢ >> >> Eliot >> >> Stef >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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

Re: [Pharo-project] withAllSubclasses -> Set or OrderedCollection

by Nicolas Cellier

The single inheritance hierarchy is a Tree... I don't see any interest in answering a Set. Some tools might expect a Set... If so, they just have to use withAllSubclasses asSet. If my own tool expect a LinkedList, I ain't gonna change the Kernel library for my conveniency, or am I ? Nicolas 2010/2/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Nicolas I remember that we discussed this point or a related one a while ago > > Squeak > > Â Â Â Â Point withAllSubclasses > Â Â Â Â Â Â Â Â an OrderedCollection(Point) > > > Pharo > > Â Â Â Â Point withAllSubclasses > Â Â Â Â Â Â Â Â a Set(Point) > > Do you remember? > I forgot? > > Stef > > > > > > > _______________________________________________ > 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

[Pharo-project] withAllSubclasses -> Set or OrderedCollection

by StÃ©phane Ducasse

Nicolas I remember that we discussed this point or a related one a while ago Squeak Point withAllSubclasses an OrderedCollection(Point) Pharo Point withAllSubclasses a Set(Point) Do you remember? I forgot? Stef

Feb. 23, 2010

Re: [Pharo-project] hex

by StÃ©phane Ducasse

Ok thanks. " The UUID spec (RFC 4122) allows both upper and lower case hex digits, so I don't see a reason not to. " Bert On Feb 23, 2010, at 10:43 PM, Eliot Miranda wrote: > > > On Tue, Feb 23, 2010 at 1:25 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > in pharo > > #[122 43 213 7] hex = '7A2BD507' > > in squeak > > #[122 43 213 7] hex = '7a2bd507' > > do you think that it makes a difference? > > > Much of the "rest of the world" (e.g. gdb, md5sum) uses lower case. Personally I find lower-case much easier to read because I find the lower-case letters visually more different from the digits than the upper case letters. For these two reasons I prefer lower-case. I haven't always been this way. I used to prefer upper case because I think the upper case letters look neater, having the same height as the digits. But now I prefer legibility over neatness. > > 2Â¢ > > Eliot > > Stef > > > _______________________________________________ > 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

Re: [Pharo-project] hex

by Eliot Miranda

On Tue, Feb 23, 2010 at 1:25 PM, stephane ducasse <stephane.ducasse(a)free.fr>wrote: > in pharo > > #[122 43 213 7] hex = '7A2BD507' > > in squeak > > #[122 43 213 7] hex = '7a2bd507' > > do you think that it makes a difference? > Much of the "rest of the world" (e.g. gdb, md5sum) uses lower case. Personally I find lower-case much easier to read because I find the lower-case letters visually more different from the digits than the upper case letters. For these two reasons I prefer lower-case. I haven't always been this way. I used to prefer upper case because I think the upper case letters look neater, having the same height as the digits. But now I prefer legibility over neatness. 2Â¢ Eliot > > Stef > > > _______________________________________________ > 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

[Pharo-project] hex

by stephane ducasse

in pharo #[122 43 213 7] hex = '7A2BD507' in squeak #[122 43 213 7] hex = '7a2bd507' do you think that it makes a difference? Stef

Feb. 23, 2010

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

by Janko MivÅ¡ek

What if use redudancy features of Internet itself? As you know the Internet was designed to withstand a nuclear attack, with a lot of redudant features, which we can explore to harden the Smalltalk infracture as well. In the similar ways as guyss like Google do. You know, they have always a single entry, http://www.google.com, but actually they direct your search to 1000s and milions of their servers behind. A mini version of Google can be use for Squeak or PharoSource as well. As I can see the Monticello repositories are basically the stateless WebDAV enabled Apache web servers. So having a mirror is a first thing to do. To still have a single entry point like http://www.squeaksource.com) we can exploit the redundancy feature of DNS: round robin entries. That is, you enter two entries in DNS zone, with the same name but different IP addresses, say: squeaksource.com www IN A 87.54.32.108 www IN A 212.18.45.87 This way in the case of failure of one server, the another one will responds. If both are working, DNS will return one of them in roun robin fashion. This will work for WebDAV part of the story, but we still need to tackle of the statefull web application of SqueakSource... hmm, a bit more thinking is needed therefore... Best regards Janko On 23. 02. 2010 19:48, Dale Henrichs wrote: > I like the notion of a secondary repository for packages. It is absolutely necessary to protect us from a catastrophic failure with any one of the SqueakSource repositories. > > Perhaps Gofer can be provided with a secondary repository location in the case when the primary repository fails. > > With this kind of approach, the metacello configurations can continue to reference the primary development repository, in this way we might just be able to have our cake and eat it too:) The Pharo secondary repository would protect users from repository volatility and package volatility ... Once a version is published in Pharo you can count of being able to load that version over time. > > This secondary repository could be maintained by periodically scanning the Pharo configurations and copying the referenced packages from the primary repository to a known secondary repository (this repository could just be done with Apache file access since a fancy UI for the secondary repository isn't essential). > > Having code and processes in place means that individuals can reuse the code and process to maintain their own secondary repository for their own production environment. > > I have code that does most of what is needed, as I use this process at GemStone for archiving the configurations and mcz packages in our company source code control system. > > Dale > ----- "GÃ¶ran Krampe" <goran(a)krampe.se> wrote: > > | 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 > | > | > | _______________________________________________ > | 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 -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Feb. 23, 2010

Re: [Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)

by Alexandre Bergel

Doru did some experiement with Mondrian I believe. Cheers, Alexandre On 23 Feb 2010, at 13:25, Gary Chambers wrote: > Some kind of graph-based GUI would certainly help in this scenario to > visualise the dependencies/changes... just a thought. > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, February 23, 2010 4:02 PM > Subject: [Pharo-project] Source code management - my vision. (Was: > Re: Why > apackage management system) > > >> Since Goran mentioned DeltaStreams, i'd like to share one of my >> ideas, >> which came into my mind, when i complete coding the method trailers. >> >> I made a method trailers open for future extensions. >> A first step would be to introduce an abstract 'source management' >> layer, which will be responsible for delivering >> a method's and classes sources from some abstract data source. The >> next step is actually implement such data sources. >> >> So, the idea is to abandon hardwiring with .sources and .changes >> files. >> What new opportunities it gives to us? >> Suppose that instead of storing sources into file, you putting them >> directly to database , such as CouchDB (yes! :). >> >> Now if you imagine that anyone could access to this database on some >> public location, this means that we automagically made a source code >> exchange hub, and could do a very cool things with it. >> >> Suppose that ALL source code is put into a single database. Now >> different users creating own accounts and makind own 'forks' from >> original. What we getting is a number of update streams (methods, >> doits etc etc), which lying in those databases, >> and if one user wants to load/merge code from one of the sources he >> simply points to it and it get loaded into his image. >> We could organize things very closely to what github currently is: >> everyone could create any number of new projects, or forks of >> existing >> ones. Freely exchange the code, do a cherry picking etc etc. >> And what is most important, that with such organization you can track >> any methods, classes in the image and their evolutionary history back >> to its origin. As well as, you can query database, how an when a >> concrete method/class get deleted (everything is recorded, not just >> current state). >> >> Also, it would allow us to manipulate the code at the lowest level of >> granularity (individual methods/classes/doits, same as DS does), not >> at a package level. >> There are a lot of synergy with DeltaStreams - it could serve as an >> 'offline' format, in same way as git storing the files locally, but >> can reconnect with remote storage (which can be a public database). >> One of the things, which could be made is to allow stashing/popping >> code from stash. Suppose two projects started from a single starting >> point (Squeak 3.9). Now suppose that by clicking a single button you >> could get either trunk image, or Pharo 1.0 image. >> But that's not all! With DeltaStreams, you could then click once >> more, >> and revert things back from , say Pharo 1.0 to trunk or vice versa :) >> Of course it would be stupid to do things at such large scale, but if >> we put some common 'root' stuff into database, then we could very >> easily track all changes & compare them. This would make cherry >> picking and code exchange much more easier. >> >> This could get us on the next level of code management and system >> organization and organization of community efforts. >> >> >> >> 2010/2/23 GÃ¶ran Krampe <goran(a)krampe.se>: >>> 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 >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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] Shout

by StÃ©phane Ducasse

Hi guys I would like to know which version of shout we are using and relying on. Apparently one version was integrated on squeak and I would like to make sure that the one we use continue to get improved. One of these days we will have to think about the status of important packages that are external to pharo: shout, XMLSupport.... Stef

Feb. 23, 2010