[squeak-dev] The Trunk: Graphics-tpr.205.mcz

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Mar 26 22:49:08 UTC 2013


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?

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


More information about the Squeak-dev mailing list