stdio support

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

stdio support

Levente Uzonyi-2
Hi,

yesterday I added Eliot's stdio change set to the Trunk. There are some
questions left to be answered:

1) Do we want to use CrLfFileStream?
Currently it has only two users in the image, but the class is "patched"
so #new will return an instance of MultiByteFileStream in those cases. The
change set overrides this "patch" for the stdio streams.

2) Read buffering: currently it's enabled for the stdio streams. For
stdout and stderr it doesn't make a difference. For stdin it's a problem
if these streams should be really shared. For example: if there are 10
bytes readable from stdin and you evaluate [StandardFileStream stdin
next], then it will fetch all 10 bytes. If you then evaluate
[MultiByteFileStream stdin next], then you'll get nothing (nil). If we
want these streams to be shared like this (accessible via both
MultiByteFileStream and StandardFileStream), then this is a problem.

3) Should we set the line end convention of MultiByteFileStream for these
streams? It's currently not set.


Cheers,
Levente

Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Bert Freudenberg

On 02.11.2010, at 17:41, Levente Uzonyi wrote:

> Hi,
>
> yesterday I added Eliot's stdio change set to the Trunk. There are some questions left to be answered:
>
> 1) Do we want to use CrLfFileStream?
> Currently it has only two users in the image, but the class is "patched" so #new will return an instance of MultiByteFileStream in those cases. The change set overrides this "patch" for the stdio streams.

Should use MultiByteFileStream.

> 2) Read buffering: currently it's enabled for the stdio streams. For stdout and stderr it doesn't make a difference. For stdin it's a problem if these streams should be really shared. For example: if there are 10 bytes readable from stdin and you evaluate [StandardFileStream stdin next], then it will fetch all 10 bytes. If you then evaluate [MultiByteFileStream stdin next], then you'll get nothing (nil). If we want these streams to be shared like this (accessible via both
> MultiByteFileStream and StandardFileStream), then this is a problem.

Only stdout should be buffered.

> 3) Should we set the line end convention of MultiByteFileStream for these streams? It's currently not set.

IMHO, yes, set it to LF.

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Levente Uzonyi-2
On Tue, 2 Nov 2010, Bert Freudenberg wrote:

>
> On 02.11.2010, at 17:41, Levente Uzonyi wrote:
>
>> Hi,
>>
>> yesterday I added Eliot's stdio change set to the Trunk. There are some questions left to be answered:
>>
>> 1) Do we want to use CrLfFileStream?
>> Currently it has only two users in the image, but the class is "patched" so #new will return an instance of MultiByteFileStream in those cases. The change set overrides this "patch" for the stdio streams.
>
> Should use MultiByteFileStream.
>
>> 2) Read buffering: currently it's enabled for the stdio streams. For stdout and stderr it doesn't make a difference. For stdin it's a problem if these streams should be really shared. For example: if there are 10 bytes readable from stdin and you evaluate [StandardFileStream stdin next], then it will fetch all 10 bytes. If you then evaluate [MultiByteFileStream stdin next], then you'll get nothing (nil). If we want these streams to be shared like this (accessible via both
>> MultiByteFileStream and StandardFileStream), then this is a problem.
>
> Only stdout should be buffered.

This is about image level buffering, where we only have read buffering.
I'm pretty sure these streams use the OS's default buffering scheme at the
VM level. For example stdout is line buffered on windows.

>
>> 3) Should we set the line end convention of MultiByteFileStream for these streams? It's currently not set.
>
> IMHO, yes, set it to LF.

Why LF?


Levente

>
> - Bert -
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Bert Freudenberg

On 02.11.2010, at 19:19, Levente Uzonyi wrote:

> On Tue, 2 Nov 2010, Bert Freudenberg wrote:
>
>>
>> On 02.11.2010, at 17:41, Levente Uzonyi wrote:
>>
>>> Hi,
>>>
>>> yesterday I added Eliot's stdio change set to the Trunk. There are some questions left to be answered:
>>>
>>> 1) Do we want to use CrLfFileStream?
>>> Currently it has only two users in the image, but the class is "patched" so #new will return an instance of MultiByteFileStream in those cases. The change set overrides this "patch" for the stdio streams.
>>
>> Should use MultiByteFileStream.
>>
>>> 2) Read buffering: currently it's enabled for the stdio streams. For stdout and stderr it doesn't make a difference. For stdin it's a problem if these streams should be really shared. For example: if there are 10 bytes readable from stdin and you evaluate [StandardFileStream stdin next], then it will fetch all 10 bytes. If you then evaluate [MultiByteFileStream stdin next], then you'll get nothing (nil). If we want these streams to be shared like this (accessible via both
>>> MultiByteFileStream and StandardFileStream), then this is a problem.
>>
>> Only stdout should be buffered.
>
> This is about image level buffering, where we only have read buffering. I'm pretty sure these streams use the OS's default buffering scheme at the VM level. For example stdout is line buffered on windows.

Right.

>>> 3) Should we set the line end convention of MultiByteFileStream for these streams? It's currently not set.
>>
>> IMHO, yes, set it to LF.
>
> Why LF?

Unix standard. Nobody wants CR, not even on the Mac anymore, which runs Unix nowadays.

Scripts that use stdin and stdout certainly expect LFs.

Maybe Windows should use CRLF (no idea how shell scripts work there) but everything else should use LF.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Casey Ransberger-2
+1 for LF on unix, not sure what makes sense on Windows either.

On Nov 2, 2010, at 1:19 PM, Bert Freudenberg <[hidden email]> wrote:

>
> On 02.11.2010, at 19:19, Levente Uzonyi wrote:
>
>> On Tue, 2 Nov 2010, Bert Freudenberg wrote:
>>
>>>
>>> On 02.11.2010, at 17:41, Levente Uzonyi wrote:
>>>
>>>> Hi,
>>>>
>>>> yesterday I added Eliot's stdio change set to the Trunk. There are some questions left to be answered:
>>>>
>>>> 1) Do we want to use CrLfFileStream?
>>>> Currently it has only two users in the image, but the class is "patched" so #new will return an instance of MultiByteFileStream in those cases. The change set overrides this "patch" for the stdio streams.
>>>
>>> Should use MultiByteFileStream.
>>>
>>>> 2) Read buffering: currently it's enabled for the stdio streams. For stdout and stderr it doesn't make a difference. For stdin it's a problem if these streams should be really shared. For example: if there are 10 bytes readable from stdin and you evaluate [StandardFileStream stdin next], then it will fetch all 10 bytes. If you then evaluate [MultiByteFileStream stdin next], then you'll get nothing (nil). If we want these streams to be shared like this (accessible via both
>>>> MultiByteFileStream and StandardFileStream), then this is a problem.
>>>
>>> Only stdout should be buffered.
>>
>> This is about image level buffering, where we only have read buffering. I'm pretty sure these streams use the OS's default buffering scheme at the VM level. For example stdout is line buffered on windows.
>
> Right.
>
>>>> 3) Should we set the line end convention of MultiByteFileStream for these streams? It's currently not set.
>>>
>>> IMHO, yes, set it to LF.
>>
>> Why LF?
>
> Unix standard. Nobody wants CR, not even on the Mac anymore, which runs Unix nowadays.
>
> Scripts that use stdin and stdout certainly expect LFs.
>
> Maybe Windows should use CRLF (no idea how shell scripts work there) but everything else should use LF.
>
> - Bert -
>
>

Reply | Threaded
Open this post in threaded view
|

Re: stdio support

blake watson
Could any of this result in, say, an implementation of Curses or a curses-like text output?

On Tue, Nov 2, 2010 at 1:40 PM, Casey Ransberger <[hidden email]> wrote:
+1 for LF on unix, not sure what makes sense on Windows either.

On Nov 2, 2010, at 1:19 PM, Bert Freudenberg <[hidden email]> wrote:

>
> On 02.11.2010, at 19:19, Levente Uzonyi wrote:
>
>> On Tue, 2 Nov 2010, Bert Freudenberg wrote:
>>
>>>
>>> On 02.11.2010, at 17:41, Levente Uzonyi wrote:
>>>
>>>> Hi,
>>>>
>>>> yesterday I added Eliot's stdio change set to the Trunk. There are some questions left to be answered:
>>>>
>>>> 1) Do we want to use CrLfFileStream?
>>>> Currently it has only two users in the image, but the class is "patched" so #new will return an instance of MultiByteFileStream in those cases. The change set overrides this "patch" for the stdio streams.
>>>
>>> Should use MultiByteFileStream.
>>>
>>>> 2) Read buffering: currently it's enabled for the stdio streams. For stdout and stderr it doesn't make a difference. For stdin it's a problem if these streams should be really shared. For example: if there are 10 bytes readable from stdin and you evaluate [StandardFileStream stdin next], then it will fetch all 10 bytes. If you then evaluate [MultiByteFileStream stdin next], then you'll get nothing (nil). If we want these streams to be shared like this (accessible via both
>>>> MultiByteFileStream and StandardFileStream), then this is a problem.
>>>
>>> Only stdout should be buffered.
>>
>> This is about image level buffering, where we only have read buffering. I'm pretty sure these streams use the OS's default buffering scheme at the VM level. For example stdout is line buffered on windows.
>
> Right.
>
>>>> 3) Should we set the line end convention of MultiByteFileStream for these streams? It's currently not set.
>>>
>>> IMHO, yes, set it to LF.
>>
>> Why LF?
>
> Unix standard. Nobody wants CR, not even on the Mac anymore, which runs Unix nowadays.
>
> Scripts that use stdin and stdout certainly expect LFs.
>
> Maybe Windows should use CRLF (no idea how shell scripts work there) but everything else should use LF.
>
> - Bert -
>
>




Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Bert Freudenberg
On 03.11.2010, at 17:41, blake wrote:

Could any of this result in, say, an implementation of Curses or a curses-like text output?

It wouldn't magically "result" in that, no. But you could built one. However, since you could have done that using OSProcess for many years, it's not more likely to happen. Who needs curses anyway nowadays? The space between command line utilities and full-blown graphical UIs is drying up ...

- Bert -




Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Eliot Miranda-2
In reply to this post by blake watson


On Wed, Nov 3, 2010 at 9:41 AM, blake <[hidden email]> wrote:
Could any of this result in, say, an implementation of Curses or a curses-like text output?

What do you want to build that would use a curses style interface?
 


On Tue, Nov 2, 2010 at 1:40 PM, Casey Ransberger <[hidden email]> wrote:
+1 for LF on unix, not sure what makes sense on Windows either.

On Nov 2, 2010, at 1:19 PM, Bert Freudenberg <[hidden email]> wrote:

>
> On 02.11.2010, at 19:19, Levente Uzonyi wrote:
>
>> On Tue, 2 Nov 2010, Bert Freudenberg wrote:
>>
>>>
>>> On 02.11.2010, at 17:41, Levente Uzonyi wrote:
>>>
>>>> Hi,
>>>>
>>>> yesterday I added Eliot's stdio change set to the Trunk. There are some questions left to be answered:
>>>>
>>>> 1) Do we want to use CrLfFileStream?
>>>> Currently it has only two users in the image, but the class is "patched" so #new will return an instance of MultiByteFileStream in those cases. The change set overrides this "patch" for the stdio streams.
>>>
>>> Should use MultiByteFileStream.
>>>
>>>> 2) Read buffering: currently it's enabled for the stdio streams. For stdout and stderr it doesn't make a difference. For stdin it's a problem if these streams should be really shared. For example: if there are 10 bytes readable from stdin and you evaluate [StandardFileStream stdin next], then it will fetch all 10 bytes. If you then evaluate [MultiByteFileStream stdin next], then you'll get nothing (nil). If we want these streams to be shared like this (accessible via both
>>>> MultiByteFileStream and StandardFileStream), then this is a problem.
>>>
>>> Only stdout should be buffered.
>>
>> This is about image level buffering, where we only have read buffering. I'm pretty sure these streams use the OS's default buffering scheme at the VM level. For example stdout is line buffered on windows.
>
> Right.
>
>>>> 3) Should we set the line end convention of MultiByteFileStream for these streams? It's currently not set.
>>>
>>> IMHO, yes, set it to LF.
>>
>> Why LF?
>
> Unix standard. Nobody wants CR, not even on the Mac anymore, which runs Unix nowadays.
>
> Scripts that use stdin and stdout certainly expect LFs.
>
> Maybe Windows should use CRLF (no idea how shell scripts work there) but everything else should use LF.
>
> - Bert -
>
>








Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Sean P. DeNigris
Administrator
I must have missed something - does this mean I don't have to install OSProcess and CommandShell anymore to easily run a unix command and get the output back (e.g. "ls")?

Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Eliot Miranda-2


On Wed, Nov 3, 2010 at 1:02 PM, Sean P. DeNigris <[hidden email]> wrote:

I must have missed something - does this mean I don't have to install
OSProcess and CommandShell anymore to easily run a unix command and get the
output back (e.g. "ls")?

No.  The stdio support means you can read and write stdio and hence more easily add Squeak to a pipe or, as I did, write a command-line read-eval-print loop (reader).

cheers,
Eliot

Sean
--
View this message in context: http://forum.world.st/stdio-support-tp3023995p3026097.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.




Reply | Threaded
Open this post in threaded view
|

Re: stdio support

David T. Lewis
In reply to this post by Bert Freudenberg
On Wed, Nov 03, 2010 at 06:15:01PM +0100, Bert Freudenberg wrote:
> On 03.11.2010, at 17:41, blake wrote:
>
> > Could any of this result in, say, an implementation of Curses or a curses-like text output?
>
>
> It wouldn't magically "result" in that, no. But you could built one. However, since you could have done that using OSProcess for many years, it's not more likely to happen. Who needs curses anyway nowadays? The space between command line utilities and full-blown graphical UIs is drying up ...
>

Supporting curses (or or vi or emacs...) requires a pty interface
(http://en.wikipedia.org/wiki/Pseudo_terminal) as well as some layer
of terminal emulation (e.g. ansi terminal). Ian Piumarta implemented
both of these in his "telnet" package many years ago. I don't have a
link handy, but it appears on SqueakMap.

If anyone is seriously interested in this, you should definitely take
Ian's work as a starting point.

Ian suggested adding the pty part to OSProcess, though I never took
the time to do it. To be honest, I doubt there is any real demand for
this nowadays.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: stdio support

David T. Lewis
In reply to this post by Eliot Miranda-2
On Wed, Nov 03, 2010 at 01:06:32PM -0700, Eliot Miranda wrote:

> On Wed, Nov 3, 2010 at 1:02 PM, Sean P. DeNigris <[hidden email]>wrote:
>
> >
> > I must have missed something - does this mean I don't have to install
> > OSProcess and CommandShell anymore to easily run a unix command and get the
> > output back (e.g. "ls")?
> >
>
> No.  The stdio support means you can read and write stdio and hence more
> easily add Squeak to a pipe or, as I did, write a command-line
> read-eval-print loop (reader).

FYI, a read-eval-print loop is also included in CommandShell:
  http://wiki.squeak.org/squeak/6023

Dave


Reply | Threaded
Open this post in threaded view
|

Re: stdio support

blake watson
In reply to this post by Bert Freudenberg
It wouldn't magically "result" in that, no. But you could built one. However, since you could have done that using OSProcess for many years, it's not more likely to happen.
 
I wasn't expecting it to magically happen. But if it included the main elements needed to build a cross-platform TUI (ability to get and maybe even set screen dimensions, "bitblt" the screen, and receive mouse input), I'd take another stab at it. (I'm not _trying_ to be irritating about it, just got stumped in my attempts.)
 
Who needs curses anyway nowadays? The space between command line utilities and full-blown graphical UIs is drying up ...

Sure. But you don't always have (or want) a GUI.  At least, I don't always. I've got some headless machines, e.g., and I'd like the friendliness of a GUI without the footprint. I actually do a lot of console stuff, but I've never been able to do it in ST. 




Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Bert Freudenberg
In reply to this post by David T. Lewis

On 04.11.2010, at 00:56, David T. Lewis wrote:

> On Wed, Nov 03, 2010 at 06:15:01PM +0100, Bert Freudenberg wrote:
>> On 03.11.2010, at 17:41, blake wrote:
>>
>>> Could any of this result in, say, an implementation of Curses or a curses-like text output?
>>
>>
>> It wouldn't magically "result" in that, no. But you could built one. However, since you could have done that using OSProcess for many years, it's not more likely to happen. Who needs curses anyway nowadays? The space between command line utilities and full-blown graphical UIs is drying up ...
>>
>
> Supporting curses (or or vi or emacs...) requires a pty interface
> (http://en.wikipedia.org/wiki/Pseudo_terminal) as well as some layer
> of terminal emulation (e.g. ansi terminal). Ian Piumarta implemented
> both of these in his "telnet" package many years ago. I don't have a
> link handy, but it appears on SqueakMap.
>
> If anyone is seriously interested in this, you should definitely take
> Ian's work as a starting point.
>
> Ian suggested adding the pty part to OSProcess, though I never took
> the time to do it. To be honest, I doubt there is any real demand for
> this nowadays.
>
> Dave

I thought Blake wanted to do the reverse. Not run a curses app inside Squeak, but make a curses UI for a Squeak app. Is there something in Ian's package to help with this?

- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: stdio support

blake watson
On Thu, Nov 4, 2010 at 4:13 AM, Bert Freudenberg <[hidden email]> wrote:

I thought Blake wanted to do the reverse. Not run a curses app inside Squeak, but make a curses UI for a Squeak app. Is there something in Ian's package to help with this?


Right. Although the development would become an issue if you didn't have some way to look at your output.

Also, Curses is more a model than anything. I wanted to interface with Curses on the premise it would make cross-platform portability easier. But I really don't need much: Just ability to read (and ideally set) screen size, ability to peek and poke screen coords, and a way to capture input.

At least, I don't think it's much; it was obviously too much for me.



Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Eliot Miranda-2


On Thu, Nov 4, 2010 at 12:41 PM, blake <[hidden email]> wrote:
On Thu, Nov 4, 2010 at 4:13 AM, Bert Freudenberg <[hidden email]> wrote:

I thought Blake wanted to do the reverse. Not run a curses app inside Squeak, but make a curses UI for a Squeak app. Is there something in Ian's package to help with this?


Right. Although the development would become an issue if you didn't have some way to look at your output.

You would still develop it in headful Squeak, using the full development environment but launching the system on the command line with its stdio hooked to the terminal.  At least that's what I'm doing with my listener which is a test case for the threaded (non-blocking FFI) VM I'm working on.

Also, Curses is more a model than anything. I wanted to interface with Curses on the premise it would make cross-platform portability easier. But I really don't need much: Just ability to read (and ideally set) screen size, ability to peek and poke screen coords, and a way to capture input.

At least, I don't think it's much; it was obviously too much for me.







Reply | Threaded
Open this post in threaded view
|

Re: stdio support

blake watson

You would still develop it in headful Squeak, using the full development environment but launching the system on the command line with its stdio hooked to the terminal.  At least that's what I'm doing with my listener which is a test case for the threaded (non-blocking FFI) VM I'm working on.

So, emulate the terminal as an object inside the dev screen? I can see that. How do you get from that to the final, "headless" output?


Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Levente Uzonyi-2
In reply to this post by blake watson
On Wed, 3 Nov 2010, blake wrote:

>>
>> It wouldn't magically "result" in that, no. But you could built one.
>> However, since you could have done that using OSProcess for many years, it's
>> not more likely to happen.
>>
>
> I wasn't expecting it to magically happen. But if it included the main
> elements needed to build a cross-platform TUI (ability to get and maybe even
> set screen dimensions, "bitblt" the screen, and receive mouse input), I'd
> take another stab at it. (I'm not _trying_ to be irritating about it, just
> got stumped in my attempts.)
>
>
>> Who needs curses anyway nowadays? The space between command line utilities
>> and full-blown graphical UIs is drying up ...
>>
>
> Sure. But you don't always have (or want) a GUI.  At least, I don't always.
> I've got some headless machines, e.g., and I'd like the friendliness of a
> GUI without the footprint. I actually do a lot of console stuff, but I've
> never been able to do it in ST.
>

You can always use RFB (VNC) to access the GUI even if your image is
"headless".


Levente

Reply | Threaded
Open this post in threaded view
|

Re: stdio support

Bert Freudenberg
In reply to this post by blake watson

On 04.11.2010, at 21:06, blake wrote:


You would still develop it in headful Squeak, using the full development environment but launching the system on the command line with its stdio hooked to the terminal.  At least that's what I'm doing with my listener which is a test case for the threaded (non-blocking FFI) VM I'm working on.

So, emulate the terminal as an object inside the dev screen? I can see that. How do you get from that to the final, "headless" output?

I don't understand what problem you see.

To write a curses-like UI you simply read keyboard input from stdin, and you issue "drawing commands" to stdout. When deploying you would run the VM headlessly, and while developing you would just use the regular Squeak GUI to write your code, and at the same time stdin/stdout to test your app. No need to "emulate a terminal" because you have the real terminal right there. Ot at least what counts as a real terminal nowadays ;)

- Bert -




Reply | Threaded
Open this post in threaded view
|

Re: stdio support

blake watson
I don't understand what problem you see.

To write a curses-like UI you simply read keyboard input from stdin, and you issue "drawing commands" to stdout. When deploying you would run the VM headlessly, and while developing you would just use the regular Squeak GUI to write your code, and at the same time stdin/stdout to test your app. No need to "emulate a terminal" because you have the real terminal right there. Ot at least what counts as a real terminal nowadays ;)

OK, so there's really--this wouldn't apply to a WIMP TUI since stdio/stdout are streams. I'll have to check it out anyway, since it probably handles some of the problems I ran into.