On Fri, Dec 17, 2004 at 04:54:33PM +1100, Russell Penney wrote:
My plan is to have nearly everything written in Squeak with very basic primitives, that way it allows more control.
Fundamentally there are 3 classes: File handles file access Directory handles directory access FileSystem handles the raw access and provides a unified interface for Files and Directories.
Russell,
If you're going to do a complete rewrite, it would also be good to generalize the notion of an I/O channel for files, sockets, pipes, or whatever other external resources can be modeled in this way.
I took a step in this direction with IOHandle (on Squeak Map). This has not been updated for current Squeak, but I'll be happy to do so if you have an interest. IOHandle separates the representation of I/O channels such as files and sockets from the higher level stream and file system stuff.
On Squeak versions up through 3.6, you can install IOHandle to move all the low-level representations out of FileStream and Socket without breaking the old code (this is a bit tricky, because you have to be able to keep using the changes file while filing in the changes). To make it work on current Squeak, I would need to adapt it for the new Sockets classes, and redo the installation process.
You might also find some useful things in DirectoryPlugin on SM, although this is intended to support the current file system, and it's probably best to throw all of this out and start fresh.
Dave
Does ClosureCompiler have support for ScaledDecimal literals (3.1415s3)? I have loaded older version and I don't see it in the scanner definition.
Pavel
Am 17.12.2004 um 15:50 schrieb Pavel Krivanek:
Does ClosureCompiler have support for ScaledDecimal literals (3.1415s3)? I have loaded older version and I don't see it in the scanner definition.
The latest version on SqueakSource (project compiler) now has support for Scaled Decimals.
Marcus
Am 07.02.2005 um 16:21 schrieb Brent Pinkney:
The latest version on SqueakSource (project compiler) now has support for Scaled Decimals.
Does is have support for decompiing its BlockClosures yet ?
Not yet. But I'm starting to look again into that.
What now works is decompiling non-closure code to the IRBuilder representation. (This is nice to do transformations on bytecode... which in turn is useful for doing strange things without having to modify the vm).
On the todo list are
-> check bytecode-to-IR for closures -> fix IR to AST for closure -> fix IR to AST for non-closure (nearly done) -> implement better error messages -> and then lots of testing.
This would then be the point were it could be added to the image. After that:
-> look in speeding up the compilation (but it will always be slower then the old compiler, as it does more. e.g. building up IR graph) -> package up the old compiler for SqueakMap, remove it from the image.
Marcus
Hi,
What now works is decompiling non-closure code to the IRBuilder representation.
What is this ? Is is a new parse tree ?
(This is nice to do transformations on bytecode... which in turn is useful for doing strange things without having to modify the vm).
Aye, which is why I am interested in the decompiler.
look in speeding up the compilation (but it will always be slower then the old compiler, as it does more. e.g. building up IR graph)
Andreas's profile suggested a lot of time was in one method it the SmaccScanner.
Anyway, this is good to hear. Thanks
Brent
Am 08.02.2005 um 06:34 schrieb Brent Pinkney:
Hi,
What now works is decompiling non-closure code to the IRBuilder representation.
What is this ? Is is a new parse tree ?
Not a parsetree. It's an intermediate representation of Bytecode. It has the semantics of bytecode, but the abstration is one step higher, e.g. no hard-coded jumps but instead a controlflow encoded in a graph of basic blocks.
(This is nice to do transformations on bytecode... which in turn is useful for doing strange things without having to modify the vm).
Aye, which is why I am interested in the decompiler.
So this will be usable quite soon: Bytecode --> IR --> Transform --> Bytecode. I hope to have something usable and documented about that next week or so. I mean, it's nothing earth-shattering, but it's quite interesting how easy you can do experiments with this.
Marcus
Hi all--
Russell writes:
My plan is to have nearly everything written in Squeak with very basic primitives, that way it allows more control...
David writes:
If you're going to do a complete rewrite, it would also be good to generalize the notion of an I/O channel for files, sockets, pipes, or whatever other external resources can be modeled in this way.
I've done this with Flow ( http://netjam.org/flow ). I originally wrote it in 1997, first released it in 1998, and have been trying to get it into Squeak ever since, without much success. :) I've also spoken with both of you about it before, so I'm a little surprised it hasn't been mentioned in this conversation before now (not upset, just a little surprised :). I'm especially surprised that Tim didn't mention it, since he sat next to me while I implemented most of the MIDI support. :)
While Flow hasn't been widely adopted yet, it has had some influence, e.g., on the "network rewrite" that Michael Rueger did, distinguishing streams from their resources.
The current release features support for writing socket-based clients and servers, and for using files, speech synthesis and recognition, serial ports, and parallel ports. I've also written (but not yet released) support for bidirectional streams on MIDI ports, which I have found to be a lot of more convenient interface than the standard one. I'm also working on support for digital audio, firewire, USB and IR.
Flow is used by Squat ( http://netjam.org/squat ), a minimal Squeak system (minimal snapshot, minimal virtual machine, and module system using live peer-to-peer negotiation). The current release of Squat has a complete URI implementation with tests, written by asparagi.
For the record, I've mentioned all of this on this mailing list (squeak-dev) multiple times. :) I was holding off a little this week because I'm in the middle of renaming Squat to "Spoon", and I didn't want to cause any unnecessary confusion. 'Sorry if I've been too quiet, I've been working hard on this stuff instead of writing email... I guess one needs to say *something* to the list at least every few weeks, just so people still think you're alive. :)
thanks!
-C
p.s.
Russell, I've made encouraging noises about your Ogg implementation before, albeit on the the Squeak IRC channel and not on the squeak-dev list. :) Good work! While I'm at it... thanks, David, for CommandShell; I use it frequently. :)
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
Craig Latta craig@netjam.org wrote:
surprised :). I'm especially surprised that Tim didn't mention it, since he sat next to me while I implemented most of the MIDI support. :)
Err, umm, I wanted Russell to rediscover it for himself. Yes, that's it.
Flow is A Good Thing. As always, the hard part is persuading a large group of people to adopt something new, especially since it is a replacement not an add on. I don't see any particular problem with replacing all the prims, especially since they're in plugin(s) but getting package owners to rewrite to use new streams and so on.... I've never been able to think of a way round that part.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: IIB: Ignore Inquiry and Branch anyway
Hi guys
I'm not good (another area where I lack knowledge :( ) in streams and related. But this would be good if a group of experts can work on deciding whether flow should be pushed into squeak.
In the past I heard (I do not remember quite well) that flow was quite large and really changing a lot of stuff in a non-compatible way with a limited transition path.
Stef
surprised :). I'm especially surprised that Tim didn't mention it, since he sat next to me while I implemented most of the MIDI support. :)
Err, umm, I wanted Russell to rediscover it for himself. Yes, that's it.
Flow is A Good Thing. As always, the hard part is persuading a large group of people to adopt something new, especially since it is a replacement not an add on. I don't see any particular problem with replacing all the prims, especially since they're in plugin(s) but getting package owners to rewrite to use new streams and so on.... I've never been able to think of a way round that part.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: IIB: Ignore Inquiry and Branch anyway
I'm not good (another area where I lack knowledge :( ) in streams and related. But this would be good if a group of experts can work on deciding whether flow should be pushed into squeak. In the past I heard (I do not remember quite well) that flow was quite large and really changing a lot of stuff in a non-compatible way with a limited transition path.
Modularity, Namespaces and compatibility layers seem like the (only) way forward
This approach would also give the structure for compatibility with mainstream (and/or other dialects of) Smalltalk.
Probably a lot of work, although most likely worth it in the end.
Aaron
Here we go, answering myself, before anyone else does :)
Modularity, Namespaces and compatibility layers seem like the (only) way forward
Change sets are an alternative, and the mechanism for them is already there. But this does lead to the "many headed beast problem" :)
Or as mentioned prefixes, another simple solution.
This approach would also give the structure for compatibility with mainstream (and/or other dialects of) Smalltalk.
I would like to choose the dialect/libraries either squeaks, of Flow, or ...
Probably a lot of work, although most likely worth it in the end.
Probably still worth it in the end, as modularity and namespaces would solve many compatibility problems neatly.
And this would tame the beast...
Aaron
Aaron Gray wrote:
Here we go, answering myself, before anyone else does :)
Modularity, Namespaces and compatibility layers seem like the (only) way forward
Change sets are an alternative,
Unfortunately not, as the fact that Craig's work didn't get wider adoption since 1999 proves. ChangeSets are patches.
and the mechanism for them is already there.
The mechanism for loading a Monticello package (through the SqueakMap package loader and directly) is here as well for some time and it works fine! We do not depend on the update stream (patching, patching, patching .....) alone to build a more capable system.
We are actually at the beginning of the phase where I can get a base image and add the packages I want. The packages have their independant people working on them and their independant release schedule.
This applies even for an infrastructure package like a New FileSystem.
Hannes
On Fri, 17 Dec 2004 11:00:49 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
Flow is A Good Thing. As always, the hard part is persuading a large group of people to adopt something new, especially since it is a replacement not an add on. I don't see any particular problem with replacing all the prims, especially since they're in plugin(s) but getting package owners to rewrite to use new streams and so on.... I've never been able to think of a way round that part.
I've advocated this in the past without any success, but I might as well try again: the way to get people to adopt Flow is to make it possible for them to use it side by side with the existing streams, so that they can migrate to it incrementally without anything needing to be broken during the process. All this means, I think, is prefixing Flow's classes so that they can coexist in the image with the old Stream implementation. Yes, there's something aesthetically unpleasing about having FlowStream or FStream instead of just Stream, but if adoption is actually a goal it seems a small price to pay.
Avi
On Dec 17, 2004, at 7:47 PM, Avi Bryant wrote:
On Fri, 17 Dec 2004 11:00:49 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
Flow is A Good Thing. As always, the hard part is persuading a large group of people to adopt something new, especially since it is a replacement not an add on. I don't see any particular problem with replacing all the prims, especially since they're in plugin(s) but getting package owners to rewrite to use new streams and so on.... I've never been able to think of a way round that part.
I've advocated this in the past without any success, but I might as well try again: the way to get people to adopt Flow is to make it possible for them to use it side by side with the existing streams, so that they can migrate to it incrementally without anything needing to be broken during the process. All this means, I think, is prefixing Flow's classes so that they can coexist in the image with the old Stream implementation. Yes, there's something aesthetically unpleasing about having FlowStream or FStream instead of just Stream, but if adoption is actually a goal it seems a small price to pay.
I concur. One other suggestion: either have Flow use the existing primitives (as John mentioned) or distribute the Flow plugin as part of the standard VM install. No one will want to switch if it creates a VM-level dependency for their package.
Colin
Avi Bryant wrote:
On Fri, 17 Dec 2004 11:00:49 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
Flow is A Good Thing. As always, the hard part is persuading a large group of people to adopt something new, especially since it is a replacement not an add on..
....
the way to get people to adopt Flow is to make it possible for them to use it side by side with the existing streams, so that they can migrate to it incrementally without anything needing to be broken during the process.
All this means, I think, is prefixing Flow's classes so that they can coexist in the image with the old Stream implementation.
Yes, there's something aesthetically unpleasing about having FlowStream or FStream instead of just Stream, but if adoption is actually a goal it seems a small price to pay.
Avi
I fully agree (100%). If Flow would be available as a package on SqueakMap compatible with 3.8 (with the class names prefixed) I would start using it right away. And my old code would still work. As I gain confidence in the New File System I can port the code gradually.
When Craig first released it in 1998 I was not in a position to choose without the risk of having porting issues every time a new version of Squeak comes out.
Today with a package system in place it is up to the individual developer to choose if he wants to use a package to build on or not. Of course this depends on the level of confidence that versions will be maintainded to be compatible with future Squeak core releases.
Hannes
I agree with Avi. So please think about transition.
Flow is A Good Thing. As always, the hard part is persuading a large group of people to adopt something new, especially since it is a replacement not an add on. I don't see any particular problem with replacing all the prims, especially since they're in plugin(s) but getting package owners to rewrite to use new streams and so on.... I've never been able to think of a way round that part.
I've advocated this in the past without any success, but I might as well try again: the way to get people to adopt Flow is to make it possible for them to use it side by side with the existing streams, so that they can migrate to it incrementally without anything needing to be broken during the process. All this means, I think, is prefixing Flow's classes so that they can coexist in the image with the old Stream implementation. Yes, there's something aesthetically unpleasing about having FlowStream or FStream instead of just Stream, but if adoption is actually a goal it seems a small price to pay.
Avi
Hi all--
Avi writes:
I've advocated this in the past without any success, but I might as well try again: the way to get people to adopt Flow is to make it possible for them to use it side by side with the existing streams, so that they can migrate to it incrementally without anything needing to be broken during the process.
(I've said the following before as well. :)
In August 2002, when I released Flow for Squeak 3.2, I decided that, rather than continuing to chase the moving target of the conventional accretive-growth snapshot (AKA the Bloat snapshot :), it'd be better to solve the modularity and minimal-core problems first. So, that was the last release of Flow I made for the conventional snapshot, and I started the Squat project ( http://netjam.org/squat ). In the meantime, I encouraged people to do port things to use Flow in a separate snapshot (e.g., the one I provided in the Flow release). I didn't agree that everything old and new should have to run at the same time in the same snapshot, during the porting process.
I hope it's clear that I'm no longer trying to get Flow into the Squeak 1, 2, or 3 series; I gave up on that in 2002. Instead, I'm helping to attack the more fundamental issue of developing a minimal core into which one may load modules. Ideally, that will be Squeak 4 or 5 (depending on the timing of other pent-up features like the new compiler and compiled method format). Then, I can release Flow as an optional module (and not as changesets or other static artifacts). (The Squat minimal snapshot does use a few elements of Flow, but they can be unloaded; I don't think Squat's partial use of Flow for bootstrapping is a salient point in this discussion.)
So, to Stéphane, who writes...
I agree with Avi. So please think about transition.
...I respond that my transition plan is to first solve the underlying system organization problems. I think having a minimal core and peer-to-peer module installation will solve the problems of accretion and name conflicts that made installing low-level frameworks like Flow so problematic.
When I reminded people of Flow in this thread, I didn't mean to advocate its literal inclusion in the Squeak 3 series; I apologize if I gave that impression. But it's true that until we've made a transition to a minimal core, using Flow as currently released does indeed require work (unless one wants to work in a 3.2 snapshot, which I wouldn't expect). This just inspires me all the more to work on the minimal system.
There's also the matter of how my ideas for packaging jibe with those of SqueakMap and Monticello. While I intend to address these in detail in a different thread, the short summary is this:
When the Guides were formed in November 2002, and the community started trying to define the content of particular packages, I'd hoped that the major result would be finding the boundaries between packages, without getting too set on the form of the package artifacts. But of course, they had to take some form, and they did. And time passed while I did the first round of work on the minimal core and how to add to it. So, I now find myself in the awkward position of having an alternate form to propose, despite the fact that there are now many package artifacts in existence in new-since-2002 "de facto" forms. I think what saves things here are the technical aspects of what I propose (the peer-to-peer negotiation stuff).
But it's because of that awkward position that I intend Squat to be a future version of Squeak if people want that, or a fork otherwise (or rather, a Spoon :). I don't mean to imply any particular value judgement about forking; it's just that if I'm going to share my minimal-system work and it's not official Squeak, I shouldn't call it Squeak. :)
thanks for reading,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
Hi Craig,
I am really glad to know that you are still working on a truly minimal image.
Avi writes:
I've advocated this in the past without any success, but I might as well try again: the way to get people to adopt Flow is to make it possible for them to use it side by side with the existing streams, so that they can migrate to it incrementally without anything needing to be broken during the process.
(I've said the following before as well. :)
In August 2002, when I released Flow for Squeak 3.2, I decided that, rather than continuing to chase the moving target of the conventional accretive-growth snapshot (AKA the Bloat snapshot :), it'd be better to solve the modularity and minimal-core problems first. So, that was the last release of Flow I made for the conventional snapshot, and I started the Squat project ( http://netjam.org/squat ). In the meantime, I encouraged people to do port things to use Flow in a separate snapshot (e.g., the one I provided in the Flow release). I didn't agree that everything old and new should have to run at the same time in the same snapshot, during the porting process.
I hope it's clear that I'm no longer trying to get Flow into the Squeak 1, 2, or 3 series; I gave up on that in 2002. Instead, I'm helping to attack the more fundamental issue of developing a minimal core into which one may load modules. Ideally, that will be Squeak 4 or 5 (depending on the timing of other pent-up features like the new compiler and compiled method format). Then, I can release Flow as an optional module (and not as changesets or other static artifacts). (The Squat minimal snapshot does use a few elements of Flow, but they can be unloaded; I don't think Squat's partial use of Flow for bootstrapping is a salient point in this discussion.)
So, to Stéphane, who writes...
I agree with Avi. So please think about transition.
...I respond that my transition plan is to first solve the underlying system organization problems. I think having a minimal core and peer-to-peer module installation will solve the problems of accretion and name conflicts that made installing low-level frameworks like Flow so problematic.
When I reminded people of Flow in this thread, I didn't mean to advocate its literal inclusion in the Squeak 3 series; I apologize if I gave that impression. But it's true that until we've made a transition to a minimal core, using Flow as currently released does indeed require work (unless one wants to work in a 3.2 snapshot, which I wouldn't expect). This just inspires me all the more to work on the minimal system.
There's also the matter of how my ideas for packaging jibe with those of SqueakMap and Monticello.
While I intend to address these in detail in a different thread,
I am looking forward to this thread.
the short summary is this:
When the Guides were formed in November 2002, and the community started trying to define the content of particular packages, I'd hoped that the major result would be finding the boundaries between packages, without getting too set on the form of the package artifacts. But of course, they had to take some form, and they did. And time passed while I did the first round of work on the minimal core and how to add to it. So, I now find myself in the awkward position of having an alternate form to propose, despite the fact that there are now many package artifacts in existence in new-since-2002 "de facto" forms. I think what saves things here are the technical aspects of what I propose (the peer-to-peer negotiation stuff).
But it's because of that awkward position that I intend Squat to be a future version of Squeak if people want that, or a fork otherwise (or rather, a Spoon :). I don't mean to imply any particular value judgement about forking; it's just that if I'm going to share my minimal-system work and it's not official Squeak, I shouldn't call it Squeak. :)
What's the current status of Spoon ? Is it available online ?
Cheers,
PhiHo.
Am 18.12.2004 um 12:32 schrieb SmallSqueak:
Hi Craig,
I am really glad to know that you are still working on a truly minimal image.
Indeed :)
What's the current status of Spoon ? Is it available online ?
http://www.netjam.org/squat/releases/current/
- Bert -
Bert Freudenberg wrote:
What's the current status of Spoon ? Is it available online ?
I think this is the old version Feb 2004.
Thanks,
PhiHo.
Hi--
PhiHo: What's the current status of Spoon? Is it available online? Bert: http://www.netjam.org/squat/releases/current/ PhiHo: I think this is the old version Feb 2004.
That is indeed the most recent release (although it has patches made as recently as August 2004). I do have new bits to release; I plan to make another 14 February release, and subsequent releases on equinoxes and solstices (this very message will have to suffice for the solstice we're about to have :).
thanks,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
Avi Bryant avi.bryant@gmail.com wrote:
All this means, I think, is prefixing Flow's classes so that they can coexist in the image with the old Stream implementation. Yes, there's something aesthetically unpleasing about having FlowStream or FStream instead of just Stream, but if adoption is actually a goal it seems a small price to pay.
And of course my little Namespace mechanism would make it look nicer. :)
Still wondering btw why Stephane and the others didn't think my Namespaces were any good.
regards, Göran
squeak-dev@lists.squeakfoundation.org
-
Aaron Gray -
Avi Bryant -
Bert Freudenberg -
Brent Pinkney -
Colin Putney -
Craig Latta -
David T. Lewis -
goran.krampe＠bluefish.se -
Hannes Hirzel -
Marcus Denker -
Pavel Krivanek -
SmallSqueak -
stéphane ducasse -
Tim Rowledge