My own Squeak direction
Locked
12345
12345
 
|
Folks,
thanks to Andreas for a great topic. My Squeak directions are two-fold, pragmatics (performance and interoperability), and programming (the system as a metasystem for defining languages & systems). I don't think I need to justify these; they both are important underpinnings and enablers even if they're only means to ends.
Performance for me translates to continuing with Cog, getting it released to the community, and integrating with other performance work (especially Igor's Hydra). The next steps are a less naive code generator and a streamlined object representation which together should raise performance to VisualWorks levels. Releasing to the community could yield some more ports (PowerPC, ARM). I'd like to see someone copy the zygote idea in Dalvik of having the system spawn a read-only copy from which instances are rapidly obtained and diverge via copy-on-write. This obviously fits with Hydra.
Interoperability agan translates initially to Cog work. The threaded VM I've been working on should result in much more convenient interfacing with APIs such as those for GUI events and blocking i/o such as sockets. Providing proper callbacks, merging Alien facilities with the FFI and providing a natively multi-threaded but non-concurrent VM provides a good platform for lots of stuff.
For a vision I think both of the above point in the direction of image-level components, which I believe is one sensible direction up from objects. All sorts of distribution, reliability, scalability and update issues are addressable when one architects a system out of many virtual machines (think thousands or millions of ~< 1 meg footprint images).
Another direction is being able to allow plugins to be covered by the sands of time. I know you are concerned about the lack of modularity and hence fragility that implementing plugin-like facilities at the image level might entail. But that militates for better modularity constructs and things like exception handling in the FFI to allow easier debugging of crashes. That many plugins are prototyped and written in Smalltalk^H^H^H^H^H^H^H^H^HSlang and then deployed through C is testament to the advantages of writing them in Smalltalk, and it would be great if the whole Slang cycle was eliminable.
As far as the metasystem goes, keeping Squeak really good at doing language experimentation and tool evolution will keep things like Seaside and Newspeak happening and, even if only indirectly, enriching and growing the Squeak community. This is another source of requirements for better modularity, since being able to understand a small core and spawn a new language system from it while jettissoning the rest of the system is key.
Of course the jury is still out on how to do namespaces for Squeak. Newspeak is excitingly radical here but its perhaps too far. Perhaps one can get a long way without a language construct and instead relying on tools to help partition the system into the right set of onion skins, each skin divided into techtonic plates. But modularity is a consistent theme in most of the above, so I hope lots of experimentation with modularity occurs and the current cleanup work continues. Good conventions and language support like pragmas can probably go a long way.
On a specific you've mentioned: Packages: Better performance and smarter implementation will allow one to get rid of image segments. As you've pointed out image segments are too inflexible. David Leibs' basic design for parcels, which is essentially batch allocations and keep the interconnection graph separate, so that loading involves populating an object table with instances and then knitting these together using the graph data, is much faster than e.g. ReferenceStream. Once binary loading is handled by the image it is easy to make it flexible and add the metadata to allow shape-change on load etc.
best Eliot
|
|
|
In reply to this post by Andreas.Raab
Cool thread Andreas. The direction I am looking to move Squeak
in as part of the Open Cobalt project: I would like Squeak (Cobalt) to be a real-time collaboration tool. I want to invent a new medium for teaching classes, creating art in teams, and pair-programming over the internet. In the long term, that would involve merging with a lot of Jecel's ideas. In the short term, we are working on better network support, better support for saving and running multiple islands (which are kind of like Morphic projects with any number of people using them over the internet), and a well-integrated chat and voice UI. I also am going to make an attempt over the winter break to rebase Cobalt atop Pharo. The short-term goal of this is to have support for Alien FFI; long term goals are: - Finally make Tweak a loadable package - Have a fast path for adopting Cog and other VM changes - Get rid of one of the more unnecessary forks of Squeak And, finally, some things I'd like to see but am not working on: - A better Monticello with much better support for cross-project management, which used git or something as a backend in order to be able to use the excellent hosting providers that are available. (hosting has always been the achilies heel for monticello, and even more so for Monticello 2) - Incorperation of the Newspeak UI and namespace implementation solution into Squeak - Traits support in SystemEditor. This would enable the release of MC1.6 in the short term, but would also serve as an excellent base for future experiments on code management systems, and also could be used to replace ClassBuilder. -- Matthew Fulmer (a.k.a. Tapple) |
|
|
On Sun, 29 Nov 2009, Matthew Fulmer wrote:
> I also am going to make an attempt over the winter break to > rebase Cobalt atop Pharo. The short-term goal of this is to have > support for Alien FFI; long term goals are: AFAIK only the mac vm supports Alien. > - Finally make Tweak a loadable package > - Have a fast path for adopting Cog and other VM changes > - Get rid of one of the more unnecessary forks of Squeak How can pharo (and can't squeak) help you with these goals? Levente |
|
|
On Sun, Nov 29, 2009 at 4:36 PM, Levente Uzonyi <[hidden email]> wrote:
More correctly, Alien fully supports only IA32. The data manipulation part of Alien is cross-platform. Call-out and call-back support only exists for IA32, although callback support is pretty easy to provide for all platforms. Michael Haupt is looking at extracting the cross-platform part, so that should be available generally. I'm looking at integrating Alien marshaling with the FFI and at supporting Alien style callbacks. In any case it is not a lot of work to get this stuff done.
|
|
|
On Sun, 29 Nov 2009, Eliot Miranda wrote:
> On Sun, Nov 29, 2009 at 4:36 PM, Levente Uzonyi <[hidden email]> wrote: >> >> AFAIK only the mac vm supports Alien. > > > More correctly, Alien fully supports only IA32. The data manipulation part > of Alien is cross-platform. Call-out and call-back support only exists for > IA32, although callback support is pretty easy to provide for all platforms. > Michael Haupt is looking at extracting the cross-platform part, so that > should be available generally. I'm looking at integrating Alien marshaling > with the FFI and at supporting Alien style callbacks. In any case it is not > a lot of work to get this stuff done. > I mean there's no vm with Alien support available for windows and unix/linux. Levente |
|
|
In reply to this post by Eliot Miranda-2
On Sun, Nov 29, 2009 at 4:42 PM, Eliot Miranda <[hidden email]> wrote:
> For a vision I think both of the above point in the direction of image-level > components, which I believe is one sensible direction up from objects. All > sorts of distribution, reliability, scalability and update issues are > addressable when one architects a system out of many virtual machines (think > thousands or millions of ~< 1 meg footprint images). Namespaces would be much less of an issue if you had image-level components. More precisely, names within an image would not be a big problem, it would be names between images. i agree that figuring out how to make systems out of lots of images is important. Imagine if the debugger ran in a different image than the application. All sorts of problems with the debugger would go away. It is the right way to deal with parallelism. It is key to reliability. It is important for security. -Ralph |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |