Strange packaging errors

[Richard Sargent]

CgImageFileFormat class>>#allFormats - Reference to excluded class #GbtPNGFileFormat
CgImageFileFormat class>>#allFormats - Reference (by name) to excluded class #GbtPNGFileFormat

The method in question?

allFormats
"Answer a collection containing all concrete CgImageFileFormat classes
 which are subclasses of the receiver."

^self allSubclasses

The first one is bad enough, but the second one is beyond belief.

[Marcus Wagner]

Courious. There seems to exist a special packager logic (!) dealing with adjustments of class references making use of this protocol. 

I never had heard about that before, so I have no idea about the underlying problem and the presented solution, where allFormats is called.

I hesitate here as I almost never used private classes and I did not ever package something containing private classes. 

Might be related to this.

However it matches my experiences about mixing "meta" information (like allFormats) with active (to be packaged) runtime code.

Can it be, that allFormats (intended to deliver metainformation) gets accidentially (somehow) in scope of to be packaged material?

It remembers me to (ancient) situations where references to development code were left accidentially in the to be packed code (like calls to inspect s.th.) causing the compiler environment to be included in the package which has to fail, as a contraction of the goal of packaging. 

[Louis LaBrunda]

Hi Guys,

I apologize for hijacking this thread (a little).  I want to put my 2 cents for options in the packager that are less aggressive at removing things.  Sure, certain stuff shouldn't get packaged and that's fine.  But the packager doesn't need to remove every last byte.  I have two programs that run on a Raspberry Pi.  It is a tiny little computer the size of a deck of playing cards.  You can get one with a power supply and a memory card for about $100.  The memory cards are plenty big enough to run a GUI version of Linux and my 11MB image and the maybe 50MB of other stuff needed to run a VA Smalltalk program.  It even runs the development environment.  A bit slow but it all fits, no problem.  If the packager ran faster but I ended up with a 20MB image, that would be fine with me.

My point isn't that the packager need to run faster on the Raspberry Pi, there aren't enough of us using it for that to matter.  My point is, memory is cheap but our time debugging oddball packager problems to save a few bytes of image size is not worth it.

Lou

[Richard Sargent]

I agree.

On Tue, Sep 23, 2025 at 9:32 AM Louis LaBrunda <loulab...@gmail.com> wrote:

Hi Guys,

I apologize for hijacking this thread (a little).  I want to put my 2 cents for options in the packager that are less aggressive at removing things.  Sure, certain stuff shouldn't get packaged and that's fine.  But the packager doesn't need to remove every last byte.  I have two programs that run on a Raspberry Pi.  It is a tiny little computer the size of a deck of playing cards.  You can get one with a power supply and a memory card for about $100.  The memory cards are plenty big enough to run a GUI version of Linux and my 11MB image and the maybe 50MB of other stuff needed to run a VA Smalltalk program.  It even runs the development environment.  A bit slow but it all fits, no problem.  If the packager ran faster but I ended up with a 20MB image, that would be fine with me.

My point isn't that the packager need to run faster on the Raspberry Pi, there aren't enough of us using it for that to matter.  My point is, memory is cheap but our time debugging oddball packager problems to save a few bytes of image size is not worth it.

Design choices made when we had 486 and Pentium processes and a few dozen megabytes of memory required aggressive tactics.

With computers O(2) faster than then and O(3) more memory, the forces are different.

Mind you, it is probably harder to dial back the aggression in an established product than one might think.

Lou

On Tuesday, September 23, 2025 at 11:46:21 AM UTC-4 Marcus Wagner wrote:

Courious. There seems to exist a special packager logic (!) dealing with adjustments of class references making use of this protocol. 

I never had heard about that before, so I have no idea about the underlying problem and the presented solution, where allFormats is called.

I hesitate here as I almost never used private classes and I did not ever package something containing private classes. 

Might be related to this.

However it matches my experiences about mixing "meta" information (like allFormats) with active (to be packaged) runtime code.

Can it be, that allFormats (intended to deliver metainformation) gets accidentially (somehow) in scope of to be packaged material?

It remembers me to (ancient) situations where references to development code were left accidentially in the to be packed code (like calls to inspect s.th.) causing the compiler environment to be included in the package which has to fail, as a contraction of the goal of packaging. 

Richard Sargent schrieb am Dienstag, 23. September 2025 um 03:49:15 UTC+2:

CgImageFileFormat class>>#allFormats - Reference to excluded class #GbtPNGFileFormat
CgImageFileFormat class>>#allFormats - Reference (by name) to excluded class #GbtPNGFileFormat

The method in question?

allFormats
"Answer a collection containing all concrete CgImageFileFormat classes
 which are subclasses of the receiver."

^self allSubclasses

The first one is bad enough, but the second one is beyond belief.

--
You received this message because you are subscribed to a topic in the Google Groups "VAST Community Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/B0YqzqCZn-w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/423a43cf-88de-4c39-9fc5-022429c1ae00n%40googlegroups.com.

[Richard Sargent]

See below.

On Tue, Sep 23, 2025 at 8:46 AM 'Marcus Wagner' via VAST Community Forum <va-sma...@googlegroups.com> wrote:

Courious. There seems to exist a special packager logic (!) dealing with adjustments of class references making use of this protocol. 

I never had heard about that before, so I have no idea about the underlying problem and the presented solution, where allFormats is called.

I hesitate here as I almost never used private classes and I did not ever package something containing private classes. 

Might be related to this.

I can't imaging how private vs public classes would actually be packaged differently.

However, the point about this method being included at all is valid and that is something I will investigate separately.

The fact remains that these errors are bogus. I admit the possibility that they are trying to point out something important or potentially so. But, if that's the case, the error message is way off base.

 

However it matches my experiences about mixing "meta" information (like allFormats) with active (to be packaged) runtime code.

Can it be, that allFormats (intended to deliver metainformation) gets accidentially (somehow) in scope of to be packaged material?

It remembers me to (ancient) situations where references to development code were left accidentially in the to be packed code (like calls to inspect s.th.) causing the compiler environment to be included in the package which has to fail, as a contraction of the goal of packaging. 

Richard Sargent schrieb am Dienstag, 23. September 2025 um 03:49:15 UTC+2:

CgImageFileFormat class>>#allFormats - Reference to excluded class #GbtPNGFileFormat
CgImageFileFormat class>>#allFormats - Reference (by name) to excluded class #GbtPNGFileFormat

The method in question?

allFormats
"Answer a collection containing all concrete CgImageFileFormat classes
 which are subclasses of the receiver."

^self allSubclasses

The first one is bad enough, but the second one is beyond belief.

--

You received this message because you are subscribed to a topic in the Google Groups "VAST Community Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/B0YqzqCZn-w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to va-smalltalk...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/6a044265-7f51-4b23-9df8-142752f377f2n%40googlegroups.com.

[Richard Sargent]

For diagnostic purposes, that was encountered in an 11.0.1 image.

I doubt the packager has seen significant changes between then and now.

--

You received this message because you are subscribed to a topic in the Google Groups "VAST Community Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/B0YqzqCZn-w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to va-smalltalk...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/7c841af7-2057-4be3-aeb1-b04ed91f4510n%40googlegroups.com.

[Richard Sargent]

On Tuesday, September 23, 2025 at 9:32:40 AM UTC-7 Louis LaBrunda wrote:

Hi Guys,

I apologize for hijacking this thread (a little).  I want to put my 2 cents for options in the packager that are less aggressive at removing things.  Sure, certain stuff shouldn't get packaged and that's fine.  But the packager doesn't need to remove every last byte.  I have two programs that run on a Raspberry Pi.  It is a tiny little computer the size of a deck of playing cards.  You can get one with a power supply and a memory card for about $100.  The memory cards are plenty big enough to run a GUI version of Linux and my 11MB image and the maybe 50MB of other stuff needed to run a VA Smalltalk program.  It even runs the development environment.  A bit slow but it all fits, no problem.  If the packager ran faster but I ended up with a 20MB image, that would be fine with me.

My point isn't that the packager need to run faster on the Raspberry Pi, there aren't enough of us using it for that to matter.  My point is, memory is cheap but our time debugging oddball packager problems to save a few bytes of image size is not worth it.

I think there is a defect in CgImageSupport class>>#epClassReferenceAdjustmentsFor:in:.
It uses CgFileFormat subclasses collect: [:aClass | aClass name] to get the subclasses, even those that shouldn't be packaged. And later it gets the AllSubclasses of these abstract subclasses, regardless of whether they should be packaged.