Smalltalk › Pharo › Pharo Smalltalk Developers

Xtreams in Pharo 3

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

26 messages Options

Sven Van Caekenberghe-2

Xtreams in Pharo 3

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

Esteban A. Maringolo

Re: Xtreams in Pharo 3

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

2013/11/18 Sven Van Caekenberghe <[hidden email]>:

> 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
>
>

Nicolas Cellier

Re: Xtreams in Pharo 3

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 <[hidden email]>

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

2013/11/18 Sven Van Caekenberghe <[hidden email]>:

> 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
>
>

Nicolas Cellier

Re: Xtreams in Pharo 3

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

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.

2013/11/18 Nicolas Cellier <[hidden email]>

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 <[hidden email]>

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

2013/11/18 Sven Van Caekenberghe <[hidden email]>:

> 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
>
>

Sven Van Caekenberghe-2

Re: Xtreams in Pharo 3

On 18 Nov 2013, at 23:12, Nicolas Cellier <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
>
> One more reason to look after Pharo 3 :)
> Esteban A. Maringolo
>
>
> 2013/11/18 Sven Van Caekenberghe <[hidden email]>:
> > 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
> >
> >
>
>
>

Sven Van Caekenberghe-2

Re: Xtreams in Pharo 3

In reply to this post by Nicolas Cellier

On 18 Nov 2013, at 22:33, Nicolas Cellier <[hidden email]> 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

Marcus Denker-4

Re: Xtreams in Pharo 3

In reply to this post by Sven Van Caekenberghe-2

On 19 Nov 2013, at 16:49, Sven Van Caekenberghe <[hidden email]> wrote:

>
> On 18 Nov 2013, at 23:12, Nicolas Cellier <[hidden email]> 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.

I do not understand that sentence either, but I guess there is information missing.

Marcus

Ben Coman

Re: Xtreams in Pharo 3

In reply to this post by Esteban A. Maringolo

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.

cheers -ben

Esteban A. Maringolo wrote:

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


2013/11/18 Sven Van Caekenberghe [hidden email]:

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

EstebanLM

Re: Xtreams in Pharo 3

On Nov 19, 2013, at 5:40 PM, [hidden email] 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 [hidden email]:

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

Ben Coman

Re: Xtreams in Pharo 3

Esteban Lorenzano wrote:

On Nov 19, 2013, at 5:40 PM, [hidden email] 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

Fair enough.
A random thought then, maybe the Configruation Browser could have a tab "Preview" containing a small list of packages to be integrated into next version of Pharo. Or maybe thats more effort than its worth.

cheers -ben

cheers -ben

Esteban A. Maringolo wrote:

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


2013/11/18 Sven Van Caekenberghe [hidden email]:

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

Sven Van Caekenberghe-2

Re: Xtreams in Pharo 3

In reply to this post by EstebanLM

On 19 Nov 2013, at 17:48, Esteban Lorenzano <[hidden email]> wrote:

>
> On Nov 19, 2013, at 5:40 PM, [hidden email] 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
>>> <[hidden email]>
>>> :
>>>
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>

Nicolas Cellier

Re: Xtreams in Pharo 3

In reply to this post by Sven Van Caekenberghe-2

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 <[hidden email]>

On 18 Nov 2013, at 22:33, Nicolas Cellier <[hidden email]> 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

Chris Muller-3

Re: [squeak-dev] Re: Xtreams in Pharo 3

Unfortunate that KeyNotFound is not more generic (e.g., NotFound).

On Tue, Nov 19, 2013 at 4:50 PM, Nicolas Cellier
<[hidden email]> 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 <[hidden email]>
>>
>>
>> On 18 Nov 2013, at 22:33, Nicolas Cellier
>> <[hidden email]> 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
>
>
>
>
>

Levente Uzonyi-2

Re: Xtreams in Pharo 3

In reply to this post by Nicolas Cellier

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.

> 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.

Levente

>
>
> 2013/11/19 Sven Van Caekenberghe <[hidden email]>
>
> On 18 Nov 2013, at 22:33, Nicolas Cellier <[hidden email]> 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
>
>
>
>

Levente Uzonyi-2

Re: [squeak-dev] Re: Xtreams in Pharo 3

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 <[hidden email]>
>>
>> On 18 Nov 2013, at 22:33, Nicolas Cellier
>> <[hidden email]> 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
>>
>>
>>
>>
>
>

Sven Van Caekenberghe-2

Re: Xtreams in Pharo 3

In reply to this post by Nicolas Cellier

Hi Nicolas,

On 19 Nov 2013, at 23:50, Nicolas Cellier <[hidden email]> 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.

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.

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 ?

Sven

> 2013/11/19 Sven Van Caekenberghe <[hidden email]>
>
> On 18 Nov 2013, at 22:33, Nicolas Cellier <[hidden email]> 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
>

Frank Shearar-3

Re: Xtreams in Pharo 3

On 20 November 2013 16:13, Sven Van Caekenberghe <[hidden email]> wrote:

> Hi Nicolas,
>
> On 19 Nov 2013, at 23:50, Nicolas Cellier <[hidden email]> 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 <[hidden email]>
>>
>> On 18 Nov 2013, at 22:33, Nicolas Cellier <[hidden email]> 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
>>
>
>

Sean P. DeNigris

Re: Xtreams in Pharo 3

Administrator

In reply to this post by Sven Van Caekenberghe-2

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...

Cheers,
Sean

Sven Van Caekenberghe-2

Re: Xtreams in Pharo 3

On 20 Nov 2013, at 17:24, Sean P. DeNigris <[hidden email]> 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.
>

Nicolas Cellier

Re: Xtreams in Pharo 3

In reply to this post by Frank Shearar-3

I don't like the Squeak encoders with all the basicNext & co complications, it cries for rewriting.
In Xtreams, I just included a compatibility layer for legacy text converters, because it was the fastest ROI.
But in my pre-Xtreams attempt, I previously started rewriting the most common (UTF8 & UTF16) - see http://www.squeaksource.com/XTream.html.
I saw that you did the same in Zn, so I agree that it is the way to go.

I'd just like those classes to loose their XT or Zn prefix, they are common stuff...

2013/11/20 Frank Shearar <[hidden email]>

On 20 November 2013 16:13, Sven Van Caekenberghe <[hidden email]> wrote:
> Hi Nicolas,
>
> On 19 Nov 2013, at 23:50, Nicolas Cellier <[hidden email]> 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 <[hidden email]>
>>
>> On 18 Nov 2013, at 22:33, Nicolas Cellier <[hidden email]> 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
>>
>
>