DBTxn transcriptMessage: stripped

Hello

I am packaging a Database application.  According to the Dolphin
Application Deployment log DBTxn>>transcriptMessage: is being
stripped.

When I issue a commit I get a warning message from the Session manager
about this.  The error log shows that DBTxn doesNotUnderstand

Not sure why this is being stripped.

At any rate I have found where to preserve classes that should not be
stripped, but I have NOT found how to preserve methods that shouldn't
be stripped.  And even if you preserve a class, it still seems to
strip what it thinks are unused methods

Any suggestion would be appreciated<g>!

Even putting this method in the must not strip category did not force
it to be retained.

Eric,

If you turn off "Strip redundant messages" in the image stripper does the
problem go away? Certainly, adding the rogue method to the "must not strip"
method category should be enough to get it to hang around. The fact that it
doesn't, seems to indicate that something strange is going on. Can you send
through (or post up) the stripping log and the contents of the error log?
Make sure both files are current by deleting them first.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com

---
Visit the Dolphin Smalltalk WikiWeb
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---

Eric

"Eric Langjahr" <[hidden email]> wrote in message
news:[hidden email]...
> Even putting this method in the must not strip category did not force
> it to be retained.

The method is in the "development" category, which is stripped forcibly. I'd
imagine it was intended for development-time use only (the name would
certainly suggest that originally it wrote directly to the Transcript, which
is not available at run time). The current implementation writes to the
"trace" device of the current SessionManager, so there is no particular
reason for it to be in the "development" category any longer. You can just
remove it from that category, which is best done from the package deployment
"script" so that the change is preserved as part of your package:

    (MethodCategory name: 'development')
        removeMethod: (DBTxn compiledMethodAt: #transcriptMessage:)

We'll change this in the next patch/maintenance release, but the above will
continue to work (as a no-op).

Regards

Blair

Blair - that worked fine.  I have one other issue<g>.

I have methods that are only invoked thru #perform: messages.

These methods appear to be getting stripped.

Is there a simple way to insure that a Class and all its methods are
not stripped, or do I have to put all these methods in a must not
strip category?

Thanks, again for all your help

On Tue, 23 Jan 2001 09:49:22 -0000, "Blair McGlashan"
<[hidden email]> wrote:

Well I used your example to point me to the MethodCategory class.
I programatically iterate thru all the compiled methods for all my
classes and add them to the 'must not strip' category.  Really neat
how you can do all this on the fly!

Not sure if there isn't a more elegant way, but this got me going.

I love it<g>!

On Tue, 23 Jan 2001 07:15:34 -0800, Eric Langjahr
<[hidden email]> wrote:

>Blair - that worked fine.  I have one other issue<g>.
>
>I have methods that are only invoked thru #perform: messages.
>

Eric,

> Well I used your example to point me to the MethodCategory class.
> I programatically iterate thru all the compiled methods for all my
> classes and add them to the 'must not strip' category.  Really neat
> how you can do all this on the fly!
>
> Not sure if there isn't a more elegant way, but this got me going.

The one thing to watch for is adding methods and forgetting to re-run your
script.  You might want to include it in a pre-strip script if you have not
done so already.


> I love it<g>!

Andy, I'm starting to think we need another run of T-shirts :)

Have a good one,

Bill

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

Good point.  Actually most of these classes that are being stripped
are being compiled on the fly based on either flat file layouts or sql
tables.  So what I will probably do is change the compile: code to
also put the methods in the proper category at compile time.

T-shirts?  Did you say T-shirts? <g>

On Tue, 23 Jan 2001 12:10:07 -0500, "Bill Schwab"
<[hidden email]> wrote:

>Eric,
>
>> Well I used your example to point me to the MethodCategory class.
>> I programatically iterate thru all the compiled methods for all my
>> classes and add them to the 'must not strip' category.  Really neat
>> how you can do all this on the fly!
>>

Andy, adding 'must not strip' category to my methods DID make them
stick around.

It just didn't work on the DBTxn>>transcriptLog: because it is a
development category method.

Blairs suggestion to remove the transcriptLog: method from development
corrected the problem with it being stripped out.

I had explicitly preserved my classes by making a subclass of
ImageStripper invoking super requiredClasses ... and then adding my
classes to the list of required classes.
However this didn't stop my methods in these classes from being
removed regardless of settings. These methods were only invoked with
perform: someString asSymbol.

Because that usage couldn't be detected,  I am guessing that the
methods were being, quite correctly stripped.

At any rate, my impression is that the Deployment Kit is working
correctly and I was successfully able to deploy my app after the
adjustments I made.

So I am not sure, at this point, if you need a log or not.  Things
seem to be working correctly.

On Tue, 23 Jan 2001 07:33:01 -0000, "Andy Bower"
<[hidden email]> wrote:

Eric

You wrote in message news:[hidden email]...
>...
> However this didn't stop my methods in these classes from being
> removed regardless of settings. These methods were only invoked with
> perform: someString asSymbol.
>
> Because that usage couldn't be detected,  I am guessing that the
> methods were being, quite correctly stripped.

As I'm sure you've realised (but for the benefit of others), there is no
general problem with methods being stripped that are #perform:'d, as long as
the selectors used are literal constants. The ADK cannot detect dynamically
constructed selectors (and neither can the browser tools, so athough this is
a powerful technique that has its uses, we do recommend avoiding it where
alternatives exist).

Another workaround where the set of selectors is well-known (fixed), but
still dynamically constructed, is to include them all in a method which you
know will not be stripped - e.g. a dummy one created specifically for this
purpose and placed in the 'must not strip' category of a class that you know
will not be stripped. Here is an example:

selectorsNotToStrip
    #preservedSelector.
    #anotherPreservedSelector.
    #yetAnotherPreservedSelector.
    #andSoOn.

A literal array could also be used.

On the other hand if you are generating the implementations, then it easier
just to compile them directly into the 'must not strip' category as you are
now doing.

Regards

Blair