Xtreams : first embryonary port on Squeak
Locked
Xtreams : first embryonary port on Squeak
 
|
So, I started a quick port of VW Xtreams to Squeak this evening.
Only the Xtreams-Core and the trivial Xtreams-Terminals (no file/pipe/socket/pointer). You'll find code at http://www.squeaksource.com/XTream. My previous experimental Xtream project has been renamed SqueaXTream to reduce confusion, but still sits in the same project. Please find my report below. cheers Nicolas --------------------- REPORT --------------------- THE CONTENTS: This first port is made of 3 packages - Xtreams-Core - Xtreams-Terminals - Xtreams-VWCompatible Plus 2 tests - Xtreams-CoreTests - Xtreams-TerminalsTests Please notice I removed one hyphen from test package names for MC compatibility. THE PROCEDURE: I didn't use FileOut30 not any more advanced tool, but just a simple copy/paste strategy. This gave me a chance to do a fast review of code. For porting the future evolutions of VW Xtreams, more advanced tools will be necessary, the manual approach does not scale. THE MODIFICATIONS: The changes I made are quite restricted, which indicates that Xtreams is not that hard to port. Main changes are due to lack of namespace in Squeak: - I added a XT prefix to every Xtreams classes (no Namespace in Squeak) - I added XTPools, a SharedPool for holding the single Xtreams namespace variable DefaultBufferSize - I transformed class SharedVariables into class variables and added proper class side initialization for these in XTWriteStream For the rest, I tried to not change Xtreams contents. but rather did implement VW compatible messages when possible in the Xtreams-VWCompatible package when they did not exist in Squeak. These message are a full rewrite and are also released under MIT license. The few exceptions are: - I modified originator -> self originator in XTIncomplete. - I changed the senders of #newInFixedSpace: to rather send an #error: 'not implemented in Squeak' in XTRecyclingBuffer - I replaced #waitIfCurtailedSignal/#signal with a #critical: section in XTRecyclingBuffer - I replaced Core.Timer after:do: with self after:do: in Xtreams-CoreTests A DISCUSSION OF TECHNICAL DETAILS: I first attempted to replace #growToAtLeast: with #grownBy: because Squeak become: is notoriously inefficient. But obviously, this did not work, the tests rely on destination preserving its identity. This clearly is going to degrade micro benchmarks when the destination collection capacity is not well adjusted in advance. I think we should discuss this particular point. Is identity preservation absolutely required, or just convenient ? THE STATUS OF TESTS: Tests do not all pass. There seems to be a bug in Squeak #replace:from:to:with: when the replacement is the collection itself, moved to the right (this is with a COG VM). THE FUTURE: I will probably continue porting with reduced activity, so I invite any interested person to help. Right now, the project is world writeable, code commited here falling under MIT license. |
Re: Xtreams : first embryonary port on Squeak
|
|
On Sat, Oct 9, 2010 at 3:33 PM, Nicolas Cellier <[hidden email]> wrote: So, I started a quick port of VW Xtreams to Squeak this evening. It might be cool to create a subclass of Association, say VariableBindingWithInitializer, that holds an initializer method or block, and see how much work it takes to support. For example a SharedPool's default class>side initialize method could be to enumerate its variables and run initializers on any that answer true to, say, hasInitializer.
|
Re: Xtreams : first embryonary port on Squeak
|
|
In reply to this post by Nicolas Cellier
On Sun, 10 Oct 2010, Nicolas Cellier wrote:
> So, I started a quick port of VW Xtreams to Squeak this evening. > Only the Xtreams-Core and the trivial Xtreams-Terminals (no > file/pipe/socket/pointer). > You'll find code at http://www.squeaksource.com/XTream. > My previous experimental Xtream project has been renamed SqueaXTream > to reduce confusion, but still sits in the same project. > Please find my report below. Great. :) > > cheers > > Nicolas > > --------------------- REPORT --------------------- > > THE CONTENTS: > > This first port is made of 3 packages > - Xtreams-Core > - Xtreams-Terminals > - Xtreams-VWCompatible > Plus 2 tests > - Xtreams-CoreTests > - Xtreams-TerminalsTests > Please notice I removed one hyphen from test package names for MC compatibility. > > THE PROCEDURE: > > I didn't use FileOut30 not any more advanced tool, but just a simple > copy/paste strategy. > This gave me a chance to do a fast review of code. > For porting the future evolutions of VW Xtreams, more advanced tools > will be necessary, the manual approach does not scale. If you can create a diff from the VW changes, then porting "by hand" shouldn't be hard. > > THE MODIFICATIONS: > > The changes I made are quite restricted, which indicates that Xtreams > is not that hard to port. > Main changes are due to lack of namespace in Squeak: > - I added a XT prefix to every Xtreams classes (no Namespace in Squeak) > - I added XTPools, a SharedPool for holding the single Xtreams > namespace variable DefaultBufferSize > - I transformed class SharedVariables into class variables and added > proper class side initialization for these in XTWriteStream > > For the rest, I tried to not change Xtreams contents. but rather did > implement VW compatible messages when possible in the > Xtreams-VWCompatible package when they did not exist in Squeak. > These message are a full rewrite and are also released under MIT license. > The few exceptions are: > - I modified originator -> self originator in XTIncomplete. > - I changed the senders of #newInFixedSpace: to rather send an #error: > 'not implemented in Squeak' in XTRecyclingBuffer > - I replaced #waitIfCurtailedSignal/#signal with a #critical: section > in XTRecyclingBuffer > - I replaced Core.Timer after:do: with self after:do: in Xtreams-CoreTests > > A DISCUSSION OF TECHNICAL DETAILS: > > I first attempted to replace #growToAtLeast: with #grownBy: because > Squeak become: is notoriously inefficient. > But obviously, this did not work, the tests rely on destination > preserving its identity. > This clearly is going to degrade micro benchmarks when the destination > collection capacity is not well adjusted in advance. > I think we should discuss this particular point. Is identity > preservation absolutely required, or just convenient ? I've never seen a real world example where this identity preservation was useful, but it causes trouble when literals aren't immutable. IMHO the #become: send is just convenient with VW's stream implementation and it has no advantage over Squeak's approach. > > THE STATUS OF TESTS: > > Tests do not all pass. There seems to be a bug in Squeak > #replace:from:to:with: when the replacement is the collection itself, > moved to the right (this is with a COG VM). #replace:from:to:with: is not supposed to work for moves. IIRC the primitive version uses memcpy (or strncpy), so moving to the left works just because the undelying C function supports it. I used to (ab)use this feature though. Levente > > THE FUTURE: > > I will probably continue porting with reduced activity, so I invite > any interested person to help. Right now, the project is world > writeable, code commited here falling under MIT license. > > |
Re: Xtreams : first embryonary port on Squeak
|
|
In reply to this post by Nicolas Cellier
thanks nicolas
Stef On Oct 10, 2010, at 12:33 AM, Nicolas Cellier wrote: > So, I started a quick port of VW Xtreams to Squeak this evening. > Only the Xtreams-Core and the trivial Xtreams-Terminals (no > file/pipe/socket/pointer). > You'll find code at http://www.squeaksource.com/XTream. > My previous experimental Xtream project has been renamed SqueaXTream > to reduce confusion, but still sits in the same project. > Please find my report below. > > cheers > > Nicolas > > --------------------- REPORT --------------------- > > THE CONTENTS: > > This first port is made of 3 packages > - Xtreams-Core > - Xtreams-Terminals > - Xtreams-VWCompatible > Plus 2 tests > - Xtreams-CoreTests > - Xtreams-TerminalsTests > Please notice I removed one hyphen from test package names for MC compatibility. > > THE PROCEDURE: > > I didn't use FileOut30 not any more advanced tool, but just a simple > copy/paste strategy. > This gave me a chance to do a fast review of code. > For porting the future evolutions of VW Xtreams, more advanced tools > will be necessary, the manual approach does not scale. > > THE MODIFICATIONS: > > The changes I made are quite restricted, which indicates that Xtreams > is not that hard to port. > Main changes are due to lack of namespace in Squeak: > - I added a XT prefix to every Xtreams classes (no Namespace in Squeak) > - I added XTPools, a SharedPool for holding the single Xtreams > namespace variable DefaultBufferSize > - I transformed class SharedVariables into class variables and added > proper class side initialization for these in XTWriteStream > > For the rest, I tried to not change Xtreams contents. but rather did > implement VW compatible messages when possible in the > Xtreams-VWCompatible package when they did not exist in Squeak. > These message are a full rewrite and are also released under MIT license. > The few exceptions are: > - I modified originator -> self originator in XTIncomplete. > - I changed the senders of #newInFixedSpace: to rather send an #error: > 'not implemented in Squeak' in XTRecyclingBuffer > - I replaced #waitIfCurtailedSignal/#signal with a #critical: section > in XTRecyclingBuffer > - I replaced Core.Timer after:do: with self after:do: in Xtreams-CoreTests > > A DISCUSSION OF TECHNICAL DETAILS: > > I first attempted to replace #growToAtLeast: with #grownBy: because > Squeak become: is notoriously inefficient. > But obviously, this did not work, the tests rely on destination > preserving its identity. > This clearly is going to degrade micro benchmarks when the destination > collection capacity is not well adjusted in advance. > I think we should discuss this particular point. Is identity > preservation absolutely required, or just convenient ? > > THE STATUS OF TESTS: > > Tests do not all pass. There seems to be a bug in Squeak > #replace:from:to:with: when the replacement is the collection itself, > moved to the right (this is with a COG VM). > > THE FUTURE: > > I will probably continue porting with reduced activity, so I invite > any interested person to help. Right now, the project is world > writeable, code commited here falling under MIT license. > |
Re: [vwnc] Xtreams : first embryonary port on Squeak
|
|
In reply to this post by Nicolas Cellier
>
> I first attempted to replace #growToAtLeast: with #grownBy: because > Squeak become: is notoriously inefficient. > But obviously, this did not work, the tests rely on destination > preserving its identity. > This clearly is going to degrade micro benchmarks when the destination > collection capacity is not well adjusted in advance. > I think we should discuss this particular point. Is identity > preservation absolutely required, or just convenient ? Which tests? I'd be in favor of removing that assumption. Michael |
Re: Xtreams : first embryonary port on Squeak
|
|
In reply to this post by Levente Uzonyi-2
2010/10/10 Levente Uzonyi <[hidden email]>:
> On Sun, 10 Oct 2010, Nicolas Cellier wrote: > snip... > >> >> THE STATUS OF TESTS: >> >> Tests do not all pass. There seems to be a bug in Squeak >> #replace:from:to:with: when the replacement is the collection itself, >> moved to the right (this is with a COG VM). > > #replace:from:to:with: is not supposed to work for moves. IIRC the primitive > version uses memcpy (or strncpy), so moving to the left works just because > the undelying C function supports it. I used to (ab)use this feature though. > > > Levente > Shouldn't we use memmove then ? Nicolas |
Re: [vwnc] Xtreams : first embryonary port on Squeak
|
|
In reply to this post by Michael Lucas-Smith-2
2010/10/10 Michael Lucas-Smith <[hidden email]>:
>> >> I first attempted to replace #growToAtLeast: with #grownBy: because >> Squeak become: is notoriously inefficient. >> But obviously, this did not work, the tests rely on destination >> preserving its identity. >> This clearly is going to degrade micro benchmarks when the destination >> collection capacity is not well adjusted in advance. >> I think we should discuss this particular point. Is identity >> preservation absolutely required, or just convenient ? > > Which tests? I'd be in favor of removing that assumption. > > Michael > This is in: CollectionReadingWritingTest>>setUp | buffer | buffer := XTElasticBuffer on: ByteArray new. input := buffer reading. output := buffer writing. The expectation is that the buffer will be shared between input and output. If output modifies a copy of buffer, then the tests fail (input is empty or partial or too long if WriteStream>>#close did not perform a #become: ) Nicolas |
Re: Xtreams : first embryonary port on Squeak
|
|
In reply to this post by Levente Uzonyi-2
2010/10/10 Levente Uzonyi <[hidden email]>:
> On Sun, 10 Oct 2010, Nicolas Cellier wrote: > >> >> THE STATUS OF TESTS: >> >> Tests do not all pass. There seems to be a bug in Squeak >> #replace:from:to:with: when the replacement is the collection itself, >> moved to the right (this is with a COG VM). > > #replace:from:to:with: is not supposed to work for moves. IIRC the primitive > version uses memcpy (or strncpy), so moving to the left works just because > the undelying C function supports it. I used to (ab)use this feature though. > > > Levente > OK, since we use memcpy rather than memmove in Squeak VM, I implemented the trivial work around - move through a motionBuffer temporary copy. I now have a single test failing, XTCollectionWriteStream>>#testReadWriteLargeAmount and this must be due to my #after:do: simplistic implementation. Messing with #fork in SUnit TestCase is tricky, and I need help on this point. Nicolas |
Re: Xtreams : first embryonary port on Squeak
|
|
In reply to this post by Nicolas Cellier
This still seems confusing. Could we just have a new SqueakSource
project called "Xtreams" (small T + an S)? It's not like projects are expensive to create... Julian On Sat, Oct 9, 2010 at 11:33 PM, Nicolas Cellier <[hidden email]> wrote: > So, I started a quick port of VW Xtreams to Squeak this evening. > Only the Xtreams-Core and the trivial Xtreams-Terminals (no > file/pipe/socket/pointer). > You'll find code at http://www.squeaksource.com/XTream. > My previous experimental Xtream project has been renamed SqueaXTream > to reduce confusion, but still sits in the same project. > Please find my report below. |
Re: Xtreams : first embryonary port on Squeak
|
|
I think it should go the way Seaside is handled. Something like
'Grease' and 'Sport' *** on top of Squeak and the go to the original code base. Not a fork of the code for the library. Maybe Grease and Sport are good enough to have compatibility? --Hannes Sport and Grease cover different areas with their portability APIs. Sport covers Sockets, Files, Time, Exception handling and utilities such as being able to explicitly test in which Smalltalk dialect code is being run in. Grease covers utilities for parsing, printing, encoding & decoding strings, delayed sends, common exceptions, utilities such as secure hash. There is some overlap, but not much. For example, Seaside expects the underlying HTTP server to deal with socket issues so Grease does not deal with sockets. Sport in turn does not have the extensive parsing and printing facilities found in Grease. On 10/11/10, Julian Fitzell <[hidden email]> wrote: > This still seems confusing. Could we just have a new SqueakSource > project called "Xtreams" (small T + an S)? It's not like projects are > expensive to create... > > Julian > > On Sat, Oct 9, 2010 at 11:33 PM, Nicolas Cellier > <[hidden email]> wrote: >> So, I started a quick port of VW Xtreams to Squeak this evening. >> Only the Xtreams-Core and the trivial Xtreams-Terminals (no >> file/pipe/socket/pointer). >> You'll find code at http://www.squeaksource.com/XTream. >> My previous experimental Xtream project has been renamed SqueaXTream >> to reduce confusion, but still sits in the same project. >> Please find my report below. > > |
Re: Xtreams : first embryonary port on Squeak
|
|
I wasn't suggesting forking (I had another post in this thread talking
about Grease). But even Seaside exists both in SqueakSource and in the Cincom Public Store. I was merely asking if the the appropriate project name couldn't be used in SqueakSource. Using a slight variation (and having two projects in the one repo) is just confusing. Julian On Mon, Oct 11, 2010 at 12:29 PM, Hannes Hirzel <[hidden email]> wrote: > I think it should go the way Seaside is handled. Something like > 'Grease' and 'Sport' *** on top of Squeak and the go to the original > code base. Not a fork of the code for the library. > > Maybe Grease and Sport are good enough to have compatibility? > > --Hannes > > > Sport and Grease cover different areas with their portability APIs. > Sport covers Sockets, Files, Time, Exception handling and utilities > such as being able to explicitly test in which Smalltalk dialect code > is being run in. Grease covers utilities for parsing, printing, > encoding & decoding strings, delayed sends, common exceptions, > utilities such as secure hash. There is some overlap, but not much. > For example, Seaside expects the underlying HTTP server to deal with > socket issues so Grease does not deal with sockets. Sport in turn does > not have the extensive parsing and printing facilities found in > Grease. > > On 10/11/10, Julian Fitzell <[hidden email]> wrote: >> This still seems confusing. Could we just have a new SqueakSource >> project called "Xtreams" (small T + an S)? It's not like projects are >> expensive to create... >> >> Julian >> >> On Sat, Oct 9, 2010 at 11:33 PM, Nicolas Cellier >> <[hidden email]> wrote: >>> So, I started a quick port of VW Xtreams to Squeak this evening. >>> Only the Xtreams-Core and the trivial Xtreams-Terminals (no >>> file/pipe/socket/pointer). >>> You'll find code at http://www.squeaksource.com/XTream. >>> My previous experimental Xtream project has been renamed SqueaXTream >>> to reduce confusion, but still sits in the same project. >>> Please find my report below. >> >> > > |
Re: Xtreams : first embryonary port on Squeak
|
|
Thank you Julian for the clarification.
Yes, -- using a slight variation and having two projects in the same repository is confusing. And -- having Xtreams (is this the correct name?) for Squeak is exciting! --Hannes On 10/11/10, Julian Fitzell <[hidden email]> wrote: > I wasn't suggesting forking (I had another post in this thread talking > about Grease). > > But even Seaside exists both in SqueakSource and in the Cincom Public > Store. I was merely asking if the the appropriate project name > couldn't be used in SqueakSource. Using a slight variation (and having > two projects in the one repo) is just confusing. > > Julian > > On Mon, Oct 11, 2010 at 12:29 PM, Hannes Hirzel <[hidden email]> > wrote: >> I think it should go the way Seaside is handled. Something like >> 'Grease' and 'Sport' *** on top of Squeak and the go to the original >> code base. Not a fork of the code for the library. >> >> Maybe Grease and Sport are good enough to have compatibility? >> >> --Hannes >> >> >> Sport and Grease cover different areas with their portability APIs. >> Sport covers Sockets, Files, Time, Exception handling and utilities >> such as being able to explicitly test in which Smalltalk dialect code >> is being run in. Grease covers utilities for parsing, printing, >> encoding & decoding strings, delayed sends, common exceptions, >> utilities such as secure hash. There is some overlap, but not much. >> For example, Seaside expects the underlying HTTP server to deal with >> socket issues so Grease does not deal with sockets. Sport in turn does >> not have the extensive parsing and printing facilities found in >> Grease. >> >> On 10/11/10, Julian Fitzell <[hidden email]> wrote: >>> This still seems confusing. Could we just have a new SqueakSource >>> project called "Xtreams" (small T + an S)? It's not like projects are >>> expensive to create... >>> >>> Julian >>> >>> On Sat, Oct 9, 2010 at 11:33 PM, Nicolas Cellier >>> <[hidden email]> wrote: >>>> So, I started a quick port of VW Xtreams to Squeak this evening. >>>> Only the Xtreams-Core and the trivial Xtreams-Terminals (no >>>> file/pipe/socket/pointer). >>>> You'll find code at http://www.squeaksource.com/XTream. >>>> My previous experimental Xtream project has been renamed SqueaXTream >>>> to reduce confusion, but still sits in the same project. >>>> Please find my report below. >>> >>> >> >> > > |
Re: Xtreams : first embryonary port on Squeak
|
|
done
2010/10/11 Hannes Hirzel <[hidden email]>: > Thank you Julian for the clarification. > > Yes, -- using a slight variation and having two projects in the same > repository is confusing. > > And -- having Xtreams (is this the correct name?) for Squeak is exciting! > > --Hannes > > On 10/11/10, Julian Fitzell <[hidden email]> wrote: >> I wasn't suggesting forking (I had another post in this thread talking >> about Grease). >> >> But even Seaside exists both in SqueakSource and in the Cincom Public >> Store. I was merely asking if the the appropriate project name >> couldn't be used in SqueakSource. Using a slight variation (and having >> two projects in the one repo) is just confusing. >> >> Julian >> >> On Mon, Oct 11, 2010 at 12:29 PM, Hannes Hirzel <[hidden email]> >> wrote: >>> I think it should go the way Seaside is handled. Something like >>> 'Grease' and 'Sport' *** on top of Squeak and the go to the original >>> code base. Not a fork of the code for the library. >>> >>> Maybe Grease and Sport are good enough to have compatibility? >>> >>> --Hannes >>> >>> >>> Sport and Grease cover different areas with their portability APIs. >>> Sport covers Sockets, Files, Time, Exception handling and utilities >>> such as being able to explicitly test in which Smalltalk dialect code >>> is being run in. Grease covers utilities for parsing, printing, >>> encoding & decoding strings, delayed sends, common exceptions, >>> utilities such as secure hash. There is some overlap, but not much. >>> For example, Seaside expects the underlying HTTP server to deal with >>> socket issues so Grease does not deal with sockets. Sport in turn does >>> not have the extensive parsing and printing facilities found in >>> Grease. >>> >>> On 10/11/10, Julian Fitzell <[hidden email]> wrote: >>>> This still seems confusing. Could we just have a new SqueakSource >>>> project called "Xtreams" (small T + an S)? It's not like projects are >>>> expensive to create... >>>> >>>> Julian >>>> >>>> On Sat, Oct 9, 2010 at 11:33 PM, Nicolas Cellier >>>> <[hidden email]> wrote: >>>>> So, I started a quick port of VW Xtreams to Squeak this evening. >>>>> Only the Xtreams-Core and the trivial Xtreams-Terminals (no >>>>> file/pipe/socket/pointer). >>>>> You'll find code at http://www.squeaksource.com/XTream. >>>>> My previous experimental Xtream project has been renamed SqueaXTream >>>>> to reduce confusion, but still sits in the same project. >>>>> Please find my report below. >>>> >>>> >>> >>> >> >> > > |
Re: Xtreams : first embryonary port on Squeak
|
|
Thanks Nicolas.
Julian On 10/11/10, Nicolas Cellier <[hidden email]> wrote: > done > > 2010/10/11 Hannes Hirzel <[hidden email]>: >> Thank you Julian for the clarification. >> >> Yes, -- using a slight variation and having two projects in the same >> repository is confusing. >> >> And -- having Xtreams (is this the correct name?) for Squeak is exciting! >> >> --Hannes >> >> On 10/11/10, Julian Fitzell <[hidden email]> wrote: >>> I wasn't suggesting forking (I had another post in this thread talking >>> about Grease). >>> >>> But even Seaside exists both in SqueakSource and in the Cincom Public >>> Store. I was merely asking if the the appropriate project name >>> couldn't be used in SqueakSource. Using a slight variation (and having >>> two projects in the one repo) is just confusing. >>> >>> Julian >>> >>> On Mon, Oct 11, 2010 at 12:29 PM, Hannes Hirzel <[hidden email]> >>> wrote: >>>> I think it should go the way Seaside is handled. Something like >>>> 'Grease' and 'Sport' *** on top of Squeak and the go to the original >>>> code base. Not a fork of the code for the library. >>>> >>>> Maybe Grease and Sport are good enough to have compatibility? >>>> >>>> --Hannes >>>> >>>> >>>> Sport and Grease cover different areas with their portability APIs. >>>> Sport covers Sockets, Files, Time, Exception handling and utilities >>>> such as being able to explicitly test in which Smalltalk dialect code >>>> is being run in. Grease covers utilities for parsing, printing, >>>> encoding & decoding strings, delayed sends, common exceptions, >>>> utilities such as secure hash. There is some overlap, but not much. >>>> For example, Seaside expects the underlying HTTP server to deal with >>>> socket issues so Grease does not deal with sockets. Sport in turn does >>>> not have the extensive parsing and printing facilities found in >>>> Grease. >>>> >>>> On 10/11/10, Julian Fitzell <[hidden email]> wrote: >>>>> This still seems confusing. Could we just have a new SqueakSource >>>>> project called "Xtreams" (small T + an S)? It's not like projects are >>>>> expensive to create... >>>>> >>>>> Julian >>>>> >>>>> On Sat, Oct 9, 2010 at 11:33 PM, Nicolas Cellier >>>>> <[hidden email]> wrote: >>>>>> So, I started a quick port of VW Xtreams to Squeak this evening. >>>>>> Only the Xtreams-Core and the trivial Xtreams-Terminals (no >>>>>> file/pipe/socket/pointer). >>>>>> You'll find code at http://www.squeaksource.com/XTream. >>>>>> My previous experimental Xtream project has been renamed SqueaXTream >>>>>> to reduce confusion, but still sits in the same project. >>>>>> Please find my report below. >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |