- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: Sake, Packages, and deployment code

by StÃ©phane Ducasse

Begin forwarded message: > From: "Damien Pollet" <damien.pollet(a)gmail.com> > Date: November 11, 2008 10:35:49 PM CEST > To: "Keith Hodges" <keith_hodges(a)yahoo.co.uk> > Cc: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > Subject: Re: Sake, Packages, and deployment code > > On Tue, Nov 11, 2008 at 2:13 AM, Keith Hodges <keith_hodges(a)yahoo.co.uk > > wrote: >>> IMHO the root class should be packaged separately from its >>> subclasses, > > Also, part of the code is there to make the task-declaration DSLâ¦ it > would be nice if the DSL layer was documented as such and separated > from the implementation code. I guess SakeMeta separates it a bit > alreadyâ¦ maybe it would help me if I knew the implementation of rake, > but I don't :) > >> tasks are generally named task* , in "bob" build methods are named >> build*. > > ok. I'm not advocating for a particular prefix (maybe a short one like > pkg is best indeed). > >> However I dont see the problem with not having "task" in this >> context. I would prefer pkg* or package* , but I felt it looked >> untidy. > > Well, for one, it would be symmetrical with SUnit's test* methods. > Then, I think it's better to keep the convention that capitalized > names are for globals; think of analysis tools. Also, this is a whole > family of methods that are supposed to respect a few rules, so it's > better if they are easily identifiable; we can imagine that some day, > Slime will be extended with Sake-specific checks. > > As for utility methods, they are all defined in the root class > Packages, but I don't see why there couldn't be a need for some more > in a subclass, especially if you want to implement a kind of lazy > graph construction like in PRDistribution. > >> From what I understand you are simply suggesting that "sub- >> universes" be defined and available as SomeProject-Setup. That >> sounds fair enough, and is part of the original idea. > > Actually I'm not convinced that the central Universe approach really > works for the squeak community, since it's so divided. Application > developers have a precise knowledge of the dependancies of their own > packages. They could document the fine-grained dependancies in their > Foo-Setup (i.e. for Seaside, encode > http://code.google.com/p/seaside/wiki/LoadOrder) Then, if someone > wants to provide a universe-like larger-grained set of dependancies, > they can do so in a separate place, reusing dependancies from multiple > independently developed projects. > >> Will it catch on though... I expect that if I ever get to release >> 3.11 it will include LPF and sake-packages as standard (with the >> option to remove them) > > Well, as far as I am concerned, if the big modular packages like > Seaside/Magritte/Pier+addons/Moose adopt it, I consider it's caught on > :) > More than the features of sake over rake, I think it's whether it > enables the community to progress in a smoother way that will > determine success. For instance, I think SourceTalk and Bob should be > linked or even integrated someday, so that getting automatic builds > for a new project is near-instant. > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Nov. 12, 2008

[Pharo-project] Fwd: Sake, Packages, and deployment code

by StÃ©phane Ducasse

Begin forwarded message: > From: Tudor Girba <girba(a)iam.unibe.ch> > Date: November 11, 2008 11:55:21 AM CEST > To: Damien Pollet <damien.pollet(a)gmail.com> > Cc: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr>, keith_hodges(a)yahoo.co.uk > , "Damien Cassou" <damien.cassou(a)gmail.com> > Subject: Re: Sake, Packages, and deployment code > > I completely agree. This was also the plan for the Moose project. It > just did not get realized :). I have a similar set of scripts in VW. > > Unfortunately, I do not know Sake/Packages, but the idea of a > standard name and infrastructure for the set of loading scripts > would be super nice :). > > Cheers, > Doru > > > On Nov 10, 2008, at 10:59 PM, Damien Pollet wrote: > >> Hi, >> >> I'm looking at Sake and Packages, and I'm wondering if it would make >> sense to use them in a slightly different manner. >> Currently, the Sake-Package classes duplicate the various existing >> universes (most of them are generated from the universe >> descriptions), >> so for end-developers it's basically the same, except there is no >> nice >> OB-based UI for it. There is a difference though: sake package >> descriptions are saved in Monticello. >> >> What I'm thinking is, it would be nice to have a kind of deployment >> scripts for some projects, that is written and maintained by the >> project authors and not an external guy. For instance, Doru wrote >> PRDistribution to generate the Pier kernel in the one-click image, >> which is pre-filled with a set of pages, access rights, etc. The >> problem is, PRDistribution relies on all the code already being >> present, and will fail if you forgot to install Pier-Blog, for >> instance. >> >> So it would be nice if it was able to install the required packages >> form Magritte, Pier, and Pier-Addons. Then it would act as a clear >> entry point for users of the code, and a nice place for developers to >> put stuff that currently goes into class initialization methods (like >> the Licence-popping in magritte and pier, or the login/password >> stuff). >> >> The pattern could look like this: >> >> - application developersâ¦ >> package their application code in Foo-Subfoo packages >> package their tests in Foo-Tests packages >> package deployment stuff it Foo-Setup: dependancies between >> individual Foo-specific packages + dependancies to high-level >> external >> dependancies + deployment scripts like PRDistribution >> (maybe) copy snapshots of Foo-Setup to a common repository >> - code usersâ¦ >> know that Foo-Setup will help them get a working installation of >> Foo when they browse Squeaksource >> install Foo-Setup package using Installer, then call one of the >> sake tasks it defines (there can be several of them since they are >> quite high-level) >> - distribution maintainers (e.g. the other Damien)â¦ >> pull carefully chosen versions of Foo-Setup into their repository, >> and maybe maintain a distribution-specific -Setup package. >> >> What do you think? >> >> ps. remarks on Sake-Packagesâ¦ >> IMHO the root class should be packaged separately from its >> subclasses, >> since the former provides the code and the latter define the metadata >> for particular distributions. >> Also since the rules are somewhat like unit test methods, they could >> be named taskFoo instead of just Foo. That would differenciate sake >> rules from utility smalltalk methods. >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Relationships are of two kinds: those we choose and those that > happen. They both matter." > > > >

Nov. 12, 2008

[Pharo-project] Squeak Carbon OS-X VM 3.8.19beta2U ships

by John M McIntosh

Ken Brown was lucky enough to figure out that the 3.8.19beta1U VM won't launch on a 4GB Mac Pro when you have 27 other applications running. The 3.8.19beta2U VM has a fix to work around mmap issues when the operating system would rather load you at the 42GB boundary, versus our suggested 512MB. I've posted the new VM in the usual places via ftp or my idisk at http://www.smalltalkconsulting.com/squeak.html -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 12, 2008

[Pharo-project] Re: [squeak-dev] ANN Rio now supports ftp

by Keith Hodges

Now that the architecture for Rio is complete. Its time for a vote! Current usage.... 'someDir/someFile' asRio -> instance of Rio. 'someDir/newDir' asRio mkdir -> instance of Rio. 'someDir/file.zip' asRio zip -> instance of RioArchive. Could change to usage..... 'someDir/someFile' asFile. -> instance of File. 'someDir/newDir' asDirectory -> instance of Directory. 'someDir/file.zip' asFile zip -> instance of FileArchive. I like the original #asRio, and I wonder if there are any other smalltalks which already use #asFile and #asDirectory, and classes File and Directory. Nevertheless I can see why people would prefer the latter. votes? Keith

Nov. 11, 2008

Re: [Pharo-project] Sunit Extensions breaking the TestRunner

by bryce＠kampjes.demon.co.uk

Igor Stasenko writes: > 2008/11/11 <bryce(a)kampjes.demon.co.uk>: > > StÃÂ©phane Ducasse writes: > > > > > > Overrides are still something that we should avoid as much as possible. > > > > It's always possible to avoid overrides by having your own branch of a > > package. Exupery does that for VMMaker. That works with MC 1.x's > > merging, and allows it to track who's changed what to make it easier > > to follow downstream changes. > > > > It may work for VMMaker (because it is quite uncommon thing), but in > broader range it will introduce even more problems. > Going with your doctrine, there can be 10 developers, each forced to > maintain own version of some basic package with own overrides. > Now, if someone would want to use all 10 projects in single image, he > will have to deal with 10 different versions of same package. > The brave soul can go through all 10 versions, spend week or two > merging them into common base. > But i don't think he would want to repeat it over and over again, in > case he wants to update one of 10 packages to new version, where some > bugs fixed or new features added. In the case you describe you're better off using separate MC packages. You'd build your own image by merging each of the 10 developers changes together to make your own version. You're better off because MC will alert you if two of the package versions change the same method. If the changes in the separate package versions do not change the same methods then there will be no conflicts and no trouble merging. Using overrides, you're on your own tracking down conflicting changes and the only notification you'll get is the bugs produced. If one of the packages is updated, then with MC all you need to do is merge it in, MC will figure out if the new changes in that package conflict with something else. That's why I now maintain my own VMMaker packages instead of using overrides or change sets. The VMMaker base does change and sometimes methods I've changed change underneath me. It's too easy to badly break the VM trying to manage merging without utilising MCs capabilities and tracking down the breakage without decent tool support is very painful. I've done it with VMMaker before MC. I do use overrides if I need to change a single method in another package but even there I'd be tempted to keep the override in a separate override package to make them easier to find and to limit such overrides to optional functionality so users are not forced to use the override. There is one such override in Exupery itself. Bryce

Nov. 11, 2008

Re: [Pharo-project] OldSocket removal

by John M McIntosh

Well I'm still struggling with it, I spent a few hours last weekend working issues. One is that many of the tests I had depend on open port 7 (echo port) on a linux server somewhere and reflecting data to test send/receive. That fails because usually an arbitrary server on the internet doesn't have port 7 open. Let me bundle it up then and forward you a change set. On Nov 11, 2008, at 11:04 AM, Damien Cassou wrote: > Hi John, > > On Wed, Oct 22, 2008 at 10:24 PM, John M McIntosh > <johnmci(a)smalltalkconsulting.com> wrote: >> Ok, Michael R suggested I bundle these up, recheck them, so who >> would I send >> them to? > > > Could you please send what you've done? To me for example. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 11, 2008

Re: [Pharo-project] I would like to clean the inbox! Please read

by StÃ©phane Ducasse

Thanks I will have a look at it after kids readings :) Stef On Nov 11, 2008, at 7:51 PM, Damien Cassou wrote: > On Sat, Nov 8, 2008 at 1:45 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> For example, I asked you if you could redo your embedded world. > > Please review http://code.google.com/p/pharo/issues/detail?id=273. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 11, 2008

Re: [Pharo-project] OldSocket removal

by Damien Cassou

Hi John, On Wed, Oct 22, 2008 at 10:24 PM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > Ok, Michael R suggested I bundle these up, recheck them, so who would I send > them to? Could you please send what you've done? To me for example. -- Damien Cassou http://damiencassou.seasidehosting.st

Nov. 11, 2008

Re: [Pharo-project] I would like to clean the inbox! Please read

by Damien Cassou

On Sat, Nov 8, 2008 at 1:45 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > For example, I asked you if you could redo your embedded world. Please review http://code.google.com/p/pharo/issues/detail?id=273. -- Damien Cassou http://damiencassou.seasidehosting.st

Nov. 11, 2008

[Pharo-project] New pharo-dev based on 10144

by Damien Cassou

https://gforge.inria.fr/frs/download.php/10934/pharo0.1-10144dev08.11.3.zip Always downloadable from: http://code.google.com/p/pharo/wiki/Downloads -- Damien Cassou http://damiencassou.seasidehosting.st

Nov. 11, 2008