Strange instance class valiable behavior

Hi,

    I'm experiencing a strange behavior here, perhaps someone could bring
some ligth to this matter.

    This app had a singleton that holds configuration info and I mada that
this object saves on disk (stb format) and loads from disk. As every
singleton does, it verifies for it's class instance variable called
'current' (so original :).

    In the development environment everithing is ok, but in the executable,
current isn't nil at the begining. Even when I check for allInstances of
that class (having 0), and inspect this class instance variable with flipper
to check that where nil.

    I've logged the instanciation of the variable and never (in the exe)
enters inside the true

    current ifNil:[ current := self loadInstnace ].

    ^ current


    mrs. wizards... I need some help here..

    regards


Seb

Seb,

>     This app had a singleton that holds configuration info and I mada that
> this object saves on disk (stb format) and loads from disk. As every
> singleton does, it verifies for it's class instance variable called
> 'current' (so original :).
>
>     In the development environment everithing is ok, but in the
executable,
> current isn't nil at the begining. Even when I check for allInstances of
> that class (having 0), and inspect this class instance variable with
flipper
> to check that where nil.
>
>     I've logged the instanciation of the variable and never (in the exe)
> enters inside the true
>
>     current ifNil:[ current := self loadInstnace ].

Are you sure this isn't some kind of weird #ifNil: behavior???   I raise the
question only because I don't use those shortcut methods.

The variable is class-side, but you're using a name starting w/ lower case.
That's not conventional, and I vaguely recall Dolphin or Squeak informing me
of that/refusing to cooperate when I did the same thing.

Could you be getting fooled by a workspace variable?  Maybe you are looking
at a "hidden" current in the IDE and the exe is looking for Current, or vice
versa.  As you can tell, I think workspace variables are a bug, not a
feature :)

Those issue aside, have you output a print string or something to show what
current/Current holds in the exe?  Could a Lagoon script be assigning
something to the variable?  Also, on the off chance that you are using
SuiteBuilder, look at your #suiteBuilderPreDeploy methods to verify that
they don't set Current late in the game.

Good luck!

Bill

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

Smalltalkiano wrote:

> Even when I check for
> allInstances of that class (having 0), and inspect this class
> instance variable with flipper to check that where nil.

Are you doing this just before you strip? The Deployment log that is
produced when stripping shows how many instances of each class remain in the
stripped image. Is that showing 0?

Assuming the problem is that for some reason current is not nil, you could
try setting it to nil in the deployment "Pre-Strip Script". Alternatively,
the first thing your SessionManager>>main method could do is to set it to
nil.

Hope this helps,
Steve

--
Steve Waring
Email: [hidden email]
About: http://www.dolphinharbor.org/dh/harbor/steve.html
Journal: http://www.stevewaring.net/blog/home/index.html

> The variable is class-side, but you're using a name starting w/ lower
case.
> That's not conventional, and I vaguely recall Dolphin or Squeak informing
me
> of that/refusing to cooperate when I did the same thing.

I only  relatively began smalltalking seriously but I think that for class
instance variables this rule is not correct, as it is in fact the instance
var of a class object. The speciality about CLASS vraiables is that they are
visible to all instances AND classes even for all subclasses, so there is a
good point in defining them capitalized as mixup with instance vars is quite
likely. For class instance vars there is IMO no point in naming the
uppercase at all, especially as the same mixup with ClassVars exists.

Anyway I remember Squeak used uppercase class inst vars, but I am not shure
it is enforced. At least I consider it bad practise for the above reasons.

Just my two cents...

Ciao

...Jochen

Hi Steve,

    thats a good point I'll try it to unmistify this :)

    Anyway I had to make it some other way to get it 'on time' and worked.

    thank you all,

Seb


"Steve Waring" <[hidden email]> escribió en el mensaje
news:b0chll$o1b88$[hidden email]...
> Smalltalkiano wrote:
>
> > Even when I check for
> > allInstances of that class (having 0), and inspect this class
> > instance variable with flipper to check that where nil.
>
> Are you doing this just before you strip? The Deployment log that is
> produced when stripping shows how many instances of each class remain in
the