How to improve Squeak

[stéphane ducasse]

Hi all

the last two/three days I have been browsing a lot of code while mainly
playing with BookMorph.
And I noticed a lot of "nearly working" or "half broken" behavior. Most
of the time you start with a good state of mind and think that you will
be able to do something and suddenly you lost a day and get frustrated.

For example, EventRecorder when we say not to save the file still ask
you (I will try to fix that)
TextMorphProperty when the the text is too large does not fit on the
screen (I tried to add a ScrollPane but failed),
BookMorph sortPages breaks when there are more than 40 slides (in my
version I remove the test),
BookMorph does not save anymore on files (again I tried to add a file
server but the code is quite complex). I will continue but I'm sure
that it will work.

I saw a lot of code that is in but is empty, or class have bad name
(AlansText, ProjectRefactoring,....really cool). I already fixed
I saw a lot of properties used everywhere and this makes the code
extremely hard to browse
and understand.
BookMorph>>fromUser is empty

May be this is because I'm bad in Morphic but my impression is there is
a lot of stuff broken in Morphic and in Squeak in general.

So I would like to know how we could proceed to rescue some of the
squeak asset.
- Should we rewrite some of them from scratch?
- Is there some people around willing to spend some evenings fixing so
key classes?
- I think that it would be nice to take a month and focus on a class
and fix it.
But alone I feel that I will never make it.
- Should we keep it like that and continue to claim that this is cool
while everything is
only working if you fix it (and you have the precondition that you are
an expert).
- I will continue to harvest as much as I can the good fix of ned so
this will improve the situation.
But I'm sure that having some task force to fix some parts would be a
good answer to the problem.


Stef

[Giovanni Giorgi]

Post by stéphane ducasse
Hi all
the last two/three days I have been browsing a lot of
code while mainly
playing with BookMorph.
And I noticed a lot of "nearly working" or "half broken"
behavior.

[...]
I have the same impression on some parts of morphic

Post by stéphane ducasse
May be this is because I'm bad in Morphic but my
impression is there is
a lot of stuff broken in Morphic and in Squeak in
general.

As far as I know Morphic is very complex and a lot of
people work on it.
I have similar problems now refactoring Celeste, because
some modules like SMTP client are used also in other
context, and uses superclasses or subclasses.
When I must modify a method, I first search how it is used,
and I must decide if my action will broke some other
software parts.
I think this is a peculiar characteristic of Smalltalk,
because the high dynamic environment bring the developer to
easily integrate his code into the existing, boosting code
reuse in an incredible strong way.

[...]

Post by stéphane ducasse
But I'm sure that having some task force to fix some
parts would be a
good answer to the problem.

By the way, there is some quite up-t-date tutorial we can
look for building morphin interfaces?
Morphic seems changed a lot from two year ago...
Ciao ciao!

=====
// Giovanni Giorgi http://www.siforge.org

[Hans Nikolaus Beck]

Hi Stephane,

Post by stéphane ducasse
May be this is because I'm bad in Morphic but my impression is there
is a lot of stuff broken in Morphic and in Squeak in general.
So I would like to know how we could proceed to rescue some of the
squeak asset.
- Should we rewrite some of them from scratch?
- Is there some people around willing to spend some evenings fixing
so key classes?
- I think that it would be nice to take a month and focus on a class
and fix it.
But alone I feel that I will never make it.
- Should we keep it like that and continue to claim that this is cool
while everything is
only working if you fix it (and you have the precondition that you
are an expert).
- I will continue to harvest as much as I can the good fix of ned so
this will improve the situation.
But I'm sure that having some task force to fix some parts would be a
good answer to the problem.

What would you concrete suggest as next step, or better, what would be
your favorite next action ?

Greetings

Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040711/fd50a658/PGP.pgp

[stéphane ducasse]

Hi all

After reading all this thread over my sllllloooowwwwwww modem I will
try to sum up my point
and remarks.

- The current process is working. More process will not help.

- We need more people testing/writing tests/fixing. I think that
everybody can contribute by writing
tests this way we will be able to have a real active documentation.

- I agree with ned that having a wilder alpha phase would help (we were
slow down in KCP
because we had to consider the potential desynchronisation with the
update stream).

- I agree with Tim peer review is the best way to get quality in.
Everybody can be tired and make mistake. Mistakes are part of the
process. I like to read when Ned and andreas argue about some morphic
points because this gives me the confidence that something is
improving.

- About managing the image with MC. I would like to get rid of
changeset (at least the fact that they do not hold versions). I think
that doing that we will have to address the point that MC packages
are weak (nathanael reported to me a lot of problems he encountered
with them while working on the new version of traits). But again
pressure is the drive for improvement. By the way we have a byte-code
loader for MC.

- Finally I would like to say that even if having image managed by MC
this will not solve the problem
I mentioned with my original email.
could we have a new tag in BFAV to report broken parts or part to
refactor clean...?
[REP] Bookmorph saving broken
[REP] Class ZZZ should be removed
...
Then I think that we should identify some assets EventRecorderMorph,
BookMorph and build some tasks forces. But I'm pessimist.



Stef

[Avi Bryant]

Post by stéphane ducasse
- About managing the image with MC. I would like to get rid of
changeset (at least the fact that they do not hold versions). I think
that doing that we will have to address the point that MC packages
are weak (nathanael reported to me a lot of problems he encountered
with them while working on the new version of traits). But again
pressure is the drive for improvement.

Exactly - so put on the pressure. Why did Nathanael report the
problems only to you, and not to the list, or to me and Colin? This
gets back to Colin's recent post about fear of criticism - if you have
complaints, bring 'em on...

Post by stéphane ducasse
By the way we have a byte-code loader for MC.

Yes, that's cool. Are you guys using it?

Avi

[David T. Lewis]

Post by stéphane ducasse
the last two/three days I have been browsing a lot of code while mainly
playing with BookMorph.
And I noticed a lot of "nearly working" or "half broken" behavior. Most
of the time you start with a good state of mind and think that you will
be able to do something and suddenly you lost a day and get frustrated.

...

Post by stéphane ducasse
So I would like to know how we could proceed to rescue some of the
squeak asset.

Personally, I don't mind having some incomplete or unfinished things in
Squeak. Many of them show good ideas and things that could be brought to
completion in the future.

But as you described, there is a real problem when you waste a whole day
trying to get something to work, only to find out that it never really worked
in the first place, but nobody ever bothered to mention it in a class comment.
This is particularly annoying when you realize that the original author could
have added the documentation in about five minutes, but never got around to
doing it.

So what is TSTTCPW? Contribute class comments. Where possible, document
the intent of the class, mention that it, ehem, does not actually work,
and maybe add a couple of example methods or test cases to show how it
is supposed to work.

This is actually very difficult to do, because it requires guessing the
intentions of the original authors, and there is a risk of adding incorrect
or misleading documentation. However, it would address the problem you
described, and it certainly would be easier than trying to actually fix
all of the things in Squeak that never actually worked in the first place ;-)

Dave

[Marcus Denker]

Post by David T. Lewis

Post by stéphane ducasse
the last two/three days I have been browsing a lot of code while mainly
playing with BookMorph.
And I noticed a lot of "nearly working" or "half broken" behavior. Most
of the time you start with a good state of mind and think that you will
be able to do something and suddenly you lost a day and get
frustrated.

...

Post by stéphane ducasse
So I would like to know how we could proceed to rescue some of the
squeak asset.

Personally, I don't mind having some incomplete or unfinished things in
Squeak. Many of them show good ideas and things that could be brought to
completion in the future.

But there's a lot of stuff that will never be completed because it was
"officially"
abandoned. e.g. the "Squeak Server Pages" are, es much as I know, an
experiment that was superseded by Projects.

So while I'm personally very much pro experiments (and I'd like to see a
Squeak that makes real deep experimentation even simpler), the situation
we have now has realy gotten out of hand...

The Number one Principle of a System made for Experimentation: Make it
easy
to throw stuff away. It's an interesting view of Modularity: A modular
system not only
allows for easy composition, but should make decomposition easy, too.

For the Kernel, we have KCP (I hope to be able to actively contribute
to that). For
Morphic, there once was MCP, but the state of Morhpic is so bad that I
guess only
"thow it away" will work...

One question is how to make sure that something like that does not
happen in the
future again... for the ObjectMemory, we have an automatic garbadge
collector.

I think a Team doing experimental work would need to model a "garbage
collector"
in their process. Either distributed among team members or one person
responsible
for cleaning up. No nice job... but it needs to be done.

Marcus

[goran.krampe at bluefish.se ()]

Hi all!
[SNIP]

Post by Marcus Denker

Post by David T. Lewis
Personally, I don't mind having some incomplete or unfinished things in
Squeak. Many of them show good ideas and things that could be brought to
completion in the future.

But there's a lot of stuff that will never be completed because it was
"officially"
abandoned. e.g. the "Squeak Server Pages" are, es much as I know, an
experiment that was superseded by Projects.

I agree with Marcus and also, experiments are better made in a separate
package. Then they don't bother anyone and can "rot" in peace. :)

Having loose nobody-really-knows-if-it-works-half-rotten-half-finished
stuff in the base image is simply not good.

Post by Marcus Denker
So while I'm personally very much pro experiments (and I'd like to see a
Squeak that makes real deep experimentation even simpler), the situation
we have now has realy gotten out of hand...
The Number one Principle of a System made for Experimentation: Make it
easy
to throw stuff away. It's an interesting view of Modularity: A modular
system not only
allows for easy composition, but should make decomposition easy, too.

Yes, and we shouldn't be so scared of touching these things. Either we:

1. Cut it out and put it in a package. It doesn't even have to work.
This option is nice if it isn't too tangled up.

2. Delete it. Remember, there are always old images and old VM to pick
up and look inside if someone wants to salvage it in the future.

Post by Marcus Denker
For the Kernel, we have KCP (I hope to be able to actively contribute
to that). For
Morphic, there once was MCP, but the state of Morhpic is so bad that I
guess only
"thow it away" will work...
One question is how to make sure that something like that does not
happen in the
future again... for the ObjectMemory, we have an automatic garbadge
collector.

Well, best is if experimental stuff are in external packages. Then they
can be marked clearly as half finisihed experimental stuff etc. And
there is a maintainer, and we can see when it last worked etc.

Post by Marcus Denker
I think a Team doing experimental work would need to model a "garbage
collector"
in their process. Either distributed among team members or one person
responsible
for cleaning up. No nice job... but it needs to be done.
Marcus

Sidenote: There are a multitude of cool things piling up on SM that we
need to consider if we want to "bless" as being part of the official
package pool. A good example is Shout - it is so DAMN good it should be
an official package IMHO. :) And it should be in Basic.

Now, what we can do is to simply agree on this - the maintainer must be
in on it of course - and then Doug can simply put out an update loading
it. Voila.

Now, of course - 3.7 is close at hand so I propose we take a look at
these things in the beginning of 3.8. Removals and additions.

regards, Göran

[Karl Ramberg]

Post by Marcus Denker
But there's a lot of stuff that will never be completed because it was
"officially"
abandoned. e.g. the "Squeak Server Pages" are, es much as I know, an
experiment that was superseded by Projects.

A removal of the Squeak Server Pages would be quite safe. It's used by BookMorph
and Morph>>saveOnUrl and a few other places. But since the saving does
not work,
or is very hard to use, it is quite useless in the state it is.
It could be put on SqueakMap as a package for interested people.

Karl

[Karl Ramberg]

Hi, here is a quick and dirty trick to avoid the bogus save menu options.
I just commented out the old menu options and offer Morph>>saveOnFile as
the only option for book saving. Works nice.
Karl

Post by stéphane ducasse
Hi all
the last two/three days I have been browsing a lot of code while mainly
playing with BookMorph.
And I noticed a lot of "nearly working" or "half broken" behavior. Most
of the time you start with a good state of mind and think that you will
be able to do something and suddenly you lost a day and get frustrated.
For example, EventRecorder when we say not to save the file still ask
you (I will try to fix that)
TextMorphProperty when the the text is too large does not fit on the
screen (I tried to add a ScrollPane but failed),
BookMorph sortPages breaks when there are more than 40 slides (in my
version I remove the test),
BookMorph does not save anymore on files (again I tried to add a file
server but the code is quite complex). I will continue but I'm sure
that it will work.
I saw a lot of code that is in but is empty, or class have bad name
(AlansText, ProjectRefactoring,....really cool). I already fixed
I saw a lot of properties used everywhere and this makes the code
extremely hard to browse
and understand.
BookMorph>>fromUser is empty
May be this is because I'm bad in Morphic but my impression is there is
a lot of stuff broken in Morphic and in Squeak in general.
So I would like to know how we could proceed to rescue some of the
squeak asset.
- Should we rewrite some of them from scratch?
- Is there some people around willing to spend some evenings fixing so
key classes?
- I think that it would be nice to take a month and focus on a class
and fix it.
But alone I feel that I will never make it.
- Should we keep it like that and continue to claim that this is cool
while everything is
only working if you fix it (and you have the precondition that you are
an expert).
- I will continue to harvest as much as I can the good fix of ned so
this will improve the situation.
But I'm sure that having some task force to fix some parts would be a
good answer to the problem.
Stef

-------------- next part --------------
A non-text attachment was scrubbed...
Name: BookMorph.kfr.1.cs.gz
Type: application/octet-stream
Size: 1070 bytes
Desc: Unknown Document
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040711/d1c49a02/BookMorph.kfr.1.cs.obj

[Brad Fuller]

Hi all,

What is the criteria and approval process of being in the base image?

brad

-----Original Message-----
Sent: Sunday, July 11, 2004 8:59 AM
To: The general-purpose Squeak developers list
Subject: Re: How to improve Squeak
Hi all!
[SNIP]

Post by Marcus Denker

Post by David T. Lewis
Personally, I don't mind having some incomplete or

unfinished things

Post by Marcus Denker

Post by David T. Lewis
in Squeak. Many of them show good ideas and things that could be
brought to completion in the future.

But there's a lot of stuff that will never be completed

because it was

Post by Marcus Denker
"officially"
abandoned. e.g. the "Squeak Server Pages" are, es much as I

know, an

Post by Marcus Denker
experiment that was superseded by Projects.

I agree with Marcus and also, experiments are better made in
a separate package. Then they don't bother anyone and can
"rot" in peace. :)
Having loose nobody-really-knows-if-it-works-half-rotten-half-finished
stuff in the base image is simply not good.

Post by Marcus Denker
So while I'm personally very much pro experiments (and I'd

like to see

Post by Marcus Denker
a Squeak that makes real deep experimentation even simpler), the
situation we have now has realy gotten out of hand...
The Number one Principle of a System made for

Experimentation: Make it

Post by Marcus Denker
easy to throw stuff away. It's an interesting view of Modularity: A
modular system not only allows for easy composition, but

should make

Post by Marcus Denker
decomposition easy, too.

Yes, and we shouldn't be so scared of touching these things.
1. Cut it out and put it in a package. It doesn't even have to work.
This option is nice if it isn't too tangled up.
2. Delete it. Remember, there are always old images and old
VM to pick up and look inside if someone wants to salvage it
in the future.

Post by Marcus Denker
For the Kernel, we have KCP (I hope to be able to actively

contribute

Post by Marcus Denker
to that). For Morphic, there once was MCP, but the state of

Morhpic is

Post by Marcus Denker
so bad that I guess only "thow it away" will work...
One question is how to make sure that something like that does not
happen in the future again... for the ObjectMemory, we have an
automatic garbadge collector.

Well, best is if experimental stuff are in external packages.
Then they can be marked clearly as half finisihed
experimental stuff etc. And there is a maintainer, and we can
see when it last worked etc.

Post by Marcus Denker
I think a Team doing experimental work would need to model

a "garbage

Post by Marcus Denker
collector"
in their process. Either distributed among team members or

one person

Post by Marcus Denker
responsible for cleaning up. No nice job... but it needs to be done.
Marcus

Sidenote: There are a multitude of cool things piling up on
SM that we need to consider if we want to "bless" as being
part of the official package pool. A good example is Shout -
it is so DAMN good it should be an official package IMHO. :)
And it should be in Basic.
Now, what we can do is to simply agree on this - the
maintainer must be in on it of course - and then Doug can
simply put out an update loading it. Voila.
Now, of course - 3.7 is close at hand so I propose we take a
look at these things in the beginning of 3.8. Removals and additions.
regards, G?ran

[Doug Way]

Post by Brad Fuller
Hi all,
What is the criteria and approval process of being in the base image?

The approval process (Harvesting Process) is pretty much covered here:

http://minnow.cc.gatech.edu/squeak/3152

Note that there aren't really strictly defined criteria for something
to be allowed in the base image, other than approval/review from one or
more harvesters and other volunteers. However, most of the things
being discussed here (Squeak Server Pages, EventRecorderMorph, etc)
pre-date the existence of the Harvesting Process anyway. (they were
added earlier in the days of Squeak Central)

- Doug

Post by Brad Fuller
brad

-----Original Message-----
Sent: Sunday, July 11, 2004 8:59 AM
To: The general-purpose Squeak developers list
Subject: Re: How to improve Squeak
Hi all!
[SNIP]

Post by Marcus Denker

Post by David T. Lewis
Personally, I don't mind having some incomplete or

unfinished things

Post by Marcus Denker

Post by David T. Lewis
in Squeak. Many of them show good ideas and things that could be
brought to completion in the future.

But there's a lot of stuff that will never be completed

because it was

Post by Marcus Denker
"officially"
abandoned. e.g. the "Squeak Server Pages" are, es much as I

know, an

Post by Marcus Denker
experiment that was superseded by Projects.

I agree with Marcus and also, experiments are better made in
a separate package. Then they don't bother anyone and can
"rot" in peace. :)
Having loose nobody-really-knows-if-it-works-half-rotten-half-finished
stuff in the base image is simply not good.

Post by Marcus Denker
So while I'm personally very much pro experiments (and I'd

like to see

Post by Marcus Denker
a Squeak that makes real deep experimentation even simpler), the
situation we have now has realy gotten out of hand...
The Number one Principle of a System made for

Experimentation: Make it

Post by Marcus Denker
easy to throw stuff away. It's an interesting view of Modularity: A
modular system not only allows for easy composition, but

should make

Post by Marcus Denker
decomposition easy, too.

Yes, and we shouldn't be so scared of touching these things.
1. Cut it out and put it in a package. It doesn't even have to work.
This option is nice if it isn't too tangled up.
2. Delete it. Remember, there are always old images and old
VM to pick up and look inside if someone wants to salvage it
in the future.

Post by Marcus Denker
For the Kernel, we have KCP (I hope to be able to actively

contribute

Post by Marcus Denker
to that). For Morphic, there once was MCP, but the state of

Morhpic is

Post by Marcus Denker
so bad that I guess only "thow it away" will work...
One question is how to make sure that something like that does not
happen in the future again... for the ObjectMemory, we have an
automatic garbadge collector.

Well, best is if experimental stuff are in external packages.
Then they can be marked clearly as half finisihed
experimental stuff etc. And there is a maintainer, and we can
see when it last worked etc.

Post by Marcus Denker
I think a Team doing experimental work would need to model

a "garbage

Post by Marcus Denker
collector"
in their process. Either distributed among team members or

one person

Post by Marcus Denker
responsible for cleaning up. No nice job... but it needs to be done.
Marcus

Sidenote: There are a multitude of cool things piling up on
SM that we need to consider if we want to "bless" as being
part of the official package pool. A good example is Shout -
it is so DAMN good it should be an official package IMHO. :)
And it should be in Basic.
Now, what we can do is to simply agree on this - the
maintainer must be in on it of course - and then Doug can
simply put out an update loading it. Voila.
Now, of course - 3.7 is close at hand so I propose we take a
look at these things in the beginning of 3.8. Removals and additions.
regards, G?ran

[goran.krampe at bluefish.se ()]

Hi people!

The question from Brad Fuller (below) spurred me into doing a recap of
how Squeak is ... well, partitioned or whatever you call it. This is
good to know - and not really dead simple, so I will give it a shot to
explain.

Post by Doug Way

Post by Brad Fuller
Hi all,
What is the criteria and approval process of being in the base image?

http://minnow.cc.gatech.edu/squeak/3152
Note that there aren't really strictly defined criteria for something
to be allowed in the base image, other than approval/review from one or
more harvesters and other volunteers. However, most of the things
being discussed here (Squeak Server Pages, EventRecorderMorph, etc)
pre-date the existence of the Harvesting Process anyway. (they were
added earlier in the days of Squeak Central)
- Doug

Doug refers to how code changes (additions/removals/modifications) to
the classes LIVING in the current Basic image are handled. In short it
goes like this:

1. Someone makes a nice FIX or ENH (enhancement) to the image and sends
it to the list, preferrably using the ChangeSorter tools in the .cs.gz
format - a compressed ChangeSet. A ChangeSet is like a "tape recording"
when the user did his/her modifications. Those are very nice for these
things.

2. The ChangeSet gets sucked up into what we call BFAV - Bug Fixes
Archive (Viewer). BFAV is like an assembly line where these FIXes get
collected and then go through a few different states. Anyone can install
"BFAV2 Installer" (that is the one you want, NOT any other package) but
you need to use Squeak 3.7b. It is also a very nice tool to give
feedback and reviews on FIXes and YOU can play a vital part here, even
if you don't know how to code.

3. Eventually these changesets gets rejected or approved, but only the
Harvesters can approve. When a changeset has been approved it sits there
and waits to go out as an update. Doug is the update master - he will
collect them, make a final test and then shoot them out. These you can
load into your image by pulling out the left flap and push "Load code
updates".


So the above process covers most of the stuff in a Basic image. The
Basic image is the image that is fed the update stream. The latest at
the moment of writing - the bleeding edge - is 3.76beta-5969, available
here:

ftp://st.cs.uiuc.edu/Smalltalk/Squeak/3.7beta/
(well, 5967 is the latest zipped up, just load code updates to get the
last two)

Ok, BUT... the above describes how you get modifications of the stuff
that lives IN THE IMAGE into the image. But the Basic image also
contains stuff that doesn't LIVE there - it contains a few loaded
Packages.

If you start a fresh 3.7beta Basic image, open the Package Loader,
select "only display installed packages", then you will see that it
contains these packages:

Compiler (1)
MCInstaller (8->10)
PackageInfo (16)
SARInstaller for 3.6 (28)
SUnit (3.1.6)
SmaCC Smalltalk Compiler-Compiler-Runtime (2)
SqueakMap2 base (0.96->1.0)
SqueakMap2 loader (0.92->1.0)
VersionNumber (1.0)

(sidenote: If we look at
http://map1.squeakfoundation.org/sm/category/af36d60e-6066-4d68-bae0-90c
459f5b9d8 then we see that this information is not accurately
represented in SqueakMap. But the current categorization scheme is a bit
messed up, so we can wait a bit until I get things straightened out both
UI-wise and a few extra mechanisms are needed)

Now, these packages live their own lives with their own update cycles
and their own releases. And their own dedicated maintainers. The version
installed in the image is shown in parenthesis, if there is an arrow it
means that there is a newer release available to install.

So... how did those packages end up in Basic? Well, we have decided
together that they need to be there. :) We are working slowly towards a
Squeak which is more and more partitioned in packages.

Putting a package into the package group "Official package in Basic"
means that we decide together that it is needed, and the maintainer is
willing. Then we simply issue an update into the stream that installs a
specific release of the package using SqueakMap.

So "being in the image" can mean two things:

1. Code that has gone through the harvesting process and entered the
image as a changeset through the update stream. That code is truly in
the IMAGE and it will evolve further using the harvesting process. There
is no special maintainer for that code - we all maintain it together.

2. A package that we have decided to load into the image using
SqueakMap. A small update is sent out that simply has a command that
installs the package using SM. Such a package is "more important" than
other packages and we need to make sure it works properly etc. But it is
still a package that has a maintainer and a release cycle independent of
the update stream. Normally the releases are somewhat coordinated with
the releases of Squeak. For example, I am currently furiously trying to
shape up the SqueakMap2 packages in time for the Grand Release of Squeak
3.7! :)


Finally it is worth mentioning the Full image. The Full image is the
Basic image with more cool packages installed on top. When the Basic
image is getting ready for release - like NOW - the assembly of the Full
image needs to be taken care of. It results in a load script:

http://map1.squeakfoundation.org/sm/package/412ecc69-eeda-4029-8113-27c
e05bdc7c0

That when installed into a Basic image will install a whole bunch of
other cool stuff on top.


Well enough for now, hopefully someone learned something new. :)

regards, Göran

[Brad Fuller]

Post by Brad Fuller

Post by Brad Fuller
Hi all,
What is the criteria and approval process of being in the

base image?
http://minnow.cc.gatech.edu/squeak/3152
Note that there aren't really strictly defined criteria for
something to be allowed in the base image, other than
approval/review from one or more harvesters and other
volunteers. However, most of the things being discussed here
(Squeak Server Pages, EventRecorderMorph, etc) pre-date the
existence of the Harvesting Process anyway. (they were added
earlier in the days of Squeak Central)
- Doug

Thanks Doug. I see now that the classes discussed here are before the
Harvesting Process. However, they could go back through the Harvesting
Process -- if this is the only formal process avaiable. At least they would
meet the same criteria as any new one -- and they could be thrown out if
need be.

But, in addition and more important: After reviewing this link, I don't have
to tell you experienced ones that the approval process is somewhat of a
problem from a quality standpoint. For instance, ONE harvester can "approve"
a submission to be included in the image (and, it could be his/her own
submission) -- there is no mandated peer review, or even a peer review
process for that matter. I trust that everyone intimately understands the
other issues and problems with this process.

Has a proposal been put forth in the past to improve this process? I for one
would like to see this tighter. Perhaps this is what Ramiro was pointing out
in his "Magma" email.

brad

[goran.krampe at bluefish.se ()]

"Brad Fuller" <***@sonaural.com> wrote:
[SNIP]

Post by Brad Fuller
But, in addition and more important: After reviewing this link, I don't have
to tell you experienced ones that the approval process is somewhat of a
problem from a quality standpoint. For instance, ONE harvester can "approve"
a submission to be included in the image (and, it could be his/her own
submission) -- there is no mandated peer review, or even a peer review
process for that matter. I trust that everyone intimately understands the
other issues and problems with this process.

You know... I claim the total opposite. :) The process we have now is
somewhat bureaucratic and even though it works "kinda" it would be
better if the process was much more agile. Normally open source projects
don't have this kind of process for core development - only for
contributions coming in from the outside.

Post by Brad Fuller
Has a proposal been put forth in the past to improve this process? I for one
would like to see this tighter.

"Tighter" would "kill" the joy and joy is what we thrive on. In fact -
as I said - we need a swifter process with more trust in the experienced
developers. The harvesting process is perfectly fine for handling ENHs
and FIXes coming in from less experienced developers - but it should
IMHO not be used for core development by the more active experienced
Squeakers.

We need something similar to a CVS with an update/commit process based
on trusted core developers. And I think we may try to put something like
that in place pretty soon - there have been a few experiments. And even
if we don't put that in place for the image - it is used or can be used
for the packages being broken out of the image.

What we also need is less centralization and more personal
responsibility. That can be had using packages and maintainers. So...
more packages! More maintainers! :)

regards, Göran

[Ned Konz]

Post by goran.krampe at bluefish.se ()
"Tighter" would "kill" the joy and joy is what we thrive on. In fact -
as I said - we need a swifter process with more trust in the experienced
developers. The harvesting process is perfectly fine for handling ENHs
and FIXes coming in from less experienced developers - but it should
IMHO not be used for core development by the more active experienced
Squeakers.
We need something similar to a CVS with an update/commit process based
on trusted core developers. And I think we may try to put something like
that in place pretty soon - there have been a few experiments. And even
if we don't put that in place for the image - it is used or can be used
for the packages being broken out of the image.

I absolutely agree with this. I think we should make it easier for our more
experienced and trusted developers to get fixes into the system.

I think there should be something equivalent to the old Squeak Central
"internal update stream", but with more public visibility.

We have been so conservative with reviewing individual items because there are
a number of people (too many, probably) using the pre-release versions of
Squeak for everyday work. As a result, we don't want to break too much.

This results in a slow-moving process, with the same added overhead being
applied to every little fix.

Instead we should have a fast-moving, probably often broken but quickly fixed
development head (like most other open source development efforts) with
commits available to the core developers.

That head should then get forked to become the release versions, as is also
typical. These should go through more rigorous testing, and should be usable
by beta time for most people.

Using a bug tracking system (no, we don't have to write our own!) would give
better tracking, threading, assignment of responsibility, etc.

A simple tool in Squeak for submissions (as we have now), or a harvester on
the existing lists would be adequate for getting external submissions.

[tim Rowledge]

[snip]

Post by goran.krampe at bluefish.se ()
We need something similar to a CVS with an update/commit process based
on trusted core developers. And I think we may try to put something like
that in place pretty soon - there have been a few experiments. And even
if we don't put that in place for the image - it is used or can be used
for the packages being broken out of the image.

I absolutely agree with this. I think we should make it easier for our more
experienced and trusted developers to get fixes into the system.

[snip]
I _almost_ agree; the difference being that I would specify 'trusted
core reveiwers' rather than developers. Whilst in many cases these would
be the same people it is alos entirely feasible to have reviews done by
quite different persons. Except for the tiniest most localised cases
(I'm a pretty trustable person for self-approving RISC OS specific
changes for example) nobody should approve their own code. The wider the
effect of the change the more careful a review it should get.

tim

[Alexander Lazarević]

Post by Ned Konz
We have been so conservative with reviewing individual items because there are
a number of people (too many, probably) using the pre-release versions of
Squeak for everyday work. As a result, we don't want to break too much.

I think more people would use the stable version of Squeak for every day
work if it would receive a little maintenance in form of irregular
updates. Certainly these should only include bug fixes that (ideally)
don't have any negative influence on existing code, which was written
based on the stable version.

Post by Ned Konz
Using a bug tracking system (no, we don't have to write our own!) would give
better tracking, threading, assignment of responsibility, etc.

We _definitely_ should have such a BTS. Why not just set up bugzilla,
mantis or whatever to see how we could make it fit in the Squeak
development process?

Alex

[Serge Stinckwich]

Post by Alexander Lazarević

Post by Ned Konz
We have been so conservative with reviewing individual items because
there are a number of people (too many, probably) using the
pre-release versions of Squeak for everyday work. As a result, we
don't want to break too much.

I think more people would use the stable version of Squeak for every day
work if it would receive a little maintenance in form of irregular
updates. Certainly these should only include bug fixes that (ideally)
don't have any negative influence on existing code, which was written
based on the stable version.

Post by Ned Konz
Using a bug tracking system (no, we don't have to write our own!)
would give better tracking, threading, assignment of responsibility, etc.

We _definitely_ should have such a BTS. Why not just set up bugzilla,
mantis or whatever to see how we could make it fit in the Squeak
development process?

Maybe, we can try to use a bug tracking system with the 3.7 stable
version of Squeak when it is out. He could be a test if this kind of
tools works with Squeak without any interference with the unstable
Squeak dev process.

I might help to build a BTS if there is some interest.

-- oooo
Serge Stinckwich OOOOOOOO
Universit? de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO
http://purl.org/net/SergeStinckwich oooooo
Smalltalkers do: [:it | All with: Class, (And love: it)] \ /
##

[Marcus Denker]

Post by Brad Fuller
Has a proposal been put forth in the past to improve this process? I
for one
would like to see this tighter. Perhaps this is what Ramiro was
pointing out
in his "Magma" email.

I don't think it makes sense to thighten the process at this point. I
am aware that
"shit happens" with the current process.

One simple example: I am the one to blame to have accepted the
"asPlural" changeset.
So, yes, dumb idea to approve that. Something like that happens.

But what's the alternative? Even with the "only one harvester" rule, we
don't manage to do *anything*
at all. Just look at BFAV: The amount of unreviewed stuff is growing.
If we now require a real formal
process beyond what we have now, I fear that nothing will happen. (I
actually would call the current
state of progress "nothing" already).

To come back to the example: Don't forget that we strike for a "fast
moving agile" process. So even
with me doing the wrong thing (approving somthing that should not be
approved), the right thing
nevertheless will happen in the long run, as it did with the asPlural
stuff.

So to sum up: I don't think that making the process more heavy-wheigt
will be the solution.

Marcus

[goran.krampe at bluefish.se ()]

Hi people!

Post by Marcus Denker
To come back to the example: Don't forget that we strike for a "fast
moving agile" process.

Yes, and I think we should really sit down and try to set up Monticello
for managing the image. Avi has already done some experiments. Then we
should of course have limited "commit" access to that.

This way we can have BFAV for the contributions coming in (like patches
in other open source projects) and we can go straight to Monticello for
other stuff.

Such a model would help A LOT I think but it will demand two things of
developers with such commit access:

1. Test it locally first. Don't commit stuff that is half baked. This is
basic stuff for working in an open source project of course. In the
Mozilla project they say that the "tree is on fire" when someone does
that.

2. Write proper commit notes (= commit comment in CVS). Those will be
critical in knowing what has been done and for us to be able to produce
ChangeLogs.

I think perhaps if we do this step first - then we can more easily pick
up the TFNR goals again. It will be easier to perform those things when
we have a "full Monticello" working.

Avi? Comments? Is Monticello up to the task? :)

regards, Göran

[Avi Bryant]

Post by goran.krampe at bluefish.se ()
Avi? Comments? Is Monticello up to the task? :)

Of course not - nobody's tried it yet ;). That is, there's no reason
in theory why it shouldn't work, but I have confidence that we'll run
into a whole bunch of problems at the beginning, some of which I can
predict (performance and UI issues arising from Monticello not being
designed to handle at once the 50+ packages we'll probably want to
divide the image into), most of which I'm sure I can't. But *will*
Monticello be up to the task, in the long run? Yes, definitely. I
think this is a great experiment, and if we try it in earnest, I'll
commit some serious time to smoothing over whatever problems we run
into.

My point is this: I think it's a good time to try this out, but we'll
be in for a rough ride. As long as you promise to nag me to fix what's
broken instead of getting discouraged and giving up, then let's do it.

</disclaimer>

Avi

[Colin Putney]

Post by Avi Bryant

Post by goran.krampe at bluefish.se ()
Avi? Comments? Is Monticello up to the task? :)

My point is this: I think it's a good time to try this out, but we'll
be in for a rough ride. As long as you promise to nag me to fix
what's broken instead of getting discouraged and giving up, then let's
do it.

For what it's worth, I'll throw my weight behind this as well. If the
Guides want to use MC for maintaining Squeak, I'll commit to making it
feasible as soon as possible.

Cheers,

Colin

[Avi Bryant]

Post by Colin Putney

Post by Avi Bryant

Post by goran.krampe at bluefish.se ()
Avi? Comments? Is Monticello up to the task? :)

My point is this: I think it's a good time to try this out, but we'll
be in for a rough ride. As long as you promise to nag me to fix
what's broken instead of getting discouraged and giving up, then
let's do it.

For what it's worth, I'll throw my weight behind this as well. If the
Guides want to use MC for maintaining Squeak, I'll commit to making it
feasible as soon as possible.

Good. That makes both of us, then - G?ran, you have no excuse not to
pursue it now. ;)

Avi

[Brad Fuller]

Hi all,

From the responses so far, you may have assumed what I meant by "tighter" as

"more" process. I'm not necessarily suggesting that. I personally believe
there is a balance that must be maintained between strict software
engineering processes (like formally accepted review methods such as
Software Inspection) and the goals that the group is trying to achieve. In
Squeak's particular case (it's not just an open source application, but a
system where anyone can change anything -- a special case, IMHO), I believe
the approval processes are a bit too far to the left side, that's all. A lot
can be achieved with the right balance - by keeping it "agile" but also
putting in a few safeguards so people don't get sidewhacked.

Also, I don't think you can have more personal responsibility w/o more
community accountability. Clearly any system is only as good as the people
who make it.
I have no suggestions at this time, just my observation.

brad

-----Original Message-----
Sent: Sunday, July 11, 2004 2:37 PM
To: The general-purpose Squeak developers list
Subject: RE: How to improve Squeak
[SNIP]

Post by Brad Fuller
But, in addition and more important: After reviewing this link, I
don't have to tell you experienced ones that the approval

process is

Post by Brad Fuller
somewhat of a problem from a quality standpoint. For

instance, ONE harvester can "approve"

Post by Brad Fuller
a submission to be included in the image (and, it could be

his/her own

Post by Brad Fuller
submission) -- there is no mandated peer review, or even a

peer review

Post by Brad Fuller
process for that matter. I trust that everyone intimately

understands

Post by Brad Fuller
the other issues and problems with this process.

You know... I claim the total opposite. :) The process we
have now is somewhat bureaucratic and even though it works
"kinda" it would be better if the process was much more
agile. Normally open source projects don't have this kind of
process for core development - only for contributions coming
in from the outside.

Post by Brad Fuller
Has a proposal been put forth in the past to improve this

process? I

Post by Brad Fuller
for one would like to see this tighter.

"Tighter" would "kill" the joy and joy is what we thrive on.
In fact - as I said - we need a swifter process with more
trust in the experienced developers. The harvesting process
is perfectly fine for handling ENHs and FIXes coming in from
less experienced developers - but it should IMHO not be used
for core development by the more active experienced Squeakers.
We need something similar to a CVS with an update/commit
process based on trusted core developers. And I think we may
try to put something like that in place pretty soon - there
have been a few experiments. And even if we don't put that in
place for the image - it is used or can be used for the
packages being broken out of the image.
What we also need is less centralization and more personal
responsibility. That can be had using packages and maintainers. So...
more packages! More maintainers! :)
regards, G?ran

[Brad Fuller]

-----Original Message-----
Behalf Of Marcus Denker
Sent: Sunday, July 11, 2004 2:51 PM
To: The general-purpose Squeak developers list
Subject: Re: How to improve Squeak

Post by Brad Fuller
Has a proposal been put forth in the past to improve this

process? I

Post by Brad Fuller
for one would like to see this tighter. Perhaps this is what Ramiro
was pointing out in his "Magma" email.

I don't think it makes sense to thighten the process at this
point. I am aware that "shit happens" with the current process.
One simple example: I am the one to blame to have accepted
the "asPlural" changeset.
So, yes, dumb idea to approve that. Something like that happens.

One point to make here is that with a few safeguards, there wouldn't be
anyone to "blame". The proper process in the right setting would make sure
this doesn't happen. It doesn't mean that people can't have fun or that it
isn't agile. But, it could mean that Squeak would grow and be more
recognized and used by others.

But what's the alternative? Even with the "only one
harvester" rule, we don't manage to do *anything*
at all. Just look at BFAV: The amount of unreviewed stuff
is growing.
If we now require a real formal
process beyond what we have now, I fear that nothing will
happen. (I actually would call the current state of progress
"nothing" already).

Quality shouldn't be reduced because the queue gets bigger.

To come back to the example: Don't forget that we strike for
a "fast moving agile" process. So even with me doing the
wrong thing (approving somthing that should not be approved),
the right thing nevertheless will happen in the long run, as
it did with the asPlural stuff.

Cool: I like that goal. Something for me to keep in mind.

So to sum up: I don't think that making the process more
heavy-wheigt will be the solution.

I know you didn't suggest that I said this, but to be clear: I haven't
suggested any process, let alone a heavy-weight one.

Marcus

[danielv at tx.technion.ac.il ()]

Actually, note that the process is (somewhat) new, and other than some
fixes when things squeaked (;-) hasn't had too much discussion. So of
course new viewpoints are appreciated.

However - note that in this kind of endeavour (actually in many others
too), the benefits of many reasonable seeming policies can be
outweighted by their (sometimes indirect and hard to predict) costs if
they turn people off doing the work. So if you're interested in
improving it, you really should experience it first (read all the docs, review
someone else fix, try to get it resolved. Submit a fix/enh, get someone
to review it, until it is closed or approved).

I'm sure there are many things that could be done to improve the
process, and I for one would love to hear them, but they really need to
be clever and careful about use of precious resources, especially
people's time.

Daniel

Date: Sun, 11 Jul 2004 13:21:55 -0700
Subject: RE: How to improve Squeak
delivery-date: Sun, 11 Jul 2004 23:51:12 +0300
organization: Sonaural Audio Studios

Post by Brad Fuller

Post by Brad Fuller
Hi all,
What is the criteria and approval process of being in the

base image?
http://minnow.cc.gatech.edu/squeak/3152
Note that there aren't really strictly defined criteria for
something to be allowed in the base image, other than
approval/review from one or more harvesters and other
volunteers. However, most of the things being discussed here
(Squeak Server Pages, EventRecorderMorph, etc) pre-date the
existence of the Harvesting Process anyway. (they were added
earlier in the days of Squeak Central)
- Doug

Thanks Doug. I see now that the classes discussed here are before the
Harvesting Process. However, they could go back through the Harvesting
Process -- if this is the only formal process avaiable. At least they would
meet the same criteria as any new one -- and they could be thrown out if
need be.
But, in addition and more important: After reviewing this link, I don't have
to tell you experienced ones that the approval process is somewhat of a
problem from a quality standpoint. For instance, ONE harvester can "approve"
a submission to be included in the image (and, it could be his/her own
submission) -- there is no mandated peer review, or even a peer review
process for that matter. I trust that everyone intimately understands the
other issues and problems with this process.
Has a proposal been put forth in the past to improve this process? I for one
would like to see this tighter. Perhaps this is what Ramiro was pointing out
in his "Magma" email.
brad

[Russell Penney]

Stephane,
Sorry for the loss of the accent in your name, I can't find the
right character! :)

I agree wholeheartedly, I keep running across bits and pieces that do not
work. It must be very hard for people new to Squeak and/or Smalltalk to
makes sense of the multitude of class especially when lots of stuff doesn't
work OR doesn't work correctly!! I know I have been bitten a lot.

I am proposing parallel way of tiding things up a bit:

Resources (Codec is another (maybe better) term for the classes I will
describe in a sec)

A "resource" is some object encoded on a data source external to Squeak.
MP3, OGG, JPEG, MPEG, PNG, Hypertext, Rich text, Word documents, Illustrator
files, etc, etc ,etc.

The problem I see is that getting access to a "resource" is easy for some
types and not so easy for others. Most types have different interfaces.
ImageReadWriter is great but doesn't go far enough. Also types are usually
setup to read streams but again, sometimes, in an inconsistent manner. Which
can make code that writes a JPEG to a file, unable to write that JPEG to a
HTTP socket. Yes I know there is a way to do most things in the existing
classes BUT there is no common way.

As an application developer (say a new game or top level application) I want
to be able to reference some address and get a Form returned simply and
easily. Same for any sounds I want, or video, or my instructions page. I
don't want to have to learn a bunch of other classes (which have lots of
unfinished code in them) just to be able to return my resource object (lazy
aren't I). I don't care that my object is a JPEG file on a hard disk, I just
want it!!!!! :)

If I am writing a tool, I don't want to write an interface for files, HTTP,
FTP, etc. I want to write one interface for resources no matter where they
are.

This is so much re-inventing of interfaces to resources in current Squeak.
Having a good set of base interfaces would go a long way to cleaning up some
of the code.

I have made a start at http://minnow.cc.gatech.edu/squeak/415. I have a lot
more to document but this is a start to stimulate discussion.

I am willing to guide/drive this process and to write most/some of the code.
:) In fact I have made a start and am getting ready for another assault.

Oh and please note I am not suggesting we replace Stream classes, just
basically adding a high level layer over the top so people who don't care
about the implementation don't get bogged down in it.

Russell

[Andreas Raab]

Post by Brad Fuller

Post by Marcus Denker
One simple example: I am the one to blame to have accepted
the "asPlural" changeset.
So, yes, dumb idea to approve that. Something like that happens.

One point to make here is that with a few safeguards, there wouldn't be
anyone to "blame". The proper process in the right setting would make sure
this doesn't happen. It doesn't mean that people can't have fun or that it
isn't agile. But, it could mean that Squeak would grow and be more
recognized and used by others.

Sounds presumptuous. So what's this process that will fix all of these
issues?!

Cheers,
- Andreas

[Doug Way]

Off the top of my head this sounds like a good amount of work, and I
don't want to get stuck doing most or even half of it. ;) But it may
be the right thing to do.

I guess we should brainstorm a bit on how this might work before making
a decision, of course. Erm, would the "image" be a giant single
package in Monticello? Or at least the part of the basic image which
is not already split into other packages... which would still be a
pretty giant package at this point.

And then how would the update stream fit into this, if at all. It
would appear that the core committers would not need an update stream,
at least. Maybe there would still be an update stream for the "public"
alpha image somehow.

- Doug

Post by goran.krampe at bluefish.se ()
Hi people!

Post by Marcus Denker
To come back to the example: Don't forget that we strike for a "fast
moving agile" process.

Yes, and I think we should really sit down and try to set up Monticello
for managing the image. Avi has already done some experiments. Then we
should of course have limited "commit" access to that.
This way we can have BFAV for the contributions coming in (like patches
in other open source projects) and we can go straight to Monticello for
other stuff.
Such a model would help A LOT I think but it will demand two things of
1. Test it locally first. Don't commit stuff that is half baked. This
is
basic stuff for working in an open source project of course. In the
Mozilla project they say that the "tree is on fire" when someone does
that.
2. Write proper commit notes (= commit comment in CVS). Those will be
critical in knowing what has been done and for us to be able to produce
ChangeLogs.
I think perhaps if we do this step first - then we can more easily pick
up the TFNR goals again. It will be easier to perform those things when
we have a "full Monticello" working.
Avi? Comments? Is Monticello up to the task? :)
regards, G?ran

[Avi Bryant]

Post by Doug Way
I guess we should brainstorm a bit on how this might work before
making a decision, of course.

More than that - I would hope we would try it out in parallel with the
update stream for a few sets of updates to see how well it works before
we even talk about making a decision.

Post by Doug Way
Erm, would the "image" be a giant single package in Monticello? Or
at least the part of the basic image which is not already split into
other packages... which would still be a pretty giant package at this
point.

No, I think we'd want to carve it up much more than that - maybe one
package per major set of system categories (Kernel, Collections,
Morphic, etc). Though some of those (Morphic esp) are pretty huge in
themselves, and should probably be split more.

When Andreas and I tried a very early proto-attempt at this (see the
Squeak project on SqueakSource), we used one package per category,
which was easy, but probably excessive.

One thing to point out is that there's no requirement that the packages
have clean dependency chains between them - Monticello actually deals
reasonably well with spaghetti code arbitrarily carved into different
packages. I had a feeling that would be a necessary use case in this
world ;).

Post by Doug Way
And then how would the update stream fit into this, if at all. It
would appear that the core committers would not need an update stream,
at least. Maybe there would still be an update stream for the
"public" alpha image somehow.

I think the vision G?ran was articulating was to get rid of the update
stream altogether. That's not something we could do all at once, of
course, but I think it's a reasonable goal.

Avi

[goran.krampe at bluefish.se ()]

Post by Avi Bryant

Post by Doug Way
I guess we should brainstorm a bit on how this might work before
making a decision, of course.

More than that - I would hope we would try it out in parallel with the
update stream for a few sets of updates to see how well it works before
we even talk about making a decision.

Yes, let's:

1. Draft a plan. (we are doing it now and when this thread is over I can
put an article on SqP)

2. Make an experiment.

Post by Avi Bryant

Post by Doug Way
Erm, would the "image" be a giant single package in Monticello? Or
at least the part of the basic image which is not already split into
other packages... which would still be a pretty giant package at this
point.

No, I think we'd want to carve it up much more than that - maybe one
package per major set of system categories (Kernel, Collections,
Morphic, etc). Though some of those (Morphic esp) are pretty huge in
themselves, and should probably be split more.
When Andreas and I tried a very early proto-attempt at this (see the
Squeak project on SqueakSource), we used one package per category,
which was easy, but probably excessive.
One thing to point out is that there's no requirement that the packages
have clean dependency chains between them - Monticello actually deals
reasonably well with spaghetti code arbitrarily carved into different
packages. I had a feeling that would be a necessary use case in this
world ;).

That is VERY important. Because we can't take the time to untangle
stuff.
The important thing is that all code is covered and belongs *somewhere*.

Post by Avi Bryant

Post by Doug Way
And then how would the update stream fit into this, if at all. It
would appear that the core committers would not need an update stream,
at least. Maybe there would still be an update stream for the
"public" alpha image somehow.

I think the vision Göran was articulating was to get rid of the update
stream altogether. That's not something we could do all at once, of
course, but I think it's a reasonable goal.

Yes, but we need to make sure we don't "loose" something. For example,
today the ChangeSorters work as a live "Changelog". We might want
Monticello "commits" to produce changesets in the same fashion, or
provide a similar service some other way.

Another thing is "do its" - not sure if Monticello has support for such
stuff today.

Let's pretend we have solved these issues - since we IMHO should keep
BFAV for external contributions/fixes - then the harvesters could
actually "commit" approved FIXes instead of queueing them up for Doug.

Or if the queueing is of some value Doug could commit them in the proper
sequence.

Post by Avi Bryant
Avi

regards, Göran

[danielv at tx.technion.ac.il ()]

I think to replace the BFAV-centric process, MC needs to deal with some
of the same, and some new concepts:
1. Instead of global "approvers", MC should let each user have a list of
"repos I monitor". Dougs list is the list of "approvers".
2. In addition to existing concepts, we need "patch" or "change", which
aggregates some of the stuff an update does -
a. Set of specific changes to a package (or a few?)
b. Documentation of the change (as a change, besides code comments and
so forth)
People should be able to look at the list of patches in someones
repository, not just the code diffs compared to his version. People
should be able to take/reject/remove specific patches.
3. Bring attention to patches that deserve it. In the BFAV, this looks
like an item with reviews/testing comments. I don't know how this should
happen in the new scheme.

Ideas?

Daniel

Date: Mon, 12 Jul 2004 01:08:58 -0400
Subject: Re: Going for the Full Monti (Re: How to improve Squeak)
delivery-date: Mon, 12 Jul 2004 11:19:05 +0300
Off the top of my head this sounds like a good amount of work, and I
don't want to get stuck doing most or even half of it. ;) But it may
be the right thing to do.
I guess we should brainstorm a bit on how this might work before making
a decision, of course. Erm, would the "image" be a giant single
package in Monticello? Or at least the part of the basic image which
is not already split into other packages... which would still be a
pretty giant package at this point.
And then how would the update stream fit into this, if at all. It
would appear that the core committers would not need an update stream,
at least. Maybe there would still be an update stream for the "public"
alpha image somehow.
- Doug

Post by goran.krampe at bluefish.se ()
Hi people!

Post by Marcus Denker
To come back to the example: Don't forget that we strike for a "fast
moving agile" process.

Yes, and I think we should really sit down and try to set up Monticello
for managing the image. Avi has already done some experiments. Then we
should of course have limited "commit" access to that.
This way we can have BFAV for the contributions coming in (like patches
in other open source projects) and we can go straight to Monticello for
other stuff.
Such a model would help A LOT I think but it will demand two things of
1. Test it locally first. Don't commit stuff that is half baked. This
is
basic stuff for working in an open source project of course. In the
Mozilla project they say that the "tree is on fire" when someone does
that.
2. Write proper commit notes (= commit comment in CVS). Those will be
critical in knowing what has been done and for us to be able to produce
ChangeLogs.
I think perhaps if we do this step first - then we can more easily pick
up the TFNR goals again. It will be easier to perform those things when
we have a "full Monticello" working.
Avi? Comments? Is Monticello up to the task? :)
regards, Gsran

[Avi Bryant]

Post by danielv at tx.technion.ac.il ()
I think to replace the BFAV-centric process, MC needs to deal with some
1. Instead of global "approvers", MC should let each user have a list of
"repos I monitor".

Doesn't it already? Though I admit that "monitor" needs to be fleshed
out: what I want is for it to automatically download new versions it
finds in those repositories to the cache, and inform you of them - I'm
picturing repositories being treated something like RSS feeds.

Post by danielv at tx.technion.ac.il ()
2. In addition to existing concepts, we need "patch" or "change", which
aggregates some of the stuff an update does -
a. Set of specific changes to a package (or a few?)
b. Documentation of the change (as a change, besides code comments and
so forth)
People should be able to look at the list of patches in someones
repository, not just the code diffs compared to his version. People
should be able to take/reject/remove specific patches.

You can already look at the diffs between two arbitrary versions
(though I admit the UI could make this more obvious). And there are
already commit logs for each change you make (and a given commit should
really only encompass one or two changes). But no, there's no easy way
to apply the diff between two versions to an unrelated third version.
The problem is that this has unspecified ancestry semantics: in what
way does it affect future merges? Should it not change the ancestry of
your image at all, and just be as if you had independently made those
same changes? If that became a common practice, we'd make automatic
merges much messier down the line.

Avi

[danielv at tx.technion.ac.il ()]

Post by Avi Bryant

Post by danielv at tx.technion.ac.il ()
I think to replace the BFAV-centric process, MC needs to deal with some
1. Instead of global "approvers", MC should let each user have a list of
"repos I monitor".

Doesn't it already? Though I admit that "monitor" needs to be fleshed
out: what I want is for it to automatically download new versions it
finds in those repositories to the cache, and inform you of them - I'm
picturing repositories being treated something like RSS feeds.

You're right of course, I intended mostly to show the mapping - the
monitored repos replaces a current concept. This also shows what
enhancements would be beneficial in this context - ideally, Dougs
version
would use his monitored repos list to produce something very similar to
the BFAV window with the "approved" filter.

Post by Avi Bryant

Post by danielv at tx.technion.ac.il ()
2. In addition to existing concepts, we need "patch" or "change", which
aggregates some of the stuff an update does -
a. Set of specific changes to a package (or a few?)
b. Documentation of the change (as a change, besides code comments and
so forth)
People should be able to look at the list of patches in someones
repository, not just the code diffs compared to his version. People
should be able to take/reject/remove specific patches.

You can already look at the diffs between two arbitrary versions
(though I admit the UI could make this more obvious). And there are
already commit logs for each change you make (and a given commit should
really only encompass one or two changes).

I'm not convinced the concept I'm talking about should be mapped to
versions, but maybe. To make sure we're talking about the same use
case - during a month I apply 20 fixes from the BFAV (not everyone is
using MC (yet)). Doug was hard at work, comes back and sees I've
got some patch I've commited 3 weeks ago (presumably I'm happy with
them) and something suspicious I put in this last week, and also a fix
I took in at the beginning of the month. He should see the separate
patches
at a glance, and those he decides to adopt should survive intact with
their
former documentation (posters characterization, my review/notes..).
He should also be able to merge in or reject any of the above, without
much
regard to time, at least as long as they touch disjoint sets of code.

If the right way to do this is to have a version for every patch I
filein,
then it would be a good thing to MC to detect such system operations
and version before and after them automatically. I know the lack of this

feature was a great annoyance with change sets.

Post by Avi Bryant
But no, there's no easy way
to apply the diff between two versions to an unrelated third version.

AFAIU, they should not be unrelated versions - MCing people will be
synching with Dougs repository quite often. Maybe I'm missing
something?

Post by Avi Bryant
The problem is that this has unspecified ancestry semantics: in what
way does it affect future merges? Should it not change the ancestry of
your image at all, and just be as if you had independently made those
same changes? If that became a common practice, we'd make automatic
merges much messier down the line.

I think we should whatever is possible to make sure that merges do not
become more messy, since we'll be doing lots of them. For example if we
want to handle the file in of other formats as mentioned above, and
suppose to people filein the same code separately, it would be nice if
MC
knew the common ancestry (say, by using a content hash on the file).

(not sure whether I replied to your question, btw, if not, I didn't get
it :-)

BTW, at the moment I'm not particularly trying to make this
easy/incremental
on MC, but instead to think about what's need to make it easy to do the
process. Its important to think whether this can be done in small steps.

Daniel

[Avi Bryant]

Post by danielv at tx.technion.ac.il ()
If the right way to do this is to have a version for every patch I
filein, then it would be a good thing to MC to detect such system
operations
and version before and after them automatically. I know the lack of this
feature was a great annoyance with change sets.

That makes sense, as a transitional measure (for however long people
still submit change sets more than they do versions). It would be part
of a set of reviewer-friendly extensions to MC. I would imagine the
full process would be this:

- you start at a baseline version, probably a recent release
- you choose a changeset to review, which gets filed in. A version is
automatically saved, recording the preamble comment from the changeset.
- you try out the changes, possibly making minor modifications along
the way. When you're done, you provide a set of review notes. A new
version is made with your modifications and these notes.
- the system is then reverted back to the baseline release, before the
next changeset comes in

Post by danielv at tx.technion.ac.il ()

Post by Avi Bryant
But no, there's no easy way
to apply the diff between two versions to an unrelated third version.

AFAIU, they should not be unrelated versions - MCing people will be
synching with Dougs repository quite often. Maybe I'm missing
something?

No, I was just misunderstanding what you wanted.

Post by danielv at tx.technion.ac.il ()
I think we should whatever is possible to make sure that merges do not
become more messy, since we'll be doing lots of them. For example if we
want to handle the file in of other formats as mentioned above, and
suppose to people filein the same code separately, it would be nice if
MC knew the common ancestry (say, by using a content hash on the file).

Hm. So basically generate a fictional ancestor version for the
changeset, giving it a UUID based on the hash of the file. That's an
interesting idea. I'll have to think through the implications.

Avi

[danielv at tx.technion.ac.il ()]

Post by Avi Bryant
I would imagine the
- you start at a baseline version, probably a recent release
- you choose a changeset to review, which gets filed in. A version is
automatically saved, recording the preamble comment from the changeset.
- you try out the changes, possibly making minor modifications along
the way. When you're done, you provide a set of review notes. A new
version is made with your modifications and these notes.
- the system is then reverted back to the baseline release, before the
next changeset comes in

Delaying for a while more any consideration on my part for ease of
implementation, it seems to me like it would be more useful if the
testing/reviewing of patches is more smoothly integrated with day to day
work.

For example, I reviewed a patch, it seems sane, I file it in. I keep on
working, and testing other patches, until I have a chance to notice some
bugs come up that are related to that patch. So we shouldn't assume a
stack discipline to patch application. Also, I might later on have
additional comments to add that are related to that patch like "also
appears to solve the X bug", even without changing the code.

But adding the comment simply in a commit log wouldn't associate the
comment with the patch - in fact, AFAIU, once commited, there's no way
to add comments to the patch, if we view the patch as merely a version.
Hence, it might be that "patch", or whatever we call it, is better
modeled as a new entity. Maybe something that is itself editable and
versioned (a "kind of" package?), which refers to a dynamic set of
versions. Or maybe I'm going overboard and there's a much simpler
solution, but I think the problem exists.

Generally, the way I imagine the "gene" of code, the smallest meaningful
unit of code propagation, it looks more like a BFAV entry than like a
version. It should be a minimum of code, it should continuously acquire
any soft context/feedback the environment supplies...

Though of course I agree the existance and machinary provided by
versions could make their propagation much smoother. And versions give
us a more natural unit for wholesale adoption/synchronization of code
than patches or series of patches.

Daniel

[Avi Bryant]

Post by danielv at tx.technion.ac.il ()
For example, I reviewed a patch, it seems sane, I file it in. I keep on
working, and testing other patches, until I have a chance to notice some
bugs come up that are related to that patch. So we shouldn't assume a
stack discipline to patch application.

But if you're testing multiple patches at once, what you're really
testing is whether or not to patches can coexist. Which is a good
thing to test (and probably deserves a version of its own, with a
commit message like "successfully merged changes A and B, had to make
minor tweak C"), but you should have tested them in isolation first,
surely?
If you were really careful, you would use a "stack discipline" in your
day to day development, too. That is, the ideal thing from
Monticello's point of view would be that, every time you started a new
set of changes, you reverted back to the earliest version that could
support them and continued from there. If the next changes you make
are unrelated to those, you revert back again and branch. Then if both
of those changes are required to do the next changes, you merge the two
resulting versions and use that as the baseline going forward. But you
shouldn't do them linearly, because that implies to the versioning
system that the second changes are dependent on the first, and you'll
have trouble if you later want to use them on their own.
Now, I don't do this much in practice, because it's a hassle, and not
the way I'm used to working. But it would be interesting to see if
this awareness of the dependence and independence of sets of changes
could be integrated into the development environment well enough that
it was a natural and pleasant way to work.

Post by danielv at tx.technion.ac.il ()
Also, I might later on have
additional comments to add that are related to that patch like "also
appears to solve the X bug", even without changing the code.

Oh, I'm not really suggesting that the commit log be the only source of
comments. We definitely want some kind of bug-tracking system that's
connected to all this that is organized by thread, not by version. But
I think the traditional "issue" is more appropriate here than "patch":
as in the BFAV, you want to track comments and associated
changesets/versions right from the time the bug is reported to the time
it's closed, not just the history of a particular changeset. It sounds
like the question you're asking is "how do we replace the BFAV", and I
was trying to answer "how do we replace the update stream". I think
the answer to the latter will inform the former - except we won't
really replace it, just migrate it to a slightly different workflow.

Avi

[Doug Way]

Post by goran.krampe at bluefish.se ()
Hi people!
The question from Brad Fuller (below) spurred me into doing a recap of
how Squeak is ... well, partitioned or whatever you call it. This is
good to know - and not really dead simple, so I will give it a shot to
explain.
... For example, I am currently furiously trying to
shape up the SqueakMap2 packages in time for the Grand Release of
Squeak
3.7! :)
Finally it is worth mentioning the Full image. The Full image is the
Basic image with more cool packages installed on top. When the Basic
image is getting ready for release - like NOW - the assembly of the
Full
image needs to be taken care of.

Just so people don't think I've forgotten about it, the 3.7gamma image
is still due Real Soon Now.

Lately, I've been waiting for Goran's latest SM2 packages to include as
updates (which load from SM). We decided that these have only minor
new functionality and deserve to be in 3.7. The new SM2 versions are
out there and it looks pretty good so far, but I will wait for the
upcoming 1.01 bugfix release.

Other than that, I need to summarize the SqueakPeople poll on UI
preferences and change the appropriate settings in the gamma image.
Basically, it looks like I'll be turning on dragNDrop and also changing
the scrollbar width to not be tied to the font size, and that's it.
I'll do this while waiting for SM2 1.01.

Then I will do the other image cleanups including looking at the ones
Michael provided, updating the Welcome Window, etc. I'll shoot for
mid-week to have a gamma image ready.

- Doug

[goran.krampe at bluefish.se ()]

Post by Doug Way
Just so people don't think I've forgotten about it, the 3.7gamma image
is still due Real Soon Now.

Cool!

Post by Doug Way
Lately, I've been waiting for Goran's latest SM2 packages to include as
updates (which load from SM). We decided that these have only minor
new functionality and deserve to be in 3.7. The new SM2 versions are
out there and it looks pretty good so far, but I will wait for the
upcoming 1.01 bugfix release.

Sidenote: Make sure you install "SqueakMap2 base" before "SqueakMap2
loader". And also - check if they are already installed. :)

Post by Doug Way
Other than that, I need to summarize the SqueakPeople poll on UI
preferences and change the appropriate settings in the gamma image.
Basically, it looks like I'll be turning on dragNDrop and also changing
the scrollbar width to not be tied to the font size, and that's it.
I'll do this while waiting for SM2 1.01.

Coming later today.

Post by Doug Way
Then I will do the other image cleanups including looking at the ones
Michael provided, updating the Welcome Window, etc. I'll shoot for
mid-week to have a gamma image ready.

Sounds great.

Post by Doug Way
- Doug

regards, Göran

[Michael Rueger]

Post by Doug Way
Lately, I've been waiting for Goran's latest SM2 packages to include as
updates (which load from SM). We decided that these have only minor new
functionality and deserve to be in 3.7. The new SM2 versions are out
there and it looks pretty good so far, but I will wait for the upcoming
1.01 bugfix release.
PS. I think it is about time Monticello became an "Official package in
Basic". One good reason is that anyone who upgrades to the new SM2
releases I just made - and I assume everyone does eventually - will be
asked to install it anyway. Doug? Time to make that little update. :)

This would mean that in *gamma* both a new package loader and Monticello
would come into the image???

Michael

[Ned Konz]

Post by Michael Rueger

Post by Doug Way
Lately, I've been waiting for Goran's latest SM2 packages to include as
updates (which load from SM). We decided that these have only minor new
functionality and deserve to be in 3.7. The new SM2 versions are out
there and it looks pretty good so far, but I will wait for the upcoming
1.01 bugfix release.
PS. I think it is about time Monticello became an "Official package in
Basic". One good reason is that anyone who upgrades to the new SM2
releases I just made - and I assume everyone does eventually - will be
asked to install it anyway. Doug? Time to make that little update. :)

This would mean that in *gamma* both a new package loader and Monticello
would come into the image???

I agree. I thought we were trying to stick to FIXes in the gamma stream.

I wouldn't call loading Monticello as "only minor new functionality". Why, by
the way, does the new SM2 version require Monticello? The MCZInstaller does
OK for most SM package loading.

[Avi Bryant]

Why, by the way, does the new SM2 version require Monticello? The
MCZInstaller does
OK for most SM package loading.

Because people already have the old SM2 version installed. The
MczInstaller would load the new version on top of the old, instead of
doing a clean upgrade.

Avi

[Ned Konz]

Post by Avi Bryant

Why, by the way, does the new SM2 version require Monticello? The
MCZInstaller does
OK for most SM package loading.

Because people already have the old SM2 version installed. The
MczInstaller would load the new version on top of the old, instead of
doing a clean upgrade.

OK, but for the purposes of the upgrade stream, why not just distribute the
change set that MC produces when doing that? That way we could do a clean
upgrade without having to load Monticello to do it.

[goran.krampe at bluefish.se ()]

Hi all!

Post by Ned Konz

Post by Avi Bryant

Why, by the way, does the new SM2 version require Monticello? The
MCZInstaller does
OK for most SM package loading.

Because people already have the old SM2 version installed. The
MczInstaller would load the new version on top of the old, instead of
doing a clean upgrade.

OK, but for the purposes of the upgrade stream, why not just distribute the
change set that MC produces when doing that? That way we could do a clean
upgrade without having to load Monticello to do it.

I am just chatting with Doug on IRC and we just decided ( :) Yup, you
should be there!) that we skip Monticello for now, issue an upgrade of
MCInstaller from 8 to 10, and issue an upgrade for the two SM packages
with any method removals embedded in the changeset (since MCInstaller
don't do removals).

regards, Göran

[Avi Bryant]

Post by Michael Rueger
This would mean that in *gamma* both a new package loader and
Monticello would come into the image???

Yes, that seems excessive. Why not make those updates, if we want
them, the first ones in 3.8a?

[SmallSqueak]

Post by Avi Bryant

Post by goran.krampe at bluefish.se ()
Avi? Comments? Is Monticello up to the task? :)

Of course not - nobody's tried it yet ;). That is, there's
no reason in theory why it shouldn't work, but I have
confidence that we'll run into a whole bunch of problems at
the beginning, some of which I can predict (performance and

Oh, this reminds me after Chuck was loaded, any package
from SM was loaded very slowly.

Has anyone else experienced this slowness ?

Just wondering if Chuck or Monticello or the combination
was responsible for the slowness.

Post by Avi Bryant
UI issues arising from Monticello not being designed to
handle at once the 50+ packages we'll probably want to divide
the image into), most of which I'm sure I can't. But *will*

Talking of slicing, dicing and versioning, one would
wonder if Monticello and Ginsu can supplement each other.
Or are they just two completely different beasts.

Maybe Goran, who broke the news of the first public release
of Stable Squeak with an extensive and exclusive interview
and now has used Monticello a lot can give some review ?

Post by Avi Bryant
Monticello be up to the task, in the long run? Yes,
definitely. I think this is a great experiment, and if we
try it in earnest, I'll commit some serious time to smoothing
over whatever problems we run into.
My point is this: I think it's a good time to try this out,
but we'll be in for a rough ride. As long as you promise to
nag me to fix what's broken instead of getting discouraged
and giving up, then let's do it.

This is very encouraging.
Please keep up with the spirit.

Cheers,

PhiHo.

[Avi Bryant]

Post by SmallSqueak
Oh, this reminds me after Chuck was loaded, any package
from SM was loaded very slowly.
Has anyone else experienced this slowness ?
Just wondering if Chuck or Monticello or the combination
was responsible for the slowness.

Monticello likely is. Loading .mcz packages properly is definitely
slower than using the bootstrap MCInstaller. But how slowly is "very
slowly"?

Avi

[smallsqueak.net]

Post by Avi Bryant

Post by SmallSqueak
Oh, this reminds me after Chuck was loaded, any package
from SM was loaded very slowly.
Has anyone else experienced this slowness ?
Just wondering if Chuck or Monticello or the combination
was responsible for the slowness.

Monticello likely is. Loading .mcz packages properly is definitely
slower than using the bootstrap MCInstaller. But how slowly is "very
slowly"?

Honestly, it's been quite a while ago and it was the first impression.

Anyway, I guess it doesn't matter much how slowly it was 'very slow',
once we are aware of it and commit to improve it.

P4 4GHz is pretty soon the entry level PC while software engineering
is still an oxymoron so I guess we can rely on the hardware to
compensate
for what's lost during the process of de-oxymoronizing.
(Webster.com crashed when I searched for this word ;-)

Cheers,

PhiHo.

[goran.krampe at bluefish.se ()]

"SmallSqueak" <***@rogers.com> wrote:
[SNIP]

Post by SmallSqueak
Talking of slicing, dicing and versioning, one would
wonder if Monticello and Ginsu can supplement each other.
Or are they just two completely different beasts.
Maybe Goran, who broke the news of the first public release
of Stable Squeak with an extensive and exclusive interview
and now has used Monticello a lot can give some review ?

I didn't really dwelve into Ginsu, but IMHO Ginsu is "dead".

Monticello is a simpler solution more adapted to how open source
projects work (auto merge, distributed development etc) that *works* and
has become the de facto standard in Squeak, with a dedicated group of
developers behind it that are active in the Squeak community. That last
part is more important than anything else.

So... IMHO... forget Ginsu.

We have Monticello, Avi, Julian and Colin (and perhaps more). We don't
need no stinkin Ginsu. ;)


regards, Göran

PS. I think it is about time Monticello became an "Official package in
Basic". One good reason is that anyone who upgrades to the new SM2
releases I just made - and I assume everyone does eventually - will be
asked to install it anyway. Doug? Time to make that little update. :)

[smallsqueak.net]

Post by goran.krampe at bluefish.se ()
[SNIP]

Post by SmallSqueak
Talking of slicing, dicing and versioning, one would
wonder if Monticello and Ginsu can supplement each other.
Or are they just two completely different beasts.
Maybe Goran, who broke the news of the first public release
of Stable Squeak with an extensive and exclusive interview
and now has used Monticello a lot can give some review ?

I didn't really dwelve into Ginsu, but IMHO Ginsu is "dead".
Monticello is a simpler solution more adapted to how open source
projects work (auto merge, distributed development etc) that *works* and
has become the de facto standard in Squeak, with a dedicated group of
developers behind it that are active in the Squeak community. That last
part is more important than anything else.
So... IMHO... forget Ginsu.

Thanks for the review.

Post by goran.krampe at bluefish.se ()
We have Monticello, Avi, Julian and Colin (and perhaps more).

Agreed.

Post by goran.krampe at bluefish.se ()
We don't need no stinkin Ginsu. ;)

Now, now !

No stinking Piece Keeper would have this kind of attitude ;-)

Cheers,

PhiHo.

[Stephan Rudlof]

Brad,

Post by Brad Fuller
...

Post by Marcus Denker
I don't think it makes sense to thighten the process at this
point. I am aware that "shit happens" with the current process.
One simple example: I am the one to blame to have accepted
the "asPlural" changeset.
So, yes, dumb idea to approve that. Something like that happens.

And this is not a problem: some iteration(s) and all are happy.

Post by Brad Fuller
One point to make here is that with a few safeguards, there wouldn't be
anyone to "blame". The proper process in the right setting would make sure
this doesn't happen.

How should this work? What do you mean with a few safeguards (there are
already some of them in the actual process)?

Post by Brad Fuller
It doesn't mean that people can't have fun or that it
isn't agile. But, it could mean that Squeak would grow and be more
recognized and used by others.

Post by Marcus Denker
But what's the alternative? Even with the "only one
harvester" rule, we don't manage to do *anything*
at all. Just look at BFAV: The amount of unreviewed stuff
is growing.
If we now require a real formal
process beyond what we have now, I fear that nothing will
happen. (I actually would call the current state of progress
"nothing" already).

Quality shouldn't be reduced because the queue gets bigger.

But if it's too difficult to review fixes, the quality will be reduced,
since only a few fixes come through the bug fixing process then at all...

It's better to have some fixes with good quality than one or none with
super duper very mostly good one.

Recently I've made a review with comments and a further iteration, and I
can say: this is hard work beside the bug fixing process!
And it takes some time to start reviewing at all (you have to read some
docs to understand how it should work).
If you like you can try it...

I think currently the slowness of the process hinders quality in the
first place...


Greetings
Stephan

Post by Brad Fuller
...

[Marcus Denker]

Post by Stephan Rudlof

Post by Brad Fuller
One point to make here is that with a few safeguards, there wouldn't be
anyone to "blame". The proper process in the right setting would make sure
this doesn't happen.

How should this work? What do you mean with a few safeguards (there are
already some of them in the actual process)?

The interesting thing is that this question is a pretty fundamental
one: When designing
Systems, there are two philosopies of how to deal with errors or
failures: 1) Make sure
no Error happens 2) Errors will happen, deal with them.

The interesting thing is now that 2) allows to make the whole System
much much simpler
and powerful, as you can ommit all the savegards that ensured
"correctness" before.

Examples are: TCP/IP vs. the other system (e.g. ISDN), dynamic vs.
static typing, Agile
software development (e.g. XP) Vs. heavy weight methods, early Vs. late
binding...

Failiure is no "exceptional" state of a system, but the most important
one to design for.

Marcus

[Giovanni Giorgi]

Post by Marcus Denker
[...]
The interesting thing is that this question is a pretty
fundamental one: When designing
Systems, there are two philosopies of how to deal with
errors or
failures: 1) Make sure
no Error happens 2) Errors will happen, deal with them.
The interesting thing is now that 2) allows to make the
whole System
much much simpler
and powerful, as you can ommit all the savegards that
ensured "correctness" before.

In the first year of my professional IT job, I think to
protect the code from destructive changes.
Then I start to apply a "light" XP process on my work and
schedule.
I embrace the change, at least in my mind, because the
project I worked was not XP-oriented.

Now my project are planned for change: the code I wrote
*should be reviewed* in the next future!
This vision improved my code: errors are less then
expected, even if now I take less care when writing the
"single" code line, and plan often releases.
The only think to do is to stake outs, for example via
class comment, where the code can be broken and when should
not :)




=====
// Giovanni Giorgi http://www.siforge.org

[Lic. Edgar J. De Cleene]

Post by Karl Ramberg
Hi, here is a quick and dirty trick to avoid the bogus save menu options.
I just commented out the old menu options and offer Morph>>saveOnFile as
the only option for book saving. Works nice.
Karl

So, I send an slow and dirty subclass what could improve to a help system
into Squeak.
I call Anotador (kind of NotePad in Spanish) and is a subclass of BookMorph
intended for fit in poor people 800x600 machines (so many in poor countries
like Argentina).
My own solution:
Have a directory in image path named SqueakBooks

!ServerDirectory class methodsFor: 'server groups' stamp: 'edc 6/30/2004
09:52'!
localSqueakBooksDirectory
| fd |
LocalSqueakBooksDirectory ifNil: [fd _ FileDirectory default.
(fd directoryExists: 'SqueakBooks') ifFalse:[fd createDirectory:
'SqueakBooks'].

LocalSqueakBooksDirectory _ FileDirectory default pathName ,
FileDirectory slash , 'SqueakBooks' ].
^LocalSqueakBooksDirectory! !

Changing defaultStemUrl to:

!ServerDirectory class methodsFor: 'misc' stamp: 'edc 6/30/2004 09:58'!
defaultStemUrl
"For writing on an FTP directory. Users should insert their own server
url here."
"ftp://jumbo.rd.wdi.disney.com/raid1/people/dani/Books/Grp/Grp"
" ServerDirectory defaultStemUrl "

| rand dir |
rand := String new: 4.
1 to: rand size do: [:ii |
rand at: ii put: ('bdfghklmnpqrstvwz' at: 17 atRandom)].
dir := self serverNamed: 'DaniOnJumbo' ifAbsent: [^ 'file://',
ServerDirectory localSqueakBooksDirectory,FileDirectory slash].


Having in mind Mac weirdness about paths:

!FileUrl methodsFor: 'printing' stamp: 'edc 7/2/2004 07:43'!
toText
"Return the FileUrl according to RFC1738 plus supporting fragments:
'file://<host>/<path>#<fragment>'
Note that <host> being '' is equivalent to 'localhost'.
Note: The pathString can not start with a leading $/
to indicate an 'absolute' file path.
This is not according to RFC1738 where the path should have
no leading or trailing slashes, and always
be considered absolute relative to the filesystem."

^String streamContents: [:s |
s nextPutAll: self schemeName, '://'.
host ifNotNil: [s nextPutAll: host].
(Smalltalk platformName = 'Mac OS') ifFalse: [s nextPut: $/]. s
nextPutAll: self pathString.
fragment ifNotNil: [ s nextPut: $#; nextPutAll: fragment
encodeForHTTP ]]! !

!FileUrl methodsFor: 'private-initialization' stamp: 'edc 7/1/2004 09:33'!
privateInitializeFromText: aString
"Calculate host and path from a file URL in String format.
Some malformed formats are allowed and interpreted by guessing."

| schemeName pathString bare hasDriveLetter stream char i |
bare _ aString withBlanksTrimmed.
schemeName _ Url schemeNameForString: bare.
(schemeName isNil or: [schemeName ~= self schemeName])
ifTrue: [
host _ ''.
pathString _ bare]
ifFalse: [
"First remove schemeName and colon"
bare _ bare copyFrom: (schemeName size + 2) to: bare size.
"A proper file URL then has two slashes before host,
A malformed URL is interpreted as using syntax file:<path>."
(bare beginsWith: '//')
ifTrue: [i _ bare indexOf: $/ startingAt: 3.
i=0 ifTrue: [
host _ bare copyFrom: 3 to: bare size.
pathString _ '']
ifFalse: [
host _ bare copyFrom: 3 to: i-1.
pathString _ bare copyFrom: host size + 3
to: bare size]]
ifFalse: [host _ ''.
pathString _ bare]].
( Smalltalk platformName = 'Mac OS') ifFalse: [
self initializeFromPathString: pathString]
! !


!ServerDirectory methodsFor: 'accessing' stamp: 'edc 7/2/2004 07:52'!
printOn: aStrm
aStrm nextPutAll: self class name; nextPut: $<.
aStrm nextPutAll: self moniker.
(Smalltalk platformName = 'Mac OS') ifFalse: [aStrm nextPut: $>].
! !

!ServerDirectory methodsFor: 'file directory' stamp: 'edc 7/2/2004 08:08'!
fileNamed: fullName
"Create a RemoteFileStream for writing. If the file exists, do not
complain. fullName is directory path, and does include name of the server.
Or it can just be a fileName. Only write the data upon close."

| file remoteStrm path |
file _ self asServerFileNamed: fullName.
file readWrite.
file isTypeFile ifTrue: [(Smalltalk platformName = 'Mac OS') ifFalse: [
^ FileStream fileNamed: (file fileNameRelativeTo: self)] ifTrue:[
path _ fullName copyFrom: 8to: fullName size.

^ FileStream fileNamed: path ]
].

remoteStrm _ RemoteFileStream on: (String new: 2000).
remoteStrm remoteFile: file.
^ remoteStrm "no actual writing till close"
! !

So doing Anotador new reloadMeFromDisk brings all .sp pages .
I have a example full of Spanish and English recipes for Squeak stuff (with
authors or senders to list) what could sent to who is interested in this and
a morph saved with Karl solution which one click brings the "Anotador"
Also I try to have this help systen works with sblog.

Edgar

^ 'ftp://', dir server, dir slashDirectory, '/BK', rand! !

-------------- next part --------------
'From Squeak3.7beta of ''1 April 2004'' [latest update: #5923] on 9 July 2004 at 8:41:34 am'!
"Change Set: Anotador
Date: 9 July 2004
Author: Edgar J. De Cleene

I cook this slow and dirty partial solution for saving BookMorphs in Mac.
Is only for having NotePad (Anotador in Spanish) like pages and a index on disk"!

BookMorph subclass: #Anotador
instanceVariableNames: 'font'
classVariableNames: ''
poolDictionaries: ''
category: 'SqueakRos'!
Object subclass: #ServerDirectory
instanceVariableNames: 'server directory type user passwordHolder group moniker altURL urlObject client loaderUrl eToyUserListUrl eToyUserList keepAlive '
classVariableNames: 'LocalEToyBaseFolderSpecs LocalEToyUserListUrls LocalProjectDirectories Servers LocalSqueakBooksDirectory '
poolDictionaries: ''
category: 'Network-RemoteDirectory'!

!Anotador methodsFor: 'page controls' stamp: 'edc 7/6/2004 15:02'!
getBookNamefromUser
^FillInTheBlank request: 'Give a name for this book '.
! !

!Anotador methodsFor: 'page controls' stamp: 'edc 6/18/2004 09:57'!
getPageNamefromUser
| pn s |

pn _ FillInTheBlank request: 'Ingresar nombre pagina '.
s _ StringMorph contents: pn font: self font.
s center: (self center x) @ (self top + 50).
s color: Color blue.
self currentPage addMorph: s.
s beSticky

! !

!Anotador methodsFor: 'page controls' stamp: 'edc 3/4/2004 17:20'!
insertPage
| texto r |
pages isEmpty
ifTrue: [^ self insertPageColored: self color].
self insertPageColored: self color.
self getPageNamefromUser.

texto := pages first submorphs first copy.
texto setMyText: ''.
r := Rectangle
left: currentPage left + 5
right: currentPage right - 5
top: currentPage top + 20
bottom: currentPage bottom - 5.
texto bounds: r.
self currentPage addMorph: texto! !

!Anotador methodsFor: 'page controls' stamp: 'edc 5/19/2003 15:15'!
showPageNumber
| font pn s |
font _ StrikeFont familyName: #ComicBold size: 18.
pn _ self pageNumber asString.
s _ StringMorph contents: pn font: font.
s center: (self center x) @ (self bottom - s height).
self currentPage addMorph: s.
s beSticky

! !

!Anotador methodsFor: 'page controls' stamp: 'edc 7/7/2004 07:36'!
sortPagesByTitle
| sortedTitles sortedPages |

sortedTitles := (pages collect: [:pg | self pageTitle: pg ]) asSortedCollection .
sortedPages := OrderedCollection new.
sortedTitles do: [ :thispage | sortedPages add: (pages detect:[ :pg| thispage = (self pageTitle: pg) ]) ].
pages := pages species new.
pages addAll: sortedPages

! !

!Anotador methodsFor: 'as yet unclassified' stamp: 'edc 7/9/2004 08:31'!
exporting
| nombre texto blog story |

self pages
do: [:aPage|
nombre _ self pageTitle: aPage .
texto _ ( aPage findA: ScrollableField ) getMyText string.
blog _ SLBlog name: nombre.
story _ SLStory parent: nombre.
story title: nombre.
story text: texto.
story post.
story _ SLStory parent: blog].
blog save! !

!Anotador methodsFor: 'as yet unclassified' stamp: 'edc 7/9/2004 08:12'!
nombres
| nombre indice menu sel res |
menu := CustomMenu new.
menu title: 'Seleccione la pagina '.
indice := Dictionary new.
self pages
doWithIndex: [:each :ind |
nombre := self pageTitle: each .
indice at: nombre put: ind.
menu add: nombre action: #goToPage:.
menu addLine].
sel := menu startUp.

res := menu selection.
self goToPage: res! !

!Anotador methodsFor: 'as yet unclassified' stamp: 'edc 7/7/2004 08:44'!
title: aString
aString emphasis: 1.
aString center: self center x @ (self top + 55).
aString color: Color blue.
self currentPage addMorph: aString.
aString beSticky.! !

!Anotador methodsFor: 'accessing' stamp: 'edc 6/18/2004 09:55'!
font
"Answer the value of font"

^ StrikeFont familyName: #Accuny15 size: 12.! !

!Anotador methodsFor: 'accessing' stamp: 'edc 6/18/2004 09:53'!
font: anObject
"Set the value of font"

font _ anObject! !

!Anotador methodsFor: 'accessing' stamp: 'edc 7/9/2004 08:22'!
pageTitle: aPage
.
^ ( aPage findA: StringMorph ) contents
! !

!Anotador methodsFor: 'accessing' stamp: 'edc 7/6/2004 10:01'!
title
^(self currentPage findA: StringMorph ) contents! !

!Anotador methodsFor: 'initialization' stamp: 'edc 7/9/2004 08:09'!
initialize
| text r boton lev lev2 lev3 |
super initialize.
self borderWidth: 2.
self
color: (Color
r: 0.939
g: 0.939
b: 0.258).
self resizePagesTo: 350 @ 500.
self pages first color: self color.
self showMoreControls.
self openInWorld.

boton := SimpleButtonMorph new label: 'How to ...';
target: self;
color: Color lightBlue;
actionSelector: #nombres.
lev := (submorphs at: 1).
lev2 := lev submorphs at: 1.
lev3 := lev2 submorphs at: 1.
lev3 submorphs last delete.
lev3 addMorph: boton .
lev3 color: self color.
self title: (StringMorph contents: 'My Help System' font: self font).

text := ScrollableField new.
text
color: (Color
r: 0.972
g: 0.972
b: 0.662).
self currentPage addMorph: text.
r := Rectangle
left: text owner left + 5
right: text owner right - 5
top: text owner top + 25
bottom: text owner bottom - 5.
text bounds: r! !

!Anotador methodsFor: 'fileIn/out' stamp: 'edc 7/9/2004 08:24'!
localDiskSave
| nombre |

self forgetURLs.
self pages
do: [ :aPage |

nombre := ServerDirectory defaultStemUrl , self pageTitle: aPage
,'.sp'.
aPage saveOnURL: nombre].



! !

!Anotador methodsFor: 'fileIn/out' stamp: 'edc 7/8/2004 09:26'!
reloadMeFromDisk

| index urlList fileStream dir newpage |
dir := ServerDirectory defaultStemUrl.
dir := dir copyFrom: 8 to: dir size.
index := dir , self getBookNamefromUser
, '.ind'.

fileStream := FileStream oldFileNamed: index.
urlList := fileStream fileInObjectAndCode.
fileStream close.
urlList do: [:pgName | fileStream := FileStream oldFileNamed: dir,pgName. newpage := fileStream fileInObjectAndCode.
(newpage isKindOf: SqueakPage) ifTrue:[newpage := newpage asMorph].
fileStream close.pages add: newpage ].! !

!Anotador methodsFor: 'fileIn/out' stamp: 'edc 7/7/2004 09:08'!
saveIndexOnDisk
"Make up an index to the pages of this book, with thumbnails, and store it on the server. (aDictionary, aMorphObjectOut, aMorphObjectOut, aMorphObjectOut). The last part corresponds exactly to what pages looks like when they are all out. Each holds onto a SqueakPage, which holds a url and a thumbnail."

| index sf remoteFile urlList |
index := ServerDirectory defaultStemUrl , self getBookNamefromUser
, '.ind'.
urlList := pages collect: [:ppg | self pageTitle:ppg ].
sf := ServerDirectory new fullPath: index.
Cursor wait showWhile:
[remoteFile := sf fileNamed: index.
remoteFile dataIsValid.
remoteFile fileOutClass: nil andObject: urlList
"remoteFile close"]! !


!FileUrl methodsFor: 'printing' stamp: 'edc 7/2/2004 07:43'!
toText
"Return the FileUrl according to RFC1738 plus supporting fragments:
'file://<host>/<path>#<fragment>'
Note that <host> being '' is equivalent to 'localhost'.
Note: The pathString can not start with a leading $/
to indicate an 'absolute' file path.
This is not according to RFC1738 where the path should have
no leading or trailing slashes, and always
be considered absolute relative to the filesystem."

^String streamContents: [:s |
s nextPutAll: self schemeName, '://'.
host ifNotNil: [s nextPutAll: host].
(Smalltalk platformName = 'Mac OS') ifFalse: [s nextPut: $/]. s nextPutAll: self pathString.
fragment ifNotNil: [ s nextPut: $#; nextPutAll: fragment encodeForHTTP ]]! !

!FileUrl methodsFor: 'private-initialization' stamp: 'edc 7/1/2004 09:33'!
privateInitializeFromText: aString
"Calculate host and path from a file URL in String format.
Some malformed formats are allowed and interpreted by guessing."

| schemeName pathString bare hasDriveLetter stream char i |
bare _ aString withBlanksTrimmed.
schemeName _ Url schemeNameForString: bare.
(schemeName isNil or: [schemeName ~= self schemeName])
ifTrue: [
host _ ''.
pathString _ bare]
ifFalse: [
"First remove schemeName and colon"
bare _ bare copyFrom: (schemeName size + 2) to: bare size.
"A proper file URL then has two slashes before host,
A malformed URL is interpreted as using syntax file:<path>."
(bare beginsWith: '//')
ifTrue: [i _ bare indexOf: $/ startingAt: 3.
i=0 ifTrue: [
host _ bare copyFrom: 3 to: bare size.
pathString _ '']
ifFalse: [
host _ bare copyFrom: 3 to: i-1.
pathString _ bare copyFrom: host size + 3 to: bare size]]
ifFalse: [host _ ''.
pathString _ bare]].
( Smalltalk platformName = 'Mac OS') ifFalse: [
self initializeFromPathString: pathString]
! !


!ServerDirectory methodsFor: 'accessing' stamp: 'edc 7/2/2004 07:52'!
printOn: aStrm
aStrm nextPutAll: self class name; nextPut: $<.
aStrm nextPutAll: self moniker.
(Smalltalk platformName = 'Mac OS') ifFalse: [aStrm nextPut: $>].
! !

!ServerDirectory methodsFor: 'file directory' stamp: 'edc 7/2/2004 08:08'!
fileNamed: fullName
"Create a RemoteFileStream for writing. If the file exists, do not complain. fullName is directory path, and does include name of the server. Or it can just be a fileName. Only write the data upon close."

| file remoteStrm path |
file _ self asServerFileNamed: fullName.
file readWrite.
file isTypeFile ifTrue: [(Smalltalk platformName = 'Mac OS') ifFalse: [
^ FileStream fileNamed: (file fileNameRelativeTo: self)] ifTrue:[ path _ fullName copyFrom: 8to: fullName size.

^ FileStream fileNamed: path ]
].

remoteStrm _ RemoteFileStream on: (String new: 2000).
remoteStrm remoteFile: file.
^ remoteStrm "no actual writing till close"
! !


!ServerDirectory class methodsFor: 'misc' stamp: 'edc 6/30/2004 09:58'!
defaultStemUrl
"For writing on an FTP directory. Users should insert their own server url here."
"ftp://jumbo.rd.wdi.disney.com/raid1/people/dani/Books/Grp/Grp"
" ServerDirectory defaultStemUrl "

| rand dir |
rand := String new: 4.
1 to: rand size do: [:ii |
rand at: ii put: ('bdfghklmnpqrstvwz' at: 17 atRandom)].
dir := self serverNamed: 'DaniOnJumbo' ifAbsent: [^ 'file://', ServerDirectory localSqueakBooksDirectory,FileDirectory slash].

^ 'ftp://', dir server, dir slashDirectory, '/BK', rand! !

!ServerDirectory class methodsFor: 'server groups' stamp: 'edc 6/30/2004 09:52'!
localSqueakBooksDirectory
| fd |
LocalSqueakBooksDirectory ifNil: [fd _ FileDirectory default.
(fd directoryExists: 'SqueakBooks') ifFalse:[fd createDirectory: 'SqueakBooks'].

LocalSqueakBooksDirectory _ FileDirectory default pathName , FileDirectory slash , 'SqueakBooks' ].
^LocalSqueakBooksDirectory! !

Object subclass: #ServerDirectory
instanceVariableNames: 'server directory type user passwordHolder group moniker altURL urlObject client loaderUrl eToyUserListUrl eToyUserList keepAlive'
classVariableNames: 'LocalEToyBaseFolderSpecs LocalEToyUserListUrls LocalProjectDirectories LocalSqueakBooksDirectory Servers'
poolDictionaries: ''
category: 'Network-RemoteDirectory'!

[Brad Fuller]

Post by Brad Fuller

Post by Brad Fuller

Post by Marcus Denker
One simple example: I am the one to blame to have accepted the
"asPlural" changeset.
So, yes, dumb idea to approve that. Something like that happens.

One point to make here is that with a few safeguards, there

wouldn't

Post by Brad Fuller
be anyone to "blame". The proper process in the right setting would
make sure this doesn't happen. It doesn't mean that people

can't have

Post by Brad Fuller
fun or that it isn't agile. But, it could mean that Squeak

would grow

Post by Brad Fuller
and be more recognized and used by others.

Sounds presumptuous. So what's this process that will fix all
of these issues?!

Hi Andreas,

my point here is rather simple: if there is a problem, the process
should be analyzed and fixed; the person should not be blamed.

Again, I'm not suggesting a new process, but I could ;-)
It's just a red flag for me to see that code submissions can make it into a
released product without peer review. Is peer review a fix-all: heck no.
It's just one accepted practice. Is it fool-proof: heck no. I've seen
instances where people will make agreements just to get their code in (if
you'll approve mine, I'll approve yours). Any process can be hacked.

[Stephan Rudlof]

Brad,

Post by Brad Fuller
...
Hi Andreas,
my point here is rather simple: if there is a problem, the process
should be analyzed and fixed; the person should not be blamed.

Agreed.

Post by Brad Fuller
Again, I'm not suggesting a new process, but I could ;-)

You're welcome!

Post by Brad Fuller
It's just a red flag for me to see that code submissions can make it into a
released product without peer review.

Have you read the docs related to the BFAV and how to deal with the
ENH/FIX process in Squeak?
Have you tried to make a review yourself to understand it?

Post by Brad Fuller
Is peer review a fix-all: heck no.
It's just one accepted practice. Is it fool-proof: heck no. I've seen
instances where people will make agreements just to get their code in (if
you'll approve mine, I'll approve yours). Any process can be hacked.

That's always true. But not the case here.

1. About a year ago I've been forced - at work - to make peer reviews of
rotten UML diagrams, where the people haven't known how to model well in
UML (I've visited some introduction course and spoken with the teacher).
The diagrams looked nice, but haven't tackled the real problems to be
solved: it was *only* top-down design, and stopped in direction to the
down where it starts to become difficult (and interesting, of course!).
And it has taken so much time to explain what was bad in these diagrams...

2. I know software development planning in a very complex project with
some scientific aspects, where 'pi * thumb' planning would have been far
superior about the pseudo-exact MSProject plans. One of the highlights:
an MSProject plan with say 100 tasks, but with none (human) resource
allocation; in short: is every task taken some time exactly made by one
man this time? Not very probable...

Sorry, but you have hitted - without intention, of course - some wounded
point in my professional life...


Greetings and peace
Stephan

[Doug Way]

Post by Michael Rueger

Post by Doug Way
Lately, I've been waiting for Goran's latest SM2 packages to include
as updates (which load from SM). We decided that these have only
minor new functionality and deserve to be in 3.7. The new SM2
versions are out there and it looks pretty good so far, but I will
wait for the upcoming 1.01 bugfix release.
PS. I think it is about time Monticello became an "Official package in
Basic". One good reason is that anyone who upgrades to the new SM2
releases I just made - and I assume everyone does eventually - will be
asked to install it anyway. Doug? Time to make that little update. :)

This would mean that in *gamma* both a new package loader and
Monticello would come into the image???

Well, it's still 3.7beta right now when they would go in, but it would
soon be gamma afterward.

But you're right... unless the new package loader really needs
Monticello in order to function (and I don't think it does), we'd
probably be better off adding Monticello in 3.8alpha instead.

The new package loader is mostly bug fixes and some modest UI usability
improvements. It's a slight stretch, but I don't think it's too
unreasonable to add in 3.7beta right now. (Well, I guess the category
filtering pane is a significant UI addition.)

- Doug

[lex at cc.gatech.edu ()]

My goodness, 38 posts and no one answered the question itself. Everyone
is making plans and proprosing processes, but eventually someone needs
to actually change the system you know. :)

In short, BookMorph is old. It has bitrotted because not many people
are using it and because its core functionality is now in a different
part of the UI. Nowadays, projects are used as "pages" of a multi-page
work. Instead of a BookMorph, we have project threads. Instead of a
navigation bar, we have a navigation flap plus
InternalNavigationMorph's. Resorting is still present, but you access
it via InternalNavigationMorph instead of through the BookMorph toolbar.

Because of this history, I don't see a particular reason to fix up
BookMorph at all. This is not some random widget, but is designed to be
a core part of the UI. The UI doesn't use it any more. Even if
BookMorph is fixed up to work well in current Squeak's, it's feature set
should surely be revisited because most of the stuff just doesn't make
sense nowadays. And really, why does it need to be fixed up anyway?
It is perfectly fine just to delete the thing or even just to mark the
comment as "no longer supported, but present for historical interest".


Now, my two cents on process is that this is a perfectly normal
situation in a system that is supposed to have experimental stuff in it.
We don't need any process; we just need someone who has some vision
about the state of the whole image, to go through and if things like
this. That seems to be happening, so what's the problem? If anything,
my suggestion would be for individuals to start volunteering as stewards
of the image(s); I don't expect that we can have an excellent image when
every little change is made by committee. And if multiple people step
forward, that's great too; we'll have multiple images that are all
interesting.



-Lex

[Avi Bryant]

Post by lex at cc.gatech.edu ()
Now, my two cents on process is that this is a perfectly normal
situation in a system that is supposed to have experimental stuff in it.
We don't need any process; we just need someone who has some vision
about the state of the whole image, to go through and if things like
this. That seems to be happening, so what's the problem? If anything,
my suggestion would be for individuals to start volunteering as stewards
of the image(s); I don't expect that we can have an excellent image when
every little change is made by committee. And if multiple people step
forward, that's great too; we'll have multiple images that are all
interesting.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yes, yes, yes. That's exactly what I have in the back of my head when
I talk about replacing the update stream with Monticello. The problem
with the update stream is that we're all using, effectively, "Doug's
image" (there is, of course, a large process behind it; I don't mean to
imply that we're subject to Doug's tyrannical whims). But it would be
great to be able to track, say, "Ned's image" instead. These would
probably share a lot of changesets, and advance more or less in step,
but would likely have different criteria for which fixes and
enhancements went into them. And of course really what I'd be tracking
is "Avi's image" (which I might as well make public - why not?), which
*would* be subject to my tyrannical whims, but which would probably
mostly just feed off of Doug/Ned/whoever else's images with some minor
local tweaks.

Anyway, in theory this could be done with update streams, but I don't
think it would scale very well. For one thing, a crucial part of the
process I'm describing is being able to steal changes you like from
other people's streams. It's easy enough to move a given changeset
over to your stream, but it might depend on changes that were made
earlier that you don't have, or conflict with changes that you've made
locally, and so on. It would also be tedious for a user to switch from
image to image - migrating a "Doug image" to a "Ned image" would be
nearly impossible. You'd have to go back to a baseline release and
start again with the new stream from there.

Monticello wouldn't make it *easy* to manage all of this, but it would
certainly make it much more feasible. This is exactly the kind of
thing that its distributed repository and merging model was designed
for.

Avi

[Kamil Kukura]

Yes, yes, yes. That's exactly what I have in the back of my head when I
talk about replacing the update stream with Monticello. The problem
with the update stream is that we're all using, effectively, "Doug's
image" (there is, of course, a large process behind it; I don't mean to
imply that we're subject to Doug's tyrannical whims). But it would be
great to be able to track, say, "Ned's image" instead. These would
probably share a lot of changesets, and advance more or less in step,
but would likely have different criteria for which fixes and
enhancements went into them. And of course really what I'd be tracking
is "Avi's image" (which I might as well make public - why not?), which
*would* be subject to my tyrannical whims, but which would probably
mostly just feed off of Doug/Ned/whoever else's images with some minor
local tweaks.

This brought a deep thoughts to me. I was always thinking about
_purpose_ of given image. If Squeak was born with intention to be
playground for education/learning, then it's understandable that it
contains a lot of "play with this" things. But now it's possible to use
Squeak to build something useful for daily life. I develop web
applications which deal with data storages. I have plan for development
of applications relying on touchscreen and thus using Morphic. I like it
resembles me a society of people working in different areas. You can
have coffee which is result of activity of people knowing how to best
gather coffee beans, of people who prepared those beans, of people who
built machine that is able to process these beans and finally bartender
who specialize on how to assembly objects such as cup, hot coffee,
sugar, spoon, etc. But as a matter of fact, at the very begining all
these people were kids playing with toys. In order to contribute to this
world, we are first up to recognize/grasp it.

So, can we determine what is desired state of "young" image, ready to go
to real life? I've seen this tagged as "minimal". I'm trying to find
desired state of image which could be referred as "adolescent" - knowing
all crucial things in order to become adult in its own specialized way.
I can see there aspect of "manifestation" (can display in specific
way, can recognize keyboard/mouse gestures, can respond to surrounding
events) and "sophistication" (can access other computer via network, can
use hardware it sees, can persist for survival). Does it make sense?

Sometimes I have relax time just browsing what's in the image. It feels
like adventure game. For example recently I "discovered" StarSqueak as
it floats in 3.6 full image. Now I wonder why there are methods in class
SmartRefStream named as:

#starLogoAntColonybosfcedppplppppttwssdlgrstta0
#starLogoMorphbosfcedppplppppttwssdlgrstt0
#starLogoTreesbosfcedppplppppttwssdlgrsttdt0
#starLogoTurtlewwxywwhcpn0

Is it normal, or some kind of bug?

[stéphane ducasse]

Hi kamil

I will try to answer your questions a bit :)

- It is important that you can develop real applications with Squeak
(even if Squeak is already a quite complex applications in itself).
There are some really good tools already.

- Now parts of squeak need energy to be cleaned, adapted to new
requirements. So feel free to help
us making the system better. This can be by writing tests to document
classes, proposing enh....

Post by Kamil Kukura
Sometimes I have relax time just browsing what's in the image. It
feels like adventure game. For example recently I "discovered"
StarSqueak as it floats in 3.6 full image. Now I wonder why there are
#starLogoAntColonybosfcedppplppppttwssdlgrstta0
#starLogoMorphbosfcedppplppppttwssdlgrstt0
#starLogoTreesbosfcedppplppppttwssdlgrsttdt0
#starLogoTurtlewwxywwhcpn0

I would say that this is related to saving starLogo in projects, and
knowing which class to use when
loading projects back in the image.

Stef

[Serge Stinckwich]

Post by lex at cc.gatech.edu ()
My goodness, 38 posts and no one answered the question itself. Everyone
is making plans and proprosing processes, but eventually someone needs
to actually change the system you know. :)
In short, BookMorph is old. It has bitrotted because not many people
are using it and because its core functionality is now in a different
part of the UI. Nowadays, projects are used as "pages" of a multi-page
work. Instead of a BookMorph, we have project threads. Instead of a
navigation bar, we have a navigation flap plus
InternalNavigationMorph's. Resorting is still present, but you access
it via InternalNavigationMorph instead of through the BookMorph toolbar.
Because of this history, I don't see a particular reason to fix up
BookMorph at all. This is not some random widget, but is designed to be
a core part of the UI. The UI doesn't use it any more. Even if
BookMorph is fixed up to work well in current Squeak's, it's feature set
should surely be revisited because most of the stuff just doesn't make
sense nowadays. And really, why does it need to be fixed up anyway?
It is perfectly fine just to delete the thing or even just to mark the
comment as "no longer supported, but present for historical interest".

Hi Lex,
i think you are a bit harsh with BookMorph. Because, i think they are
much useful
for doing slides presentation than projects ... I'm using BookMorph for
many presentations and if they are not perfect, i think that they have a
role. I also try projects for presentations but i have suffer from a lot
of problems.

-- oooo
Serge Stinckwich OOOOOOOO
Universit? de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO
http://purl.org/net/SergeStinckwich oooooo
Smalltalkers do: [:it | All with: Class, (And love: it)] \ /
##

[goran.krampe at bluefish.se ()]

Hi all!

I am a bit lost here. I use BookMorph for my presentations. I save them
currently using the ... well, whatever "save morph" does - probably a
refstream.

I never bothered with SqueakPages etc, because I knew that was rotten
anyway.

So what is the problem? BookMorph works just fine - no need to dump it
at all, just rip out the SqueakPage-whatever-it-is-stuff. :)

regards, Göran

[stéphane ducasse]

Hi goran

What I want to be able to do is:
- save a page
- save this page on a server so that we can build shared powerpoint
presentation
- I want to be able to edit using a texteditor the order of the
presentation
because the dragand drop thumbnail can be painful.
- I want to be able to say: here is a script and a directory: build
the presentation for me

I tried to do that using projects and I failed because projects are too
complex for my limited amount
of time.

I started to use bookMorph for static slides (because I want to be able
to reuse my slides).
So I'm planning to develop slowly my own BookMorph and we will see.

Stef

Post by goran.krampe at bluefish.se ()
Hi all!
I am a bit lost here. I use BookMorph for my presentations. I save them
currently using the ... well, whatever "save morph" does - probably a
refstream.
I never bothered with SqueakPages etc, because I knew that was rotten
anyway.
So what is the problem? BookMorph works just fine - no need to dump it
at all, just rip out the SqueakPage-whatever-it-is-stuff. :)
regards, G?ran

[stéphane ducasse]

Hi lex

finally somebody answers :)
The problems with projects is that you can get a lot of problems with
them. I tried to do some simple
extension of the navigator to be able to save and load automatically
some projects to build a demo from a textual description and this is
complex.... :(.
I used them for my previous demoes but a simple bookmorph that we could
save on a server
and with a simple way yo sort pages is definitively needed. So I think
that I will start to write one
by looking at BookMorph.

Stef

Post by lex at cc.gatech.edu ()
My goodness, 38 posts and no one answered the question itself.
Everyone
is making plans and proprosing processes, but eventually someone needs
to actually change the system you know. :)
In short, BookMorph is old. It has bitrotted because not many people
are using it and because its core functionality is now in a different
part of the UI. Nowadays, projects are used as "pages" of a multi-page
work. Instead of a BookMorph, we have project threads. Instead of a
navigation bar, we have a navigation flap plus
InternalNavigationMorph's. Resorting is still present, but you access
it via InternalNavigationMorph instead of through the BookMorph toolbar.
Because of this history, I don't see a particular reason to fix up
BookMorph at all. This is not some random widget, but is designed to be
a core part of the UI. The UI doesn't use it any more. Even if
BookMorph is fixed up to work well in current Squeak's, it's feature set
should surely be revisited because most of the stuff just doesn't make
sense nowadays. And really, why does it need to be fixed up anyway?
It is perfectly fine just to delete the thing or even just to mark the
comment as "no longer supported, but present for historical interest".
Now, my two cents on process is that this is a perfectly normal
situation in a system that is supposed to have experimental stuff in it.
We don't need any process; we just need someone who has some vision
about the state of the whole image, to go through and if things like
this. That seems to be happening, so what's the problem? If anything,
my suggestion would be for individuals to start volunteering as stewards
of the image(s); I don't expect that we can have an excellent image when
every little change is made by committee. And if multiple people step
forward, that's great too; we'll have multiple images that are all
interesting.
-Lex

[danielv at tx.technion.ac.il ()]

Umm, like he said.

That's what 3.8 alpha is for. People should either get their stuff
ready in time for alpha, or wait for the next release. Even Guides.

Maybe especially Guides? :-)

IMHO, of course.

Daniel

Post by Michael Rueger
This would mean that in *gamma* both a new package loader and Monticello
would come into the image???
Michael

[Richard A. O'Keefe]

***@cc.gatech.edu wrote:
In short, BookMorph is old. ...
Because of this history, I don't see a particular reason to fix up
BookMorph at all. This is not some random widget, but is designed to be
a core part of the UI. The UI doesn't use it any more. ...
And really, why does it need to be fixed up anyway?
It is perfectly fine just to delete the thing or even just to mark the
comment as "no longer supported, but present for historical interest".

I would have been very happy to see saving a BookMorph to a file work.
I have several times used BookMorphs as a kind of "rich man's PowerPoint"
(NOT "poor man's" -- BookMorphs are *better* as far as I'm concerned).

I have always put my occasional problems with BookMorphs down to inadequate
documentation. I don't *care* whether they are a "core" part of the UI or
not, they do a useful job, and if they were better documented and not left
to rot I suspect more people would use them.

By arguing in this way you could kill off practically ANY part of Squeak.
Conceal from people how to use it.
Make incompatible changes to the system.
Then say it's not core and doesn't need to be fixed.

It may well be that BookMorphs *should* die, but PLEASE, someone write
a *DETAILED* tutorial about how to get the same funcationality from the
other aspects of the system FIRST.

And I do mean detailed. About the level of the documentation that
BookMorph should have had in the first place, in fact.

[lex at cc.gatech.edu ()]

Post by Richard A. O'Keefe
It may well be that BookMorphs *should* die, but PLEASE, someone write
a *DETAILED* tutorial about how to get the same funcationality from the
other aspects of the system FIRST.
And I do mean detailed. About the level of the documentation that
BookMorph should have had in the first place, in fact.

Okay. :) Really, the functionality is there, and Squeak Central does
not use BookMorph, and I have watched the UI develop to phase out
BookMorph in favor of other mechanisms. I almost always use Squeak
instead of PowerPoint or Latex, and yet I haven't used BookMorph in many
years.

To make a better analogy, fixing up BookMorph for 3.7 is like trying to
make PROGMAN.EXE from Windows 3.1 work in Windows XP. There can be long
discussions about it, and probably you can succeed to some level, but in
the end it's a silly thing to do. This isn't just a matter of
preferences; we are talking about a UI component that has been
deliberately redesigned into something better.

Following the analogy, if you really really like Program Manager from
Windows 3.1, then you may as well just stick with 3.1. You'll probably
be a lot happier. If you really like BookMorph, then stick with Squeak
2.8. You'll have company....

For people wanting to use the newer style, though, let me give a few
pointers. I am sorry I cannot give a full tutorial, but the following
should really be enough. This is simple stuff I think:

1. Instead of pages, use entire projects.

2. Instead of a "next" and "previous" buttons from BookMorph, use
InternalThreadNavigationMorph's. Go ahead andopen one up if
you are curiuos; it will drop itself to the bottom right corner of
the screen.

3. Instead of book's, make "threads". If you click in the middle of
an ITNM you will get a lot of options for creating and manipulating
threads -- options very similar to BookMorph's menu when you click
the little circle. To get started, you should probably "create a
thread
of all projects" and then edit it down to what you want.


That's it, poor man's powerpoint and no BookMorph. What features have I
left out that people are wondering about?


Oh, one other thing I should mention, especially if someone wants to
redo a half-completed BookMorph as a thread of projects:

4. Make a flap called "Scratch" that you use to transfer stuff between
projects. Flaps are terrific if you are jumping between projects a lot.
As one example, you can transfer a morph between two projects by going
to project A, dumping the morph in the flap, going to project B, and
removing the morph from the flap. Simple. So go make that flap; if you
author in Squeak a lot, I bet you end up using it!

Post by Richard A. O'Keefe
I never bothered with SqueakPages etc, because I knew that was rotten
anyway.

Dude, SqueakPage is part of BookMorph. :)


Anyway, there happens to be some space on the Swiki for discussing
presentations in Squeak. If anyone is really psyched about this area
then they should flesh it out a little.

http://minnow.cc.gatech.edu/squeak/3486

It even includes a short tutorial on ITNM plus an email from Alan Kay
about ITNM's that is dated July 2001.

-Lex

[Stéphane Rollandin]

Post by lex at cc.gatech.edu ()
That's it, poor man's powerpoint and no BookMorph. What features have I
left out that people are wondering about?

saving the presentation in a file.

in my understanding it is not possible to save more than one project as
a file, and saving a single project with sub-projects does not work
either. am I missing something ?


Stef

[David T. Lewis]

Lex, your four-step recipe for poor-persons' Powerpoint is actually quite
helpful. I've made a couple of SqueakerPoint presentations of rather
dubious quality, and I could have gotten them done faster and better if
I had read your recipe first.

If you have a chance, maybe you could add this to the swiki.

Dave

Post by lex at cc.gatech.edu ()
For people wanting to use the newer style, though, let me give a few
pointers. I am sorry I cannot give a full tutorial, but the following
1. Instead of pages, use entire projects.
2. Instead of a "next" and "previous" buttons from BookMorph, use
InternalThreadNavigationMorph's. Go ahead andopen one up if
you are curiuos; it will drop itself to the bottom right corner of
the screen.
3. Instead of book's, make "threads". If you click in the middle of
an ITNM you will get a lot of options for creating and manipulating
threads -- options very similar to BookMorph's menu when you click
the little circle. To get started, you should probably "create a
thread of all projects" and then edit it down to what you want.
That's it, poor man's powerpoint and no BookMorph. What features have I
left out that people are wondering about?
Oh, one other thing I should mention, especially if someone wants to
4. Make a flap called "Scratch" that you use to transfer stuff between
projects. Flaps are terrific if you are jumping between projects a lot.
As one example, you can transfer a morph between two projects by going
to project A, dumping the morph in the flap, going to project B, and
removing the morph from the flap. Simple. So go make that flap; if you
author in Squeak a lot, I bet you end up using it!

[Milan Zimmermann]

Hi,

Playing with InternalThreadNavigationMorph .. I have created a "My
PresentationProject" which has 4 Projects in it, each intended to be one
"Page" of the presentation. As well, in "My PresentationProject" I have a
there a InternalThreadNavigationMorph which navigates through the 4 pages.

My problem is that once navigating inside the InternalThreadNavigationMorph ,
I cannot find a straightforward way to go back to the "parent" "My
PresentationProject" ... I was thinking it should be on the middle button ...
anyway, is there a way to go back to parent?

Milan

Post by lex at cc.gatech.edu ()

Post by Richard A. O'Keefe
It may well be that BookMorphs *should* die, but PLEASE, someone write
a *DETAILED* tutorial about how to get the same funcationality from the
other aspects of the system FIRST.
And I do mean detailed. About the level of the documentation that
BookMorph should have had in the first place, in fact.

Okay. :) Really, the functionality is there, and Squeak Central does
not use BookMorph, and I have watched the UI develop to phase out
BookMorph in favor of other mechanisms. I almost always use Squeak
instead of PowerPoint or Latex, and yet I haven't used BookMorph in many
years.
To make a better analogy, fixing up BookMorph for 3.7 is like trying to
make PROGMAN.EXE from Windows 3.1 work in Windows XP. There can be long
discussions about it, and probably you can succeed to some level, but in
the end it's a silly thing to do. This isn't just a matter of
preferences; we are talking about a UI component that has been
deliberately redesigned into something better.
Following the analogy, if you really really like Program Manager from
Windows 3.1, then you may as well just stick with 3.1. You'll probably
be a lot happier. If you really like BookMorph, then stick with Squeak
2.8. You'll have company....
For people wanting to use the newer style, though, let me give a few
pointers. I am sorry I cannot give a full tutorial, but the following
1. Instead of pages, use entire projects.
2. Instead of a "next" and "previous" buttons from BookMorph, use
InternalThreadNavigationMorph's. Go ahead andopen one up if
you are curiuos; it will drop itself to the bottom right corner of
the screen.
3. Instead of book's, make "threads". If you click in the middle of
an ITNM you will get a lot of options for creating and manipulating
threads -- options very similar to BookMorph's menu when you click
the little circle. To get started, you should probably "create a
thread
of all projects" and then edit it down to what you want.
That's it, poor man's powerpoint and no BookMorph. What features have I
left out that people are wondering about?
Oh, one other thing I should mention, especially if someone wants to
4. Make a flap called "Scratch" that you use to transfer stuff between
projects. Flaps are terrific if you are jumping between projects a lot.
As one example, you can transfer a morph between two projects by going
to project A, dumping the morph in the flap, going to project B, and
removing the morph from the flap. Simple. So go make that flap; if you
author in Squeak a lot, I bet you end up using it!

Post by Richard A. O'Keefe
I never bothered with SqueakPages etc, because I knew that was rotten
anyway.

Dude, SqueakPage is part of BookMorph. :)
Anyway, there happens to be some space on the Swiki for discussing
presentations in Squeak. If anyone is really psyched about this area
then they should flesh it out a little.
http://minnow.cc.gatech.edu/squeak/3486
It even includes a short tutorial on ITNM plus an email from Alan Kay
about ITNM's that is dated July 2001.
-Lex

[C. David Shaffer]

Post by Milan Zimmermann
Hi,
Playing with InternalThreadNavigationMorph .. I have created a "My
PresentationProject" which has 4 Projects in it, each intended to be one
"Page" of the presentation. As well, in "My PresentationProject" I have a
there a InternalThreadNavigationMorph which navigates through the 4 pages.
My problem is that once navigating inside the InternalThreadNavigationMorph ,
I cannot find a straightforward way to go back to the "parent" "My
PresentationProject" ... I was thinking it should be on the middle button ...
anyway, is there a way to go back to parent?

Milan,

I usually make the "parent" the first project in my thread that way you
can use the "First project in thread" menu item from the ITNM.
Recently, I got out of the habit of having all of the projects be
children of the root project. Instead, I use the ITNM's "insert new
project" menu option to create a new project. You may or may not like
this since it won't create a thumbnail of the project anywhere. The
only places you'll see it are in the ITNM and in the "jump to
project..." menu. It is certainly a matter of personal preference but
the reason I stopped creating all of the projects rooted in a single
project is that lengthy talks make crowded root projects and I found
myself wasting time rearranging the thumbnails so I could see them all.

I've been using projects to make my presentations for a year now (3
presentations). I have a lot of complaints but I'm reluctant to share
them as I don't have any code to share. Now, if someone solicits
comments that would be another story :-) I can add at least one hint in
addition to Lex's comment regarding flaps: copy morphs. One thing I
found myself doing consistently was (pseudo-smalltalk/morph, sorry,
don't have my actual code handy):

"Do this once to set up the container for your templates"
Smalltalk at: #PageTemplates put: Dictionary new.

"Execute this code in a page which has a format you like, change
BulletPage to something which describes the page"
PageTemplates at: #BulletPage put: (World submorphs collect: [:morph
| morph copy])

"Go to the new/destination project and execute this code"
(PageTemplates at: #BulletPage) do: [:morph | morph copy
openInWorld: World]

I think that's how it worked. The thing I most fuzzy on is sending copy
(was it deepCopy or something?). The wonderful thing about this
mailling list is that I'm sure if it's wrong someone will correct me
:-) Anyway this works well if you write presentations where the slide
format doesn't vary much from slide to slide (like us boring academic
types tend to do). The reason I used a dictionary was to keep from
having globals scattered all around Smalltalk. It also makes creating
some scripted buttons quite easy.

Also, I couldn't get any of the ServerDirectory classes to work with my
Apache+WebDAV system so I wrote DAVServerDirectory and posted it to the
list. It allows you to save your projects right to an Apache web server
(I recommend using stunnel since Squeak doesn't support SSL and
publishing unencrypted is begging for trouble).

Finally, if you're using 3.6 and True-Type Fonts, be sure to get Diego's
patch from BFAV since otherwise you won't be able to properly load your
published presentations (you must have the patch installed when you
publish!).

David

[Milan Zimmermann]

David,

Thanks for the hints.

I played with making the "parent/root project" the first project in the
presentation and that works well for being able to jump back to the "parent".
As well, I played with just creating the "Presentation Pages" directly from
the InternalThreadNavigationMorph(ITNM) as you suggested by doing:

click "edit this thread"
click "make a new project" (the middle image on ITNM)
drop new project on presentation thread

This works very nicely in that it does not unnecesarily display those
"Presentation Pages" on the "parent project", just lists them in the ITNM
(but see 2 below).

There are a few complaints I would have from a UI perspective .. I'll just
list them to get it off my mind :)

1) The most confusing thing: If I click on the ITNM middle button and do
"simply close this navigator". it disappears and I do not have any another
way to get back to it, apart from dragging a NEW ITNM. Maybe I missed
something ...

2) Within Squeak, the presentation pages created as described above are
visible on "jump to project" as standalone "projects" - which they are but it
would be far more natural if the InternalThreadNavigationMorph (ITNM) becomes
a "Parent Project" on the "jump to project" list (or there could be a menu
item in world for "presentations/navigations" that would list the ITNMs) ..
the way it is now is confusing because it "flattens" all pages of all
presentation I may have and clutters the project list way too much ...

3) I do not see and easy way to save the presentation, I think that is what
you are describing below

Thanks again for the suggestion, including copy and publishing to web server,
have to try some day,

Milan

Post by Raymond Asselin

Post by Milan Zimmermann
Hi,
Playing with InternalThreadNavigationMorph .. I have created a "My
PresentationProject" which has 4 Projects in it, each intended to be one
"Page" of the presentation. As well, in "My PresentationProject" I have a
there a InternalThreadNavigationMorph which navigates through the 4 pages.
My problem is that once navigating inside the
InternalThreadNavigationMorph , I cannot find a straightforward way to go
back to the "parent" "My PresentationProject" ... I was thinking it
should be on the middle button ... anyway, is there a way to go back to
parent?

Milan,
I usually make the "parent" the first project in my thread that way you
can use the "First project in thread" menu item from the ITNM.
Recently, I got out of the habit of having all of the projects be
children of the root project. Instead, I use the ITNM's "insert new
project" menu option to create a new project. You may or may not like
this since it won't create a thumbnail of the project anywhere. The
only places you'll see it are in the ITNM and in the "jump to
project..." menu. It is certainly a matter of personal preference but
the reason I stopped creating all of the projects rooted in a single
project is that lengthy talks make crowded root projects and I found
myself wasting time rearranging the thumbnails so I could see them all.
I've been using projects to make my presentations for a year now (3
presentations). I have a lot of complaints but I'm reluctant to share
them as I don't have any code to share. Now, if someone solicits
comments that would be another story :-) I can add at least one hint in
addition to Lex's comment regarding flaps: copy morphs. One thing I
found myself doing consistently was (pseudo-smalltalk/morph, sorry,
"Do this once to set up the container for your templates"
Smalltalk at: #PageTemplates put: Dictionary new.
"Execute this code in a page which has a format you like, change
BulletPage to something which describes the page"
PageTemplates at: #BulletPage put: (World submorphs collect: [:morph
| morph copy])
"Go to the new/destination project and execute this code"
(PageTemplates at: #BulletPage) do: [:morph | morph copy
openInWorld: World]
I think that's how it worked. The thing I most fuzzy on is sending copy
(was it deepCopy or something?). The wonderful thing about this
mailling list is that I'm sure if it's wrong someone will correct me
:-) Anyway this works well if you write presentations where the slide
format doesn't vary much from slide to slide (like us boring academic
types tend to do). The reason I used a dictionary was to keep from
having globals scattered all around Smalltalk. It also makes creating
some scripted buttons quite easy.
Also, I couldn't get any of the ServerDirectory classes to work with my
Apache+WebDAV system so I wrote DAVServerDirectory and posted it to the
list. It allows you to save your projects right to an Apache web server
(I recommend using stunnel since Squeak doesn't support SSL and
publishing unencrypted is begging for trouble).
Finally, if you're using 3.6 and True-Type Fonts, be sure to get Diego's
patch from BFAV since otherwise you won't be able to properly load your
published presentations (you must have the patch installed when you
publish!).
David

[stéphane ducasse]

Hi richard

I agree with you and I'm thinking to see how we can program a
clean/simpler/bookmorph with TESTS.
the active documentation. ;)

Stef

Post by Richard A. O'Keefe
In short, BookMorph is old. ...
Because of this history, I don't see a particular reason to fix up
BookMorph at all. This is not some random widget, but is designed to be
a core part of the UI. The UI doesn't use it any more. ...
And really, why does it need to be fixed up anyway?
It is perfectly fine just to delete the thing or even just to mark the
comment as "no longer supported, but present for historical interest".
I would have been very happy to see saving a BookMorph to a file work.
I have several times used BookMorphs as a kind of "rich man's
PowerPoint"
(NOT "poor man's" -- BookMorphs are *better* as far as I'm concerned).
I have always put my occasional problems with BookMorphs down to inadequate
documentation. I don't *care* whether they are a "core" part of the UI or
not, they do a useful job, and if they were better documented and not left
to rot I suspect more people would use them.
By arguing in this way you could kill off practically ANY part of Squeak.
Conceal from people how to use it.
Make incompatible changes to the system.
Then say it's not core and doesn't need to be fixed.
It may well be that BookMorphs *should* die, but PLEASE, someone write
a *DETAILED* tutorial about how to get the same funcationality from the
other aspects of the system FIRST.
And I do mean detailed. About the level of the documentation that
BookMorph should have had in the first place, in fact.

[jhkeel]

Post by lex at cc.gatech.edu ()
If anything,
my suggestion would be for individuals to start volunteering as stewards
of the image(s);

Lex,

Many of us have volunteered. I offered to steward "collections" for TFNR over 7 months
ago and nothing has come of it. We are just waiting for someone to give us the go ahead
on that long delayed project.

Jack

[goran.krampe at bluefish.se ()]

Post by jhkeel

Post by lex at cc.gatech.edu ()
If anything,
my suggestion would be for individuals to start volunteering as stewards
of the image(s);

Lex,
Many of us have volunteered. I offered to steward "collections" for TFNR over 7 months
ago and nothing has come of it. We are just waiting for someone to give us the go ahead
on that long delayed project.
Jack

Yes, I know. I lost all momentum on that unfortunately. Perhaps the time
is ripe again.

We should probably just start small. But let us get this damn 3.7 out
the door first, should be done this week. Still busy with the SM stuff
here...

regards, Göran

[smallsqueak.net]

Hi Jack,

Post by jhkeel

Post by lex at cc.gatech.edu ()
If anything,
my suggestion would be for individuals to start volunteering as stewards
of the image(s);

Lex,
Many of us have volunteered. I offered to steward "collections" for TFNR over 7 months
ago and nothing has come of it. We are just waiting for someone to give us the go ahead
on that long delayed project.

Let's look at the brighter side of it.

There are still 4 more months to go
before November arrives ;-)

In the meantime, let's keep stocking ammunition,
and make best use of the gelatine printing press
to advertise the revolution. (It's even more effective
with localized DVD copiers ;-)

Viva la revolution !

Cheers,

SmallSqueak.

[danielv at tx.technion.ac.il ()]

Ok, go ahead.

I propose the following first objectives: (specific to collections, but
this is generalizable)
Most of the collections code should be basic stuff that everyone and
everything uses. This means that it should not depend on optional stuff,
like UI frameworks. So:
1. Go through the collection class, and make a list of any that are not
such - stuff used or adapted to only a specific application. These
should be in another package, possibly to be extracted.
2. Go through the collection classes again, this time looking at
methods, and find any methods that refer to non-basic stuff, like
applications, or Morphic and so forth. Then you have to situations:
A. If these methods serve only specific application, then they should
be moved to class extensions. If you don't know what to call the class
extensions at the moment (maybe the package these should belong to
doesn't exist yet), do it anyway. The assignment of these external
methods will be easy to refine later, the important part is to separate
them out.
B. If they are general method that use other mechanisms that don't seem
completely basic (use sound system to beep, for example), then they
might require refactoring. Try to figure out what should be done about
them. Write up a message to the list about them.
3. When all the collections class categories depend only on stuff in
Kernel, themselves, or other very basic class categories, be happy,
you've achieved something significant. Make reasonable changesets and
submit.

And please, let people know how you're doing, so we can learn from one
anothers experience.

BTW, there are tools that do most of the easy parts, like looking for
external (PackageInfo externalReferences or something like it), the hard
work is deciding what is what.

You might think other goals are more worthy, then go ahead. But don't
just wait.

Daniel Vainsencher

Date: Tue, 13 Jul 2004 13:55:34 -0000
Subject: Re: How to improve Squeak
delivery-date: Tue, 13 Jul 2004 19:15:13 +0300

Post by lex at cc.gatech.edu ()
If anything,
my suggestion would be for individuals to start volunteering as stewards
of the image(s);

Lex,
Many of us have volunteered. I offered to steward "collections" for TFNR over 7 months
ago and nothing has come of it. We are just waiting for someone to give us the go ahead
on that long delayed project.
Jack

[danielv at tx.technion.ac.il ()]

As to BookMorph itself, it sounds like its a piece of the system that
some people use - it should be a package, external or internal. Someone
that wants to give it some love should make sure its not hardcoded
anywhere, make a nice package for it, with nice docs, and put it on SM.

Then the decision of whether it is in any particular image or not is a
trivial one to change.

If someone cares about BM either way, the first thing to do in the
process is to see where references to it are hardcoded, which would be
also the first step in deleting it anyway.

So this is the same things we've talked about a long time ago - most
of the solution to the complexity problem in Squeak is refactoring things
into packages. So why do you guys think this is not happening faster?

Daniel

Date: Tue, 13 Jul 2004 12:53:35 +0200
Subject: Re: How to improve Squeak
delivery-date: Tue, 13 Jul 2004 16:30:37 +0300
Hi all!
I am a bit lost here. I use BookMorph for my presentations. I save them
currently using the ... well, whatever "save morph" does - probably a
refstream.
I never bothered with SqueakPages etc, because I knew that was rotten
anyway.
So what is the problem? BookMorph works just fine - no need to dump it
at all, just rip out the SqueakPage-whatever-it-is-stuff. :)
regards, Gsran

[Lic. Edgar J. De Cleene]

Post by Avi Bryant
Anyway, in theory this could be done with update streams, but I don't
think it would scale very well. For one thing, a crucial part of the
process I'm describing is being able to steal changes you like from
other people's streams. It's easy enough to move a given changeset
over to your stream, but it might depend on changes that were made
earlier that you don't have, or conflict with changes that you've made
locally, and so on. It would also be tedious for a user to switch from
image to image - migrating a "Doug image" to a "Ned image" would be
nearly impossible. You'd have to go back to a baseline release and
start again with the new stream from there.

Avi:
Not really.
I like see and try code by Squeakers more advanced.
The "experimental" or chaos mode of Squeak is the most valuable thing.
Remember, in Greek mythology (and modern Entropy_, world and life evolved
from chaos.

I wait you, Ned, Goran and all masters publish your images somewhere.
Or only give us , the people, a list of what packages you think is important
have/ test in ours.

Edgar

[jhkeel]

Post by goran.krampe at bluefish.se ()

Post by jhkeel

Post by lex at cc.gatech.edu ()
If anything,
my suggestion would be for individuals to start volunteering as stewards
of the image(s);

Lex,
Many of us have volunteered. I offered to steward "collections" for TFNR over 7

months

Post by goran.krampe at bluefish.se ()

Post by jhkeel
ago and nothing has come of it. We are just waiting for someone to give us the go

ahead

Post by goran.krampe at bluefish.se ()

Post by jhkeel
on that long delayed project.
Jack

Yes, I know. I lost all momentum on that unfortunately. Perhaps the time
is ripe again.
We should probably just start small. But let us get this damn 3.7 out
the door first, should be done this week. Still busy with the SM stuff
here...
regards, G?ran

I understand and I certainly wasn't complaining about your work on this front - there is
only so much you can do and you do a lot. But it is difficult to help you "insiders" when
the rest of us aren't sure where things stand. I was just letting you know that we are still
out here waiting to help if only given the chance.

And

Post by goran.krampe at bluefish.se ()
Ok, go ahead.
I propose the following first objectives:.....

<bunch of reasonable ideas/>

Post by goran.krampe at bluefish.se ()
You might think other goals are more worthy, then go ahead. But don't
just wait.
Daniel Vainsencher

Okay, thanks, I won't wait. Curious, I didn't see your name on the task force list :)

However, I have been thinking about this for several months (i.e., not just waiting) and
your list of tasks (and any others Squeakers wish to provide) will be added to my existing
list of tasks and considered in due course and within priority.

I seem to be from the St?phane Ducasse school of thought though, and my first order of
business might be to
1. Get in contact with G?ran, Peter van Rooijen, and Richard O'Keefe (others who were
interested in Collections)
2. add/improve Class and Method documentation (so we know what we've got and to see
if our changes actually will make it into the system),
3. add unit tests (so we know what works, how it performs, and, later, what we break, slow
down, or speed up),
4. accumulate ISO, VW, VA, Blue Book and other info so we know how it might fit into the
world at large,
5. generate UML diagrams or other documentation so others may understand it too and
provide informed comments on our proposed future directions
6. then we'll consider what we're going to do *to* it but do it in a way that nothing that is
running now breaks.

Jack

[stéphane ducasse]

Hi Jack


Something that I would do if I would be you would be to take the online
books
available on my web page and check all the stupid examples on
collection and turn them into
tests. Then check the comments because this way you would have already
scenarios
and comments can rot faster than tests.

Stef

Post by jhkeel

Post by goran.krampe at bluefish.se ()

Post by jhkeel

Post by lex at cc.gatech.edu ()
If anything,
my suggestion would be for individuals to start volunteering as stewards
of the image(s);

Lex,
Many of us have volunteered. I offered to steward "collections" for TFNR over 7

months

Post by goran.krampe at bluefish.se ()

Post by jhkeel
ago and nothing has come of it. We are just waiting for someone to give us the go

ahead

Post by goran.krampe at bluefish.se ()

Post by jhkeel
on that long delayed project.
Jack

Yes, I know. I lost all momentum on that unfortunately. Perhaps the time
is ripe again.
We should probably just start small. But let us get this damn 3.7 out
the door first, should be done this week. Still busy with the SM stuff
here...
regards, G?ran

I understand and I certainly wasn't complaining about your work on this front - there is
only so much you can do and you do a lot. But it is difficult to help you "insiders" when
the rest of us aren't sure where things stand. I was just letting you
know that we are still
out here waiting to help if only given the chance.
And

Post by goran.krampe at bluefish.se ()
Ok, go ahead.
I propose the following first objectives:.....

<bunch of reasonable ideas/>

Post by goran.krampe at bluefish.se ()
You might think other goals are more worthy, then go ahead. But don't
just wait.
Daniel Vainsencher

Okay, thanks, I won't wait. Curious, I didn't see your name on the task force list :)
However, I have been thinking about this for several months (i.e., not just waiting) and
your list of tasks (and any others Squeakers wish to provide) will be added to my existing
list of tasks and considered in due course and within priority.
I seem to be from the St?phane Ducasse school of thought though, and my first order of
business might be to
1. Get in contact with G?ran, Peter van Rooijen, and Richard O'Keefe (others who were
interested in Collections)
2. add/improve Class and Method documentation (so we know what we've got and to see
if our changes actually will make it into the system),
3. add unit tests (so we know what works, how it performs, and, later, what we break, slow
down, or speed up),
4. accumulate ISO, VW, VA, Blue Book and other info so we know how it might fit into the
world at large,
5. generate UML diagrams or other documentation so others may
understand it too and
provide informed comments on our proposed future directions
6. then we'll consider what we're going to do *to* it but do it in a
way that nothing that is
running now breaks.
Jack

[danielv at tx.technion.ac.il ()]

Post by jhkeel
Okay, thanks, I won't wait. Curious, I didn't see your name on the task force list :)

Yup, it got started just as a busy spell came on me. Might find my dirty
finger prints on related projects though :-)

Post by jhkeel
However, I have been thinking about this for several months (i.e., not just waiting)

Cool

Post by jhkeel
I seem to be from the StZphane Ducasse school of thought though, and my first order of
business might be to
1. Get in contact with Gsran, Peter van Rooijen, and Richard O'Keefe (others who were
interested in Collections)
2. add/improve Class and Method documentation (so we know what we've got and to see
if our changes actually will make it into the system),
3. add unit tests (so we know what works, how it performs, and, later, what we break, slow
down, or speed up),
4. accumulate ISO, VW, VA, Blue Book and other info so we know how it might fit into the
world at large,
5. generate UML diagrams or other documentation so others may understand it too and
provide informed comments on our proposed future directions
6. then we'll consider what we're going to do *to* it but do it in a way that nothing that is
running now breaks.

Sounds all good. Some things that might or might not help:
- Start with things you're sure you want and know how to do and will be
fun.
-Wiki pages with your plans. Having your plans in the open where people
can see them will also help you get feedback and other help from the
community.
- If your plans involve blocks that will be non-trivial for the
harvesting process to swallow, get feedback early.

Hope at least some of this helps,
Daniel

[Raymond Asselin]

Hi Lex,

I jump in the discussion because I'm not an heavy user of
BookMorph but I really appreciate it and for now I believe that
BookMorph give us things no other objects in the image give us.

I must say that I know everything you mentioned about project and
use them for presentation. But really there is situations where I like
BookMorph better. Often I use them all together (Projects and
BookMorphs).

Don't forget that BookMorph is "also" a way to 'bundle', to 'package'
content in one file, and to transport it...or send it to somebody else it
is not only pages we can flip. Also note that there is time when the
90 projects I have in one image are difficult to manage...It is easier to
manage 3 BookMorphs instead.... I'm kidding...Projects are more than
BookMorphs... but also less than that. It is'nt a good idea to think in
term of replacing Projects with BookMorphs.

The other way is faisable (Replace BookMorphs with Projects) but
IMHO the functionality provide with projects and or Squeak isn't all
there yet.

- For example, you can save a BookMorph 'as a morph' in a file, and
load it in another image....go load the 40 projects you used as 'pages'
instead of one BookMorph.... ! May be we just need easy way to save
and load threads of projects from the InternalThreadNavigationMorph
...

- There is time too where you have pictures and where you prefer to
put them in a BookMorph instead of in multiple projects you first have
to create. Again it may be just another functionality we can add to
the image but we will need PersonaliseGraphicalImport we can pick an
say 'create projects for each image' in that one.

- Or you just want to browse the pages in a BookMorph without
leaving the current project.... again we need a kind of GraphicalImport
ENHANCED with method to view graphics files on disk before to import
them etc....

Personnaly I think BookMorph is not 'THE WAY' but 'one of ours tools'
and for now, until we have the functionality mentioned and may be
others somebody else can think of, I don't want to get rid of it.

My point is like your in a way.....

' THE BETTER WAY TO GET RID OF BOOKMORPH IS TO ENHANCE THE
SQUEAK ENVIRONNEMENT SO THAT NO BODY WANT TO USE
BOOKMORPH ANYMORE...'

I repeat, IMHO, we are not there yet.

Raymond

[lex at cc.gatech.edu ()]

Post by Raymond Asselin
' THE BETTER WAY TO GET RID OF BOOKMORPH IS TO ENHANCE THE
SQUEAK ENVIRONNEMENT SO THAT NO BODY WANT TO USE
BOOKMORPH ANYMORE...'
I repeat, IMHO, we are not there yet.

I repeat, the guys who wrote BookMorph have learned from their
experience and moved on. Are you sure you might simply be overlooking
where the new functionality is?

Post by Raymond Asselin
Don't forget that BookMorph is "also" a way to 'bundle', to 'package'
content in one file, and to transport it...or send it to somebody else it
is not only pages we can flip.

Yes. Nowadays there are two options in addition to BookMorph:

1. Send around an image as a bundle.
2. Save your projects on a superswiki, and ship around a project that
holds links to all the projects.

Post by Raymond Asselin
It is'nt a good idea to think in
term of replacing Projects with BookMorphs.

That's a deep question. On the face of it, both approaches look fine to
me. Instead of choosing one way or the other, it seems more important
to pick a direction and be consistent about it. That is the main thing
that bugs me about trying to patch up every single method currently in
BookMorph; I would much rather see one of:

1. Phase out BookMorph, and copying over any missing functionality to
the newer "threads" approach. Possibly leave behind a lobotomized
BookMorph if that makes sense.

2. Refactor BookMorph and ITNM somehow so that they really are just
different views on the same underlying components. This seems more
trouble than it is worth, but would be neat to see.

Post by Raymond Asselin
- For example, you can save a BookMorph 'as a morph' in a file, and
load it in another image....go load the 40 projects you used as 'pages'
instead of one BookMorph.... !

I normally use whole images or use a SuperSwiki, both of which work well
in these situations. You should probably also be able to save an ITNM;
I haven't tried.

A save-all command may still be nice, however. I don't see one in
there, but here's some untested code that is probably close:

saveAllInThread
listOfPages do: [ :pageInfo |
(Project named: pageInfo first) storeOnServer ]


There's no nead for load-all, by the way -- once you load the ITNM
top project, the others will get loaded.

Post by Raymond Asselin
- There is time too where you have pictures and where you prefer to
put them in a BookMorph instead of in multiple projects you first have
to create. Again it may be just another functionality we can add to
the image but we will need PersonaliseGraphicalImport we can pick an
say 'create projects for each image' in that one.

I don't understand what you are describing. I have had no problems
putting pictures into projects....

Post by Raymond Asselin
- Or you just want to browse the pages in a BookMorph without
leaving the current project.... again we need a kind of GraphicalImport
ENHANCED with method to view graphics files on disk before to import
them etc....

The functionality of looking at multiple things at the same time comes
via overlapping windows and via flaps. Can you be more specific about
what you are missing? (Other than a better file browser)

Post by Raymond Asselin
The problems with projects is that you can get a lot of problems with
them. I tried to do some simple
extension of the navigator to be able to save and load automatically

Automatic loading is already in there. Automatic saving is missing
AFAIK, but let's add it like I described above.

I'm not sure whether auto-save as you flip through is useful, if there
were a "save all" menu item. It's easy to implement though; just add a
'autoSave' instance variable to ITNM, and have the switch-to-page method
check the flag.

Post by Raymond Asselin
some projects to build a demo from a textual description and this is
complex....

Why build from a text list when you have a GUI? Anyway, if you really
want it, you should look at ThreadNavigationMorph class>>example1, which
does just that.

Post by Raymond Asselin
and with a simple way yo sort pages is definitively needed.

Choose "edit this thread" from the menu.


-Lex

[stéphane ducasse]

Hi lex

I tried to work with projects. I started to have a kind of bundle that
would contain several projects and a description file. So that we could
reorder the presentation by simply editing them. But I got stuck when
doing exactly this kind of loops because the code is much much more
complex.

Stef

Post by lex at cc.gatech.edu ()
saveAllInThread
listOfPages do: [ :pageInfo |
(Project named: pageInfo first) storeOnServer ]

[lex at cc.gatech.edu ()]

Okay, I withdraw my objection. Fix up BookMorph, anyone who is
interested, especially if it is just minor tweak. However, the general
issue remains: we have two UI's that do the same sort of stuff but are
missing key functionality in different areas. Since we seem to have no
one who is champonioning the overall UI, we end up with inconsistencies
like this. But also, given a lack of UI champion, I guess we may as
well keep things going as long as possible. And heck, maybe BookMorph's
win out in the end and it's project threads that go away.


On specific issues, let me toss in half a cent, rounded down.

Post by stéphane ducasse
But I got stuck when
doing exactly this kind of loops because the code is much much more
complex.

Okay, there is a problem in that if you save a project, it will kill
your thread; thus, it is hard to keep saving it. However, it only
*needs* to kill the thread if you are saving the current project. (And
maybe even that is not necessary, but I haven't looked closely enough.)
Thus, it is sufficient to save the current project last, and to tweak
the project-saving machinery to only kill your thread if you are saving
the current project.

So here's an updated saveAllInThread:

saveAllInThread
| leftover |
listOfPages do: [ :pageInfo |
| project |
project _ (Project named: pageInfo first).
project isCurrentProject
ifTrue: [ leftover _ project ]
ifFalse: [ project storeOnServer ] ].

"save the current project last, because saving the current project will
kill the current thread"
leftover ifNotNil: [ leftover storeOnServer ].


Also, you need to add the following to the beginning of
armsLengthCommand:withDescription: :

self isCurrentProject ifFalse: [
^self perform: aCommand ].

And it's still not quite what is desired: this saves all the projects
including ones that have not changed.

Post by stéphane ducasse
Just to mention one of the things you can do with a BookMorph which I
(Control-Left Mouse Click)(book...)(search for text)

True, that's not in there that I know of. It should be easy to do,
however.

Post by stéphane ducasse
I agree with you and I'm thinking to see how we can program a
clean/simpler/bookmorph with TESTS. the active documentation. ;)

With respect, before you can write a test, you have to know what the
desired behavior is....


-Lex

[danielv at tx.technion.ac.il ()]

changed the order a bit...

Post by Avi Bryant
It sounds
like the question you're asking is "how do we replace the BFAV", and I
was trying to answer "how do we replace the update stream". I think
the answer to the latter will inform the former - except we won't
really replace it, just migrate it to a slightly different workflow.

I guess you're right, and its a good distinction. Replacing the update
stream is almost easy - make a mechanism that polls for new updates from
Doug, eats up the updates automatically one by one, commiting after each
one, and saves to a public repository, and you're almost done. Still
need to deal with non-code changes to the image, scalability (so its
practical to merge images-worth of code) and so forth. But it doesn't
seem to require big conceptual changes to me, so it might be a good
first step.

The problem of replacing the BFAV is really the problem of integrating
lots of little changes from uncoordinated sources. Seems to me like this
is the harder problem, but also the one that will give us more network
effect gains, which (IMO) is really what we're trying to leverage.

Let me give you an example - I recently thought of an enhancement for
the BFAV - that it should show first all the items you ever replied to,
except those in which you're the last who replied. This way you'd see
right away any progress with an item you're invested in. Of course this
lead to the next thing, which is that the rest of the stream could be
sorted using some predictor of "how interesting is this to me", as used
in Bayesian spam filters and such. For a small, coherent project
currently using MC, with 10 distinct contributors, this is irrelevant. For
Squeak, this could help harvest more of the network effect benefits of
many people doing things from their own POV.

Post by Avi Bryant
But if you're testing multiple patches at once, what you're really
testing is whether or not to patches can coexist. Which is a good
thing to test (and probably deserves a version of its own, with a
commit message like "successfully merged changes A and B, had to make
minor tweak C"), but you should have tested them in isolation first,
surely?

In a big enough system, given finite resources, I think the assumption
"most changes made by different people are independent" is reasonably
valid and really quite important. Most of the testing done on software
isn't intentional and dedicated to a patch, is is simply use of a system
that includes it. We do the distinctio work lazily, when bugs actually
happen. Seems to me that requiring a stack discipline in the tools simply
means that most of the actual, defacto testing will be harder to report
properly.

BTW, given a good versioning system, we have more options for tools to
help do the lazy distinction between bug-causes (found a bug, made a
test - fork off a process that runs the failing unit test repeatedly, peeling
off versions until it works again, remove the culprit, start adding stuff
back while doing regression testing, then report the functional
dependencies :-).

Post by Avi Bryant
If you were really careful, you would use a "stack discipline" in your
day to day development, too.

If I were really careful, my room would be in order, and I'd never lose
my keys, either ;-)

Post by Avi Bryant
That is, the ideal thing from
Monticello's point of view would be that, every time you started a new
set of changes, you reverted back to the earliest version that could
support them and continued from there. If the next changes you make
are unrelated to those, you revert back again and branch. Then if both
of those changes are required to do the next changes, you merge the two
resulting versions and use that as the baseline going forward. But you
shouldn't do them linearly, because that implies to the versioning
system that the second changes are dependent on the first, and you'll
have trouble if you later want to use them on their own.
Now, I don't do this much in practice, because it's a hassle, and not
the way I'm used to working. But it would be interesting to see if
this awareness of the dependence and independence of sets of changes
could be integrated into the development environment well enough that
it was a natural and pleasant way to work.

Sure, but if you pick up two random patches from the BFAV,
they're much likelier to be independent than otherwise. Assuming that
any two patches have a specific ordering dependency just because I filed
them in in that order seems unwarranted. BTW, I see how assumptions
about order are more useful when a single person is developing - then
there's usually a thread of dependencies between changes made, at least
if one commits often enough, but it I think they apply less when this person
is acting as integrator doing "random access" the great pool of floating
patches about anything and everything in Squeak.

Post by Avi Bryant

Post by danielv at tx.technion.ac.il ()
Also, I might later on have
additional comments to add that are related to that patch like "also
appears to solve the X bug", even without changing the code.

Oh, I'm not really suggesting that the commit log be the only source of
comments. We definitely want some kind of bug-tracking system that's
connected to all this that is organized by thread, not by version. But
as in the BFAV, you want to track comments and associated
changesets/versions right from the time the bug is reported to the time
it's closed, not just the history of a particular changeset.

Could be that separating the code from the problem would do the trick.
But I'm not sure. How do you think this external system would allow us
to know that this "issue" is dealt with in versions x,y,z? its pretty
easy to detect whether their ancestors include a specific patch, so the
concept seems useful. An issue can also often generate distinct
patches... so they seem like distinct connected concepts to me, rather
than mutually exclusive.

Post by Avi Bryant
Avi

[Richard A. O'Keefe]

Stef wrote:
I agree with you and I'm thinking to see how we can program a
clean/simpler/bookmorph with TESTS. the active documentation. ;)

Just to mention one of the things you can do with a BookMorph which I
do not know how to do with a labyrinth of projects:
(Control-Left Mouse Click)(book...)(search for text)

If Stef says he's thinking about something, I confidently expect awesome
results in the not too distant future.

[stéphane ducasse]

Post by Richard A. O'Keefe
If Stef says he's thinking about something, I confidently expect awesome
results in the not too distant future.

unfortunately I'm not so confident since I'm quite slow in Squeak UI
and that's why I got frustrated
recently. Then I do not have that much time. Anyway I started to do
an exercise to write some tests first and code after. So that I can
learn something. I plan to work regularly as a relaxing exercise and
publish it everyday or so so that people can join.

Stef

[Raymond Asselin]

Post by Milan Zimmermann
Hi,

...snipp

Post by Milan Zimmermann
My problem is that once navigating inside the

InternalThreadNavigationMorph ,

Post by Milan Zimmermann
I cannot find a straightforward way to go back to the "parent" "My
PresentationProject" ... I was thinking it should be on the middle

button ...

Post by Milan Zimmermann
anyway, is there a way to go back to parent?
Milan

Hi Milan,
yes there is a way, you just have to add the parent project in your
thread, and put it the first or last one as you like. If you builded a
thread of 4 projects you know how to do that...

Raymond

[Milan Zimmermann]

<<snip>>

Post by Raymond Asselin

Post by Milan Zimmermann
I cannot find a straightforward way to go back to the "parent" "My
PresentationProject" ... I was thinking it should be on the middle button
anyway, is there a way to go back to parent?
Milan

Hi Milan,
yes there is a way, you just have to add the parent project in your
thread, and put it the first or last one as you like. If you builded a
thread of 4 projects you know how to do that...

Raymond,

thanks, makes sense, I did not think of that, will try it (once I get my
crashed non-restartable :( image back)

Milan.

Post by Raymond Asselin
Raymond

[Raymond Asselin]

Post by Milan Zimmermann
There are a few complaints I would have from a UI perspective .. I'll just
list them to get it off my mind :)
1) The most confusing thing: If I click on the ITNM middle button and
do "simply close this navigator". it disappears and I do not have any
another way to get back to it, apart from dragging a NEW ITNM. Maybe I
missed something ...

To make it reappears just select in the world menu
object(o)/navigation/ThreadNavigator

this will give you a new ITNM and you'll see in the 'middle button' the name of your
Trhead... just select it.

Post by Milan Zimmermann
2) Within Squeak, the presentation pages created as described above are
visible on "jump to project" as standalone "projects" - which they are
but it would be far more natural if the InternalThreadNavigationMorph
(ITNM) becomes a "Parent Project" on the "jump to project" list (or
there could be a menu item in world for "presentations/navigations"
that would list the ITNMs) .. the way it is now is confusing because
it "flattens" all pages of all presentation I may have and clutters the
project list way too much ...

Yes your are right.

Post by Milan Zimmermann
3) I do not see and easy way to save the presentation, I think that is
what you are describing below

You can save the ITNM as a morph (this will end up with a file .morph)
but this does not save the projects only the thread.

You probably can save all project of a thread but with a script on a workspace may
be you will have to create a method in InternalNavigationMorph to access the
instanceVariable 'listOfPages'.

Bye

[Milan Zimmermann]

Raymond,

Post by Raymond Asselin

Post by Milan Zimmermann
There are a few complaints I would have from a UI perspective .. I'll just
list them to get it off my mind :)
1) The most confusing thing: If I click on the ITNM middle button and
do "simply close this navigator". it disappears and I do not have any
another way to get back to it, apart from dragging a NEW ITNM. Maybe I
missed something ...

To make it reappears just select in the world menu
object(o)/navigation/ThreadNavigator
this will give you a new ITNM and you'll see in the 'middle button' the
name of your Trhead... just select it.

I guess that's what I was trying to say above :) - it seems to be a unusual
thing to do from UI perspective - we usually go to the object bin for a new
object, so to trag out a new navigation to get access to an existing one that
is "lost" - at least I thought for a long time it was lost...

Post by Raymond Asselin

Post by Milan Zimmermann
2) Within Squeak, the presentation pages created as described above
are visible on "jump to project" as standalone "projects" - which they
are but it would be far more natural if the InternalThreadNavigationMorph
(ITNM) becomes a "Parent Project" on the "jump to project" list (or there
could be a menu item in world for "presentations/navigations" that would
list the ITNMs) .. the way it is now is confusing because it "flattens"
all pages of all presentation I may have and clutters the project list
way too much ...

Yes your are right.

Post by Milan Zimmermann
3) I do not see and easy way to save the presentation, I think that is
what you are describing below

You can save the ITNM as a morph (this will end up with a file .morph)
but this does not save the projects only the thread.
You probably can save all project of a thread but with a script on a
workspace may be you will have to create a method in
InternalNavigationMorph to access the instanceVariable 'listOfPages'.

thanks .... I will try that .. learning with too little time...

Thanks Milan

Post by Raymond Asselin
Bye