Compiler Flag (SendYourself)

Hi,

I'm trying to turn off the compiler flag "SendYourself", but i can not find
where.

(I'm having some problems with ODBReference of OmniBase, since
anODBReference yourself return anODBReference Not the referenced object)

Any one did it ?


Regards
Bruno

Bruno wrote:

> (I'm having some problems with ODBReference of OmniBase, since
> anODBReference yourself return anODBReference Not the referenced
> object)

You just beat me to it.  I was about to post exactly the same question...

I suspect, though, that the best long-term approach is probably to make
OmniBase (and STS) send a different selector -- #resolve say -- instead of
#yourself.

BTW, #resolve could usefully be defined against Object as a part of the
standard image, specifically for this kind of use.

    -- chris

> I suspect, though, that the best long-term approach is probably to make
> OmniBase (and STS) send a different selector -- #resolve say -- instead of
> #yourself.

Yes! I did the same.

But I invented #mySelf message (may be too similar to #yourself ?)

Object
mySelf
    ^self
ODBReference
mySelf
    ^demandLoader

>BTW, #resolve could usefully be defined against Object as a part of the
>standard image, specifically for this kind of use.

I have a package named "OmniBase Additional" where i put this stuff.
But if it came with the standard image it will be better.

Regards
Bruno

"Bruno" <[hidden email]> wrote in message
news:b86791$6it0u$[hidden email]...
> Hi,
>
> I'm trying to turn off the compiler flag "SendYourself", but i can not
find
> where.
>
> (I'm having some problems with ODBReference of OmniBase, since
> anODBReference yourself return anODBReference Not the referenced object)
>
> Any one did it ?

It is missing from the CompilerFlags pool (sorry), where it should have the
value 16r400.

Regards

Blair

Bruno wrote:
Yes, I've just added #resolve to my version, defined the same way.  I didn't
bother to define #resolve against ODBReference, though (happened not to think
of it, and I doubt if it's worth adding now).

In case it helps anyone else using STS or OmniBase, here are the changes I've
made.  STS *seems* to be working, after an hour or so of versioning stuff, and
browsing editions.

Changes to Omnibase package:
    Added Object>>resolve.  Defined to answer self.
    Changed:
        ODBLocalTransaction>>store:in:ifLocked:
        ODBLocalTransaction>>markDirty:
    to send #resolve instead of #yourself.

Changes to STS package(s)
    Changed:
        StsPackageEdition>>loadGlobals
        StsMethodEdition>>source
        StsManager>>versionPackage:
        StsManager>>getClassEditions:in:
        StsManager>>addPackageEdition:toProjectEdition:
        StsPackageEdition>>loadResourcesIn:progress:tick:
        StsVersionTreeDiagram>>add:asChildOf:
        StsResourceEdition>>resource
        StsClassEdition>>compareWith:on:
        StsPackageEdition>>imageStripperBytes
        StsManager>>addPackageEdition:beforeIndex:onProjectEdition:

    to send #resolve instead of #yourself.
    Added StsStbProxy>>resolve with same implementation as #yourself used to
have.
    Deprecated StsStbProxy>>yourself and made it forward to #resolve.

As I say, this *seems* to be working for me, but I'd be interested (*very*!) to
hear of anything I've missed.

    -- chris

"Blair McGlashan" <[hidden email]> wrote in message
news:b8869v$78am8$[hidden email]... the
> value 16r400.

Could someone please explain how to set the system wide compiler flags and
recompile.  I see this mentioned as a workaround in the release notes but
there is not enough information.  Google does not know, and neither do I. ;)
Until I can get new versions of some tools I would like to use this
workaround.

Chris

Christopher J. Demers wrote:

> Could someone please explain how to set the system wide compiler
> flags and recompile.  I see this mentioned as a workaround in the
> release notes but there is not enough information.  Google does not
> know, and neither do I. ;) Until I can get new versions of some tools
> I would like to use this workaround.

Not I.  I fixed the tool -- in my case STS -- instead.

It *looks* as if you'd have to change the definition of Behavior>>basicCompile:
to include the value Blair mentioned in the "flags" passed to
#compile:in:flags, and then send #recompileAll to each of the root classes
(Object and ProtoObject in a vanilla image).  I'm not at all confident that
that catches all cases, though.

For me it was easier to fix STS (working in a 5.0.3 image) and then load the
code into D5.1, than to try to force the 5.1 system into a globally "unnatural"
state (not least because the optimisation looks quite valuable for JNIPort).

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:3eb11904$0$45175$[hidden email]... Behavior>>basicCompile:
> to include the value Blair mentioned in the "flags" passed to
> #compile:in:flags, and then send #recompileAll to each of the root classes
> (Object and ProtoObject in a vanilla image).  I'm not at all confident
that
> that catches all cases, though.

It would seem there is not an easy way to override the flags.  As it turns
out it sounds like STS is my main problem.  So I may follow your example, or
see if David has a revision available.

> For me it was easier to fix STS (working in a 5.0.3 image) and then load
the
> code into D5.1, than to try to force the 5.1 system into a globally
"unnatural"
> state (not least because the optimisation looks quite valuable for
JNIPort).

That is a good point.  It would be nice to benefit from the optimization.
Actually now I am thinking about selective recompilation of only a few
methods with the flag.

Chris

Christopher J. Demers wrote:

> It would seem there is not an easy way to override the flags.  As it
> turns out it sounds like STS is my main problem.  So I may follow
> your example, or see if David has a revision available.

Further up-thread I posted a list of the changes I'd made to STS/OmniBase, I
can add that they *still* don't seem to have broken it after several more days
of use ;-)

> That is a good point.  It would be nice to benefit from the
> optimization. Actually now I am thinking about selective
> recompilation of only a few methods with the flag.

I wondered about that too, essentially by overriding the #basicCompile: method
in selected classes, but decided that it'd be too fragile for my taste -- the
main problem being that it's the *sender* of #yourself that needs to be hacked,
not the receiver.

    -- chris