Weird package issues

Ok, I've just been beating my head back and forth against this for a few
hours and I'm starting to feel somewhat annoyed and lost.

I have an inprocess COM object in Package XXXX, which I have the bulk of
my application code, now I'm wanting to break this up a bit into
sub-packages, so I've created package YYYY and moved the COM object
class into the new package and altered to code so that theres no
circular references.

Because I'm ( currently ) still wanting to deploy package XXXX as the
DLL and include the class from YYYY I tell package XXXX to include YYYY
as a manual prerequesite - but for some reason the deployed DLL doesn't
seen to include my COM object ( as evidenced by outlook failing to
initialise the addin ).

I'm suspecting just adding package YYYY as a prereq isn't enough.



As an aside, if I deployed YYYY as the same named DLL, Outlook justs
spits the dummy with weird Index out of bounds errors, something
definitely strange happening there....

On Thu, 23 Sep 2004 15:48:35 +1200, Mark Derricutt <[hidden email]>  
wrote:

> Because I'm ( currently ) still wanting to deploy package XXXX as the  
> DLL and include the class from YYYY I tell package XXXX to include YYYY  
> as a manual prerequesite - but for some reason the deployed DLL doesn't  
> seen to include my COM object ( as evidenced by outlook failing to  
> initialise the addin ).
>
> I'm suspecting just adding package YYYY as a prereq isn't enough.

Did you check the deployment log (the .htm file) to see if the classes are  
retained (in)correctly?

--
Regards
HweeBoon
MotionObj

Yar Hwee Boon wrote:

> Did you check the deployment log (the .htm file) to see if the classes
> are  retained (in)correctly?

Looking at the log, the package is included, and the class is there.  It
just doesn't seem to run.

I've tried re-registering the dll via regsvr32 thinking maybe the new
package gave it a different signature or something, but no joy...

Mark Derricutt wrote:

> Looking at the log, the package is included, and the class is there.  
> It just doesn't seem to run.

Ok, package was there, class wasn't...

I was doing a 'hack' to include it my creating an instance to the temp
var in a method but that obviously is getting optimized out as I'm not
doing anything with it, so I tried adding an instance var and assigning
it there, no joy.

Lets try calling a method...

Nope.  Its just not including that class.... mmmmm.

On Thu, 23 Sep 2004 17:00:16 +1200, Mark Derricutt <[hidden email]>  
wrote:

> Ok, package was there, class wasn't...
>
> I was doing a 'hack' to include it my creating an instance to the temp  
> var in a method but that obviously is getting optimized out as I'm not  
> doing anything with it, so I tried adding an instance var and assigning  
> it there, no joy.

See if ImageStripper>>requiredClasses helps.

--
Regards
HweeBoon
MotionObj

Mark Derricutt wrote:

> Ok, package was there, class wasn't...

Are you:

    - referring to the class "normally"
    - from at least one method in XXXX that is not stripped

?

It sounds as if you may be referring to the class by an expression like:

    Smalltalk at: #MyClass

in order to avoid circular dependencies (or why else do you need to add YYY to
XXX's manual prerequisites ?). If so then the image stripper, which uses
essentially the same logic as the automatic prerequisite calculation, will
throw it out as unused.

If at least one method in XXX refers directly to YYY then YYY will be included
in XXX's automatic prerequisites.  If, further, that method is not itself
removed by the stripper, then the class should be left in the deployed DLL.

One way to force a reference, if none exists naturally, is to choose a method
that you know will not be stripped and just refer to the class by name from it.
Code like

    aMethod
            MyClass.    "dummy ref to prevent stripping"
            ... real code...

Or you can create a special method for that purpose alone and put it in the
'must not strip" category. (It still has to be defined against a class that is
not itself discarded, though).

Yet another way is to create a custom image stripper that "knows" that certain
classes should not be removed.  E.g. I like to use table-driven "parsing" of
complicated file formats, but that can mean that many necessary classes are
not referred to by any code at all, but only appear indirectly via entries in
the table; so I have a custom ImageStripper which overrides
#requiredClasses with code like:

    requiredClasses
         ^ (super requiredClasses)
              addAll: MyBaseClass withAllSubclasses;
              yourself.

Incidentally, for OA, this seems to be a problem that could use a generic
solution.  Would it be sensible to have a way of saying of some class "if this
class is included then include all its subclasses too", perhaps a 'must not
strip subclasses' category ?  Also, I had thought that there was a 'must not
strip' category for classes too, but I can't find a hint of it in the code.  Am
I missing something ?

    -- chris

Mark

(I'm replying to Chris, but this is mainly for Mark)

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
Chris is right. Including a package as a manual prerequisite is not
sufficient to ensure that any classes it contains will not be stripped IF
you have stripping of redundant classes enabled (the default). With an
Active-X server DLL it is quite likely that you may not any references to
the server class because instances of that server are created indirectly on
request from client. Effectively this amounts to a "symbolic" reference
using the GUID.

>...
> If at least one method in XXX refers directly to YYY then YYY will be
> included
> in XXX's automatic prerequisites.  If, further, that method is not itself
> removed by the stripper, then the class should be left in the deployed
> DLL.
>

Exactly.

Yes, this is the way to preserve a class that is not otherwise referenced -
it will also mean you don't need the manual prerequisite. Manual
prerequisites are only really useful for covering the case where there is a
dependency on a loose method in a package. The prerequisites mechanism is
not able to detect these dependencies - in fact it does not look at messages
at all. The image stripper, on the other hand, will preserve all
implementations of sent messages (that are in classes that are referenced),
but it can only do that for implementations that are not unloaded by the
uninstallation of non-prerequisite packages that occurs first.

The stripping of redundant (non-prerequisite) packages is a more gung ho
mechanism than the relatively conservative removal of unreferenced classes
and methods. That's why it is there. Earlier versions of our deployment
mechanism relied entirely on the conservative mechanism, and were much less
effective. If you turn off the stripping of redundant packages in the
deployment wizard, you'll see what I mean. In fact if you just strip
redundant packages, and not classes and methods, you may find that the
resulting executables are not much larger (although this is more the case in
Dolphin 6 because we have been working hard to break down the large base
packages into smaller pieces).

In order for the stripping of redundant packages to be correct, it is
necessary that the prerequisites be correct. If the automatic prerequisites
are not correct (which is relatively rare) then the stripping process will
generate incorrect results. However, since this also means the package will
not load or (more probably) run correctly, this should be discovered during
the development process.

In your particular case you have successfully used a manual prerequisite to
workaround an undetected class dependency, but then been foiled by the
"conservative" redundant class and method stripping throwing it out because
it is considered unreferenced. The best solution in this case is to create
an artificial reference. This will also mean that your package dependencies
are correct.

No, we could certainly add a 'Must not strip' class category to complement
the 'must not strip' method category. My preferred solution in these cases
at present is to ensure that the method which initialises the table has hard
references to the classes, and is not stripped itself. Class initialisation
methods are often in 'must not strip' for this reason e.g. VARIANT
class>>initializeVTClasses. Note that #initialize methods won't get stripped
anyway, unless placed in 'development' or 'must strip' categories, because
of sends of #initialize from core classes. Of course this requires
enumerating the classes explicitly, so is not ideal where you want to build
the table using reflection.

Regards

Blair

Blair McGlashan wrote:

>Mark
>
>(I'm replying to Chris, but this is mainly for Mark)
>  
>
Weird - last post doesn't seem to have been, er, posted.

I went back to the base level, deployed my other package but told it NOT
to strip anything, and it works, strip packages/classes and I get my odd
Out of bounds error ( attached ).

Hmmmm, something I need to force to include, god only knows what thou.


************************** Dolphin Virtual Machine Dump Report ***************************

10:52:42 AM, 9/24/2004: Index 8 is out of bounds

*----> VM Context <----*
Process: {07C40004:size 168 words, suspended frame 07C40169, priority 5, callbacks 1
last failure 1:nil, FPE mask 3, thread nil}
Active Method: SessionManager>>logError:
IP: 07AC3BCD (13)
SP: 07C40350
BP: 07C40328 (185)
ActiveFrame: {07C4032C: cf 07C40311, sp 07C40340, bp 07C40328, ip 5, GUIAXDllSessionManager(SessionManager)>>logError:}
        receiver: a GUIAXDllSessionManager
        arg[0]: a BoundsError


New Method: VMLibrary>>dump:path:stackDepth:walkbackDepth:
Message Selector: #dump:path:stackDepth:walkbackDepth:

*----> Stack Back Trace <----*
{07C4032C: cf 07C40311, sp 07C40340, bp 07C40328, ip 5, GUIAXDllSessionManager(SessionManager)>>logError:}
        receiver: a GUIAXDllSessionManager
        arg[0]: a BoundsError

{07C40310: cf 07C402F5, sp 07C40320, bp 07C4030C, ip 4, GUIAXDllSessionManager(SessionManager)>>unhandledException:}
        receiver: a GUIAXDllSessionManager
        arg[0]: a BoundsError

{07C402F4: cf 07C402D9, sp 07C40304, bp 07C402F0, ip 4, GUIAXDllSessionManager(SessionManager)>>onUnhandledError:}
        receiver: a GUIAXDllSessionManager
        arg[0]: a BoundsError

{07C402D8: cf 07C402C1, sp 07C402E8, bp 07C402D8, ip 5, BoundsError(Error)>>defaultAction}
        receiver: a BoundsError

{07C402C0: cf 07C402AD, sp 07C402D0, bp 07C00010, ip 57, BoundsError(Exception)>>_propagateFrom:}
        receiver: a BoundsError
        arg[0]: a ExceptionHandler
        temp[0]: nil
        temp[1]: a ExceptionHandler
        temp[2]: nil
        temp[3]: a Process('Main' base 07C40000 [ACTIVE] in SessionManager>>logError: sp=00000000 ip=8 list=nil)
        temp[4]: nil

{07C402AC: cf 07C40291, sp 07C402BC, bp 07C402A8, ip 6, BoundsError(Exception)>>_propagate}
        receiver: a BoundsError
        temp[0]: nil

{07C40290: cf 07C40279, sp 07C402A0, bp 07C40290, ip 12, BoundsError(Exception)>>signal}
        receiver: a BoundsError

{07C40278: cf 07C40259, sp 07C40288, bp 07C40270, ip 11, BoundsError(Exception)>>signal:with:}
        receiver: a BoundsError
        arg[0]: nil
        arg[1]: 8

{07C40258: cf 07C4023D, sp 07C40268, bp 07C40254, ip 5, BoundsError(Exception)>>signalWith:}
        receiver: a BoundsError
        arg[0]: 8

{07C4023C: cf 07C40221, sp 07C4024C, bp 07C40238, ip 9, Array(Object)>>errorSubscriptBounds:}
        receiver: a Array
        arg[0]: 8

{07C40220: cf 07C40205, sp 07C40230, bp 07C4021C, ip 11, Array(Object)>>errorAt:}
        receiver: a Array
        arg[0]: 8

{07C40204: cf 07C401E9, sp 07C40214, bp 07C40200, ip 4, Array(Object)>>basicAt:}
        receiver: a Array
        arg[0]: 8

{07C401E8: cf 07C401C5, sp 07C401F8, bp 07C401DC, ip 6, AddInDesignerObjects_IDTExtensibility2(COMInterface)>>callback:vfn:withArgumentsAt:}
        receiver: a AddInDesignerObjects_IDTExtensibility2
        arg[0]: a COMObjectStub
        arg[1]: 8
        arg[2]: 25556288

{07C401C4: cf 07C401A1, sp 07C401D4, bp 07C401B8, ip 9, COMObjectStub>>callback:vfn:withArgumentsAt:}
        receiver: a COMObjectStub
        arg[0]: 1
        arg[1]: 8
        arg[2]: 25556288

{07C401A0: cf 07C40185, sp 07C401B0, bp 07C00240, ip 15, [] in ProcessorScheduler>>comCallback:id:subId:withArgumentsAt:cookie:}
        receiver: a ProcessorScheduler
        arg[0]: 8
        arg[1]: 3
        arg[2]: 1
        arg[3]: 25556288
        arg[4]: 12778020

{07C40184: cf 07C40169, sp 07C4019C, bp 07C001D0, ip 17, BlockClosure>>ifCurtailed:}
        receiver: [] @ 13369350 in nil
        arg[0]: [] @ 20 in ProcessorScheduler>>comCallback:id:subId:withArgumentsAt:cookie:
        temp[0]: nil
        temp[1]: nil
        temp[2]: nil

{07C40168: cf 07C4014D, sp 07C40180, bp 07C00240, ip 25, ProcessorScheduler>>comCallback:id:subId:withArgumentsAt:cookie:}
        receiver: a ProcessorScheduler
        arg[0]: 8
        arg[1]: 3
        arg[2]: 1
        arg[3]: 25556288
        arg[4]: 12778020

{07C4014C: cf 07C40131, sp 07C40164, bp 07C40148, ip 32, InputState>>pumpMessage:}
        receiver: a InputState
        arg[0]: a MSG

{07C40130: cf 07C40109, sp 07C40140, bp 07C40120, ip 22, InputState>>loopWhile:}
        receiver: a InputState
        arg[0]: [] @ 6 in InputState>>mainLoop
        temp[0]: a MSG
        temp[1]: true
        temp[2]: [] @ 5 in SessionManager>>forkMain

{07C40108: cf 07C400F5, sp 07C40118, bp 07C002B0, ip 12, InputState>>mainLoop}
        receiver: a InputState

{07C400F4: cf 07C400E1, sp 07C40104, bp 07C000B8, ip 13, [] in InputState>>forkMain}
        receiver: a InputState

{07C400E0: cf 07C400CD, sp 07C400F0, bp 07C00278, ip 11, ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry}
        receiver: a ExceptionHandler
        temp[0]: nil

{07C400CC: cf 07C400B1, sp 07C400DC, bp 07C00198, ip 21, [] in ExceptionHandler(ExceptionHandlerAbstract)>>try:}
        receiver: a ExceptionHandler
        arg[0]: [] @ 8 in InputState>>forkMain
        temp[0]: nil
        temp[1]: nil
        temp[2]: a Process('Main' base 07C40000 [ACTIVE] in SessionManager>>logError: sp=00000000 ip=8 list=nil)

{07C400B0: cf 07C4009D, sp 07C400C8, bp 07C00208, ip 17, BlockClosure>>ifCurtailed:}
        receiver: [] @ 13369350 in nil
        arg[0]: [] @ 34 in ExceptionHandlerAbstract>>try:
        temp[0]: nil
        temp[1]: nil
        temp[2]: nil

{07C4009C: cf 07C4007D, sp 07C400AC, bp 07C40094, ip 4, BlockClosure>>ensure:}
        receiver: [] @ 15 in ExceptionHandlerAbstract>>try:
        arg[0]: [] @ 34 in ExceptionHandlerAbstract>>try:
        temp[0]: nil

{07C4007C: cf 07C40069, sp 07C4008C, bp 07C00198, ip 39, ExceptionHandler(ExceptionHandlerAbstract)>>try:}
        receiver: a ExceptionHandler
        arg[0]: [] @ 8 in InputState>>forkMain
        temp[0]: nil
        temp[1]: nil
        temp[2]: a Process('Main' base 07C40000 [ACTIVE] in SessionManager>>logError: sp=00000000 ip=8 list=nil)

{07C40068: cf 07C40049, sp 07C40078, bp 07C40060, ip 7, BlockClosure>>on:do:}
        receiver: [] @ 8 in InputState>>forkMain
        arg[0]: ProcessTermination
        arg[1]: [] @ 12 in BlockClosure>>newProcess

{07C40048: cf 00000001, sp 07C40058, bp 07C000F0, ip 17, [] in BlockClosure>>newProcess}
        receiver: [] @ 8 in InputState>>forkMain
        temp[0]: nil

<Bottom of stack>

***** End of dump *****


************************** Dolphin Virtual Machine Dump Report ***************************

11:01:44 AM, 9/24/2004: Index 8 is out of bounds

*----> VM Context <----*
Process: {07E50004:size 168 words, suspended frame 07E50169, priority 5, callbacks 1
last failure 1:nil, FPE mask 3, thread nil}
Active Method: SessionManager>>logError:
IP: 07B6A80D (13)
SP: 07E50350
BP: 07E50328 (185)
ActiveFrame: {07E5032C: cf 07E50311, sp 07E50340, bp 07E50328, ip 5, GUIAXDllSessionManager(SessionManager)>>logError:}
        receiver: a GUIAXDllSessionManager
        arg[0]: a BoundsError


New Method: VMLibrary>>dump:path:stackDepth:walkbackDepth:
Message Selector: #dump:path:stackDepth:walkbackDepth:

*----> Stack Back Trace <----*
{07E5032C: cf 07E50311, sp 07E50340, bp 07E50328, ip 5, GUIAXDllSessionManager(SessionManager)>>logError:}
        receiver: a GUIAXDllSessionManager
        arg[0]: a BoundsError

{07E50310: cf 07E502F5, sp 07E50320, bp 07E5030C, ip 4, GUIAXDllSessionManager(SessionManager)>>unhandledException:}
        receiver: a GUIAXDllSessionManager
        arg[0]: a BoundsError

{07E502F4: cf 07E502D9, sp 07E50304, bp 07E502F0, ip 4, GUIAXDllSessionManager(SessionManager)>>onUnhandledError:}
        receiver: a GUIAXDllSessionManager
        arg[0]: a BoundsError

{07E502D8: cf 07E502C1, sp 07E502E8, bp 07E502D8, ip 5, BoundsError(Error)>>defaultAction}
        receiver: a BoundsError

{07E502C0: cf 07E502AD, sp 07E502D0, bp 07DAC2E8, ip 57, BoundsError(Exception)>>_propagateFrom:}
        receiver: a BoundsError
        arg[0]: a ExceptionHandler
        temp[0]: nil
        temp[1]: a ExceptionHandler
        temp[2]: nil
        temp[3]: a Process('Main' base 07E50000 [ACTIVE] in SessionManager>>logError: sp=00000000 ip=8 list=nil)
        temp[4]: nil

{07E502AC: cf 07E50291, sp 07E502BC, bp 07E502A8, ip 6, BoundsError(Exception)>>_propagate}
        receiver: a BoundsError
        temp[0]: nil

{07E50290: cf 07E50279, sp 07E502A0, bp 07E50290, ip 12, BoundsError(Exception)>>signal}
        receiver: a BoundsError

{07E50278: cf 07E50259, sp 07E50288, bp 07E50270, ip 11, BoundsError(Exception)>>signal:with:}
        receiver: a BoundsError
        arg[0]: nil
        arg[1]: 8

{07E50258: cf 07E5023D, sp 07E50268, bp 07E50254, ip 5, BoundsError(Exception)>>signalWith:}
        receiver: a BoundsError
        arg[0]: 8

{07E5023C: cf 07E50221, sp 07E5024C, bp 07E50238, ip 9, Array(Object)>>errorSubscriptBounds:}
        receiver: a Array
        arg[0]: 8

{07E50220: cf 07E50205, sp 07E50230, bp 07E5021C, ip 11, Array(Object)>>errorAt:}
        receiver: a Array
        arg[0]: 8

{07E50204: cf 07E501E9, sp 07E50214, bp 07E50200, ip 4, Array(Object)>>basicAt:}
        receiver: a Array
        arg[0]: 8

{07E501E8: cf 07E501C5, sp 07E501F8, bp 07E501DC, ip 6, AddInDesignerObjects_IDTExtensibility2(COMInterface)>>callback:vfn:withArgumentsAt:}
        receiver: a AddInDesignerObjects_IDTExtensibility2
        arg[0]: a COMObjectStub
        arg[1]: 8
        arg[2]: 26080576

{07E501C4: cf 07E501A1, sp 07E501D4, bp 07E501B8, ip 9, COMObjectStub>>callback:vfn:withArgumentsAt:}
        receiver: a COMObjectStub
        arg[0]: 1
        arg[1]: 8
        arg[2]: 26080576

{07E501A0: cf 07E50185, sp 07E501B0, bp 07DAC518, ip 15, [] in ProcessorScheduler>>comCallback:id:subId:withArgumentsAt:cookie:}
        receiver: a ProcessorScheduler
        arg[0]: 8
        arg[1]: 3
        arg[2]: 1
        arg[3]: 26080576
        arg[4]: 13040164

{07E50184: cf 07E50169, sp 07E5019C, bp 07DAC4E0, ip 17, BlockClosure>>ifCurtailed:}
        receiver: [] @ 13631494 in nil
        arg[0]: [] @ 20 in ProcessorScheduler>>comCallback:id:subId:withArgumentsAt:cookie:
        temp[0]: nil
        temp[1]: nil
        temp[2]: nil

{07E50168: cf 07E5014D, sp 07E50180, bp 07DAC518, ip 25, ProcessorScheduler>>comCallback:id:subId:withArgumentsAt:cookie:}
        receiver: a ProcessorScheduler
        arg[0]: 8
        arg[1]: 3
        arg[2]: 1
        arg[3]: 26080576
        arg[4]: 13040164

{07E5014C: cf 07E50131, sp 07E50164, bp 07E50148, ip 32, InputState>>pumpMessage:}
        receiver: a InputState
        arg[0]: a MSG

{07E50130: cf 07E50109, sp 07E50140, bp 07E50120, ip 22, InputState>>loopWhile:}
        receiver: a InputState
        arg[0]: [] @ 6 in InputState>>mainLoop
        temp[0]: a MSG
        temp[1]: true
        temp[2]: [] @ 5 in SessionManager>>forkMain

{07E50108: cf 07E500F5, sp 07E50118, bp 07DAC278, ip 12, InputState>>mainLoop}
        receiver: a InputState

{07E500F4: cf 07E500E1, sp 07E50104, bp 07DAC390, ip 13, [] in InputState>>forkMain}
        receiver: a InputState

{07E500E0: cf 07E500CD, sp 07E500F0, bp 07DAC550, ip 11, ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry}
        receiver: a ExceptionHandler
        temp[0]: nil

{07E500CC: cf 07E500B1, sp 07E500DC, bp 07DAC470, ip 21, [] in ExceptionHandler(ExceptionHandlerAbstract)>>try:}
        receiver: a ExceptionHandler
        arg[0]: [] @ 8 in InputState>>forkMain
        temp[0]: nil
        temp[1]: nil
        temp[2]: a Process('Main' base 07E50000 [ACTIVE] in SessionManager>>logError: sp=00000000 ip=8 list=nil)

{07E500B0: cf 07E5009D, sp 07E500C8, bp 07DAC4A8, ip 17, BlockClosure>>ifCurtailed:}
        receiver: [] @ 13631494 in nil
        arg[0]: [] @ 34 in ExceptionHandlerAbstract>>try:
        temp[0]: nil
        temp[1]: nil
        temp[2]: nil

{07E5009C: cf 07E5007D, sp 07E500AC, bp 07E50094, ip 4, BlockClosure>>ensure:}
        receiver: [] @ 15 in ExceptionHandlerAbstract>>try:
        arg[0]: [] @ 34 in ExceptionHandlerAbstract>>try:
        temp[0]: nil

{07E5007C: cf 07E50069, sp 07E5008C, bp 07DAC470, ip 39, ExceptionHandler(ExceptionHandlerAbstract)>>try:}
        receiver: a ExceptionHandler
        arg[0]: [] @ 8 in InputState>>forkMain
        temp[0]: nil
        temp[1]: nil
        temp[2]: a Process('Main' base 07E50000 [ACTIVE] in SessionManager>>logError: sp=00000000 ip=8 list=nil)

{07E50068: cf 07E50049, sp 07E50078, bp 07E50060, ip 7, BlockClosure>>on:do:}
        receiver: [] @ 8 in InputState>>forkMain
        arg[0]: ProcessTermination
        arg[1]: [] @ 12 in BlockClosure>>newProcess

{07E50048: cf 00000001, sp 07E50058, bp 07DAC3C8, ip 17, [] in BlockClosure>>newProcess}
        receiver: [] @ 8 in InputState>>forkMain
        temp[0]: nil

<Bottom of stack>

***** End of dump *****

Mark Derricutt wrote:

> > Weird - last post doesn't seem to have been, er, posted.

One thing to note is that comp.lang.smalltalk.dolphin is a /text/ group and
many NNTP servers will not propagate postings with attachments (even text
ones).


> >
> > ************************** Dolphin Virtual Machine Dump Report
> > ***************************
> >
> > 10:52:42 AM, 9/24/2004: Index 8 is out of bounds


BTW, thanks for posting this dump report.  It's the first chance I've had to
test my new "ghoul" tool reading a report in one locale that was produced in a
different one.  And, sure enough, that exposes a bug in it :-(

Anyway, I don't understand this COM stuff, but the problem seems to be that
your array of functions (held in the class instvar 'functions' of class
AddInDesignerObjects_IDTExtensibility2 -- inspect that class and you should see
it) is too small in the stripped version of your DLL.  It does not have an
eighth element, which is what COM is trying to find.  Why that should be is
beyond me ;-)

    -- chris

Chris Uppal wrote:

>One thing to note is that comp.lang.smalltalk.dolphin is a /text/ group and
>many NNTP servers will not propagate postings with attachments (even text
>ones).
>  
>
True - my bad.  It's easy to forget that.  Although I'd rather see files
-attached- rather than just pasted in as I have seen in the past with
"---cuthere---" markers.  Just seems kinda silly when we have this
feature called attachments for like, attaching things :p

>BTW, thanks for posting this dump report.  It's the first chance I've had to
>test my new "ghoul" tool reading a report in one locale that was produced in a
>different one.  And, sure enough, that exposes a bug in it :-(
>  
>
I've been playing with Ghoul as well after I saw you mention it the
other day - very nice, only two really minor niggles I have with it - a)
it doesn't use the font I've defined as my workspace font, and b) the
code you're looking at isn't editable/compilable - I remember seeing
this mentioned, but would just love to see the ability included.  Look
through the errors and go "doh" and edit it then and there...

>Anyway, I don't understand this COM stuff, but the problem seems to be that
>your array of functions (held in the class instvar 'functions' of class
>AddInDesignerObjects_IDTExtensibility2 -- inspect that class and you should see
>it) is too small in the stripped version of your DLL.  It does not have an
>eighth element, which is what COM is trying to find.  Why that should be is
>beyond me ;-)
>  
>
Er ok - I'll take a look at that.  Not sure what would be going on there
- that class is generated by Dolphin's ActiveX wizard tool.  Will take a
look at it thou...

Mark Derricutt wrote:

> I've been playing with Ghoul as well after I saw you mention it the
> other day - very nice, only two really minor niggles I have with it - a)
> it doesn't use the font I've defined as my workspace font.

Good idea, thank you.  I'll fix that in the next version.  Quick "hotfix"
appended (not attatched, alas ;-)


> b) the
> code you're looking at isn't editable/compilable - I remember seeing
> this mentioned, but would just love to see the ability included.  Look
> through the errors and go "doh" and edit it then and there...

I deliberately didn't make the code pane "live" because I thought (still think)
that it'd be too misleading.  What you /can/ do is double-click in the stack
list, and that should open a class browser on the target method.

    -- chris


===========================================
!GhoulStackFramePresenter methodsFor!

importWorkspaceSettings
 "private -- copy across the default settings from SmalltakWorkspace to
 our source text presenter (which doesn't pick them up by default because
 it's not a workspace)"

 | source |

 source := Smalltalk at: #SmalltalkWorkspace ifAbsent: [^ self].
 (self methodSourcePresenter view)
  backcolor: source defaultBackcolor;
  font: source actualFont;
  wordWrap: source wordWrap.! !
!GhoulStackFramePresenter categoriesFor:
#importWorkspaceSettings!helpers!private! !

!GhoulStackFramePresenter methodsFor!

onViewOpened
 "private -- called when our view is fully open"

 self importWorkspaceSettings.

 super onViewOpened.! !
!GhoulStackFramePresenter categoriesFor: #onViewOpened!event handling!private!
!

!GhoulStackFrame methodsFor!

methodIsCurrent
 "answer whether the method we correspond to is present in this image
 and has not been re-defined"

 | then |

 then := trace timestamp ifNil: [^ true "can't tell"].

 ^ self methodIsDefined and: [self methodTimestamp
      ifNil: [true "can't tell"]
      ifNotNil: [:current | current <= then]].! !
!GhoulStackFrame categoriesFor: #methodIsCurrent!public!testing! !

Mark Derricutt wrote:

Solved that issue just now - turns out somehow all the generated methods
for the AddInDesigner... classes were loose methods in my original
package, so when I deployed the new package, they were lost.  I think
some time ago when looking around the system I click on the "default
package" item which probably did it...

Arrg ;)  All that hair loss for loose methods...

Chris Uppal wrote:

>Good idea, thank you.  I'll fix that in the next version.  Quick "hotfix"
>appended (not attatched, alas ;-)
>  
>
Ug - Ghoul -really- doesn't seem to like opening a 7mb .ERRORS file :(  
Welcome to non-responsive dolphin land ;(

Mark Derricutt wrote:

> > Good idea, thank you.  I'll fix that in the next version.  Quick
> > "hotfix" appended (not attatched, alas ;-)
> >
> >
> Ug - Ghoul -really- doesn't seem to like opening a 7mb .ERRORS file :(
> Welcome to non-responsive dolphin land ;(

Please /DON'T/ email me the problem file ;-)

How in hell did you get a 7MB stack dump anyway ?  Even if the VM goes into an
infinite recursion before bombing out, it doesn't get anything like that large.
Or do you have one file with /lots/ of stack dumps in it ?

Testing a 2.6 MB file, containing two "blown stack" dumps, it loads the file in
< 3 seconds, which I consider quite good.  Is it possible that you are
loading something that isn't in crashdump or dump format (the two are almost
identical) ?  I make no assertions about what will happen if you do that.
(Indeed you can consider yourself lucky that I bothered to remove the, um,
feature that made it always go into an infinite loop in such circumstances ;-)
I originally didn't intend to, and only changed my mind at the last minute...)

BTW, if you want to open the file by hand (in an editor) the best tool I know
(oddly enough) for opening really large text files without long delays is M$
Word. (WordPad isn't too bad either).

    -- chris

On Thu, 30 Sep 2004 09:44:11 +0100, Chris Uppal  
<[hidden email]> wrote:

> BTW, if you want to open the file by hand (in an editor) the best tool I  
> know
> (oddly enough) for opening really large text files without long delays  
> is M$
> Word. (WordPad isn't too bad either).

Or UltraEdit, etc.

--
Regards
HweeBoon
MotionObj