[squeak-dev] FractalMorph 1.2 won't load into 3.10.2-7179

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.
                                        <[hidden email]>

On 04/12/2008, at 23:42, Greg A. Woods; Planix, Inc. wrote:


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

Edgar J. De Cleene wrote:
> 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

Andreas Raab wrote: I suggested this months and months ago, the
[hidden email] 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.

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.
                                        <[hidden email]>

Hear, hear.  This has the makings of a manifesto.  Thus I have quoted  
it in its entirety :)

- TimJ


On Dec 5, 2008, at 1:32 PM, Greg A. Woods; Planix, Inc. wrote:

+ 1

Stef

Pharo is active and producing the Smalltalk that I always wanted.

On Fri, Dec 5, 2008 at 3:12 PM, Edgar J. De Cleene
<[hidden email]> wrote:

2008/12/5 David Mitchell <[hidden email]>:
> 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.

Edgar J. De Cleene wrote: 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

Igor Stasenko wrote: Well said that man!

+10

Keith
> - 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)
>  
My point exactly - watch this space

Hello Keith,

Cheers.

Hernán

On 05/12/2008, at 22:20, Hernán Morales Durand wrote:

> 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

Hello Edgar,

EJDC> 3.11 ? Vaporware....

unnecessary destructive comment.


Cheers,

Herbert                                        

El 12/6/08 8:20 AM, "Herbert König" <[hidden email]> escribió:


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

2008/12/6 Edgar J. De Cleene <[hidden email]>: 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".

> 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.
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.

> Edgar
>


--
Best regards,
Igor Stasenko AKA sig.

http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20081129/58d8a9b3/FileList-0001.zip