Improvements to wiki.squeak.org
Locked
123
123
 
|
Hi Alistair,
> On Apr 7, 2018, at 4:11 AM, Alistair Grant <[hidden email]> wrote: > > Hi Benoit, > >> On 7 April 2018 at 10:24, Alistair Grant <[hidden email]> wrote: >> Hi Benoit, >> >> On 7 April 2018 at 02:38, Benoit St-Jean via Squeak-dev >> <[hidden email]> wrote: >>> Thanks for your help. >>> >>> So far, I've had : >>> >>> a) lots of "primitive failed", most of the time primitiveFileAtEnd >>> (FilePlugin) >> >> I've been able to reproduce this one. I'll take a look and get back to you. > > Can you send me steps to reproduce the problem? $ cd image $ ./buildspurtrunkreaderimage.sh $ myvm spurreader.image squeak> 3 + 4! 7 squeak> Smalltalk quit! $ ./buildspurtrunkreader64image.sh $ myvm spurreader-64.image squeak> 3 + 4! 7 squeak> Smalltalk quit! $ This no longer works on Mac OS X with the latest VMs either. > > > Thanks, > Alistair > > > > >>> b) An error/warning message in the console, >>> "VirtualProtect(x,y,PAGE_EXECUTE_READWRITE): No error" and then nothing >>> happens, not even a prompt! >>> c) A "Manufactured file handle detected" error >>> d) An emergency error handler >>> e) An error saying "stdout is not open" >>> f) the VM terminating abruptly >>> g) The "Squeak Cog Spur Virtual Machine" unresponsive and totally frozen >>> (not even able to interrupt it!) >>> >>> I tried the original and some refactored (VERY simple snippets) examples I >>> could find on the net using : >>> >>> a) OSProcess >>> b) FileStream >>> c) StdioListener >>> >>> I have tried all tips & tricks : >>> a) load the "application code" from a script >>> b) doIt the code in a workspace and save the image >>> c) doIt some code with code to save the image first so the rest of the doIt >>> resumes at startup >>> d) I tried so many things I don't remember it all!! >>> >>> So far, nothing worked, not even was I once close ! Except for the example >>> with StdioListener : it shows the prompt but does nothing with the input... >>> >>> I'm using Squeak 5.1 32bit on Windows 10. >>> >>> My goal is to produce a headless application is a *simple* way. It can be a >>> script or some code I execute in a workspace. Then save the image (or >>> whatever step is required). >>> >>> When running the application, I don't want to have to specify a script to >>> start it up from the console. Also, I don't want to open another command >>> window! I want the app/image to run from the command window without any >>> artifact/trick the same way any other Windows utility/app would work. I >>> also want the application to be interactive (it waits for input, does >>> something with the input, then shows result and presents me with a prompt >>> again). >>> >>> Once I get this to work, you can be sure I'll document it in detail !!!! >>> >>> >>> >>> ----------------- >>> Benoît St-Jean >>> Yahoo! Messenger: bstjean >>> Twitter: @BenLeChialeux >>> Pinterest: benoitstjean >>> Instagram: Chef_Benito >>> IRC: lamneth >>> Blogue: endormitoire.wordpress.com >>> "A standpoint is an intellectual horizon of radius zero". (A. Einstein) >>> >>> >>> On Friday, April 6, 2018, 5:42:27 p.m. EDT, tim Rowledge <[hidden email]> >>> wrote: >>> >>> >>> >>> >>>> On 06-04-2018, at 11:10 AM, Alistair Grant <[hidden email]> wrote: >>>> >>>> Hi Benoit, >>>> >>>> On 6 April 2018 at 12:16, Benoit St-Jean via Squeak-dev >>>> <[hidden email]> wrote: >>>>> Is there any way I can start squeak from a command window, *headless*, >>>>> and >>>>> WITHOUT providing a script and have an interactive application^ Say, for >>>>> instance, my application waits for input and answers back the square of >>>>> the >>>>> number I type in? >>>>> >>>>> I've tried a gazillion examples I found and it just doesn't work at >>>>> all... >>>>> >>>>> I'm on Windows 10 if that helps. >>>> >>>> >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/image/buildspurtrunkreaderimage.sh >>> >>> Just for the record here for the future - this process >>> a) simply loads the CogTools-Listener (sub)package from the VMMaker >>> repository - which is a very small bit of code we could very sensibly >>> include in the default image >>> b) uses a simple initial script to create an image that will start up at the >>> beginning of an incantation that loops around the StdioListener. All you do >>> is start up the image saved after loading the Listener tools with the >>> StartReader.st - subsequent runs do not need that. >>> >>> Unfortunately it doesn't seem to be working quite right on my Pi at the >>> moment; I get a "squeak>" prompt but it doesn't seem to ever read any input. >>> I know it works in principle because I've used it plenty of times in the >>> past , but clearly I'm forgetting some important detail. >>> >>> >>> tim >>> -- >>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim >>> >>> Useful Latin Phrases:- Te audire no possum. Musa sapientum fixa est in aure. >>> = I can't hear you. I have a banana in my ear. > |
|
|
> On 07-04-2018, at 7:44 AM, Eliot Miranda <[hidden email]> wrote: > > $ myvm spurreader.image > squeak> 3 + 4! > 7 Works on Pi/Raspbian once you remember the ! thing. Damn, I even read the code and missed that... Seems to me that for the purposes of a headless terminal-access system we would probably not want the ! to be essential since it can only confuse users of 'regular' stuff. What do most terminal things do to continue a line? Isn't it \ on unix? What about others? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: IA: Illogical And |
|
|
In reply to this post by Eliot Miranda-2
On Saturday 07 April 2018 08:14 PM, Eliot Miranda wrote:
> $ cd image > $ ./buildspurtrunkreaderimage.sh > $ myvm spurreader.image > squeak> 3 + 4! > 7 > squeak> Smalltalk quit! Nice. This can become a good smoke test at the end of the build*.sh: /bin/echo -e '14*3!\nSmalltalk quit!' | $VM spurreader.image Now there's the answer to life, the universe and everything ;-) Regards .. Subbu |
|
|
> On 07-04-2018, at 11:29 AM, K K Subbu <[hidden email]> wrote: > > On Saturday 07 April 2018 08:14 PM, Eliot Miranda wrote: >> $ cd image >> $ ./buildspurtrunkreaderimage.sh >> $ myvm spurreader.image >> squeak> 3 + 4! >> 7 >> squeak> Smalltalk quit! > > Nice. This can become a good smoke test at the end of the build*.sh: > > /bin/echo -e '14*3!\nSmalltalk quit!' | $VM spurreader.image > > Now there's the answer to life, the universe and everything ;-) Not quite; you actually need - ((6*9) printStringRadix: 13) last: 2 ! tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: QVC: Question Valid Command |
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
On 7 April 2018 at 16:44, Eliot Miranda <[hidden email]> wrote: > Hi Alistair, > > >> On Apr 7, 2018, at 4:11 AM, Alistair Grant <[hidden email]> wrote: >> >> Hi Benoit, >> >>> On 7 April 2018 at 10:24, Alistair Grant <[hidden email]> wrote: >>> Hi Benoit, >>> >>> On 7 April 2018 at 02:38, Benoit St-Jean via Squeak-dev >>> <[hidden email]> wrote: >>>> Thanks for your help. >>>> >>>> So far, I've had : >>>> >>>> a) lots of "primitive failed", most of the time primitiveFileAtEnd >>>> (FilePlugin) >>> >>> I've been able to reproduce this one. I'll take a look and get back to you. >> >> Can you send me steps to reproduce the problem? > > $ cd image > $ ./buildspurtrunkreaderimage.sh > $ myvm spurreader.image > squeak> 3 + 4! > 7 > squeak> Smalltalk quit! > $ ./buildspurtrunkreader64image.sh > $ myvm spurreader-64.image > squeak> 3 + 4! > 7 > squeak> Smalltalk quit! > $ > > This no longer works on Mac OS X with the latest VMs either. Thanks! I believe I understand the issue now. I just need to tidy up the code and run it through the usual test suites. My apologies for the troubles. Cheers, Alistair |
|
|
In reply to this post by K K Subbu
On 7 April 2018 at 20:29, K K Subbu <[hidden email]> wrote:
> On Saturday 07 April 2018 08:14 PM, Eliot Miranda wrote: >> >> $ cd image >> $ ./buildspurtrunkreaderimage.sh >> $ myvm spurreader.image >> squeak> 3 + 4! >> 7 >> squeak> Smalltalk quit! > > > Nice. This can become a good smoke test at the end of the build*.sh: > > /bin/echo -e '14*3!\nSmalltalk quit!' | $VM spurreader.image > > Now there's the answer to life, the universe and everything ;-) > > Regards .. Subbu Interesting idea... But even the old VM doesn't provide the answer. Piped input is working in general with my new test VM. I'll have to figure out why the reader image doesn't handle it. Thanks, Alistair |
|
|
In reply to this post by timrowledge
On Sat, Apr 07, 2018 at 11:05:46AM -0700, tim Rowledge wrote:
> > > > On 07-04-2018, at 7:44 AM, Eliot Miranda <[hidden email]> wrote: > > > > > $ myvm spurreader.image > > squeak> 3 + 4! > > 7 > > Works on Pi/Raspbian once you remember the ! thing. Damn, I even read the code and missed that... > > Seems to me that for the purposes of a headless terminal-access system we would probably not want the ! to be essential since it can only confuse users of 'regular' stuff. What do most terminal things do to continue a line? Isn't it \ on unix? What about others? > > Ah, but wait. That spurreader REPL is pretty cool, but just in case they ever start handing out Ig Nobel awards (1) in the field of computer science (sic), I want to claim prior art (2). I assert that I am the perpetrator of the most ghastly syntax mashup since invention of English, or possibly even (gasp!) Perl. The $! delimiter means that the stuff before it should be interpreted as Smalltalk, so if you were to mix this up with unix shell syntax, it might look something like this: lewis@lewis-Gazelle-Pro:~/squeak/Squeak5.1$ run osp64.image sqsh> 3 + 4 ! 7 sqsh> 3 + 4 7 sqsh> 3 + 4! | /bin/cat 7 sqsh> exit lewis@lewis-Gazelle-Pro:~/squeak/Squeak5.1$ So, in the above, $! is a chunk terminator but it is not essential in a context where the chunk can be disambiguated from other unixy syntax cruft. Dave (1) https://www.improbable.com/ig/winners/ (2) http://wiki.squeak.org/squeak/1064 |
|
|
> On 07-04-2018, at 2:52 PM, David T. Lewis <[hidden email]> wrote: > just in case > they ever start handing out Ig Nobel awards (1) in the field of computer > science (sic), I think they call those 'Microsoft Senior Fellow'. > I want to claim prior art (2). I assert that I am the > perpetrator of the most ghastly syntax mashup since invention of English, > or possibly even (gasp!) Perl. > > The $! delimiter means that the stuff before it should be interpreted as > Smalltalk, so if you were to mix this up with unix shell syntax, it might > look something like this: > > lewis@lewis-Gazelle-Pro:~/squeak/Squeak5.1$ run osp64.image > > sqsh> 3 + 4 ! > 7 > sqsh> 3 + 4 > 7 > sqsh> 3 + 4! | /bin/cat > 7 > sqsh> exit > lewis@lewis-Gazelle-Pro:~/squeak/Squeak5.1$ I bow before the Master. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: DPC: Double Precision Crash |
|
|
In reply to this post by alistairgrant
Hi Alistair,
On Sat, Apr 7, 2018 at 12:32 PM, Alistair Grant <[hidden email]> wrote:
It will do, but that \n must be a ^M. So if one types '3+4! followed by ctrl-v carriage return, followed by Smalltalk quit!' then echo will echo a carriage return. But since the REPL is actually reading chunk format (hence the !'s) one doesn't need the carriage return at all and one should be able to say echo '3+4!Smalltalk quit!' | $VM spurreader.image and see "squeak> 7 squeak> " printed to stdout Piped input is working in general with my new test VM. I'll have to I think the details are in the nextChunkNoTag method in the CogTools-Listener package. I was trying to do the simplest thing that could possibly work here, not produce a usable listener. The ! requirement is absurd for general use but acceptable for someone simply wanting to exercise (potentially non-blocking) reading from stdin. _,,,^..^,,,_ best, Eliot |
|
|
In reply to this post by David T. Lewis
Hi David,
> On Apr 7, 2018, at 2:52 PM, David T. Lewis <[hidden email]> wrote: > >> On Sat, Apr 07, 2018 at 11:05:46AM -0700, tim Rowledge wrote: >> >> >>> On 07-04-2018, at 7:44 AM, Eliot Miranda <[hidden email]> wrote: >>> >> >>> $ myvm spurreader.image >>> squeak> 3 + 4! >>> 7 >> >> Works on Pi/Raspbian once you remember the ! thing. Damn, I even read the code and missed that... >> >> Seems to me that for the purposes of a headless terminal-access system we would probably not want the ! to be essential since it can only confuse users of 'regular' stuff. What do most terminal things do to continue a line? Isn't it \ on unix? What about others? >> >> > > Ah, but wait. That spurreader REPL is pretty cool, It is not. It's just a very quick hack to test the threaded ffi and the simulator. > but just in case > they ever start handing out Ig Nobel awards (1) in the field of computer > science (sic), I want to claim prior art (2). I assert that I am the > perpetrator of the most ghastly syntax mashup since invention of English, > or possibly even (gasp!) Perl. > > The $! delimiter means that the stuff before it should be interpreted as > Smalltalk, so if you were to mix this up with unix shell syntax, it might > look something like this: > > lewis@lewis-Gazelle-Pro:~/squeak/Squeak5.1$ run osp64.image > > sqsh> 3 + 4 ! > 7 > sqsh> 3 + 4 > 7 So do you require long expressions occur on one line? > sqsh> 3 + 4! | /bin/cat > 7 > sqsh> exit > lewis@lewis-Gazelle-Pro:~/squeak/Squeak5.1$ > > So, in the above, $! is a chunk terminator but it is not essential in a > context where the chunk can be disambiguated from other unixy syntax cruft. The issue is how to input a multi line doit. Do you allow it and hence either require each end of line to be escaped (Unix/C, end a non end line with \ CR) or I escaped and require an input terminator (st chunk's ! or Unix here script's repeat of the opening tag)? > > Dave > > (1) https://www.improbable.com/ig/winners/ > (2) http://wiki.squeak.org/squeak/1064 > > |
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
On 8 April 2018 at 03:02, Eliot Miranda <[hidden email]> wrote: > Hi Alistair, > > On Sat, Apr 7, 2018 at 12:32 PM, Alistair Grant <[hidden email]> > wrote: >> >> On 7 April 2018 at 20:29, K K Subbu <[hidden email]> wrote: >> > On Saturday 07 April 2018 08:14 PM, Eliot Miranda wrote: >> >> >> >> $ cd image >> >> $ ./buildspurtrunkreaderimage.sh >> >> $ myvm spurreader.image >> >> squeak> 3 + 4! >> >> 7 >> >> squeak> Smalltalk quit! >> > >> > >> > Nice. This can become a good smoke test at the end of the build*.sh: >> > >> > /bin/echo -e '14*3!\nSmalltalk quit!' | $VM spurreader.image >> > >> > Now there's the answer to life, the universe and everything ;-) >> > >> > Regards .. Subbu >> >> >> Interesting idea... But even the old VM doesn't provide the answer. > > > It will do, but that \n must be a ^M. So if one types '3+4! followed by > ctrl-v carriage return, followed by Smalltalk quit!' then echo will echo a > carriage return. But since the REPL is actually reading chunk format (hence > the !'s) one doesn't need the carriage return at all and one should be able > to say > > echo '3+4!Smalltalk quit!' | $VM spurreader.image > > and see "squeak> 7 > squeak> " printed to stdout > >> Piped input is working in general with my new test VM. I'll have to >> figure out why the reader image doesn't handle it. In this case: - PositionableStream>>nextChunkNoTag calls #peek - #peek tries to save the state, which tries to read the stream position. - And getting the stream position doesn't seem to be supported for piped input. - So an Error is raised. - But because the input processing is done outside the exception handler, there's nothing to catch the error. - And the system becomes unresponsive (when run headless). I want to get #primitiveFileAtEnd working first - I've written the code, I just need to run it through the usual test suites. Adding a primitivePeek would be trivial and should also work with piped input. I might have a look at this after I'm sure #primitiveFileAtEnd works properly. Cheers, Alistair > I think the details are in the nextChunkNoTag method in the > CogTools-Listener package. I was trying to do the simplest thing that could > possibly work here, not produce a usable listener. The ! requirement is > absurd for general use but acceptable for someone simply wanting to exercise > (potentially non-blocking) reading from stdin. > > > _,,,^..^,,,_ > best, Eliot > > > |
|
|
Hi Alistair,
> On Apr 8, 2018, at 5:23 AM, Alistair Grant <[hidden email]> wrote: > > Hi Eliot, > >> On 8 April 2018 at 03:02, Eliot Miranda <[hidden email]> wrote: >> Hi Alistair, >> >> On Sat, Apr 7, 2018 at 12:32 PM, Alistair Grant <[hidden email]> >> wrote: >>> >>>> On 7 April 2018 at 20:29, K K Subbu <[hidden email]> wrote: >>>>> On Saturday 07 April 2018 08:14 PM, Eliot Miranda wrote: >>>>> >>>>> $ cd image >>>>> $ ./buildspurtrunkreaderimage.sh >>>>> $ myvm spurreader.image >>>>> squeak> 3 + 4! >>>>> 7 >>>>> squeak> Smalltalk quit! >>>> >>>> >>>> Nice. This can become a good smoke test at the end of the build*.sh: >>>> >>>> /bin/echo -e '14*3!\nSmalltalk quit!' | $VM spurreader.image >>>> >>>> Now there's the answer to life, the universe and everything ;-) >>>> >>>> Regards .. Subbu >>> >>> >>> Interesting idea... But even the old VM doesn't provide the answer. >> >> >> It will do, but that \n must be a ^M. So if one types '3+4! followed by >> ctrl-v carriage return, followed by Smalltalk quit!' then echo will echo a >> carriage return. But since the REPL is actually reading chunk format (hence >> the !'s) one doesn't need the carriage return at all and one should be able >> to say >> >> echo '3+4!Smalltalk quit!' | $VM spurreader.image >> >> and see "squeak> 7 >> squeak> " printed to stdout >> >>> Piped input is working in general with my new test VM. I'll have to >>> figure out why the reader image doesn't handle it. > > In this case: > > - PositionableStream>>nextChunkNoTag calls #peek > - #peek tries to save the state, which tries to read the stream position. > - And getting the stream position doesn't seem to be supported for piped input. > - So an Error is raised. > - But because the input processing is done outside the exception > handler, there's nothing to catch the error. > - And the system becomes unresponsive (when run headless). > > I want to get #primitiveFileAtEnd working first - I've written the > code, I just need to run it through the usual test suites. Agreed. And having peek work on stdin, as if used to, is essential. Consider the reader part of the tests. > > Adding a primitivePeek would be trivial and should also work with > piped input. I might have a look at this after I'm sure > #primitiveFileAtEnd works properly. This would have bay be acceptable on a major release. You /cannot/ break problems motives and expect image code to change except at a major release. The VM /must/ continue to run exist my images unchanged. If it does not then there has been a regression and it must be fixed. So if your changes to primitiveFileAtEnd are at fault they must be fixed. Adding primitivePeek seems to me a mistake. It is adding unnecessary code at a low level. I had managed to get perk working for stdin. Why is it broken? > > Cheers, > Alistair > > > > > >> I think the details are in the nextChunkNoTag method in the >> CogTools-Listener package. I was trying to do the simplest thing that could >> possibly work here, not produce a usable listener. The ! requirement is >> absurd for general use but acceptable for someone simply wanting to exercise >> (potentially non-blocking) reading from stdin. >> >> >> _,,,^..^,,,_ >> best, Eliot >> >> >> > |
|
|
Hi Eliot,
On 8 April 2018 at 17:25, Eliot Miranda <[hidden email]> wrote: > Hi Alistair, > > >> On Apr 8, 2018, at 5:23 AM, Alistair Grant <[hidden email]> wrote: >> >> Hi Eliot, >> >>> On 8 April 2018 at 03:02, Eliot Miranda <[hidden email]> wrote: >>> Hi Alistair, >>> >>> On Sat, Apr 7, 2018 at 12:32 PM, Alistair Grant <[hidden email]> >>> wrote: >>>> >>>>> On 7 April 2018 at 20:29, K K Subbu <[hidden email]> wrote: >>>>>> On Saturday 07 April 2018 08:14 PM, Eliot Miranda wrote: >>>>>> >>>>>> $ cd image >>>>>> $ ./buildspurtrunkreaderimage.sh >>>>>> $ myvm spurreader.image >>>>>> squeak> 3 + 4! >>>>>> 7 >>>>>> squeak> Smalltalk quit! >>>>> >>>>> >>>>> Nice. This can become a good smoke test at the end of the build*.sh: >>>>> >>>>> /bin/echo -e '14*3!\nSmalltalk quit!' | $VM spurreader.image >>>>> >>>>> Now there's the answer to life, the universe and everything ;-) >>>>> >>>>> Regards .. Subbu >>>> >>>> >>>> Interesting idea... But even the old VM doesn't provide the answer. >>> >>> >>> It will do, but that \n must be a ^M. So if one types '3+4! followed by >>> ctrl-v carriage return, followed by Smalltalk quit!' then echo will echo a >>> carriage return. But since the REPL is actually reading chunk format (hence >>> the !'s) one doesn't need the carriage return at all and one should be able >>> to say >>> >>> echo '3+4!Smalltalk quit!' | $VM spurreader.image >>> >>> and see "squeak> 7 >>> squeak> " printed to stdout >>> >>>> Piped input is working in general with my new test VM. I'll have to >>>> figure out why the reader image doesn't handle it. >> >> In this case: >> >> - PositionableStream>>nextChunkNoTag calls #peek >> - #peek tries to save the state, which tries to read the stream position. >> - And getting the stream position doesn't seem to be supported for piped input. >> - So an Error is raised. >> - But because the input processing is done outside the exception >> handler, there's nothing to catch the error. >> - And the system becomes unresponsive (when run headless). >> >> I want to get #primitiveFileAtEnd working first - I've written the >> code, I just need to run it through the usual test suites. > > Agreed. And having peek work on stdin, as if used to, is essential. Consider the reader part of the tests. > >> >> Adding a primitivePeek would be trivial and should also work with >> piped input. I might have a look at this after I'm sure >> #primitiveFileAtEnd works properly. > > This would have bay be acceptable on a major release. You /cannot/ break problems motives and expect image code to change except at a major release. The VM /must/ continue to run exist my images unchanged. If it does not then there has been a regression and it must be fixed. So if your changes to primitiveFileAtEnd are at fault they must be fixed. > I think two issues are being mixed together here: 1. primitiveFileAtEnd My change broke some behaviour - no question. Cyril, Subbu and your reports allowed me to identify what was wrong there. I've modified the code and have a PR being built at the moment to make sure it builds on all platforms. Both the Pharo and Squeak test suites (32 bit) had their usual group of errors, which aren't related to file i.o, so that is looking good. However that has nothing to do with the issue we're talking about at the moment. Second issue: 2. #peek not working with piped input > Adding primitivePeek seems to me a mistake. It is adding unnecessary code at a low level. I had managed to get perk working for stdin. Why is it broken? The problem here is that the current implementation of #peek, which relies on getting and setting the position of the stream, works with terminal input and a redirected input file, but not with piped input. The additional primitive I'm proposing I think will allow it to also work with piped input (although I haven't tested it). Obviously existing images won't be affected - they won't be calling the new primitive. None of the changes I'm proposing (primitiveFileAtEnd or adding a primitivePeek) would break backward compatibility (bugs aside :-)). Please let me know if I've misunderstood anything. Thanks, Alistair >> Cheers, >> Alistair >> >> >> >> >> >>> I think the details are in the nextChunkNoTag method in the >>> CogTools-Listener package. I was trying to do the simplest thing that could >>> possibly work here, not produce a usable listener. The ! requirement is >>> absurd for general use but acceptable for someone simply wanting to exercise >>> (potentially non-blocking) reading from stdin. >>> >>> >>> _,,,^..^,,,_ >>> best, Eliot >>> >>> >>> >> > |
|
|
Hi Alistair,
> On Apr 8, 2018, at 8:43 AM, Alistair Grant <[hidden email]> wrote: > > Hi Eliot, > >> On 8 April 2018 at 17:25, Eliot Miranda <[hidden email]> wrote: >> Hi Alistair, >> >> >>> On Apr 8, 2018, at 5:23 AM, Alistair Grant <[hidden email]> wrote: >>> >>> Hi Eliot, >>> >>>> On 8 April 2018 at 03:02, Eliot Miranda <[hidden email]> wrote: >>>> Hi Alistair, >>>> >>>> On Sat, Apr 7, 2018 at 12:32 PM, Alistair Grant <[hidden email]> >>>> wrote: >>>>> >>>>>>> On 7 April 2018 at 20:29, K K Subbu <[hidden email]> wrote: >>>>>>> On Saturday 07 April 2018 08:14 PM, Eliot Miranda wrote: >>>>>>> >>>>>>> $ cd image >>>>>>> $ ./buildspurtrunkreaderimage.sh >>>>>>> $ myvm spurreader.image >>>>>>> squeak> 3 + 4! >>>>>>> 7 >>>>>>> squeak> Smalltalk quit! >>>>>> >>>>>> >>>>>> Nice. This can become a good smoke test at the end of the build*.sh: >>>>>> >>>>>> /bin/echo -e '14*3!\nSmalltalk quit!' | $VM spurreader.image >>>>>> >>>>>> Now there's the answer to life, the universe and everything ;-) >>>>>> >>>>>> Regards .. Subbu >>>>> >>>>> >>>>> Interesting idea... But even the old VM doesn't provide the answer. >>>> >>>> >>>> It will do, but that \n must be a ^M. So if one types '3+4! followed by >>>> ctrl-v carriage return, followed by Smalltalk quit!' then echo will echo a >>>> carriage return. But since the REPL is actually reading chunk format (hence >>>> the !'s) one doesn't need the carriage return at all and one should be able >>>> to say >>>> >>>> echo '3+4!Smalltalk quit!' | $VM spurreader.image >>>> >>>> and see "squeak> 7 >>>> squeak> " printed to stdout >>>> >>>>> Piped input is working in general with my new test VM. I'll have to >>>>> figure out why the reader image doesn't handle it. >>> >>> In this case: >>> >>> - PositionableStream>>nextChunkNoTag calls #peek >>> - #peek tries to save the state, which tries to read the stream position. >>> - And getting the stream position doesn't seem to be supported for piped input. >>> - So an Error is raised. >>> - But because the input processing is done outside the exception >>> handler, there's nothing to catch the error. >>> - And the system becomes unresponsive (when run headless). >>> >>> I want to get #primitiveFileAtEnd working first - I've written the >>> code, I just need to run it through the usual test suites. >> >> Agreed. And having peek work on stdin, as if used to, is essential. Consider the reader part of the tests. >> >>> >>> Adding a primitivePeek would be trivial and should also work with >>> piped input. I might have a look at this after I'm sure >>> #primitiveFileAtEnd works properly. >> >> This would have bay be acceptable on a major release. You /cannot/ break problems motives and expect image code to change except at a major release. The VM /must/ continue to run exist my images unchanged. If it does not then there has been a regression and it must be fixed. So if your changes to primitiveFileAtEnd are at fault they must be fixed. >> > > > I think two issues are being mixed together here: > > 1. primitiveFileAtEnd > > My change broke some behaviour - no question. Cyril, Subbu and your > reports allowed me to identify what was wrong there. I've modified > the code and have a PR being built at the moment to make sure it > builds on all platforms. Both the Pharo and Squeak test suites (32 > bit) had their usual group of errors, which aren't related to file > i.o, so that is looking good. > > However that has nothing to do with the issue we're talking about at the moment. > > > Second issue: > > 2. #peek not working with piped input > >> Adding primitivePeek seems to me a mistake. It is adding unnecessary code at a low level. I had managed to get perk working for stdin. Why is it broken? > > The problem here is that the current implementation of #peek, which > relies on getting and setting the position of the stream, works with > terminal input and a redirected input file, but not with piped input. > > The additional primitive I'm proposing I think will allow it to also > work with piped input (although I haven't tested it). Obviously > existing images won't be affected - they won't be calling the new > primitive. > > None of the changes I'm proposing (primitiveFileAtEnd or adding a > primitivePeek) would break backward compatibility (bugs aside :-)). Good to hear! > > > Please let me know if I've misunderstood anything. I don't think so. I think the misunderstandings are in my side. My current concern is that if stdin is at end of input (input consumed or user has typed EOF) that stdin reflect that, otherwise the listener is severely hampered and requires Smalltalk quit to exit cleanly, getting blocked otherwise. > > Thanks, > Alistair > > >>> Cheers, >>> Alistair >>> >>> >>> >>> >>> >>>> I think the details are in the nextChunkNoTag method in the >>>> CogTools-Listener package. I was trying to do the simplest thing that could >>>> possibly work here, not produce a usable listener. The ! requirement is >>>> absurd for general use but acceptable for someone simply wanting to exercise >>>> (potentially non-blocking) reading from stdin. >>>> >>>> >>>> _,,,^..^,,,_ >>>> best, Eliot >>>> >>>> >>>> >>> >> > |
Squeak REPL (was Re: Windows, stdin, stdout)
|
|
In reply to this post by Eliot Miranda-2
Although Eliot's little REPl thing for image testing is cool, it is minimal and would need extending to be generally useful. I took a quick amble down the rabbit-hole to see what other REPL things people have made for Squeak and it looks to me that the most advanced one was the REPL package within www.squeaksource.com/SecureSqueak
It's quite old and includes classes like ANSIStream (which I'm going to guess was a pre-i18n work way of dealing with the Squeak charset issues). It apparently "Requires Comanche (or at least ConnectionHandler and SocketStream)." to quote from the swiki page where I found out about it (http://wiki.squeak.org/squeak/2648) A modernised version would be a nice thing to have. I'm pretty much certain I've heard of work on a 'squeak shell' too - which I suspect would be Craig? Am I remembering something about 'squish'? - but I can't find anything right now. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Not an idiot, but plays one in his life. |
Re: Squeak REPL (was Re: Windows, stdin, stdout)
|
|
Hi Tim,
On Sun, Apr 8, 2018 at 11:23 AM, tim Rowledge <[hidden email]> wrote: Although Eliot's little REPl thing for image testing is cool, it is minimal and would need extending to be generally useful. +0. It's not cool and it would indeed need extending. I took a quick amble down the rabbit-hole to see what other REPL things people have made for Squeak and it looks to me that the most advanced one was the REPL package within www.squeaksource.com/ Was. Pharo have something much more up-to-date. Take a look at that. They have full curses integration so colored output and the possibility of doing an emacs-like input editor.
I would look at the Pharo system. _,,,^..^,,,_ best, Eliot |
Re: Squeak REPL (was Re: Windows, stdin, stdout)
|
|
Just to give my 2 cents on the subject, when I started this thread I was just asking for an easy way to have an interactive headless console application. Quite frankly, I never had the need to compile Smalltalk expressions from a prompt and I've never seen the benefits of it. If one wants to execute Smalltalk code, we do have the capability to do it by providing a script as an argument! Yes, it's quite nice to be able to do so when you want to show off how cool is Smalltalk but is there any *real* use for such a functionality? I doubt it!
----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)
On Sunday, April 8, 2018, 4:09:07 p.m. EDT, Eliot Miranda <[hidden email]> wrote:
Hi Tim, On Sun, Apr 8, 2018 at 11:23 AM, tim Rowledge <[hidden email]> wrote: Although Eliot's little REPl thing for image testing is cool, it is minimal and would need extending to be generally useful. +0. It's not cool and it would indeed need extending. I took a quick amble down the rabbit-hole to see what other REPL things people have made for Squeak and it looks to me that the most advanced one was the REPL package within www.squeaksource.com/ SecureSqueak Was. Pharo have something much more up-to-date. Take a look at that. They have full curses integration so colored output and the possibility of doing an emacs-like input editor.
I would look at the Pharo system. _,,,^..^,,,_ best, Eliot |
|
|
In reply to this post by Eliot Miranda-2
Hi Eliot,
On 8 April 2018 at 19:06, Eliot Miranda <[hidden email]> wrote: > Hi Alistair, > > >> On Apr 8, 2018, at 8:43 AM, Alistair Grant <[hidden email]> wrote: >> >> Hi Eliot, >> >>> On 8 April 2018 at 17:25, Eliot Miranda <[hidden email]> wrote: >>> Hi Alistair, >>> >>> >>>> On Apr 8, 2018, at 5:23 AM, Alistair Grant <[hidden email]> wrote: >>>> >>>> Hi Eliot, >>>> >>>>> On 8 April 2018 at 03:02, Eliot Miranda <[hidden email]> wrote: >>>>> Hi Alistair, >>>>> >>>>> On Sat, Apr 7, 2018 at 12:32 PM, Alistair Grant <[hidden email]> >>>>> wrote: >>>>>> >>>>>>>> On 7 April 2018 at 20:29, K K Subbu <[hidden email]> wrote: >>>>>>>> On Saturday 07 April 2018 08:14 PM, Eliot Miranda wrote: >>>>>>>> >>>>>>>> $ cd image >>>>>>>> $ ./buildspurtrunkreaderimage.sh >>>>>>>> $ myvm spurreader.image >>>>>>>> squeak> 3 + 4! >>>>>>>> 7 >>>>>>>> squeak> Smalltalk quit! >>>>>>> >>>>>>> >>>>>>> Nice. This can become a good smoke test at the end of the build*.sh: >>>>>>> >>>>>>> /bin/echo -e '14*3!\nSmalltalk quit!' | $VM spurreader.image >>>>>>> >>>>>>> Now there's the answer to life, the universe and everything ;-) >>>>>>> >>>>>>> Regards .. Subbu >>>>>> >>>>>> >>>>>> Interesting idea... But even the old VM doesn't provide the answer. >>>>> >>>>> >>>>> It will do, but that \n must be a ^M. So if one types '3+4! followed by >>>>> ctrl-v carriage return, followed by Smalltalk quit!' then echo will echo a >>>>> carriage return. But since the REPL is actually reading chunk format (hence >>>>> the !'s) one doesn't need the carriage return at all and one should be able >>>>> to say >>>>> >>>>> echo '3+4!Smalltalk quit!' | $VM spurreader.image >>>>> >>>>> and see "squeak> 7 >>>>> squeak> " printed to stdout >>>>> >>>>>> Piped input is working in general with my new test VM. I'll have to >>>>>> figure out why the reader image doesn't handle it. >>>> >>>> In this case: >>>> >>>> - PositionableStream>>nextChunkNoTag calls #peek >>>> - #peek tries to save the state, which tries to read the stream position. >>>> - And getting the stream position doesn't seem to be supported for piped input. >>>> - So an Error is raised. >>>> - But because the input processing is done outside the exception >>>> handler, there's nothing to catch the error. >>>> - And the system becomes unresponsive (when run headless). >>>> >>>> I want to get #primitiveFileAtEnd working first - I've written the >>>> code, I just need to run it through the usual test suites. >>> >>> Agreed. And having peek work on stdin, as if used to, is essential. Consider the reader part of the tests. >>> >>>> >>>> Adding a primitivePeek would be trivial and should also work with >>>> piped input. I might have a look at this after I'm sure >>>> #primitiveFileAtEnd works properly. >>> >>> This would have bay be acceptable on a major release. You /cannot/ break problems motives and expect image code to change except at a major release. The VM /must/ continue to run exist my images unchanged. If it does not then there has been a regression and it must be fixed. So if your changes to primitiveFileAtEnd are at fault they must be fixed. >>> >> >> >> I think two issues are being mixed together here: >> >> 1. primitiveFileAtEnd >> >> My change broke some behaviour - no question. Cyril, Subbu and your >> reports allowed me to identify what was wrong there. I've modified >> the code and have a PR being built at the moment to make sure it >> builds on all platforms. Both the Pharo and Squeak test suites (32 >> bit) had their usual group of errors, which aren't related to file >> i.o, so that is looking good. >> >> However that has nothing to do with the issue we're talking about at the moment. >> >> >> Second issue: >> >> 2. #peek not working with piped input >> >>> Adding primitivePeek seems to me a mistake. It is adding unnecessary code at a low level. I had managed to get perk working for stdin. Why is it broken? >> >> The problem here is that the current implementation of #peek, which >> relies on getting and setting the position of the stream, works with >> terminal input and a redirected input file, but not with piped input. >> >> The additional primitive I'm proposing I think will allow it to also >> work with piped input (although I haven't tested it). Obviously >> existing images won't be affected - they won't be calling the new >> primitive. >> >> None of the changes I'm proposing (primitiveFileAtEnd or adding a >> primitivePeek) would break backward compatibility (bugs aside :-)). > > Good to hear! > >> >> >> Please let me know if I've misunderstood anything. > > I don't think so. I think the misunderstandings are in my side. My current concern is that if stdin is at end of input (input consumed or user has typed EOF) that stdin reflect that, otherwise the listener is severely hampered and requires Smalltalk quit to exit cleanly, getting blocked otherwise. The behaviour of #atEnd for stdin from a terminal is the same with my patch as before. That is, once the code has read past the end of the stream #atEnd will answer true. This doesn't meet the original definition of #atEnd, which is that it should answer true once the last element has been read. But that isn't possible for stdin from a terminal since we need to wait for the user to explicitly flag the end of input (using Ctrl-D) and #atEnd shouldn't block waiting for input from the user. In practice, this generally isn't an issue in Squeak as any code that is reading from stdin isn't relying on #atEnd, but checking for #next returning nil. For all other files: #atEnd used to return the correct answer if the size of the file was reported accurately by the file system. This was generally true for "normal" files, i.e. those where I can find the contents on the disk. But was often wrong for virtual files, e.g. /proc/cpuinfo, and character devices, e.g. /dev/urandom, which return a file size of 0. Hopefully now it returns the correct answer in all cases. Cheers, Alistair |
|
|
Hi Alistair,
On Sun, Apr 8, 2018 at 2:19 PM, Alistair Grant <[hidden email]> wrote: Hi Eliot, Well, I don't know why but when I try the reader image it works, but no prompt is printed until after one supplies input. So something has changed. I want your fixes but we also need backward compatibility. So some more investigation is necessary. _,,,^..^,,,_ best, Eliot |
Re: Squeak REPL (was Re: Windows, stdin, stdout)
|
|
In reply to this post by Squeak - Dev mailing list
On Sun, Apr 8, 2018 at 3:28 PM, Benoit St-Jean via Squeak-dev
<[hidden email]> wrote: > Just to give my 2 cents on the subject, when I started this thread I was > just asking for an easy way to have an interactive headless console > application. Start a server on localhost which can then accept commands from one or more terminals or elsewhere. This is how Magma and many other applications work. Multi-user and modal-less. > Quite frankly, I never had the need to compile Smalltalk expressions from a > prompt and I've never seen the benefits of it. If one wants to execute > Smalltalk code, we do have the capability to do it by providing a script as > an argument! Yes, it's quite nice to be able to do so when you want to show > off how cool is Smalltalk but is there any *real* use for such a > functionality? I doubt it! +1. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |