On 26 March 2013 22:49, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2013/3/26 Frank Shearar <frank.shearar at gmail.com>:
>> Thanks very much Chris, I'll give this a whirl.
>>
>> Indeed, my _primary_ goal is to run things headless, which requires
>> decent error reporting to stdout/stderr.
>>
>> However, I do really like REPLs (I use Clojure's, Python's and Ruby's
>> just about every day), and having such a thing for Smalltalk would
>> make me very happy. It would aid my ambassadorship greatly as well.
>>
>> frank
>>
>
> But isn't REPL is more demanding than just read-eval-print?
>
> Without a decent class/message discovery mechanism (replacing the browser)
> - on line help
> - autocompletion
> - ...
> nor decent error reporting and debugging services,
> could your ambassadorship sustain comparison to above references?

Sure. But saying to people "sorry but you have no easy way to test
something short of running inside this special UI unlike anything
you've ever used, with special keybindings like nothing you've ever
used" doesn't win me anything.

It'd take a fair amount of work before one could compete with SLIME,
but Python's and Ruby's REPLs are pretty primitive.

And I don't suggest reimplementing all of this: Camillo Bruni and co
have done a lot of work in this area already.

frank

> Nicolas
>
>> On 26 March 2013 21:40, Chris Muller <asqueaker at gmail.com> wrote:
>>> Forwarding to your personal email as I have a feeling squeak-dev is
>>> going to bounce my message due to being a whopping 130K attachment.
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Chris Muller <asqueaker at gmail.com>
>>> Date: Tue, Mar 26, 2013 at 4:38 PM
>>> Subject: Re: [squeak-dev] The Trunk: Graphics-tpr.205.mcz
>>> To: The general-purpose Squeak developers list
>>> <squeak-dev at lists.squeakfoundation.org>
>>>
>>>
>>> Here is my little wrapper for handling running .st scripts from the
>>> command-line and outputting Notifications and SyntaxErrors to stdOut
>>> and Errors to stdErr.  I use this every day, at one time I had wanted
>>> to integrate this into the trunk.
>>>
>>> I've never found interacting back-and-forth with an image via
>>> command-line in the style of Camillo's tool useful.  I don't know when
>>> one would want to do that.  However certainly I do need to kick off
>>> Smalltalk jobs from the command-line, headless or not, by passing in
>>> .st scripts and that sounds like what  you're wanting to do with a
>>> build server.
>>>
>>> MaCommandLineProcessor in the attached package is 11 methods total --
>>> it thinly wraps Squeaks existing capability so that some of the
>>> "gotcha's" are taken care of -- for example like the fact that if you
>>> try to print an Error's signalerContext's longStack, it's full of CR's
>>> rather than the platform line-ending making it unreadable in the host
>>> OS.  MaCommandLineProcessor in the attached package fixes that.
>>>
>>> Comments welcome -- maybe you'll see some tips at least..
>>>
>>>
>>>
>>> On Tue, Mar 26, 2013 at 1:49 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>> On 26 March 2013 00:27, tim Rowledge <tim at rowledge.org> wrote:
>>>>> Starting from a fresh image from the Jenkins server that claimed to be completely clean and up to date
>>>>
>>>> That's going to be the best we have, for the moment. Mainly because
>>>> * we never have a green build,
>>>> * Squeak has very limited command line support
>>>> ** you need to feed it a chunk-formatted startup script, or a script
>>>> with no !s in it
>>>> ** exceptions mean debuggers pop up, rather than dumping stack traces to stdout
>>>>
>>>> But otherwise, if the resulting image is _not_ completely clean & up
>>>> to date, it's my fault, and please yell at me. Preferably in the form
>>>> of a nice bug report :)
>>>>
>>>> frank
>>>>
>>>>>, making the changes to get rid of the obsolete 'BitBlt current' idiom for everything visible, I have now committed about half-a-dozen packages that seem to be correct.
>>>>>
>>>>> I also committed a VMMaker change to
>>>>> a) move BitBltSImulation under SmartSyntaxPlugin
>>>>> b) move the pixel-peeker primitive into BitBltSimulation
>>>>> c) update the comment a bit to include some combination rules added about  ten years ago
>>>>>
>>>>> A VM built from this passes the BitBltTests in TestRunner and appears to run everything normally.
>>>>>
>>>>> tim
>>>>> --
>>>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>>>> Strange OpCodes: SD: Self Destruct
>>>>>
>>>>>
>>>>>
>>>>
>>
>