Re: Making AttachableFileStream UTF aware

Re: Making AttachableFileStream UTF aware

FYI I will start making changes in OSProcess and CommandShell
(CommandShell does not load cleanly, but I need PipeableOSProcess for
Coral).

For the time being, I'll commit those, as well as the updated
ConfigurationOfOSProcess to the Coral repo
(http://ss3.gemstone.com/ss/coral.html), but it would be nice if you
could give me write access to the official repos (or at least review
my changes and integrate them).

> On Mon, Aug 22, 2011 at 04:11:53PM +0100, Damien Pollet wrote:
>> To display stuff in UTF-8 terminals, I've made AttachableFileStream a
>> subclass of MultiByteFileStream (instead of StandardFileStream). I can
>> then attach a converter to it, and it works for my purposes.
>>
>> However, a whole bunch of tests are red (they were already, but still???)
>>
>> Opinions ?
>
> I'm away and can't look at code right now, but at the time I
> wrote it there was no MultiByteFileStream, and AttachableFileStream
> was an acceptable hack to avoid modifying the standard stream
> classes. It's probably long past time to make the mechanism
> a bit more general. IIRC, there are methods like #attachTo:
> and #asAttachableFileStream that could be adapted to do the
> right thing for a MultiByteFileStream.
>
> Regarding tests, if you have a Unix/Linux box handy it would
> be best to start with a unix interpreter VM with all OSProcess
> and CommandShell tests green. That way you can see what breaks
> as a result of your stream changes. The tests should all be
> green on a Pharo or Squeak image when run on the unix interpreter
> VM, but not necessarily so on other VMs.
>
> Dave
>
>

Re: Making AttachableFileStream UTF aware

On 26 October 2011 02:20, David T. Lewis <[hidden email]> wrote:
> If you prefer to just commit your changes to the Coral repo, I will
> do my best to integrate them back into the SqS/OSProcess and CommandShell
> repositories. It might be that I spend more time working with the older
> images than you do, so it may easier if we do it that way, but either
> way is fine by me.

That might be the best way to do. I already have cold feet about
changing code that is not mine like that, so if I also have to worry
about compatibility, I will not go anywhere.
For Coral I will rely on metacello configurations so I can easily
commit code that works for me and update the #development version,
then you're free to smooth things for old images and make proper
releases. I really don't want to end up with a fork, so tell me if I
write crap :)

A bit of a roadmap:
- I'd like to group in OSProcess all that pertains to launching and
interacting with child processes, particularly PipeableOSProcess and
maybe a couple other classes it needs.
- there are tests about forking squeak that don't pass on my machine,
apparently because they rely on X11. Should they be marked as expected
failures ?
- if possible I'd like to simplify the architecture (or push you in
this direction ;) From reading the code I feel like there are many
convenience methods but the core ones are not completely orthogonal or
complete… No actual examples at the moment but I can make a list of
what surprises me if you like.