[Pharo-dev] Xtreams in Pharo 3

Frank Shearar frank.shearar at gmail.com
Wed Nov 20 11:18:14 EST 2013

On 20 November 2013 16:13, Sven Van Caekenberghe <sven at stfx.eu> wrote:
> Hi Nicolas,
> On 19 Nov 2013, at 23:50, Nicolas Cellier <nicolas.cellier.aka.nice at 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.


> 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

> 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

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.


> Sven
>> 2013/11/19 Sven Van Caekenberghe <sven at stfx.eu>
>> On 18 Nov 2013, at 22:33, Nicolas Cellier <nicolas.cellier.aka.nice at 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

More information about the Pharo-dev mailing list