I'll let someone else talk about the status of closures VM changes, but
I think part of the isolation you want can be provided by ClassBoxes. I
hope that we can include the VM changes required for that, so people can
play with them so we can learn and evolve this kind of capability.

Daniel

Phil Hargett <hargettp at mindspring.com> wrote:
> A few items I'd love to see put into the VM & base image sooner rather 
> than later:
> 
> 	1.  Full support for closures in the VM; I recall some work was being 
> done on this, so if it's ready for prime time, that would be a great 
> addition
> 	2.  Support for namespaces/modules/islands/environments whatever you 
> wanna call them to isolate portions of the VM & image from other 
> portions
> 
> The modules stuff in 3.3 had some of the right plumbing in place, but 
> IMHO partitioned the VM too much.  If, however, one could choose when 
> to partition the VM and explicitly allow sharing among them.  For 
> example, the current environments implementation still has the 
> plumbing, but it's hard to create a separate environment if one wants 
> to experiment inside a safe sandbox.  Projects do a decent job of 
> providing isolation, but I don't believe there designed to accomodate 
> multiple active Projects in the same VM at the same time.
> 
> Of course, the downer for me is that the areas of Squeak I'll be 
> contributing to is likely to be neither of the above....
> 
> My $.02
> 
> On Wednesday, October 8, 2003, at 11:05  AM, goran.krampe at bluefish.se 
> wrote:
> 
> > Hi all!
> >
> > Just felt like writing a bit "The Day After". 3.6 is out! Yay! And
> > personally I think we all did quite good with this one.
> >
> > 3.6 is the third release of Squeak that is "community driven". 3.4 was
> > the first one, but IIRC it included mostly the 3.3 work (without
> > 3.3-Modules) so even though it was the first release done by the
> > community through Doug Way (with help from Scott) it still consisted
> > mostly of work done "during SqC".
> >
> > 3.5 was a very small release (with a few "critical" bug fixes) which we
> > did mostly to get "our feet wet". The move to have a small release was
> > criticized at the time but whatever - water under the bridge. :-)
> >
> > 3.5->3.6 turned out to be 244 updates. 3.2->3.4 was 214 updates so 3.6
> > is much more a "real release". We set up a plan at the beginning and we
> > almost followed it all through. Sure, we can always improve the 
> > process.
> >
> > The Party
> > ===========
> >
> > Yesterday we had a "party" on the squeak IRC channel. Sure, we could 
> > have prepared it better with some fun stuff going on - but hey. :-) 
> > Anyway, it started slowly and built up gradually throughout. Someone 
> > counted 40 nicks total - quite a lot of people showed up and there 
> > where interesting discussions and toasts to people deserving it etc. 
> > Generally nice!
> >
> > I think we should try to have more of these "fun virtual events". 
> > Daniel and I have discussed a few ideas and I know that the idea of a 
> > "Bugathon" has been voiced. As always someone need to "take charge" so 
> > if you have a good idea, speak up!
> >
> > For example - a "BFAV crash course" on IRC with the authors and 
> > harvesters standing by for support would probably be a great boost.
> >
> >
> > Now what?
> > ============
> >
> > 3.7 alpha is starting and as always we have tons of things going on. 
> > And that is a really good thing! This means that Squeak is alive and 
> > kicking.
> >
> > The harvesting process has picked up a notch, BFAV works pretty good. 
> > There is a discussion currently how we should deal with bug tracking 
> > and that discussion also bring other issues to the table like for 
> > example the "Steward idea" and how we carve up the image into 
> > different areas of responsibility. Most discussions about bug tracking 
> > eventually end up in the "Who is responsible for that code?"-area. 
> > Note that this is not necessarily the same thing as cutting these 
> > areas out into packages.
> >
> > Personally I think that during the 3.7 iteration we should at least 
> > consider doing these things:
> >
> > 1. We (guides) have started trying to formulate a vision that we stand 
> > by. This is still very much in its infancy, but I think one goal for 
> > 3.7 is to get that out.
> >
> > 2. I think we should at least try to rotate one Guide. Rotation was a 
> > key idea from the beginning and I think it is healthy for the 
> > community.
> >
> > 3. Make a targeted effort at "harvesting" many of the enhancement 
> > packages currently living on SM. Many of those actually belong in the 
> > base image packages.
> >
> > 4. Get the new Compiler in. The word is out that SmaCC is now 
> > available under MIT so the license question is out of the way. Let's 
> > get this stuff in! It would be a real shame if all that work Anthony 
> > did got wasted...
> >
> > 5. Get Babel in and squeeze out a few translations. Already much on 
> > the way.
> >
> > 6. Split out at least ... 3 (?) more packages from Basic.
> >
> > 7. Get the TimeStamp/DateAndTime-whatever-package in. I am getting 
> > bored at including that in SM...
> >
> > 8. Whatever stuff that comes out of KCP and MCP of course. :)
> >
> > 9. General harvesting, and perhaps have a "BFAV crash course" during 
> > the iteration to pick up more users and thus speed through more 
> > eyeballs.
> >
> > 10. Come up with *anything* regarding bug tracking. Both for the image 
> > and for packages. SM2 can help a bit.
> >
> > 11. Start thinking about Stewarding areas of the image using 
> > PackageInfo definitions (without necessarily splitting it out). This 
> > way we get someone "in charge" and bug tracking, decision making etc 
> > gets much more defined.
> >
> > 12. And of course... get SM2 up and running. :-)
> >
> >
> > Now, this is by far a full list of candidate tasks. There are tons 
> > more that I both didn't think of rightnow or even purposefully left 
> > out so that other people get a chance to pipe up.
> >
> > over and out for now, Göran
> >
> > PS. If people simply throw out candidate tasks I will gather them up 
> > to a grand list which we then can prioritize.
> >