Dear All,
Sake/Packages is now at a point where it is a useful resource for the community to contribute to. To help this along I have set the squeaksource.com commit emails to go to packages@lists.squeakfoundation.com Discussion as to what should go where and whether or not specific configurations work or not can be directed there also. I believe that the Sake/Packages package definitions will be a useful resource for all of the Squeak communities.
Please join me in in this knowledge gathering exercise, please bring what you know about what loads where and feel free to fill in the package definitions. Its very easy, I updated all of Seaside/Scriptaculous in 3.7 through to 3.10 in about 10 mins.
To load Sake/Packages into a LevelPlayingField (LPF) image:
Installer install: 'Packages'.
If you want to maintain all of the published versions of your package you may prefer to load.
Installer install: 'PackageAllVersions'.
If you are using squeak 3.10 the following hierarchy of classes will load.
1. Packages - Abstract Base Class
2. PackagesAllVersions - Non-specific package definitions that load the latest version, if that version is likely (but not 100% guarenteed) to work in all versions. You don't have to wait for your package to be perfect, to put a generic definition in here, enabling your users to try it out in their favourite squeak version, and provide you with feedback.
3. PackagesSqueak310beta - Non-specific package definitions that load the very latest version, specific to 3.10. Again it is expected to work, but the author may not have actually tested your configuration.
4. PackagesSqueak310U - The specific exact published version in Universes that is supposed to have been tested in that image version.
5. PackagesSqueak310 - The specific exact version that 'you'/'we' have found 'actually' works, overriding the universes definition.
Make it easy for Authors and Users. ==========================
Benefits for Authors - You do not have to constantly update your published packages all the time, you can publish a "load latest" script in the generic (2. 3.) levels of the hierarchy.
Benefits for Users ============= Quality
The community can clearly identify and publish what works where, and this provides a shared collective whiteboard in which active collaboration can take place. In addition, if a specific version in a specific image needs a patch to work, then it can actually be included in the load script for that package. Thus for the first time patches can be included in published packages, and released for testing, without the bottleneck of waiting for the Package author to get around to fixing the problem for your squeak-fork. Those who submit patches will actually see their work get used immediately.
Automation
All installation scripts should run without interaction, for automated installation. See 'Seaside' for an example.
Deterministic Builds (potentially*)
All of the package definitions, for the image you are using are version controlled in monticello. So you can go back to a previous configuration from a previous date and load it. *The packages you are loading have to be listed to nominate specific packages for this to work.
Flexibility
Have your own package definitions for your own squeak fork, subclass to specialize/override etc etc.
I declare Sake/Packages for squeak open!
enjoy
Keith
===
btw... LevelPlayingField is currently broken in 3.8.1 and I dont have time to fix it, the SqueakMap update process chokes it. to do: Sake/Packages-SqueakMap the same scheme for
p.s. In case anyone wonders... the packages mailing list has not been used for ~ 3 years. I emailed the packages mailing over a year ago and discussed its use for this purpose with anyone who cared.
I declare Sake/Packages for squeak open!
Great. It leaves only one question open: What *is* "Sake/Packages for Squeak"? You are describing nicely everything around it just not what it is... some clarification would be welcome ;-)
Cheers, - Andreas
Keith Hodges wrote:
Dear All,
Sake/Packages is now at a point where it is a useful resource for the community to contribute to. To help this along I have set the squeaksource.com commit emails to go to packages@lists.squeakfoundation.com Discussion as to what should go where and whether or not specific configurations work or not can be directed there also. I believe that the Sake/Packages package definitions will be a useful resource for all of the Squeak communities.
Please join me in in this knowledge gathering exercise, please bring what you know about what loads where and feel free to fill in the package definitions. Its very easy, I updated all of Seaside/Scriptaculous in 3.7 through to 3.10 in about 10 mins.
To load Sake/Packages into a LevelPlayingField (LPF) image:
Installer install: 'Packages'.
If you want to maintain all of the published versions of your package you may prefer to load.
Installer install: 'PackageAllVersions'.
If you are using squeak 3.10 the following hierarchy of classes will load.
Packages - Abstract Base Class
PackagesAllVersions - Non-specific package definitions that load the
latest version, if that version is likely (but not 100% guarenteed) to work in all versions. You don't have to wait for your package to be perfect, to put a generic definition in here, enabling your users to try it out in their favourite squeak version, and provide you with feedback.
- PackagesSqueak310beta - Non-specific package definitions that load
the very latest version, specific to 3.10. Again it is expected to work, but the author may not have actually tested your configuration.
- PackagesSqueak310U - The specific exact published version in
Universes that is supposed to have been tested in that image version.
- PackagesSqueak310 - The specific exact version that 'you'/'we' have
found 'actually' works, overriding the universes definition.
Make it easy for Authors and Users.
Benefits for Authors - You do not have to constantly update your published packages all the time, you can publish a "load latest" script in the generic (2. 3.) levels of the hierarchy.
Benefits for Users
Quality
The community can clearly identify and publish what works where, and this provides a shared collective whiteboard in which active collaboration can take place. In addition, if a specific version in a specific image needs a patch to work, then it can actually be included in the load script for that package. Thus for the first time patches can be included in published packages, and released for testing, without the bottleneck of waiting for the Package author to get around to fixing the problem for your squeak-fork. Those who submit patches will actually see their work get used immediately.
Automation
All installation scripts should run without interaction, for automated installation. See 'Seaside' for an example.
Deterministic Builds (potentially*)
All of the package definitions, for the image you are using are version controlled in monticello. So you can go back to a previous configuration from a previous date and load it. *The packages you are loading have to be listed to nominate specific packages for this to work.
Flexibility
Have your own package definitions for your own squeak fork, subclass to specialize/override etc etc.
I declare Sake/Packages for squeak open!
enjoy
Keith
===
btw... LevelPlayingField is currently broken in 3.8.1 and I dont have time to fix it, the SqueakMap update process chokes it. to do: Sake/Packages-SqueakMap the same scheme for
p.s. In case anyone wonders... the packages mailing list has not been used for ~ 3 years. I emailed the packages mailing over a year ago and discussed its use for this purpose with anyone who cared.
On Apr 19, 2008, at 22:16 , Andreas Raab wrote:
I declare Sake/Packages for squeak open!
Great. It leaves only one question open: What *is* "Sake/Packages for Squeak"? You are describing nicely everything around it just not what it is... some clarification would be welcome ;-)
This also tends to drive me nuts...anyway:
Begin forwarded message:
From: Keith Hodges keith_hodges@yahoo.co.uk Date: April 8, 2008 22:50:12 PDT To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
Subject: [squeak-dev] Sake/Packages Reply-To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org
For those not familiar with the idea, Sake is an attempt to provide similar functionality to Make and Rake, only using Smalltalk as the DSL. I hope that Sake is simple and sufficiently useful for all Squeak forks make use of it.
Hello Andreas,
there is a detailed previous Sake/Packages thread form the 9th April 2008
regards
Keith
El 4/19/08 11:18 PM, "Keith Hodges" keith_hodges@yahoo.co.uk escribió:
Dear All,
Sake/Packages is now at a point where it is a useful resource for the community to contribute to. To help this along I have set the squeaksource.com commit emails to go to packages@lists.squeakfoundation.com Discussion as to what should go where and whether or not specific configurations work or not can be directed there also. I believe that the Sake/Packages package definitions will be a useful resource for all of the Squeak communities.
Please join me in in this knowledge gathering exercise, please bring what you know about what loads where and feel free to fill in the package definitions. Its very easy, I updated all of Seaside/Scriptaculous in 3.7 through to 3.10 in about 10 mins.
I can't wait for KPHSqueak ....
Hi Keith, "Keith Hodges" keith_hodges@yahoo.co.uk wrote in message news:480AA7E5.2020401@yahoo.co.uk...
Dear All,
Sake/Packages is now at a point where it is a useful resource for the community to contribute to. To help this along I have set the squeaksource.com commit emails to go to packages@lists.squeakfoundation.com Discussion as to what should go
.com ? did you mean .org ?
where and whether or not specific configurations work or not can be directed there also. I believe that the Sake/Packages package definitions will be a useful resource for all of the Squeak communities.
Please join me in in this knowledge gathering exercise, please bring what you know about what loads where and feel free to fill in the package definitions. Its very easy, I updated all of Seaside/Scriptaculous in 3.7 through to 3.10 in about 10 mins.
To load Sake/Packages into a LevelPlayingField (LPF) image:
Installer install: 'Packages'.
If you want to maintain all of the published versions of your package you may prefer to load.
Installer install: 'PackageAllVersions'.
I think you meant to write... Installer install: 'PackagesAllVersions' (s was missing from end of Packages)
If you are using squeak 3.10 the following hierarchy of classes will load.
Packages - Abstract Base Class
PackagesAllVersions - Non-specific package definitions that load the
latest version, if that version is likely (but not 100% guarenteed) to work in all versions. You don't have to wait for your package to be perfect, to put a generic definition in here, enabling your users to try it out in their favourite squeak version, and provide you with feedback.
- PackagesSqueak310beta - Non-specific package definitions that load the
very latest version, specific to 3.10. Again it is expected to work, but the author may not have actually tested your configuration.
- PackagesSqueak310U - The specific exact published version in Universes
that is supposed to have been tested in that image version.
- PackagesSqueak310 - The specific exact version that 'you'/'we' have
found 'actually' works, overriding the universes definition.
I can see that I have this hierarchy of classes. Let's try loading something that I know about. I am using developer image sq3.10-7159dev08.04.1 , and I can see that PackagesSqueak310U has a method #FreeTypePlus, so let's try loading that.
From the class comment(s) , I work out that I need to evaluate this...
(Packages universe load: 'FreeTypePlus') run
I get a walkback, looks like there is a bug in the universe method, I don't think it should have ' new' at the end. Ok. Let's try...
(Packages current load: 'FreeTypePlus') run.
That works. It's loading... I get an error when it tries to load the dependent package 'FFI', but I expected that. I have a patch on mantis to get FFI to load, so let's edit the entry for FFI to load that patch first.... self load: [ (Installer mantis) bug: 6952 fix: 'ClassBuilder-nameinEnvironmentsubclassOftypeinstanceVariableNamesclassVariableNamespoolDictionariescategoryunsafe.st'. Installer installUrl:'http://map.squeak.org/accountbyid/cf58c358-46ee-465e-b6db-2740e9b32a53/files...'. ].
and try again.... It gets further, and fails after loading FreeTypePlus when trying to load the fonts from the OS. I know what this is, the initialize methods are run in a different order with MC1.5.
After a couple of hours trial and error, I have a new class, PackagesSqueak310 subclass: #PackagesSqueak310dev0804, which allows FreeTypePlus and FFI to load into sq3.10-7159dev08.04.1.
Having committed the modified Packages-Squeak310 to http://www.squeaksource.com/Packages , I note that subsequent invocations of... Installer install: 'PackagesAllVersions' cause my new class to be loaded. So it is installing the most recent version of Packages-Squeak310 ?
I can now evaluate... (PackagesSqueak310dev0804 load: 'FreeTypePlus') run. and FreeTypePlus & FFI get loaded.
I'm not suggesting for one moment that any of this is a substitute for fixing underlying bugs/problems in packages and installers; but it seems to be a very useful tool for documenting those problems and providing workarounds.
Now, I wonder, did I do the right thing in creating the PackagesSqueak310dev0804 class? Is it a good name? Were you expecting people to do this kind of thing for specific versions of particular forks/distributions? Was I right to add my class to Packages-Squeak310, or should I have created a separate package?
Cheers, Andy
Hello Andrew,
Thanks for having a go, and working throught the wrinkles... I was very tired last night.
Sake really deserves some mre documentation, and more tests, but I just dont have time at the moment.
There is some in class comments.
Hi Keith, "Keith Hodges" keith_hodges@yahoo.co.uk wrote in message news:480AA7E5.2020401@yahoo.co.uk...
Dear All,
Sake/Packages is now at a point where it is a useful resource for the community to contribute to. To help this along I have set the squeaksource.com commit emails to go to packages@lists.squeakfoundation.com Discussion as to what should go
.com ? did you mean .org ?
indeed, tiredness getting the better of me there.
where and whether or not specific configurations work or not can be directed there also. I believe that the Sake/Packages package definitions will be a useful resource for all of the Squeak communities.
Please join me in in this knowledge gathering exercise, please bring what you know about what loads where and feel free to fill in the package definitions. Its very easy, I updated all of Seaside/Scriptaculous in 3.7 through to 3.10 in about 10 mins.
To load Sake/Packages into a LevelPlayingField (LPF) image:
Installer install: 'Packages'.
If you want to maintain all of the published versions of your package you may prefer to load.
Installer install: 'PackageAllVersions'.
I think you meant to write... Installer install: 'PackagesAllVersions' (s was missing from end of Packages)
and there
If you are using squeak 3.10 the following hierarchy of classes will load.
Packages - Abstract Base Class
PackagesAllVersions - Non-specific package definitions that load
the latest version, if that version is likely (but not 100% guarenteed) to work in all versions. You don't have to wait for your package to be perfect, to put a generic definition in here, enabling your users to try it out in their favourite squeak version, and provide you with feedback.
- PackagesSqueak310beta - Non-specific package definitions that load
the very latest version, specific to 3.10. Again it is expected to work, but the author may not have actually tested your configuration.
- PackagesSqueak310U - The specific exact published version in
Universes that is supposed to have been tested in that image version.
- PackagesSqueak310 - The specific exact version that 'you'/'we'
have found 'actually' works, overriding the universes definition.
I can see that I have this hierarchy of classes. Let's try loading something that I know about. I am using developer image sq3.10-7159dev08.04.1 , and I can see that PackagesSqueak310U has a method #FreeTypePlus, so let's try loading that.
From the class comment(s) , I work out that I need to evaluate this...
(Packages universe load: 'FreeTypePlus') run
that should work now.
I get a walkback, looks like there is a bug in the universe method, I don't think it should have ' new' at the end. Ok. Let's try...
(Packages current load: 'FreeTypePlus') run.
This is the correct usage, it loads the universe definition, overridden with the current definitions if present.
That works. It's loading... I get an error when it tries to load the dependent package 'FFI', but I expected that. I have a patch on mantis to get FFI to load, so let's edit the entry for FFI to load that patch first.... self load: [ (Installer mantis) bug: 6952 fix: 'ClassBuilder-nameinEnvironmentsubclassOftypeinstanceVariableNamesclassVariableNamespoolDictionariescategoryunsafe.st'.
InstallerinstallUrl:'http://map.squeak.org/accountbyid/cf58c358-46ee-465e-b6db-2740e9b32a53/files...'.
].
and try again.... It gets further, and fails after loading FreeTypePlus when trying to load the fonts from the OS. I know what this is, the initialize methods are run in a different order with MC1.5.
After a couple of hours trial and error, I have a new class, PackagesSqueak310 subclass: #PackagesSqueak310dev0804, which allows FreeTypePlus and FFI to load into sq3.10-7159dev08.04.1.
Great!
If the dev image returns Squeak3.10 from
SystemVersion current majorAndMinorVersion
then your contribution to the world of knowledge about Squeak310, should go into PackgesSqueak310.
Having committed the modified Packages-Squeak310 to http://www.squeaksource.com/Packages , I note that subsequent invocations of... Installer install: 'PackagesAllVersions' cause my new class to be loaded. So it is installing the most recent version of Packages-Squeak310 ?
I can now evaluate... (PackagesSqueak310dev0804 load: 'FreeTypePlus') run. and FreeTypePlus & FFI get loaded.
Pacakges current load: 'FreeTypePlus'. should work too.
I'm not suggesting for one moment that any of this is a substitute for fixing underlying bugs/problems in packages and installers; but it seems to be a very useful tool for documenting those problems and providing workarounds.
Now, I wonder, did I do the right thing in creating the PackagesSqueak310dev0804 class? Is it a good name? Were you expecting people to do this kind of thing for specific versions of particular forks/distributions? Was I right to add my class to Packages-Squeak310, or should I have created a separate package?
add your improved definitions to the PackagesSqueak310 class itself, no need for another class (unless its another version of squeak entirely.
Cheers, Andy
great stuff
Keith
(resend)
Hello Andrew,
Thanks for having a go, and working throught the wrinkles... I was very tired last night.
Sake really deserves some mre documentation, and more tests, but I just dont have time at the moment.
There is some in class comments.
Hi Keith, "Keith Hodges" keith_hodges@yahoo.co.uk wrote in message news:480AA7E5.2020401@yahoo.co.uk...
Dear All,
Sake/Packages is now at a point where it is a useful resource for the community to contribute to. To help this along I have set the squeaksource.com commit emails to go to packages@lists.squeakfoundation.com Discussion as to what should go
.com ? did you mean .org ?
indeed, tiredness getting the better of me there.
where and whether or not specific configurations work or not can be directed there also. I believe that the Sake/Packages package definitions will be a useful resource for all of the Squeak communities.
Please join me in in this knowledge gathering exercise, please bring what you know about what loads where and feel free to fill in the package definitions. Its very easy, I updated all of Seaside/Scriptaculous in 3.7 through to 3.10 in about 10 mins.
To load Sake/Packages into a LevelPlayingField (LPF) image:
Installer install: 'Packages'.
If you want to maintain all of the published versions of your package you may prefer to load.
Installer install: 'PackageAllVersions'.
I think you meant to write... Installer install: 'PackagesAllVersions' (s was missing from end of Packages)
and there
If you are using squeak 3.10 the following hierarchy of classes will load.
Packages - Abstract Base Class
PackagesAllVersions - Non-specific package definitions that load
the latest version, if that version is likely (but not 100% guarenteed) to work in all versions. You don't have to wait for your package to be perfect, to put a generic definition in here, enabling your users to try it out in their favourite squeak version, and provide you with feedback.
- PackagesSqueak310beta - Non-specific package definitions that load
the very latest version, specific to 3.10. Again it is expected to work, but the author may not have actually tested your configuration.
- PackagesSqueak310U - The specific exact published version in
Universes that is supposed to have been tested in that image version.
- PackagesSqueak310 - The specific exact version that 'you'/'we'
have found 'actually' works, overriding the universes definition.
I can see that I have this hierarchy of classes. Let's try loading something that I know about. I am using developer image sq3.10-7159dev08.04.1 , and I can see that PackagesSqueak310U has a method #FreeTypePlus, so let's try loading that.
From the class comment(s) , I work out that I need to evaluate this...
(Packages universe load: 'FreeTypePlus') run
that should work now.
I get a walkback, looks like there is a bug in the universe method, I don't think it should have ' new' at the end. Ok. Let's try...
(Packages current load: 'FreeTypePlus') run.
This is the correct usage, it loads the universe definition, overridden with the current definitions if present.
That works. It's loading... I get an error when it tries to load the dependent package 'FFI', but I expected that. I have a patch on mantis to get FFI to load, so let's edit the entry for FFI to load that patch first.... self load: [ (Installer mantis) bug: 6952 fix: 'ClassBuilder-nameinEnvironmentsubclassOftypeinstanceVariableNamesclassVariableNamespoolDictionariescategoryunsafe.st'.
InstallerinstallUrl:'http://map.squeak.org/accountbyid/cf58c358-46ee-465e-b6db-2740e9b32a53/files...'.
].
and try again.... It gets further, and fails after loading FreeTypePlus when trying to load the fonts from the OS. I know what this is, the initialize methods are run in a different order with MC1.5.
After a couple of hours trial and error, I have a new class, PackagesSqueak310 subclass: #PackagesSqueak310dev0804, which allows FreeTypePlus and FFI to load into sq3.10-7159dev08.04.1.
Great!
If the dev image returns Squeak3.10 from
SystemVersion current majorAndMinorVersion
then your contribution to the world of knowledge about Squeak310, should go into PackgesSqueak310.
Having committed the modified Packages-Squeak310 to http://www.squeaksource.com/Packages , I note that subsequent invocations of... Installer install: 'PackagesAllVersions' cause my new class to be loaded. So it is installing the most recent version of Packages-Squeak310 ?
I can now evaluate... (PackagesSqueak310dev0804 load: 'FreeTypePlus') run. and FreeTypePlus & FFI get loaded.
Pacakges current load: 'FreeTypePlus'. should work too.
I'm not suggesting for one moment that any of this is a substitute for fixing underlying bugs/problems in packages and installers; but it seems to be a very useful tool for documenting those problems and providing workarounds.
Now, I wonder, did I do the right thing in creating the PackagesSqueak310dev0804 class? Is it a good name? Were you expecting people to do this kind of thing for specific versions of particular forks/distributions? Was I right to add my class to Packages-Squeak310, or should I have created a separate package?
add your improved definitions to the PackagesSqueak310 class itself, no need for another class (unless its another version of squeak entirely.
Cheers, Andy
great stuff
Keith
Installer install: 'Packages'.
If you want to maintain all of the published versions of your package you may prefer to load.
Installer install: 'PackageAllVersions'.
Keith I try to understand what you mean by the previous statement. It is not clear to me.
I do not understand the following one either. It seems that I missed something.
If you are using squeak 3.10 the following hierarchy of classes will load.
Packages - Abstract Base Class
PackagesAllVersions - Non-specific package definitions that load
the latest version, if that version is likely (but not 100% guarenteed) to work in all versions. You don't have to wait for your package to be perfect, to put a generic definition in here, enabling your users to try it out in their favourite squeak version, and provide you with feedback.
- PackagesSqueak310beta - Non-specific package definitions that
load the very latest version, specific to 3.10. Again it is expected to work, but the author may not have actually tested your configuration.
- PackagesSqueak310U - The specific exact published version in
Universes that is supposed to have been tested in that image version.
- PackagesSqueak310 - The specific exact version that 'you'/'we'
have found 'actually' works, overriding the universes definition.
The community can clearly identify and publish what works where, and this provides a shared collective whiteboard in which active collaboration can take place. In addition, if a specific version in a specific image needs a patch to work, then it can actually be included in the load script for that package. Thus for the first time patches can be included in published packages, and released for testing, without the bottleneck of waiting for the Package author to get around to fixing the problem for your squeak-fork. Those who submit patches will actually see their work get used immediately.
Automation
All installation scripts should run without interaction, for automated installation. See 'Seaside' for an example.
Deterministic Builds (potentially*)
All of the package definitions, for the image you are using are version controlled in monticello. So you can go back to a previous configuration from a previous date and load it. *The packages you are loading have to be listed to nominate specific packages for this to work.
I do not understand the previous sentence and its implication.
Flexibility
Have your own package definitions for your own squeak fork, subclass to specialize/override etc etc.
I declare Sake/Packages for squeak open!
enjoy
Keith
===
btw... LevelPlayingField is currently broken in 3.8.1 and I dont have time to fix it, the SqueakMap update process chokes it. to do: Sake/Packages-SqueakMap the same scheme for
p.s. In case anyone wonders... the packages mailing list has not been used for ~ 3 years. I emailed the packages mailing over a year ago and discussed its use for this purpose with anyone who cared.
stephane ducasse wrote:
Installer install: 'Packages'.
If you want to maintain all of the published versions of your package you may prefer to load. Installer install: 'PackageAllVersions'.
Ok, there is a monticello package for each squeak version, so far 3.7, 3.8, 3.9, and 3.10 but the more the merrier. As a user of a particular version of squeak, Installer install: 'Packages' only installs the one that is relevant for you.
If you are a package author and you want to see/edit every place in the Packages/Sake system in which your package has a load task and edit them, then you will want to load all of the packages. That what PackagesAllVersions does.
Keith I try to understand what you mean by the previous statement. It is not clear to me.
I do not understand the following one either. It seems that I missed something.
Each "Package Load Task" is an instance method. A hierarchy of classes allows general package definitions at the top and more specific definitions at the bottom.
We start with the most generic "Package Load Tasks". Packages which will load into any version of squeak, and they will load the latest version whatever it may be.
From there we work towards the most specific "Package Load Tasks". Packages which need this script to load into this particular squeak version.
In between we have the Tasks, as defined by the current Universes system, so these are fixed from the Sake/Packages point of view. The universes definition should work but is potentially out of date.
You choose which level of specificity you want like so...
(Packages currentBeta load: 'Pier') run. "scripts defined at this level can be generic" (Packages universe load: 'Pier') run. "This is a recent universes definition" (Packages current load: 'Pier') run. "this is the maintained definition"
The nice thing about this is that it can be adapt to your position in the development cycle. A new package that is constantly being updated need only be defined generically. As a package matures and more people are interested in stability, more specific definitions can be added.
If you are using squeak 3.10 the following hierarchy of classes will load.
- Packages - Abstract Base Class
Deterministic Builds (potentially*)
All of the package definitions, for the image you are using are version controlled in monticello. So you can go back to a previous configuration from a previous date and load it. *The packages you are loading have to be listed to nominate specific packages for this to work.
I do not understand the previous sentence and its implication.
If I load a package from Universes today it might give me a completely different result from yesterday. So testing and publishing a fantastic image building script which uses Installer and Universes, can be broken by someone removing a package from the universes server.
With a Sake/Packages based installer script you can say, "This worked with PackagesSqueak310-kph-14". They use can load this and all will work exactly as when you tested it. IFF the script uses tasks which are specifically defined.
A generally defined task is like so:
Installer squeaksource project: 'Sake'; install: 'Sake'.
A specifically defined task is like so:
Installer squeaksource project: 'Sake'; install: 'Sake-kph.15'.
does that help?
Keith
thanks I will have a look
I'm still writing on installer for sbe volume two. But I took a break to finish the seaside book :)
Stef
On Apr 21, 2008, at 10:16 PM, Keith Hodges wrote:
stephane ducasse wrote:
Installer install: 'Packages'.
If you want to maintain all of the published versions of your package you may prefer to load. Installer install: 'PackageAllVersions'.
Ok, there is a monticello package for each squeak version, so far 3.7, 3.8, 3.9, and 3.10 but the more the merrier. As a user of a particular version of squeak, Installer install: 'Packages' only installs the one that is relevant for you.
If you are a package author and you want to see/edit every place in the Packages/Sake system in which your package has a load task and edit them, then you will want to load all of the packages. That what PackagesAllVersions does.
Keith I try to understand what you mean by the previous statement. It is not clear to me.
I do not understand the following one either. It seems that I missed something.
Each "Package Load Task" is an instance method. A hierarchy of classes allows general package definitions at the top and more specific definitions at the bottom.
We start with the most generic "Package Load Tasks". Packages which will load into any version of squeak, and they will load the latest version whatever it may be.
From there we work towards the most specific "Package Load Tasks". Packages which need this script to load into this particular squeak version.
In between we have the Tasks, as defined by the current Universes system, so these are fixed from the Sake/Packages point of view. The universes definition should work but is potentially out of date.
You choose which level of specificity you want like so...
(Packages currentBeta load: 'Pier') run. "scripts defined at this level can be generic" (Packages universe load: 'Pier') run. "This is a recent universes definition" (Packages current load: 'Pier') run. "this is the maintained definition"
The nice thing about this is that it can be adapt to your position in the development cycle. A new package that is constantly being updated need only be defined generically. As a package matures and more people are interested in stability, more specific definitions can be added.
If you are using squeak 3.10 the following hierarchy of classes will load.
- Packages - Abstract Base Class
Deterministic Builds (potentially*)
All of the package definitions, for the image you are using are version controlled in monticello. So you can go back to a previous configuration from a previous date and load it. *The packages you are loading have to be listed to nominate specific packages for this to work.
I do not understand the previous sentence and its implication.
If I load a package from Universes today it might give me a completely different result from yesterday. So testing and publishing a fantastic image building script which uses Installer and Universes, can be broken by someone removing a package from the universes server.
With a Sake/Packages based installer script you can say, "This worked with PackagesSqueak310-kph-14". They use can load this and all will work exactly as when you tested it. IFF the script uses tasks which are specifically defined.
A generally defined task is like so:
Installer squeaksource project: 'Sake'; install: 'Sake'.
A specifically defined task is like so:
Installer squeaksource project: 'Sake'; install: 'Sake-kph.15'.
does that help?
Keith
2008/4/22 Keith Hodges keith_hodges@yahoo.co.uk:
stephane ducasse wrote:
thanks I will have a look
I'm still writing on installer for sbe volume two. But I took a break to finish the seaside book :)
Stef
I think Sake will be worth a chapter or two! I wonder what animal O'Reilly will give it?
Seaside full of nutshells :)
Keith
I have one chapter! May be this would be nice to have
MCInstaller because Installer start to be fat
Still you could type
Installer mc which returns an instance of MCInstaller.
Stef
On Apr 22, 2008, at 10:53 PM, Keith Hodges wrote:
stephane ducasse wrote:
thanks I will have a look
I'm still writing on installer for sbe volume two. But I took a break to finish the seaside book :)
Stef
I think Sake will be worth a chapter or two! I wonder what animal O'Reilly will give it?
Keith
On Tue, Apr 22, 2008 at 9:53 PM, Keith Hodges keith_hodges@yahoo.co.uk wrote:
I think Sake will be worth a chapter or two! I wonder what animal O'Reilly will give it?
Keith
I don't know about the book as a whole, but a chapter on Sake could have only one animal:
"Statues of tanuki can be found outside many Japanese temples and restaurants, especially noodle shops. These statues often wear big, cone-shaped hats and carry bottles of sake in one hand, and a promissory note (a bill it will never pay) or empty purse in the other hand." http://en.wikipedia.org/wiki/Tanuki
cheers, Michael
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Andrew Tween -
Edgar J. De Cleene -
Igor Stasenko -
Keith Hodges -
Marcel Weiher -
Michael Davies -
stephane ducasse