On Tue, Oct 5, 2010 at 12:23 PM, Chris Muller asqueaker@gmail.com wrote:
Thank you both, it worked in my Linux test! And Levente tested it in Windows. Does that mean only Mac needs tested and clean up the stream-usage to be able to include this into 4.2? Bert, I was not clear if that what you meant in your reference to work needed by platform maintainers..?
I wrote it on Mac and use it regularly on Mac. It works on Mac. Mac == unix at this level.
But the VM support needs to get merged into the trunk before we an add it to 4.2.
On Mon, Oct 4, 2010 at 10:26 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Both,
2010/10/3 Levente Uzonyi leves@elte.hu
On Sun, 3 Oct 2010, Chris Muller wrote:
Thanks for the code Eliot. Can you give me a hint about proper usage. In the current trunk I tried
CrLfFileStream newForStdio
Levente, as usual, is exactly right. use e.g. StandardFileStream stdout.
but I was not able to nextPutAll: a String onto that (rwmode was not set).
I also found StandardFileStream class>>#standardIOStreamNamed:forWrite: but it has undeclared variable, "stdioFiles". Is that supposed to be a class-inst var defined at the StandardFileStream level? Senders did not help me understand what arguments I should pass...
That class instance variable is missing, but the code still works. Try this:
CrLfFileStream stdout nextPutAll: 'Hello World!'.
That's right. This is missing: StandardFileStream class instanceVariableNames: 'stdioFiles' best Eliot
Levente
Sorry for my confusion..
- Chris
On Mon, Sep 27, 2010 at 1:09 PM, Eliot Miranda <
eliot.miranda@gmail.com>
wrote:
On Sun, Sep 26, 2010 at 10:18 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Levente,
On Sun, Sep 26, 2010 at 7:13 PM, Levente Uzonyi leves@elte.hu
wrote:
> > On Sun, 26 Sep 2010, Eliot Miranda wrote: > >> Hi Chris, >> >> I have code for this, but right now I need to crack some crabs,
so
>> I >> don't have time to verify this code in 4.1 :) Use at your own risk >> ;) >> The >> most important thing is the StandardFileStream>>stdioHandles >> primitive >> for >> accessing the streams. N.B. some work needs to be done on the
win32
>> FilePlugin support code before this will work on Windows. > > All three streams seem to be working on Windows Vista with the
latest
> CogVM. > This seems to be a really cool feature, though I think
CrLfFileStream
> should be deprecated, so MultiByteFileStream support would be better > IMO.
The streams work if directed to files. But they will /not/ work if directed to input or output in a console window. I should have been clearer, sorry. The work needed is in platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c where if input and/or output is the console we need to use ReadConsole & WriteConsole in place of ReadFile & WriteFile.
Hmmm. Turns out I was confused about this. One doesn't need ReadConsole & WriteConsole; ReadFile & WriteFile should do just fine. But the Cog code doesnt work in either an MS-DOS console window or a cygwin console window. If anyone's familiar with this area of Windows please feel free to
take
a look... TIA Eliot
cheers Eliot > > > Levente > >> >> >> On Sun, Sep 26, 2010 at 2:46 PM, Chris Muller <asqueaker@gmail.com
>> wrote: >> >>> I am developing a simple "CommandLineProcessor" facade for easily >>> transferring command-line arguments simply as block-arguments, so >>> you >>> can write smalltalk scripts in vi: >>> >>> CommandLineProcessor do: [ : arg1 : arg2 : arg3 | "args come in
as
>>> Strings" ... ] >>> >>> and also for directing Notifications and Warnings messages to >>> stdOut, >>> and Errors to stdErr. It relies on OSProcess to write to stdOut
and
>>> stdErr for this. However, ever since switching to Cog, writing to >>> these streams does not seem to redirect out to Linux.. >>> >>> I don't know whether writing to these streams makes me >>> Linux-dependent, but it really is nice to be able to write Linux >>> scripts that employ Squeak in the back-end, but operate normally >>> like >>> other shell programs in the terminal window and with redirecting >>> output, etc. >>> >>> - Chris >>> >>> >> >