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). Thanks. On 22 August 2011 21:37, David T. Lewis <[hidden email]> wrote: > 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 > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet _______________________________________________ Pharo-coral mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral |
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. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet _______________________________________________ Pharo-coral mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-coral |
Free forum by Nabble | Edit this page |