gmane.comp.lang.smalltalk.squeak.webteam

headers Stephan B. Wessels | 17 Apr 02:38 · /3.10/

_______________________________________________
Webteam mailing list
Webteam@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/webteam

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@...> 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@...
>  http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/webteam
>
>

--

-- 
Brad Fuller
www.bradfuller.com

On Thu, Apr 17, 2008 at 1:38 AM, Stephan B. Wessels <swessels@...> 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

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

Suggestion for Squeak Website

Re: Suggestion for Squeak Website

Re: Suggestion for Squeak Website

Re: [Webteam] Suggestion for Squeak Website

Re: Suggestion for Squeak Website