Packaging problem

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.

Interesting Joachim. I think you should really look https://github.com/instantiations/ci-examples-vast  as I am automating that very same/similar process. 

On Tue, Feb 2, 2021 at 12:33 PM Joachim Tuchel <[hidden email]> wrote:

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.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

Hi Joachim and Mariano,

Thanks for the information.

I have automated packaging for both headless and GUI applications.  When making changes, I start with a clean image, make the changes, version and then update maps.  To package I then again start with a clean image and bring things in via the maps.  The packaging step is automated to the point where I have added menu items to the "main" class (both headless and GUI) where I can right click on it and select the menu item that will run its packaging.  As I have said, this works well enough that I can package Raspberry Pi Linux stuff on windows and copy the image to the Raspberry.

What messed me up this time was that I was using a required map entry of "ST: Server Smalltalk (SST) - HTTP" that loaded the Sst... stuff into the clean image and worked and tested great in the development environment but failed to create a good packaged image.  For reasons I still don't fully understand, loading the Sst... stuff as a feature from the menu item is different than loading "it" from the map.  I now load it as a feature and not from a map for both development and packaging.  Note: the problem is for the GUI program.  The headless stuff uses the map and seems to be fine.  Go figure?

Lou

On Tuesday, February 2, 2021 at 10:46:20 AM UTC-5 [hidden email] wrote:

Interesting Joachim. I think you should really look https://github.com/instantiations/ci-examples-vast  as I am automating that very same/similar process. 

On Tue, Feb 2, 2021 at 12:33 PM Joachim Tuchel <[hidden email]> wrote:

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.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

Hi Lou,

This is of course a stupid question, because I know you have been using VAST at least as long as I have. But you mention diferences between loading a map vs. oading a feature....
Did you try loading one of the z.ST or z.VA maps? Because these are what features are about as far as I understand. So I would guess that loading z.ST: Server Smalltalk (SST) HTTP would solve your problems....?

Joachim

[hidden email] schrieb am Dienstag, 2. Februar 2021 um 19:41:45 UTC+1:

Hi Joachim and Mariano,

Thanks for the information.

I have automated packaging for both headless and GUI applications.  When making changes, I start with a clean image, make the changes, version and then update maps.  To package I then again start with a clean image and bring things in via the maps.  The packaging step is automated to the point where I have added menu items to the "main" class (both headless and GUI) where I can right click on it and select the menu item that will run its packaging.  As I have said, this works well enough that I can package Raspberry Pi Linux stuff on windows and copy the image to the Raspberry.

What messed me up this time was that I was using a required map entry of "ST: Server Smalltalk (SST) - HTTP" that loaded the Sst... stuff into the clean image and worked and tested great in the development environment but failed to create a good packaged image.  For reasons I still don't fully understand, loading the Sst... stuff as a feature from the menu item is different than loading "it" from the map.  I now load it as a feature and not from a map for both development and packaging.  Note: the problem is for the GUI program.  The headless stuff uses the map and seems to be fine.  Go figure?

Lou

On Tuesday, February 2, 2021 at 10:46:20 AM UTC-5 [hidden email] wrote:

Interesting Joachim. I think you should really look https://github.com/instantiations/ci-examples-vast  as I am automating that very same/similar process. 

On Tue, Feb 2, 2021 at 12:33 PM Joachim Tuchel <[hidden email]> wrote:

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.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

Hi Joachim,

It is not a stupid question at all.  VA Smalltalk packaging is one of those things like sockets that I know far more about (which isn't saying that much) than I ever wanted to learn.  The program I had this packaging problem with is a windows GUI (not headless) program.  I was loading  "ST: Server Smalltalk (SST) - HTTP" which caused the problem.  Is there a z.VA map that I should have been using?  Is that the difference between the maps?  What made things work was loading the Sst... stuff via the Options>Load/Unload Features... menu item.  Then packaging with a map that doesn't include "ST: Server Smalltalk (SST) - HTTP".  It is late now so maybe tomorrow (after I clean up some snow) I will look for a z.VA map and try it instead of loading the feature from the option.  If that works I will have learned one more thing I should probably know but...

Lou

On Tuesday, February 2, 2021 at 1:55:12 PM UTC-5 [hidden email] wrote:

Hi Lou,

This is of course a stupid question, because I know you have been using VAST at least as long as I have. But you mention diferences between loading a map vs. oading a feature....
Did you try loading one of the z.ST or z.VA maps? Because these are what features are about as far as I understand. So I would guess that loading z.ST: Server Smalltalk (SST) HTTP would solve your problems....?

Joachim

[hidden email] schrieb am Dienstag, 2. Februar 2021 um 19:41:45 UTC+1:

Hi Joachim and Mariano,

Thanks for the information.

I have automated packaging for both headless and GUI applications.  When making changes, I start with a clean image, make the changes, version and then update maps.  To package I then again start with a clean image and bring things in via the maps.  The packaging step is automated to the point where I have added menu items to the "main" class (both headless and GUI) where I can right click on it and select the menu item that will run its packaging.  As I have said, this works well enough that I can package Raspberry Pi Linux stuff on windows and copy the image to the Raspberry.

What messed me up this time was that I was using a required map entry of "ST: Server Smalltalk (SST) - HTTP" that loaded the Sst... stuff into the clean image and worked and tested great in the development environment but failed to create a good packaged image.  For reasons I still don't fully understand, loading the Sst... stuff as a feature from the menu item is different than loading "it" from the map.  I now load it as a feature and not from a map for both development and packaging.  Note: the problem is for the GUI program.  The headless stuff uses the map and seems to be fine.  Go figure?

Lou

On Tuesday, February 2, 2021 at 10:46:20 AM UTC-5 [hidden email] wrote:

Interesting Joachim. I think you should really look https://github.com/instantiations/ci-examples-vast  as I am automating that very same/similar process. 

On Tue, Feb 2, 2021 at 12:33 PM Joachim Tuchel <[hidden email]> wrote:

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.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

Lou,

I don't think there is a z.VA version and I also don'zt think there should be. Sst stuff is always headless, so there is nothing in it that would need VA stuff.

So I would guess that if you load the z.ST stuff, you will be fine. As far as I understand Features, the z.* maps are what they are about. Although I must admit I never got confirmation on that from anywhere ;-)

Joachim

[hidden email] schrieb am Mittwoch, 3. Februar 2021 um 01:17:24 UTC+1:

Hi Joachim,

It is not a stupid question at all.  VA Smalltalk packaging is one of those things like sockets that I know far more about (which isn't saying that much) than I ever wanted to learn.  The program I had this packaging problem with is a windows GUI (not headless) program.  I was loading  "ST: Server Smalltalk (SST) - HTTP" which caused the problem.  Is there a z.VA map that I should have been using?  Is that the difference between the maps?  What made things work was loading the Sst... stuff via the Options>Load/Unload Features... menu item.  Then packaging with a map that doesn't include "ST: Server Smalltalk (SST) - HTTP".  It is late now so maybe tomorrow (after I clean up some snow) I will look for a z.VA map and try it instead of loading the feature from the option.  If that works I will have learned one more thing I should probably know but...

Lou

On Tuesday, February 2, 2021 at 1:55:12 PM UTC-5 [hidden email] wrote:

Hi Lou,

This is of course a stupid question, because I know you have been using VAST at least as long as I have. But you mention diferences between loading a map vs. oading a feature....
Did you try loading one of the z.ST or z.VA maps? Because these are what features are about as far as I understand. So I would guess that loading z.ST: Server Smalltalk (SST) HTTP would solve your problems....?

Joachim

[hidden email] schrieb am Dienstag, 2. Februar 2021 um 19:41:45 UTC+1:

Hi Joachim and Mariano,

Thanks for the information.

I have automated packaging for both headless and GUI applications.  When making changes, I start with a clean image, make the changes, version and then update maps.  To package I then again start with a clean image and bring things in via the maps.  The packaging step is automated to the point where I have added menu items to the "main" class (both headless and GUI) where I can right click on it and select the menu item that will run its packaging.  As I have said, this works well enough that I can package Raspberry Pi Linux stuff on windows and copy the image to the Raspberry.

What messed me up this time was that I was using a required map entry of "ST: Server Smalltalk (SST) - HTTP" that loaded the Sst... stuff into the clean image and worked and tested great in the development environment but failed to create a good packaged image.  For reasons I still don't fully understand, loading the Sst... stuff as a feature from the menu item is different than loading "it" from the map.  I now load it as a feature and not from a map for both development and packaging.  Note: the problem is for the GUI program.  The headless stuff uses the map and seems to be fine.  Go figure?

Lou

On Tuesday, February 2, 2021 at 10:46:20 AM UTC-5 [hidden email] wrote:

Interesting Joachim. I think you should really look https://github.com/instantiations/ci-examples-vast  as I am automating that very same/similar process. 

On Tue, Feb 2, 2021 at 12:33 PM Joachim Tuchel <[hidden email]> wrote:

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.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

Lou,

I don't think there is a z.VA version and I also don'zt think there should be. Sst stuff is always headless, so there is nothing in it that would need VA stuff.

So I would guess that if you load the z.ST stuff, you will be fine. As far as I understand Features, the z.* maps are what they are about. Although I must admit I never got confirmation on that from anywhere ;-)

Joachim

[hidden email] schrieb am Mittwoch, 3. Februar 2021 um 01:17:24 UTC+1:

Hi Joachim,

It is not a stupid question at all.  VA Smalltalk packaging is one of those things like sockets that I know far more about (which isn't saying that much) than I ever wanted to learn.  The program I had this packaging problem with is a windows GUI (not headless) program.  I was loading  "ST: Server Smalltalk (SST) - HTTP" which caused the problem.  Is there a z.VA map that I should have been using?  Is that the difference between the maps?  What made things work was loading the Sst... stuff via the Options>Load/Unload Features... menu item.  Then packaging with a map that doesn't include "ST: Server Smalltalk (SST) - HTTP".  It is late now so maybe tomorrow (after I clean up some snow) I will look for a z.VA map and try it instead of loading the feature from the option.  If that works I will have learned one more thing I should probably know but...

Lou

On Tuesday, February 2, 2021 at 1:55:12 PM UTC-5 [hidden email] wrote:

Hi Lou,

This is of course a stupid question, because I know you have been using VAST at least as long as I have. But you mention diferences between loading a map vs. oading a feature....
Did you try loading one of the z.ST or z.VA maps? Because these are what features are about as far as I understand. So I would guess that loading z.ST: Server Smalltalk (SST) HTTP would solve your problems....?

Joachim

[hidden email] schrieb am Dienstag, 2. Februar 2021 um 19:41:45 UTC+1:

Hi Joachim and Mariano,

Thanks for the information.

I have automated packaging for both headless and GUI applications.  When making changes, I start with a clean image, make the changes, version and then update maps.  To package I then again start with a clean image and bring things in via the maps.  The packaging step is automated to the point where I have added menu items to the "main" class (both headless and GUI) where I can right click on it and select the menu item that will run its packaging.  As I have said, this works well enough that I can package Raspberry Pi Linux stuff on windows and copy the image to the Raspberry.

What messed me up this time was that I was using a required map entry of "ST: Server Smalltalk (SST) - HTTP" that loaded the Sst... stuff into the clean image and worked and tested great in the development environment but failed to create a good packaged image.  For reasons I still don't fully understand, loading the Sst... stuff as a feature from the menu item is different than loading "it" from the map.  I now load it as a feature and not from a map for both development and packaging.  Note: the problem is for the GUI program.  The headless stuff uses the map and seems to be fine.  Go figure?

Lou

On Tuesday, February 2, 2021 at 10:46:20 AM UTC-5 [hidden email] wrote:

Interesting Joachim. I think you should really look https://github.com/instantiations/ci-examples-vast  as I am automating that very same/similar process. 

On Tue, Feb 2, 2021 at 12:33 PM Joachim Tuchel <[hidden email]> wrote:

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.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

Hi Joachim,

I can confirm that the z. maps are the definitions for the  Features.  The Feature Loader uses information stored in  the comments of the z. maps to determine the proper version to load, as well as if the Feature is even suitable for the current platform (Windows, Unix, etc).  Always keep in mind that loading (with required maps) a z. map  directly ties you to a specific version of the feature, so you would need to manage that appropriately.

Bob

On Wednesday, February 3, 2021 at 9:21:13 AM UTC-5 [hidden email] wrote:

Lou,

I don't think there is a z.VA version and I also don'zt think there should be. Sst stuff is always headless, so there is nothing in it that would need VA stuff.

So I would guess that if you load the z.ST stuff, you will be fine. As far as I understand Features, the z.* maps are what they are about. Although I must admit I never got confirmation on that from anywhere ;-)

Joachim

[hidden email] schrieb am Mittwoch, 3. Februar 2021 um 01:17:24 UTC+1:

Hi Joachim,

It is not a stupid question at all.  VA Smalltalk packaging is one of those things like sockets that I know far more about (which isn't saying that much) than I ever wanted to learn.  The program I had this packaging problem with is a windows GUI (not headless) program.  I was loading  "ST: Server Smalltalk (SST) - HTTP" which caused the problem.  Is there a z.VA map that I should have been using?  Is that the difference between the maps?  What made things work was loading the Sst... stuff via the Options>Load/Unload Features... menu item.  Then packaging with a map that doesn't include "ST: Server Smalltalk (SST) - HTTP".  It is late now so maybe tomorrow (after I clean up some snow) I will look for a z.VA map and try it instead of loading the feature from the option.  If that works I will have learned one more thing I should probably know but...

Lou

On Tuesday, February 2, 2021 at 1:55:12 PM UTC-5 [hidden email] wrote:

Hi Lou,

This is of course a stupid question, because I know you have been using VAST at least as long as I have. But you mention diferences between loading a map vs. oading a feature....
Did you try loading one of the z.ST or z.VA maps? Because these are what features are about as far as I understand. So I would guess that loading z.ST: Server Smalltalk (SST) HTTP would solve your problems....?

Joachim

[hidden email] schrieb am Dienstag, 2. Februar 2021 um 19:41:45 UTC+1:

Hi Joachim and Mariano,

Thanks for the information.

I have automated packaging for both headless and GUI applications.  When making changes, I start with a clean image, make the changes, version and then update maps.  To package I then again start with a clean image and bring things in via the maps.  The packaging step is automated to the point where I have added menu items to the "main" class (both headless and GUI) where I can right click on it and select the menu item that will run its packaging.  As I have said, this works well enough that I can package Raspberry Pi Linux stuff on windows and copy the image to the Raspberry.

What messed me up this time was that I was using a required map entry of "ST: Server Smalltalk (SST) - HTTP" that loaded the Sst... stuff into the clean image and worked and tested great in the development environment but failed to create a good packaged image.  For reasons I still don't fully understand, loading the Sst... stuff as a feature from the menu item is different than loading "it" from the map.  I now load it as a feature and not from a map for both development and packaging.  Note: the problem is for the GUI program.  The headless stuff uses the map and seems to be fine.  Go figure?

Lou

On Tuesday, February 2, 2021 at 10:46:20 AM UTC-5 [hidden email] wrote:

Interesting Joachim. I think you should really look https://github.com/instantiations/ci-examples-vast  as I am automating that very same/similar process. 

On Tue, Feb 2, 2021 at 12:33 PM Joachim Tuchel <[hidden email]> wrote:

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.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/