Improvements to wiki.squeak.org

> 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)?
>

>
> If you update your CommandShell package to the latest version, you can now
> use ExternalCommandShell to do wonderfully useless things such as this:
>
>    lewis@lewis-Gazelle-Pro:~/squeak/Squeak5.1$ run squeakSpur64.image
>
>    sqsh> 3 + 4
>    7
>    sqsh> 3 + 4!
>    7
>    sqsh> 3\
>    + 4!
>    7
>    sqsh> exit

> Hi Alistair,
>
> On Sun, Apr 8, 2018 at 2:19 PM, Alistair Grant <[hidden email]>
> wrote:
>>
>> 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.
>
>
> 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.

> Hi Chris, Hi Benoît,
>
> On Apr 8, 2018, at 5:13 PM, Chris Muller <[hidden email]> wrote:
>
> 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.
>
>
> You've probably seen this in the other thread.  Forgive me; I don't mean to
> say "I told you so", and the REPL that I did implement is for my own usage,
> in which I find it much more convenient than scripts.  But I don't like to
> see useful things shot down.
>
> On Apr 12, 2018, at 1:16 AM, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
> On 12 Apr 2018, at 03:15, Eliot Miranda <[hidden email]> wrote:
>
>
> Hi Sven,
>
>
> On Wed, Apr 11, 2018 at 1:25 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>
>
> On 11 Apr 2018, at 21:44, Stephane Ducasse <[hidden email]> wrote:
>
>
> I did not know about the NeoConsole. Nice because I wanted to build a
>
> little REPL for my minilanguage implementation.
>
>
> You are of course welcome to look at it.
>
> But it is Pharo specific.
>
> I use it to be able to hook/look into running headless server images.
>
> For this it is super handy.
>
>
> Cool usage!  Could you tell me whether you type Smalltalk expressions into
> this to examine your running server?  The answer will be used in a related
> discussion on a mailing list not too distant from this one ;-)
>
>
> Yes of course, that it the whole purpose, to type in expressions and to
> manipulate objects in a running image. I recently added options to look at
> code and change/add methods. All very primitive, but when in trouble, it
> works well.
>
>
> So it turns out to be very useful.

> Hi Eliot,
>
> I went back to Benoit's words to look for what may have caused
> negative feelings to emerge.  My guess is it must be the last two
> sentences.  From what I know of you, you're in my "friend" psyche, and
> I read your words in that context.  Try to read Benoit's expression of
> doubt as merely an invitation for someone to please provide some
> enlightenment.  He did say it was "cool," to which I agree, and no one
> wants to shoot down cool.  I want to learn.  Please allow me to
> inquire the circumstances about when a Smalltalk REPL would be useful,
> and be _necessarily critical_ of that usefulness, without taking it
> personally but by further enlightenment; which, you did.  :)
>
> I'm sincerely intrigued by Smalltalk REPL's, but still skeptical that
> *I* would have the patience to use them given all the other tools at
> my disposal; VNC, error-handling, logging, intercepting kill signals,
> etc.  That does not mean it is not useful for others or in other
> contexts, though.
>
>  - Chris
>
> On Thu, Apr 12, 2018 at 3:35 AM, Eliot Miranda <[hidden email]>
> wrote:
>> Hi Chris, Hi Benoît,
>>
>> On Apr 8, 2018, at 5:13 PM, Chris Muller <[hidden email]> wrote:
>>
>> 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.
>>
>>
>> You've probably seen this in the other thread.  Forgive me; I don't mean
>> to
>> say "I told you so", and the REPL that I did implement is for my own
>> usage,
>> in which I find it much more convenient than scripts.  But I don't like to
>> see useful things shot down.
>>
>> On Apr 12, 2018, at 1:16 AM, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>>
>> On 12 Apr 2018, at 03:15, Eliot Miranda <[hidden email]> wrote:
>>
>>
>> Hi Sven,
>>
>>
>> On Wed, Apr 11, 2018 at 1:25 PM, Sven Van Caekenberghe <[hidden email]>
>> wrote:
>>
>>
>> On 11 Apr 2018, at 21:44, Stephane Ducasse <[hidden email]>
>> wrote:
>>
>>
>> I did not know about the NeoConsole. Nice because I wanted to build a
>>
>> little REPL for my minilanguage implementation.
>>
>>
>> You are of course welcome to look at it.
>>
>> But it is Pharo specific.
>>
>> I use it to be able to hook/look into running headless server images.
>>
>> For this it is super handy.
>>
>>
>> Cool usage!  Could you tell me whether you type Smalltalk expressions into
>> this to examine your running server?  The answer will be used in a related
>> discussion on a mailing list not too distant from this one ;-)
>>
>>
>> Yes of course, that it the whole purpose, to type in expressions and to
>> manipulate objects in a running image. I recently added options to look at
>> code and change/add methods. All very primitive, but when in trouble, it
>> works well.
>>
>>
>> So it turns out to be very useful.
>
>

> On 05-05-2018, at 12:06 AM, Ben Coman <[hidden email]> wrote:
>
>
>
> On 4 May 2018 at 18:53, Craig Latta <[hidden email]> wrote:
>
> Quoth evaluates English as Smalltalk code
> (roughly as a sequence of unary messages, with mild gymnastics for
> punctuation).
> [1] http://netjam.org/quoth
>
> "Behind the scenes, the system is taking the natural language states traversed by the player and generating Smalltalk code from them." [1]
>
> Wow. Just blew my mind.

>> Quoth evaluates English as Smalltalk code
>> (roughly as a sequence of unary messages, with mild gymnastics for
>> punctuation).
>> [1] http://netjam.org/quoth
>
>
> "Behind the scenes, the system is taking the natural language states
> traversed by the player and generating Smalltalk code from them." [1]
>
> Wow. Just blew my mind.