Shouldn't the main Squeak website have 3.10 by now?
I'm working on a re-write of my tutorial and intend, among other changes, to have the student begin with Squeak 3.10. The thing is, I'm wanting to capture screen-shots of the web page where it is found as well as the original opening desktop.
Not trying to nag, but I remember seeing the messages about 3.10 being released weeks ago.
Thanks in advance,
- Steve Wessels -- The world is a dangerous place to live, not because of the people who are evil, but because of the people who don't do anything about it. - Albert Einstein
Thanks for the message Steve. We are waiting for the release team's final decision on how they want it to be released and waiting for the packaging for each platform. You can still get it from the ftp site, though.
brad
On Wed, Apr 16, 2008 at 5:38 PM, Stephan B. Wessels swessels@cox.net wrote:
Shouldn't the main Squeak website have 3.10 by now?
I'm working on a re-write of my tutorial and intend, among other changes, to have the student begin with Squeak 3.10. The thing is, I'm wanting to capture screen-shots of the web page where it is found as well as the original opening desktop.
Not trying to nag, but I remember seeing the messages about 3.10 being released weeks ago.
Thanks in advance,
- Steve Wessels
-- The world is a dangerous place to live, not because of the people who are evil, but because of the people who don't do anything about it.
- Albert Einstein
Webteam mailing list Webteam@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/webteam
On Thu, Apr 17, 2008 at 1:38 AM, Stephan B. Wessels swessels@cox.net wrote: ...
I'm working on a re-write of my tutorial and intend, among other changes, to have the student begin with Squeak 3.10. The thing is, I'm wanting to capture screen-shots of the web page where it is found as well as the original opening desktop.
Hi Stephan,
I wonder if you're aware of the discussion that Damien Cassou and (I think) Oscar Nierstrasz had on the squeak-dev mailing list where they proposed building a fixed "newbie" image that could then be used by everyone writing tutorials. This would address one of the frequent causes of newbie questions - "I'm trying to do X, but instead of Y happening, I'm getting Z", and this turning out to be because of a behaviour changing in the latest version of the image (eg default browser changing, menu options moving or being renamed, mouse button preferences changing, underscore behaviour, different versions of packages being imported etc etc). The ability to configure Squeak images to one's own preferences and requirements is one of its strengths for experienced users, but a cause of extreme frustration to new users (as can be seen by reading the logs of the #squeak irc channel).
Andrew Black reflected on this a while back when he said of the experience of getting novices into Squeak: "My greatest frustrations in writing the [SBE] book were the following. First, that I didn't know what I could assume was in the image that the reader was using! The "standard" release didn't have most of the development tools that I needed, and those that were there mostly didn't work. We even had trouble amongst ourselves (the authors) deciding on which version to use, and when to go back and revise a chapter because the image had been revised."
If you and the SBE team (and maybe also the Hasso Plattner-Institut people) were to adopt such an image, it would then make sense for the web team to make that image very prominent on the Squeak.org website, so as to guide new users towards a managed experience.
Once such an image was prepared and included all the functionality required by the collaborating authors, it could reasonably remain unchanged much longer than the squeak.org image would, and so of much more use to people coming to your tutorial in years to come (as I expect they will, because it's an excellent introduction to development in Squeak and Morphic).
I'd be interested in hearing your thoughts on this approach.
Cheers, Michael
Hello Michael,
I'd be interested in hearing your thoughts on this approach.
Cheers, Michael
I have been using Bazaar to version control my images, I am just getting to grips with it, and I think it is fantastic, better than mercurial for managing squeak images. So I have set up a server that I can use, and make public at some point.
My typical workflow involves, downloading the version I want, unzipping, copying, moving the version into my "Originals" folder, applying LPF, copying that moving that into my "LPF" folder, and then copy that to a working directory in which I start to load the packages that I need.
In looking at the Bazaar user manual, it allows some interesting ways of organizing a reporistory of versions/branches. Here is a sample of my current repository structure.
/squeak/3.10/.bzr /squeak/3.10/LPF/.bzr /squeak/3.10/LPF/pr_tools/.bzr /squeak/3.7/.bzr /squeak/3.8/.bzr /squeak/3.8.1/.bzr /squeak/3.9.1/.bzr /squeak/3.9.1/LPF/.bzr
The directory /squeak/3.10/.bzr is a repository for the base version, which contains within it, the repository for the LPF image that was derived from 3.10 /Squeak/3.10/LPF/.bzr , which in turn contains a repository of my "pr_tools" working image, which was derived from the LPF version.
A user can obtain a base 3.10 release, specifying a revision number or tag if need be, via:
bzr checkout sftp://squeak.warwick.st/squeak/3.10 myworkingdirectory --lightweight
to obtain the LPF derivative:
bzr checkout sftp://squeak.warwick.st/squeak/3.10/LPF myworkingdirectory --lightweight
to obtain a personal working branch for a new project based upon 3.10/LPF:
bzr branch sftp://squeak.warwick.st/squeak/3.10/LPF mynewproject --lightweight
to publish a the new project back to the shared repository:
cd mynewpoject bzr push sftp://squeak.warwick.st/squeak/3.10/LPF/mynewproject
Although I am not writing a book, I am wanting to simplify, a) the learning process, and b) the collaboration process. Although it is getting easier the process of enabling others to learn and come on board is still an uphill one.
So my plan is to adjust my day to day working to use a number of "Public Images". I will have a single image as my working environment for 5 or 6 tools, and publish that as a version controlled deliverable. This deliverable will have the test environment for each package ready to run, and the documentation that is written can be version managed alongside or in some cases in the image itself.
If this works, I can ensure that a properly configured image with of all of these tools is available for anyone to browse and try out. When it comes to collaboration on any one tool, there is a clearly defined and very easily obtainable test-bed for any new innovations.
I am hoping that this deliverable, version managed in a public repository, will help me to address some of my own weaknesses. I often find myself publishing packages which unwittingly break things. This is fine, IFF you can adequately inform potential users, as to which versions are working correctly and which versions are still pre-release, which tests pass and which fail. Our current tools (mcz/universes) do not provide that part of the feedback loop and so it is often very difficult to inform our users exactly which combination of bits works as intended.... So my solution is to adopt these version controlled "reference images".
With such a hierarchical version controlled server in place, it becomes much simpler to tell a user exactly which image they need for a particular tutorial. Furthermore, the documentation could be version managed together with an image as a coherent whole.
just my 2p
Keith
webteam@lists.squeakfoundation.org