What we want with Squeak?

[diegogomezdeck at consultar.com ()]

Hi,

I think we're really near to find *the* source of all these discussion we
have periodically since SqC leaves Disney.

What we want with Squeak? Clearly there are 2 groups:

- The "Media-Squeakers" (in Andreas's words)
- The "Traditional-Squeaker" (in my words)

I'll try to explain creating radicalized descriptions of these groups:

The Media-Squeakers believes in Squeak as the most promising incarnation of
the Dynabook concept. These guys want TTF in the Image, Sound, Midi, PDF
support, SVG readers/writers, Improved Look&Feel, Video support, etc and
they are able to accept a big core image.

The Traditional-Squeakers are more interested in "normal" development with
Squeak and they are interested in SOAP, Relational DB Access, CORBA, CVS
support, cgi-type web servers, native-widgets, etc. These guys want a
really small core image with nothing more than stdio support.

If we don't agree with the goals difficulty we'll agree on methods.

We have to decide what we want with Squeak and accept that, probably, the
goals of these groups are not the same. Personally I think we have not
enough resources to try to get all the goals of both groups.

In the SqC age the Media-Group was in charge and Squeak has excellent
multimedia capabilities and absolute no support for "traditional"
development. In the Guides-Age these goals, imho, are not so clear.

Cheers,

Diego

[Gary Fisher]

Hi, Diego!

Your assessment sounds about right and implies (at least to me) a subsequent
question: is Squeak to remain the vanguard in the journey from 3 + 4 to
*real* personal computing -- "Media (and much more) Squeak" -- or is it to
be sidetracked at some intermediate point like all the other descendants of
ST-72? Simply put, is Squeak being built for tomorrow or for today?

Gary Fisher

----- Original Message -----
From: ***@consultar.com
To: squeak-***@lists.squeakfoundation.org
Sent: Tuesday, May 06, 2003 4:23 AM
Subject: What we want with Squeak?


Hi,

I think we're really near to find *the* source of all these discussion we
have periodically since SqC leaves Disney.

What we want with Squeak? Clearly there are 2 groups:

- The "Media-Squeakers" (in Andreas's words)
- The "Traditional-Squeaker" (in my words)

I'll try to explain creating radicalized descriptions of these groups:

The Media-Squeakers believes in Squeak as the most promising incarnation
of
the Dynabook concept. These guys want TTF in the Image, Sound, Midi, PDF
support, SVG readers/writers, Improved Look&Feel, Video support, etc and
they are able to accept a big core image.

The Traditional-Squeakers are more interested in "normal" development with
Squeak and they are interested in SOAP, Relational DB Access, CORBA, CVS
support, cgi-type web servers, native-widgets, etc. These guys want a
really small core image with nothing more than stdio support.

If we don't agree with the goals difficulty we'll agree on methods.

We have to decide what we want with Squeak and accept that, probably, the
goals of these groups are not the same. Personally I think we have not
enough resources to try to get all the goals of both groups.

In the SqC age the Media-Group was in charge and Squeak has excellent
multimedia capabilities and absolute no support for "traditional"
development. In the Guides-Age these goals, imho, are not so clear.

Cheers,

Diego




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030506/b96d6995/attachment.htm

[Stephen Pair]

Post by Gary Fisher
Hi, Diego!
Your assessment sounds about right and implies (at least to me) a
subsequent question: is Squeak to remain the vanguard in the journey
from 3 + 4 to *real* personal computing -- "Media (and much more)
Squeak" -- or is it to be sidetracked at some intermediate point like
all the other descendants of ST-72? Simply put, is Squeak being built
for tomorrow or for today?
Gary Fisher

I think this dichotomy of the traditional squeaker vs. the media
squeaker is not valid at all...and neither is the question you pose.
Most of the "traditional" squeakers want Squeak to be a great media
environment as well...but, I think many have come to the conclusion that
you can't shoot the moon if your engines fail half way there.

The point is, Squeak does need lot's of attention in the blue plane if
it is to make progress in the pink (or did I get those colors backwards
again). ;)

As for being "sidetracked"...I don't think that's possible...Squeak is
nothing without the people that are driving it, and only they can have
goals that can be sidetracked. There are lot's of people making
progress with Squeak in lot's of directions, and that should continue.

- Stephen

[Gary Fisher]

Hi, Stephen!

The pink plane / blue plane tension is certainly a critical force. My
concern is that the desire to move Squeak out onto the pink (let's say
"practical") plane must not pull it away from the intersection with the
orthogonally oriented blue ("bold?" :-) plane. Squeak (IMO) should not
try to compete with or try to become like other versions of Smalltalk, but
should instead continue to do what Smalltalk did twenty or thirty years ago
by 'competing with' (defining) the future and being what others want to
emulate. I keep thinking of the story of the Jobs demo at PARC, which led
to a whole industry trying with all their might to build systems which
simply *looked like* what "proto-Squeak" ST-72 could actually do.

To address your metaphor, the engines must not fail; but every successful
Moon-shot to date has required that some of the engines must fall off once
their purpose has been achieved.

All the best,

Gary


----- Original Message -----
From: Stephen Pair
To: The general-purpose Squeak developers list
Sent: Tuesday, May 06, 2003 9:13 AM
Subject: Re: What we want with Squeak?

Post by Gary Fisher
Hi, Diego!
Your assessment sounds about right and implies (at least to me) a
subsequent question: is Squeak to remain the vanguard in the journey
from 3 + 4 to *real* personal computing -- "Media (and much more)
Squeak" -- or is it to be sidetracked at some intermediate point like
all the other descendants of ST-72? Simply put, is Squeak being built
for tomorrow or for today?
Gary Fisher

I think this dichotomy of the traditional squeaker vs. the media
squeaker is not valid at all...and neither is the question you pose.
Most of the "traditional" squeakers want Squeak to be a great media
environment as well...but, I think many have come to the conclusion that
you can't shoot the moon if your engines fail half way there.

The point is, Squeak does need lot's of attention in the blue plane if
it is to make progress in the pink (or did I get those colors backwards
again). ;)

As for being "sidetracked"...I don't think that's possible...Squeak is
nothing without the people that are driving it, and only they can have
goals that can be sidetracked. There are lot's of people making
progress with Squeak in lot's of directions, and that should continue.

- Stephen

[Simon Michael]

Gary - practical pink, bold blue - thanks! at last I'll remember which is
which. :)

[Simon Michael]

Gary - practical pink, bold blue - thanks! at last I'll remember which is
which. :)

[Daniel Vainsencher]

I think this generalization is not precise. I care about the media stuff
much more than I can about any of the "traditional squeakers" topics you
mentioned (cgi..).

What concerns me, and motivated me to start pushing in certain
directions, is that Squeak's direction had ignored some "economic
principles" of software development, and as a result, really was dying.

Think back to the final days of 3.3a.

* Big untested changes can kill you
Nobody is using the alpha version, because it's hard to develop in. This
is the direct result of accepting the Module code, which changed a lot
of things, but was incomplete, and not widely understood. This code was
accepted into the image because there was no other way for a module
system to be posted for people to use. So the whole problem was an
indirect result of not having mechanisms for people to easily see
available projects. Hence the importance of SM, and of using it as a
testing ground for serious chunks of proposed code.

* Concentrated decision making about every little thing doesn't scale
You might or not remember it, but harvesting had been very slow and
erratic then too. This was because the process was such a pain, that
nobody wanted to do it. I remember enhancements and fixes I posted to
the list, that we're forgotten at some point by SqC, after they
mentioned a problem in it, and then I fixed it - they never got a single
reply from anyone. Hence a new harvesting process, with explicit place
for ANYONE to review code and state it is better or worse, and push for
it's inclusion.

* If you tolerate this (cruft) then your children will be next
Even now, the image, from a software engineering perspective, is a mess.
Object (The Base Object) indirectly depends on well over half the
classes in the system. This is why it is hard to make images for
specific purposes - because everything depends on everything else.,
because there are not module limits. Hence, we try to factor stuff out,
and use new packaging mechanisms that allow clean extensions to classes
like PackageInfo.

These are pressures we simply have to respond to in order to keep Squeak
alive and changing. This is what interests me.

What I think is being collectively expressed here by many people is not
that "media is more important than web development". I think what you're
really saying is that the need for a rich loaded Squeak image is also
critical, because that's what draws people to play with Squeak in the
first place.

Maybe we were wrong to think we can get away with a "lean" release that
removes stuff, without addressing the "rich image" concern immidiately,
by having official configurations and preloaded images.

And I completely disagree with the sentiment that we don't have enough
resources to cater to people with different tastes. This requires moving
to working with configurations, and this is a big change that is
happening slowly. It also require everybody to be active about making
their stuff viable and pushing it, correctly.

Daniel

Post by diegogomezdeck at consultar.com ()
Hi,
I think we're really near to find *the* source of all these discussion we
have periodically since SqC leaves Disney.
- The "Media-Squeakers" (in Andreas's words)
- The "Traditional-Squeaker" (in my words)
The Media-Squeakers believes in Squeak as the most promising incarnation of
the Dynabook concept. These guys want TTF in the Image, Sound, Midi, PDF
support, SVG readers/writers, Improved Look&Feel, Video support, etc and
they are able to accept a big core image.
The Traditional-Squeakers are more interested in "normal" development with
Squeak and they are interested in SOAP, Relational DB Access, CORBA, CVS
support, cgi-type web servers, native-widgets, etc. These guys want a
really small core image with nothing more than stdio support.
If we don't agree with the goals difficulty we'll agree on methods.
We have to decide what we want with Squeak and accept that, probably, the
goals of these groups are not the same. Personally I think we have not
enough resources to try to get all the goals of both groups.
In the SqC age the Media-Group was in charge and Squeak has excellent
multimedia capabilities and absolute no support for "traditional"
development. In the Guides-Age these goals, imho, are not so clear.
Cheers,
Diego

[diegogomezdeck at consultar.com ()]

Hi,

Post by Daniel Vainsencher
I think this generalization is not precise.

Every generalization is not precise. This is the reason I say "I'll try to
explain creating radicalized descriptions of these groups"

Post by Daniel Vainsencher
I care about the media
stuff much more than I can about any of the "traditional squeakers"
topics you mentioned (cgi..).

Everybody has a foot in each group but we're not talking about individuals.
We're talking about goals for Squeak.

Post by Daniel Vainsencher
What concerns me, and motivated me to start pushing in certain
directions, is that Squeak's direction had ignored some "economic
principles" of software development, and as a result, really was dying.
Think back to the final days of 3.3a.

[snip]

I remember exactly the problems we had. But your comments remember me the
human ideas about dinosaurs extinction: ?The dinosaurs get extincted...?
but they was on the earth much more time than humans.

The SqC age had a lot of problems but they produce things we still are not
able to produce.

Post by Daniel Vainsencher
These are pressures we simply have to respond to in order to keep
Squeak alive and changing. This is what interests me.
What I think is being collectively expressed here by many people is not
that "media is more important than web development".

This is not a juice to ?web development? at all.

The point is: Can we produce fully multimedia content and web applications
with the same tool?

As an example: I used to program web applications for living, but I can use
gnu/st, visualworks, dolphin, smalltalk/x, etc for it.

Post by Daniel Vainsencher
I think what
you're really saying is that the need for a rich loaded Squeak image is
also critical, because that's what draws people to play with Squeak in
the first place.

I'm trying to express my feelings: Squeak is better defined as a media-
producer than as a power-php.

Post by Daniel Vainsencher
Maybe we were wrong to think we can get away with a "lean" release that
removes stuff, without addressing the "rich image" concern immidiately,
by having official configurations and preloaded images.

IMHO this is not the problem but the slow progress is.

Post by Daniel Vainsencher
And I completely disagree with the sentiment that we don't have enough
resources to cater to people with different tastes.

If you are right and we have enough resources the problem is worst because
we're not producing so much.

Post by Daniel Vainsencher
This requires
moving to working with configurations, and this is a big change that is
happening slowly.

Q: Everybody agree on the politic of small-image with configurations?

IMHO, We still don't have enough support on squeak to create
packages/modules/application/parcels/theNameYouWant and we're creating much
more problem with the intent of fragmentation of the image without the
proper support.

On the other side I think there are not yet a clear solution for the
problem. The parcels, applications, etc have a deep impact on the way of
producing with an object-environment moving the process to a more
declarative one (just in the opposite direction I'd like).

Post by Daniel Vainsencher
It also require everybody to be active about making
their stuff viable and pushing it, correctly.

I'm trying hard, beleive me! :)

Post by Daniel Vainsencher
Daniel

Cheers,

Diego

[Jimmie Houchin]

Howdy Diego,

***@consultar.com wrote:
[snip]

Post by diegogomezdeck at consultar.com ()

Post by Daniel Vainsencher
What I think is being collectively expressed here by many people is not
that "media is more important than web development".

Yes, yes.

Post by diegogomezdeck at consultar.com ()
This is not a juice to ?web development? at all.
The point is: Can we produce fully multimedia content and web applications
with the same tool?

Absolutely.

Post by diegogomezdeck at consultar.com ()
As an example: I used to program web applications for living, but I can use
gnu/st, visualworks, dolphin, smalltalk/x, etc for it.

This is true. But none of those is as cross platform as Squeak. Not a
knock on any of those other communities, but I like the Squeak
community. I think it is an asset.

Like many here, time is a valuable resource for me. Squeak being able to
do all that I want it to do (when I am able) is of extraordinary
importance to me. I don't really want to have to learn and become
proficient in a multiplicity of tools, IDEs, languages, etc..., in order
to accomplish those things I want to do. Squeak is able. I personally
place a large value on its diversity of capabilities.

Post by diegogomezdeck at consultar.com ()

Post by Daniel Vainsencher
I think what
you're really saying is that the need for a rich loaded Squeak image is
also critical, because that's what draws people to play with Squeak in
the first place.

I'm trying to express my feelings: Squeak is better defined as a media-
producer than as a power-php.

I don't see that it needs to be an either/or proposition.

The people who want to push Squeak as the best Media Environment
available aren't going to spend time making it the best web-tool.

The people pushing Squeak to be the best web-tool aren't going to put
that same time into Squeak the Media Environment. (But that doesn't mean
they won't use or enjoy it.)

Stephen, Avi, Julian, etc. because of what their day jobs are, are going
to put a certain amount of time into creating what they percieve to be
the best web-tool available for them. We are blessed that the see Squeak
as that tool. (Avi and Julian could be hacking Ruby.) It in no means
conflicts with Squeak Media.
[snip]

Post by diegogomezdeck at consultar.com ()
I'm trying hard, beleive me! :)

I do. Be of good cheer, mi amigo!

Jimmie Houchin

[Jay Carlson]

Post by Daniel Vainsencher
* If you tolerate this (cruft) then your children will be next
Even now, the image, from a software engineering perspective, is a mess.
Object (The Base Object) indirectly depends on well over half the
classes in the system. This is why it is hard to make images for
specific purposes - because everything depends on everything else.,
because there are not module limits.

In a system that encourages code browsing as a documentation and exploration
strategy, this is particularly painful.

Object and Morph are important classes. I wish it was easier for me to read
them and understand them.

Jay

[Stephane Ducasse]

Hi daniel

I agree with you. Now we have the opportunity to change and we are
learning
how to do it.

Stef

Post by Daniel Vainsencher
I think this generalization is not precise. I care about the media
stuff
much more than I can about any of the "traditional squeakers" topics
you
mentioned (cgi..).
What concerns me, and motivated me to start pushing in certain
directions, is that Squeak's direction had ignored some "economic
principles" of software development, and as a result, really was dying.
Think back to the final days of 3.3a.
* Big untested changes can kill you
Nobody is using the alpha version, because it's hard to develop in.
This
is the direct result of accepting the Module code, which changed a lot
of things, but was incomplete, and not widely understood. This code was
accepted into the image because there was no other way for a module
system to be posted for people to use. So the whole problem was an
indirect result of not having mechanisms for people to easily see
available projects. Hence the importance of SM, and of using it as a
testing ground for serious chunks of proposed code.
* Concentrated decision making about every little thing doesn't scale
You might or not remember it, but harvesting had been very slow and
erratic then too. This was because the process was such a pain, that
nobody wanted to do it. I remember enhancements and fixes I posted to
the list, that we're forgotten at some point by SqC, after they
mentioned a problem in it, and then I fixed it - they never got a
single
reply from anyone. Hence a new harvesting process, with explicit place
for ANYONE to review code and state it is better or worse, and push for
it's inclusion.
* If you tolerate this (cruft) then your children will be next
Even now, the image, from a software engineering perspective, is a
mess.
Object (The Base Object) indirectly depends on well over half the
classes in the system. This is why it is hard to make images for
specific purposes - because everything depends on everything else.,
because there are not module limits. Hence, we try to factor stuff out,
and use new packaging mechanisms that allow clean extensions to classes
like PackageInfo.
These are pressures we simply have to respond to in order to keep
Squeak
alive and changing. This is what interests me.
What I think is being collectively expressed here by many people is not
that "media is more important than web development". I think what
you're
really saying is that the need for a rich loaded Squeak image is also
critical, because that's what draws people to play with Squeak in the
first place.
Maybe we were wrong to think we can get away with a "lean" release that
removes stuff, without addressing the "rich image" concern immidiately,
by having official configurations and preloaded images.
And I completely disagree with the sentiment that we don't have enough
resources to cater to people with different tastes. This requires
moving
to working with configurations, and this is a big change that is
happening slowly. It also require everybody to be active about making
their stuff viable and pushing it, correctly.
Daniel

Post by diegogomezdeck at consultar.com ()
Hi,
I think we're really near to find *the* source of all these
discussion we
have periodically since SqC leaves Disney.
- The "Media-Squeakers" (in Andreas's words)
- The "Traditional-Squeaker" (in my words)
The Media-Squeakers believes in Squeak as the most promising
incarnation of
the Dynabook concept. These guys want TTF in the Image, Sound, Midi,
PDF
support, SVG readers/writers, Improved Look&Feel, Video support, etc
and
they are able to accept a big core image.
The Traditional-Squeakers are more interested in "normal" development
with
Squeak and they are interested in SOAP, Relational DB Access, CORBA,
CVS
support, cgi-type web servers, native-widgets, etc. These guys want a
really small core image with nothing more than stdio support.
If we don't agree with the goals difficulty we'll agree on methods.
We have to decide what we want with Squeak and accept that, probably,
the
goals of these groups are not the same. Personally I think we have
not
enough resources to try to get all the goals of both groups.
In the SqC age the Media-Group was in charge and Squeak has excellent
multimedia capabilities and absolute no support for "traditional"
development. In the Guides-Age these goals, imho, are not so clear.
Cheers,
Diego

[Bob Arning]

Post by diegogomezdeck at consultar.com ()
Q: Everybody agree on the politic of small-image with configurations?

The short answer is no, not everybody shares the enthusiasm for that goal.

Cheers,
Bob

[Cees de Groot]

Post by Bob Arning
The short answer is no, not everybody shares the enthusiasm for that goal.

Ok, then I'm going to request the long answer ;-).

Enthusiasm is not necessary, but it *is* the only feasible way to make
sure Squeak works for everybody, not?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030507/3ee26c38/attachment.pgp

[Chris Reuter]

Post by diegogomezdeck at consultar.com ()
Hi,
I think we're really near to find *the* source of all these discussion we
have periodically since SqC leaves Disney.
- The "Media-Squeakers" (in Andreas's words)
- The "Traditional-Squeaker" (in my words)

[...]

Post by diegogomezdeck at consultar.com ()
In the SqC age the Media-Group was in charge and Squeak has excellent
multimedia capabilities and absolute no support for "traditional"
development. In the Guides-Age these goals, imho, are not so clear.

Forgive me if I've misunderstood your post, but it looks to me like
you're saying that we should be focussed on doing one or the other. I
think that's absolutely the worst thing we could do.

These goals don't cancel each other out. Making Squeak a better
multimedia platform, for example, doesn't make it a worse development
platform or vice versa.

In fact, I'd say the converse is true. Most of the features added by
one group are also useful to the other and as a whole, we increase the
usefulness of the system. The more useful it is, the more people will
use it. The more users there are, the more contributors there are and
the better it gets at achieving everyone's goals.

Right now, Squeak is used for web applications, teaching, PDAs,
embedded systems, scientific computation and PC application
development. It runs in a web browser, on bare metal or on a
workstation and can use the existing operating system or get by with
none at all.

Which is, I think, a pretty good start. Now all we need is a killer
app or three.


--Chris

[Daniel Vainsencher]

Post by diegogomezdeck at consultar.com ()

Post by Daniel Vainsencher
It also require everybody to be active about making
their stuff viable and pushing it, correctly.

I'm trying hard, beleive me! :)

I know, and I am glad for it, now just get used to it - that's what it
takes. Nobody else will magically "take your idea the rest of the way to
realization". That's the point of my other reply to Andreas on this
thread, which seems much less popular to reply to, I wonder why...

Post by diegogomezdeck at consultar.com ()

Post by Daniel Vainsencher
I care about the media
stuff much more than I can about any of the "traditional squeakers"
topics you mentioned (cgi..).

Everybody has a foot in each group but we're not talking about individuals.
We're talking about goals for Squeak.

Hmm, that wasn't my point, maybe I was too indirect. As I see it, Squeak
is not about MM, or any other specific direction. It is a platform, a
place where people start to work to get towards whatever they want.
Simplicity and understandability is critical for Squeak to be a good
platform.

The Guides work towards making and keeping the platform viable, so
everyone else can pursue whatever goals they want. For us as a community
to choose specifically media, or web stuff, or genetic algorithms, would
miss the point.

Which needs to not clash with the need for a sexy, rich version that
makes people want to start playing with it.

Post by diegogomezdeck at consultar.com ()
I remember exactly the problems we had. But your comments remember me the
human ideas about dinosaurs extinction: –The dinosaurs get extincted...”
but they was on the earth much more time than humans.
The SqC age had a lot of problems but they produce things we still are not
able to produce.

Of course (see my first reply to Andreas). Again, I was trying to
explain what I believe it takes to keep the platform viable.

Post by diegogomezdeck at consultar.com ()
The point is: Can we produce fully multimedia content and web applications
with the same tool?

Squeak is not a mere tool. It is not a collection of tools, either. It's
a platform. Tools based on Squeak should definitely allow you to do all
those things. That's what SM is for.

Post by diegogomezdeck at consultar.com ()

Post by Daniel Vainsencher
I think what
you're really saying is that the need for a rich loaded Squeak image is
also critical, because that's what draws people to play with Squeak in
the first place.

I'm trying to express my feelings: Squeak is better defined as a media-
producer than as a power-php.

And I'm trying to figure out from those feelings what about reality is
bugging you. Since I don't believe Squeak is merely a better Flash
authoring package, I theorize that what bugs you is the need for
preloaded images. Maybe I'm wrong.

Post by diegogomezdeck at consultar.com ()

Post by Daniel Vainsencher
Maybe we were wrong to think we can get away with a "lean" release that
removes stuff, without addressing the "rich image" concern immidiately,
by having official configurations and preloaded images.

IMHO this is not the problem but the slow progress is.

Ah, in that case, that's simple. Go to the bug fixes archive, look for
some unreviewed code that you think should be in the image, test it,
review it, and bring something read for inclusion to a Harvester. And
yes, be a little patient.

Post by diegogomezdeck at consultar.com ()

Post by Daniel Vainsencher
This requires
moving to working with configurations, and this is a big change that is
happening slowly.

Q: Everybody agree on the politic of small-image with configurations?
IMHO, We still don't have enough support on squeak to create
packages/modules/application/parcels/theNameYouWant

What does opinion have to do with it? I think we have enough to remove a
specific package. If you think otherwise, state what is missing.

Post by diegogomezdeck at consultar.com ()
and we're creating much
more problem with the intent of fragmentation of the image without the
proper support. On the other side I think there are not yet a clear solution for the
problem.

What we are still missing is support for configurations of package, that
let Diego, for example, publish a list of packages, and then anyone can
choose from a menu Diegos configuration, and get an image with all those
loaded. Hey... that sounds like a not very complicated web application.
Instead of the downloading static images and loading them with packages,
a web interface that shows the list of load scripts, and returns you the
image of your dreams, configured.


Daniel

[Daniel Vainsencher]

Hi Bob.

And the long answer?

Daniel

Post by Bob Arning

Post by diegogomezdeck at consultar.com ()
Q: Everybody agree on the politic of small-image with configurations?

The short answer is no, not everybody shares the enthusiasm for that goal.
Cheers,
Bob

[Arie van Wingerden]

Hi to all,

since I am a newbie to Squeak and Smalltalk in general I dare not say too
much. Still, I've got programming experience for about 24 years and I am so
impressed with Squeak so far, that I really won't see it die.
One of the best "features" of Smalltalk and even more Squeak, is the general
availability of source code.

When "decreasing the image size" really means creating several "unclothed"
versions + sets of "clothes" to make them wear, I think it's a bad idea.

IMHO I think that Squeak should remain a stable platform which is generally
useable to build upon for anyone.
BTW, why bother about image size? As far as I get it so far one can unload
lots of stuff if needed for some reason?

Keep up the good work and please don't let Squeak die ...
Kind regards,
Arie van Wingerden

[Ned Konz]

Post by Arie van Wingerden
One of the best "features" of Smalltalk and even more
Squeak, is the general availability of source code.

No one wants to get rid of the source code.

Post by Arie van Wingerden
When "decreasing the image size" really means creating several
"unclothed" versions + sets of "clothes" to make them wear, I think
it's a bad idea.
IMHO I think that Squeak should remain a stable platform which is
generally useable to build upon for anyone.
BTW, why bother about image size? As far as I get it so far one can
unload lots of stuff if needed for some reason?

That's the problem. Squeak doesn't unload things very well.

Because we want to encourage people to use Squeak in many different
kinds of systems -- all the way from little embedded systems to full
blown media environments -- we decided to follow the strategy of
distributing a minimal stable system with a couple of sets of
packages loaded on top of it. This way you can choose the "off the
shelf" image that best suits your needs. Other packages can be loaded
as needed.

Right now, there's a single official image that you download. It has
lots of packages loaded in it. If you don't need those packages you
are faced with a lengthy process of tracking down and removing the
extra stuff.

We're working toward having three official images available for
download. The safest way we can think of to do this is to do it in an
additive way: make sure we can make the smallest one work, and then
define two different sets of packages to load into this small image
to make the bigger ones.

This gives us three images to test, of course, but lets us have
off-the-shelf solutions that are better matched to various needs.

[Paul Chapman]

Ned,

Post by Ned Konz
We're working toward having three official images available for
download. The safest way we can think of to do this is to do it in an
additive way: make sure we can make the smallest one work, and then
define two different sets of packages to load into this small image
to make the bigger ones.

This sounds like an excellent approach.

The app I'm working on in Squeak will be used by a small number of people, who fall roughly into three categories: (1) those who will enjoy exploring the full functionality of Squeak alongside my app; (2) those who won't care too much about the Squeak environment and its potential, although minimal, dangers; and (3) those who will be concerned about loading a large image which includes access to the net, access to files on their local platform, and compiling and running arbitrary pieces of code.

The current all-inclusive standard Squeak image may well raise concerns among people in this third group. When I release an alpha version, I'll basically say to people, "If you want to run this, download and install Squeak for your machine, then follow these instructions to file in my app." I'd *like* to be able to say, "If you like, download this *secure* version of Squeak, which limits net access and/or local file access," etc.

I don't expect such a thing to arrive overnight. But in the long run, if the Squeak community wants to be able to give the thing wings by distributing apps built for vertical markets, I think security will have to be considered (and will have to be built into the VM).

Cheers, Paul

[Anthony Adachi]

Post by Daniel Vainsencher
What concerns me, and motivated me to start pushing

in certain

Post by Daniel Vainsencher
directions, is that Squeak's direction had ignored

some "economic

Post by Daniel Vainsencher
principles" of software development, and as a

result, really was dying.

It sounds like to me that it would help Squeak
considerably if it was developed the Extreme
Programming way (especially the core system). i.e.-
Face to Face communication, Pair programming, Test
First Development, on site customer (person(s) acting
in the capacity of) , ect..

http://www.extremeprogramming.org/rules.html
http://www.extremeprogramming.org/map/project.html
http://xprogramming.com/Practices/xpractices.htm
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap

Post by Daniel Vainsencher
PS: if we could get money for two persons full time

improving Squeak

Post by Daniel Vainsencher
this would solve a lot of problems.

Yes, at least two full time programmers. Or two
part-time programmers who can arrange to work at the
same time in the same place. So they can, at a
minimum, practice pair programming.

http://www.extremeprogramming.org/rules/pair.html
http://xprogramming.com/Practices/PracPairs.html
http://c2.com/cgi/wiki?PairProgramming

Post by Daniel Vainsencher
I'm really wondering how we could make this happens.

Squeak has had a significant involvement in Education,
has it not? Isn't there grants (government, corporate,
or private) which can be applied/lobbied for Squeak?

The Refactoring Browser was developed at a University
under the guidance of a professor was it not? Could
something similar be done with Squeak?

Failing that, Squeak developers who are geographically
located near each other could pair on a voluntary
basis.

In the event, were it's not possible to be in the same
room during the development process, ways to
effectively communicate still need to be found.

http://c2.com/cgi/wiki?InterTeamCommunication

Post by Daniel Vainsencher
If you tolerate this (cruft) then your children

will be next

Post by Daniel Vainsencher
Even now, the image, from a software engineering

perspective, is a mess.

Post by Daniel Vainsencher
Object (The Base Object) indirectly depends on well

over half the

Post by Daniel Vainsencher
classes in the system.

Dedication to Test Driven Development would help
considerably to resolve and avoid this situation.

http://c2.com/cgi/wiki?TestDrivenDevelopment

Moreover, XP puts a very strong emphasis on
communication, especially face to face communication.
A core group of people who are able to meet, plan, and
program in the same room using XP would go a long way
to resolving this cruft.

http://c2.com/cgi/wiki?WholeTeam

Post by Daniel Vainsencher
we have pages and pages describing a process (the

harvesting process) that

Post by Daniel Vainsencher
don't work. The bureaucracy is killing us. The

steps to get a fix

Post by Daniel Vainsencher
approved are, in most of the cases, more difficult

and time consumer than

Post by Daniel Vainsencher
the fix itself. We have lists of people with roles

(guides, harvesters,

Post by Daniel Vainsencher
etc) but in the reality only a few of them are

active and working.

Post by Daniel Vainsencher
These are pressures we simply have to respond to in

order to keep Squeak

Post by Daniel Vainsencher
alive and changing. This is what interests me.

Someone or some persons playing the role of the on
site "customer" could make it easier to resolve the
decision turn around time issues.

http://www.extremeprogramming.org/rules/customer.html

XP's practices were created in order to enable agility
and change. i.e.- "Embrace Change".

http://c2.com/cgi/wiki?AreYouDoingXp
http://c2.com/cgi/wiki?ExtremeValues

Just a thought,

Anthony


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

[Lorenzo Schiavina]

Hi Diego,

in my opinion you are posing a strategical question, while the problem is
tactical.

The right Squeak goal is to be both "Media" AND "Traditional", because this
will be the final need for any application we will write in the future.

We can reach this result if will have many people that use Squeak.

Certainly, if we have no user, Sqeak will die.

How will we have more users ?

The question is the same as "why Java succeeded and not Smalltalk ?"

You cannot aspect that everybody will understand Squeak, which is years
beyond the normal development tools and we cannot succeed with only a
technical approach; we should start a marketing approach.

Please, note that a marketing approach is not a synonym of commercial
approach (that is money oriented): is only an approach oriented to
demonstrate which is the best tool, defining what a modern tool is, not only
from a technical point of view, but from usability and many other aspect
that we do not point out.
I believe (for example) that the possibility to have an uniform environment
for all kind of work is an enormous advantage.

But you must educate people to understand which are the modern values for
tools evaluation: you can address data models no more, while world models
are the main concern.

In my opinion this is Smalltalk weakness: it has been proposed as the right
tools for developing application, but which kind of application was not
clear.

But what must you consider in order to evaluate an environment ? If you
consider only the capability to manipulate data (with the model we are used
from a procedural point of view) you will never be able to convince people
to use Squeak; on the contrary, if you are able to point out all the modern
problems in data processing (flexibility, different environments etc),
everybody will understand that an investment in knowledge is need: in such a
case, Squeak is certainly the best solution.

But for that, you must convince people that a new point of view is needed
and everybody is worried in changing old habits.

So, if we think that Squeak is for an elite, the current approach is ok; if
we want survive, we must divide our conviction with everybody, after
educating them (my definition of marketing).

This was the Smalltalk problem and in my opinion is Squeak's.

Ciao

Lorenzo


----- Original Message -----
From: <***@consultar.com>
To: <squeak-***@lists.squeakfoundation.org>
Sent: Tuesday, May 06, 2003 10:23 AM
Subject: What we want with Squeak?

Post by diegogomezdeck at consultar.com ()
Hi,
I think we're really near to find *the* source of all these discussion we
have periodically since SqC leaves Disney.
- The "Media-Squeakers" (in Andreas's words)
- The "Traditional-Squeaker" (in my words)
The Media-Squeakers believes in Squeak as the most promising incarnation of
the Dynabook concept. These guys want TTF in the Image, Sound, Midi, PDF
support, SVG readers/writers, Improved Look&Feel, Video support, etc and
they are able to accept a big core image.
The Traditional-Squeakers are more interested in "normal" development with
Squeak and they are interested in SOAP, Relational DB Access, CORBA, CVS
support, cgi-type web servers, native-widgets, etc. These guys want a
really small core image with nothing more than stdio support.
If we don't agree with the goals difficulty we'll agree on methods.
We have to decide what we want with Squeak and accept that, probably, the
goals of these groups are not the same. Personally I think we have not
enough resources to try to get all the goals of both groups.
In the SqC age the Media-Group was in charge and Squeak has excellent
multimedia capabilities and absolute no support for "traditional"
development. In the Guides-Age these goals, imho, are not so clear.
Cheers,
Diego

[Larry White]

An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030506/a9ed86aa/attachment.htm

[Alejandro F. Reimondo]

Diego makes an interesting point about there being multiple
groups within the overall Squeak community, each pulling
the language in a different direction.

Please remember that there is (also) a "little group" that
consider that Smalltalk is not a language ;-)
( we know that it is an environment,
an open ambient constrained to evolution
and not only to changes as languages).
Probably each of us can't enumerate all the groups
co-laborating in our community.

Also, we must consider that time is different
for an individual that for the goup.
(the duration of a second depends on the
side of the [bathroom]door you are :-)

Relax and do Squeak for fun.
Squeak is an Smalltalk and it will not dissapear
without changing our minds.
Languages are replaced by new languages,
ambients evolve.

Ale.


----- Original Message -----
From: "Larry White" <***@hotmail.com>
To: <squeak-***@lists.squeakfoundation.org>
Sent: Tuesday, May 06, 2003 4:00 PM
Subject: Re: What we want with Squeak?

Diego makes an interesting point about there being multiple groups within

the overall Squeak community, each pulling the language in a different
direction.

A possible solution to this is to organize 'families of functionality' as

separate projects in the same way that the Apache Jakarta work supports
developers building Web-centric Java applications by providing a central
source for (among other things): the tomcat web server, the struts web
application framework, a mail server, xml processing, test utilities, etc.
These things have become semi-official parts of the java development world
without being part of Sun's official Java (except for the XML stuff, which
is repackaged). The project provides not just a set of tools but also
confidence - that the projects are active, the tools have a certain quality
and that, to some degree at least, they work together. This 'branding'
effect is very important.

The benefits of this are several: First, the basic image can remain small

without preventing access to useful tools. Second, the time-consuming
process of blessing image changes can be avoided. Third, those 'families'
that meet real user needs will thrive while others can fill smaller niches,
or fade away entirely - without having to remove them from the image later.
Finally, if the tools prove valuable to mainstream developers, they can
always be rolled into to the image later.

There's enough existing software to form the basis of a 'traditional'

development family - Comanche, Seaside, some of the database tools,
SOAPOpera, XML-RPC, etc. Whether or not their developers would want to work
this way is the real question.

---------------------------------------------------------------------
Hi,
I think we're really near to find *the* source of all these discussion we
have periodically since SqC leaves Disney.
- The "Media-Squeakers" (in Andreas's words)
- The "Traditional-Squeaker" (in my words)
The Media-Squeakers believes in Squeak as the most promising incarnation

of

the Dynabook concept. These guys want TTF in the Image, Sound, Midi, PDF
support, SVG readers/writers, Improved Look&Feel, Video support, etc and
they are able to accept a big core image.
The Traditional-Squeakers are more interested in "normal" development with
Squeak and they are interested in SOAP, Relational DB Access, CORBA, CVS
support, cgi-type web servers, native-widgets, etc. These guys want a
really small core image with nothing more than stdio support.
If we don't agree with the goals difficulty we'll agree on methods.
We have to decide what we want with Squeak and accept that, probably, the
goals of these groups are not the same. Personally I think we have not
enough resources to try to get all the goals of both groups.
In the SqC age the Media-Group was in charge and Squeak has excellent
multimedia capabilities and absolute no support for "traditional"
development. In the Guides-Age these goals, imho, are not so clear.
Cheers,
Diego
--------------------------------------------------------------------------

------

Add photos to your messages with MSN 8. Get 2 months FREE*.

----------------------------------------------------------------------------
----

[Hans Nikolaus Beck]

Hi,

Post by Daniel Vainsencher

Post by diegogomezdeck at consultar.com ()

Post by Daniel Vainsencher
I care about the media
stuff much more than I can about any of the "traditional squeakers"
topics you mentioned (cgi..).

Everybody has a foot in each group but we're not talking about
individuals.
We're talking about goals for Squeak.

Hmm, that wasn't my point, maybe I was too indirect. As I see it,
Squeak
is not about MM, or any other specific direction. It is a platform, a
place where people start to work to get towards whatever they want.
Simplicity and understandability is critical for Squeak to be a good
platform.
The Guides work towards making and keeping the platform viable, so
everyone else can pursue whatever goals they want. For us as a
community
to choose specifically media, or web stuff, or genetic algorithms,
would
miss the point.

I see it in a little bit similar way. For me, Squeak is a collection of
ideas. Ideas which take one away
from the all-day dictate whow computers should work or whow should
programming be performed.
It presents these ideas in a easy to understand way, by beeing a full
open system and using a easy to learn
language. Squeak is a notation of ideas. It is not a product, say for
multimedia or for doing anything specific.
It invites to play.

Because of this, for me it is not important if some classes are in
image or could be loaded be squeak map or must
be downloaded from an ftp server. I make it to my product by creating
an image as I need.

From this point, the grouping of squeakes given at beginning of the
thread seems to me more
- the one who want to have a product
- the one who use squeak as gate leading to the next ideas (of
computing)

So, if we want to have a Squeak for using in school and education, we
take the people interested in and make
our own "product", (the best example ist the german Squeak Deutschland
foundation)
and therefore we depend not on any release management from outer
space. But nevertheless, ideas are welcomed
form everywhere :-)

So from my *private* point of view, having a set of groups organized
locally (and of course communicate to each other !),
interesting in a special aspect of squeak would
be better for me than looking for a general oll-over instance who say
what to do.

Have we to fear a lot of similiar but not so similar Squeaks in the
world ? I think - with some limitations - no.

As I said, my private view from a squeak fan and beginner.


Greetings

Hans

[Jimmie Houchin]

Hello Diego,

I wish to add my voice to the many who have expressed similar sentiments.

Post by diegogomezdeck at consultar.com ()
Hi,
I think we're really near to find *the* source of all these discussion we
have periodically since SqC leaves Disney.
- The "Media-Squeakers" (in Andreas's words)
- The "Traditional-Squeaker" (in my words)

To quote a popular series of commercials with Deion Sanders of the
Dallas Cowboys, "both Boss". My apologies to those outside of the US who
probably won't understand.

Post by diegogomezdeck at consultar.com ()
The Media-Squeakers believes in Squeak as the most promising incarnation of
the Dynabook concept. These guys want TTF in the Image, Sound, Midi, PDF
support, SVG readers/writers, Improved Look&Feel, Video support, etc and
they are able to accept a big core image.
The Traditional-Squeakers are more interested in "normal" development with
Squeak and they are interested in SOAP, Relational DB Access, CORBA, CVS
support, cgi-type web servers, native-widgets, etc. These guys want a
really small core image with nothing more than stdio support.

As someone who really, really looks forward to the day that "his" (mine)
abilities and Squeak's converge at a point he can use Squeak as his
primary Operating Environment, I firmly want Both.

For my personal OE the Media Image. For my web app the small image.
I have apps I want to develop for both groups.

Post by diegogomezdeck at consultar.com ()
If we don't agree with the goals difficulty we'll agree on methods.
We have to decide what we want with Squeak and accept that, probably, the
goals of these groups are not the same. Personally I think we have not
enough resources to try to get all the goals of both groups.

The goals may be different, but not necessarily in conflict. The
capability of the small kernel/image... does not imply an inability to
deploy the Media Image on such a kernel/vm.

As to resources they seem reasonably available. Each group has their
advocates and developers. As in all open source, you scratch the itch
you have.

Many people will potentially be a user of one of your groups and a
user/developer in the other.

Those in the traditional group as developers are not necessarily
unwilling to be consumer users of the Media Squeak.

Post by diegogomezdeck at consultar.com ()
In the SqC age the Media-Group was in charge and Squeak has excellent
multimedia capabilities and absolute no support for "traditional"
development. In the Guides-Age these goals, imho, are not so clear.

We do have some challenges, we have our frustrating moments. But I think
this community is up to the challenge.

Cheer up Diego, the sun is a shining. :)

Jimmie Houchin

[Bob Arning]

Post by Cees de Groot

The short answer is no, not everybody shares the enthusiasm for that goal..

Ok, then I'm going to request the long answer ;-).
Enthusiasm is not necessary, but it *is* the only feasible way to make
sure Squeak works for everybody, not?

Well, first, does the "it" in "it *is* the only feasible way" refer to enthusiasm or to the (not quoted above) "politic of small-image with configurations"?

In any event, I'm not sure Squeak can work for everybody, depending on your interpretation of "work". Any particular change will probably make some people more happy and others less so. What sort of calculus one applies to sum up these pluses and minuses is, I think, entirely subjective. I'm one of those who sums it up for the present trends and arrives at a negative number. Maybe I'm alone in that regard, maybe not, but that's what prompted me to reply to Diego's inquiry.

Cheers,
Bob

[Jim Benson]

Post by Bob Arning
- it does not solve any problem that I face now or forsee facing in the

near future

My sentiments exactly.

Jim Benson

[Stephen Pair]

Post by Bob Arning

Post by Bob Arning
- it does not solve any problem that I face now or forsee facing in the

near future
My sentiments exactly.
Jim Benson

I sort of look at SqueakMap as a kind of Google for Squeak stuff. It
makes it very easy to find and install Squeak goodies that people create
that are not included in the base image. For me, that's the most
important thing that SqueakMap does. The packaging effort is nothing
more than a refactoring effort.

- Stephen

[Jim Benson]

Stephen,

I agree with the SqueakMap stuff. However, another part of the 'packaging'
effort is refactoring the image and making large chunks of the image
'unloadable'. For me, that's problematic (ok, I think it sucks) ; what
happens is that you end up with a whole lot of different configurations of
Squeak. I'll give you a example:

- I write a package, let's call it Zurgle.
- By request, I place it in a SAR package on SqueakMap.
- Let's say that going from 3.2 to 3.4 a bug is introduced,. For the sake of
argument, let's say it introduces a problem in 32-bit color management. This
manifests itself as making IconicButtons invisible, and confuses FlapMorphs
in their layout when different fonts are assignd. Both problems in the stock
image.
- By coincidence, let's say that Zurgle happens to try to load itself in
32-bit color. People who download the SAR complain, and the 'reliability' of
the Zurgle package is questioned. User downloads Zurgle, it don't work.
- As another coincidence, let's say we have an image upgrade going from 3.4
to 3.5. (Zurgle package is still marked as 3.4 on SqueakMap, so it doesn't
show up under packages).
- User does magic incantation, figures out the 'show all versions' deally
and tries to load the Zurgle SAR.
- Squeak starts barking, "server not responding" error, though you can use
the download menu item to download the SAR.
-- This is a SqueakMap bug
- There's another problem; compatibility with the StarBrowser package.
StarBrowser needs a little magic incantation to work in harmony with the
zurg.

As with any new image release, there are some problems. At the end of the
day, Zurgle comes out looking unusable, with which I have to agree.
Regardless of who, what, when, where or why it doesn't work. The feedback I
get, "Zurgle isn't a very reliable package". OK.

So, just like in the old days, I would hunt up the bugs and submit fixes (or
more likely whine loudly and the amazing Ned would magically fix them :-)
Submit them to the list with the appropriate tag. But here's the rub. Once
people start splitting the core image up, you can bet that whole silly
dependencies graph thing rears it's ugly head. To run this package you need
version 1.2 of this and 3.2 of that and 2.7 of the other thing. I'm not
close to smart enough to figure all that out. I couldn't even get my simple
package to work going from 3.2 to 3.5 when virtually no changes were
introduced within the monolithic image.

At the end of the day, what did all of the packaging stuff buy me? I'm sure
that there are benefits, I just can't think of any.

Jim

Post by Stephen Pair

Post by Bob Arning

Post by Bob Arning
- it does not solve any problem that I face now or forsee facing in the

near future
My sentiments exactly.
Jim Benson

I sort of look at SqueakMap as a kind of Google for Squeak stuff. It
makes it very easy to find and install Squeak goodies that people create
that are not included in the base image. For me, that's the most
important thing that SqueakMap does. The packaging effort is nothing
more than a refactoring effort.
- Stephen

[Stephen Pair]

I'm having a hard time figuring out how any of these problems magically
disappear in the absence of system that is well factored into packages.
The ugly dependency graphs are all still there...you just can't see them
and it's difficult to cope with them.

For example, if I download base Squeak 3.5, and try to load Zurgle
directly from your website...I'll bet I run into the same issues you
described (if you haven't dealt with them already). Right now, the only
way for you to deal with that issue is to build your own pre-packaged
image with Zurgle included...and nothing stops you from doing so in the
presence of a well-factored Squeak.

However, if I want to use Zurgle with a different version of Squeak,
then I've potentially got some work to do. I can't see how having the
system properly factored into packages with dependencies clearly
understood would do anything but help that situation.

- Stephen

Post by Jimmie Houchin
Stephen,
I agree with the SqueakMap stuff. However, another part of the 'packaging'
effort is refactoring the image and making large chunks of the image
'unloadable'. For me, that's problematic (ok, I think it sucks) ; what
happens is that you end up with a whole lot of different configurations of
- I write a package, let's call it Zurgle.
- By request, I place it in a SAR package on SqueakMap.
- Let's say that going from 3.2 to 3.4 a bug is introduced,. For the sake of
argument, let's say it introduces a problem in 32-bit color management. This
manifests itself as making IconicButtons invisible, and confuses FlapMorphs
in their layout when different fonts are assignd. Both problems in the stock
image.
- By coincidence, let's say that Zurgle happens to try to load itself in
32-bit color. People who download the SAR complain, and the 'reliability' of
the Zurgle package is questioned. User downloads Zurgle, it don't work.
- As another coincidence, let's say we have an image upgrade going from 3.4
to 3.5. (Zurgle package is still marked as 3.4 on SqueakMap, so it doesn't
show up under packages).
- User does magic incantation, figures out the 'show all versions' deally
and tries to load the Zurgle SAR.
- Squeak starts barking, "server not responding" error, though you can use
the download menu item to download the SAR.
-- This is a SqueakMap bug
- There's another problem; compatibility with the StarBrowser package.
StarBrowser needs a little magic incantation to work in harmony with the
zurg.
As with any new image release, there are some problems. At the end of the
day, Zurgle comes out looking unusable, with which I have to agree.
Regardless of who, what, when, where or why it doesn't work. The feedback I
get, "Zurgle isn't a very reliable package". OK.
So, just like in the old days, I would hunt up the bugs and submit fixes (or
more likely whine loudly and the amazing Ned would magically fix them :-)
Submit them to the list with the appropriate tag. But here's the rub. Once
people start splitting the core image up, you can bet that whole silly
dependencies graph thing rears it's ugly head. To run this package you need
version 1.2 of this and 3.2 of that and 2.7 of the other thing. I'm not
close to smart enough to figure all that out. I couldn't even get my simple
package to work going from 3.2 to 3.5 when virtually no changes were
introduced within the monolithic image.
At the end of the day, what did all of the packaging stuff buy me? I'm sure
that there are benefits, I just can't think of any.
Jim

Post by Stephen Pair

Post by Bob Arning

Post by Bob Arning
- it does not solve any problem that I face now or forsee facing in the

near future
My sentiments exactly.
Jim Benson

I sort of look at SqueakMap as a kind of Google for Squeak stuff. It
makes it very easy to find and install Squeak goodies that people create
that are not included in the base image. For me, that's the most
important thing that SqueakMap does. The packaging effort is nothing
more than a refactoring effort.
- Stephen

--
- Stephen
_________
Do you need:
Web/Domain/Application Hosting?
Mailing List Services?
IMAP/POP3/Web Email Accounts?
Instant Messaging Accounts hosted on your domain?

Email me for information.

[diegogomezdeck at consultar.com ()]

Stephen,

The problem is not to try to modularize the image. The problem is to ignore
that it's really hard (close to imposible) to avoid somebody break the
reallyGoodDesign in a couple of hours.

The current evolution-state of Smalltalk (and Squeak) allows the mess, so
the mess will be there.

To *really* change theBigMess to a reallyGoodDesign we have to talk about
Smalltalk-2003 (the next Smalltalk).

The solution we're trying is to spend much more power on cleaning and
refactoring that the time used to create something.

To say in a short sentence: The current state of Smalltalk allows bad
designs so we'll have always bad-designs. (You know: Thermodynamic rules!)

Cheers,

Diego

Post by Stephen Pair
I'm having a hard time figuring out how any of these problems magically
disappear in the absence of system that is well factored into
packages. The ugly dependency graphs are all still there...you just
can't see them and it's difficult to cope with them.
For example, if I download base Squeak 3.5, and try to load Zurgle
directly from your website...I'll bet I run into the same issues you
described (if you haven't dealt with them already). Right now, the
only way for you to deal with that issue is to build your own
pre-packaged image with Zurgle included...and nothing stops you from
doing so in the presence of a well-factored Squeak.
However, if I want to use Zurgle with a different version of Squeak,
then I've potentially got some work to do. I can't see how having the
system properly factored into packages with dependencies clearly
understood would do anything but help that situation.
- Stephen

Post by Jimmie Houchin
Stephen,
I agree with the SqueakMap stuff. However, another part of the
'packaging' effort is refactoring the image and making large chunks of
the image 'unloadable'. For me, that's problematic (ok, I think it
sucks) ; what happens is that you end up with a whole lot of different
- I write a package, let's call it Zurgle.
- By request, I place it in a SAR package on SqueakMap.
- Let's say that going from 3.2 to 3.4 a bug is introduced,. For the
sake of argument, let's say it introduces a problem in 32-bit color
management. This manifests itself as making IconicButtons invisible,
and confuses FlapMorphs in their layout when different fonts are
assignd. Both problems in the stock image.
- By coincidence, let's say that Zurgle happens to try to load itself
in 32-bit color. People who download the SAR complain, and the
'reliability' of the Zurgle package is questioned. User downloads
Zurgle, it don't work. - As another coincidence, let's say we have an
image upgrade going from 3.4 to 3.5. (Zurgle package is still marked as
3.4 on SqueakMap, so it doesn't show up under packages).
- User does magic incantation, figures out the 'show all versions'
deally and tries to load the Zurgle SAR.
- Squeak starts barking, "server not responding" error, though you can
use the download menu item to download the SAR.
-- This is a SqueakMap bug
- There's another problem; compatibility with the StarBrowser package.
StarBrowser needs a little magic incantation to work in harmony with
the zurg.
As with any new image release, there are some problems. At the end of
the day, Zurgle comes out looking unusable, with which I have to agree.
Regardless of who, what, when, where or why it doesn't work. The
feedback I get, "Zurgle isn't a very reliable package". OK.
So, just like in the old days, I would hunt up the bugs and submit
fixes (or more likely whine loudly and the amazing Ned would magically
fix them :-) Submit them to the list with the appropriate tag. But
here's the rub. Once people start splitting the core image up, you can
bet that whole silly dependencies graph thing rears it's ugly head. To
run this package you need version 1.2 of this and 3.2 of that and 2.7
of the other thing. I'm not close to smart enough to figure all that
out. I couldn't even get my simple package to work going from 3.2 to
3.5 when virtually no changes were introduced within the monolithic
image.
At the end of the day, what did all of the packaging stuff buy me? I'm
sure that there are benefits, I just can't think of any.
Jim

Post by Stephen Pair

Post by Bob Arning

Post by Bob Arning
- it does not solve any problem that I face now or forsee facing in the

near future
My sentiments exactly.
Jim Benson

I sort of look at SqueakMap as a kind of Google for Squeak stuff. It
makes it very easy to find and install Squeak goodies that people
create that are not included in the base image. For me, that's the
most important thing that SqueakMap does. The packaging effort is
nothing more than a refactoring effort.
- Stephen

--
- Stephen
_________
Web/Domain/Application Hosting?
Mailing List Services?
IMAP/POP3/Web Email Accounts?
Instant Messaging Accounts hosted on your domain?
Email me for information.

[Jim Benson]

Stephen,

Post by Stephen Pair
I'm having a hard time figuring out how any of these problems magically
disappear in the absence of system that is well factored into packages.
The ugly dependency graphs are all still there...you just can't see them
and it's difficult to cope with them.

In the old days, the only dependency is that you have Squeak image version
x.x. That's the extent of the dependency graph. As you start breaking the
image up, you have the interdependencies of the image pieces.

Post by Stephen Pair
I can't see how having the
system properly factored into packages with dependencies clearly
understood would do anything but help that situation.

Personal View Here:

If it's a zero cost effort that will succeed, great. My perception is that
it takes a *lot* of work and some bit of luck for that outcome. As in the
case of modules, *I* don't get any real benefit. I download Jumbo image or
whatever, done. Hopefully any media are stored in a Project so I can jetison
them after I play with them. Typically, I don't do anything like that
currently.

I don't get the benefit of the update stream while we go through the
refactoring process (I think the update stream is important so that changes
can be tested by a larger group of people). So for *me*, I don't gain
anything. That's all I'm saying.

Jim

[Chris Reuter]

Post by Jimmie Houchin
Stephen,
I agree with the SqueakMap stuff. However, another part of the 'packaging'
effort is refactoring the image and making large chunks of the image
'unloadable'. For me, that's problematic (ok, I think it sucks) ;

The big plus as far as I can see is that you can write a stand-alone
desktop calculator that isn't ten megabytes in size. Since I'm using
Squeak for stand-alone apps, that's _very_ useful for me.

Post by Jimmie Houchin
what
happens is that you end up with a whole lot of different configurations of
- I write a package, let's call it Zurgle.
- By request, I place it in a SAR package on SqueakMap.

[and then a new version of Squeak introduces a bug that breaks Zurgle
and hilarity ensues]

The real problem is not with the packaging so much as that Squeak is a
moving target. There are no guarantees of compatiblity between
versions and that really complicates things when you introduce
packages. However, this lack of constraints lets Squeak evolve freely
so we don't really want to fix it in place.

So the current state has its plusses and minuses.

Of course, we can have it both ways. Just do what the Linux folks are
doing and split the project into a stable branch and development
branch. In particular:


1) Squeak development continues as it always has, as a single big
image with everything. There is no guarantee that _anything_ will
work between releases or even bug fix updates. We call this the
development branch.


2) Every year or two (or whenever the development branch reaches a
major milestone) we take a snapshot of the development branch and
call this the new stable branch.

All of the major subsystems get turned into SARs and experimental
stuff gets put into SARs tagged as "alpha code". There are no new
updates to the core except for bug fixes and those are expected
not to break compatiblity.


This won't be much extra work. We just need someone to go through all
the bug fixes and see if it's relevant to their branch and the update
system will need to be able to handle the presence or absence of
certain key optional subsystems, but that seems to be most of it.

The problem with this, of course, is that it's effectively a fork and
forks (sometimes) divide the effort. I don't think it's a problem in
this case, though, because code from one branch will be reasonably
easy to share with the other branch. If we reach a point where this
isn't the case anymore, it just means that it's time to abandon the
current stable branch and start another.

Post by Jimmie Houchin
At the end of the day, what did all of the packaging stuff buy me? I'm sure
that there are benefits, I just can't think of any.

See, I'd benefit enormously from something like that because I know
what's out there and can get it without any hard work. Since I'm
usually trying to use Squeak to do stuff rather than hack on Squeak
itself, that's a huge help for me.

It's just like CPAN, only for Squeak.

But I can see why it's not useful for you--it depends on what you're
doing. Hence, the stable branch idea.

Any thoughts?


--Chris

[Cees de Groot]

Post by Bob Arning
Any particular change will probably make some people more happy and others less so.

I see no reason whatsoever supporting the idea that this project is
somehow a zero sum game.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030507/a8d602e2/attachment.pgp

[goran.hultgren at bluefish.se ()]

Hi all!

Now I have read through this long thread and want to chip in. :-)


* Regarding how we develop Squeak and trying to use XP more:

We are all different. Period. Open Source projects like Squeak with
numerous developers scattered geographically using spare time simply
doesn't work with methods like XP. And people are doing this for fun and
want to work the way *they* like to - not using some method someone else
tells them to use. I am exaggerating a bit here to make my point. We are
trying to establish some standards like increasing the use of Tests etc.
but going much further than that is IMHO not good nor possible. Let
people have fun!


* Regarding packages vs images:

We will have both. Period.

Splitting the image into packages is mainly about clearing up the
dependencies. And when we do that we also gain the capability of being
able to have pieces of the codebase installable. Today SM feels like a
remote kindof repository (which it isn't - its a catalog) but in the
near future it will have a proper cache and hopefully people will see
that the end user experience will not be harmed.

Essentially this is how it will work:

1. You download Squeak. You selected to download the smallest zip-file
because you are on a modem. You get the smallest image and a filetree
with packages (the package cache of SM).

2. You fire up the image and read in a window that you can build a full
developer image or an even fuller "the works" image with a single click.
You pick the developer image. Squeak installs what it needs from the
local cache (no net involved) and let you save the new image.

3. At this point you are more or less where we are today. Knock yourself
out.

4. You look in the package loader and see that there is even more nice
things to load - hey, 5 different libraries for remote object calls, 3
different webservers etc. Yummy.

Now, please explain to me what you don't like with this picture.


* Regarding Bob's fear of loosing the synergy effects of a common
ground:

This one is IMHO the only interesting issue raised against the current
planned future. I have also thought about it. What happens when people
sit in different images and don't see the same things?

"Hey, just use class JumperThingy! What? You don't have that class? Oh,
sorry - it's in package Blammer."

Personally I think this is an important issue we need to try to address
as much as possible. For example - today you can select "senders of" and
get a list of senders. None? Aha, nobody uses that method - alt-x. :-)
But hey, nobody *in the image* uses that method. But what about packages
not installed? Many may say this is a new problem coming but it isn't.
We have had it all along - code outside of the image has been rotting
like hell because of Squeak changing beneath their feet. People have
even gotten to the point where they don't bother to port stuff to Squeak
because it will just stop working in the next Squeak release! Ooops -
isn't that a wake up call?

Having a proper SM we at least have a *chance* to make this situation
better. We could even create a "database" of senders/implementors that
have the information from *all* packages on SM. Think about that.


* Regarding all you that want a single image and no packages:

I may have already written about this above - but anyway...

How are you then going to cater to all the conflicting code packages out
there?
In one image "there can be only one" of each and every thing. One
library for doing remote calls. One webserver. And so on. Sure we could
try to stuff *everything* currently on SM into the image but hey - that
would not work, there is simply too much out there! So what do we choose
then? And who gets to choose? And what happens to all the other packages
that aren't allowed into the image? They turn into second class citizens
and rot away.

Face it people - if Squeak will be able to sustain the growth and be
able to scale with the community we *need* packages. But... that doesn't
mean we need to sacrifice the ability to simply download a rather big
and juice image and be happy. We have repeatedly explained that we aim
to have three of those available for immediate download.

Sorry for the long post.

regards, Göran

[Daniel Vainsencher]

Yup, some of the people in this discussion are aware of and to various
degrees buy into XP. However, the assumptions of XP are pretty stretched
by the realities. I think Eric S Raymonds "The cathedral and the bazaar"
and related papers are more relevant.

Daniel

Post by Daniel Vainsencher

Post by Daniel Vainsencher
What concerns me, and motivated me to start pushing

in certain

Post by Daniel Vainsencher
directions, is that Squeak's direction had ignored

some "economic

Post by Daniel Vainsencher
principles" of software development, and as a

result, really was dying.
It sounds like to me that it would help Squeak
considerably if it was developed the Extreme
Programming way (especially the core system). i.e.-
Face to Face communication, Pair programming, Test
First Development, on site customer (person(s) acting
in the capacity of) , ect..
http://www.extremeprogramming.org/rules.html
http://www.extremeprogramming.org/map/project.html
http://xprogramming.com/Practices/xpractices.htm
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap

Post by Daniel Vainsencher
PS: if we could get money for two persons full time

improving Squeak

Post by Daniel Vainsencher
this would solve a lot of problems.

Yes, at least two full time programmers. Or two
part-time programmers who can arrange to work at the
same time in the same place. So they can, at a
minimum, practice pair programming.
http://www.extremeprogramming.org/rules/pair.html
http://xprogramming.com/Practices/PracPairs.html
http://c2.com/cgi/wiki?PairProgramming

Post by Daniel Vainsencher
I'm really wondering how we could make this happens.

Squeak has had a significant involvement in Education,
has it not? Isn't there grants (government, corporate,
or private) which can be applied/lobbied for Squeak?
The Refactoring Browser was developed at a University
under the guidance of a professor was it not? Could
something similar be done with Squeak?
Failing that, Squeak developers who are geographically
located near each other could pair on a voluntary
basis.
In the event, were it's not possible to be in the same
room during the development process, ways to
effectively communicate still need to be found.
http://c2.com/cgi/wiki?InterTeamCommunication

Post by Daniel Vainsencher
If you tolerate this (cruft) then your children

will be next

Post by Daniel Vainsencher
Even now, the image, from a software engineering

perspective, is a mess.

Post by Daniel Vainsencher
Object (The Base Object) indirectly depends on well

over half the

Post by Daniel Vainsencher
classes in the system.

Dedication to Test Driven Development would help
considerably to resolve and avoid this situation.
http://c2.com/cgi/wiki?TestDrivenDevelopment
Moreover, XP puts a very strong emphasis on
communication, especially face to face communication.
A core group of people who are able to meet, plan, and
program in the same room using XP would go a long way
to resolving this cruft.
http://c2.com/cgi/wiki?WholeTeam

Post by Daniel Vainsencher
we have pages and pages describing a process (the

harvesting process) that

Post by Daniel Vainsencher
don't work. The bureaucracy is killing us. The

steps to get a fix

Post by Daniel Vainsencher
approved are, in most of the cases, more difficult

and time consumer than

Post by Daniel Vainsencher
the fix itself. We have lists of people with roles

(guides, harvesters,

Post by Daniel Vainsencher
etc) but in the reality only a few of them are

active and working.

Post by Daniel Vainsencher
These are pressures we simply have to respond to in

order to keep Squeak

Post by Daniel Vainsencher
alive and changing. This is what interests me.

Someone or some persons playing the role of the on
site "customer" could make it easier to resolve the
decision turn around time issues.
http://www.extremeprogramming.org/rules/customer.html
XP's practices were created in order to enable agility
and change. i.e.- "Embrace Change".
http://c2.com/cgi/wiki?AreYouDoingXp
http://c2.com/cgi/wiki?ExtremeValues
Just a thought,
Anthony
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

[Jeffrey T. Read]

Post by Daniel Vainsencher
Yup, some of the people in this discussion are aware of and to various
degrees buy into XP. However, the assumptions of XP are pretty stretched
by the realities. I think Eric S Raymonds "The cathedral and the bazaar"
and related papers are more relevant.

XP isn't a silver bullet. It tends to work well in certain development environments and situations so people tend to think it will be a panacea in ALL development situations.

CATB is not entirely relevant either, since Squeak seems to encompass aspects of the Cathedral (SqC/Guides) and Bazaar (the rest of us jabronies) within the same project.

Squeak is a different software project entirely from Linux, Mozilla, Perl, or something like that. And each of those employ their own methodologies with varying degrees of success. I think the thing to do when considering how to go about developing or improving a piece of software is to look for "design patterns" in your methodology and use the ones which work best. (There, another methodology buzzword. :))

[Daniel Vainsencher]

Assuming I understood correctly, I join Cees in expressing curiousity
about what you think about the current trends, and specifically what
makes you unhappy about splitting it into packages. If specific effects
bug you, maybe they can be dealt with better.

What I certainly don't want is to go on my merry way and get told "but
we didn't want this" a year down the road.

Daniel

Post by Bob Arning

Post by Cees de Groot

The short answer is no, not everybody shares the enthusiasm for that goal..

Ok, then I'm going to request the long answer ;-).
Enthusiasm is not necessary, but it *is* the only feasible way to make
sure Squeak works for everybody, not?

Well, first, does the "it" in "it *is* the only feasible way" refer to enthusiasm or to the (not quoted above) "politic of small-image with configurations"?
In any event, I'm not sure Squeak can work for everybody, depending on your interpretation of "work". Any particular change will probably make some people more happy and others less so. What sort of calculus one applies to sum up these pluses and minuses is, I think, entirely subjective. I'm one of those who sums it up for the present trends and arrives at a negative number. Maybe I'm alone in that regard, maybe not, but that's what prompted me to reply to Diego's inquiry.
Cheers,
Bob

[Bob Arning]

Post by Daniel Vainsencher
Assuming I understood correctly, I join Cees in expressing curiousity
about what you think about the current trends, and specifically what
makes you unhappy about splitting it into packages. If specific effects
bug you, maybe they can be dealt with better.

My dislike for the packagizing effort stems from:
- it has a _very_ low signal-to-noise ratio
- it does not solve any problem that I face now or forsee facing in the near future
- I think that it will reduce the shared experience that has contributed to the growth of Squeak to this point

Post by Daniel Vainsencher
What I certainly don't want is to go on my merry way and get told "but
we didn't want this" a year down the road.

You will not hear "but we didn't want this" from me since I speak only for myself. What I will say now is that the packagizing of Squeak is of zero interest to me personally and I suspect it will diminish the synergy that was so enjoyable in the old Squeak.

Cheers,
Bob

Post by Daniel Vainsencher
Daniel

Post by Bob Arning

Post by Cees de Groot

The short answer is no, not everybody shares the enthusiasm for that goal..

Ok, then I'm going to request the long answer ;-).
Enthusiasm is not necessary, but it *is* the only feasible way to make
sure Squeak works for everybody, not?

Well, first, does the "it" in "it *is* the only feasible way" refer to enthusiasm or to the (not quoted above) "politic of small-image with configurations"?
In any event, I'm not sure Squeak can work for everybody, depending on your interpretation of "work". Any particular change will probably make some people more happy and others less so. What sort of calculus one applies to sum up these pluses and minuses is, I think, entirely subjective. I'm one of those who sums it up for the present trends and arrives at a negative number. Maybe I'm alone in that regard, maybe not, but that's what prompted me to reply to Diego's inquiry.
Cheers,
Bob

[Dan Ingalls]

Post by Bob Arning
- it has a _very_ low signal-to-noise ratio
- it does not solve any problem that I face now or forsee facing in the near future
- I think that it will reduce the shared experience that has contributed to the growth of Squeak to this point

I don't see why this has to be...

Good packaging *should* make it easier for anyone to put out a new enhancement to Squeak. It should make it easier for people to try out, and it should make it easier for to ensure that it works in different versions of the system. If it becomes part of some jumbo image, it should make it easier for people to jettison if they don't want it.

This would appear to enhance the ease of sharing, and hence the motivation to contribute. I don't understand the downside.

Unless you're comparing it to a world in which everyone operates with the "latest and greatest jumbo image". Even then, I don't seeany conflict. While I'm sort of enjoying life on the sidelines right now, it always felt to me that the big picture in the package world supported several classic patterns of use:

Latest and Greatest Jumbo image
Includes just about everything that is stable, plus a couple of interesting
projects that are alpha and may not survive ultimately.
This is pretty much what SqC used to release.

Simple Development image
Complete enough to give full development support
but lean enough that you could feel proud to teach a class from it.
This is what the 2.1 Mini.image was (thought in the days of MVC)

Minimal Kernel
This one is hard to generalize because different people
want different stuff discarded.

I have always felt that it made sense to release both a Simple Development image and a Jumbo image. The promise of the packages work was to offer pretty much of a check-box control panel that could allow you to import or jettison anything between these three levels -- a great leap forward over the old discardX methods that leave dangling code references all over the place, and don't work from one release to the next.

So I see only upsides in the *framework*.

I have a feeling that the underlying issue is a bit more about leadership and how we choose direction. In the days of SqC it was pretty much of a (hopefully benevolent) dictatorship. This worked because the steady state community agreed with most of the direction -- by definition: those who didn't left the community.

It may be that there's a need to revisit some of the basic charter/vision issues, what with changes in the community, technology, leadership, etc. To the extent that this was successful, it might give the guides some useful guidance, and the community some useful assurance that there is a shared script where most major concerns are addressed. The idea is to separate the process of agreeing on a vision and plan from that of realizing the plan, and thus to reduce the chances of idealogical tension frustration in the process of practical progress.

This kind of realignment and rededication has to happen regularly (like yearly) in any evolving project such as this, but the responsibility for it is being allowed to fall back on the entire community now for the first time.

I realize this is SqF territory, but it's just my reflection on what has spilled out into general discussion in the last day or two.

- Dan

[Bill Schwab]

Daniel,

========================
Assuming I understood correctly, I join Cees in expressing curiousity
about what you think about the current trends, and specifically what
makes you unhappy about splitting it into packages. If specific effects
bug you, maybe they can be dealt with better.

What I certainly don't want is to go on my merry way and get told "but
we didn't want this" a year down the road.
========================

I'll jump in on this one, because I am also _slightly_ uneasy about the current direction. Ok, packages, and the ability to cleanly remove them is GREAT - bring it on :) However, I would very much like to not have to trust Squeak Map, or worse yet pick though what is sure to become several hundred, if not thousands, of packages to build an image. I want to download the whole mess at one shot and get going. Being able to chop out things that don't interest me is a BIG plus.

I haven't said anything because: (1) the cleanup is a good thing; (2) if Squeak becomes mission-critical to me, I'll end up making tools that make it easy to do the things I find tedious.

Before I jump off the soapbox, I'll stick in yet another plug for analysis/scripting tools to go along with Squeak Map; in short, something that can tell me what I need to grab to "do this again".

The other thing (probably my current pet issue for Squeak) is that it would be really nice if read streams would throw an exception when asked to read past the end of their collection. Not that I'm in a hurry to port it, I have a lot of code the depends on it.

And the third rail: the underscore thing. It's always interesting to look at file names in Scamper, and while some find it offensive, I have lots of code that uses underscores to prevent collisions. It works. It's a cash cow. Yes, I could fix it if I had to, but I really think that what should have been an optional convenience in the editor was allowed to soak into the compiler and sources. It should be fixed; sorry, just my 2 asCents.

The general question to the guides is: when does stuff like this cease to become advocacy and start to become nagging/ranting? I suspect that a big problem is that people suggest/fix, nothing happens, and they give up. Andreas' idea of a Wiki or other repository for ideas could be an excellent start. Some kind of tracking tool that lets "anybody" suggest, and only the guides prioritize might be better.

Thanks for listening!!

Bill


Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: ***@anest4.anest.ufl.edu
Tel: [phone]
FAX: [phone]

[Tim Rowledge]

Post by Bill Schwab
I'll jump in on this one, because I am also _slightly_ uneasy about the current direction. Ok, packages, and the ability to cleanly remove them is GREAT - bring it on :) However, I would very much like to not have to trust Squeak Map, or worse yet pick though what is sure to become several hundred, if not thousands, of packages to build an image. I want to download the whole mess at one shot and get going. Being able to chop out things that don't interest me is a BIG plus.

You won't have to trust SM nor wade through thousands of packages.
Remember, the declared aim is to release three kinds of image, all built
from the same base:-
1) the baby bear image, with almost nothing in it except enough to be
able to say "I exist!" and load more stuff. OR something like that.
2) the mummy bear image, with all that plus the typical things one would
expect in a Smalltalk developers system. UI, browsers, tools of many
flavours, etc
3) the big fat, TV watching couch potato daddy bear image with
everything (pretty much?) that is in the current release image.

The crucial bits we are trying to achieve right now is the ability to
a) make the baby bear image
b) add all that other stuff in a reliable manner

One day I imagine we will be able to unload packages as well but I
personally find it a little harder to work out how to
remove-without-breaking than load-without-breaking.

tim

[Richard A. O'Keefe]

Diego <***@consultar.com> wrote:
- The "Media-Squeakers" (in Andreas's words)
[want everything]
- The "Traditional-Squeaker" (in my words)
...
want a really small core image with nothing more than stdio support.

I place myself firmly, but FIRMLY, in the "Traditional Squeaker" camp.
Multimedia is way over my head.

BUT when I am developing in Squeak I for sure want to be able to
read stuff comfortably. While I might be interested in developing _for_
a teeny tiny core, the Squeak I am developing _in_ will most certainly
have some kind of font support, so it might as well be GOOD font support.

In short, when it comes to the Squeak that people develop in,
the needs of the Traditional Squeaker and of the Media-Squeakers
do not conflict at all.

[Benoit St-Jean]

Anyone can tell me what I need to properly load
Seaside and experiment with it?

I've tried loading it (with and without ComanchNG and
Seaside Services) in various orders but I can't seem
to make it work. Am I missing something? I get
walkbacks from all over the place...

=====
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero. -- Albert Einstein

[Avi Bryant]

Post by Benoit St-Jean
Anyone can tell me what I need to properly load
Seaside and experiment with it?

Have you tried following the tutorial at
http://beta4.com/seaside2/tutorial.html ?

Basically, if you:
1. Load Comanche 5.1 (not NG) from SqueakMap
2. Load Seaside from SqueakMap
3. execute: "WAKom startOn: 9090"
4. go to: http://localhost:9090/seaside/counter

You should see the simple counter demo.

Does this not work for you?

Avi

[Benoit St-Jean]

Post by Avi Bryant

Post by Benoit St-Jean
Anyone can tell me what I need to properly load
Seaside and experiment with it?

Have you tried following the tutorial at
http://beta4.com/seaside2/tutorial.html ?
1. Load Comanche 5.1 (not NG) from SqueakMap
2. Load Seaside from SqueakMap
3. execute: "WAKom startOn: 9090"
4. go to: http://localhost:9090/seaside/counter
You should see the simple counter demo.
Does this not work for you?

Doesn't work... Loads fine now but nothing is
displayed in browser... Anyway, got to leave now so
will check that tomorrow!

Thanks.

=====
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero. -- Albert Einstein

[Jim Menard]

Benoit,

Post by Benoit St-Jean

Post by Avi Bryant

Post by Benoit St-Jean
Anyone can tell me what I need to properly load
Seaside and experiment with it?

Have you tried following the tutorial at
http://beta4.com/seaside2/tutorial.html ?
1. Load Comanche 5.1 (not NG) from SqueakMap
2. Load Seaside from SqueakMap
3. execute: "WAKom startOn: 9090"
4. go to: http://localhost:9090/seaside/counter
You should see the simple counter demo.
Does this not work for you?

Doesn't work... Loads fine now but nothing is
displayed in browser... Anyway, got to leave now so
will check that tomorrow!

I followed these steps yesterday. I have two comments. First, for some
reason Seaside won't work for me when using Scamper. It works just fine in
Safari (Apple's new browser).

Second, there is a "self halt" in the decrement method of the WACounter
demo. It brings up a debugger walkback in the browser. Though that is very
cool, it was confusing until I found and commented out the "self halt".

Jim

[Julian Fitzell]

Post by Jim Menard
Benoit,

Post by Benoit St-Jean

Post by Avi Bryant

Post by Benoit St-Jean
Anyone can tell me what I need to properly load
Seaside and experiment with it?

Have you tried following the tutorial at
http://beta4.com/seaside2/tutorial.html ?
1. Load Comanche 5.1 (not NG) from SqueakMap
2. Load Seaside from SqueakMap
3. execute: "WAKom startOn: 9090"
4. go to: http://localhost:9090/seaside/counter
You should see the simple counter demo.
Does this not work for you?

Doesn't work... Loads fine now but nothing is
displayed in browser... Anyway, got to leave now so
will check that tomorrow!

I followed these steps yesterday. I have two comments. First, for some
reason Seaside won't work for me when using Scamper. It works just fine in
Safari (Apple's new browser).
Second, there is a "self halt" in the decrement method of the WACounter
demo. It brings up a debugger walkback in the browser. Though that is very
cool, it was confusing until I found and commented out the "self halt".

The self halt is there on purpose as a demo. I believe it's referred to
in the tutorial. I'm also not convinced it *should* be there by
default, but it isn't just a slip :)

Julian

[Stephane Ducasse]

Sorry diego I disagree.
We can do our best now, we are working on ST2003 but for now we need a
cleaner stuff.
I think that your frustration just came for a process issue. I have no
problem that a group of people work on something because they need it
and that the result gets in the image as soon as it does not break
obvious rules or other architectures.
See my previous email

Stef

Post by Jimmie Houchin
Stephen,
The problem is not to try to modularize the image. The problem is to
ignore
that it's really hard (close to imposible) to avoid somebody break the
reallyGoodDesign in a couple of hours.
The current evolution-state of Smalltalk (and Squeak) allows the mess,
so
the mess will be there.
To *really* change theBigMess to a reallyGoodDesign we have to talk
about
Smalltalk-2003 (the next Smalltalk).
The solution we're trying is to spend much more power on cleaning and
refactoring that the time used to create something.
To say in a short sentence: The current state of Smalltalk allows bad
designs so we'll have always bad-designs. (You know: Thermodynamic
rules!)
Cheers,
Diego

Post by Stephen Pair
I'm having a hard time figuring out how any of these problems
magically
disappear in the absence of system that is well factored into
packages. The ugly dependency graphs are all still there...you just
can't see them and it's difficult to cope with them.
For example, if I download base Squeak 3.5, and try to load Zurgle
directly from your website...I'll bet I run into the same issues you
described (if you haven't dealt with them already). Right now, the
only way for you to deal with that issue is to build your own
pre-packaged image with Zurgle included...and nothing stops you from
doing so in the presence of a well-factored Squeak.
However, if I want to use Zurgle with a different version of Squeak,
then I've potentially got some work to do. I can't see how having the
system properly factored into packages with dependencies clearly
understood would do anything but help that situation.
- Stephen

Post by Jimmie Houchin
Stephen,
I agree with the SqueakMap stuff. However, another part of the
'packaging' effort is refactoring the image and making large chunks
of
the image 'unloadable'. For me, that's problematic (ok, I think it
sucks) ; what happens is that you end up with a whole lot of
different
- I write a package, let's call it Zurgle.
- By request, I place it in a SAR package on SqueakMap.
- Let's say that going from 3.2 to 3.4 a bug is introduced,. For the
sake of argument, let's say it introduces a problem in 32-bit color
management. This manifests itself as making IconicButtons invisible,
and confuses FlapMorphs in their layout when different fonts are
assignd. Both problems in the stock image.
- By coincidence, let's say that Zurgle happens to try to load itself
in 32-bit color. People who download the SAR complain, and the
'reliability' of the Zurgle package is questioned. User downloads
Zurgle, it don't work. - As another coincidence, let's say we have an
image upgrade going from 3.4 to 3.5. (Zurgle package is still marked
as
3.4 on SqueakMap, so it doesn't show up under packages).
- User does magic incantation, figures out the 'show all versions'
deally and tries to load the Zurgle SAR.
- Squeak starts barking, "server not responding" error, though you
can
use the download menu item to download the SAR.
-- This is a SqueakMap bug
- There's another problem; compatibility with the StarBrowser
package.
StarBrowser needs a little magic incantation to work in harmony with
the zurg.
As with any new image release, there are some problems. At the end of
the day, Zurgle comes out looking unusable, with which I have to
agree.
Regardless of who, what, when, where or why it doesn't work. The
feedback I get, "Zurgle isn't a very reliable package". OK.
So, just like in the old days, I would hunt up the bugs and submit
fixes (or more likely whine loudly and the amazing Ned would
magically
fix them :-) Submit them to the list with the appropriate tag. But
here's the rub. Once people start splitting the core image up, you
can
bet that whole silly dependencies graph thing rears it's ugly head.
To
run this package you need version 1.2 of this and 3.2 of that and 2.7
of the other thing. I'm not close to smart enough to figure all that
out. I couldn't even get my simple package to work going from 3.2 to
3.5 when virtually no changes were introduced within the monolithic
image.
At the end of the day, what did all of the packaging stuff buy me?
I'm
sure that there are benefits, I just can't think of any.
Jim

Post by Stephen Pair

Post by Bob Arning

Post by Bob Arning
- it does not solve any problem that I face now or forsee facing
in
the

near future
My sentiments exactly.
Jim Benson

I sort of look at SqueakMap as a kind of Google for Squeak stuff.
It
makes it very easy to find and install Squeak goodies that people
create that are not included in the base image. For me, that's the
most important thing that SqueakMap does. The packaging effort is
nothing more than a refactoring effort.
- Stephen

--
- Stephen
_________
Web/Domain/Application Hosting?
Mailing List Services?
IMAP/POP3/Web Email Accounts?
Instant Messaging Accounts hosted on your domain?
Email me for information.

[Daniel Vainsencher]

Why do you think Squeak changing wouldn't break Zurgle?
Why do you think Zurgle wouldn't interact badly with StarBrowser?

Only reasons you're noticing that problem now is that SM makes it so
much easier for people to use your code, you're getting more feedback.
Since it makes it easy to load that AND other tools, some people
actually try both together.

The reality is the same reality - bits rot, complex software needs to be
maintained.

SM means that you're doing the same things for a lot more benefit - more
people enjoying the loveliness of your changes.

Modularization will one day means you'll need to do less work, and you
work will be worth morebecause of cleaner interfaces. As in all those
package that show up in the open menu, and magically don't remove one
another when two are loaded :-)

Daniel

Post by Jimmie Houchin
Stephen,
I agree with the SqueakMap stuff. However, another part of the 'packaging'
effort is refactoring the image and making large chunks of the image
'unloadable'. For me, that's problematic (ok, I think it sucks) ; what
happens is that you end up with a whole lot of different configurations of
- I write a package, let's call it Zurgle.
- By request, I place it in a SAR package on SqueakMap.
- Let's say that going from 3.2 to 3.4 a bug is introduced,. For the sake of
argument, let's say it introduces a problem in 32-bit color management. This
manifests itself as making IconicButtons invisible, and confuses FlapMorphs
in their layout when different fonts are assignd. Both problems in the stock
image.
- By coincidence, let's say that Zurgle happens to try to load itself in
32-bit color. People who download the SAR complain, and the 'reliability' of
the Zurgle package is questioned. User downloads Zurgle, it don't work.
- As another coincidence, let's say we have an image upgrade going from 3.4
to 3.5. (Zurgle package is still marked as 3.4 on SqueakMap, so it doesn't
show up under packages).
- User does magic incantation, figures out the 'show all versions' deally
and tries to load the Zurgle SAR.
- Squeak starts barking, "server not responding" error, though you can use
the download menu item to download the SAR.
-- This is a SqueakMap bug
- There's another problem; compatibility with the StarBrowser package.
StarBrowser needs a little magic incantation to work in harmony with the
zurg.
As with any new image release, there are some problems. At the end of the
day, Zurgle comes out looking unusable, with which I have to agree.
Regardless of who, what, when, where or why it doesn't work. The feedback I
get, "Zurgle isn't a very reliable package". OK.
So, just like in the old days, I would hunt up the bugs and submit fixes (or
more likely whine loudly and the amazing Ned would magically fix them :-)
Submit them to the list with the appropriate tag. But here's the rub. Once
people start splitting the core image up, you can bet that whole silly
dependencies graph thing rears it's ugly head. To run this package you need
version 1.2 of this and 3.2 of that and 2.7 of the other thing. I'm not
close to smart enough to figure all that out. I couldn't even get my simple
package to work going from 3.2 to 3.5 when virtually no changes were
introduced within the monolithic image.
At the end of the day, what did all of the packaging stuff buy me? I'm sure
that there are benefits, I just can't think of any.
Jim

Post by Stephen Pair

Post by Bob Arning

Post by Bob Arning
- it does not solve any problem that I face now or forsee facing in the

near future
My sentiments exactly.
Jim Benson

I sort of look at SqueakMap as a kind of Google for Squeak stuff. It
makes it very easy to find and install Squeak goodies that people create
that are not included in the base image. For me, that's the most
important thing that SqueakMap does. The packaging effort is nothing
more than a refactoring effort.
- Stephen

[Sean Charles]

Post by Tim Rowledge
One day I imagine we will be able to unload packages as well but I
personally find it a little harder to work out how to
remove-without-breaking than load-without-breaking.

As my old woodwork teacher used to say: "You can always take away (wood)
but you can't put it back!" when making a dove-tailed box for a project.

[Tim Rowledge]

Post by Sean Charles

Post by Tim Rowledge
One day I imagine we will be able to unload packages as well but I
personally find it a little harder to work out how to
remove-without-breaking than load-without-breaking.

As my old woodwork teacher used to say: "You can always take away (wood)
but you can't put it back!" when making a dove-tailed box for a project.

Whilst I (as a forty year experienced woodworker) can appreciate that,
I also (as a thirty year experienced programmer and ~twenty year
Smalltalker) would point out that it doesn't really apply terribly well
to the issue of intertwinglements within an image.

One of the problems we have let creep up on us is that in an image one
can get references to all sorts of objects that perhaps we shouldn't
have. Removing sections of the system leaves dangling refernces and
messes up life, not least wrt garbage collection. At least we have been
smarter than the c++#/java people and it rarely explodes the image...
I think part of the problem has been a (possibly misguided) effort to
'improve performance' rather than really relying upon message sending.
Remeber Alan's canonical talk about the origins of OOP as being like
biology? We should consider being a little more like cells with
messenger proteins doing our communicating. And no, I don't have any
magical proposal how to do that, sadly.

One big advantage of having a system explicitly built upon packages that
accrete is that people will be forced to think a little about issues
like 'what if this is not here?', 'how do I find out is this stuff is
present?' and so on. Since we are a lazy but creative bunch, I posit
that this pressure will lead to some useful tools to help make it all
happen semi-automagically. At first I suspect there will be a rapid
spread of the infection of
Smalltalk classAt: #Foo
ifAbsent:[^self damnitError: 'Foo not installed']
until somebody finds some patterns that serve as phages.

tim

[Sean Charles]

I've been following this discussion with great interest and then I see...

Post by Bob Arning
packagizing of Squeak is of zero interest to me personally and I suspect
it will diminish the synergy that was so enjoyable in the old Squeak.

BINGO and DITTO! To *me* personally, what Bob says here is absolutely on
the money, 200 percent and then some. When I first got introduced to
Squeak about three years ago(?), it was at 2.7. A long time Smalltalker
(10+ years plus) IBM guy I worked with would constantly be saying 'Ah yes,
but in Smalltalk it's practically free (class creation overhead)' and so
on while we developed a C++ object engine for a database, all the thorny
issues in C++ he would say 'Oh, in ST you would just become that object'
etc etc. He then showed me 2.7 on a ThinkPad and I've been sadly, madly
addicted since then. I judge all other IDE's and languages against
Smalltalk and they all come up short most if the time, IMO.

The *best* think about a Squeak download is the sheer volume and diversity
of classes you get built in. As well as the expected boring stuff (numbers,
strings, files etc) you get Morphic, you get MPEG stuff, Sound stuff,
WarpBlt, JPEG, images flying everywhere, the paintbox, scripting, eToys,
Scamper, Celeste, and so on...this was what blew me out in the early days.
it still does to some extent as the range is always increasing it seems.

If I had had to download and install other packages to do all those things
it currently does out of the box, I just know that I wouldn't have
bothered and moved on to something else....maybe? I remember reading the
original Smalltalk Byte(81) article and thinking 'this is brilliant' but
being young and green, Smalltalk passed me by as I continued college etc
etc jobs...life etc etc.

To *win over* newcomers then, I think that a massive, bloated,
splitting-at-the-seams image is how it should be, and currently is. When I
first got into Linux, the thing that stumped / irritated / confused me the
most was the 'perceived complexity' of matching libraries against distros.
of this and that to make things work. Indeed, the first time I got Squeak
to run on Linux box it took some long head-banging and judicious use of
'ln'!

A newcomer does not want this. IMHO, a newcomer will definitely not want
to know JS about what modules are. Hey, I just bought a Ferrari, why do I
need to know about hydraulic brakes, I just wanna burn rubber. FAST!

As a developer, I see the value in modularizing the bits and pieces but I
think that it should be very well hidden through a superb interface for
newcomers lest they get put off and think it's too difficult.

Squeak will never die because it is just too good a meme that has infected
too many people!

Sean Charles.

PS: Tim, your mail server might be able to beat up mine but my dongle is
bigger than yours.

[Cees de Groot]

Post by Sean Charles
To *win over* newcomers then, I think that a massive, bloated,
splitting-at-the-seams image is how it should be, and currently is.

Please tell me where you read that we will *not* supply a full image
anymore. In fact, I think in the course of this discussion, it has been
mentioned at least 6 times that the full image *will* be available. It
helps to read a thread before you step in with a rant.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030507/0e2dda15/attachment.pgp

[Sean Charles]

Dear Cees and List,

Post by Cees de Groot

Post by Sean Charles
To *win over* newcomers then, I think that a massive, bloated,
splitting-at-the-seams image is how it should be, and currently is.

Please tell me where you read that we will *not* supply a full image
anymore. In fact, I think in the course of this discussion, it has been
mentioned at least 6 times that the full image *will* be available. It
helps to read a thread before you step in with a rant.

LOL. Er, excuse me, but please point out to me in that sentence where I am
ranting? I think people have talked too much and are getting a little
flaky and edgy. Chill, relax. Ranting is anything but close to my 'mood'.
HA HA HA. Sometimes e-mail is unbelievably bad at communicating! By
'massive, bloated. splitting-at-the-seams' I am actually being
complimentary.

Post by Cees de Groot
mentioned at least 6 times that the full image *will* be available. It
helps to read a thread before you step in with a rant.

Good job I'm thick skinned or I'd be extremely offended at that remark.
Firstly, I have read *every* post so far and secondly, I *never* rant, it
wastes energy. I suggest *you* read things more carefully before stepping
in with a *downright offensive and insulting reply*. And people go on
about not putting people off regarding Squeak.

I', disabling my mail for a week until a new topic lands.
People should chill out a little.

Yours disgustedly,
Sean Charles.

[Benoit St-Jean]

For whatever reason, the last bunch of updates did
screw up my image. As I speak, I have a debugger
opened on a collection of more than 62000 processes!

In other words, how can I just kill all those and
re-initialize the Squeak processes?



=====
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero. -- Albert Einstein

[Ned Konz]

Post by Benoit St-Jean
For whatever reason, the last bunch of updates did
screw up my image. As I speak, I have a debugger
opened on a collection of more than 62000 processes!
In other words, how can I just kill all those and
re-initialize the Squeak processes?

What are the processes?

What spawned them?

What's their priority?

You could do something like this:

(Process allSubInstances select: [ :ea | (ProcessBrowser
nameAndRulesFor: ea) second and: [ ea suspendedContext notNil ]]) do:
[ :ea | ea terminate ]

[Benoit St-Jean]

On Friday 09 May 2003 11:27 am, Benoit St-Jean

Post by Benoit St-Jean
For whatever reason, the last bunch of updates did
screw up my image. As I speak, I have a debugger
opened on a collection of more than 62000

processes!

Post by Benoit St-Jean
In other words, how can I just kill all those and
re-initialize the Squeak processes?

What are the processes?

Don't know!!! More than 61800 of them are of priority
70 (highIOPriority). A quick look at the senders of
#highIOPriority shows nothing that rings a bell...

What spawned them?

No idea! All of them have a <nil> suspendedContext
though.
All of them have the allow-debug flag to false.

Any hint/idea/revelation ?

=====
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero. -- Albert Einstein

[Ned Konz]

Post by Benoit St-Jean

Post by Ned Konz
What are the processes?

Don't know!!! More than 61800 of them are of priority
70 (highIOPriority). A quick look at the senders of
#highIOPriority shows nothing that rings a bell...

Are you running anything that tends to spawn processes (database,
Comanche, etc.)?

[Benoit St-Jean]

On Friday 09 May 2003 12:10 pm, Benoit St-Jean

Post by Benoit St-Jean

Post by Ned Konz
What are the processes?

Don't know!!! More than 61800 of them are of

priority

Post by Benoit St-Jean
70 (highIOPriority). A quick look at the senders

of

Post by Benoit St-Jean
#highIOPriority shows nothing that rings a bell...

Are you running anything that tends to spawn
processes (database,
Comanche, etc.)?

Nope!

=====
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero. -- Albert Einstein

[Ned Konz]

On Friday 09 May 2003 12:10 pm, Benoit St-Jean

Post by Benoit St-Jean

Post by Ned Konz
What are the processes?

Don't know!!! More than 61800 of them are of

priority

Post by Benoit St-Jean
70 (highIOPriority). A quick look at the senders

of

Post by Benoit St-Jean
#highIOPriority shows nothing that rings a bell...

Are you running anything that tends to spawn
processes (database,
Comanche, etc.)?

Nope!

Have you run the EToyPeerToPeer stuff or started up a Nebraska server?
Both of these use highIOPriority to start their processes.

[Benoit St-Jean]

On Friday 09 May 2003 12:19 pm, Benoit St-Jean

On Friday 09 May 2003 12:10 pm, Benoit St-Jean

Post by Benoit St-Jean

Post by Ned Konz
What are the processes?

Don't know!!! More than 61800 of them are of

priority

Post by Benoit St-Jean
70 (highIOPriority). A quick look at the

senders

of

Post by Benoit St-Jean
#highIOPriority shows nothing that rings a

bell...

Are you running anything that tends to spawn
processes (database,
Comanche, etc.)?

Nope!

Have you run the EToyPeerToPeer stuff or started up
a Nebraska server?
Both of these use highIOPriority to start their
processes.

Nope! Pretty strange ! Can't terminate or suspend
these processes either!

=====
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
A standpoint is an intellectual horizon of radius zero. -- Albert Einstein