Lagoon problem

Andy/Blair,
Here's one of those structure deployment problems that I know you like <g>

Below is a simple package, one Shell subclass with one method,
aSessionManager subclass for deployment  and a modified
BITMAPINFO>>bmiColors: method. The main thing to notice are the four trace
statements, two in #onViewOpened and two in #bmiColors:

1) Run if from the development image. It works as expected and all four
traces display on the Transcript.

2) Deploy it with the default deployment settings. When the app is run the
two trace statements in the #onViewOpened show but the other traces do not.
No error is raised - the #bmiColors: method is just never evaluated.

3) Turn off any one of the "Strip redundant methods", "Strip redundant
classes" or "Fully compile external structures" options and Lagoon crashes
out with a non-continuable exception

4) Turn off the "Strip redundant packages" and the "Fully compile external
structures" options. Lagoon completes without error and the app works as
expected, all four traces appearing.

I should mention that finding (2) in the depths of a deployed executable
that just refused to work, without any indication why, was not fun!!

Ian
(reposted because of ISP problem)

-~-~-~-~-~-~ Cut and paste the rest for package test.pac

| package |
package := Package name: 'Test'.
package paxVersion: 0;
 basicComment: ''.

package basicPackageVersion: ''.

"Image stripper bytes"
package imageStripperBytes: #[33 83 84 66 32 48 32 70 15 13 0 3 0 0 0 73 109
97 103 101 83 116 114 105 112 112 101 114 0 0 0 0 0 0 0 0 54 0 6 0 83 116
114 105 110 103 4 0 0 0 84 101 115 116 114 0 0 0 8 0 0 0 116 101 115 116 46
101 120 101 78 2 13 0 1 0 0 0 83 84 66 67 108 97 115 115 80 114 111 120 121
0 0 0 0 128 0 0 0 114 0 0 0 6 0 0 0 84 101 115 116 83 77 239 191 5 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ].
"Add the package scripts"

"Add the class names, loose method names, global names, resource names"
package classNames
 add: #Test;
 add: #TestSM;
 yourself.

package methodNames
 add: #BITMAPINFO -> #bmiColors:;
 yourself.

package globalNames
 yourself.

package resourceNames
 yourself.

"Binary Global Names"
package binaryGlobalNames: (Set new
 yourself).
"Resource Names"
package allResourceNames: (Set new
 add: #Test -> 'Default view';
 yourself).

"Add the prerequisite names"
package setPrerequisites: (IdentitySet new
 add: 'Dolphin';
 yourself).

package!

"Class Definitions"!

Shell subclass: #Test
 instanceVariableNames: ''
 classVariableNames: ''
 poolDictionaries: ''
 classInstanceVariableNames: ''!
RuntimeSessionManager subclass: #TestSM
 instanceVariableNames: ''
 classVariableNames: ''
 poolDictionaries: ''
 classInstanceVariableNames: ''!
"Loose Methods"!

!BITMAPINFO methodsFor!

bmiColors: anObject
 "Set the receiver's bmiColors field to the value of anObject."

 | size |
 SessionManager current trace: 'Inside In'.
 size := anObject size min: (self numQuads * 4).
 anObject replaceBytesOf: bytes from: 41 to: 40 + size startingAt: 1.
 SessionManager current trace: 'Inside Out'.
! !
!BITMAPINFO categoriesFor: #bmiColors:!**compiled accessors**!public! !

"End of package definition"!



Test comment: ''!

Test guid: (GUID fromString: '{CB07A04F-28FE-47BB-A646-FD81C627F364}')!

!Test categoriesForClass!Unclassified! !
!Test methodsFor!

onViewOpened
 | bmi colorTable |
 super onViewOpened.

 bmi := BITMAPINFO colorDepth: 1.
 colorTable := (StructureArray length: 2 elementClass: RGBQUAD)
  at: 1 put: (RGBQUAD new rgbRed: 0; rgbBlue: 0; rgbGreen: 0);
  at: 2 put: (RGBQUAD new rgbRed: 255; rgbBlue: 255; rgbGreen: 255);
  yourself.
 SessionManager current trace: 'Before'.
 bmi bmiColors: colorTable.
 SessionManager current trace: 'After'.



 ! !
!Test categoriesFor: #onViewOpened!*-unclassified!public! !



TestSM comment: ''!

TestSM guid: (GUID fromString: '{B539F0CC-8B50-41ED-94A7-909C0997A22C}')!

!TestSM categoriesForClass!Unclassified! !
!TestSM methodsFor!

main
 Test show! !
!TestSM categoriesFor: #main!*-unclassified!public! !


"Binary Globals"!

"Resources"!

(ResourceIdentifier class: Test name: 'Default view') assign: (Object
fromBinaryStoreBytes:
#[33 83 84 66 32 48 32 70 2 12 0 1 0 0 0 86 105 101 119 82 101 115 111 117
114 99 101 0 0 0 0 14 1 36 0 83 84 66 82 101 115 111 117 114 99 101 83 84 66
66 121 116 101 65 114 114 97 121 65 99 99 101 115 115 111 114 80 114 111 120
121 0 0 0 0 54 0 9 0 66 121 116 101 65 114 114 97 121 159 2 0 0 33 83 84 66
32 48 32 78 8 12 0 10 0 0 0 83 84 66 86 105 101 119 80 114 111 120 121 0 0 0
0 78 2 13 0 1 0 0 0 83 84 66 67 108 97 115 115 80 114 111 120 121 0 0 0 0 54
0 6 0 83 116 114 105 110 103 7 0 0 0 68 111 108 112 104 105 110 146 0 0 0 9
0 0 0 83 104 101 108 108 86 105 101 119 38 0 5 0 65 114 114 97 121 24 0 0 0
0 0 0 0 0 0 0 0 194 0 0 0 2 0 0 0 1 0 158 1 1 0 2 0 96 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 7 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 14 2 26 0 83 84 66
73 100 101 110 116 105 116 121 68 105 99 116 105 111 110 97 114 121 80 114
111 120 121 0 0 0 0 122 0 0 0 0 0 0 0 160 0 0 0 146 0 0 0 18 0 0 0 73 100
101 110 116 105 116 121 68 105 99 116 105 111 110 97 114 121 194 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 6 1 15 0 77 101 115 115 97 103 101 83 101 113 117 101 110 99 101 0 0 0
0 14 2 18 0 83 84 66 67 111 108 108 101 99 116 105 111 110 80 114 111 120
121 0 0 0 0 122 0 0 0 0 0 0 0 160 0 0 0 146 0 0 0 17 0 0 0 79 114 100 101
114 101 100 67 111 108 108 101 99 116 105 111 110 194 0 0 0 2 0 0 0 6 3 11 0
77 101 115 115 97 103 101 83 101 110 100 0 0 0 0 14 1 14 0 83 84 66 83 121
109 98 111 108 80 114 111 120 121 0 0 0 0 146 0 0 0 16 0 0 0 99 114 101 97
116 101 65 116 58 101 120 116 101 110 116 58 194 0 0 0 2 0 0 0 6 2 5 0 80
111 105 110 116 0 0 0 0 11 0 0 0 11 0 0 0 18 2 0 0 0 0 0 0 165 4 0 0 199 1 0
0 96 0 0 0 178 1 0 0 0 0 0 0 218 1 0 0 0 0 0 0 146 0 0 0 8 0 0 0 109 101 110
117 66 97 114 58 194 0 0 0 1 0 0 0 0 0 0 0 96 0 0 0 6 1 15 0 87 73 78 68 79
87 80 76 65 67 69 77 69 78 84 0 0 0 0 54 0 9 0 66 121 116 101 65 114 114 97
121 44 0 0 0 44 0 0 0 0 0 0 0 0 0 0 0 255 255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 5 0 0 0 5 0 0 0 87 2 0 0 232 0 0 0 106 1 0 0 0 0
0 0 128 1 0 0 48 1 0 0 18 2 0 0 0 0 0 0 193 0 0 0 193 0 0 0 0 0 0 0 19 0 0 0
70 5 4 0 3 0 0 0 73 99 111 110 0 0 0 0 0 0 0 0 16 0 0 0 14 2 17 0 83 84 66
83 105 110 103 108 101 116 111 110 80 114 111 120 121 0 0 0 0 78 2 13 0 1 0
0 0 83 84 66 67 108 97 115 115 80 114 111 120 121 0 0 0 0 54 0 6 0 83 116
114 105 110 103 7 0 0 0 68 111 108 112 104 105 110 18 1 0 0 24 0 0 0 73 109
97 103 101 82 101 108 97 116 105 118 101 70 105 108 101 76 111 99 97 116 111
114 14 1 14 0 83 84 66 83 121 109 98 111 108 80 114 111 120 121 0 0 0 0 18 1
0 0 7 0 0 0 99 117 114 114 101 110 116 18 1 0 0 13 0 0 0 83 104 101 108 108
86 105 101 119 46 105 99 111 14 2 31 0 83 84 66 69 120 116 101 114 110 97
108 82 101 115 111 117 114 99 101 76 105 98 114 97 114 121 80 114 111 120
121 0 0 0 0 18 1 0 0 16 0 0 0 100 111 108 112 104 105 110 100 114 48 48 52
46 100 108 108 0 0 0 0])!

Ian,

> 4) Turn off the "Strip redundant packages" and the "Fully compile external
> structures" options. Lagoon completes without error and the app works as
> expected, all four traces appearing.

Thanks for posting this.  Probably related, I have a deployed app that
failed on bitmap creation (I got a black rectangle where a document should
have been).  I tried your formula (left in the packages and didn't compile
definitions) and suddenly the bitmap code started to work.  FWIW, I generate
the bitmaps using your DIBitmap class, which I've maintained separately
because it is so useful.  Interestingly, another app that makes heavy use of
bitmaps (draws the same stuff in fact, just for display on screen and the
printer rather than to bitmaps in files), is aggressively stripped and seems
to work fine.

Have a good one,

Bill

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

Ian,

> > 4) Turn off the "Strip redundant packages" and the "Fully compile
external
> > structures" options. Lagoon completes without error and the app works as
> > expected, all four traces appearing.
>
> Thanks for posting this.  Probably related, I have a deployed app that
> failed on bitmap creation (I got a black rectangle where a document should
> have been).  I tried your formula (left in the packages and didn't compile
> definitions) and suddenly the bitmap code started to work.  FWIW, I
generate
> the bitmaps using your DIBitmap class, which I've maintained separately
> because it is so useful.  Interestingly, another app that makes heavy use
of
> bitmaps (draws the same stuff in fact, just for display on screen and the
> printer rather than to bitmaps in files), is aggressively stripped and
seems
> to work fine.

After a little more trial and error, I have been able to remove redundant
packages.  Turning off compiling external structures appears to be
necessary, and in that configuration (remove packages, don't compile
structs), Lagoon crashes with an "empty" crash dump.  It got into trouble
when trying to remove the class builder; leaving the builder in place
appears to give me a working app.

Have a good one,

Bill

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

Bill,

> Thanks for posting this.  Probably related, I have a deployed app that
> failed on bitmap creation (I got a black rectangle where a document should
> have been).  I tried your formula (left in the packages and didn't compile
> definitions) and suddenly the bitmap code started to work.

Yes, that is the symptom. The #bmiColors: method sets the colorTable for the
bitmap, an array of RGB values, but as the method is not being called the
entire table is left at 0's which makes every colour appear black.

>      FWIW, I generate
> the bitmaps using your DIBitmap class, which I've maintained separately
> because it is so useful.

I've got a tidied up version of the DIBitmap class, now called by it's
proper name of DeviceIndependentBitmap, ready to upload as a goodie(ette) in
it's own right. I just need to write the documentation - wanna copy?

>         Interestingly, another app that makes heavy use of
> bitmaps (draws the same stuff in fact, just for display on screen and the
> printer rather than to bitmaps in files), is aggressively stripped and
seems
> to work fine.

That's quite likely. The problem only occurs when you need to populate the
BITMAPINFO structure and then do something that needs the colour information
from the table.

Ian

Ian,

> Yes, that is the symptom. The #bmiColors: method sets the colorTable for
the
> bitmap, an array of RGB values, but as the method is not being called the
> entire table is left at 0's which makes every colour appear black.

That makes a lot of sense - thanks for working through it!


> >      FWIW, I generate
> > the bitmaps using your DIBitmap class, which I've maintained separately
> > because it is so useful.
>
> I've got a tidied up version of the DIBitmap class, now called by it's
> proper name of DeviceIndependentBitmap, ready to upload as a goodie(ette)
in
> it's own right. I just need to write the documentation - wanna copy?

Absolutely.  I'll gladly take a beta copy, or if you'd rather polish it
first, that's ok too.


> >         Interestingly, another app that makes heavy use of
> > bitmaps (draws the same stuff in fact, just for display on screen and
the
> > printer rather than to bitmaps in files), is aggressively stripped and
> seems
> > to work fine.
>
> That's quite likely. The problem only occurs when you need to populate the
> BITMAPINFO structure and then do something that needs the colour
information
> from the table.

Just a hunch (and probably wrong) but, this brings to mind the
StructureArray changes and #owner instance variable.  It makes me wonder if
we're having problems with an array be gc'd out from under us????  Probably
not, because nothing's crashing (due to bad pointers that would result) and
you have concluded (and I have no reason to doubt you) that the method isn't
being called.

Have a good one,

Bill

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

Ian

You wrote in message news:91odhv$7nk$[hidden email]...
>...
> Here's one of those structure deployment problems that I know you like <g>

I like them when I find the root cause as quickly as I did this time - just
because I've had a similar problem myself in the past though, not due to any
special talent.

You're bmiColors: method has been left in the special '** compiled accessors
**' category. This category is completely deleted when the structures are
recompiled ((I can hear you groaning already), hence it gets replaced by the
re-generated #bmiColors: method which does not contain any trace statements.
not.
> No error is raised - the #bmiColors: method is just never evaluated.

Now I note that the regenerated method is not the same as the one that has
been generated in the past (it has "numQuads * 0" instead of "numQuads * 4",
so obviously that is a problem - perhaps the one you were originally looking
into, since this would have prevent any data being assigned over for the
bitmap colours after the #bmiColors: method has been regenerated. This would
make it appear that bmiColors: was never being executed, and your subsequent
trace experiments would (falsely) have confirmed that suspicion.

To work around this bug (in the generation of the accessor method for
#bmiColors:, which seems to be the only example of a
VariableStructureArrayField that is writeable) I suggest removing the
existing implementation of #bmiColors: from the '**compiled accessors**'
category. Obviously this must have worked at some point, because that
existing method has been correctly generated. I can see why it isn't working
and will check our source code database to identify when and why we broke
it.

> 3) Turn off any one of the "Strip redundant methods", "Strip redundant
> classes" or "Fully compile external structures" options and Lagoon crashes
> out with a non-continuable exception

I'm not immediately sure why the deployment crashes in this step, that will
require further investigation.

> 4) Turn off the "Strip redundant packages" and the "Fully compile external
> structures" options. Lagoon completes without error and the app works as
> expected, all four traces appearing.

That would be consistent with the fact that your method is being overwritten
when recompiling external structures.

>
> I should mention that finding (2) in the depths of a deployed executable
> that just refused to work, without any indication why, was not fun!!

Indeed, sorry.

Regards

Blair

Blair,

> You're bmiColors: method has been left in the special '** compiled
accessors
> **' category. This category is completely deleted when the structures are
> recompiled ((I can hear you groaning already), hence it gets replaced by
the
> re-generated #bmiColors: method which does not contain any trace
statements.

Quite a big groan actually <g>. That ones going onto a bit of paper pinned
to the notice board.!!

> Now I note that the regenerated method is not the same as the one that has
> been generated in the past (it has "numQuads * 0" instead of "numQuads *
4",
> so obviously that is a problem - perhaps the one you were originally
looking
> into, since this would have prevent any data being assigned over for the
> bitmap colours after the #bmiColors: method has been regenerated.

That sounds like it. The color table never being copied over results in the
structure's table only containing the colour black (2, 16 or 256 times)
which is what I was seeing.

It's working quite happily after deploying with the options I mentioned
turned off so I'll probably leave it at that for the time being. Thanks for
the suggested fix though.

> > I should mention that finding (2) in the depths of a deployed executable
> > that just refused to work, without any indication why, was not fun!!
>
> Indeed, sorry.

Thanks but it wasn't really a winge at you though, just a little release of
tension as I felt that three lines in the report just didn't express the
_pain_ I'd just been through <g>

Ian