[squeak-dev] Squeak 4

I've been needing to use spoon for my research project this
summer, and now that the board has (finally) officially decided
to base Squeak 4 on spoon, can I expect that there will be a
downloadable spoon soon? as in, 2 weeks?

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

 > I've been needing to use spoon for my research project this
 > summer, and now that the board has (finally) officially decided
 > to base Squeak 4 on spoon, can I expect that there will be a
 > downloadable spoon soon? as in, 2 weeks?

      Yes.


-C

Matthew Fulmer wrote:
> I've been needing to use spoon for my research project this
> summer, and now that the board has (finally) officially decided
> to base Squeak 4 on spoon, can I expect that there will be a
> downloadable spoon soon? as in, 2 weeks?

Interesting. I didn't even know that discussion was on ;-) Can the board
recap the high points of the discussion here and let the rest of us know
what tipped the decision in favor of Spoon instead of some alternative
direction?

Cheers,
   - Andreas

Agree with Andreas.


2008/7/1 Andreas Raab <[hidden email]>:

      Matthew writes:

 > I've been needing to use spoon for my research project this summer,
 > and now that the board has (finally) officially decided to base Squeak
 > 4 on spoon, can I expect that there will be a downloadable spoon soon?
 > as in, 2 weeks?

      Andreas responds:

 > Interesting. I didn't even know that discussion was on ;-)

      Yeah, we discussed it at the last board meeting. We decided I
would post an introductory message about the Squeak 4 effort to
squeak-dev, after which Tim would post the meeting notes. Apparently
Randal mentioned this a few days ago on the Squeak IRC channel (BAD
Randal! :).

      I'm currently vetting a draft of that message with the rest of the
board, and getting that Spoon release out. For those keeping score, that
means the order is Spoon release, Squeak 4 announcement, meeting notes.
Oh what a lovely surprise it will be! ;)

 > Can the board recap the high points of the discussion here and let the
 > rest of us know what tipped the decision in favor of Spoon instead of
 > some alternative direction?

      Yep, that's in there.

      I'm as annoyed as anyone at the timescales, which is why I just
took off from work for the rest of the week to do this. I'm shooting for
next Tuesday.


      thanks,

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

No worries. Take your time.

Cheers,
   - Andreas

Craig Latta wrote:

Same here. But don't feel pushed by me please I want to be informed due to its
importance but I have no complains ok?
All the best,

Sebastian Sastre


 

>>>>> "Craig" == Craig Latta <[hidden email]> writes:

Craig>  Apparently Randal mentioned this a few days ago on the Squeak IRC
Craig> channel (BAD Randal! :).

Well, if you had kept your timeline, it all would have played together.  So
consider this a slap for not doing that.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Thanks by the comments Craig.


2008/7/1 Craig Latta <[hidden email]>:

Matthew Fulmer wrote:

> and now that the board has (finally) officially decided
> to base Squeak 4 on spoon

Are there any news on this?

Hi--

      Matthew Fulmer wrote:

 > ...and now that the board has (finally) officially decided to base
 > Squeak 4 on spoon...

      Markus Fritsche responded:

 > Are there any news on this?

      I'm adapting Naiad (Spoon's module system) to the minimal object
memory, then folks can start creating modules from existing licensed code.


      thanks,

-C

Craig Latta wrote:

>      I'm adapting Naiad (Spoon's module system) to the minimal object
> memory, then folks can start creating modules from existing licensed code.

So, for my understanding, there are some main threads within the squeak
community...

I read (a bit) about the sapphire/ pharo events.

Stef et al are reimplementing the smalltalk kernel by tailoring taking a
squeak 3.10 image, tailoring it to a 'known working'-non-etoys image,
experimenting with the kernel image with non graphics, taking the
file-ins for the sunit test of the 3.x images making them work (and, for
instance, making the ColorTest>>#testPrintHtmlString test work by
implementing a cleanroom implementation of Color>>#printHtmlSting) and
finally targetted to support "Universe loads". The goal is to transform
the tools and methods provided by squeak, squeakvm etc. to an
environment where 'low-level-code' (i.e. the compiler) does not rely on
'high-level-code' (i. e., graphics, browser).

Naiad, (or Spoon, as I have seen it) relies on 'imprinting' and
'unification'. A Naiad system will be basically build up by running test
which pull the necessary functionality 'automagically' from a providing
project. This means, whenever a class behaviour, a class instance
behaviour, pool dictionaries, etc. are accessed, Naiad pulls the
necessary things from a complete image, making sure that all needed
behaviour for a target system has been pulled by complete tests (Oh well
- erm - I am most probably horribly wrong, so please correct me!).
Everything named by the developer with a string will be uuid'ed, which
means that uuids will be the id, followed by the name if not resolvable.

Both approaches share the license-clean approach. So if I'd like to
provide fixes, code, implementation ideas to these, I'll have to sign a
license agreement that my changes to-be-contributed will be MIT-licensed
as this is the license to go, as it serves the smalltalk-squeak freedom
to be used both in closed-source-distributed-images and
open-source-distributed-images... right!? (Please correct me if I'm wrong).

I am just revisting squeak/ smalltalk/ et al and as there are no "Zack's
squeak news", it's very hard to assess the recent developments. And it's
not easy to paraphrase my (probably wrong) findings without being
insulting too, I think :-(

Kind regards,
  Markus

Hi Markus,

Just a few clarifications...

On Sep 30, 2008, at 22:29 , Markus Fritsche wrote:

> Craig Latta wrote:
>
>>     I'm adapting Naiad (Spoon's module system) to the minimal object
>> memory, then folks can start creating modules from existing  
>> licensed code.
>
> So, for my understanding, there are some main threads within the  
> squeak
> community...

Pharo is a fork of Squeak, and its getting more and more independent.  
That is, its not "a thread *within* Squeak".

> I read (a bit) about the sapphire/ pharo events.
>
> Stef et al are reimplementing the smalltalk kernel by tailoring  
> taking a
> squeak 3.10 image, tailoring it to a 'known working'-non-etoys image,

[...]

Pharo is based on Squeak 3.9, not 3.10.
We don't re-implement the kernel, at least not for now. The current  
focus is on cleaning up and removing stuff we are not interested in  
(like toys), and providing a stable basis for professional use.

Cheers,
Adrian


___________________
http://www.adrian-lienhard.ch/

Hi Markus--

 > Naiad, (or Spoon, as I have seen it)...

      Spoon is the working name for the whole system, Naiad is the
module system part.

 > ...relies on 'imprinting' and 'unification'. A Naiad system will be
 > basically build up by running test which pull the necessary
 > functionality 'automagically' from a providing project.

      We could do things this way, but I suspect most authors will do a
lot of manual fine-tuning, to make sure that their modules contain
exactly what they intend and nothing else. Imprinting really comes into
play when a finished module is transferred between one live system and
another.

 > Everything named by the developer with a string will be uuid'ed, which
 > means that uuids will be the id, followed by the name if not
 > resolvable.

      Every version of every module, author, class, and metaclass has a
UUID. Methods are uniquely identified by a combination of a class or
metaclass version and a selector. Names are never needed to transfer
behavior between systems.

 > Both approaches share the license-clean approach. So if I'd like to
 > provide fixes, code, implementation ideas to these, I'll have to sign
 > a license agreement that my changes to-be-contributed will be
 > MIT-licensed as this is the license to go, as it serves the
 > smalltalk-squeak freedom to be used both in
 > closed-source-distributed-images and open-source-distributed-images...
 > right!? (Please correct me if I'm wrong).

      You'll need to have signed and returned the Squeak project
contributor's agreement to have your code included in the official
Squeak releases, and the agreement is MIT-style, yes.


      thanks again,

-C

Adrian Lienhard schrieb:

> Just a few clarifications...

Merci!

> Pharo is a fork of Squeak, and its getting more and more independent.
> That is, its not "a thread *within* Squeak".

This will mean, judging by mission statement, that Pharo most probably
will develop into a direction where there will be a filein for Pharo and
a filein for squeak, right?

Otoh, Pharo is (for now) concentrated on the smalltalk side, right? So
Pharo and Squeak will share the same VM since Pharo is not targetted at
the VM/ primitives development?

I see that the Pharo-One-Click-Experience (those get popular lately,
don't they?) does use the icon of the seaside-one-click-vm.

How does "Flow" fit into this? For my understanding, Naiad is
'Flow-based', that means, a whole new primitive-based approach for
networking/ streaming.

How will this influence the development between Pharo/ Squeak 4?

> Pharo is based on Squeak 3.9, not 3.10.

Thx

> We don't re-implement the kernel, at least not for now. The current
> focus is on cleaning up and removing stuff we are not interested in
> (like toys), and providing a stable basis for professional use.

Well, I mixed "kernel" and "image" here I think.

Thank you for your clarification.

Either way, there will be a transformation from
"change-file-loading-emergency-valuator" to "install-to-your-needs", I'm
sure.

It is good to see the active community and have the certainty that
skilled people will take part in both approaches, providing the lessons
learned from the one "base" to the other.

 > How does "Flow" fit into this? For my understanding, Naiad is
 > 'Flow-based', that means, a whole new primitive-based approach for
 > networking/ streaming.

      I wrote Naiad using Flow, but it's just another networking
application. Someone else could adapt it to some other networking
framework. I don't see this as a big issue.


-C

Craig Latta schrieb:

I'm sorry if I'm annoying ;-)

>      Every version of every module, author, class, and metaclass has a
> UUID. Methods are uniquely identified by a combination of a class or
> metaclass version and a selector. Names are never needed to transfer
> behavior between systems.

This was something when I first - with my modes knowledge - tried to do
some bytecode serialization within squeak. I ended up in serializing
half of the image half of the times, trying to walk down the
dependencies between classes, behavious, constants and pool dictionaries.

Is there a methology to identify identical behaviours/ objects even if
identified by different UUIDs? Or is there a another approach like
creating the "UUID'd ancestor" which will provide the unique base and
which will be 'patched' (for the very base kernel) with commonly agreed/
shared UUIDs?

I am interested to understand the implications and I hope I am asking
the question that a 'reasonable Naiad newbie' will ask himself when he
comes across this list only to find these archived postings ;-)

>      You'll need to have signed and returned the Squeak project
> contributor's agreement to have your code included in the official
> Squeak releases, and the agreement is MIT-style, yes.

I think (correct me if I'm wrong) that this precondition is not
advertised on squeak.org. I would have just provided DNUs and fixes to
squeak-general if celest would have worked for me ;-)

Kind regards,
         Markus

--
Official PITA

> Pharo is based on Squeak 3.9, not 3.10.
> We don't re-implement the kernel, at least not for now. The current
> focus is on cleaning up and removing stuff we are not interested in
> (like toys), and providing a stable basis for professional use.
And in 3.11+ we will be looking to borrow improvements from Pharo,
without sacrificing backwards compatibility. This means we will likely
trail Pharo, but there is no reason why some level of compatability at
the kernel level cannot be maintained.

For those interested in following any 3.11 progress discussion, the
[hidden email] mailing list is open.

Keith

Keith Hodges schrieb:

> For those interested in following any 3.11 progress discussion, the
> [hidden email] mailing list is open.

gmane'd as gmane.comp.lang.smalltalk.squeak.release, right?

Hi Markus--

 > I'm sorry if I'm annoying ;-)

      Not at all! :)

 > > Every version of every module, author, class, and metaclass has a
 > > UUID. Methods are uniquely identified by a combination of a class or
 > > metaclass version and a selector. Names are never needed to transfer
 > > behavior between systems.
 >
 > This was something when I first - with my modes knowledge - tried to
 > do some bytecode serialization within squeak. I ended up in
 > serializing half of the image half of the times, trying to walk down
 > the dependencies between classes, behavious, constants and pool
 > dictionaries.

      I think the literal marker framework in Spoon keeps that from
happening (a way to refer to a method literal algorithmically, without
copying it).

 > Is there a methodology to identify identical behaviors/objects even if
 > identified by different UUIDs?

      Well, generally a UUID is used to refer to an object over time. To
refer to the object at a particular moment in time, other information is
added to the UUID (e.g., a version number). For example, an author ID
has a UUID and a version number, and a class ID has a UUID, an author
ID, and a version number.

 > Or is there a another approach like creating the "UUID'd ancestor"
 > which will provide the unique base and which will be 'patched' (for
 > the very base kernel) with commonly agreed/shared UUIDs?

      I'm not sure what you're saying there. :)


      thanks again,

-C