Does this lay the groundwork towards a Linux Terminal "(SQ)REPL" interface to a headless VM?

Should this be the place to start such a project?

thx.

tty

---- On Mon, 11 Jul 2016 03:40:17 -0400 marcel.taeumel<Marcel.Taeumel@hpi.de> wrote ----

<http://forum.world.st/file/n4905883/squeak-shell-2.gif%3E;

See SqshCommandLine >> #editText to understand extension points (shortcuts) inthe command line and how to run custom applications (i.e. subclasses of SqshController).

Best, Marcel

David T. Lewis wrote > This is a really nice demonstration of how Projects work in Squeak. It > is completely different from either Morphic or MVC, and the removal of > the traditional GUI makes it clear that Projects are not directly tied > to any one mode of user interaction. > > The shell itself has an interesting conceptual model. We usually think > of a "shell" or "console window" that navigates around file systems, > such that where you are in the shell is based on a current working > directory in a file system. But in SqueakShell we are navigating in > the object space. > > And of course the text-mode Squeaky the Mouse logo makes for a compelling > user experience :-) > > I would encourage everyone to try loading this and playing around with > SqueakShell. > > Dave > > > On Fri, Jul 08, 2016 at 07:17:26AM -0700, marcel.taeumel wrote: >> Hi, there! >> >> I am happy to announce a new kind of project for Squeak: "The Squeak >> Shell". >> :-) >> >> You can install it into any trunk image via: >> >> Installer swa >> project: 'SqueakShell'; >> install: 'SqueakShell'. >> >> Then you will find a new kind of project under Projects -> New Project >> ... >> >> The Squeak Shell is independent from Morphic and MVC. It's architecture >> is, >> partially, a mixture of both. :-D I wanted to keep it as simple as >> possible >> while avoiding global state as much as possible. >> >> My goal is to add it to trunk to simplify modularization of MVC and >> Morphic. >> For example, we have to extract UserInputEvent and Canvas from Morphic >> into >> the base system. These would form a splendid addition to other projects >> because object-oriented event processing and displaying is not something >> that only Morphic should have. >> >> The Squeak Shell helped me refactor Squeak's project mechanism. It also >> revealed potential improvements for our Debugger, which I am going to >> address later this year. One goal is to make Squeak more robust and >> mitigate >> the risk of getting locked out of the system. >> >> Here is the interesting part: It can be used to recover from >> serious/recursive errors in Morphic and MVC. When you open a new Morphic >> project from within a Squeak Shell project, the shell will appear then. >> Only >> recursive errors in the shell will then start our traditional emergency >> evaluator. >> >> Some figures: 12 classes, 274 methods, 1454 LOC. >> >> You can open the Squeak Shell on top of the Morphic loop ("SqueakShell >> open") or as custom process inside the Morphic project ("SqueakShell >> openConcurrent"). You enter a SqueakShell project via: "SqueakShell >> openAsProject". >> >> The core of the Squeak Shell covers only 6 classes (see >> "SqueakShell-Core"). >> There are already two applications in this project: (1) a command line >> and >> (2) a text editor (see "SqueakShell-Tools"). >> >> You can use the Squeak Shell to explore all our tool extension points, >> which >> we use for browsing classes, inspecting objects, debugging unhandled >> errors >> in processes, etc. For this, take a look at SqshProject, SqshToolSet, and >> SqshUIManager. >> >> I am sure that there can be an even smaller kind of project. However, I >> am >> not so sure about the usefulness of such a project. :-) >> >> <http://forum.world.st/file/n4905613/shell.png> >> >> Have fun! >> Marcel >> >> >> >> -- >> View this message in context: >> http://forum.world.st/ANN-The-Squeak-Shell-tp4905613.html >> Sent from the Squeak - Dev mailing list archive at Nabble.com.

Thank you.

---- On Mon, 11 Jul 2016 06:44:28 -0400 marcel.taeumel <Marcel.Taeumel@hpi.de> wrote ----

gettimothy wrote > Does this lay the groundwork towards a Linux Terminal "(SQ)REPL" interface > to a headless VM? > > Should this be the place to start such a project? > > thx. > > tty

Hi Timothy,

if you would replace event access (SqshControlManager) and screen output (FormCanvas), sure. For a non-pixel output, you might want to also move the (text) cursor. I did try to use stdin and stdout, but it is blocking for an empty input. At least on my Windows machnine. Maybe telnet could work.

Once, we did a student's project called "SqueakREPL". They used telnet, I guess, and also managed to provie an interactive debugger. Not sure, however, how close to the base system they remained and whether there are many dependencies on Morphic.

For other headless apps, which do not necessarily require the flexibility of a command line, an even smaller kind of project would be sufficient. See SqshProject.

Best, Marcel

On 11.07.2016, at 15:18, Tony Garnock-Jones tonyg@ccs.neu.edu wrote:

On 2016-07-11 6:44 AM, marcel.taeumel wrote:

...

I did try to use stdin and stdout, but it is blocking for an empty input.

This sounds like the problems I was having reading from /dev/... files.

Perhaps the OSProcess-nonblocking-style solution I was using there could also work for this case: http://lists.squeakfoundation.org/pipermail/squeak-dev/2016-June/190051.html

Regards, Tony

Or it's just buffered… That was the problem the SqueakREPL students were having and why they switched to telnet: it's not (yet?) possible to set stdout and stdin to unbuffered, let alone 'raw' (as opposed to 'cooked').

Best regards -Tobias

On 11-07-2016, at 12:40 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:

http://forum.world.st/file/n4905883/squeak-shell-2.gif

Interesting. Now if only you can make it a bit more cryptic and unfriendly we might convince all those dead-text-file weenies that we have a ‘real’ language.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Has a pulse, but that's about all.

On 12 July 2016 at 01:14, Dale Henrichs dale.henrichs@gemtalksystems.com wrote:

However, whenever I see a Smalltalk shell where folks are typing Smalltalk into the REPL I cringe, because Smalltalk is not really a scripting language

Whereas I see a wonderful minimal system for debugging when I've broken

MVC, Morphic or sometimes both :-). My use case is to require as small a part of the image as possible to function while I work out what's happened. Any sugar on top is extra code that I might have broken!

Cheers,

- Peter

Dale Henrichs-3 wrote

Marcel,

Very Cool!

However, whenever I see a Smalltalk shell where folks are typing Smalltalk into the REPL I cringe, because Smalltalk is not really a scripting language ... but I think that having scripts written in Smalltalk and callable from a shell is a real interesting idea.

In tODE[2] I allow folks to create scripts written Smalltalk that can be called from a command line and it is a very simple idea ... The Smalltalk script is simply a block.

Here's an example script[1] that is callable from a command line that looks like one of the following:

bug --help bug --install bug --clean --create--boom; edit

A command object is passed in from the command line parser and the command options are turned into a `opts` Dictionary with option names as keys and option values as values ...

Instead of stdin and stout being byte streams, the stdin and stdout for Smalltalk scripts are objects (objIn and objOut) --- the objIn arg in the block is the objIn for the script, basically the result of the last command.

The edit command above brings up an inspector on the result of the script ...

For tODE the script object (block) can be registered in the Smalltalk image itself or the script object can be written to disk[4] in STON[3] format --- making the script easily callable from multiple images ...

I can share the command/option/argument code if you are interested ... adding Smalltalk scripts to your REPL should be very straightforward ...

Dale

[1] https://gist.github.com/dalehenrich/97f2befe07ad7bf928165a3fc64a2118 [2] https://github.com/dalehenrich/tode#tode-the-object-centric-development-envi... [3] https://github.com/svenvc/ston#ston---smalltalk-object-notation [4] https://gist.github.com/dalehenrich/be9e7cd439eb5a5a0d9e937cc0a04f86

On 07/08/2016 07:17 AM, marcel.taeumel wrote:

...

Hi, there!

I am happy to announce a new kind of project for Squeak: "The Squeak Shell". :-)

You can install it into any trunk image via:

Installer swa project: 'SqueakShell'; install: 'SqueakShell'.

Then you will find a new kind of project under Projects -> New Project ...

The Squeak Shell is independent from Morphic and MVC. It's architecture is, partially, a mixture of both. :-D I wanted to keep it as simple as possible while avoiding global state as much as possible.

My goal is to add it to trunk to simplify modularization of MVC and Morphic. For example, we have to extract UserInputEvent and Canvas from Morphic into the base system. These would form a splendid addition to other projects because object-oriented event processing and displaying is not something that only Morphic should have.

The Squeak Shell helped me refactor Squeak's project mechanism. It also revealed potential improvements for our Debugger, which I am going to address later this year. One goal is to make Squeak more robust and mitigate the risk of getting locked out of the system.

Here is the interesting part: It can be used to recover from serious/recursive errors in Morphic and MVC. When you open a new Morphic project from within a Squeak Shell project, the shell will appear then. Only recursive errors in the shell will then start our traditional emergency evaluator.

Some figures: 12 classes, 274 methods, 1454 LOC.

You can open the Squeak Shell on top of the Morphic loop ("SqueakShell open") or as custom process inside the Morphic project ("SqueakShell openConcurrent"). You enter a SqueakShell project via: "SqueakShell openAsProject".

The core of the Squeak Shell covers only 6 classes (see "SqueakShell-Core"). There are already two applications in this project: (1) a command line and (2) a text editor (see "SqueakShell-Tools").

You can use the Squeak Shell to explore all our tool extension points, which we use for browsing classes, inspecting objects, debugging unhandled errors in processes, etc. For this, take a look at SqshProject, SqshToolSet, and SqshUIManager.

I am sure that there can be an even smaller kind of project. However, I am not so sure about the usefulness of such a project. :-)

<http://forum.world.st/file/n4905613/shell.png%3E;

Have fun! Marcel

-- View this message in context: http://forum.world.st/ANN-The-Squeak-Shell-tp4905613.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

Hi Dale,

thanks. Yeah, right now, the Squeak Shell is no scripting environment. There is accessible concept of object streams. This, however, was not the goal here. :-)

If I would want to introduce object streams and improve Squeak's scripting capabilities (wrt. to the Squeak Shell), I would subclass SqshCommandLine and add simple ways to connect blocks or do other things as you suggested. The SqshCommandLine right now only evaluates code, supports bindings, and has some shortcuts (beginning with !). And there is some navigation in the object space with ! and !!.

Best, Marcel

-- View this message in context: http://forum.world.st/ANN-The-Squeak-Shell-tp4905613p4906232.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

Wow Tim, I think you must have been reading Marcel's mind!

Dave

...

On 12-07-2016, at 6:21 AM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:

{snip}

...

Yeah, right now, the Squeak Shell is no scripting environment. There is accessible concept of object streams. This, however, was not the goal here. :-)

I don’t suppose it might be something that could be a more useful replacement for the emergency evaluator ? At least in some cases..

tim

tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Four wheels move the body. Two wheels move the soul

On 12-07-2016, at 12:19 PM, marcel.taeumel Marcel.Taeumel@hpi.de wrote:

Oh, it's a classic one. I made the initial post way too long. And there was no TL;DR. My bad. ;-D

OK, OK, I see (after reading several times) the part where you peripherally mention it.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim All programmers are playwrights and all computers are lousy actors.