- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: Sake, Packages, and deployment code
by StÃ©phane Ducasse Nov. 12, 2008

Nov. 12, 2008

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 >

1 0

[Pharo-project] Fwd: Sake, Packages, and deployment code
by StÃ©phane Ducasse Nov. 12, 2008

Nov. 12, 2008

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." > > > >

1 0

[Pharo-project] Squeak Carbon OS-X VM 3.8.19beta2U ships
by John M McIntosh Nov. 12, 2008

Nov. 12, 2008

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 = = = ========================================================================

1 0

[Pharo-project] Re: [squeak-dev] ANN Rio now supports ftp
by Keith Hodges Nov. 11, 2008

Nov. 11, 2008

Rio has now been refactored so as to be cleaner and to avoid any such tricks as doesNotUnderstand: best regards Keith > *News:* > > Rio has finally made it to (roughly) where it was planned to be all along. > File manipulations that work locally should now also work remotely. > > e.g. > > dir := 'ftp://squeak:viewpoints@squeak.warwick.st/test/test/test' > asRio mkpath. > file := dir / 'hello.txt' contents: 'hello world'. > > next := file rename nextVersion. > next name. { hello.1.txt } > next fileSize. {11} > > next copyTo: 'local.txt' > > *Limitations:* > > Although you can obtain read or writeStreams directly into the remote > file, it is not random access (yet?) > therefore you cant currently write directly to the write stream of a > remote gzip file (which you can do locally) > > *More Info:* > > http://wiki.squeak.org/squeak/5929 > > cheers > > Keith > ------------------------------------------------------------------------ > > >

1 1

[Pharo-project] Sunit Extensions breaking the TestRunner
by StÃ©phane Ducasse Nov. 11, 2008

Nov. 11, 2008

Hi When I load SUnit in pharoBox I cannot run tests anymore! David Alex can you really check? Guys I appreciate your work but it would be great if you could test more what you are doing because I spent a lot of time on problems like that. Stef

7 21

[Pharo-project] I would like to clean the inbox! Please read
by StÃ©phane Ducasse Nov. 11, 2008

Nov. 11, 2008

So I will harvest what I can - collection - MC enh - copyright and I will move the rest to treated. Except I you shout and tell me that your code is ready for integration. Can somebody (lukas for example) have a look at the code of noury on package renaming. Noury told me that it worked since years but lukas told me that renaming is not supported in MC so I'm puzzled. Damien. P is your fix Name: System-damien.pollet.169 Author: damien.pollet Time: 26 October 2008, 6:31:21 pm UUID: 8baf2159-f018-43d3-b746- 5310f264ee81 Ancestors: System-damien.pollet.168 Set initials at the same time as name to avoid the infinite loop of Author>>initials ready? What is the status of the networkTests and Network submissions? Should I harvest them Stef

5 15

[Pharo-project] New pharo-dev based on 10144
by Damien Cassou Nov. 11, 2008

Nov. 11, 2008

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

1 0

[Pharo-project] New pharo-dev based on latest version
by Damien Cassou Nov. 11, 2008

Nov. 11, 2008

http://gforge.inria.fr/frs/download.php/10931/pharo0.1-10142dev08.11.2.zip always available at: http://code.google.com/p/pharo/wiki/Downloads?tm=2 -- Damien Cassou http://damiencassou.seasidehosting.st

6 16

[Pharo-project] Sake Basic Documentation
by Keith Hodges Nov. 11, 2008

Nov. 11, 2008

Introduction ============ Sake-Core -- is an attempt to provide similar functionality to Make and Rake, only using Smalltalk as the DSL. Sake-Packages -- is a reimplementation of Universes functionality, using Sake. It allows the metadata, load script, and unload script for a package to be defined as a Task. Sake-Scheduler -- provides the ability to register tasks to be performed periodically. Sake-Bob -- is a tool for building and testing images. (wip) Basics ====== Tasks are typically defined class side, but can be added to any class in the image. A typical task definition follows. MakeTheTea classSide >> #taskMakeTea SakeTask define: [ :task | task dependsOn: { MakeTheTea taskBoilWater. }. task if: [ Cup isEmpty ]. task action: [ Cup add: 'tea'; add: 'water'. ]. ]. To run the task: MakeTheTea taskMakeTea run. Alternatively #runStepping, or #runLogging are available for debugging. The main structure of a sake task is defined by #dependsOn: (or #addDependency:) , #if: , #action: (or #addAction:). These can all take either blocks, or lists of tasks, or lists of blocks. To see the heirarchy of tasks that will be traversed. MakeTheTea taskMakeTea what explore. Run Order ========= There are two algorithms available for determining task run order. (Further algorithms could be defined in order to support parallelism in processing.) Given a single top level task, standard Rake ordering, simply runs all the dependancies first, for every task. However Sake-Bob, when given a list of things to do, has to analyse the dependencies to determine which needs to go first. (Universes does this) Parameters ========== Unlike Rake, tasks can be defined in terms of parameters. The typical unparametized tasks found in Rake, #taskCreateMyStartingDirectory, can be written more generically as: #taskCreateStartingDirectory: name. e.g. task dependsOn: { self taskCreateStartingDirectory: 'wip' }. Class Tasks =========== In the following examples #Cup is used where the class Cup, is not guaranteed to exist. task dependsOn:{ (SakeTask class: #Cup) exists } "create a needed class" task dependsOn:{ (SakeTask class: Object) subclass: #Cup } "create a needed class" task dependsOn:{ (SakeTask class: Object) subclass: #Cup category:'Demo'} task dependsOn:{ (SakeTask class: #Cup) removeSelector: #tmp } task dependsOn:{ (SakeTask class: #Cup) removeSelectorsMatching: '*' } task dependsOn:{ (SakeTask class: #Cup) removeSelectorsMatching: '*' } task dependsOn:{ (SakeTask class: #Cup) ifExistsDo: [ :c | c rename: #Glass ] } MetaData ======== Each Sake task contains a dictionary, SakeInfo that can be used simply to store any arbitrary metadata. task info someField: someValue. Sake-Packages uses metadata extensively, in this case the typical use pattern is begin with a subclass of SakeTask and to define the generic task on the class side and the metadata on the instance side. SakeTask subclass: MakeADrink. MakeADrink classSide >> #taskPourADrink: aDrink self define: [ :task | task perform: aDrink. task if: [ Bar containsBottle: task info name ]. task action: [ Glass add: (task info name). ]. ]. Documentation Methods ===================== Subclasses of SakeTask, utilise a specialised compiler, which allows raw text to be stored in instance side methods following six quotes. """""" aTaskClass at: selector category: cat putMethod: code doc: content aTaskClass docAt: selector. This is used by the Mantis package to pull raw data from mantis, so that subsequent tasks can process that data. SakeSignal and trace: ===================== If a task needs to communicate with the outside context, it can sends a SakeSignal, a utility method is provided for this. task lookup: #aSelector. The outside context can return a value, by defining an exception handler for SakeSignal. The default implementation of #trace: is used in Sake-Tests for a task to signal to the outside testing context what it is doing. Tasks send #trace: and the SakeTaskTest runCaseWith: block, defines an exception handler to collect the signalled values so as to record the actions of the tasks. For the tests to pass all of the required actions must have been signalled. SakeStep and SakeStop ===================== task step: 'Are you Sure'. Signals a notifier to request confirmation. task stop: 'It Broke'. Finishes processing. Task Extensions =============== In the same manner as magritte. A class side task definition may be extended by another package. #taskDoThis, may be extended by adding the extension method, #taskDoThisAndAlso: task. task addDependency: [ ... ]. task addAction: [...]. Answering Notifications ======================= Tasks are wrapped in notification handlers, to use them: task answer: '*password*' with: 'secret'. ================================ Sake. Below is a SakeTask as generated from the universes package definition. What follows is a "method", in the class PackagesSqueak310U. So here is a Sake Task Definition for Seaside.... (info is simply a dictionary for non-essential meta information) ---------- PackagesSqueak310U -i- Seaside self name: 'Seaside'. info category: 'Web Development'. info description: 'A framework for building sophisticated web applications in Squeak. Develop for the web using reusable, embeddable components and unique call/return semantics for moving between pages.'. info maintainer: 'Lukas Renggli <renggli(a)gmail.com>'. info homepage: 'http://www.seaside.st/'. info squeakMapID: ''. info url: 'http://www.squeaksource.com/Seaside/Seaside2.8a1-lr.522.mcz'. info version: '2.8.522'. info provides: #(). self dependsOn: #('KomHttpServer'). self load: [ Installer installUrl:'http://www.squeaksource.com/Seaside/Seaside2.8a1-lr.522.mcz'. ]. self unloadDependsOn: { self taskUnloadDependants }. self unload: [ Installer unload: 'Seaside'. ]. ------------- Notice that we have an unload block as well as a load block! This is a new and very experimental feature, we can now define unload scripts for each package, and Sake/Packages provides a way to capture and publish them for some or all image versions. Indeed this feature is barely tested, I mention it here simply to intoduce the concept. usage: PackagesSqueak310 new Seaside load. or, (PackagesSqueak310 named:'Seaside') load. PackagesSqueak310 new Seaside unload. or, (PackagesSqueak310 named:'Seaside') unload. Packages/Sake is also supported by Installer in a manner similar to universes support, e.g. Installer sake addPackage: 'PackagesA'; addPackage: 'PackageB'; install. enjoy... best regards Keith p.s. to load Installer install: 'Packages'. ========== Addendum: Sake/Packages no longer uses blocks as standard, but the principle is the same.

2 2

[Pharo-project] Installer Bug ?
by jannik.laval.gmail Nov. 11, 2008

Nov. 11, 2008

Hi all, I'm testing Installer, and I have a problem. When I do this : (Installer sm package: 'Labby & Walker'; versions) explore. I have a list of 3 elements (there are three versions), it is ok. But these elements are InstallerSqueakMap which contain a list of packages with the first is the name 'Labby & Walker' and the others elements are the three versions. I think it is strange to have this structure. I think a good result would be : - just one InstallerSqueakMap with the three versions inside (in the variable 'packages') - or an orderedCollection with each version. Anybody could test and help me? maybe we could correct this? Thanks Jannik

2 2