stdio support
Locked
 
|
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 |
|
|
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 - |
|
|
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 - > > > > |
|
|
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 - |
|
|
+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 - > > |
|
|
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 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 - |
|
|
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?
|
|
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 |
|
|
On Wed, Nov 3, 2010 at 1:02 PM, Sean P. DeNigris <[hidden email]> wrote:
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
|
|
|
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 |
|
|
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 |
|
|
In reply to this post by Bert Freudenberg
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.)
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.
|
|
|
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 - |
|
|
On Thu, Nov 4, 2010 at 4:13 AM, Bert Freudenberg <[hidden email]> wrote:
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. |
|
|
On Thu, Nov 4, 2010 at 12:41 PM, blake <[hidden email]> 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?
|
|
|
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 |
|
|
In reply to this post by blake watson
On 04.11.2010, at 21:06, blake wrote:
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 - |
|
|
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.
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |