Packaging problem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Packaging problem

Louis LaBrunda
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/cc0674db-c28c-42a5-befd-b0ac2742c3edn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Marcus Wagner
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/942b3132-4915-4dce-9490-60c7505bc998n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Louis LaBrunda
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/943463c3-d92c-4816-84f2-98e4c58c8eb6n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

jtuchel
Hi Lou,

does the packaged image contents browser give any hints?


Joachim

[hidden email] schrieb am Sonntag, 31. Januar 2021 um 00:23:44 UTC+1:
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/aa84d265-827b-4db1-811e-b06e9687e1c7n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Marcus Wagner
In reply to this post by Louis LaBrunda
Hi Lou,

I picked up your hint mentioning " sstAsUrl". I deduce that you are using parts of SST. So I looked around there and found this rule

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

Might this rule be contributing to the conflict?

Without having access to your image is seems to be possible  that this cancels the use of OldObjectLoader (despite the class being included by the packager).

As Joachim suggested, consider to look in the package contents browser if the class is in- or excluded and about the state of this class variable 'ClassOfOldLoader'.

If you are using SstSwapperMarshaling we have to find a way to enable OldObjectLoader (e.g. by setting the variable ClassOfOldLoader again in the startup) and then to study if this causes failures in marshaling.
If you are not using SstSwapperMarshaling (not included in your package) we have to look elsewhere.

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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/c5e56d2c-be98-4784-b88d-f0c2d85fb96dn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Marcus Wagner
In reply to this post by Louis LaBrunda
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/92ffc15f-81f2-43cc-9821-4e0bae89fc27n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Louis LaBrunda
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/26dc3beb-acc3-484e-a948-57e196da78cen%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Louis LaBrunda
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/7fdaa650-d28c-4c05-952a-a6a2752017ffn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Louis LaBrunda
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/1c72465b-6c63-4b69-8946-b790dda0e9den%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Marcus Wagner
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/28463f2d-42eb-4e51-8e17-dbff10d282efn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Louis LaBrunda
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/2accad5d-e428-420b-8bdb-e43341949604n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Marcus Wagner
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/2d860181-e364-470b-818d-2ea9a6c23858n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Louis LaBrunda
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/cc353605-b704-45cf-9087-48af17c39420n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Louis LaBrunda
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/9fea82be-e01d-4378-b0ed-911f26a4c08cn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Marcus Wagner
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:

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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/28079fed-1f81-407f-96a1-ab83ed430e8fn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Louis LaBrunda
Hi Marcus,

Problem solved, many, many thanks.

I was just using "ST: Server Smalltalk (SST) - HTTP" loaded from my configuration map.  I had tried loading the feature from the Options>Load/Unload Features... menu item before but it didn't work.  There must have been some other problem.

I removed it from my map so now it only contains my apps and required maps.

I start with the clean image I mentioned before, loaded the "ST: Server Smalltalk (SST) - HTTP" feature and saved that image for later use and convenience (I use CMD files to copy a starting image to be sure I'm working with a clean image).  I then use my automated image packaging code and my now very simple map to package the image.  All works great and the resultant program runs well and can retrieve the file.

If you are one of those people like me who like to balance their checkbook but hates the little paper checkbook registries you can download an install of my checkbook program here: KscCheckBookInstallV1_15.msi.

The feature I just added was to check the web site for the latest version and download and install it if you want.

Lou


On Monday, February 1, 2021 at 11:58:43 AM UTC-5 [hidden email] wrote:
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:

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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/35ee952b-8910-4116-8322-750287e9a2f0n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Marcus Wagner
In reply to this post by Louis LaBrunda
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/30e9ffad-d69c-4e5c-8537-14b172f67385n%40googlegroups.com.

ksc.zip (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Marcus Wagner
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/5d281131-11af-4d4e-a44e-99ecb6d72120n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Louis LaBrunda
Hi Marcus,

Thank you for all the help.

I forgot to ask, what is  s.th?

The checkbook program is something I wrote because I needed it.  If you like it and car to share it with others, I good with that.  If there is anything you think would improve it, just say so.

Lou

On Monday, February 1, 2021 at 2:37:01 PM UTC-5 [hidden email] wrote:
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/c7f4f306-2214-4ea2-b483-602ac5de8e4an%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

jtuchel
In reply to this post by Marcus Wagner
Marcus, Lou,

this is somewhat off-topic, but we've been packaging our Kontolino! headless image for quite a few years now (it went into production in 2013) and in addition to what you said about not doing anything in an image before packaging, I'd like to add a few tips that we established as our bet practice for XD packaging:
  1. create an environment which is exclusively used for XD packaging
  2. prepare a set of config map versions to preload things like Sst, Glorp and whatnot, but do not load them into that into this new image
  3. prepare a config map version for the actual application code
  4. prepare a fresh image in the environment
  5. create the passive image and save the image with its passive image
  6. load your packaging instructions into the active image
  7. switch to the passive image
  8. save image, quit VAST
  9. THIS IS THE MOST IMPORTANT STEP: go the the Windows Explorer and make the abt.icx readonly. For everybody. Right in this moment, don't do it later.
If you have some automation stuff in place, load and prepare that stuff somewhere between steps 6 and 8.

This read-only image makes things easier to handle. You know for sure nobody did or saved anything in this image before packaging. The result will be mch more reliable than any following of checklists and whatnot.

TL;DR:

Try to establish some packaging routine that works out of clean images. Force it, don't trust in anybody, even if there is noone else than yourself. A Pre-loaded image with XD image and packaging instructions saves you literally minutes every time you package.
There is only one thing that could be even better: automate the preparation of an XD image so far that you always use a fresh abt.icx that drags itself out of the swamp at its own hair with a single Environment click or Jenkins Script. But please make sure your XD Packaging image is never going to be used twice.


Joachim



[hidden email] schrieb am Sonntag, 31. Januar 2021 um 19:22:18 UTC+1:
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/2ad19f53-e190-4d7f-83be-d59e77464c0fn%40googlegroups.com.
12