Smalltalk › Squeak › Squeak - Dev

[ANN] The Squeak Shell

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

19 messages Options

marcel.taeumel

[ANN] The Squeak Shell

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. :-)

Have fun!
Marcel

David T. Lewis

Re: [ANN] The Squeak Shell

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.

marcel.taeumel

Re: [ANN] The Squeak Shell

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.

tty

Re: [ANN] The Squeak Shell

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<[hidden email]> wrote ----

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

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.

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

marcel.taeumel

Re: [ANN] The Squeak Shell

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

tty

Re: [ANN] The Squeak Shell

Thank you.

---- On Mon, 11 Jul 2016 06:44:28 -0400 marcel.taeumel <[hidden email]> 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

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

Tony Garnock-Jones-3

Re: [ANN] The Squeak Shell

In reply to this post by marcel.taeumel

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

Tobias Pape

Re: [ANN] The Squeak Shell

On 11.07.2016, at 15:18, Tony Garnock-Jones <[hidden email]> 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

timrowledge

Re: [ANN] The Squeak Shell

In reply to this post by marcel.taeumel

> On 11-07-2016, at 12:40 AM, marcel.taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Has a pulse, but that's about all.

Dale Henrichs-3

Re: [ANN] The Squeak Shell

In reply to this post by marcel.taeumel

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-environment-
[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:

David T. Lewis

Re: [ANN] The Squeak Shell

In reply to this post by Tobias Pape

On Mon, Jul 11, 2016 at 04:44:47PM +0200, Tobias Pape wrote:

>
> On 11.07.2016, at 15:18, Tony Garnock-Jones <[hidden email]> 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

The stdin for a Unix process will be blocking by default (a good choice for
processes that are expected to be chained in command pipelines, which is a
fundamental part of the Unix design). Squeak VMs inherit this behavior by
default, although more recent Cog/Spur VMs set the stdin to non-blocking mode
at startup.

You can control this with:

<primitive: 'primitiveSQFileSetNonBlocking' module: 'UnixOSProcessPlugin'>

and:

<primitive: 'primitiveSQFileSetBlocking' module: 'UnixOSProcessPlugin'>

Any Squeak VM will block on read from a blocking input stream. The two basic
strategies for dealing with this are 1) do the blocking read in a thread or
2) set non-blocking mode and use AIO notification to read the available input.

An example of setting non-blocking input from OSProcess/CommandShell is
the ExternalCommandShell REPL that sets nonblocking input in
ExternalCommandShell>>setNonblockingInput.

For the stdin stream of the VM, either of these will set to non-blocking
if the VM has not allready done it for you at startup time:

OSProcess thisOSProcess stdIn setNonBlocking.

OSProcess accessor setNonBlocking: FileStream stdin fileID.

For perspective, the win32 overlapped files design is a thread based approach
(IIUC based on thinking from earlier DEC OSs with AST asynchronous traps handing
the low level IO processing). For a Squeak VM, the equivalent would be a blocking
input stream handled by a thread with asynchronous callbacks (see Eliot's
work with Aliens and FFI callbacks).

Unix applications are more likely to use AIO to accomplish similar things,
and the AIO based event notification in the Unix VMs is an example of this.

As far as I can tell, the two approaches are roughly equivalent, although
I suspect you could still get a good flame war going between VMS bigots
and Unix bigots if you were to raise the topic ;-)

If this subject has caused confusion for students, I would say that it's
a good thing :-) It is worth thinking about, especially as the world moves
to systems with more multiprocessing and concurrency issues.

Dave

Peter Crowther-2

Re: [ANN] The Squeak Shell

In reply to this post by Dale Henrichs-3

On 12 July 2016 at 01:14, Dale Henrichs <[hidden email]> 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

Re: [ANN] The Squeak Shell

On 7/12/16 2:27 AM, Peter Crowther wrote:

On 12 July 2016 at 01:14, Dale Henrichs <[hidden email]> 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 :-).

Haha ... well I use a Smalltalk REPL everyday all day, but i rarely type Smalltalk expressions on the command line - I run Smalltalk scripts/workspaces from the command line ... much more convenient and useful on a regular basis!

Dale

marcel.taeumel

Re: [ANN] The Squeak Shell

In reply to this post by Dale Henrichs-3

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-environment-
[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>
>
> 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

timrowledge

Re: [ANN] The Squeak Shell

> On 12-07-2016, at 6:21 AM, marcel.taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Four wheels move the body. Two wheels move the soul

David T. Lewis

Re: [ANN] The Squeak Shell

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

Dave

>
>> On 12-07-2016, at 6:21 AM, marcel.taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> Four wheels move the body. Two wheels move the soul
>
>

marcel.taeumel

Re: [ANN] The Squeak Shell

David T. Lewis wrote

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

Dave

>
>> On 12-07-2016, at 6:21 AM, marcel.taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> Four wheels move the body. Two wheels move the soul
>
>

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

Best,
Marcel

timrowledge

Re: [ANN] The Squeak Shell

> On 12-07-2016, at 12:19 PM, marcel.taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
All programmers are playwrights and all computers are lousy actors.

Hannes Hirzel

Re: [ANN] The Squeak Shell

Hello Marcel

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

loads fine in Squeak 5.1rc1

Is it possible
a) to have a class comment in SqueakShellProject (aim, current status)
b) An entry in SqueakMap for 5.1

?

Best
Hannes

On 7/12/16, tim Rowledge <[hidden email]> wrote:

>
>> On 12-07-2016, at 12:19 PM, marcel.taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> All programmers are playwrights and all computers are lousy actors.
>
>
>
>