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