A message send logger in a runtime application...

Some may recall a post I made a few weeks ago about a combo box anomaly.  I
made a test package and I believe the problem is related to the
FramingLayout manager.  I am now trying to find out what the layout manager
is trying to do.  To further that goal I developed a message logger.  It
will write out each message with all arguments, and the result to a file.  I
have it working wonderfully in the development environment.  However when I
deploy it it stops working, no errors, but does not log the message sends.
I suspect this is due to some sort of optimization in the runtime
environment.  I am probably pushing some technical limits with my code.  It
has to do some interesting tricks to wrap the message sends.

I am interested in two things.  First of all is my rather complex approach
required to do what I want?  If so does any one have any idea how I might
get it to work in a deployed EXE?  Perhaps there is an easy way to turn off
the optimization?

My package can be downloaded from the link bellow.  Be warned that it is not
pretty code, it is the results of a frantic debugging session.  I suggest
looking at it in a junk image just to be safe.  My code can be tested in the
development environment by showing the MixtureTestDialog.  That will cause
parts of its layout manager to be wrapped with logging code.  A file called
MitSciMessageLogger.log will be generated in the image directory with the
results of the logging.  It will be closed (and saved) when the Dialog is
closed.  My code seems to work fine in a development image.  My problem is I
can't get it to work in a deployed application.  The interesting bit of code
is in MitSciMessageLogger<<wrapObject:.
http://www.mitchellscientific.com/smalltalk/temp/TestMixtureView.pac
The Instance Behavior Package from OA will be required to load my package.
http://www.object-arts.com/Lib/Downloads/5.0/Per%20Instance%20Behavior.zip

Any advice is greatly appreciated.  If I can get this polished up it might
be another goodie.  I can imagine many situations where it would be useful
to have a log of all message sends with arguments and return values.

Oh yeh, if anyone actually sees the dropped down combobox not displaying
give me a holler.  I only know of one computer this happens on.

Chris

Chris,

> Some may recall a post I made a few weeks ago about a combo box anomaly.
I
> made a test package and I believe the problem is related to the
> FramingLayout manager.  I am now trying to find out what the layout
manager
> is trying to do.  To further that goal I developed a message logger.  It
> will write out each message with all arguments, and the result to a file.
I
> have it working wonderfully in the development environment.  However when
I
> deploy it it stops working, no errors, but does not log the message sends.
> I suspect this is due to some sort of optimization in the runtime
> environment.  I am probably pushing some technical limits with my code.
It
> has to do some interesting tricks to wrap the message sends.

The closest thing to this that I can recall is something that looked at (I
think) instance variables.  Anyway, something that ordinarily returned a
collection of things ended up giving me an empty collection in the deployed
executable, so it did nothing when deployed.

Have a good one,

Bill

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

I'm using DebugTraceStrean together with DebugView from Sysinternals
(http://www.sysinternals.com/ntw2k/freeware/debugview.shtml) on a
regular basis for this. Especially if you are working with low level
I/O, socket or GUI stuff it helps alot. You don't need working I/O or
GUI (or you messed it up likt I dit ;.-) to output the debug messages here.

CU,

Udo



Christopher J. Demers wrote:

Christopher J. Demers wrote:
> To further that goal I developed a
> message logger.  It will write out each message with all arguments,
> and the result to a file.  I have it working wonderfully in the
> development environment.  However when I deploy it it stops working,
> no errors, but does not log the message sends.

The problem is that the generated wrapper methods are failing to compile.  If
you run your deployed .exe with the DebugView tool that Udo mentioned, then
you'll see a stream of error messages like:

    Error: _FramingConstraints>>leftFraming: at line 2: undeclared 'Processor'

That turns out to be because 'Processor' is a global and is removed from the
system table during stripping (see
ImageStripper>>stripSystemDictionaryNotifying:).  The easiest way around it is
probably just to add

    MitSciMessageLogger class>>activeProcess
         ^ Processor activeProcess

and generate calls to that instead of to Processor activeProcess.  I also (just
in case) put all the methods of MitSciMessageLogger into the 'must not strip'
category and added a "fake" method (also in that category) with the same text
as the generated methods to protect #topFrame, etc.  (May not have been
necessary, but it does no harm).  With those changes I was getting a complete
log in a deployed .exe (once I'd remembered about DolphinDR.DLL, anyway ;-).

> I am interested in two things.  First of all is my rather complex
> approach required to do what I want?

It sounds like it.  Your approach is rather like John Brant's "Method Wrappers"
of which there seems to be a port by Andres Otaduy at
http://www.smalltalking.net/Goodies/Dolphin/ (I haven't yet tried it out).

I did once try a similar thing using a nil subclass (and #become:) to create
logging wrappers around arbitrary objects.  The problem with that approach was
stopping references to the wrapped object leaking out, and it never worked very
well.

> Oh yeh, if anyone actually sees the dropped down combobox not
> displaying give me a holler.  I only know of one computer this
> happens on.

Just checking: on my machine the combo box has the "simple" style where the
list is always displayed (rather than actively dropping down), that is what you
intended ?

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:3f3231c7$0$45999$[hidden email]...
> The problem is that the generated wrapper methods are failing to compile.
If
> you run your deployed .exe with the DebugView tool that Udo mentioned,
then
> you'll see a stream of error messages like:
>
>     Error: _FramingConstraints>>leftFraming: at line 2: undeclared
'Processor'
>
> That turns out to be because 'Processor' is a global and is removed from
the
> system table during stripping (see

Thank you!  That turned out to be the problem, I implimented your suggested
workaround and I was able to get it to work.

> It sounds like it.  Your approach is rather like John Brant's "Method
Wrappers"
> of which there seems to be a port by Andres Otaduy at
> http://www.smalltalking.net/Goodies/Dolphin/ (I haven't yet tried it out).

I remember hearing something about that, I don't think I was aware of the
Dolphin port.  I might have been able to use it.  Since my code (with your
fix) does exactly what I need I think I am se for now at least.  I will look
into the method wrappers for future use though.

> I did once try a similar thing using a nil subclass (and #become:) to
create
> logging wrappers around arbitrary objects.  The problem with that approach
was
> stopping references to the wrapped object leaking out, and it never worked
very
> well.

I started out doing something a little like that, but I could not workout an
easy way to log self sends with my approach, which is what I really wanted
in this case.  I had some fun playing with the code.  As you can probably
tell from my remmed code I hadn't been properly thinking about making it
work in a deployed EXE (no source code in an EXE! ;) ).  After some
adjustments I got where it could theoretically work in an EXE, and after
your advice I now have it working.  Thanks.

 > > Oh yeh, if anyone actually sees the dropped down combobox not
> > displaying give me a holler.  I only know of one computer this
> > happens on.
>
> Just checking: on my machine the combo box has the "simple" style where
the
> list is always displayed (rather than actively dropping down), that is
what you
> intended ?

Yep it is supposed to be droppED (as opposed to drop) down (not sure if that
is the best terminology) simple style.  I have a client with one computer
that does not display the combo box at all, there is just blank space.  The
message logger is supposed to help me see why the LayoutManager is making it
go away (I think that is what is happening).

Once again, c.l.s.d to the rescue, thanks to everyone for the responses.

Chris