Packaging problem

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi Lou,

sounds that the referenced class is not defined in an application being part of the chain of the prerequisites of all apps you have added to package instructions. It is saying "add .. to the list of application to package".

Packager will not add a class to the package if it is "out of scope", where the scope consists of all apps added to the list to package including the closure of all prerequite apps. Even using any kind of include directive will not help.

My advice: run Envy Q/A over your code and check all "out of prequisite chain" references.

This kind of error is even worse if the referenced missing item is not a class but a pool entry, silently breaking associtions in methods.

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi   Marcus ,

Thanks for the reply.  I apologize, I through the post together in a hurry and left out some pertinent information.  It is claiming that #OldObjectLoader is missing.  I have included the app it lives in.  I have also told the packager to include the class but it rejects that inclusion:

The following rules refer to the component but were disallowed by the rule policy:

(1)  include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

I have tried both of the solutions listed to no avail.

Lou

On Saturday, January 30, 2021 at 12:44:23 PM UTC-5 [hidden email] wrote:

Hi Lou,

sounds that the referenced class is not defined in an application being part of the chain of the prerequisites of all apps you have added to package instructions. It is saying "add .. to the list of application to package".

Packager will not add a class to the package if it is "out of scope", where the scope consists of all apps added to the list to package including the closure of all prerequite apps. Even using any kind of include directive will not help.

My advice: run Envy Q/A over your code and check all "out of prequisite chain" references.

This kind of error is even worse if the referenced missing item is not a class but a pool entry, silently breaking associtions in methods.

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi Lou,

and another idea: packager says "disallowed by the rule policy". I know about the opposite case, a rule to exclude s.th. is not allowed producing ICs, for example.

What reduction policy is in use?

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi Marcus, Hi Everybody,

Thanks for the help.

I was including the map that brought in all the Sst... stuff.  I dropped that in favor of including the individual apps.  I wanted to reduce the inclusion of things that may not have been needed like examples.  Side note to Instantiations: it would be nice if things like examples were in their own maps.  After defining my map with the apps needed, I ended up in the same place with the same error.

As for:

SstSwapperMarshaling class>>packagingRulesFor:

    aRuleCollector
        initializeToNilClassVariable: 'ClassOfOldLoader' inClassNamed: #ObjectLoader;    "$NON-NLS$"
                "Must be included to maintain possible marshalling well-known-classes encoding
                orderings"
        includeClassNamed: #SstLinearLookupTable

It is suspicious but it is setting the class variable to nil which would remove the need to include #OldObjectLoader.  My instruction to include the class should override that?  Also, with what I have loaded at the time of packaging, I can't find that rule.

I'm looking in the packaged image contents browser and everywhere else I can think of but can't find why packager does this:

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

I don't expect anyone to try but I think packaging any GUI program that included both #ObjectLoaded and "sstAsUrl fetch", would reproduce the problem.

Lou

On Sunday, January 31, 2021 at 6:17:58 AM UTC-5 [hidden email] wrote:

Hi Lou,

and another idea: packager says "disallowed by the rule policy". I know about the opposite case, a rule to exclude s.th. is not allowed producing ICs, for example.

What reduction policy is in use?

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi All,

This is solved, almost.  I thought about # OldObjectLoader and realized I don't need it.  So, I added a rule to set 'ClassOfOldLoader' to nil.

That got me past the packaging error.

Now I get a runtime error when calling "sstAsUrl fetch".  Probably something is missing.  I will let you know.

Lou

On Sunday, January 31, 2021 at 10:44:56 AM UTC-5 Louis LaBrunda wrote:

Hi Marcus, Hi Everybody,

Thanks for the help.

I was including the map that brought in all the Sst... stuff.  I dropped that in favor of including the individual apps.  I wanted to reduce the inclusion of things that may not have been needed like examples.  Side note to Instantiations: it would be nice if things like examples were in their own maps.  After defining my map with the apps needed, I ended up in the same place with the same error.

As for:

SstSwapperMarshaling class>>packagingRulesFor:

    aRuleCollector
        initializeToNilClassVariable: 'ClassOfOldLoader' inClassNamed: #ObjectLoader;    "$NON-NLS$"
                "Must be included to maintain possible marshalling well-known-classes encoding
                orderings"
        includeClassNamed: #SstLinearLookupTable

It is suspicious but it is setting the class variable to nil which would remove the need to include #OldObjectLoader.  My instruction to include the class should override that?  Also, with what I have loaded at the time of packaging, I can't find that rule.

I'm looking in the packaged image contents browser and everywhere else I can think of but can't find why packager does this:

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

I don't expect anyone to try but I think packaging any GUI program that included both #ObjectLoaded and "sstAsUrl fetch", would reproduce the problem.

Lou

On Sunday, January 31, 2021 at 6:17:58 AM UTC-5 [hidden email] wrote:

Hi Lou,

and another idea: packager says "disallowed by the rule policy". I know about the opposite case, a rule to exclude s.th. is not allowed producing ICs, for example.

What reduction policy is in use?

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi,

Now it seems the packager won't include #SstHttpUrl.  Even though I tell it to include the class and the app it lives in?

Lou

On Sunday, January 31, 2021 at 11:18:07 AM UTC-5 Louis LaBrunda wrote:

Hi All,

This is solved, almost.  I thought about # OldObjectLoader and realized I don't need it.  So, I added a rule to set 'ClassOfOldLoader' to nil.

That got me past the packaging error.

Now I get a runtime error when calling "sstAsUrl fetch".  Probably something is missing.  I will let you know.

Lou

On Sunday, January 31, 2021 at 10:44:56 AM UTC-5 Louis LaBrunda wrote:

Hi Marcus, Hi Everybody,

Thanks for the help.

I was including the map that brought in all the Sst... stuff.  I dropped that in favor of including the individual apps.  I wanted to reduce the inclusion of things that may not have been needed like examples.  Side note to Instantiations: it would be nice if things like examples were in their own maps.  After defining my map with the apps needed, I ended up in the same place with the same error.

As for:

SstSwapperMarshaling class>>packagingRulesFor:

    aRuleCollector
        initializeToNilClassVariable: 'ClassOfOldLoader' inClassNamed: #ObjectLoader;    "$NON-NLS$"
                "Must be included to maintain possible marshalling well-known-classes encoding
                orderings"
        includeClassNamed: #SstLinearLookupTable

It is suspicious but it is setting the class variable to nil which would remove the need to include #OldObjectLoader.  My instruction to include the class should override that?  Also, with what I have loaded at the time of packaging, I can't find that rule.

I'm looking in the packaged image contents browser and everywhere else I can think of but can't find why packager does this:

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

I don't expect anyone to try but I think packaging any GUI program that included both #ObjectLoaded and "sstAsUrl fetch", would reproduce the problem.

Lou

On Sunday, January 31, 2021 at 6:17:58 AM UTC-5 [hidden email] wrote:

Hi Lou,

and another idea: packager says "disallowed by the rule policy". I know about the opposite case, a rule to exclude s.th. is not allowed producing ICs, for example.

What reduction policy is in use?

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi Lou,

packaging Sst is very particular - it has serve and to support headless and windows service environments, to mention a few (that means XD images).

So I fear you will run into many problems if you are not extremely careful.

This may sound inconvenient for you, but try to load Sst using the feature load in a fresh image before your loading your app.

I assume a bunch of initialization stuff in Sst is done here - to support XD and headless images.

Simply loading config maps or selected applications won't do, neither in the delopment nor in an XD image.

Also do not attempt to execute anything in the image before packaging.

It might destroy the consistency if something is executed before packaging (in XD you cannot run anything in the image to be packaged).

Further do not assume that the Sst Image to be optimal in size - it is designed to provide you with a fully functional headless server framework.

Even if you using only portions of Sst like sockets, transport protocols and the like, this may cause to load much more than actually needed.

May be that this helps you to include SstHttpUrl.

Good luck

Marcus

[I once successfully created an XD as windows NT service with SST, Seaside, JSON and ODBC - but always headless].

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 17:52:38 UTC+1:

Hi,

Now it seems the packager won't include #SstHttpUrl.  Even though I tell it to include the class and the app it lives in?

Lou

On Sunday, January 31, 2021 at 11:18:07 AM UTC-5 Louis LaBrunda wrote:

Hi All,

This is solved, almost.  I thought about # OldObjectLoader and realized I don't need it.  So, I added a rule to set 'ClassOfOldLoader' to nil.

That got me past the packaging error.

Now I get a runtime error when calling "sstAsUrl fetch".  Probably something is missing.  I will let you know.

Lou

On Sunday, January 31, 2021 at 10:44:56 AM UTC-5 Louis LaBrunda wrote:

Hi Marcus, Hi Everybody,

Thanks for the help.

I was including the map that brought in all the Sst... stuff.  I dropped that in favor of including the individual apps.  I wanted to reduce the inclusion of things that may not have been needed like examples.  Side note to Instantiations: it would be nice if things like examples were in their own maps.  After defining my map with the apps needed, I ended up in the same place with the same error.

As for:

SstSwapperMarshaling class>>packagingRulesFor:

    aRuleCollector
        initializeToNilClassVariable: 'ClassOfOldLoader' inClassNamed: #ObjectLoader;    "$NON-NLS$"
                "Must be included to maintain possible marshalling well-known-classes encoding
                orderings"
        includeClassNamed: #SstLinearLookupTable

It is suspicious but it is setting the class variable to nil which would remove the need to include #OldObjectLoader.  My instruction to include the class should override that?  Also, with what I have loaded at the time of packaging, I can't find that rule.

I'm looking in the packaged image contents browser and everywhere else I can think of but can't find why packager does this:

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

I don't expect anyone to try but I think packaging any GUI program that included both #ObjectLoaded and "sstAsUrl fetch", would reproduce the problem.

Lou

On Sunday, January 31, 2021 at 6:17:58 AM UTC-5 [hidden email] wrote:

Hi Lou,

and another idea: packager says "disallowed by the rule policy". I know about the opposite case, a rule to exclude s.th. is not allowed producing ICs, for example.

What reduction policy is in use?

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi  Marcus ,

I tried loading the feature and then packaging, both via my automated means and the "Make Executable" button on the Organizer window.  The result is the same, somehow #SstHttpUrl doesn't get loaded even thou I list it as a class to be loaded.  The packaging says the app is selected.  #SstTcpCommunications is also a prerequisite.

I don't care about the size of the image, I just want everything that is needed to be present.

Lou

 

On Sunday, January 31, 2021 at 1:22:18 PM UTC-5 [hidden email] wrote:

Hi Lou,

packaging Sst is very particular - it has serve and to support headless and windows service environments, to mention a few (that means XD images).

So I fear you will run into many problems if you are not extremely careful.

This may sound inconvenient for you, but try to load Sst using the feature load in a fresh image before your loading your app.

I assume a bunch of initialization stuff in Sst is done here - to support XD and headless images.

Simply loading config maps or selected applications won't do, neither in the delopment nor in an XD image.

Also do not attempt to execute anything in the image before packaging.

It might destroy the consistency if something is executed before packaging (in XD you cannot run anything in the image to be packaged).

Further do not assume that the Sst Image to be optimal in size - it is designed to provide you with a fully functional headless server framework.

Even if you using only portions of Sst like sockets, transport protocols and the like, this may cause to load much more than actually needed.

May be that this helps you to include SstHttpUrl.

Good luck

Marcus

[I once successfully created an XD as windows NT service with SST, Seaside, JSON and ODBC - but always headless].

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 17:52:38 UTC+1:

Hi,

Now it seems the packager won't include #SstHttpUrl.  Even though I tell it to include the class and the app it lives in?

Lou

On Sunday, January 31, 2021 at 11:18:07 AM UTC-5 Louis LaBrunda wrote:

Hi All,

This is solved, almost.  I thought about # OldObjectLoader and realized I don't need it.  So, I added a rule to set 'ClassOfOldLoader' to nil.

That got me past the packaging error.

Now I get a runtime error when calling "sstAsUrl fetch".  Probably something is missing.  I will let you know.

Lou

On Sunday, January 31, 2021 at 10:44:56 AM UTC-5 Louis LaBrunda wrote:

Hi Marcus, Hi Everybody,

Thanks for the help.

I was including the map that brought in all the Sst... stuff.  I dropped that in favor of including the individual apps.  I wanted to reduce the inclusion of things that may not have been needed like examples.  Side note to Instantiations: it would be nice if things like examples were in their own maps.  After defining my map with the apps needed, I ended up in the same place with the same error.

As for:

SstSwapperMarshaling class>>packagingRulesFor:

    aRuleCollector
        initializeToNilClassVariable: 'ClassOfOldLoader' inClassNamed: #ObjectLoader;    "$NON-NLS$"
                "Must be included to maintain possible marshalling well-known-classes encoding
                orderings"
        includeClassNamed: #SstLinearLookupTable

It is suspicious but it is setting the class variable to nil which would remove the need to include #OldObjectLoader.  My instruction to include the class should override that?  Also, with what I have loaded at the time of packaging, I can't find that rule.

I'm looking in the packaged image contents browser and everywhere else I can think of but can't find why packager does this:

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

I don't expect anyone to try but I think packaging any GUI program that included both #ObjectLoaded and "sstAsUrl fetch", would reproduce the problem.

Lou

On Sunday, January 31, 2021 at 6:17:58 AM UTC-5 [hidden email] wrote:

Hi Lou,

and another idea: packager says "disallowed by the rule policy". I know about the opposite case, a rule to exclude s.th. is not allowed producing ICs, for example.

What reduction policy is in use?

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi Lou,

did you register SstHttpUrl in SstHttpCommunications via loading the feature "ST: Server Smalltalk (SST) - HTTP"?

(SstHttpCommunications contains this

The class named #SstHttpUrl will be included in the packaged image, because of an inferred rule (see below).

The following rules infer an effect on the component:

(1)     do not reduce #SstHttpCommunications
    [defined by SstHttpCommunications class>>#packagingRulesFor:]

I created a simply visual part with a method referencing (nonsense code, but nethertheless)

    OldObjectLoader new.
    ObjectLoader new.
    SstEndpoint new sstAsUrl fetch

run the  Make Executable and my image is ok!

-> SstTcpCommunications is NOT sufficient, SstHttpCommunications [or SstHttpsCommunications] is required...

Good luck!

Marcus

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 20:09:06 UTC+1:

Hi  Marcus ,

I tried loading the feature and then packaging, both via my automated means and the "Make Executable" button on the Organizer window.  The result is the same, somehow #SstHttpUrl doesn't get loaded even thou I list it as a class to be loaded.  The packaging says the app is selected.  #SstTcpCommunications is also a prerequisite.

I don't care about the size of the image, I just want everything that is needed to be present.

Lou

 

On Sunday, January 31, 2021 at 1:22:18 PM UTC-5 [hidden email] wrote:

Hi Lou,

packaging Sst is very particular - it has serve and to support headless and windows service environments, to mention a few (that means XD images).

So I fear you will run into many problems if you are not extremely careful.

This may sound inconvenient for you, but try to load Sst using the feature load in a fresh image before your loading your app.

I assume a bunch of initialization stuff in Sst is done here - to support XD and headless images.

Simply loading config maps or selected applications won't do, neither in the delopment nor in an XD image.

Also do not attempt to execute anything in the image before packaging.

It might destroy the consistency if something is executed before packaging (in XD you cannot run anything in the image to be packaged).

Further do not assume that the Sst Image to be optimal in size - it is designed to provide you with a fully functional headless server framework.

Even if you using only portions of Sst like sockets, transport protocols and the like, this may cause to load much more than actually needed.

May be that this helps you to include SstHttpUrl.

Good luck

Marcus

[I once successfully created an XD as windows NT service with SST, Seaside, JSON and ODBC - but always headless].

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 17:52:38 UTC+1:

Hi,

Now it seems the packager won't include #SstHttpUrl.  Even though I tell it to include the class and the app it lives in?

Lou

On Sunday, January 31, 2021 at 11:18:07 AM UTC-5 Louis LaBrunda wrote:

Hi All,

This is solved, almost.  I thought about # OldObjectLoader and realized I don't need it.  So, I added a rule to set 'ClassOfOldLoader' to nil.

That got me past the packaging error.

Now I get a runtime error when calling "sstAsUrl fetch".  Probably something is missing.  I will let you know.

Lou

On Sunday, January 31, 2021 at 10:44:56 AM UTC-5 Louis LaBrunda wrote:

Hi Marcus, Hi Everybody,

Thanks for the help.

I was including the map that brought in all the Sst... stuff.  I dropped that in favor of including the individual apps.  I wanted to reduce the inclusion of things that may not have been needed like examples.  Side note to Instantiations: it would be nice if things like examples were in their own maps.  After defining my map with the apps needed, I ended up in the same place with the same error.

As for:

SstSwapperMarshaling class>>packagingRulesFor:

    aRuleCollector
        initializeToNilClassVariable: 'ClassOfOldLoader' inClassNamed: #ObjectLoader;    "$NON-NLS$"
                "Must be included to maintain possible marshalling well-known-classes encoding
                orderings"
        includeClassNamed: #SstLinearLookupTable

It is suspicious but it is setting the class variable to nil which would remove the need to include #OldObjectLoader.  My instruction to include the class should override that?  Also, with what I have loaded at the time of packaging, I can't find that rule.

I'm looking in the packaged image contents browser and everywhere else I can think of but can't find why packager does this:

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

I don't expect anyone to try but I think packaging any GUI program that included both #ObjectLoaded and "sstAsUrl fetch", would reproduce the problem.

Lou

On Sunday, January 31, 2021 at 6:17:58 AM UTC-5 [hidden email] wrote:

Hi Lou,

and another idea: packager says "disallowed by the rule policy". I know about the opposite case, a rule to exclude s.th. is not allowed producing ICs, for example.

What reduction policy is in use?

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi Marcus,

Thanks for all the help.

Let me recap where things are at now and a little about how it got here.  I started out with loading the feature "ST: Server Smalltalk (SST) - HTTP" as the first of the required maps.  I am back to that.  When I first packaged there were complaints about missing classes, some were #Sst... stuff and one was #OldObjectLoader.  I seemingly solver the #Sst... stuff by rules that included the classes.  I finally solved the #OldObjectLoader with a rule that set 'ClassOfOldLoader' to nil.  I liked that as I don't need it anyway.  I don't care if it is included but since I don't need it, there is no reason to go crazy fighting the packager to force its inclusion.

Also, I start with an almost clean v9.2.2 image (maybe a few settings set).  I load my map for this application that loads my support apps, and the program app.  I then run something the cleans a few things up and make more setting changes.  At this point everything looks good and testing the program works great.

That brings us to the present.  When packaging I start with the image described about but without any testing.  With feature "ST: Server Smalltalk (SST) - HTTP" as the first of the required maps and a few #Sst... classes loaded by the rule: #packagerIncludeClassNames (#SstFileUrl #SstHttpUrl #SciSocketAddress #SstHttpClient - there are other non #Sst.. classes too).  I also include #SstTcpCommunications #SstHttpCommunications,  in the list of applications to load.  This seems to package without errors.  But when I run the program, it walkbacks because #SstHttpUrl is not loaded.  Looking in classes.es it shows: SstHttpUrl excluded [application not selected].  

#SstHttpUrl is in #SstHttpCommunications, I explicitly tell the packager to load both but it won't.

A little more history.  This is a Windows GUI program.  I also have a VA Smalltalk/Seaside Linux program that runs on a Raspberry Pi.  I do all the development work on windows, package on windows and copy the image to the Raspberry.  Not the easiest thing to do but it works.  I don't think I use #SstHttpUrl but I think Seaside does and I think it is included in the packaged image.

Lou

On Sunday, January 31, 2021 at 3:46:23 PM UTC-5 [hidden email] wrote:

Hi Lou,

did you register SstHttpUrl in SstHttpCommunications via loading the feature "ST: Server Smalltalk (SST) - HTTP"?

(SstHttpCommunications contains this

The class named #SstHttpUrl will be included in the packaged image, because of an inferred rule (see below).

The following rules infer an effect on the component:

(1)     do not reduce #SstHttpCommunications
    [defined by SstHttpCommunications class>>#packagingRulesFor:]

I created a simply visual part with a method referencing (nonsense code, but nethertheless)

    OldObjectLoader new.
    ObjectLoader new.
    SstEndpoint new sstAsUrl fetch

run the  Make Executable and my image is ok!

-> SstTcpCommunications is NOT sufficient, SstHttpCommunications [or SstHttpsCommunications] is required...

Good luck!

Marcus

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 20:09:06 UTC+1:

Hi  Marcus ,

I tried loading the feature and then packaging, both via my automated means and the "Make Executable" button on the Organizer window.  The result is the same, somehow #SstHttpUrl doesn't get loaded even thou I list it as a class to be loaded.  The packaging says the app is selected.  #SstTcpCommunications is also a prerequisite.

I don't care about the size of the image, I just want everything that is needed to be present.

Lou

 

On Sunday, January 31, 2021 at 1:22:18 PM UTC-5 [hidden email] wrote:

Hi Lou,

packaging Sst is very particular - it has serve and to support headless and windows service environments, to mention a few (that means XD images).

So I fear you will run into many problems if you are not extremely careful.

This may sound inconvenient for you, but try to load Sst using the feature load in a fresh image before your loading your app.

I assume a bunch of initialization stuff in Sst is done here - to support XD and headless images.

Simply loading config maps or selected applications won't do, neither in the delopment nor in an XD image.

Also do not attempt to execute anything in the image before packaging.

It might destroy the consistency if something is executed before packaging (in XD you cannot run anything in the image to be packaged).

Further do not assume that the Sst Image to be optimal in size - it is designed to provide you with a fully functional headless server framework.

Even if you using only portions of Sst like sockets, transport protocols and the like, this may cause to load much more than actually needed.

May be that this helps you to include SstHttpUrl.

Good luck

Marcus

[I once successfully created an XD as windows NT service with SST, Seaside, JSON and ODBC - but always headless].

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 17:52:38 UTC+1:

Hi,

Now it seems the packager won't include #SstHttpUrl.  Even though I tell it to include the class and the app it lives in?

Lou

On Sunday, January 31, 2021 at 11:18:07 AM UTC-5 Louis LaBrunda wrote:

Hi All,

This is solved, almost.  I thought about # OldObjectLoader and realized I don't need it.  So, I added a rule to set 'ClassOfOldLoader' to nil.

That got me past the packaging error.

Now I get a runtime error when calling "sstAsUrl fetch".  Probably something is missing.  I will let you know.

Lou

On Sunday, January 31, 2021 at 10:44:56 AM UTC-5 Louis LaBrunda wrote:

Hi Marcus, Hi Everybody,

Thanks for the help.

I was including the map that brought in all the Sst... stuff.  I dropped that in favor of including the individual apps.  I wanted to reduce the inclusion of things that may not have been needed like examples.  Side note to Instantiations: it would be nice if things like examples were in their own maps.  After defining my map with the apps needed, I ended up in the same place with the same error.

As for:

SstSwapperMarshaling class>>packagingRulesFor:

    aRuleCollector
        initializeToNilClassVariable: 'ClassOfOldLoader' inClassNamed: #ObjectLoader;    "$NON-NLS$"
                "Must be included to maintain possible marshalling well-known-classes encoding
                orderings"
        includeClassNamed: #SstLinearLookupTable

It is suspicious but it is setting the class variable to nil which would remove the need to include #OldObjectLoader.  My instruction to include the class should override that?  Also, with what I have loaded at the time of packaging, I can't find that rule.

I'm looking in the packaged image contents browser and everywhere else I can think of but can't find why packager does this:

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

I don't expect anyone to try but I think packaging any GUI program that included both #ObjectLoaded and "sstAsUrl fetch", would reproduce the problem.

Lou

On Sunday, January 31, 2021 at 6:17:58 AM UTC-5 [hidden email] wrote:

Hi Lou,

and another idea: packager says "disallowed by the rule policy". I know about the opposite case, a rule to exclude s.th. is not allowed producing ICs, for example.

What reduction policy is in use?

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi,

I forgot to include the URL I am trying to fetch:

('http://www.keystone-software.com/ftp/download/windows/KscCheckBookVersionLog.Txt' sstAsUrl fetch) inspect.

It should work in both dev and the packaged program (without the inspect - in there I parse the file).  So far, only dev.

I'm going to look at the files created during packaging to see if they say anything else.

Lou

On Monday, February 1, 2021 at 10:29:08 AM UTC-5 Louis LaBrunda wrote:

Hi Marcus,

Thanks for all the help.

Let me recap where things are at now and a little about how it got here.  I started out with loading the feature "ST: Server Smalltalk (SST) - HTTP" as the first of the required maps.  I am back to that.  When I first packaged there were complaints about missing classes, some were #Sst... stuff and one was #OldObjectLoader.  I seemingly solver the #Sst... stuff by rules that included the classes.  I finally solved the #OldObjectLoader with a rule that set 'ClassOfOldLoader' to nil.  I liked that as I don't need it anyway.  I don't care if it is included but since I don't need it, there is no reason to go crazy fighting the packager to force its inclusion.

Also, I start with an almost clean v9.2.2 image (maybe a few settings set).  I load my map for this application that loads my support apps, and the program app.  I then run something the cleans a few things up and make more setting changes.  At this point everything looks good and testing the program works great.

That brings us to the present.  When packaging I start with the image described about but without any testing.  With feature "ST: Server Smalltalk (SST) - HTTP" as the first of the required maps and a few #Sst... classes loaded by the rule: #packagerIncludeClassNames (#SstFileUrl #SstHttpUrl #SciSocketAddress #SstHttpClient - there are other non #Sst.. classes too).  I also include #SstTcpCommunications #SstHttpCommunications,  in the list of applications to load.  This seems to package without errors.  But when I run the program, it walkbacks because #SstHttpUrl is not loaded.  Looking in classes.es it shows: SstHttpUrl excluded [application not selected].  

#SstHttpUrl is in #SstHttpCommunications, I explicitly tell the packager to load both but it won't.

A little more history.  This is a Windows GUI program.  I also have a VA Smalltalk/Seaside Linux program that runs on a Raspberry Pi.  I do all the development work on windows, package on windows and copy the image to the Raspberry.  Not the easiest thing to do but it works.  I don't think I use #SstHttpUrl but I think Seaside does and I think it is included in the packaged image.

Lou

On Sunday, January 31, 2021 at 3:46:23 PM UTC-5 [hidden email] wrote:

Hi Lou,

did you register SstHttpUrl in SstHttpCommunications via loading the feature "ST: Server Smalltalk (SST) - HTTP"?

(SstHttpCommunications contains this

The class named #SstHttpUrl will be included in the packaged image, because of an inferred rule (see below).

The following rules infer an effect on the component:

(1)     do not reduce #SstHttpCommunications
    [defined by SstHttpCommunications class>>#packagingRulesFor:]

I created a simply visual part with a method referencing (nonsense code, but nethertheless)

    OldObjectLoader new.
    ObjectLoader new.
    SstEndpoint new sstAsUrl fetch

run the  Make Executable and my image is ok!

-> SstTcpCommunications is NOT sufficient, SstHttpCommunications [or SstHttpsCommunications] is required...

Good luck!

Marcus

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 20:09:06 UTC+1:

Hi  Marcus ,

I tried loading the feature and then packaging, both via my automated means and the "Make Executable" button on the Organizer window.  The result is the same, somehow #SstHttpUrl doesn't get loaded even thou I list it as a class to be loaded.  The packaging says the app is selected.  #SstTcpCommunications is also a prerequisite.

I don't care about the size of the image, I just want everything that is needed to be present.

Lou

 

On Sunday, January 31, 2021 at 1:22:18 PM UTC-5 [hidden email] wrote:

Hi Lou,

packaging Sst is very particular - it has serve and to support headless and windows service environments, to mention a few (that means XD images).

So I fear you will run into many problems if you are not extremely careful.

This may sound inconvenient for you, but try to load Sst using the feature load in a fresh image before your loading your app.

I assume a bunch of initialization stuff in Sst is done here - to support XD and headless images.

Simply loading config maps or selected applications won't do, neither in the delopment nor in an XD image.

Also do not attempt to execute anything in the image before packaging.

It might destroy the consistency if something is executed before packaging (in XD you cannot run anything in the image to be packaged).

Further do not assume that the Sst Image to be optimal in size - it is designed to provide you with a fully functional headless server framework.

Even if you using only portions of Sst like sockets, transport protocols and the like, this may cause to load much more than actually needed.

May be that this helps you to include SstHttpUrl.

Good luck

Marcus

[I once successfully created an XD as windows NT service with SST, Seaside, JSON and ODBC - but always headless].

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 17:52:38 UTC+1:

Hi,

Now it seems the packager won't include #SstHttpUrl.  Even though I tell it to include the class and the app it lives in?

Lou

On Sunday, January 31, 2021 at 11:18:07 AM UTC-5 Louis LaBrunda wrote:

Hi All,

This is solved, almost.  I thought about # OldObjectLoader and realized I don't need it.  So, I added a rule to set 'ClassOfOldLoader' to nil.

That got me past the packaging error.

Now I get a runtime error when calling "sstAsUrl fetch".  Probably something is missing.  I will let you know.

Lou

On Sunday, January 31, 2021 at 10:44:56 AM UTC-5 Louis LaBrunda wrote:

Hi Marcus, Hi Everybody,

Thanks for the help.

I was including the map that brought in all the Sst... stuff.  I dropped that in favor of including the individual apps.  I wanted to reduce the inclusion of things that may not have been needed like examples.  Side note to Instantiations: it would be nice if things like examples were in their own maps.  After defining my map with the apps needed, I ended up in the same place with the same error.

As for:

SstSwapperMarshaling class>>packagingRulesFor:

    aRuleCollector
        initializeToNilClassVariable: 'ClassOfOldLoader' inClassNamed: #ObjectLoader;    "$NON-NLS$"
                "Must be included to maintain possible marshalling well-known-classes encoding
                orderings"
        includeClassNamed: #SstLinearLookupTable

It is suspicious but it is setting the class variable to nil which would remove the need to include #OldObjectLoader.  My instruction to include the class should override that?  Also, with what I have loaded at the time of packaging, I can't find that rule.

I'm looking in the packaged image contents browser and everywhere else I can think of but can't find why packager does this:

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

I don't expect anyone to try but I think packaging any GUI program that included both #ObjectLoaded and "sstAsUrl fetch", would reproduce the problem.

Lou

On Sunday, January 31, 2021 at 6:17:58 AM UTC-5 [hidden email] wrote:

Hi Lou,

and another idea: packager says "disallowed by the rule policy". I know about the opposite case, a rule to exclude s.th. is not allowed producing ICs, for example.

What reduction policy is in use?

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi Lou,

I am not sure that I understood an important detail of your description above:

do you load features using the load/unload feature menu entry in tools OR

do you add config maps describing features as prerequisite configuration maps in you own configuration maps and then do you load them using the configuration map browser?

The later, I fear, won't work.

Feature load from the tool menu does more than loading configuration maps (and prerequisites) out of the configuration map browser.

It is likely that you are missing s.th. doing so. Feature load was provided by ABT (Vast IBM) and configuration load was provided by Envy (OTI).

Feature load is based loading maps, but it does more... (particularly in XD packaging).

I start out to load all required features first in an image (which may be stored aside for later to save time) and then to load my stuff (organized in configuration maps).

My configuration maps never had prerequisite references to features (to avoid potential losses).

And I inspected your example

'...' sstAsUrl fetch

sstAsUrl (of SstUrl) cracks the string and looks up for the scheme to dispatch to the right parser. Here it instantiates the url in the string as instance of SstHttpUrl.

Otherwise it will fail (SstUrl instances do not understand fetch).

Check if 

('...' sstAsUrl) isKindOf: SstHttpUrl

is true at run time. It is not, then the Sst registry of schemes, parsers, transport, ... is broken.

Reasons of broken registry are missing execution of loaded, startUp, initialize methods in the packaged image or that loaded structures (of the development image) are not copied properly over to the runtime image.

Later practice was very useful for fast startups of runtime images - but heavily restricted in XD images (only simply objects like strings, numbers, symbols etc. may be copied into a XD runtime image). Using XD required significant preparation not to lose s.th. when packaging.

I assume that you use XD to package a Linux Image under Windows to be run on the Raspberry.

In that case I assume that you are aware about the XD image restrictions.

Marcus

[hidden email] schrieb am Montag, 1. Februar 2021 um 16:45:32 UTC+1:

Hi,

I forgot to include the URL I am trying to fetch:

('http://www.keystone-software.com/ftp/download/windows/KscCheckBookVersionLog.Txt' sstAsUrl fetch) inspect.

It should work in both dev and the packaged program (without the inspect - in there I parse the file).  So far, only dev.

I'm going to look at the files created during packaging to see if they say anything else.

Lou

On Monday, February 1, 2021 at 10:29:08 AM UTC-5 Louis LaBrunda wrote:

Hi Marcus,

Thanks for all the help.

Let me recap where things are at now and a little about how it got here.  I started out with loading the feature "ST: Server Smalltalk (SST) - HTTP" as the first of the required maps.  I am back to that.  When I first packaged there were complaints about missing classes, some were #Sst... stuff and one was #OldObjectLoader.  I seemingly solver the #Sst... stuff by rules that included the classes.  I finally solved the #OldObjectLoader with a rule that set 'ClassOfOldLoader' to nil.  I liked that as I don't need it anyway.  I don't care if it is included but since I don't need it, there is no reason to go crazy fighting the packager to force its inclusion.

Also, I start with an almost clean v9.2.2 image (maybe a few settings set).  I load my map for this application that loads my support apps, and the program app.  I then run something the cleans a few things up and make more setting changes.  At this point everything looks good and testing the program works great.

That brings us to the present.  When packaging I start with the image described about but without any testing.  With feature "ST: Server Smalltalk (SST) - HTTP" as the first of the required maps and a few #Sst... classes loaded by the rule: #packagerIncludeClassNames (#SstFileUrl #SstHttpUrl #SciSocketAddress #SstHttpClient - there are other non #Sst.. classes too).  I also include #SstTcpCommunications #SstHttpCommunications,  in the list of applications to load.  This seems to package without errors.  But when I run the program, it walkbacks because #SstHttpUrl is not loaded.  Looking in classes.es it shows: SstHttpUrl excluded [application not selected].  

#SstHttpUrl is in #SstHttpCommunications, I explicitly tell the packager to load both but it won't.

A little more history.  This is a Windows GUI program.  I also have a VA Smalltalk/Seaside Linux program that runs on a Raspberry Pi.  I do all the development work on windows, package on windows and copy the image to the Raspberry.  Not the easiest thing to do but it works.  I don't think I use #SstHttpUrl but I think Seaside does and I think it is included in the packaged image.

Lou

On Sunday, January 31, 2021 at 3:46:23 PM UTC-5 [hidden email] wrote:

Hi Lou,

did you register SstHttpUrl in SstHttpCommunications via loading the feature "ST: Server Smalltalk (SST) - HTTP"?

(SstHttpCommunications contains this

The class named #SstHttpUrl will be included in the packaged image, because of an inferred rule (see below).

The following rules infer an effect on the component:

(1)     do not reduce #SstHttpCommunications
    [defined by SstHttpCommunications class>>#packagingRulesFor:]

I created a simply visual part with a method referencing (nonsense code, but nethertheless)

    OldObjectLoader new.
    ObjectLoader new.
    SstEndpoint new sstAsUrl fetch

run the  Make Executable and my image is ok!

-> SstTcpCommunications is NOT sufficient, SstHttpCommunications [or SstHttpsCommunications] is required...

Good luck!

Marcus

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 20:09:06 UTC+1:

Hi  Marcus ,

I tried loading the feature and then packaging, both via my automated means and the "Make Executable" button on the Organizer window.  The result is the same, somehow #SstHttpUrl doesn't get loaded even thou I list it as a class to be loaded.  The packaging says the app is selected.  #SstTcpCommunications is also a prerequisite.

I don't care about the size of the image, I just want everything that is needed to be present.

Lou

 

On Sunday, January 31, 2021 at 1:22:18 PM UTC-5 [hidden email] wrote:

Hi Lou,

packaging Sst is very particular - it has serve and to support headless and windows service environments, to mention a few (that means XD images).

So I fear you will run into many problems if you are not extremely careful.

This may sound inconvenient for you, but try to load Sst using the feature load in a fresh image before your loading your app.

I assume a bunch of initialization stuff in Sst is done here - to support XD and headless images.

Simply loading config maps or selected applications won't do, neither in the delopment nor in an XD image.

Also do not attempt to execute anything in the image before packaging.

It might destroy the consistency if something is executed before packaging (in XD you cannot run anything in the image to be packaged).

Further do not assume that the Sst Image to be optimal in size - it is designed to provide you with a fully functional headless server framework.

Even if you using only portions of Sst like sockets, transport protocols and the like, this may cause to load much more than actually needed.

May be that this helps you to include SstHttpUrl.

Good luck

Marcus

[I once successfully created an XD as windows NT service with SST, Seaside, JSON and ODBC - but always headless].

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 17:52:38 UTC+1:

Hi,

Now it seems the packager won't include #SstHttpUrl.  Even though I tell it to include the class and the app it lives in?

Lou

On Sunday, January 31, 2021 at 11:18:07 AM UTC-5 Louis LaBrunda wrote:

Hi All,

This is solved, almost.  I thought about # OldObjectLoader and realized I don't need it.  So, I added a rule to set 'ClassOfOldLoader' to nil.

That got me past the packaging error.

Now I get a runtime error when calling "sstAsUrl fetch".  Probably something is missing.  I will let you know.

Lou

On Sunday, January 31, 2021 at 10:44:56 AM UTC-5 Louis LaBrunda wrote:

Hi Marcus, Hi Everybody,

Thanks for the help.

I was including the map that brought in all the Sst... stuff.  I dropped that in favor of including the individual apps.  I wanted to reduce the inclusion of things that may not have been needed like examples.  Side note to Instantiations: it would be nice if things like examples were in their own maps.  After defining my map with the apps needed, I ended up in the same place with the same error.

As for:

SstSwapperMarshaling class>>packagingRulesFor:

    aRuleCollector
        initializeToNilClassVariable: 'ClassOfOldLoader' inClassNamed: #ObjectLoader;    "$NON-NLS$"
                "Must be included to maintain possible marshalling well-known-classes encoding
                orderings"
        includeClassNamed: #SstLinearLookupTable

It is suspicious but it is setting the class variable to nil which would remove the need to include #OldObjectLoader.  My instruction to include the class should override that?  Also, with what I have loaded at the time of packaging, I can't find that rule.

I'm looking in the packaged image contents browser and everywhere else I can think of but can't find why packager does this:

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

I don't expect anyone to try but I think packaging any GUI program that included both #ObjectLoaded and "sstAsUrl fetch", would reproduce the problem.

Lou

On Sunday, January 31, 2021 at 6:17:58 AM UTC-5 [hidden email] wrote:

Hi Lou,

and another idea: packager says "disallowed by the rule policy". I know about the opposite case, a rule to exclude s.th. is not allowed producing ICs, for example.

What reduction policy is in use?

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi Lou,

attached you will find my demo gui attached in the zip. Please take a fresh image.

Import the single app WamKSCGuiApp [2021-02-01] MW 1.1 out of it into your respository of choice.

Load feature "ST: Server Smalltalk (SST) - HTTP" using menu tools from Transcript.

Load this application WamKSCGuiApp .

Goto Visual Organizer. Select this app.

Run Make Executable...

Select WamKSCGui as Windows to show at startup in the package dialog.

Run the package process. Store the results in a place of your choice.

Run myapp.exe from there. It will display the text from the link. See method display of WamKSCGui.

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi Lou,

I am glad that you had success. Thank you for you checkbook.msi, I will look at it tomorrow, as I am late to leave office now (8:35 pm here) to go home to my family. Thank you for your patience

Marcus

Marcus Wagner schrieb am Montag, 1. Februar 2021 um 20:32:03 UTC+1:

Hi Lou,

attached you will find my demo gui attached in the zip. Please take a fresh image.

Import the single app WamKSCGuiApp [2021-02-01] MW 1.1 out of it into your respository of choice.

Load feature "ST: Server Smalltalk (SST) - HTTP" using menu tools from Transcript.

Load this application WamKSCGuiApp .

Goto Visual Organizer. Select this app.

Run Make Executable...

Select WamKSCGui as Windows to show at startup in the package dialog.

Run the package process. Store the results in a place of your choice.

Run myapp.exe from there. It will display the text from the link. See method display of WamKSCGui.

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.

Hi Lou,

packaging Sst is very particular - it has serve and to support headless and windows service environments, to mention a few (that means XD images).

So I fear you will run into many problems if you are not extremely careful.

This may sound inconvenient for you, but try to load Sst using the feature load in a fresh image before your loading your app.

I assume a bunch of initialization stuff in Sst is done here - to support XD and headless images.

Simply loading config maps or selected applications won't do, neither in the delopment nor in an XD image.

Also do not attempt to execute anything in the image before packaging.

It might destroy the consistency if something is executed before packaging (in XD you cannot run anything in the image to be packaged).

Further do not assume that the Sst Image to be optimal in size - it is designed to provide you with a fully functional headless server framework.

Even if you using only portions of Sst like sockets, transport protocols and the like, this may cause to load much more than actually needed.

May be that this helps you to include SstHttpUrl.

Good luck

Marcus

[I once successfully created an XD as windows NT service with SST, Seaside, JSON and ODBC - but always headless].

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 17:52:38 UTC+1:

Hi,

Now it seems the packager won't include #SstHttpUrl.  Even though I tell it to include the class and the app it lives in?

Lou

On Sunday, January 31, 2021 at 11:18:07 AM UTC-5 Louis LaBrunda wrote:

Hi All,

This is solved, almost.  I thought about # OldObjectLoader and realized I don't need it.  So, I added a rule to set 'ClassOfOldLoader' to nil.

That got me past the packaging error.

Now I get a runtime error when calling "sstAsUrl fetch".  Probably something is missing.  I will let you know.

Lou

On Sunday, January 31, 2021 at 10:44:56 AM UTC-5 Louis LaBrunda wrote:

Hi Marcus, Hi Everybody,

Thanks for the help.

I was including the map that brought in all the Sst... stuff.  I dropped that in favor of including the individual apps.  I wanted to reduce the inclusion of things that may not have been needed like examples.  Side note to Instantiations: it would be nice if things like examples were in their own maps.  After defining my map with the apps needed, I ended up in the same place with the same error.

As for:

SstSwapperMarshaling class>>packagingRulesFor:

    aRuleCollector
        initializeToNilClassVariable: 'ClassOfOldLoader' inClassNamed: #ObjectLoader;    "$NON-NLS$"
                "Must be included to maintain possible marshalling well-known-classes encoding
                orderings"
        includeClassNamed: #SstLinearLookupTable

It is suspicious but it is setting the class variable to nil which would remove the need to include #OldObjectLoader.  My instruction to include the class should override that?  Also, with what I have loaded at the time of packaging, I can't find that rule.

I'm looking in the packaged image contents browser and everywhere else I can think of but can't find why packager does this:

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

I don't expect anyone to try but I think packaging any GUI program that included both #ObjectLoaded and "sstAsUrl fetch", would reproduce the problem.

Lou

On Sunday, January 31, 2021 at 6:17:58 AM UTC-5 [hidden email] wrote:

Hi Lou,

and another idea: packager says "disallowed by the rule policy". I know about the opposite case, a rule to exclude s.th. is not allowed producing ICs, for example.

What reduction policy is in use?

Marcus

[hidden email] schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Hi All,

I'm getting an odd problem (see below) trying to package a VA Smalltalk GUI program.  The packaging was working just fine.  I added the use of "sstAsUrl fetch".  It caused some packaging problems that I resolved.  The problem below remains.  I don't see the connection of the last problem with "sstAsUrl fetch".  I have implemented the suggested solutions but no joy.

Why does the packager reject my including class named #OldObjectLoader in #packagerIncludeClassNames?

Lou

The class named #OldObjectLoader has been referenced in ObjectLoader class>>#classOfOldLoader by ClassOfOldLoader.

The class named #OldObjectLoader will be excluded from the packaged image, because the application the component is defined in has not been selected for packaging.

The following rules refer to the component but were disallowed by the rule policy:

(1) include class named #OldObjectLoader

[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

Possible solutions are: 

(1) Add EswOldSwapper to the list of applications to package (the root application the class named #OldObjectLoader is defined in).

(2) If the method where the error occurred is not required at runtime, the method can be excluded from the packaged image.