STBPrefix - a would-be bug?

Hi Blair,

One of my unit tests fails intermittently.  The failure usually ends up with
a garbled string, though I haven't been able to reproduce it, and have not
been able to get the garbling to happen separate from a lot of other code.
Two things that I've considered are thread synchronization problems and a
change in the binary filer (or its behavior secondary to some other change
in the image).  The latter idea is the result of some debugging in a failed
case; inspecting an intermediate expression gave me a "not in STB format"
error that reminded me of the problem I had with that view resource (ok,
its' not exactly scientific, but, I'm running out of ideas<g>).

While I haven't found any problems, I might have noticed one in waiting.
STBPrefix shifts one way using a pool value, and the other way using a
literal (1); see below.

Have a good one,

Bill


!STBPrefix methodsFor!

smallInteger
 "Answer the receiver decoded into a SmallInteger."

 ^dword bitShift: SmallIntegerShift! !
!STBPrefix categoriesFor: #smallInteger!accessing!public! !

!STBPrefix methodsFor!

smallInteger: aSmallInteger
 "Make the receiver a prefix to a 'virtual' SmallInteger, virtual because
 as we encode the integer entirely within the prefix no object data need
follow."

 dword := (aSmallInteger bitShift: 1) bitOr: SmallIntegerMask! !
!STBPrefix categoriesFor: #smallInteger:!accessing!public! !


---
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair,

> One of my unit tests fails intermittently.  The failure usually ends up
with
> a garbled string, though I haven't been able to reproduce it, and have not
> been able to get the garbling to happen separate from a lot of other code.

The plot thickens: I can't get my 98 machine at home to exhibit the failure
=:0   I'll try some more and will check DLL versions on the offending NT
machine.  Some of the "STB" trouble was caused by side effects during
debugging.  At this point, I'm left with an NT4 machine that seems to be
mangling the first four characters of certain strings (or maybe symbols).
It seems unlikely that it's an STB versioning problem, because that should
strike more reliably, and should also occur here.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Blair,
>
> One of my unit tests fails intermittently.  The failure usually ends up
with
> a garbled string, though I haven't been able to reproduce it, and have not
> been able to get the garbling to happen separate from a lot of other code.
> Two things that I've considered are thread synchronization problems and a
> change in the binary filer ...

STB is completely unchanged since Dolphin 4.0, so it could not be that.

>...(or its behavior secondary to some other change
> in the image).

Which is possible of course. STB also uses certain VM primitives indirectly,
such as the ones to access 32-bit integers out of byte arrays, but off the
top of my head I don't believe these have been changed either.

>...The latter idea is the result of some debugging in a failed
> case; inspecting an intermediate expression gave me a "not in STB format"
> error that reminded me of the problem I had with that view resource (ok,
> its' not exactly scientific, but, I'm running out of ideas<g>).

>
> While I haven't found any problems, I might have noticed one in waiting.
> STBPrefix shifts one way using a pool value, and the other way using a
> literal (1); see below.

They are shifting in opposite directions, so somone (probably me) attempting
to squeeze the last drop of performance out has "optimized" it. I'll address
that, but it isn't actually a bug (if it were then STB would not be
operating terribly well). I don't think the STBPrefix>>smallInteger method
is actually used any more, except for development time stuff such as
#printOn: and the STBDebugger, because the aforementioned optimization also
included inlining most of its code into STBInFiler. In fact the in-filer
doesn't create STBPrefix instances at all.

Regards

Blair

Blair,

> They are shifting in opposite directions, so somone (probably me)
attempting
> to squeeze the last drop of performance out has "optimized" it. I'll
address
> that, but it isn't actually a bug (if it were then STB would not be
> operating terribly well).

Understood, but, if you ever did change the pool value, it could cause
problems, if only during development.


> STB is completely unchanged since Dolphin 4.0, so it could not be that.

That's simple.


> >...(or its behavior secondary to some other change
> > in the image).
>
> Which is possible of course. STB also uses certain VM primitives
indirectly,
> such as the ones to access 32-bit integers out of byte arrays, but off the
> top of my head I don't believe these have been changed either.

That kind of thing could account for what always looks like four bytes of
garbage.  It's intermittent even on the NT box, so maybe it's a numerical
value and/or position type of problem - something that strikes only under
specific conditions that just happens to be more likely to occur on the one
machine.  I'll play around some more.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]