Smalltalk › Usenets › Dolphin Smalltalk

Binary filing classes bug ?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Chris Uppal-3

Binary filing classes bug ?

I just posted an example of using binary packages, and while I was putting it
together I noticed what I think is a bug.

The first version of the test class had a method:

============
tryMe
Transcript nextPutAll: 'It worked!'; cr.
============

but that apparently caused the class STBer to include the Transcript itself in
the deployed .pak file. Then attempting to load the test class from the .pak
file tried to reconstitute the Transcript and failed with walkbacks.

-- chris

Blair McGlashan

Re: Binary filing classes bug ?

Chris

You wrote in message news:3e59ec52$0$9694$[hidden email]...
> I just posted an example of using binary packages, and while I was putting
it

> together I noticed what I think is a bug.
>
> The first version of the test class had a method:
>
> ============
> tryMe
> Transcript nextPutAll: 'It worked!'; cr.
> ============
>
> but that apparently caused the class STBer to include the Transcript

itself in
> the deployed .pak file. Then attempting to load the test class from the
.pak
> file tried to reconstitute the Transcript and failed with walkbacks.

By default globals are not proxied (it has to be done explicitly by the
class of the object, or the client), so probably TranscriptShell needs an
#stbSaveOn: method. We haven't bothered with that because the Transcript is
really a development time only window in Dolphin.

Regards

Blair

Andy Bower

Re: Binary filing classes bug ?

Chris,

> > The first version of the test class had a method:
> >
> > ============
> > tryMe
> > Transcript nextPutAll: 'It worked!'; cr.
> > ============
> >
> > but that apparently caused the class STBer to include the Transcript
> itself in
> > the deployed .pak file. Then attempting to load the test class from the
> .pak
> > file tried to reconstitute the Transcript and failed with walkbacks.
>
> By default globals are not proxied (it has to be done explicitly by the
> class of the object, or the client), so probably TranscriptShell needs an
> #stbSaveOn: method. We haven't bothered with that because the Transcript

is
> really a development time only window in Dolphin.

Perhaps I should add that, in general, a better way of "tracing" is to use:

NotificationManager signal: aString

since this will log to the transcript in the development system and can also
be trapped and redirected in a deployed app. The default for a deployed app
(implemented by SessionManager>>trace:) is to use
KernelLibrary>>outputDebugString:

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---