Folks -
I feel like the recent discussion about directions left us without much progress in terms of where we think Squeak is headed. I actually don't think this is particularly hard to formulate, since as we all know, Squeak will be headed where we make it head to. In other words, I think we could come up with a pretty good idea of where Squeak will be headed if those people who actually contribute tell a little bit more about their interests and directions. So let me be the first to start here:
My long-term vision for Squeak is to bring it back to being a medium for personal dynamic media. I want Squeak to be a fun, educational, small, dynamic, media-centric environment. My current immediate directions include:
* Making the system be more modular. Adding the Morphic TextEditors, refactoring Project, being able to unload various packages are in line with that. Expect more from me in this area as time allows.
* Figuring out how to load packages, projects, etc back in. I haven't done much about this yet, but we desperately need better tools for (roughly speaking) "loading apps". Squeakmap gets some things right, Universes address others, both aren't very well integrated with Monticello, and by the end of the day the UIs for all of them suck.
* Restore the media facilities. I'd really like to see the next Squeak version bring back Speech, bring back Games, bring back Wonderland etc. All in loadable project form so that people can explore them based on a small initial foot print.
I'd be interested in hearing what others working on and in Squeak have to say about their own directions. Together it should give a pretty comprehensive understanding about where Squeak is headed in practice.
Cheers, - Andreas
"Andreas" == Andreas Raab andreas.raab@gmx.de writes:
Andreas> I'd be interested in hearing what others working on and in Squeak Andreas> have to say about their own directions. Together it should give a Andreas> pretty comprehensive understanding about where Squeak is headed in Andreas> practice.
I think you're on the right track. I'd like to see Squeak core get smaller, faster, more powerful, but at the same time anything of substance we remove still be loadable from SqueakSource or some nice dependency mechanism.
Oh yeah, and I want a pony.
:-)
I would like to make a Squeak.dll that is callable by other application programs like Computer Aided Design software (CAD). I want to make addons to these programs using Squeak for the addons. A Squeak.dll will allow Squeak to be used in many situations where dll's are used to do invisible work for the main application programs.
All the best, Aik-Siong Koh
askoh wrote:
I would like to make a Squeak.dll that is callable by other application programs like Computer Aided Design software (CAD). I want to make addons to these programs using Squeak for the addons. A Squeak.dll will allow Squeak to be used in many situations where dll's are used to do invisible work for the main application programs.
In which case you might be interested in the current vm-dev thread starting here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003385.html
and I just announced a prototype that could in fact be linked from elsewhere:
http://lists.squeakfoundation.org/pipermail/vm-dev/2009-November/003437.html
Cheers, - Andreas
Andreas,
Personal dynamic media sounds excellent, media experience and malleability is what brought me to squeak in the first place. I agree with all your points modularity, packaging, projects and media. I use squeak for computational fun and learning in algorithms, art, music, presentations, information management etc.
Outside the image, I would like to see improvements in the vm; speed, 64bit (image too), multicore and better ffi.
Travis
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Andreas Raab Sent: Saturday, November 14, 2009 3:29 PM To: The general-purpose Squeak developers list Subject: [squeak-dev] My own Squeak direction
Folks -
I feel like the recent discussion about directions left us without much progress in terms of where we think Squeak is headed. I actually don't think this is particularly hard to formulate, since as we all know, Squeak will be headed where we make it head to. In other words, I think we could come up with a pretty good idea of where Squeak will be headed if those people who actually contribute tell a little bit more about their interests and directions. So let me be the first to start here:
My long-term vision for Squeak is to bring it back to being a medium for personal dynamic media. I want Squeak to be a fun, educational, small, dynamic, media-centric environment. My current immediate directions include:
* Making the system be more modular. Adding the Morphic TextEditors, refactoring Project, being able to unload various packages are in line with that. Expect more from me in this area as time allows.
* Figuring out how to load packages, projects, etc back in. I haven't done much about this yet, but we desperately need better tools for (roughly speaking) "loading apps". Squeakmap gets some things right, Universes address others, both aren't very well integrated with Monticello, and by the end of the day the UIs for all of them suck.
* Restore the media facilities. I'd really like to see the next Squeak version bring back Speech, bring back Games, bring back Wonderland etc. All in loadable project form so that people can explore them based on a small initial foot print.
I'd be interested in hearing what others working on and in Squeak have to say about their own directions. Together it should give a pretty comprehensive understanding about where Squeak is headed in practice.
Cheers, - Andreas
On Sun, Nov 15, 2009 at 02:39:24PM +0100, Bert Freudenberg wrote:
On 15.11.2009, at 03:46, Travis Kay wrote:
I would like to see [..] 64bit (image too)
Curious: what would you do if you could have a huge image?
Good question. The original Squeak 64-bit image is about five years old now, and does not seem to have attracted much interest of a practical nature:
http://squeakvm.org/squeak64/dist3/Squeak64-3.8g-6548.image.tar.gz
An updated version of this image, suitable for use on current Squeak VMs, is here:
http://squeakvm.org/squeak64/sq64-dtl.zip
You do need to build your own VM to use this image. There is nothing exotic about it, you just have to click the "64-bit image" checkbox on VMMaker to activate the 64-bit object memory version.
John McIntosh with support from ESUG is planning to do new work for a Mac VM, including 64-bit object memory support. Hopefully this will encourage new interest in the topic.
Help needed: Currently there is no way to convert new images (Squeak trunk, Cuis, Pharo, etc) into 64-bit format. If anyone has some expertise with SystemTracer, it would be good to get this working.
http://bugs.squeak.org/view.php?id=5239 http://bugs.squeak.org/view.php?id=5240
Dave
I built a 64bit VM a few years ago and converted one of my images. I had some success but I don't remember the issues I had run into with the image conversion.
Travis
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of David T. Lewis Sent: Sunday, November 15, 2009 6:20 AM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] 64 bit images
On Sun, Nov 15, 2009 at 02:39:24PM +0100, Bert Freudenberg wrote:
On 15.11.2009, at 03:46, Travis Kay wrote:
I would like to see [..] 64bit (image too)
Curious: what would you do if you could have a huge image?
Good question. The original Squeak 64-bit image is about five years old now, and does not seem to have attracted much interest of a practical nature:
http://squeakvm.org/squeak64/dist3/Squeak64-3.8g-6548.image.tar.gz
An updated version of this image, suitable for use on current Squeak VMs, is here:
http://squeakvm.org/squeak64/sq64-dtl.zip
You do need to build your own VM to use this image. There is nothing exotic about it, you just have to click the "64-bit image" checkbox on VMMaker to activate the 64-bit object memory version.
John McIntosh with support from ESUG is planning to do new work for a Mac VM, including 64-bit object memory support. Hopefully this will encourage new interest in the topic.
Help needed: Currently there is no way to convert new images (Squeak trunk, Cuis, Pharo, etc) into 64-bit format. If anyone has some expertise with SystemTracer, it would be good to get this working.
http://bugs.squeak.org/view.php?id=5239 http://bugs.squeak.org/view.php?id=5240
Dave
On 11/15/09 12:20 PM, "David T. Lewis" lewis@mail.msen.com wrote:
John McIntosh with support from ESUG is planning to do new work for a Mac VM, including 64-bit object memory support. Hopefully this will encourage new interest in the topic.
I try the last VM I have and don't work . John, you have a ready to run one ? Where ?
Edgar
There is currently a package dependency for VMMaker that requires the entire Speech package (for KlattSynthesizerPlugin). This can be resolved through a minor refactoring of Speech, mainly to move the shared pool class KlattResonatorIndices into a separate package, e.g. "SharedPool-Speech".
Are there any objections to adopting the package name "SharedPool-Speech" for this? By implication, we might also have "SharedPool-FFI" and so forth.
If no objections, I'll make a SqueakSource project for Speech, starting with the Speech-md.9.mcz from Squeak 3.9a, and updating it as described. With that in place, VMMaker will be loadable with just the shared pool prerequisite, rather than the entire Speech package.
No flame wars please, just speak up if there is a good reason that I should *not* do this.
Thanks!
On 15.11.2009, at 16:48, David T. Lewis wrote:
There is currently a package dependency for VMMaker that requires the entire Speech package (for KlattSynthesizerPlugin). This can be resolved through a minor refactoring of Speech, mainly to move the shared pool class KlattResonatorIndices into a separate package, e.g. "SharedPool-Speech".
Are there any objections to adopting the package name "SharedPool-Speech" for this? By implication, we might also have "SharedPool-FFI" and so forth.
If no objections, I'll make a SqueakSource project for Speech, starting with the Speech-md.9.mcz from Squeak 3.9a, and updating it as described. With that in place, VMMaker will be loadable with just the shared pool prerequisite, rather than the entire Speech package.
No flame wars please, just speak up if there is a good reason that I should *not* do this.
Thanks!
Wouldn't it make more sense to have packages named "Speech-Shared" and "Speech-Plugin" containing the shared pool and the plugin, respectively? That would go along well with the 8 or so other Speech categories.
Trying to have Speech as a single package is futile anyway since as you suggested it needs to be broken up.
- Bert -
On Sun, Nov 15, 2009 at 05:03:11PM +0100, Bert Freudenberg wrote:
On 15.11.2009, at 16:48, David T. Lewis wrote:
There is currently a package dependency for VMMaker that requires the entire Speech package (for KlattSynthesizerPlugin). This can be resolved through a minor refactoring of Speech, mainly to move the shared pool class KlattResonatorIndices into a separate package, e.g. "SharedPool-Speech".
Are there any objections to adopting the package name "SharedPool-Speech" for this? By implication, we might also have "SharedPool-FFI" and so forth.
Wouldn't it make more sense to have packages named "Speech-Shared" and "Speech-Plugin" containing the shared pool and the plugin, respectively? That would go along well with the 8 or so other Speech categories.
That would be a good logical organization, but doesn't that require splitting the existing Speech package into a total of 9 or 10 categories?
On 15-Nov-09, at 8:46 AM, David T. Lewis wrote:
On Sun, Nov 15, 2009 at 05:03:11PM +0100, Bert Freudenberg wrote:
On 15.11.2009, at 16:48, David T. Lewis wrote:
There is currently a package dependency for VMMaker that requires the entire Speech package (for KlattSynthesizerPlugin). This can be resolved through a minor refactoring of Speech, mainly to move the shared pool class KlattResonatorIndices into a separate package, e.g. "SharedPool-Speech".
Are there any objections to adopting the package name "SharedPool- Speech" for this? By implication, we might also have "SharedPool-FFI" and so forth.
Wouldn't it make more sense to have packages named "Speech-Shared" and "Speech-Plugin" containing the shared pool and the plugin, respectively? That would go along well with the 8 or so other Speech categories.
That would be a good logical organization, but doesn't that require splitting the existing Speech package into a total of 9 or 10 categories?
To elaborate a bit, it's not a good idea to have overlapping packages in Monticello 1.x. So if there's a package named "Speech-Shared", there should not be a package named "Speech." That would imply that the other categories "Speech-*" are all separate packages. That's probably not what we want.
David, "SharedPool-Speech" sounds good to me.
Colin
On Sun, Nov 15, 2009 at 10:48:49AM -0500, David T. Lewis wrote:
There is currently a package dependency for VMMaker that requires the entire Speech package (for KlattSynthesizerPlugin). This can be resolved through a minor refactoring of Speech, mainly to move the shared pool class KlattResonatorIndices into a separate package, e.g. "SharedPool-Speech".
Are there any objections to adopting the package name "SharedPool-Speech" for this? By implication, we might also have "SharedPool-FFI" and so forth.
If no objections, I'll make a SqueakSource project for Speech, starting with the Speech-md.9.mcz from Squeak 3.9a, and updating it as described. With that in place, VMMaker will be loadable with just the shared pool prerequisite, rather than the entire Speech package.
I opened a SqueakSource project for the Speech Klatt package:
MCHttpRepository location: 'http://www.squeaksource.com/Speech' user: '' password: ''
This is the speech package that is present in Squeak images up to and including Squeak 3.9. It is packaged here to make it available as a MC package, and allow the VMMaker package to access the Speech shared pool for use in KlattSynthesizerPlugin. The initial version in the repository is the Squeak 3.9a version that I copied from http://source.squeak.org/39a. I have updated it to recategorize the shared pool and other references needed for VMMaker.
I picked a couple of reputable soundings names out of a hat, thereby nominating Marcus Denker and Andreas Raab as "developers". If anyone has any sense of ownership over the Speech package, please speak up and I'll turn the package over to you.
The purpose of this change is to enable "VMMaker updateFromServer" to first load the Klatt shared pools, then load VMMaker and various related plugins. A similar update will be needed for FFI shared pools.
Dave
David T. Lewis wrote:
The purpose of this change is to enable "VMMaker updateFromServer" to first load the Klatt shared pools, then load VMMaker and various related plugins. A similar update will be needed for FFI shared pools.
For the FFI I'm *strongly* in favor of breaking the package out and have, e.g.,
* FFI-SharedPools * FFI-Kernel * FFI-Tests * FFI-Examples
The structure makes a lot of sense and I could even imaging moving the plugin here (i.e., into FFI-Plugin).
Cheers, - Andreas
On Mon, Nov 16, 2009 at 06:18:23PM -0800, Andreas Raab wrote:
David T. Lewis wrote:
The purpose of this change is to enable "VMMaker updateFromServer" to first load the Klatt shared pools, then load VMMaker and various related plugins. A similar update will be needed for FFI shared pools.
For the FFI I'm *strongly* in favor of breaking the package out and have, e.g.,
- FFI-SharedPools
- FFI-Kernel
- FFI-Tests
- FFI-Examples
Good, if you can make this change and make it available on a repository, then I'll update the MCConfiguration for VMMaker to pull in the FFI-SharedPools. Bert suggested the same naming convention for Speech-SharedPools, so I can update the Speech packaging if that is the preference.
The structure makes a lot of sense and I could even imaging moving the plugin here (i.e., into FFI-Plugin).
I have a slight bias, motivated primarily by personal laziness, toward the original Squeak categories that would lead to e.g.
VMConstruction-Interpreter/ObjectMemory VMConstruction-Plugins/FFIPlugin VMConstruction-Plugins-OSProcessPlugin/OSProcessPlugin
But either convention would be fine. Long term I think that VMMaker should be repackaged into smaller pieces, and I have a hard time improving on the category names that were used back in Squeak 2.4.
Dave
David T. Lewis wrote:
- FFI-SharedPools
- FFI-Kernel
- FFI-Tests
- FFI-Examples
Good, if you can make this change and make it available on a repository, then I'll update the MCConfiguration for VMMaker to pull in the FFI-SharedPools. Bert suggested the same naming convention for Speech-SharedPools, so I can update the Speech packaging if that is the preference.
Done. I've actually named the package FFI-Pools (shorter and to the point); I don't think that naming matters as long as you can figure out what it likely contains.
The structure makes a lot of sense and I could even imaging moving the plugin here (i.e., into FFI-Plugin).
I have a slight bias, motivated primarily by personal laziness, toward the original Squeak categories that would lead to e.g.
VMConstruction-Interpreter/ObjectMemory VMConstruction-Plugins/FFIPlugin VMConstruction-Plugins-OSProcessPlugin/OSProcessPlugin
But either convention would be fine. Long term I think that VMMaker should be repackaged into smaller pieces, and I have a hard time improving on the category names that were used back in Squeak 2.4.
I have no particular preference either way. The laziness is traded in my view by making sure you actually know how to find the prerequisites, i.e., you won't be able to load VMMaker if you don't know where to find the FFI pools but that should be fair game if you don't care about the FFI. Or more to the point Speech. I'm sure there are people out there who don't care about the Klatt plugin and forcing them to go onto a hunt for this or that prerequisite seems pointless unless they care. But then, given that I just went through the process of installing all the bits I can see your point about laziness :)
Cheers, - Andreas
Not just laziness, but also convenience. The people who trying it first time, obviously having lack of knowledge, where all those plugins resided, in what repositories, and most important - do he needs them to build a test VM.
So, i think there are missing some kind of registry in VMMaker, which could tell a user , what plugins existing and where he can download them, what plugins is critical for running an image, and what is optional and can be ignored.
It would be cool to have a 1-click VM builder. So, anyone could download, install & build VM, without requiring user attention.
2009/11/17 Andreas Raab andreas.raab@gmx.de:
David T. Lewis wrote:
- FFI-SharedPools
- FFI-Kernel
- FFI-Tests
- FFI-Examples
Good, if you can make this change and make it available on a repository, then I'll update the MCConfiguration for VMMaker to pull in the FFI-SharedPools. Bert suggested the same naming convention for Speech-SharedPools, so I can update the Speech packaging if that is the preference.
Done. I've actually named the package FFI-Pools (shorter and to the point); I don't think that naming matters as long as you can figure out what it likely contains.
The structure makes a lot of sense and I could even imaging moving the plugin here (i.e., into FFI-Plugin).
I have a slight bias, motivated primarily by personal laziness, toward the original Squeak categories that would lead to e.g.
VMConstruction-Interpreter/ObjectMemory VMConstruction-Plugins/FFIPlugin VMConstruction-Plugins-OSProcessPlugin/OSProcessPlugin
But either convention would be fine. Long term I think that VMMaker should be repackaged into smaller pieces, and I have a hard time improving on the category names that were used back in Squeak 2.4.
I have no particular preference either way. The laziness is traded in my view by making sure you actually know how to find the prerequisites, i.e., you won't be able to load VMMaker if you don't know where to find the FFI pools but that should be fair game if you don't care about the FFI. Or more to the point Speech. I'm sure there are people out there who don't care about the Klatt plugin and forcing them to go onto a hunt for this or that prerequisite seems pointless unless they care. But then, given that I just went through the process of installing all the bits I can see your point about laziness :)
Cheers, - Andreas
On Tue, Nov 17, 2009 at 02:23:13PM +0200, Igor Stasenko wrote:
Not just laziness, but also convenience. The people who trying it first time, obviously having lack of knowledge, where all those plugins resided, in what repositories, and most important - do he needs them to build a test VM.
So, i think there are missing some kind of registry in VMMaker, which could tell a user , what plugins existing and where he can download them, what plugins is critical for running an image, and what is optional and can be ignored.
It would be cool to have a 1-click VM builder. So, anyone could download, install & build VM, without requiring user attention.
Look at the "update" category in VMMaker on SqueakSource, and VMMaker class>>updateFromServer.
A one-click install or update would be: MCMcmUpdater updateFromRepositories: #('http://squeaksource.com/VMMaker' )
I'm not sure if I have the MC configuration right yet (don't have time to check right now) but it's close.
Dave
On Sun, Nov 15, 2009 at 5:39 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 15.11.2009, at 03:46, Travis Kay wrote:
I would like to see [..] 64bit (image too)
Curious: what would you do if you could have a huge image?
One answer is what VW customers do with 64-bits. Travis & Martin can give more up-to-date answer on this but IIRC a number of VM customers had images that were pushing the 4Gb limit. One was Quallaby. They did a network monitoring app that had huge numbers of large integers in a graph representing the state of the network. EZBoard wanted 64-bit images because their message-board architecture was too monolithic. GemStone had/have customers hitting 32-bit limits on numbers of objects. So I'd sum up as large enterprise apps. Travis, Martin, what's the current demand like?
- Bert -
On 16.11.2009, at 23:40, Eliot Miranda wrote:
On Sun, Nov 15, 2009 at 5:39 AM, Bert Freudenberg bert@freudenbergs.de wrote: On 15.11.2009, at 03:46, Travis Kay wrote:
I would like to see [..] 64bit (image too)
Curious: what would you do if you could have a huge image?
One answer is what VW customers do with 64-bits. Travis & Martin can give more up-to-date answer on this but IIRC a number of VM customers had images that were pushing the 4Gb limit. One was Quallaby. They did a network monitoring app that had huge numbers of large integers in a graph representing the state of the network. EZBoard wanted 64-bit images because their message-board architecture was too monolithic. GemStone had/have customers hitting 32-bit limits on numbers of objects. So I'd sum up as large enterprise apps. Travis, Martin, what's the current demand like?
I can't quite imagine Squeak's GC giving satisfying performance with such a large object memory.
- Bert -
On Mon, Nov 16, 2009 at 2:50 PM, Bert Freudenberg bert@freudenbergs.dewrote:
On 16.11.2009, at 23:40, Eliot Miranda wrote:
On Sun, Nov 15, 2009 at 5:39 AM, Bert Freudenberg bert@freudenbergs.dewrote:
On 15.11.2009, at 03:46, Travis Kay wrote:
I would like to see [..] 64bit (image too)
Curious: what would you do if you could have a huge image?
One answer is what VW customers do with 64-bits. Travis & Martin can give more up-to-date answer on this but IIRC a number of VM customers had images that were pushing the 4Gb limit. One was Quallaby. They did a network monitoring app that had huge numbers of large integers in a graph representing the state of the network. EZBoard wanted 64-bit images because their message-board architecture was too monolithic. GemStone had/have customers hitting 32-bit limits on numbers of objects. So I'd sum up as large enterprise apps. Travis, Martin, what's the current demand like?
I can't quite imagine Squeak's GC giving satisfying performance with such a large object memory.
I concur :) But that's partially my next target, both to have a more efficient object representation (class decode is very slow with the current one, we could do with immediate characters and in 64-bit immediate Floats) and to provide pinning for the threaded FFI. Its probably hubris to imagine the product will scale to > 4Gb but I hope it won't be any worse :)
- Bert -
2009/11/17 Eliot Miranda eliot.miranda@gmail.com:
On Mon, Nov 16, 2009 at 2:50 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 16.11.2009, at 23:40, Eliot Miranda wrote:
On Sun, Nov 15, 2009 at 5:39 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 15.11.2009, at 03:46, Travis Kay wrote:
I would like to see [..] 64bit (image too)
Curious: what would you do if you could have a huge image?
One answer is what VW customers do with 64-bits. Travis & Martin can give more up-to-date answer on this but IIRC a number of VM customers had images that were pushing the 4Gb limit. One was Quallaby. They did a network monitoring app that had huge numbers of large integers in a graph representing the state of the network. EZBoard wanted 64-bit images because their message-board architecture was too monolithic. GemStone had/have customers hitting 32-bit limits on numbers of objects. So I'd sum up as large enterprise apps. Travis, Martin, what's the current demand like?
I can't quite imagine Squeak's GC giving satisfying performance with such a large object memory.
I concur :) But that's partially my next target, both to have a more efficient object representation (class decode is very slow with the current one, we could do with immediate characters and in 64-bit immediate Floats) and to provide pinning for the threaded FFI. Its probably hubris to imagine the product will scale to > 4Gb but I hope it won't be any worse :)
Nan trick or SmallDouble like trick or ?
Nicolas
- Bert -
Nicolas Cellier wrote:
2009/11/17 Eliot Miranda eliot.miranda@gmail.com:
Travis, Martin, what's the current demand like?
Having more than 4G of object memory is only one reason someone might want a 64-bit VM. Maybe you use integers > 2**29 but < 2**60 and would like them to be SmallIntegers for speed and/or space. Maybe you use floats and would like them to be immediate for speed and/or space. Maybe you want to call a function in a 64-bit shared library. Maybe you just want to run a pure 64-bit Linux system without all of those 32-bit libraries, which is becoming more practical as most common open-source packages are now 64-bit clean. (These days I have very few 32-bit executables on my systems.)
But yes, various size considerations were the driver for GemStone to go 64-bit. In GemStone, you don't have to have all of your objects in memory at the same time, so you could have more than 4GB of objects even on 32-bit. We had customers with more than 100GB of objects. But when you have that many object there were two problems:
1. In a 32-bit address space you can only cache <4GB of objects in memory. When you have 100GB of objects, the working set of frequently-accessed objects is probably >4GB, so things slow down with frequent disk accesses to swap objects in (and out, if modified).
2. The total number of persistent objects was limited to 2G objects due to use of a 32-bit object identifier, and some customers were approaching that limit.
Going to 64-bit fixes both of these; you can now have 2**40 objects, and use as much RAM as you've got for caching objects.
So GemStone VMs are now 64-bit. You can use a 32-bit VW VM as a client to 64-bit GemStone, by connecting client to server via a socket. But some of our customers put the client and server on the same machine and have the client VM load the server VM as a shared library, thereby getting rid of network stack overhead. You can't do that unless client and server are both the same architecture. So if you have a 64-bit server VM you have to also have a 64-bit client VM. This is an advantage to using 64-bit VW even if the client image is quite small, and this is indeed the major driver we've had in supporting 64-bit VW.
Nan trick or SmallDouble like trick or ?
For immediate floats: SmallDouble, definitely! At least that's what I'd like to see. :-)
SmallDoubles are currently bit-compatible between GemStone and VW, and I'm encouraging all dialects that go 64-bit and want immediate floats to adopt the same format. The only reason to do otherwise is if someone comes up with an immediate float format that is significantly better, and in the past few years of working with the current format it looks like the design choices were good ones.
Regards,
-Martin
Ok, one of the objectives of building 64 bit Squeak VM hosting app was to let people explore solutions to address what a 64 bit image can do, without the hosting harness it's hard to explore what's feasible.
A simple example is what happens if you have a 4GB 32bit image, although I've asked people if such a beast exists, no takers.
I'l note based on visual feedback at ESUG, and supporting hearsay you'll find *lots* of alpha developers using Squeak run on OS-X, so let's push the envelope?
On 2009-11-16, at 4:32 PM, Eliot Miranda wrote:
I concur :) But that's partially my next target, both to have a more efficient object representation (class decode is very slow with the current one, we could do with immediate characters and in 64-bit immediate Floats) and to provide pinning for the threaded FFI. Its probably hubris to imagine the product will scale to > 4Gb but I hope it won't be any worse :)
- Bert -
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
My brother is a mathematician that researches on issues related to the flow of gases in the atmosphere. He runs tests on enormous amounts of data he has on cubic "pixels" of the atmosphere. If he puts all this data on a database the tests become real slow, hence at one point I thought it would be great to implement all his tests in a large in-memory image. If I had a 64 bit squeak I'd do it :)
Cheers
r
On Tue, Nov 17, 2009 at 2:50 AM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:
Ok, one of the objectives of building 64 bit Squeak VM hosting app was to let people explore solutions to address what a 64 bit image can do, without the hosting harness it's hard to explore what's feasible.
A simple example is what happens if you have a 4GB 32bit image, although I've asked people if such a beast exists, no takers.
I'l note based on visual feedback at ESUG, and supporting hearsay you'll find *lots* of alpha developers using Squeak run on OS-X, so let's push the envelope?
On 2009-11-16, at 4:32 PM, Eliot Miranda wrote:
I concur :) But that's partially my next target, both to have a more
efficient object representation (class decode is very slow with the current one, we could do with immediate characters and in 64-bit immediate Floats) and to provide pinning for the threaded FFI. Its probably hubris to imagine the product will scale to > 4Gb but I hope it won't be any worse :)
- Bert -
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
2009/11/17 Ramiro Diaz Trepat ramiro@diaztrepat.name:
My brother is a mathematician that researches on issues related to the flow of gases in the atmosphere. He runs tests on enormous amounts of data he has on cubic "pixels" of the atmosphere. If he puts all this data on a database the tests become real slow, hence at one point I thought it would be great to implement all his tests in a large in-memory image. If I had a 64 bit squeak I'd do it :) Cheers
r
Oh, maybe a use case for Smallapack. A pity it does not work in Squeak yet...
Nicolas
On Tue, Nov 17, 2009 at 2:50 AM, John M McIntosh johnmci@smalltalkconsulting.com wrote:
Ok, one of the objectives of building 64 bit Squeak VM hosting app was to let people explore solutions to address what a 64 bit image can do, without the hosting harness it's hard to explore what's feasible.
A simple example is what happens if you have a 4GB 32bit image, although I've asked people if such a beast exists, no takers.
I'l note based on visual feedback at ESUG, and supporting hearsay you'll find *lots* of alpha developers using Squeak run on OS-X, so let's push the envelope?
On 2009-11-16, at 4:32 PM, Eliot Miranda wrote:
I concur :) But that's partially my next target, both to have a more efficient object representation (class decode is very slow with the current one, we could do with immediate characters and in 64-bit immediate Floats) and to provide pinning for the threaded FFI. Its probably hubris to imagine the product will scale to > 4Gb but I hope it won't be any worse :)
- Bert -
--
=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
If I had a 64 bit image I would import all OpenStreetMap data and experiment with algorithms to access/render this dataset fast...
Marco Schmidt
2009/11/17 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
2009/11/17 Ramiro Diaz Trepat ramiro@diaztrepat.name:
My brother is a mathematician that researches on issues related to the flow of gases in the atmosphere. He runs tests on enormous amounts of data he has on cubic "pixels" of the atmosphere. If he puts all this data on a database the tests become real slow, hence at one point I thought it would be great to implement all his tests in a large in-memory image. If I had a 64 bit squeak I'd do it :) Cheers
r
Oh, maybe a use case for Smallapack. A pity it does not work in Squeak yet...
Nicolas
On Tue, Nov 17, 2009 at 2:50 AM, John M McIntosh johnmci@smalltalkconsulting.com wrote:
Ok, one of the objectives of building 64 bit Squeak VM hosting app was to let people explore solutions to address what a 64 bit image can do, without the hosting harness it's hard to explore what's feasible.
A simple example is what happens if you have a 4GB 32bit image, although I've asked people if such a beast exists, no takers.
I'l note based on visual feedback at ESUG, and supporting hearsay you'll find *lots* of alpha developers using Squeak run on OS-X, so let's push the envelope?
On 2009-11-16, at 4:32 PM, Eliot Miranda wrote:
I concur :) But that's partially my next target, both to have a more efficient object representation (class decode is very slow with the current one, we could do with immediate characters and in 64-bit immediate Floats) and to provide pinning for the threaded FFI. Its probably hubris to imagine the product will scale to > 4Gb but I hope it won't be any worse :)
- Bert -
--
=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
On 16-Nov-09, at 2:40 PM, Eliot Miranda wrote:
One was Quallaby. They did a network monitoring app that had huge numbers of large integers in a graph representing the state of the network.
I worked on that app for bit. We had one installation we had to be careful with because the images were 3.5 GB, and if we got beyond that, there wasn't enough room for the VM to work. Other customers were smaller but headed upwards and we could see that we would hit the limit eventually. At that point we were already processing much more than 4GB of data at once, but the partitioning into separate images was based on external factors and wasn't very flexible. Before I left, I was part of a project to move to a more cloudy architecture where partitioning was much more flexible.
I guess the take-away from that was that many cooperating smaller images works as well or better than one huge image. There might be applications where that's not true, and everything *has* to be in the same address space, but I can't think of any.
That is not to say, however, that 64-bit images aren't needed, just that images larger than 4 GB are the least interesting implication of having 64-bit pointers. I'd rather use the pointer bandwidth for more/ better immediate values, and run in 64-bit mode for better use of the hardware and integration with the host OS.
Colin
El sáb, 14-11-2009 a las 15:28 -0800, Andreas Raab escribió:
I'd be interested in hearing what others working on and in Squeak have to say about their own directions. Together it should give a pretty comprehensive understanding about where Squeak is headed in practice.
I would like a timeline for squeak and a list of goals (the list you and Igor have written is a good start) and of course a release date.
Speaking of that, the following presentation can be a good advise:
http://assets.en.oreilly.com/1/event/27/Release%20Mismanagement_%20How% 20to%20Alienate%20Users%20and%20Frustrate%20Developers% 20Presentation.pdf
http://www.hyrumwright.org/papers/floss2009.pdf
found on:
http://en.oreilly.com/oscon2009/public/schedule/detail/7823
Cheers
"Miguel" == Miguel Enrique Cobá Martinez miguel.coba@gmail.com writes:
Miguel> I would like a timeline for squeak and a list of goals (the list you Miguel> and Igor have written is a good start) and of course a release date.
You can't have timelines and release dates without committed resources.
Are you committing yourself? If so, cool. That's one. :)
El sáb, 14-11-2009 a las 20:24 -0800, Randal L. Schwartz escribió:
"Miguel" == Miguel Enrique Cobá Martinez miguel.coba@gmail.com writes:
Miguel> I would like a timeline for squeak and a list of goals (the list you Miguel> and Igor have written is a good start) and of course a release date.
You can't have timelines and release dates without committed resources.
Are you committing yourself? If so, cool. That's one. :)
Maybe this is a chicken and egg problem then.
Without clear or at least focused goals and proposed timelines (they don't have to be set in stone) the people can't know in *what* they can help. And without people seeing a direction and goals, they can't propose themselves for some specific task solving.
So, yes, I will help, but I can't be sure in what. Also, as I have already said, isn't only code that Squeak needs, also needs *promotion*, tutorials, blog posts, users reporting fixes (even if they (we) can't solve them) and a lot of thing more than code.
But, count me in. I will help in whatever is in my possibilities and capabilities.
Andreas Raab wrote:
Folks -
I feel like the recent discussion about directions left us without much progress in terms of where we think Squeak is headed. I actually don't think this is particularly hard to formulate, since as we all know, Squeak will be headed where we make it head to. In other words, I think we could come up with a pretty good idea of where Squeak will be headed if those people who actually contribute tell a little bit more about their interests and directions.
No matter how many times we said this, from what I see in responses to this thread, it seems people still don't get it.
So let me be the first to start here:
My long-term vision for Squeak is to bring it back to being a medium for personal dynamic media. I want Squeak to be a fun, educational, small, dynamic, media-centric environment. My current immediate directions include:
- Making the system be more modular. Adding the Morphic TextEditors,
refactoring Project, being able to unload various packages are in line with that. Expect more from me in this area as time allows.
- Figuring out how to load packages, projects, etc back in. I haven't
done much about this yet, but we desperately need better tools for (roughly speaking) "loading apps". Squeakmap gets some things right, Universes address others, both aren't very well integrated with Monticello, and by the end of the day the UIs for all of them suck.
- Restore the media facilities. I'd really like to see the next Squeak
version bring back Speech, bring back Games, bring back Wonderland etc. All in loadable project form so that people can explore them based on a small initial foot print.
I'd be interested in hearing what others working on and in Squeak have to say about their own directions. Together it should give a pretty comprehensive understanding about where Squeak is headed in practice.
Cheers,
- Andreas
My own Squeak direction is described in http://www.jvuletich.org/Cuis/Index.html . As it seems to be incompatible with that of many in the community, it requires a fork.
Aside from that, I fully support your direction, and I'll try to keep helping. Of course, I'd be delighted if at least some of my objectives were adopted for Squeak too.
Cheers, Juan Vuletich
Juan Vuletich wrote:
No matter how many times we said this, from what I see in responses to this thread, it seems people still don't get it.
Not unexpectedly ;-) I can see both sides though; on the one hand it's difficult to describe exactly where Squeak will be without having a set of known resources. On the other hand, the question of where Squeak is headed is certainly a fair one. As a result, I'm trying to answer the question by looking at the resources that are being committed to improving Squeak, i.e., summarize what people actually work on and try to project where this will get us.
My own Squeak direction is described in http://www.jvuletich.org/Cuis/Index.html . As it seems to be incompatible with that of many in the community, it requires a fork.
I don't think that the goals are incompatible. With more work on modularity, I think that your goals can be a subset of those in the larger community (just as my goals are a subset of those).
Aside from that, I fully support your direction, and I'll try to keep helping. Of course, I'd be delighted if at least some of my objectives were adopted for Squeak too.
Absolutely. I agree with a lot of what you're writing. I have some different ideas in various areas but on a fundamental level I think we have fairly compatible ideas.
Cheers, - Andreas
Personal media, multimedia capabilities, eToys and all the goals mentioned by Andreas are my own also, and I think that they don't exclude the Juan goals. Between these I agree particularly with
* Developers working for devices with little memory or CPU power.
thinking in embedded development.
But, and is a big but on my pov, I wants also all the possibilities to make web development. I don't like the idea of think that to web dev I should switch to Pharo. Is hard to maintain myself updated with one product, I can't imagine how to stay up-to-date with two.
As Miguel mentioned in another thread, the mostly paying people on our days is paying for web projects and I wants to develop them using Squeak.
I wish a Squeak capable of run:
- Seaside - Aida - Iliad - SWT (I'm porting right now to the trunk image)
in addition to all the other goals named before.
Count me in to help also, in my really very very limited free time.
Cheers.
2009/11/15 Andreas Raab andreas.raab@gmx.de:
Juan Vuletich wrote:
No matter how many times we said this, from what I see in responses to this thread, it seems people still don't get it.
Not unexpectedly ;-) I can see both sides though; on the one hand it's difficult to describe exactly where Squeak will be without having a set of known resources. On the other hand, the question of where Squeak is headed is certainly a fair one. As a result, I'm trying to answer the question by looking at the resources that are being committed to improving Squeak, i.e., summarize what people actually work on and try to project where this will get us.
My own Squeak direction is described in http://www.jvuletich.org/Cuis/Index.html . As it seems to be incompatible with that of many in the community, it requires a fork.
I don't think that the goals are incompatible. With more work on modularity, I think that your goals can be a subset of those in the larger community (just as my goals are a subset of those).
Aside from that, I fully support your direction, and I'll try to keep helping. Of course, I'd be delighted if at least some of my objectives were adopted for Squeak too.
Absolutely. I agree with a lot of what you're writing. I have some different ideas in various areas but on a fundamental level I think we have fairly compatible ideas.
Cheers, - Andreas
Andreas Raab wrote:
Juan Vuletich wrote:
No matter how many times we said this, from what I see in responses to this thread, it seems people still don't get it.
Not unexpectedly ;-) I can see both sides though; on the one hand it's difficult to describe exactly where Squeak will be without having a set of known resources. On the other hand, the question of where Squeak is headed is certainly a fair one. As a result, I'm trying to answer the question by looking at the resources that are being committed to improving Squeak, i.e., summarize what people actually work on and try to project where this will get us.
Amen!
My own Squeak direction is described in http://www.jvuletich.org/Cuis/Index.html . As it seems to be incompatible with that of many in the community, it requires a fork.
I don't think that the goals are incompatible. With more work on modularity, I think that your goals can be a subset of those in the larger community (just as my goals are a subset of those).
Yes, you are right. When modularity in Squeak gets good enough, Cuis could merge back. That would be great.
Aside from that, I fully support your direction, and I'll try to keep helping. Of course, I'd be delighted if at least some of my objectives were adopted for Squeak too.
Absolutely. I agree with a lot of what you're writing. I have some different ideas in various areas but on a fundamental level I think we have fairly compatible ideas.
Cheers,
- Andreas
I'd like to know about where we don't agree.Your opinion is very valuable to me. Besides, it would help me think on making optional packages for a Squeak kernel with the specific features of Cuis I'd like to keep.
Cheers, Juan Vuletich
Juan Vuletich wrote:
My own Squeak direction is described in http://www.jvuletich.org/Cuis/Index.html . As it seems to be incompatible with that of many in the community, it requires a fork.
Aside from that, I fully support your direction, and I'll try to keep helping. Of course, I'd be delighted if at least some of my objectives were adopted for Squeak too.
While it is good to avoid forking as much as possible, I always like to remind people that Squeak 3.8 was a merge of four forks (squeak.org 3.7, Squeakland, SmallLand and OpenCroquet) and that merges might also happen in the future. My own vision, described below, requires a radical rewrite of ObjectMemory and a significant patch of message sending in Interpreter. So this will probably require a fork as well (we shall see - I had hoped to be able to work on this starting in August, but now next January seems more likely).
I would like for there to be a single, world-wide image for Squeak. This would be split up into many relatively small, immutable files for storage. A given machine probably wouldn't have access to the whole set of files at any one time. This image would support multiple simultaneous viewpoints such that if you have a pointer to an object and I have a pointer to the same object we might get different results when sending the exact same message. The viewpoints are managed mostly manually with a reasonable visual representation.
Each node only loads into RAM as much of the global image as it needs to run its current code. Several nodes might collaborate by loading different parts of the image and sending messages to each other. Alternatively, several nodes might load the same parts of the image and keep in sync with the TeaTime scheme. Machines with 16 thousand SiliconSqueak cores are in the early planning stage, which gives you an idea of how far I think we can scale this.
At the other extreme, a headless application running on a single core with only the barest parts of the image that it needs to support it should fit easily in just 128KB of memory. Other applications might have fancy multimedia features and I would like the option to have as much of this in Squeak so that bare hardware is a practical platform, even as Squeak makes better and better use of native features in other OSes. I would like SqueakNOS to be safer and more robust than current OSes.
-- Jecel
Jecel Assumpcao Jr wrote:
Juan Vuletich wrote:
My own Squeak direction is described in http://www.jvuletich.org/Cuis/Index.html . As it seems to be incompatible with that of many in the community, it requires a fork.
Aside from that, I fully support your direction, and I'll try to keep helping. Of course, I'd be delighted if at least some of my objectives were adopted for Squeak too.
While it is good to avoid forking as much as possible, I always like to remind people that Squeak 3.8 was a merge of four forks (squeak.org 3.7, Squeakland, SmallLand and OpenCroquet) and that merges might also happen in the future. My own vision, described below, requires a radical rewrite of ObjectMemory and a significant patch of message sending in Interpreter. So this will probably require a fork as well (we shall see
- I had hoped to be able to work on this starting in August, but now
next January seems more likely).
I would like for there to be a single, world-wide image for Squeak. This would be split up into many relatively small, immutable files for storage. A given machine probably wouldn't have access to the whole set of files at any one time. This image would support multiple simultaneous viewpoints such that if you have a pointer to an object and I have a pointer to the same object we might get different results when sending the exact same message. The viewpoints are managed mostly manually with a reasonable visual representation.
I wonder what do you have in mind as typical uses for this functionality. While I applaud efforts on modernizing Smalltalk, I'm a bit reluctant of changes to the language semantics.
Each node only loads into RAM as much of the global image as it needs to run its current code. Several nodes might collaborate by loading different parts of the image and sending messages to each other. Alternatively, several nodes might load the same parts of the image and keep in sync with the TeaTime scheme. Machines with 16 thousand SiliconSqueak cores are in the early planning stage, which gives you an idea of how far I think we can scale this.
Wow! Experimenting with such a system would be fantastic!
At the other extreme, a headless application running on a single core with only the barest parts of the image that it needs to support it should fit easily in just 128KB of memory. Other applications might have fancy multimedia features and I would like the option to have as much of this in Squeak so that bare hardware is a practical platform, even as Squeak makes better and better use of native features in other OSes. I would like SqueakNOS to be safer and more robust than current OSes.
-- Jecel
Great.
Cheers, Juan Vuletich
Juan Vuletich wrote:
Jecel Assumpcao Jr wrote:
Juan Vuletich wrote: [single, world-wide image for Squeak]
I wonder what do you have in mind as typical uses for this functionality.
Right - it was silly of me to go into some technical details of how I hope to achieve my goals without explaining first what these goals are:
I want it to be easy and elegant to create and share persistent objects using Squeak.
Solutions like Monticello+package universes/squeakmap are a bit too complicated for me and yet don't do some things that I want. Deltastreams would improve that somewhat. Keith's scripts solve some problems by automating stuff at the cost of making manual other things that I would like to be automatic. I find Spoon very interesting though I don't think it will scale to the level I want. The Squeakland and Scratch use projects to share, but that isn't very robust since these have very strict requirements about the environment into which they can be loaded without be explicit about what these requirements are.
While I applaud efforts on modernizing Smalltalk, I'm a bit reluctant of changes to the language semantics.
Though I have no problems with cleaning up Smalltalk's semantics (as should be obvious from my participation in the Self community), I did not include any such changes in my vision for Squeak. In fact, I also participate in the ANSI Smalltalk effort which would bring Squeak closer to the other Smalltalks rather than make even more different than it already is. I don't think changing how images are saved and loaded has any effect on the language semantics though it might change how you use it (just like adding virtual memory doesn't change C, but might allow a different programming style).
[16 thousand SiliconSqueak cores]
Wow! Experimenting with such a system would be fantastic!
There are a few steps before we get there. I'll keep the community informed of any progress we make.
-- Jecel
Jecel Assumpcao Jr wrote:
Juan Vuletich wrote:
Jecel Assumpcao Jr wrote:
Juan Vuletich wrote: [single, world-wide image for Squeak]
I wonder what do you have in mind as typical uses for this functionality.
Right - it was silly of me to go into some technical details of how I hope to achieve my goals without explaining first what these goals are:
I want it to be easy and elegant to create and share persistent objects using Squeak.
Solutions like Monticello+package universes/squeakmap are a bit too complicated for me and yet don't do some things that I want. Deltastreams would improve that somewhat. Keith's scripts solve some problems by automating stuff at the cost of making manual other things that I would like to be automatic. I find Spoon very interesting though I don't think it will scale to the level I want. The Squeakland and Scratch use projects to share, but that isn't very robust since these have very strict requirements about the environment into which they can be loaded without be explicit about what these requirements are.
Well, the part I didn't get was: "This image would support multiple simultaneous viewpoints such that if you have a pointer to an object and I have a pointer to the same object we might get different results when sending the exact same message." How does this help sharing persistent objects?
While I applaud efforts on modernizing Smalltalk, I'm a bit reluctant of changes to the language semantics.
Though I have no problems with cleaning up Smalltalk's semantics (as should be obvious from my participation in the Self community), I did not include any such changes in my vision for Squeak. In fact, I also participate in the ANSI Smalltalk effort which would bring Squeak closer to the other Smalltalks rather than make even more different than it already is. I don't think changing how images are saved and loaded has any effect on the language semantics though it might change how you use it (just like adding virtual memory doesn't change C, but might allow a different programming style).
By changing the language semantics I meant what you say about sending the same message to the same object and getting different results... Doesn't that change language semantics?
[16 thousand SiliconSqueak cores]
Wow! Experimenting with such a system would be fantastic!
There are a few steps before we get there. I'll keep the community informed of any progress we make.
-- Jece
Thanks!
Cheers, Juan Vuletich
Juan Vuletich wrote:
Well, the part I didn't get was: "This image would support multiple simultaneous viewpoints such that if you have a pointer to an object and I have a pointer to the same object we might get different results when sending the exact same message." How does this help sharing persistent objects?
If my version of class ByteString is slightly different than the version of that class that you use, then some object that depends on it and which I send to you might break when you try it in your environment. If, on the other hand, it carries the changes it needs to ByteString and loads them into your environment then it will work just fine but might break other stuff. The solution I see is to allow different objects in your environment to "see" the same class as slightly different. Then the code you wrote yourself will work side by side with objects I shared with you.
By changing the language semantics I meant what you say about sending the same message to the same object and getting different results... Doesn't that change language semantics?
It can, like how Self was changed into Us by adding viewpoint operations as a fundamental language concept. But for Squeak I am thinking about having this mechanism stay more in the background. So it would allow you to do in a single image what you can now do using two separate images, but otherwise the language is the same.
-- Jecel
Clever title:)
I'm new around here, but here's a short list of things that I fancy (being the Fancy New Guy) doing with Squeak:
- Media. I want to kill Powerpoint. I've been playing around with a minimalist "app" which hopes to fool the user into thinking they're using a presentation program. I love how I can just drop things into my image and get objects to play with.
- Themes. Something like Polymorph, but leaner. Working on it.
- Music. I want to make music with Squeak. Has anyone heard of Siren or DynaPiano?
After this point, beware of crazy ideas...
- User interface. I want to jettison my desktop environment and live in a Squeak image all the time. I'm sick of hating things about my desktop environment, and finding that the cost of changing them is too high. This desire necessitates the following three research ideas...
- Embed Firefox or WebKit in the Squeak VM. - Implement a reparenting X11 window manager in Squeak, allowing it to run GTK apps (like Firefox) - Embed the v8 Javascript VM into the Squeak VM and then work on making Scamper standards compliant. I tried rolling v8 into a plugin a few months back, but found my ignorance of the Squeak VM to be a barrier.
I think that modelessness is the way to go. I still need web-mode, which is really the only thing (I want) that's hard to do entirely in Smalltalk.
This thread is a lot more fun than the one where we argue about who's ideas are *the* direction! :)
On Saturday, November 14, 2009, Andreas Raab andreas.raab@gmx.de wrote:
Folks -
I feel like the recent discussion about directions left us without much progress in terms of where we think Squeak is headed. I actually don't think this is particularly hard to formulate, since as we all know, Squeak will be headed where we make it head to. In other words, I think we could come up with a pretty good idea of where Squeak will be headed if those people who actually contribute tell a little bit more about their interests and directions. So let me be the first to start here:
My long-term vision for Squeak is to bring it back to being a medium for personal dynamic media. I want Squeak to be a fun, educational, small, dynamic, media-centric environment. My current immediate directions include:
Making the system be more modular. Adding the Morphic TextEditors, refactoring Project, being able to unload various packages are in line with that. Expect more from me in this area as time allows.
Figuring out how to load packages, projects, etc back in. I haven't done much about this yet, but we desperately need better tools for (roughly speaking) "loading apps". Squeakmap gets some things right, Universes address others, both aren't very well integrated with Monticello, and by the end of the day the UIs for all of them suck.
Restore the media facilities. I'd really like to see the next Squeak version bring back Speech, bring back Games, bring back Wonderland etc. All in loadable project form so that people can explore them based on a small initial foot print.
I'd be interested in hearing what others working on and in Squeak have to say about their own directions. Together it should give a pretty comprehensive understanding about where Squeak is headed in practice.
Cheers, - Andreas
- Music. I want to make music with Squeak. Has anyone heard of Siren
or DynaPiano?
see Musical Objects for Squeak, my own project: http://www.zogotounga.net/comp/squeak/sqgeo.htm
feedback welcome...
Stef
My long-term vision for Squeak is to bring it back to being a medium for personal dynamic media. I want Squeak to be a fun, educational, small, dynamic, media-centric environment.
Great. There is nothing like Squeak in that arena, that's where it belongs IMO.
I'd be interested in hearing what others working on and in Squeak have to say about their own directions.
I'm building on top of Squeak. The base you propose, a medium for personal dynamic media, is exactly what I need to be maintained. On top of that I'm developing a very dynamic and rather ambitious musical composition environment. It is a slow-paced long-term project, steadily evolved for almost ten years now (although it did not start in Squeak). My main need is that Squeak remains mostly backward-compatible, as it currently is (I'm talking about the trunk).
At the moment the only sore point I have is the lack of MIDI support in the linux VM.
Otherwise, rather pleased at the current spirit in squeak-dev.
best,
Stef
On Sat, Nov 14, 2009 at 03:28:49PM -0800, Andreas Raab wrote:
I'd be interested in hearing what others working on and in Squeak have to say about their own directions. Together it should give a pretty comprehensive understanding about where Squeak is headed in practice.
I plan to continue working on various Squeak projects in my spare time. In the future I would like to be able to do this as a retirement project if my brain holds out, possibly a few more years at the current rate of decline ;-)
I will continue maintaining my current projects (OSProcess, TimeZoneDatabase, etc) as well as contributing to VMMaker and Squeak trunk where I can. I would also like to contribute to updating Etoys and Squeak in a more coordinated way.
I think that multimedia capabilities make Squeak very appealing. I also like the extreme scalability of the environment, with everything from a Spoon minimal image up to 64-bit object memories, SqueakNOS up to large scale servers, and all done with an interpreter written mainly in Smalltalk.
I take a rather dim view of "professional software" in general, and that line of development does not interest me much. Well, except for Seaside and AIDA, which are great.
One of these days I'd like to try integrating Squeak with BCPL such that Squeak could be a host environment for BCPL/Cintpos and vice-versa.
Dave
On Sunday 15 November 2009 04:58:49 am Andreas Raab wrote:
Folks -
I feel like the recent discussion about directions left us without much progress in terms of where we think Squeak is headed. I actually don't think this is particularly hard to formulate, since as we all know, Squeak will be headed where we make it head to. In other words, I think we could come up with a pretty good idea of where Squeak will be headed if those people who actually contribute tell a little bit more about their interests and directions. So let me be the first to start here:
Thank you for the initiative. My own interests for Squeak are:
* Make Squeak run off removable flash memory devices gracefully. This will require elimination of redundant saves of project files (Squeaklets), use of RAM file systems for temporary directories, better integration with host's desktop manager dialogs, launchers that autodetect path settings before launching Squeak etc.
* Indic language support but without an explosion in the size of the image due to a profusion of fonts. ** TeX-like text layout engines in Squeak to handle multi-lingual paragraphs. ** Add Metafont-like capabilities to Squeak where one-time glyphs can be generated on the fly and saved in the image as a regular object. ** Extend Morphs to derive shapes from scripts like PS or SVG in preparation for a zoomable interface. ** Virtual keyboard and input methods
My dream is to see Squeak become a mobile digital environment for learners across the world that frees (atleast isolates) them from dependencies on specific machines, machine architecture and form factors.
Subbu
On 11/14/09 9:28 PM, "Andreas Raab" andreas.raab@gmx.de wrote:
Folks -
I feel like the recent discussion about directions left us without much progress in terms of where we think Squeak is headed. I actually don't think this is particularly hard to formulate, since as we all know, Squeak will be headed where we make it head to. In other words, I think we could come up with a pretty good idea of where Squeak will be headed if those people who actually contribute tell a little bit more about their interests and directions. So let me be the first to start here:
My long-term vision for Squeak is to bring it back to being a medium for personal dynamic media. I want Squeak to be a fun, educational, small, dynamic, media-centric environment. My current immediate directions include:
- Making the system be more modular. Adding the Morphic TextEditors,
refactoring Project, being able to unload various packages are in line with that. Expect more from me in this area as time allows.
- Figuring out how to load packages, projects, etc back in. I haven't
done much about this yet, but we desperately need better tools for (roughly speaking) "loading apps". Squeakmap gets some things right, Universes address others, both aren't very well integrated with Monticello, and by the end of the day the UIs for all of them suck.
- Restore the media facilities. I'd really like to see the next Squeak
version bring back Speech, bring back Games, bring back Wonderland etc. All in loadable project form so that people can explore them based on a small initial foot print.
I'd be interested in hearing what others working on and in Squeak have to say about their own directions. Together it should give a pretty comprehensive understanding about where Squeak is headed in practice.
Cheers,
- Andreas
I trying to do exact you are writing now, nice to see Master of Masters doing what I only dream.
Edgar
Hi Andreas, Hi All,
here's an interesting rant: http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html from one Jeff Bone. I think he's wrong on implementation and right on general direction. He wants current stuff (web, files, regular expressions) to be easy, but (IMO) he's wrong to think that the only way to get there is to put in direct linguistic support. Why this rant might be relevant to our discussion is that it shows what some current programmers look for in a system and that if one can do what he wants one has a better chance of competing to grow the community, and growing the community can help in reaching other goals.
Anyway, 2¢, grist to the mill, etc.
On 2009-11-16 21:22, Eliot Miranda wrote:
Hi Andreas, Hi All,
here's an interesting rant:http://www.xent.com/pipermail/fork/Week-of-Mon-20091109/054578.html from one Jeff Bone. I think he's wrong on implementation and right on general direction. He wants current stuff (web, files, regular expressions) to be easy, but (IMO) he's wrong to think that the only way to get there is to put in direct linguistic support. Why this rant might be relevant to our discussion is that it shows what some current programmers look for in a system and that if one can do what he wants one has a better chance of competing to grow the community, and growing the community can help in reaching other goals.
Anyway, 2¢, grist to the mill, etc.
+1000
Rant of the year!
Karl
On 11/14/2009 11:29 PM, Andreas Raab wrote:
Folks -
I feel like the recent discussion about directions left us without much progress in terms of where we think Squeak is headed. I actually don't think this is particularly hard to formulate, since as we all know, Squeak will be headed where we make it head to. In other words, I think we could come up with a pretty good idea of where Squeak will be headed if those people who actually contribute tell a little bit more about their interests and directions. So let me be the first to start here:
My long-term vision for Squeak is to bring it back to being a medium for personal dynamic media. I want Squeak to be a fun, educational, small, dynamic, media-centric environment. My current immediate directions include:
- Making the system be more modular. Adding the Morphic TextEditors,
refactoring Project, being able to unload various packages are in line with that. Expect more from me in this area as time allows.
- Figuring out how to load packages, projects, etc back in. I haven't
done much about this yet, but we desperately need better tools for (roughly speaking) "loading apps". Squeakmap gets some things right, Universes address others, both aren't very well integrated with Monticello, and by the end of the day the UIs for all of them suck.
- Restore the media facilities. I'd really like to see the next Squeak
version bring back Speech, bring back Games, bring back Wonderland etc. All in loadable project form so that people can explore them based on a small initial foot print.
I'd be interested in hearing what others working on and in Squeak have to say about their own directions. Together it should give a pretty comprehensive understanding about where Squeak is headed in practice.
Cheers, - Andreas
Thanks for starting this thread.
What I would like to see with Squeak and I really don't know how possible it is or what it would take or even if it would be acceptable and supported by the community. But here goes.
Presently I am writing an app that I would love to do in Squeak but cannot. Why Squeak? Simply because I love working within a live environment. I love the tools available for writing the code. I love being able to fix a problem live and continue on. Not starting all over.
But I am constrained. I am provided two options for my application. 1. Interface with a Windows COM library. 2. Interface with Java libraries.
I would love to see Squeak running on the JVM able to import and interoperate with native Java libraries. I would love to see Squeak give Jython or Clojure a run for their money. I would love to see Squeak enable more people to use less of Java. I would love to see Squeak enable more people to make a living within the constraints imposed upon them by the business world by using Squeak.
I really believe that the more people who can make a living using Squeak, the better the opportunities for Squeak to be those things the rest of the community would like. A thriving ecosystem with a healthy number of users enables a lot of things.
And like Andreas said in the Sophie thread,
This entirely line of arguments is one of the better reasons why "being popular" isn't such a bad thing :-)
I would love to see myself, Andreas and whomever not have to choose Python, etc. for some of the things that it gets chosen for. I would love to do those things in Squeak and better than I can do them in Python.
So presently I am using Python with win32 extensions to access the COM dll, writing data to a MongoDB, reading the MongoDB from Jython and passing the data to some Java libraries and then doing other stuff in Jython and passing data back to MongoDB and Python win32. :( But it works.
I don't know how much technically I can contribute to my vision above. But at a later time I would possibly be interested in finding out if it is reasonable to pay (fund) to have Squeak on the JVM.
And yes I know about the start that Dan made on that direction. But I don't know how complete it is. And if it meets all of the requirements.
I think this could get Squeak into the business world in a way that it currently cannot. I think this could also provide a potential migratory path for people who choose so to move away from Java but are constrained not due to technical reasons but political and bureaucratic. Why should we have a great Lisp dialect (Clojure) on the JVM and not have an equally good Squeak (Smalltalk)?
And then maybe we can win Sophie back to Squeak. :)
Just some of my thoughts.
Thanks.
Jimmie
I would like to see the following directions included for Squeak:
Modularity and minimal core - so that you can load what you want onto a minimal core and be sure that you can unload the same thing cleanly. If a newly loaded package provides a new version of a method when the existing version is absolutely required by another existing package, allow the previous version to remain usable alongside the new. This should all be done in such a manner as to hopefully minimize the need for forking, or think of all custom images as forks like Guilik just mentioned.
Along with the modularity, a convenient system of automatically loading your custom modifications, such as:
Automatic test and build server eg. Installer, 'Sake/Packages' and 'Bob the Builder'.
Simple method of logging your ongoing work and migrating all your current image state to a fresh image.
Remove the barriers to using the latest dev tools like MC and ensure various updates get merged into the externally managed and loadable/unloadable package.
Remove the barriers to loading/unloading things like Tweak, Sophie, EToys.
Good code execution visualization tool to help understand the way things work.
A bug/enhancement tracking system that people like to use.
Ken G. Brown
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
On Sun, Nov 29, 2009 at 4:42 PM, Eliot Miranda eliot.miranda@gmail.com 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
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.
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 leves@elte.hu wrote:
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.
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.
- 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, 29 Nov 2009, Eliot Miranda wrote:
On Sun, Nov 29, 2009 at 4:36 PM, Levente Uzonyi leves@elte.hu 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
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
askoh -
Bert Freudenberg -
Colin Putney -
David T. Lewis -
Edgar J. De Cleene -
Eliot Miranda -
Germán Arduino -
Igor Stasenko -
Jecel Assumpcao Jr -
Jimmie Houchin -
John M McIntosh -
Juan Vuletich -
K. K. Subramaniam -
Karl Ramberg -
Ken G. Brown -
Levente Uzonyi -
Marco Schmidt -
Martin McClure -
Matthew Fulmer -
merlyn＠stonehenge.com -
Miguel Enrique Cobá Martinez -
Nicolas Cellier -
Ralph Johnson -
Ramiro Diaz Trepat -
Ronald Spengler -
Stéphane Rollandin -
Travis Kay