[squeak-dev] Re: [Pharo-project] Sake Basic Documentation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: [Pharo-project] Sake Basic Documentation

Stéphane Ducasse
>

I should really use Sake to understand it further.
Now what is clear to me is that I like the idea. We need something to  
write build script.

Now for the classTasks, I'm a bit worried that we can do this kind of  
actions
becuse it means that depending on the task used to create a given  
distribution
we can have a side effect method removed, added, class added ....

> 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 <[hidden email]>'.
>   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.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>