Discussion:
FractalMorph 1.2 won't load into 3.10.2-7179
(too old to reply)
Greg A. Woods; Planix, Inc.
2012-01-28 12:21:49 UTC
Permalink
I get this while trying to load FractalMorph 1.2 from the Package
Universe browser:

PluggableTextMorph(Object)>>doesNotUnderstand:
#hideScrollBarIndefinitely
FractalMorph>>initButtons
FractalMorph>>initialize
FractalMorph class(Behavior)>>new
UndefinedObject>>DoIt
Compiler>>evaluate:in:to:notifying:ifFail:logged:
Compiler class>>evaluate:for:notifying:logged:
Compiler class>>evaluate:for:logged:
Compiler class>>evaluate:logged:
[] in MultiByteFileStream(PositionableStream)>>fileInAnnouncing:
{[val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self
nextChunk l...]}
BlockContext>>on:do:
[] in MultiByteFileStream(PositionableStream)>>fileInAnnouncing:
{[:bar | [self atEnd] whileFalse: [bar value: self position.
self skipS...]}
[] in ProgressInitiationException>>defaultMorphicAction {[result :=
workBlock value: progress]}
BlockContext>>ensure:
ProgressInitiationException>>defaultMorphicAction
ProgressInitiationException>>defaultAction
UndefinedObject>>handleSignal:
MethodContext(ContextPart)>>handleSignal:
ProgressInitiationException(Exception)>>signal
ProgressInitiationException>>display:at:from:to:during:
--
Greg A. Woods; Planix, Inc.
<***@planix.ca>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081204/f924798e/PGP.pgp
Edgar J. De Cleene
2012-01-28 12:21:50 UTC
Permalink
Post by Greg A. Woods; Planix, Inc.
I get this while trying to load FractalMorph 1.2 from the Package
#hideScrollBarIndefinitely
FractalMorph>>initButtons
FractalMorph>>initialize
FractalMorph class(Behavior)>>new
UndefinedObject>>DoIt
{[val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self
nextChunk l...]}
{[:bar | [self atEnd] whileFalse: [bar value: self position.
self skipS...]}
[] in ProgressInitiationException>>defaultMorphicAction {[result :=
workBlock value: progress]}
ProgressInitiationException>>defaultMorphicAction
ProgressInitiationException>>defaultAction
ProgressInitiationException(Exception)>>signal
--
Greg A. Woods; Planix, Inc.
http://map.squeak.org/package/5728e8ea-6a53-4a67-ae1c-07f17defca22

Shows is originated in 3.4 , so no surprise not porper work in 3.10.

As I said in previous mail, we need a Packages Czar now, with power
to rule the Universes :=)

I could do this , if all agree.

For credentials, I made SqueakLight , SqueakLightII, FunSqueak, was
in past Release Team and help to port many old friends to recent images.


Edgar
Andreas Raab
2012-01-28 12:21:50 UTC
Permalink
As I said in previous mail, we need a Packages Czar now, with power to
rule the Universes :=)
I could do this , if all agree.
I think this would be great. You have my support.

Cheers,
- Andreas
Edgar J. De Cleene
2012-01-28 12:21:50 UTC
Permalink
Post by Andreas Raab
I think this would be great. You have my support.
Cheers,
- Andreas
Very thanks.

My Plan , as we discusss with Ralph (hope he read and correct me)
A review of "state of affairs" for all packages now in Squeakmap.

Tentative list to check.

This "MyGreatThing" is on Universes ?
Loads in fresh 3.10 current ?
Who owns / mantain it ?
Have .mcz version in SqueakSource ?
Have tutorial for newbies ?

We discuss in doing a Lint for each, we could do swiki page for this.
In the past, many improve his packages when I email they.
In Ralph Monticello version in 3,10, when you have a Undeclared you
got a halt.

I once talk about some more , like a Custom Office checking you don't
bring bombs or dangeorous things to OurKingdom.
Ideas to check this ?

All packages should have a owner.
No foreing people should take other packages.
Packages without owner for two years become free for any wishing take
they,
Packages without any wishing take they go to OrphansHouse,

Feedback ?

Edgar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081205/e7b1bf10/attachment.htm
Keith Hodges
2012-01-28 12:21:50 UTC
Permalink
Post by Andreas Raab
Post by Edgar J. De Cleene
As I said in previous mail, we need a Packages Czar now, with power
to rule the Universes :=)
I could do this , if all agree.
I think this would be great. You have my support.
Cheers,
- Andreas
I suggested this months and months ago, the
***@list.squeakfoundation.org was seconded for this very purpose,
and is used for that very thing.

Since the keeper of Universes resisted any sensible suggestions to make
things open enough to fix problems effectively, I developed
Sake/Packages instead. I spent less time developing Sake/Packages than I
did wrestling with Universes trying to build my production image.

The best way forward is for the community to manage all of the package
definitions for all of the images in Sake/Packages. Then to have an
automated build script which is able to update the universe(s) server
from the Sake/Packages definitions.

At present this is done the other way around, Universes is synced to
Sake/Packages, but S/P reserves the right to override the universes
definition. Inability to fix a broken universe entry is still the
biggest problem in keeping things in sync.

My personally favoured option would be to forget about universes
entirely because it is a pain to keep current. But the "keeping them
bothin sync" option would certainly be worthwhile.

Keith

p.s. Andreas, Sake/Packages is data driven now.
Greg A. Woods; Planix, Inc.
2012-01-28 12:21:50 UTC
Permalink
I'm glad I'm keeping this topic alive with my bug reports! :-)

I must say though that the underlying complexity that shows up here
mystifies me somewhat. I'm guessing there's some kind of politics
under the hood that I'm not fully aware of.

The basic problem for me is that I need the default package management
tool, however it might work under the hood, to actually work reliably,
110%, all the time for everyone.

I.e. there's a button for the user to press in the default 3.10.2-7179-
basic package which starts the process and I think it's essential that
everything from there work 110%, even if it means that what's
available lags somewhat behind the latest and greatest of what's
available.

Also essential is a clean and safe way of upgrading installed
packages. Default error handlers need to be in place to cleanly and
safely back out any attempted upgrades which encounter any errors or
conflicts. It would also be nice to have a de-installer and cleanup
tools in the package manager too. Sure one can always start with a
fresh image and load everything still wanted from scratch, including
one's own local change sets, etc., and doing so has some of its own
advantages, but for beginners and _end_ users an uninstaller is pretty
much a necessary feature of any package management subsystem.

The consequences of not having 110% perfection in the initial user
experience of loading new packages into the now stripped down basic
Squeak image means skeptical users will be driven away in droves.

Perhaps it would be better to return to a form of the old pre-loaded
bloated image, but this time adorn it with tools that would facilitate
_unloading_ of unwanted packages by those who want to reduce the
bloat. The last time I forayed with any dedication into the world of
Squeak I was actually very happy to have a complete stable
distribution image that came with all the available tools and toys
already installed and tested. It meant I could jump right in and play
or work with anything and everything. Now with 3.10 it's almost three
weeks since I tried to "upgrade" and I'm still struggling. I hate to
think what any more naive user than I would feel about this experience.

There are problems with the pre-loaded image though -- looking at
what's in the dev image now makes me want to avoid it because it
contains some stuff I don't want, stuff which so far as I understand
actually changes too much about the environment over and above the
default "basic" configuration which want to work with.

Squeak definitely needs a good strong leader, or at least a cohesive
leadership, with a good and hopefully popular vision of where the core
is going and how it's going to get there, and I think now with the
"basic" default image being one without everything pre-loaded this
vision has to stretch out over the basic package management issues too.
--
Greg A. Woods; Planix, Inc.
<***@planix.ca>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081205/d61dbd52/PGP.pgp
Tim Johnson
2012-01-28 12:21:50 UTC
Permalink
Hear, hear. This has the makings of a manifesto. Thus I have quoted
it in its entirety :)

- TimJ
Post by Greg A. Woods; Planix, Inc.
I'm glad I'm keeping this topic alive with my bug reports! :-)
I must say though that the underlying complexity that shows up here
mystifies me somewhat. I'm guessing there's some kind of politics
under the hood that I'm not fully aware of.
The basic problem for me is that I need the default package
management tool, however it might work under the hood, to actually
work reliably, 110%, all the time for everyone.
I.e. there's a button for the user to press in the default
3.10.2-7179-basic package which starts the process and I think it's
essential that everything from there work 110%, even if it means
that what's available lags somewhat behind the latest and greatest
of what's available.
Also essential is a clean and safe way of upgrading installed
packages. Default error handlers need to be in place to cleanly and
safely back out any attempted upgrades which encounter any errors or
conflicts. It would also be nice to have a de-installer and cleanup
tools in the package manager too. Sure one can always start with a
fresh image and load everything still wanted from scratch, including
one's own local change sets, etc., and doing so has some of its own
advantages, but for beginners and _end_ users an uninstaller is
pretty much a necessary feature of any package management subsystem.
The consequences of not having 110% perfection in the initial user
experience of loading new packages into the now stripped down basic
Squeak image means skeptical users will be driven away in droves.
Perhaps it would be better to return to a form of the old pre-loaded
bloated image, but this time adorn it with tools that would
facilitate _unloading_ of unwanted packages by those who want to
reduce the bloat. The last time I forayed with any dedication into
the world of Squeak I was actually very happy to have a complete
stable distribution image that came with all the available tools and
toys already installed and tested. It meant I could jump right in
and play or work with anything and everything. Now with 3.10 it's
almost three weeks since I tried to "upgrade" and I'm still
struggling. I hate to think what any more naive user than I would
feel about this experience.
There are problems with the pre-loaded image though -- looking at
what's in the dev image now makes me want to avoid it because it
contains some stuff I don't want, stuff which so far as I understand
actually changes too much about the environment over and above the
default "basic" configuration which want to work with.
Squeak definitely needs a good strong leader, or at least a cohesive
leadership, with a good and hopefully popular vision of where the
core is going and how it's going to get there, and I think now with
the "basic" default image being one without everything pre-loaded
this vision has to stretch out over the basic package management
issues too.
Stéphane Rollandin
2012-01-28 12:21:50 UTC
Permalink
+ 1

Stef
Edgar J. De Cleene
2012-01-28 12:21:51 UTC
Permalink
Post by Greg A. Woods; Planix, Inc.
Squeak definitely needs a good strong leader, or at least a
cohesive leadership, with a good and hopefully popular vision of
where the core is going and how it's going to get there, and I
think now with the "basic" default image being one without
everything pre-loaded this vision has to stretch out over the basic
package management issues too.
But we don't have a good strong leader.

Hopes of many was when Dan say he wish be on Board.

Now I sit on his chair (because maybe nobody with better
qualification is at hand ?).

You should be new, so don't know about Pirates or Failed Unification
of all Forks (Open meeting regarding the Squeak Release Team, look
for this)

This days all have his own image and some go Pharo, some go Damien
dev, no idea who is going Squeakland or EToys or Sophie or Scratch or...

Maybe we becoming Linux ? With thousands of distributions on some
similar core ?

Ketih and Matthew said they made 3.11 .

Craig said he made Spoon.

Where are they ? Could you use ?

I have my pet , SqueakLightIi, based on years of work, RUNNING.

http://wiki.squeak.org/squeak/6056
http://wiki.squeak.org/squeak/6098

I have FunSqueak RUNNING

Edgar

P.S. I don't said running at 110% as you wish,
For this I ask zillions gold coins , like the other Board member who
leaves we in the dark and crying :-)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081205/bebae9b4/attachment.htm
David Mitchell
2012-01-28 12:21:51 UTC
Permalink
Pharo is active and producing the Smalltalk that I always wanted.

On Fri, Dec 5, 2008 at 3:12 PM, Edgar J. De Cleene
Post by Greg A. Woods; Planix, Inc.
Squeak definitely needs a good strong leader, or at least a cohesive
leadership, with a good and hopefully popular vision of where the core is
going and how it's going to get there, and I think now with the "basic"
default image being one without everything pre-loaded this vision has to
stretch out over the basic package management issues too.
But we don't have a good strong leader.
Hopes of many was when Dan say he wish be on Board.
Now I sit on his chair (because maybe nobody with better qualification is at
hand ?).
You should be new, so don't know about Pirates or Failed Unification of all
Forks (Open meeting regarding the Squeak Release Team, look for this)
This days all have his own image and some go Pharo, some go Damien dev, no
idea who is going Squeakland or EToys or Sophie or Scratch or...
Maybe we becoming Linux ? With thousands of distributions on some similar
core ?
Ketih and Matthew said they made 3.11 .
Craig said he made Spoon.
Where are they ? Could you use ?
I have my pet , SqueakLightIi, based on years of work, RUNNING.
http://wiki.squeak.org/squeak/6056
http://wiki.squeak.org/squeak/6098
I have FunSqueak RUNNING
Edgar
P.S. I don't said running at 110% as you wish,
For this I ask zillions gold coins , like the other Board member who leaves
we in the dark and crying :-)
Igor Stasenko
2012-01-28 12:21:51 UTC
Permalink
Post by David Mitchell
Pharo is active and producing the Smalltalk that I always wanted.
- there is no human resources to support bloated image(s) by single
team, and i hope that Pharo guys understand this clearly and never
turn back to strategy of maintaining big-fat bloated images. It should
be clear, where ends Pharo and where starts package(s) developed and
maintained by independent developers/teams.

- i think that somewhere in crosshatching Pharo and Spoon lies a golden spot:
- having well integrated old-style image (Pharo)
- but also be very agile/modular (Spoon).

- IMO, first and ultimately , squeak needs better modularity to move on.
- only when we solve the first problem, it would be much easier to
come up with better integration solutions (packaging tools)
--
Best regards,
Igor Stasenko AKA sig.
Keith Hodges
2012-01-28 12:21:51 UTC
Permalink
Post by Igor Stasenko
Post by David Mitchell
Pharo is active and producing the Smalltalk that I always wanted.
- there is no human resources to support bloated image(s) by single
team, and i hope that Pharo guys understand this clearly and never
turn back to strategy of maintaining big-fat bloated images. It should
be clear, where ends Pharo and where starts package(s) developed and
maintained by independent developers/teams.
Well said that man!

+10

Keith
Post by Igor Stasenko
- having well integrated old-style image (Pharo)
- but also be very agile/modular (Spoon).
- IMO, first and ultimately , squeak needs better modularity to move on.
- only when we solve the first problem, it would be much easier to
come up with better integration solutions (packaging tools)
My point exactly - watch this space
Edgar J. De Cleene
2012-01-28 12:21:51 UTC
Permalink
Post by David Mitchell
Pharo is active and producing the Smalltalk that I always wanted.
So go to Pharo, I don't wish unhappy people.

Or go Ruby, Perl, COBOL or any you feel at home with.

But I want Squeak as once was.

For kids, for teachers, for researchers and for web developers, and
for all who found some different in it.

And I do my best for going smaller and modular for you only load what
you want and others load different things like MathMorphs,
MorphicWrappers, Etoys, or maybe Morphic 3.0 one day.


This list lost FUN.

Edgar




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081205/d6033c8e/attachment.htm
Keith Hodges
2012-01-28 12:21:51 UTC
Permalink
Post by Edgar J. De Cleene
Post by Greg A. Woods; Planix, Inc.
Squeak definitely needs a good strong leader, or at least a cohesive
leadership, with a good and hopefully popular vision of where the
core is going and how it's going to get there, and I think now with
the "basic" default image being one without everything pre-loaded
this vision has to stretch out over the basic package management
issues too.
But we don't have a good strong leader.
No we dont need a strong leader. We tried that one before and what we
got was an uncommunicative invisible ne disappearing leader.

What we need is people who are willing to contribute positively to the
positive forward thinking vision that we already have got. There is a
vision for 3.11, and there is a vision for 4, and 5. For 3 and 4 we have
a fairly bold and strong philosophical line, of making as many things
work for as many people as possible. And providing the tools required in
order to move forward.

Previous release teams identified the need for tools, for atomic loading
for example, then focussed primarily on the image once more, plugging
away with the old tools, and complaining all the way about the tools.

While the pharo faction is hammering away on the core image, its roughly
the same team who years ago complained that their work was hard because
the tools (i.e. Monticello) werent good enough for the job. They also
announce... "we are going for a more modular image"... and they have no
coherent strategy or effective tools for explaining how once I have a
more modular image I can (un)load things back in again and be sure that
they will work.

For years and years and years the difficulty of doing things particularly.

1) loading stuff getting dependencies right so things work
2) writing stuff that works and is loadable in many images
3) Providing feedback to the community about what works where and what
doesnt.
4) unloading (forget it)

These have been the biggest NEEDS in the community for those of us who
are using squeak for real work. They have ALL been addressed in the
ongoing 3.11/3.x tools effort.

Another thing that has been difficult has been migrating large codebases
from one image to another because the tools were different in each
squeak version. At one time I was working on projects in 3 different
squeak versions simultaneously, while maintaining 6 further images
because of the bugs in monticello1.

I dont need a better kernel I would like one, but I dont need it (YET).
Its a complete red herring until I can build production images that work
in less than 2 weeks. (thats what it took me using universes) Without
having to email every package owner, and twist their arm to fix things
or add my fixes to their code because I am using a more recent image
than they are.

Our goals are to make things better for everyone. The pharo team have no
such goals to ensure that their wonderful improvements to the image are
as widely useful to the community as possible. Any tools they produce
are in the first instance for their image only.

Did you know that someone in the Pharo camp recently merged FileList and
FileList2. Is it just me or could that improvement be useful to
everyone, whether in etoys or croquet. There is nothing in the Pharo
mindset or toolset that enables this to happen by default.

In contrast, for us, that is our number one goal. With the work that we
have been doing for 3.11, all the tools work for all the people in
theory. With the help of Installer, Sake/Packages and LevelPlayingField,
that FileList-improved could be made available to everyone, croquet,
etoys, sophie, not only that it can be loaded atomically too. We have
and are building the TOOLS to achieve this now.

Does that example help you see the difference of what we are trying to
achieve. We can and will catch up with these "exclusive visionaries", we
can pick the best of SqueakLight/FunSqueak/Pharo, but we can do it in a
coherent, considered "for as many as possible" manner.

The 3.x era is drawing to a close, what we need is more coherence, and
stability, and better tools.

The 3.11 team has a philosophy of improving the tools for everyone. And
if you look carefully a lot has happened on the tools front in the past
18 months.

There is a coherent strategy in place, and a vision, even if that vision
is a long time in coming, it is coming

volunteers are welcome to join us on squeak irc

Keith
Hernán Morales Durand
2012-01-28 12:21:51 UTC
Permalink
Hello Keith,
Post by Keith Hodges
Did you know that someone in the Pharo camp recently merged FileList and
FileList2. Is it just me or could that improvement be useful to
everyone, whether in etoys or croquet. There is nothing in the Pharo
mindset or toolset that enables this to happen by default.
I merged FileList two weeks before I saw the open issue in the Pharo issues
list, as an excercise in a new automatic merging tool I'm writing. But
anyone feel free to take that fix and merge it into any Squeak image.

Cheers.

Hern?n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081205/dd359ea6/attachment.htm
Edgar J. De Cleene
2012-01-28 12:21:51 UTC
Permalink
Post by Hernán Morales Durand
I merged FileList two weeks before I saw the open issue in the
Pharo issues list, as an excercise in a new automatic merging tool
I'm writing. But anyone feel free to take that fix and merge it
into any Squeak image.
Cheers.
Hern?n
Where is the code ? So I put into SqueakLighthII , the only thing
working now .
3.11 ? Vaporware....

Edgar
Herbert König
2012-01-28 12:21:51 UTC
Permalink
Hello Edgar,

EJDC> 3.11 ? Vaporware....

unnecessary destructive comment.


Cheers,

Herbert
Hernán Morales Durand
2012-01-28 12:21:51 UTC
Permalink
http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20081129/58d8a9b3/FileList-0001.zip
To install:

-Remove the Morphic-FileList category.
-Evaluate:

FileStream fileIn: 'Morphic-FileList.st'.
FileStream fileIn: 'FileListNewReferences.st'
Post by Hernán Morales Durand
I merged FileList two weeks before I saw the open issue in the Pharo
issues list, as an excercise in a new automatic merging tool I'm writing.
But anyone feel free to take that fix and merge it into any Squeak image.
Cheers.
Hern?n
Where is the code ? So I put into SqueakLighthII , the only thing working
now .
3.11 ? Vaporware....
Edgar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081206/d64af58d/attachment.htm
Edgar J. De Cleene
2012-01-28 12:21:52 UTC
Permalink
Post by Hernán Morales Durand
http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/
20081129/58d8a9b3/FileList-0001.zip
-Remove the Morphic-FileList category.
FileStream fileIn: 'Morphic-FileList.st'.
FileStream fileIn: 'FileListNewReferences.st'
Very thanks, I add you to helpers.

Edgar


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081206/09c5c375/attachment.htm
Keith Hodges
2012-01-28 12:21:52 UTC
Permalink
Post by Hernán Morales Durand
Hello Keith,
Did you know that someone in the Pharo camp recently merged FileList and
FileList2. Is it just me or could that improvement be useful to
everyone, whether in etoys or croquet. There is nothing in the Pharo
mindset or toolset that enables this to happen by default.
I merged FileList two weeks before I saw the open issue in the Pharo
issues list, as an excercise in a new automatic merging tool I'm
writing. But anyone feel free to take that fix and merge it into any
Squeak image.
Cheers.
Hern?n
Dear Hern?n,

first of all I must make clear that my comment re: FileList was intended
to be entirely illustrative of the attitude, not concrete to any one
fix, or person.

Again using FileList as an easy example, of how to think about
positioning this tool for the future.

Firstly if someone were to take FileList and make it a standalone
loadable package, this would potentially contribute to every squeak
varient out there.

Secondly it would need to be refactored so that its interface to
FileDirectory is a separate package. So that in the future an
alternative to FileDirectory could be slotted in, or images that
nolonger have FileDirectory might supply their own Interface package.
Perhaps the UI could be a separate package for when the OB version, or
Morphic3 version is required.

As I said this is only an illustrative example.

Keith
Craig Latta
2012-01-28 12:22:08 UTC
Permalink
Hi Edgar--
Post by Edgar J. De Cleene
Hopes of many was when Dan say he wish be on Board.
Now I sit on his chair (because maybe nobody with better qualification
is at hand ?).
Dan left the board because he was too busy with work and his other
commitments to participate. You're on the board now because we had two
open slots (Tim had also left), and you were one of the two next highest
vote-getters in the last election.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]
Edgar J. De Cleene
2012-01-28 12:22:08 UTC
Permalink
Post by Craig Latta
Hi Edgar--
Post by Edgar J. De Cleene
Hopes of many was when Dan say he wish be on Board.
Now I sit on his chair (because maybe nobody with better
qualification
Post by Edgar J. De Cleene
is at hand ?).
Dan left the board because he was too busy with work and his
other commitments to participate.
Too bad for us.

As I said, many have the wish Dan could bring wisdom to Squeakers again
Post by Craig Latta
You're on the board now because we had two open slots (Tim had also
left), and you were one of the two next highest vote-getters in the
last election.
So , Tim and Dan go , Giovanni and me was the next on the line :=)

Next January I hope many apply for the Board and have the energy and
the charisma Squeak needs.


Edgar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081216/da794060/attachment.htm
Edgar J. De Cleene
2012-01-28 12:21:51 UTC
Permalink
Post by Herbert König
Hello Edgar,
EJDC> 3.11 ? Vaporware....
unnecessary destructive comment.
Cheers,
Herbert
Seems this point is still without a minimal consensus.

For me, Squeak is a descendant of original Smalltalk.

Any disagree ?

Because the way of Smalltalk is a image in chicken and egg cycle and any
image comes from previous one, mutating in the process.

And Smalltalk is about objects and not about scripting.

Any not sharing this should be on another list.

Also Squeak once was a wonderful fun world for all.

Children's, teachers, researchers and web developers.

I have deep respect for Pharo people, but fellows, Pharo is not Squeak and I
don't lost my time with it.

I know my SqueakLightII is not a silver bullet .
I name it SqueakLightII , because 3.11 name was taked at the time and I have
a SqueakLight before, but is really a logic step from 3.10.
Smaller and more modular.

Yesterday I have another fight on IRC with no minimal consensus.

Some say I can't made image and others could do.

Others say I should join they and I saw 3.11 folder empty, like when I
create it a long , long time ago.

We don't have more with us to
Dan , Ralph , Ned, Diego , Steph , Tim , Pavel, etc.

If I don't put some , is by lack of memory.

So Herbert , you should know me better.
I don't wish be destructive.

I wish AWAKE Squeakers.

Edgar
Igor Stasenko
2012-01-28 12:21:51 UTC
Permalink
Post by Edgar J. De Cleene
Post by Herbert König
Hello Edgar,
EJDC> 3.11 ? Vaporware....
unnecessary destructive comment.
Cheers,
Herbert
Seems this point is still without a minimal consensus.
For me, Squeak is a descendant of original Smalltalk.
Any disagree ?
Because the way of Smalltalk is a image in chicken and egg cycle and any
image comes from previous one, mutating in the process.
And Smalltalk is about objects and not about scripting.
Any not sharing this should be on another list.
Also Squeak once was a wonderful fun world for all.
Children's, teachers, researchers and web developers.
I have deep respect for Pharo people, but fellows, Pharo is not Squeak and I
don't lost my time with it.
Hmm, i see nothing fun when i loading random package from squeak map
have a 50% chance (or less) of successfull load.
And even if it loads, it could be half-working and may lead to
DNU/crash each time i using this package.
Maybe i too dumb , because i can't see how such situation can be
called wonderfull world for "children's, teachers, researchers and web
developers".
Post by Edgar J. De Cleene
I know my SqueakLightII is not a silver bullet .
I name it SqueakLightII , because 3.11 name was taked at the time and I have
a SqueakLight before, but is really a logic step from 3.10.
Smaller and more modular.
Being smaller doesn't makes it any more modular.
Post by Edgar J. De Cleene
Yesterday I have another fight on IRC with no minimal consensus.
Some say I can't made image and others could do.
Others say I should join they and I saw 3.11 folder empty, like when I
create it a long , long time ago.
We don't have more with us to
Dan , Ralph , Ned, Diego , Steph , Tim , Pavel, etc.
If I don't put some , is by lack of memory.
So Herbert , you should know me better.
I don't wish be destructive.
I wish AWAKE Squeakers.
To awake Squeakers, you should think about developers. Not childrens,
nor teachers, because they are end users.
First we should make squeak a nice living places for devs, then
developers will turn it out to nice place for the rest in the world.
Make no toys, make things for professionals, so they can easily make own toys.
And 3.11 "vaporware" is the step towards developers, as well as Pharo.
Post by Edgar J. De Cleene
Edgar
--
Best regards,
Igor Stasenko AKA sig.
Nikolay Suslov
2012-01-28 12:21:52 UTC
Permalink
Igor,
Post by Igor Stasenko
To awake Squeakers, you should think about developers. Not childrens,
nor teachers, because they are end users.
First we should make squeak a nice living places for devs, then
developers will turn it out to nice place for the rest in the world.
Make no toys, make things for professionals, so they can easily make own
Post by Igor Stasenko
toys.
And 3.11 "vaporware" is the step towards developers, as well as Pharo.
To be true,
thinking, that you have forgotten, that:

Software developer or programmer is just like a translator, and nothing
more...
Their work is to interpret the "real world problems" of "end users" into
"virtual world problems".
But they NOTHING know really about these "real world problems" and how to
solve them in "virtual world" also.
They could only translate "word by word or letter by letter" according to
the "sentences", constructed by the "end user" (like "from English to French
etc.") using different models.

SQUEAK is one of the attempts to develop the self-exploratory environment,
where "developers" could not be needed for the "end users" at all,
because "end users" are NOT "end users=impotent mans=dead users etc..", but
they are the CREATORS of their own real and virtual worlds and life.
So, Etoys is not a "toy", but the real "anti-developer-programmer" software
solution attempt, that allows "end users" to be the real CREATORS.

"To awake Squeakers", you should think about children, teachers, etc.. and
about developers, who accept the Etoy's philosophic concept at list.

Regards,
Nikolay Suslov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081207/3498a8b3/attachment.htm
Igor Stasenko
2012-01-28 12:21:52 UTC
Permalink
Post by Nikolay Suslov
Igor,
Post by Igor Stasenko
To awake Squeakers, you should think about developers. Not childrens,
nor teachers, because they are end users.
First we should make squeak a nice living places for devs, then
developers will turn it out to nice place for the rest in the world.
Make no toys, make things for professionals, so they can easily make own toys.
And 3.11 "vaporware" is the step towards developers, as well as Pharo.
To be true,
Software developer or programmer is just like a translator, and nothing
more...
Their work is to interpret the "real world problems" of "end users" into
"virtual world problems".
But they NOTHING know really about these "real world problems" and how to
solve them in "virtual world" also.
They could only translate "word by word or letter by letter" according to
the "sentences", constructed by the "end user" (like "from English to French
etc.") using different models.
SQUEAK is one of the attempts to develop the self-exploratory environment,
where "developers" could not be needed for the "end users" at all,
because "end users" are NOT "end users=impotent mans=dead users etc..", but
they are the CREATORS of their own real and virtual worlds and life.
So, Etoys is not a "toy", but the real "anti-developer-programmer" software
solution attempt, that allows "end users" to be the real CREATORS.
Well, if you find a kid, who can write a web server, search engine,
3D-modeling environment just using etoys , then we don't need to
distinguish developers/non-developers anymore.
Until that moment, we obviously should do.
Post by Nikolay Suslov
"To awake Squeakers", you should think about children, teachers, etc.. and
about developers, who accept the Etoy's philosophic concept at list.
A have nothing against Etoys. But i don't think that squeak , as
language, as environment , best and ultimately its goal was Etoys.
Etoys is done & shipped. So, lets hug each other, say bye and each go
its own road?
Or maybe there is still a lot of fun things which can be done, apart from etoys?
Post by Nikolay Suslov
Regards,
Nikolay Suslov
--
Best regards,
Igor Stasenko AKA sig.
Tim Johnson
2012-01-28 12:21:54 UTC
Permalink
Post by Igor Stasenko
Hmm, i see nothing fun when i loading random package from squeak map
have a 50% chance (or less) of successfull load.
And even if it loads, it could be half-working and may lead to
DNU/crash each time i using this package.
Maybe i too dumb , because i can't see how such situation can be
called wonderfull world for "children's, teachers, researchers and web
developers".
There was a professor at the University here who had the two Mark
Guzdial Squeak books on her shelf when I went to work on her computer,
roughly two years ago. I struck up a conversation about Squeak. I
knew already that she didn't teach Squeak in any courses here. She
said Squeak was very neat, but "very buggy." She found it hard to get
anything done because she "kept running into bugs." She sounded as if
she considered it something of a shame.

- TimJ
Herbert König
2012-01-28 12:21:52 UTC
Permalink
Hello Edgar,
Post by Herbert König
EJDC> 3.11 ? Vaporware....
unnecessary destructive comment.
...snip..

EJDC> Any not sharing this should be on another list.
hm, that is decided by who subscribes to this list.

EJDC> Also Squeak once was a wonderful fun world for all.
EJDC> Children's, teachers, researchers and web developers.
I came to Squeak 3.6 and yes that was the fascinating thing about
Squeak then. Seen (solely) from that perspective Squeak went downhill
from then to now.

But 3.7 and 3.8 brought things with them that made Squeak more
practical for me, so now I'm on 3.8.2. I saw the loss but was not
willing to do the work, so what? 3.9 and 3.10 didn't and didn't appeal
to me.

EJDC> I know my SqueakLightII is not a silver bullet .
EJDC> I name it SqueakLightII , because 3.11 name was taked at the time and I have
EJDC> a SqueakLight before, but is really a logic step from 3.10.
EJDC> Smaller and more modular.

And more of the old great projects running on it, at least your
reports say.

EJDC> We don't have more with us to
EJDC> Dan , Ralph , Ned, Diego , Steph , Tim , Pavel, etc.

Actually two things are needed: Work getting done and gathering of
followers. For SqueakLight I can only be the consumer. Consumers
don't report bugs, they turn away and take a fresh look later.

On the positive side I feel that more people have come here than have
left here. And I feel that both 3.11 and 4.0 efforts may bring us
closer to Squeak being a better base when somebody again will build
the big image with everything.

But maybe Squeak will change to being the great developer tool
envisioned by some here and the fun and play squeak will stay in a
less universal incarnation with Squeakland.

The world changes.

EJDC> So Herbert , you should know me better.
EJDC> I don't wish be destructive.

Yes I know you better but this is a public list. Calling some peoples
efforts "vaporware" is diminishing (a lot of) work that is done with
good intention and not awaking anybody.

Btw I had a lot of fun using Squeak the development tool to let a
program play Asteroids on a simulator running the original ROM of the
ca. 1980 Atari arcade game. Real great useless fun!

http://www.heise.de/ct/creativ/08/02/ergebnisse/ click on any of the
triangles, you find me on position 69, most impressive is position
17.


Cheers,

Herbert
Simon Michael
2012-01-28 12:21:52 UTC
Permalink
Post by Herbert König
Btw I had a lot of fun using Squeak the development tool to let a
program play Asteroids on a simulator running the original ROM of the
ca. 1980 Atari arcade game. Real great useless fun!
http://www.heise.de/ct/creativ/08/02/ergebnisse/ click on any of the
triangles, you find me on position 69, most impressive is position
17.
Hi Herbert.. that is pretty fun indeed. Yours plays like me except with
good aim. 17 is indeed impressive, but it's so unhuman that it's
stressful to watch! :)

It would be fun to read your code.
Herbert König
2012-01-28 12:21:53 UTC
Permalink
Hello Simon,


SM> Hi Herbert.. that is pretty fun indeed. Yours plays like me except with
SM> good aim. 17 is indeed impressive, but it's so unhuman that it's
SM> stressful to watch! :)

same link, scroll deeper, there is another table (search Squeak). If
you click on the down arrow there, you can download the image. I guess
I provided a batch (Win) and a .st to autostart.

If it contains separate sources, to not have the sources in files
discussion I filed out everything, as they required sources.
Programming language is English so you should have a chance in reading
code.

Feel free to mail me in private for more information.
--
Cheers,

Herbert
Benoit St-Jean
2012-01-28 12:21:53 UTC
Permalink
To all...

Can we, for once, take a deep breath and step back for a minute. No, we can't ALL be on the same page with the same goals, motivations and preferences. Personally, I don't care about EToys, Traits and some other-cool-things-that-I-do-not-use but I can understand some people have interests different than mine.

"This is a Pharo list now". No, Pharo has its own mailing list. But the Pharo guys are kind enough and do care about Smalltalk/Squeak enough that when they find/fix bugs that they suspect could be present in "other flavors/forks" of Squeak, they simply post it here too. Just to be nice. Just to help the "Squeak" community. "Squeak" not just as in "Squeak-dev" but more in the "larger sense", WhateverSqueak fork out there.

Personally, the more forks we have, the more chances we have to "convert" someone into Squeak, Smalltalk. The more Smalltalk (or Squeak) flavors out there, the better. Even though I never use ObjectStudio nor GNU Smalltalk, I'd never criticize or "bash" those guys because, in a sense, I feel we are in the same "community", the Smalltalkers one. The more Smalltalk grows (in directions we like or not), the more people we'll reach.

Let's not try to self-implode like a dying star here...

Diversity is cool and necessary to evolve. Besides, wasn't experimentation one of the initial goals of Squeak?!

Gentlemen, at your browsers. Let's not waste our time on details and let's flood the world with Smalltalk...

My 2 cents

-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
Blog: lamneth.wordpress.com
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081207/2489a94b/attachment.htm
Keith Hodges
2012-01-28 12:21:52 UTC
Permalink
Post by Edgar J. De Cleene
Because the way of Smalltalk is a image in chicken and egg cycle and any
image comes from previous one, mutating in the process.
Dear Edgar,

That is precisely the problem.

How many chickens lay their eggs while crossing the road. Chickens
normally sit down to lay their eggs.

How many eggs hatch while rolling down the hill? Normally they are
stationary, if not the new chick is going to get dizzy with confusion.
Post by Edgar J. De Cleene
And Smalltalk is about objects and not about scripting.
One person (a bottleneck) incrementally adding things to an image is
easy, and inevitably the image grows.

Modularizing and refactoring an image made up of interdependent parts is
harder it takes foresight and planning.

We want to empower everyone to contribute to parts of the core image in
parallel. When I work on a task (like refactoring SourceFiles for
example) I don't know how long it is going to take. What are the chances
of my efforts being ready at precisely the time that the release team is
ready to use my effort? Basically virtually zero.

So... if I can continuously integrate my work into a public (or private
to me) "unstable" release, I get to receive potential feedback as early
as possible ("fail fast = learn fast").

One other thing, when one person is incrementally tweaking the image
that everyone is relying upon there is a lot of pressure to be perfect.
This is really "not fun", it is usually quite painful (don't you know
that feeling?) This alone is perhaps responsible for the painfully slow
release cycle that squeak has had over the past few years.

In the past a new module like Rio would have to be perfect before
getting into an image, and even then it might take 2 or more years to
gain acceptance. Dare I mention Namespaces?

With this scripting approach we have a platform in which non perfect
contributions can be included in the unstable releases. You dont have to
wait for the release team to buy into your idea, you can throw it into
the unstable release, and get it seen. Then when the release team
decides not to include it you can still load your "task" if you want to,
and make it available to others. The basic release can be shipped
including "the unstable tasks" that you can apply if you want to. This
releases unstable tasks are the next releases potential stable ones.

We then have scope for planning the movement of unstable contributions
to stable ones. For some of us, we really produce our best work when we
are working in a team. But for most of us we are coding in squeak on our
own. The tools can facilitate the not yet perfect packages reaching
others who might form a team effort to knock them into shape. Matthew
and I have been doing this with Monticello15 for the past year, and it
works really well, with a well defined module. This can be extended to
the core with help from scripting and tools.

If we improve the tools with atomic loading where things can be loaded
and unloaded (more) easily we can tackle the core image where it was
harder to do before and free everyone from the tyrany of perfectionism.

Did your hero Pavel not achieve the kernel image through Scripting? I
think so!

regards

Keith
Edgar J. De Cleene
2012-01-28 12:21:52 UTC
Permalink
Post by Keith Hodges
Did your hero Pavel not achieve the kernel image through Scripting? I
think so!
Pavel magic was made a modern mammal from a dinosaur.
The point is.
I have one of this egss , no matter if he made thousands or how he do
this egss.
I go away, as now this is de-facto Pharo list.
Stay on Board as some should elected me thinking was for Squeak good.

Long life and prosper, Pharo people!

Edgar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081207/0ba690ef/attachment.htm
Andreas Raab
2012-01-28 12:21:52 UTC
Permalink
Post by Edgar J. De Cleene
I go away, as now this is de-facto Pharo list.
It is not. As a matter of fact I think that since the Etoy-Haters have
now found a place they can call home there just may be a chance to get
Squeak back to where it always belonged.

Cheers,
- Andreas
Igor Stasenko
2012-01-28 12:21:52 UTC
Permalink
Post by Edgar J. De Cleene
I go away, as now this is de-facto Pharo list.
It is not. As a matter of fact I think that since the Etoy-Haters have now
found a place they can call home there just may be a chance to get Squeak
back to where it always belonged.
One people hate Etoys, others hate Traits. :)

Then lets declare 3.8 a best software ever made and leave things as they is.
Since 3.8 is perfect, then any contribution made past 3.8 and any will
be made in future should be rejected because you can't improve what is
already perfect, right? :)
Let's then stop discussing how to improve things - because it is pointless.

There's only one thing which makes me uncomfortable: any organism
which can't evolve and can't react to ever-changing environment
adequately is doomed to become extinct.
Cheers,
- Andreas
--
Best regards,
Igor Stasenko AKA sig.
Andreas Raab
2012-01-28 12:21:53 UTC
Permalink
Post by Igor Stasenko
One people hate Etoys, others hate Traits. :)
Then lets declare 3.8 a best software ever made and leave things as they is.
How exactly are these two statements related? Why does a dislike for
traits imply that 3.8 is perfect?
Post by Igor Stasenko
Since 3.8 is perfect, then any contribution made past 3.8 and any will
be made in future should be rejected because you can't improve what is
already perfect, right? :)
Let's then stop discussing how to improve things - because it is pointless.
Is there any point to this rhetoric? If so I fail to see it.
Post by Igor Stasenko
There's only one thing which makes me uncomfortable: any organism
which can't evolve and can't react to ever-changing environment
adequately is doomed to become extinct.
And your point is...? You are the first person to propose stopping to
improve Squeak. Since I know this isn't your goal I can only guess that
you were trying to make some other point which I'm not getting.

Cheers,
- Andreas
Igor Stasenko
2012-01-28 12:21:54 UTC
Permalink
Post by Igor Stasenko
One people hate Etoys, others hate Traits. :)
Then lets declare 3.8 a best software ever made and leave things as they is.
How exactly are these two statements related? Why does a dislike for traits
imply that 3.8 is perfect?
i refer to Edgar's comment about 3.8 and what is gone 'wrong' after it.
Post by Igor Stasenko
Since 3.8 is perfect, then any contribution made past 3.8 and any will
be made in future should be rejected because you can't improve what is
already perfect, right? :)
Let's then stop discussing how to improve things - because it is pointless.
Is there any point to this rhetoric? If so I fail to see it.
Post by Igor Stasenko
There's only one thing which makes me uncomfortable: any organism
which can't evolve and can't react to ever-changing environment
adequately is doomed to become extinct.
And your point is...? You are the first person to propose stopping to
improve Squeak. Since I know this isn't your goal I can only guess that you
were trying to make some other point which I'm not getting.
My point :

Is it RIGHT to not do anything , because there is always someone who
will be discontented with it?
Cheers,
- Andreas
--
Best regards,
Igor Stasenko AKA sig.
Andreas Raab
2012-01-28 12:21:54 UTC
Permalink
Post by Igor Stasenko
How exactly are these two statements related? Why does a dislike for traits
imply that 3.8 is perfect?
i refer to Edgar's comment about 3.8 and what is gone 'wrong' after it.
I re-read Edgar's comments again but I still don't see anything in them
that could be construed as framing 3.8 as perfect or denying progress.
Edgar points out (correctly) that 3.8 was the last release that had wide
consensus, he points out (again correctly) that many of the major forks
are 3.8 based. He then goes on saying that 3.9 was "pain for all" and
concludes by pointing out that 3.10 release team was trying to play it
safe. All of it seems to be quite accurate from what I can tell.
Post by Igor Stasenko
Is it RIGHT to not do anything , because there is always someone who
will be discontented with it?
Of course not. That is so obvious it doesn't even bear mentioning. But
then again, has that ever happened? Or is that likely to happen? We have
seen constant improvements in Squeak, mostly non-controversial and in my
experience, the situations where you find great resistance are almost
exclusively those where one side is absolutely unwilling to adopt to
concerns and push things with pseudo justifications like "this is for
your own benefit". If it were, you wouldn't have to force people to use
it - you would make it accessible so that people have the option and
then, when its value is established, you can come back and make a real
case why it should be included by default. This is how the process
should have gone with traits.

Cheers,
- Andreas
Stéphane Rollandin
2012-01-28 12:21:54 UTC
Permalink
Post by Keith Hodges
We have
seen constant improvements in Squeak, mostly non-controversial and in my
experience, the situations where you find great resistance are almost
exclusively those where one side is absolutely unwilling to adopt to
concerns and push things with pseudo justifications like "this is for
your own benefit". If it were, you wouldn't have to force people to use
it - you would make it accessible so that people have the option and
then, when its value is established, you can come back and make a real
case why it should be included by default. This is how the process
should have gone with traits.
yes.

would it have happened this way, the people implementing traits may have
noticed that a lot of people did not use them simply because the tools
were not there. IMO the job has been left unfinished, and with the
traits team moving to Pharo we seem to be left with yet another leftover
mostly useless cruft in Squeak, which is the kind of thing these same
people have been creating Pharo to get rid of. how sadly ironic. it
seems to me that a lot of time, energy and good-willingness from all
sides has just been wasted.


Stef
Bert Freudenberg
2012-01-28 12:21:53 UTC
Permalink
Post by Igor Stasenko
Post by Edgar J. De Cleene
I go away, as now this is de-facto Pharo list.
It is not. As a matter of fact I think that since the Etoy-Haters have now
found a place they can call home there just may be a chance to get Squeak
back to where it always belonged.
One people hate Etoys, others hate Traits. :)
Traits are actually quite cool. I think people do not hate Traits but
just object to the way they were added to the system. A similar
objection applies to how Etoys is intertwined with Morphic, so I'd
think people don't actually hate Etoys but just that it cannot cleanly
be removed without severe breakage.

- Bert -
Greg A. Woods; Planix, Inc.
2012-01-28 12:21:54 UTC
Permalink
Post by Bert Freudenberg
Traits are actually quite cool.
Traits may be cool, and/or they may just be a fad like I think Aspect
Oriented Programming is.

However from what I can tell so far Traits are not really Smalltalk-80
at all.

I Squeak still supposed to be Smalltalk-80? Is it supposed to be
Smalltalk + Traits? Is it supposed to be a standards-compatible
Smalltalk? What is Squeak? Who definitively can answer that these
days?
Post by Bert Freudenberg
I think people do not hate Traits but just object to the way they
were added to the system.
From what I know at this moment I personally think trying to include
Traits in the core basic image, and especially any attempt to make use
of them in the basic core image, is fine just so long as you call the
result something other than Smalltalk-80.

I do not yet know how Traits have been introduced into Smalltalk, but
it is my very strong impression that the result is not compatible with
strict Smalltalk-80.

At this point I (naively) think Smalltalk with Traits _must_ be a fork
and it _must_ be called something else. I may be very wrong, and I
may be starting from the wrong impressions, but that's where my
understanding takes me to right now.

So, in that sense, I think I would object to the fact they were added
to the system, not just the way they were added to the system.

I personally would really like Squeak to be a strong, viable,
Smalltalk-80 implementation with full standards compatibility and with
a good strong community which provides add-ons, extensions, and such
as additional packages. Perhaps for a poor analogy, Squeak should be
the equivalent of the Linux kernel in GNU/Linux systems, thus allowing
for variant distributions which might ship ready-to-run images which
contain specific sets of pre-loaded packages and modifications, but
which hopefully all derive from the same core image and VM. A
slightly better analogy might be the full NetBSD (or FreeBSD) core
OS. It's a full base operating system (not just a kernel), but there
are thousands of additional add-on packages available to any user.
Even X11 is often considered to be just an add-on package.
--
Greg A. Woods; Planix, Inc.
<***@planix.ca>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081207/60f13eb0/PGP.pgp
Keith Hodges
2012-01-28 12:21:54 UTC
Permalink
Post by Greg A. Woods; Planix, Inc.
Post by Bert Freudenberg
Traits are actually quite cool.
Traits may be cool, and/or they may just be a fad like I think Aspect
Oriented Programming is.
However from what I can tell so far Traits are not really Smalltalk-80
at all.
I Squeak still supposed to be Smalltalk-80? Is it supposed to be
Smalltalk + Traits? Is it supposed to be a standards-compatible
Smalltalk? What is Squeak? Who definitively can answer that these days?
As far as I am aware Traits are just an implementation detail as far as
Smalltalk-80 compatability is concerned. They may effect the users
ability to understand existing code structure, and provide additional
options for structuring code. Essentially though Traits are transparent
to 99% of client code.

Keith
David Mitchell
2012-01-28 12:21:54 UTC
Permalink
I personally would really like Squeak to be a strong, viable, Smalltalk-80
implementation with full standards compatibility and with a good strong
community which provides add-ons, extensions, and such as additional
packages.
Of course, *that* would itself be a fork. Squeak has always been about
experimentation and Smalltalk-80 compatibility was more of a
historical artifact than a design goal.

I'd rather have a great Smalltalk-08 (and soon -09) than something
that matches up with the Blue Book description of Smalltalk-80. The
reason I'm using Pharo now is that it looks like the best near term
'core' Smalltalk.
Michael Haupt
2012-01-28 12:21:52 UTC
Permalink
Hi Edgar,

On Sun, Dec 7, 2008 at 10:59 AM, Edgar J. De Cleene
Post by Edgar J. De Cleene
I go away, as now this is de-facto Pharo list.
I absolutely don't share that impression. There are many many threads
that don't deal with Pharo.

Best,

Michael
Edgar J. De Cleene
2012-01-28 12:21:52 UTC
Permalink
Post by Andreas Raab
It is not. As a matter of fact I think that since the Etoy-Haters have
now found a place they can call home there just may be a chance to get
Squeak back to where it always belonged.
Cheers,
- Andreas
Andreas, you should take the challenge now.
Nobody could say you don't know Squeak in deep as they could say to me.

I tired of no progress, only read about ideas but no evidence of going in
the good direction.

The last good Squeak release with wide consensus was 3.8

Then come people who for his own (maybe good) purposes introduce Traits.
You always said and I support still no evidence Traits give us some we don't
could made with good Smalltalk.
And introduce the troubles.
Almost all major forks is no Traits (3.8) based.

They have a good point in start to "packaging" the image and introduce
Monticello as way of start to made downloadable packages.

3.9 was a pain for all, but give a way to start to download packages and
load again.

That's was 3.10, and we don't move more out because we wish play safe.

The goal for me is going to MorphicCore Pavel made.

But as MorphicCore exist today, don't run and is only for study (sorry
Pavel)

I always said the most long shot is Spoon or whatever we call it.

But if nobody take the trouble to see how to go from existent Monticello and
current image to smaller and modular, never we could reach any of it.

I do my best, sometimes good and sometimes bad.

Try to help newbies and try to keep as fun as possible.

Who think Web 2.0 is incompatible with "old Squeak" was wrong.

I put SLWeb on ftp as soon I test and prove any could load Etoys , mp3 and
all web we have now (Aida - Seaside - HV2) on top of SqueakLightII.

Scripting people always could script it if they wish.

Edgar
Michael Haupt
2012-01-28 12:21:52 UTC
Permalink
Hi Edgar,

On Sun, Dec 7, 2008 at 12:57 PM, Edgar J. De Cleene
Post by Edgar J. De Cleene
The last good Squeak release with wide consensus was 3.8
what's "good"? (Rhetoric question. *Please* don't answer. I *think* I
get your point.)

About consensus: oh please, that's frankly not possible. Once a
certain critical mass in community participation has been reached, it
is almost inevitably the case that there are digressions, branches,
and so on.
Post by Edgar J. De Cleene
Then come people who for his own (maybe good) purposes introduce Traits.
You always said and I support still no evidence Traits give us some we don't
could made with good Smalltalk.
And introduce the troubles.
I agree that traits should have been optional. That said, I recently
made ContextS work in Squeak 3.10, and yon traits weren't painful.
Then again, maybe I just didn't have to touch the "right" places...

Best,

Michael
Keith Hodges
2012-01-28 12:21:52 UTC
Permalink
Edgar,

The whole ethos behind 3.11 is to provide a framework for people to
contribute.

If we get that right progress is assured. I admit I myself have had some
hiccups, I have had domestic problems, and lots of deadlines in my day
job. BUT, in a framework where people are encouraged and enabled to
contribute that shouldn't matter.

PROGRESS HAS CONTINUALLY BEEN MADE by someone somewhere, its just a
matter of harnessing it.

I am left with a huge sense of irony, given that the whole ethos behind
3.11 is to provide a framework for people to contribute:

Irony no. 1, the entire Pharo team create a fork. Benefit, Pharo guys
get to do R&D for us to "acquire" later, iff we can persuade them to be
co-operative (i.e. use similar tools and apis)

Irony no. 2 -

I have tried and tried and tried, to encourage you, ask you persuade
you, to bring your expertise and contribute, but you will not. You
absolutely refuse.

You have expertise in unloading bits of squeak into separate packages. I
hate grovelling around looking for obsolete references. You have already
done the work. All that needs to happen is to package your work into
discrete #unload tasks, and Sake/Packages &/ Universes load tasks

If a project whose goal is to encourage people to contribute cannot get
people to contribute then it is doomed from the start.
Post by Edgar J. De Cleene
Andreas, you should take the challenge now.
Nobody could say you don't know Squeak in deep as they could say to me.
I tired of no progress,
I am fed up with you saying there is no progress. I do paid work in
squeak, and from that perspective there has been LOTS of progress. In
some ways Squeak was painful to use for commercial work. I used to
dread building up an image from scratch for a new client project, and it
was impossible to code several client projects simultaneously in one
image (due to MC bugs).
I am approaching the point where I can code all of my client projects in
one image, and automatically deploy to separate images for each client.

Things are getting much better than they were a year ago and as soon as
"Bob the Builder" is ready there will be a whole lot more progress.

LevelPlayingField - is a huge bonus
Monticello - 100's of fixes, huge speed improvements, Files support (I
announced yesterday)
Sake/Packages - Actually does work
Sake - Simple but ultimately very powerful.
Tasks - Framework for organising 3.11
Pharo - R&D for Squeak 3.1x
FunSqueak - R&D for Sake/Packages
SqueakLightII - R&D for Squeak3.1x
Post by Edgar J. De Cleene
only read about ideas but no evidence of going in
the good direction.
But Edgar you have decided in advance not to be interested. You take one
look at the fact I embed small scripts in Mantis bug reports and you
refuse to contribute even there. You have never contributed one script.
Have you ever loaded a fix using Installer mantis ensureFix: 474 ? It is
actually very useful.

You tell me that all these guru people should be listened to, at the
same time you tell me I am not worth listening to. I have been coding
for 32 years, you never know I might know something after all, you might
learn something. Sorry I am not a professor in an academic ivory tower,
I am a pragmatic programmer, and for me perfectionism gives way to
pragmatism.

This means that I appreciate the need for TEAM, I cannot do it on my
own. Matthew has been a huge help to me, dotting i's and crossing t's. I
wrote the code for atomic loading in Monticello 1.6 in December 2007.
Colin wrote the code for SystemEditor long before that. It is Matthew
who has had the patience to get SystemEditor to work as required through
painstakingly careful testing. So the irony no.1 is that many potential
team members have gone off to pharo, the irony number 2 is that other
potential team members are hankering after the same old way of doing
things and have dug their heals in.

Sure I might be wrong, and if I am, I would be happy to be shown a
better way. For 3 years the community has talked about a better way
would be led by improved tools, and greater modularity. Meanwhile
release teams have soldiered on declaring that "We are not going to
develop anything, just integrate what the community gives us". The
community has lacked the tools to give the release teams what they were
asking for. The lead time for a new bit of code to get into the image is
probably on average 3 years in a good year.

3.11 might look a bit slow of the mark, and I have my fair share of
excuses. BUT we are actually coding stuff, and coding stuff takes a bit
more time than cherry picking code that is already out there.

To be honest, all of my code works in 3.7, so from the pragmatic
perspective, the huge efforts put in by 3.8 3.9 and 3.10 teams to give
us incremental changes has not really been that radical, or even useful.
So from a pragmatic sense if 3.11 follows the same... "One person load a
few fixes and release an image" ethos, it is valueless to me.

At one point the Board/Oversight Team/Leaders(?) recognized this, and
felt that the effort was better spent on something radically new (i.e.
Spoon). I campaigned for 3.11 to go ahead because I knew we had a lot to
harness that would be really useful, and would be potentially be lost if
we didn't do it, not because I wanted 50 more random fixes in my image.

In contrast the ... "harness lots of creativity from lots of people, and
enable as much stuff to work as possible for everyone" ethos behind 3.11
will give me benefits, it will, and already has given me lots more
things to play with.

It is well known that technical projects never fail due to technical
reasons. Politics is always the make or break of any software, and I
dont do politics, I cant see much point in tact or diplomacy. If we fail
to make progress, I will blame the politicians.

Now you are on the board Edgar, that makes you a politician.
Post by Edgar J. De Cleene
The last good Squeak release with wide consensus was 3.8
Which is a fact of life
Post by Edgar J. De Cleene
Then come people who for his own (maybe good) purposes introduce Traits.
You always said and I support still no evidence Traits give us some we don't
could made with good Smalltalk.
And introduce the troubles.
Almost all major forks is no Traits (3.8) based.
And Matthew has done the work to make this a non-issue.
Post by Edgar J. De Cleene
But if nobody take the trouble to see how to go from existent Monticello and
current image to smaller and modular, never we could reach any of it.
Perhaps I should change my name to "Nobody"
Post by Edgar J. De Cleene
I do my best, sometimes good and sometimes bad.
Scripting people always could script it if they wish.
and Image tweaking people can always Image tweak if they wish. But their
work is more difficult to harness and cross fertilize between forks and
different sectors of the community. They have no ethos of desiring it to
be possible, and no means to transact it.

In contrast the scripting side of arguement goes like this:

3.11 is generated by a series of scripted tasks, but that script is
modular in such a way as to be useful to another fork, say Sophie. i.e.
we actively view other forks as part of the same moving forward process.
We support them, we don't leave them out on their own.

They can take a copy or a specialised subclass of the 3.11 set of tasks,
and apply them to their next release.

If all the forks, apply their core improvements via a common set of
tasks, and packages. And if all the forks use a common set of tools to
organise their work. Then they will naturally converge where it is most
important, where there is the most overlap.

There is a vision for the politicians to think about

best regards

Keith
Edgar J. De Cleene
2012-01-28 12:21:52 UTC
Permalink
Post by Keith Hodges
Now you are on the board Edgar, that makes you a politician.
Ja !
Am I wrong think you don't have fun !

Me politics ? Saying yes to nonsense ?

It's the best joke of this year.

I was reluctant to be on Board, remember ?

But as bad soap opera film say, until some better guy come, I do my
best.

No more mails, I read The Weekly Squeak from now

Edgar


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081207/d2938988/attachment.htm
Matthew Fulmer
2012-01-28 12:21:53 UTC
Permalink
Post by Edgar J. De Cleene
Post by Keith Hodges
Now you are on the board Edgar, that makes you a politician.
Ja !
Am I wrong think you don't have fun !
Me politics ? Saying yes to nonsense ?
It's the best joke of this year.
I was reluctant to be on Board, remember ?
But as bad soap opera film say, until some better guy come, I do my
best.
If you don't want to be on the board, then resign and let me. I
think I'm the next candidate by votes
--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Bert Freudenberg
2012-01-28 12:21:53 UTC
Permalink
Post by Herbert König
Edgar,
The whole ethos behind 3.11 is to provide a framework for people to
contribute.
If we get that right progress is assured. I admit I myself have had some
hiccups, I have had domestic problems, and lots of deadlines in my day
job. BUT, in a framework where people are encouraged and enabled to
contribute that shouldn't matter.
PROGRESS HAS CONTINUALLY BEEN MADE by someone somewhere, its just a
matter of harnessing it.
I am left with a huge sense of irony, given that the whole ethos behind
Irony no. 1, the entire Pharo team create a fork. Benefit, Pharo guys
get to do R&D for us to "acquire" later, iff we can persuade them to be
co-operative (i.e. use similar tools and apis)
Irony no. 2 -
I have tried and tried and tried, to encourage you, ask you persuade
you, to bring your expertise and contribute, but you will not. You
absolutely refuse.
You have expertise in unloading bits of squeak into separate
packages. I
hate grovelling around looking for obsolete references. You have already
done the work. All that needs to happen is to package your work into
discrete #unload tasks, and Sake/Packages &/ Universes load tasks
If a project whose goal is to encourage people to contribute cannot get
people to contribute then it is doomed from the start.
Post by Edgar J. De Cleene
Andreas, you should take the challenge now.
Nobody could say you don't know Squeak in deep as they could say to me.
I tired of no progress,
I am fed up with you saying there is no progress. I do paid work in
squeak, and from that perspective there has been LOTS of progress. In
some ways Squeak was painful to use for commercial work. I used to
dread building up an image from scratch for a new client project, and it
was impossible to code several client projects simultaneously in one
image (due to MC bugs).
I am approaching the point where I can code all of my client
projects in
one image, and automatically deploy to separate images for each client.
Things are getting much better than they were a year ago and as soon as
"Bob the Builder" is ready there will be a whole lot more progress.
LevelPlayingField - is a huge bonus
Monticello - 100's of fixes, huge speed improvements, Files support (I
announced yesterday)
Sake/Packages - Actually does work
Sake - Simple but ultimately very powerful.
Tasks - Framework for organising 3.11
Pharo - R&D for Squeak 3.1x
FunSqueak - R&D for Sake/Packages
SqueakLightII - R&D for Squeak3.1x
Post by Edgar J. De Cleene
only read about ideas but no evidence of going in
the good direction.
But Edgar you have decided in advance not to be interested. You take one
look at the fact I embed small scripts in Mantis bug reports and you
refuse to contribute even there. You have never contributed one script.
Have you ever loaded a fix using Installer mantis ensureFix: 474 ? It is
actually very useful.
You tell me that all these guru people should be listened to, at the
same time you tell me I am not worth listening to. I have been coding
for 32 years, you never know I might know something after all, you might
learn something. Sorry I am not a professor in an academic ivory tower,
I am a pragmatic programmer, and for me perfectionism gives way to
pragmatism.
This means that I appreciate the need for TEAM, I cannot do it on my
own. Matthew has been a huge help to me, dotting i's and crossing t's. I
wrote the code for atomic loading in Monticello 1.6 in December 2007.
Colin wrote the code for SystemEditor long before that. It is Matthew
who has had the patience to get SystemEditor to work as required through
painstakingly careful testing. So the irony no.1 is that many
potential
team members have gone off to pharo, the irony number 2 is that other
potential team members are hankering after the same old way of doing
things and have dug their heals in.
Sure I might be wrong, and if I am, I would be happy to be shown a
better way. For 3 years the community has talked about a better way
would be led by improved tools, and greater modularity. Meanwhile
release teams have soldiered on declaring that "We are not going to
develop anything, just integrate what the community gives us". The
community has lacked the tools to give the release teams what they were
asking for. The lead time for a new bit of code to get into the image is
probably on average 3 years in a good year.
3.11 might look a bit slow of the mark, and I have my fair share of
excuses. BUT we are actually coding stuff, and coding stuff takes a bit
more time than cherry picking code that is already out there.
To be honest, all of my code works in 3.7, so from the pragmatic
perspective, the huge efforts put in by 3.8 3.9 and 3.10 teams to give
us incremental changes has not really been that radical, or even useful.
So from a pragmatic sense if 3.11 follows the same... "One person load a
few fixes and release an image" ethos, it is valueless to me.
At one point the Board/Oversight Team/Leaders(?) recognized this, and
felt that the effort was better spent on something radically new (i.e.
Spoon). I campaigned for 3.11 to go ahead because I knew we had a lot to
harness that would be really useful, and would be potentially be lost if
we didn't do it, not because I wanted 50 more random fixes in my image.
In contrast the ... "harness lots of creativity from lots of people, and
enable as much stuff to work as possible for everyone" ethos behind 3.11
will give me benefits, it will, and already has given me lots more
things to play with.
It is well known that technical projects never fail due to technical
reasons. Politics is always the make or break of any software, and I
dont do politics, I cant see much point in tact or diplomacy. If we fail
to make progress, I will blame the politicians.
Now you are on the board Edgar, that makes you a politician.
Post by Edgar J. De Cleene
The last good Squeak release with wide consensus was 3.8
Which is a fact of life
Post by Edgar J. De Cleene
Then come people who for his own (maybe good) purposes introduce Traits.
You always said and I support still no evidence Traits give us some we don't
could made with good Smalltalk.
And introduce the troubles.
Almost all major forks is no Traits (3.8) based.
And Matthew has done the work to make this a non-issue.
Post by Edgar J. De Cleene
But if nobody take the trouble to see how to go from existent
Monticello and
current image to smaller and modular, never we could reach any of it.
Perhaps I should change my name to "Nobody"
Post by Edgar J. De Cleene
I do my best, sometimes good and sometimes bad.
Scripting people always could script it if they wish.
and Image tweaking people can always Image tweak if they wish. But their
work is more difficult to harness and cross fertilize between forks and
different sectors of the community. They have no ethos of desiring it to
be possible, and no means to transact it.
If you mean the Etoys image with that comment - we simply chose the
most efficient way for us to deliver. We were 5 people, most of them
not even working full-time on Etoys. We have an installed user base of
at least 500,000. We have to be careful about backwards compatibility.
Doing this while trying to keep in sync through 3.9, 3.10, etc., would
frankly have put the whole project in jeopardy. OTOH we tried to break
out the separable functionality so it can be used in other projects -
e.g., the DBus support, GStreamer support, which are maintained as
Monticello packages.

I for one would love to see Etoys being maintained in sync with (or
even inside) the squeak.org version, and now that the pace of
development has slowed down on the Etoys side this might even be
feasible. However, since Etoys never was a community-driven scratch-
your-own-itch project, somebody would have to come forward declaring
it his own itch (like Marcus and Michael did in 3.8). Recently I've
only seen Edgar express interest in that direction.
Post by Herbert König
3.11 is generated by a series of scripted tasks, but that script is
modular in such a way as to be useful to another fork, say Sophie. i.e.
we actively view other forks as part of the same moving forward process.
We support them, we don't leave them out on their own.
They can take a copy or a specialised subclass of the 3.11 set of tasks,
and apply them to their next release.
If all the forks, apply their core improvements via a common set of
tasks, and packages. And if all the forks use a common set of tools to
organise their work. Then they will naturally converge where it is most
important, where there is the most overlap.
There is a vision for the politicians to think about
best regards
Keith
I like your vision, and the progress you are making :)

- Bert -
Keith Hodges
2012-01-28 12:21:53 UTC
Permalink
Post by Bert Freudenberg
Post by Keith Hodges
Post by Edgar J. De Cleene
Scripting people always could script it if they wish.
and Image tweaking people can always Image tweak if they wish. But their
work is more difficult to harness and cross fertilize between forks and
different sectors of the community. They have no ethos of desiring it to
be possible, and no means to transact it.
If you mean the Etoys image with that comment - we simply chose the
most efficient way for
Not at all, "image tweaking" is the standard way of doing things, and it
is the most efficient way of developing an end product. No pesky scm,
packaging and module distribution issues.

All release teams, pharo, edgar etoys, croquet, etc have been moving
forward by imcrementally changing the image. (Sophie had a build
process, as does Gjallar)

All 3.11 aims to do differently is to increment the image in larger
discrete (but not two big) crafted steps, that forks can potentially share.
Post by Bert Freudenberg
us to deliver. We were 5 people, most of them not even working
full-time on Etoys. We have an installed user base of at least
500,000. We have to be careful about backwards compatibility. Doing
this while trying to keep in sync through 3.9, 3.10, etc., would
frankly have put the whole project in jeopardy.
Quite right. That illustrates my point, working with a moving target is
not easy, and not desirable.
Post by Bert Freudenberg
OTOH we tried to break out the separable functionality so it can be
used in other projects - e.g., the DBus support, GStreamer support,
which are maintained as Monticello packages.
I for one would love to see Etoys being maintained in sync with (or
even inside) the squeak.org version, and now that the pace of
development has slowed down on the Etoys side this might even be
feasible. However, since Etoys never was a community-driven
scratch-your-own-itch project, somebody would have to come forward
declaring it his own itch (like Marcus and Michael did in 3.8).
Recently I've only seen Edgar express interest in that direction.
That's why it is such a shame that Edgar will not come out and play
today, and believe me I have tried.
Post by Bert Freudenberg
I like your vision, and the progress you are making :)
Thanks... I trust we can pull this off.

Keith

p.s. Rob - I do seaside mostly, and interfacing to business accounts.
Rob Rothwell
2012-01-28 12:21:53 UTC
Permalink
Post by Keith Hodges
p.s. Rob - I do seaside mostly, and interfacing to business accounts.
Thanks...good to know people are out there having success with Squeak!

Take care,

Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20081207/ea794b67/attachment.htm
Claus Kick
2012-01-28 12:21:53 UTC
Permalink
Post by Keith Hodges
Not at all, "image tweaking" is the standard way of doing things, and it
is the most efficient way of developing an end product. No pesky scm,
packaging and module distribution issues.
How do you deliver the end product then?
I hope not a stripped developer image? :)
Keith Hodges
2012-01-28 12:21:53 UTC
Permalink
Post by Claus Kick
Post by Keith Hodges
Not at all, "image tweaking" is the standard way of doing things, and it
is the most efficient way of developing an end product. No pesky scm,
packaging and module distribution issues.
How do you deliver the end product then?
I hope not a stripped developer image? :)
For details - http://installer.pbwiki.com/Squeak311Proposal

The build process produces a "test-candidate" image.

The "test-candidate" is processed into a "release-candidate" image via:

1) All packages are saved to the monticello repository 2) some tools
used in building may be removed 3) version is updated.

The release, the basic image will be fairly functional, elements that
are optional will be easily unloaded. i.e. rather than produce a minimal
image that can be built into a basic image, we will produce a basic
image that can be reduced to a minimal image using Sake/Packages unload
tasks, after which Sake/Packages itself can be unloaded. Rather than
produce an image in which traits are loadable (this would prevent the
core from using traits), we will have an image in which traits are
removable/flattenable.

Derivative images, automatically built from release-basic

1. -test - basic with tests loaded
2. -minimal - basic with all removable packages removed, including
LPF, Sake, Installer etc.
3. -kernel - Pavel's shrink script applied perhaps?
4. -full/fun - (fun squeak? Edgar?)
5. -dev - Squeak-dev (Damien is moving over to use Sake/Packages to
build)
6. -web - Squeak-web
7. -dev-beta - Squeak-dev beta
8. -web-beta - Squeak-web beta
9. -seaside - The seaside one-click-experience
10. -seaside-magma-pier-magritte-scriptaculous - The basis of my own work
11. -morphic3 experimental platform

ambitious do you think?

Keith
Loading...