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
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.
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
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.
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
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.
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
On Sun, Sep 26, 2010 at 10:18 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
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
On 27 September 2010 21:09, 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...
In Hydra, i simply changed main entry point from winMain() to main(), and then i were able to print to console using printf() etc. The side effect of it, that when you run VM from explorer, it opens a console window, so you end up with two windows - console and graphic. and obvious, when you running it from command-line its using a console from which you run it.
I din't explored the way , how to make it to not open console but still have stdin/stdout working.
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
Thanks for the code Eliot. Can you give me a hint about proper usage. In the current trunk I tried
CrLfFileStream newForStdio
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...
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
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
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!'.
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
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 > > >
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..?
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 >> >> >
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 >>> >>> >> >
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.
Forgive me. I was unaware of the subtleties when I wrote the code. The important thing is the remembering of the three streams so that multiple clients that e.g. write to stdout will end up writing to a singe stdout stream, not multiple independent streams on stdout. Feel free to fix my stream usage.
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
On 27.09.2010, at 07:20, Eliot Miranda wrote:
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.
Forgive me. I was unaware of the subtleties when I wrote the code. The important thing is the remembering of the three streams so that multiple clients that e.g. write to stdout will end up writing to a singe stdout stream, not multiple independent streams on stdout. Feel free to fix my stream usage.
cheers Eliot
Since this comes up at least once every year it would really be awesome to finally get proper stdio support :)
OSProcess is a fine choice for many situations, but not all. Getting this in the regular VM + image will be very helpful.
- Bert -
+1, yes _very_ helpful
Is it a lot of work to do so?
--Hannes
On 9/27/10, Bert Freudenberg bert@freudenbergs.de wrote:
On 27.09.2010, at 07:20, Eliot Miranda wrote:
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.
Forgive me. I was unaware of the subtleties when I wrote the code. The important thing is the remembering of the three streams so that multiple clients that e.g. write to stdout will end up writing to a singe stdout stream, not multiple independent streams on stdout. Feel free to fix my stream usage.
cheers Eliot
Since this comes up at least once every year it would really be awesome to finally get proper stdio support :)
OSProcess is a fine choice for many situations, but not all. Getting this in the regular VM + image will be very helpful.
- Bert -
On 27.09.2010, at 12:23, Hannes Hirzel wrote:
+1, yes _very_ helpful
Is it a lot of work to do so?
--Hannes
Not really, but still some. More importantly, it requires coordinating all the platforms.
The new primitive(s) must be added to VMMaker, which calls into the platform support code, which must be written (or at the very least be stubbed out) for each platform.
This work typically falls to the few VM platform maintainers. We do not have a good process to share that burden.
Contributors have to send patches to the vm-dev list. But since no one is expert in all platforms, patches typically are supplied for one platform only. It is expected of the platform maintainers to implement the equivalent on their platform. This means significant work for them, so it might not happen soon or at all.
If patches were provided for all platforms and simply needed to be applied, the work would be much easier on the maintainers. However, we lack collaboration infrastructure to work on these patches.
- Bert -
On 9/27/10, Bert Freudenberg bert@freudenbergs.de wrote:
On 27.09.2010, at 07:20, Eliot Miranda wrote:
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.
Forgive me. I was unaware of the subtleties when I wrote the code. The important thing is the remembering of the three streams so that multiple clients that e.g. write to stdout will end up writing to a singe stdout stream, not multiple independent streams on stdout. Feel free to fix my stream usage.
cheers Eliot
Since this comes up at least once every year it would really be awesome to finally get proper stdio support :)
OSProcess is a fine choice for many situations, but not all. Getting this in the regular VM + image will be very helpful.
- Bert -
On 9/27/10, Bert Freudenberg bert@freudenbergs.de wrote:
On 27.09.2010, at 12:23, Hannes Hirzel wrote:
+1, yes _very_ helpful
Is it a lot of work to do so?
--Hannes
Not really, but still some. More importantly, it requires coordinating all the platforms.
The new primitive(s) must be added to VMMaker, which calls into the platform support code, which must be written (or at the very least be stubbed out) for each platform.
This work typically falls to the few VM platform maintainers. We do not have a good process to share that burden.
Contributors have to send patches to the vm-dev list. But since no one is expert in all platforms, patches typically are supplied for one platform only. It is expected of the platform maintainers to implement the equivalent on their platform. This means significant work for them, so it might not happen soon or at all.
If patches were provided for all platforms and simply needed to be applied, the work would be much easier on the maintainers. However, we lack collaboration infrastructure to work on these patches.
- Bert -
As Cog is still in test and evaluation phase and not yet widespread I think it is an opportunity to add this basic feature people expect.
I agree with your analysis. We need collaboration infrastructure for future changes like this.
But for the change at hand I hope that it is still possible to do it on a as-we-go-along basis .....
--Hannes
squeak-dev@lists.squeakfoundation.org