Hi Stef--

Just out of curiosity on which version is based Squeak 4. Squeak 3.2?

Well, that question is mostly meaningless when so much is removed. :) The most recent significant thing in there is support for weak references, which I think comes from 3.2. The VMs are all the latest, though.

-C

Agree with Andreas.

2008/7/1 Andreas Raab andreas.raab@gmx.de:

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

No worries. Take your time.

Cheers, - Andreas

Craig Latta wrote:

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

Thanks by the comments Craig.

2008/7/1 Craig Latta craig@netjam.org:

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

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

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.

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 release@lists.squeakfoundation.org mailing list is open.

Keith

Adrian Lienhard wrote:

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.

Can you say more about this? I had the impression that Pharo was mostly a fork for the sake of Seaside (which is understandable given the traction that Seaside has been getting). But is its goal more than that? Does it include media-rich applications like eToys, Scratch, Sophie or Qwaq Forums? I have been looking at the Pharo website but was mostly disappointed with the collection of empty phrases ("better for the better", "do not expect etoys to work") which promise everything but say absolutely nothing. A more down-to-earth, plain approach might be helpful if the goal is professional use. God knows that there is no shortage of areas in Squeak that could use some professional attention: From database support, over enterprise integration, native graphics, widgets up to m17n, namespace, modules, deployment, customization and installation support. There are plenty of areas where some professional attention could help. Is Pharo going to address any of these issues? Seriously. You *can* be professional, by acting professionally. Take up real issues that real products have in the real world.

Cheers, - Andreas

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

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

Markus Fritsche wrote:

(markus drinks: #wine) ifTrue: [ markus doNotPost ].