Ah, NotFoundError is also undeclared in Squeak, it is the VisualWorks class name. It could go into Xtreams-Support... For PEG parsing test, I think you are right, this is timesRepeat: They passed in Squeak last time I tried. But these are advanced features not required for legacy Stream replacement. 2013/11/18 Esteban A. Maringolo <emaringolo@gmail.com>

One more reason to look after Pharo 3 :) Esteban A. Maringolo

2013/11/18 Sven Van Caekenberghe <sven@stfx.eu>:

...

Hi,

This evening I tried to load Nicolas Cellier’s Xtreams ( http://www.squeaksource.com/Xtreams/) into Pharo #30582. This went almost flawless !

I went for

ConfigurationOfXtreams project bleedingEdge load.

which loaded

a MetacelloFetchingMCSpecLoader(linear load : linear load : 1.3-baseline [ConfigurationOfXtreams] load : Xtreams-Support-nice.11 load : Xtreams-Core-nice.20 load : Xtreams-Terminals-nice.31 load : Xtreams-Transforms-nice.23 load : Xtreams-Substreams-nice.19 load : Xtreams-CoreTests-nice.20 load : Xtreams-TerminalsTests-nice.17 load : Xtreams-TransformsTests-nice.14 load : Xtreams-SubstreamsTests-nice.13 load : Xtreams-Parsing-cwp.6 load : Xtreams-ParsingTests-cwp.5 load : Xtreams-TerminalsFileSystem-nice.3 load : Xtreams-TerminalsFileSystemTests-nice.2)

There is one Undeclared in XTReadStream>>#detect: (NotFoundError should be NotFound in Pharo).

Unit tests passed, except for the PEGParser related ones, most probably because Opal optimises #timesRepeat: which is overridden in PEGInfinity, I am not sure how this should be fixed, maybe with an Opal compiler directive somewhere ?

Running the tests resulted in some external semaphore warnings in the Transcript.

I also loaded Nicolas’ new #legacy layer (Xtreams-LegacyStreamAPI-nice.1), I’ll have to study that, it sure looks interesting.

In any case: great work, thanks Nicolas !

Sven

On 18 Nov 2013, at 23:12, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

The tests pass with this hack PEGInfinity>>adaptToInteger: anInteger andCompare: selector "This makes optimized inlining of timesRepeat: work." ^#( < <= ~= ) includes: selector

I asked Marcus for the way to do it, and if you add: PEGParser class>>#compiler ^ super compiler options: #(- optionInlineTimesRepeat); yourself And do a PEGParser recompile All tests in Xtreams-ParsingTests should be green.

But then they take 10 times longer than Squeak thanks to timesRepeat: inlining "optimization". Maybe timesRepeat: inlining should be restricted to the case when receiver is an integer literal... Or just removed.

I am not sure I understand, that is more for the compiler guys.

2013/11/18 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> Ah, NotFoundError is also undeclared in Squeak, it is the VisualWorks class name. It could go into Xtreams-Support...

For PEG parsing test, I think you are right, this is timesRepeat: They passed in Squeak last time I tried. But these are advanced features not required for legacy Stream replacement.

2013/11/18 Esteban A. Maringolo <emaringolo@gmail.com>

One more reason to look after Pharo 3 :) Esteban A. Maringolo

2013/11/18 Sven Van Caekenberghe <sven@stfx.eu>:

...

Hi,

This evening I tried to load Nicolas Cellier’s Xtreams (http://www.squeaksource.com/Xtreams/) into Pharo #30582. This went almost flawless !

I went for

ConfigurationOfXtreams project bleedingEdge load.

which loaded

a MetacelloFetchingMCSpecLoader(linear load : linear load : 1.3-baseline [ConfigurationOfXtreams] load : Xtreams-Support-nice.11 load : Xtreams-Core-nice.20 load : Xtreams-Terminals-nice.31 load : Xtreams-Transforms-nice.23 load : Xtreams-Substreams-nice.19 load : Xtreams-CoreTests-nice.20 load : Xtreams-TerminalsTests-nice.17 load : Xtreams-TransformsTests-nice.14 load : Xtreams-SubstreamsTests-nice.13 load : Xtreams-Parsing-cwp.6 load : Xtreams-ParsingTests-cwp.5 load : Xtreams-TerminalsFileSystem-nice.3 load : Xtreams-TerminalsFileSystemTests-nice.2)

There is one Undeclared in XTReadStream>>#detect: (NotFoundError should be NotFound in Pharo).

Unit tests passed, except for the PEGParser related ones, most probably because Opal optimises #timesRepeat: which is overridden in PEGInfinity, I am not sure how this should be fixed, maybe with an Opal compiler directive somewhere ?

Running the tests resulted in some external semaphore warnings in the Transcript.

I also loaded Nicolas’ new #legacy layer (Xtreams-LegacyStreamAPI-nice.1), I’ll have to study that, it sure looks interesting.

In any case: great work, thanks Nicolas !

Sven

On 18 Nov 2013, at 22:33, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

Ah, NotFoundError is also undeclared in Squeak, it is the VisualWorks class name. It could go into Xtreams-Support...

OK, are you going to check this in, or should I ? How are we going to deal with platform specific stuff (like the Opal compiler switch) ? Sven

Unfortunate that KeyNotFound is not more generic (e.g., NotFound). On Tue, Nov 19, 2013 at 4:50 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

For the OpalCompiler support, I have simply added the compiler method in Xtreams-Parsing because it does not conflict with anything else, I have the feeling that this is bearable... I have also added a NotFoundError subclass of NotFound in Xtreams-support. It's not ideal. That also means that bleeding-edge will not load in Squeak 4.4 or older, and maybe not elder version of Pharo... Maybe I could have changed NotFoundError reference into NotFound? In the future, or if we really want a bleding edge in elder images, we may have to fork the Xtreams-support, but as long as we can, it's better to avoid it.

2013/11/19 Sven Van Caekenberghe <sven@stfx.eu>

...

On 18 Nov 2013, at 22:33, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

...

Ah, NotFoundError is also undeclared in Squeak, it is the VisualWorks class name. It could go into Xtreams-Support...

OK, are you going to check this in, or should I ?

How are we going to deal with platform specific stuff (like the Opal compiler switch) ?

Sven

On Wed, 20 Nov 2013, Levente Uzonyi wrote:

On Tue, 19 Nov 2013, Nicolas Cellier wrote:

...

For the OpalCompiler support, I have simply added the compiler method in Xtreams-Parsing because it does not conflict with anything else, I have the feeling that this is bearable... I have also added a NotFoundError subclass of NotFound in Xtreams-support. It's not ideal. That also means that bleeding-edge will not load in Squeak 4.4 or older, and maybe not elder version of Pharo...

You mean any version of Squeak, since there's no class named NotFound.

I see you've added it.

...

Maybe I could have changed NotFoundError reference into NotFound? In the future, or if we really want a bleding edge in elder images, we may have to fork the Xtreams-support, but as long as we can, it's better to avoid it.

You can postpone this for a few months, but I don't see why it would make sense. Forking is bad, but if you want to support two diverging platforms, then you'll have to do it sooner or later.

Well, it's not worth to bother with it, because IIUC the Pharo folks will fork it anyway. Levente

Levente

...

2013/11/19 Sven Van Caekenberghe <sven@stfx.eu>

On 18 Nov 2013, at 22:33, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

> Ah, NotFoundError is also undeclared in Squeak, it is the VisualWorks class name. > It could go into Xtreams-Support...

OK, are you going to check this in, or should I ?

How are we going to deal with platform specific stuff (like the Opal compiler switch) ?

Sven

On 20 November 2013 16:13, Sven Van Caekenberghe <sven@stfx.eu> wrote:

Hi Nicolas,

On 19 Nov 2013, at 23:50, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

...

For the OpalCompiler support, I have simply added the compiler method in Xtreams-Parsing because it does not conflict with anything else, I have the feeling that this is bearable…

OK

...

I have also added a NotFoundError subclass of NotFound in Xtreams-support. It's not ideal. That also means that bleeding-edge will not load in Squeak 4.4 or older, and maybe not elder version of Pharo… Maybe I could have changed NotFoundError reference into NotFound?

NotFound is in Pharo 2.0 as well.

I wonder if it is really necessary to use the VW name/alias, as it is not referenced, but OK, it could be. I don’t think it is as much part of the API as Incomplete is.

...

In the future, or if we really want a bleeding edge in elder images, we may have to fork the Xtreams-support, but as long as we can, it's better to avoid it.

I think that it would be good to keep this a cross platform project (as it spans multiple platforms already). But that requires effort (at least, basic interest, maintenance from multiple people on different platforms). Fuel proves that it can be done.

Indeed!

I think it is unavoidable to have some specific code per platform, especially in Support. But indeed, not for the sake of it.

I was looking around in the source code and saw some places where I could imagine things being done differently (ZnCharacterEncoders in Pharo are properly Character <> Binary).

BTW, does TerminalsFileSystem work on Squeak or is it Pharo specific. Because FileUrl is on its way out (replaced by ZnUrl). The #reading, #writing, #appending messages on FileUrl, in their current implementation, strike me as a bit out of place (as far as I can see, they are not in the VW code either). I mean, I could image #reading or #writing am HTTP Url as well, though that would not necessarily the best design. Doing a #asFileReference in between is acceptable and clearer.

It's Pharo specific at the moment AFAICT because it refers to FileHandle and FileReference, while the upstream repo uses FSFileHandle and FSFileReference. The conversation's partly at https://code.google.com/p/xtreams/issues/detail?id=2

Are there any areas in the port of Xtreams that need more work, or do you consider the current situation as complete enough ? In other words, is there a todo list ?

Are there version differences with the VW code, and how do you see that evolving ?

Without answering for Nicolas, https://code.google.com/p/xtreams/issues/detail?id=3 has Martin Kobetic saying <quote> Regarding integration, I'd say getting the agreement of the Squeak/Pharo group should suffice to get it into the Pharo/Squeak port. Hopefully we will get a reasonable setup for crosspolination among the dialects eventually, but until then I'd hate to see evolution hampered because e.g. VW is declared the reference implementation and nothing is "officially" accepted until VW has it or some silly rule like that. I would only suggest to exercise restraint and avoid uncontrolled growth of the core framework as a general principle. Only things that are generally useful and that provide more than a marginal benefit should be added to the core. It's perfectly fine to make special purpose streams, and the core framework must always preserve the ease of doing that, but those streams themselves should live in their respective projects. </quote> frank

Sven

...

2013/11/19 Sven Van Caekenberghe <sven@stfx.eu>

On 18 Nov 2013, at 22:33, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

...

Ah, NotFoundError is also undeclared in Squeak, it is the VisualWorks class name. It could go into Xtreams-Support...

OK, are you going to check this in, or should I ?

How are we going to deal with platform specific stuff (like the Opal compiler switch) ?

Sven

On 20 Nov 2013, at 17:18, Frank Shearar <frank.shearar@gmail.com> wrote:

It's Pharo specific at the moment AFAICT because it refers to FileHandle and FileReference, while the upstream repo uses FSFileHandle and FSFileReference. The conversation's partly at https://code.google.com/p/xtreams/issues/detail?id=2

Thanks, Frank, for the explanation. Conclusion: for now it can be consider Pharo only (but given some class renames, it should be broader). With/without prefixes is one aspect, forking/not-forking another. Like I said, and like you acknowledged, it is possible to keep things together, but it requires real, continuous effort from all sides. Sven

On 23 November 2013 09:41, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

If Xtreams goes in the core of Pharo (which could be good), there should be no compatibility layers with others platforms. Sorry but we have too many of them and we do not want to have strings attached. if necessary we can rename the complete library so that people can load the real CrossPlatformXtream projects on top of Pharo.

I'm not sure that people can understand that but this is important. And we do not do that for the sake of it. As one of the keeper of the core I do not want to have to think about systems I do not know.

I completely understand the desire to do this. Every other platform maintainer agrees with you. That's why hardly anything ever gets done between the dialects, and why those that do maintain cross-dialect libraries probably (I know I certainly do) curse all the platform maintainers for being so insular. This problem even has a name: the tragedy of the commons. frank

Stef

...

...

It's Pharo specific at the moment AFAICT because it refers to FileHandle and FileReference, while the upstream repo uses FSFileHandle and FSFileReference. The conversation's partly at https://code.google.com/p/xtreams/issues/detail?id=2

Thanks, Frank, for the explanation. Conclusion: for now it can be consider Pharo only (but given some class renames, it should be broader).

With/without prefixes is one aspect, forking/not-forking another.

Like I said, and like you acknowledged, it is possible to keep things together, but it requires real, continuous effort from all sides.

Sven

...

...

If Xtreams goes in the core of Pharo (which could be good), there should be no compatibility layers with others platforms. Sorry but we have too many of them and we do not want to have strings attached. if necessary we can rename the complete library so that people can load the real CrossPlatformXtream projects on top of Pharo.

I'm not sure that people can understand that but this is important. And we do not do that for the sake of it. As one of the keeper of the core I do not want to have to think about systems I do not know.

I completely understand the desire to do this. Every other platform maintainer agrees with you. That's why hardly anything ever gets done between the dialects, and why those that do maintain cross-dialect libraries probably (I know I certainly do) curse all the platform maintainers for being so insular. This problem even has a name: the tragedy of the commons.

frank

@Stef - yes, I understand, but that is only an issue if/when we actually do include it for real, and if/when we actually start using it (remember Nile, it was there, but never used)

Yes I think that treams will have a better chance

For now, I think it would be better to move together (remember, this code started and lives in VW), when we encounter insurmountable problems with compatibility, then we’ll deal with them.

Sure.

On 20 Nov 2013, at 17:24, Sean P. DeNigris <sean@clipperadams.com> wrote:

Sven Van Caekenberghe-2 wrote

...

Are there version differences with the VW code, and how do you see that evolving ?

When we looked a few years ago at ESUG in Ghent, the port was out-of-date with the VW code. We were able to patch filetree to bring the code round-trip to/from VW, mapping namespaces to prefixes. I have our experimental image somewhere if that would be helpful…

Well, years, not last ESUG but the one before, August 2012, and yes I remember, sitting next to you when you were hacking away. Maybe, you and Nicolas should sync up a bit.

----- Cheers, Sean -- View this message in context: http://forum.world.st/Xtreams-in-Pharo-3-tp4723225p4723773.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

On Nov 19, 2013, at 5:40 PM, btc@openinworld.com wrote:

So does that mean that Xtreams might go into the Pharo 3 Release as a technology preview in parallel with the existing streams, with the aim of replacing existing streams in Pharo 4? The advantage for users would be enhanced certainty that the future is Xtreams. In the year between Pharo3 and Pharo4 users could develop their application against Xtreams such that migrating from Pharo 3 to Pharo 4 is simplified.

sorry, but no. we are freezing Pharo 3 this week and we didn't even think before on including Xtream in this version *(bah, we though at the beginning of the year and we discarded because no one was able to take care and spend time on it). but... I would really like to have it in Pharo 4 :) cheers, Esteban

cheers -ben

Esteban A. Maringolo wrote:

...

One more reason to look after Pharo 3 :) Esteban A. Maringolo

2013/11/18 Sven Van Caekenberghe <sven@stfx.eu>:

...

Hi,

This evening I tried to load Nicolas Cellier’s Xtreams (http://www.squeaksource.com/Xtreams/) into Pharo #30582. This went almost flawless !

I went for

ConfigurationOfXtreams project bleedingEdge load.

which loaded

a MetacelloFetchingMCSpecLoader(linear load : linear load : 1.3-baseline [ConfigurationOfXtreams] load : Xtreams-Support-nice.11 load : Xtreams-Core-nice.20 load : Xtreams-Terminals-nice.31 load : Xtreams-Transforms-nice.23 load : Xtreams-Substreams-nice.19 load : Xtreams-CoreTests-nice.20 load : Xtreams-TerminalsTests-nice.17 load : Xtreams-TransformsTests-nice.14 load : Xtreams-SubstreamsTests-nice.13 load : Xtreams-Parsing-cwp.6 load : Xtreams-ParsingTests-cwp.5 load : Xtreams-TerminalsFileSystem-nice.3 load : Xtreams-TerminalsFileSystemTests-nice.2)

There is one Undeclared in XTReadStream>>#detect: (NotFoundError should be NotFound in Pharo).

Unit tests passed, except for the PEGParser related ones, most probably because Opal optimises #timesRepeat: which is overridden in PEGInfinity, I am not sure how this should be fixed, maybe with an Opal compiler directive somewhere ?

Running the tests resulted in some external semaphore warnings in the Transcript.

I also loaded Nicolas’ new #legacy layer (Xtreams-LegacyStreamAPI-nice.1), I’ll have to study that, it sure looks interesting.

In any case: great work, thanks Nicolas !

Sven

On 19 Nov 2013, at 17:48, Esteban Lorenzano <estebanlm@gmail.com> wrote:

On Nov 19, 2013, at 5:40 PM, btc@openinworld.com wrote:

...

So does that mean that Xtreams might go into the Pharo 3 Release as a technology preview in parallel with the existing streams, with the aim of replacing existing streams in Pharo 4? The advantage for users would be enhanced certainty that the future is Xtreams. In the year between Pharo3 and Pharo4 users could develop their application against Xtreams such that migrating from Pharo 3 to Pharo 4 is simplified.

sorry, but no. we are freezing Pharo 3 this week and we didn't even think before on including Xtream in this version *(bah, we though at the beginning of the year and we discarded because no one was able to take care and spend time on it).

but... I would really like to have it in Pharo 4 :)

For now, the goal should be: ‘make it easily loadable’ (using the Configuration Browser) and keep it maintained. Only then can we take the next step (of what will be a long road).

cheers, Esteban

...

cheers -ben

Esteban A. Maringolo wrote:

...

One more reason to look after Pharo 3 :) Esteban A. Maringolo

2013/11/18 Sven Van Caekenberghe <sven@stfx.eu> :

...

Hi,

This evening I tried to load Nicolas Cellier’s Xtreams ( http://www.squeaksource.com/Xtreams/ ) into Pharo #30582. This went almost flawless !

I went for

ConfigurationOfXtreams project bleedingEdge load.

which loaded

a MetacelloFetchingMCSpecLoader(linear load : linear load : 1.3-baseline [ConfigurationOfXtreams] load : Xtreams-Support-nice.11 load : Xtreams-Core-nice.20 load : Xtreams-Terminals-nice.31 load : Xtreams-Transforms-nice.23 load : Xtreams-Substreams-nice.19 load : Xtreams-CoreTests-nice.20 load : Xtreams-TerminalsTests-nice.17 load : Xtreams-TransformsTests-nice.14 load : Xtreams-SubstreamsTests-nice.13 load : Xtreams-Parsing-cwp.6 load : Xtreams-ParsingTests-cwp.5 load : Xtreams-TerminalsFileSystem-nice.3 load : Xtreams-TerminalsFileSystemTests-nice.2)

There is one Undeclared in XTReadStream>>#detect: (NotFoundError should be NotFound in Pharo).

Unit tests passed, except for the PEGParser related ones, most probably because Opal optimises #timesRepeat: which is overridden in PEGInfinity, I am not sure how this should be fixed, maybe with an Opal compiler directive somewhere ?

Running the tests resulted in some external semaphore warnings in the Transcript.

I also loaded Nicolas’ new #legacy layer (Xtreams-LegacyStreamAPI-nice.1), I’ll have to study that, it sure looks interesting.

In any case: great work, thanks Nicolas !

Sven