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

Hello Edgar,


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

Hernán Morales Durand wrote: 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

Herbert König wrote:
> 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.

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

El 12/7/08 7:09 AM, "Andreas Raab" <[hidden email]> escribió:

> 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

Hi Edgar,

On Sun, Dec 7, 2008 at 10:59 AM, Edgar J. De Cleene
<[hidden email]> wrote:
> 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

Hi Edgar,

On Sun, Dec 7, 2008 at 12:57 PM, Edgar J. De Cleene
<[hidden email]> wrote:
> 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.

> 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

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.
> 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
> 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.
> The last good Squeak release with wide consensus was 3.8
>  
Which is a fact of life
> 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.
> 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"
> 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

Igor,



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

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

2008/12/7 Nikolay Suslov <[hidden email]>:
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.

> "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?


> Regards,
> Nikolay Suslov
>


--
Best regards,
Igor Stasenko AKA sig.

On 07.12.2008, at 14:29, Keith Hodges wrote:

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.


I like your vision, and the progress you are making :)

- Bert -

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.
> 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. That's why it is such a shame that Edgar will not come out and play
today, and believe me I have tried.
>
> 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.

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                                        

Keith Hodges wrote:

Sorry to interfere with this, but this statement is puzzling me:

> 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? :)