Packaging problem

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

Re: Packaging problem

Mariano Martinez Peck-2
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.

--
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/CAOUkibFcDuHetCLX7Lh%2BtU3kjkVo51%3DnOWYN%3D51PnKwTCsh9CA%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

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

--
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/815c2f75-63ce-4f06-a1f5-ddcb8c5129ecn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

jtuchel
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.

--
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/88acd9f8-997d-4a2f-97c8-c9e2150ac895n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

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

--
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/00915837-9fb5-478c-a9ce-4670176849d6n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

jtuchel
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.

--
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/028a161f-fb18-43bf-8d4d-727cf23e8287n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Louis LaBrunda
Hi Joachim ,

I think you are right, there is no z.VA version and one isn't needed.  I tried putting "z.ST: Server Smalltalk (SST) - HTTP V 9.2.2 [002]" back as my first required map.  This is what I had before but for some reason when the program was packaged, a lot of the required Sst classes weren't in the image.  Marcus suggested that I first load the Sst... stuff from the Options>Load/Unload Features... menu item and then package.  That worked.  I saved an image with the feature loaded and would use that image with my automated packaging.

I have now gone back to starting with a clean image (the Sst... feature not loaded).  Using "z.ST: Server Smalltalk (SST) - HTTP V 9.2.2 [002]" as the first required map followed by another map of mine.  This map works both for loading things to work on in development and when I package the image.  So, when things weren't packaging the required classes, I must have changed something I thought was minor at the time that really fixed the problem.

I am very glad you asked your so called stupid question as it led me to try a few things even after I had things working and those things have gotten me to exactly where I want to be.  Thanks.

Now for the reason I am using the Sst... stuff in a GUI (non headless) program.  I wanted to add a feature to my little program where it could see if there was a newer version and give the user a chance to update.  Part of my packaging is to create a small file that servers as a version log.  I put the latest version of that file along with the latest install file where it can be downloaded on my web site.  I use this to read the file:

versionFile := 'http://www.keystone-software.com/ftp/download/windows/KscCheckBookVersionLog.Txt' sstAsUrl fetch.

I then parse the file to find the latest version.  I then build a URL to download the install file:

newInstall := 'http://www.keystone-software.com/ftp/download/windows/KscCheckBookInstallV1_15.msi' sstAsUrl fetch.

This is a big file but it download just find with the one line of code.  I then save the string to the disk where it can be run to install the latest version of the program.

Anyone interested in using this little program to keep track of a checking account without the old paper registry should feel free to use it.

Lou

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.

--
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/e2c60b0d-1c5e-4906-8367-0676b9f92c43n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

Bob Brodd
In reply to this post by jtuchel
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.

--
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/0d1c5c51-c4d0-4c78-9b23-384047297eb5n%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Packaging problem

jtuchel
Hi Bob,

thanks for this insight. I wasn't aware of the Comments and was wondering what the heck might be so special about Features. Now the mystery is solved ;-)
(I even have to admit I had to stare at the ConfigMap Browser for a while to find the comments ;-) )

Joachim



Bob Brodd schrieb am Mittwoch, 3. Februar 2021 um 23:06:51 UTC+1:
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.

--
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/89c2128b-df62-4d99-86b4-fe19d0bbd5fen%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

RE: Packaging problem

David Gregory

When working on the CI building system for smalltalk, we tried using ‘just config maps’ to bootstrap XD images for builds and packaging, but XD features do differ from config maps in 3 ways - main/development image features are very similar to a config map, but XD features are not.

 

The contents of an XD Feature are defined by a config map, but

1.       The feature will hunt for the appropriate version of the config map as already noted.  As most application versions are tied to a specific VAST version, tying to a specific z config map version is not all that problematic.

2.       The feature can set settings into the image.  Specifically for SST it sets a subsystem value.

3.       The feature loader is different to the config map loader in that the config map loader loads applications and required maps in a fixed order as defined by the maps.  The feature loader builds a list of applications to load using the content of the config map it links to, but does not use the order in the config maps.  It re-orders the load of applications based on a dependency analysis.

 

More technically XD Features are objects which are subclasses of AbtAbstractXDFeature.  These can do more than what a config map can do.  For example, AbtSstFeature>>#subsystemTypesFor: adds extra sub-systems to the image when you load the XD SST feature.  You cannot do that via a loading a config map alone.

 

Basically, the loading of the 'Server Smalltalk Framework (SST)' XD feature into an UNIX XD image is equivalent to doing the following steps:

-          Adding an SCI: UNIX subsystem

-          Loading the zz.Server.Hidden.AbtSstHiddenFeature config map

-          Loading the zz.Server.SstFeature config map

 

You can look at https://github.com/instantiations/ci-examples-vast/blob/master/scripts/abt.cnf#L141 for where the seaside example application loads the seaside feature into UNIX XD image. 

 

For my application, which uses SST HTTP we have to do the following instead

 

    installFeatures

        add: (Smalltalk classAt: 'AbtSstFeature' asSymbol) new;

        add: (Smalltalk classAt: 'AbtSstWebFeature' asSymbol) new;

        add: (Smalltalk classAt: 'AbtWebConnFeature' asSymbol) new.

 

If you just load the config map manually into the XD image, the correct subsystems won’t be set, and the application will spit out all sorts of cryptic errors as the bits needed by the relevant sub-systems won’t be included in the package.

 

 

 

 

From: [hidden email] <[hidden email]> On Behalf Of Joachim Tuchel
Sent: Friday, 5 February 2021 05:54
To: VA Smalltalk <[hidden email]>
Subject: Re: Packaging problem

 

EXTERNAL: Do not click links or open attachments if you do not recognize the sender.

Hi Bob,

 

thanks for this insight. I wasn't aware of the Comments and was wondering what the heck might be so special about Features. Now the mystery is solved ;-)

(I even have to admit I had to stare at the ConfigMap Browser for a while to find the comments ;-) )

 

Joachim

 

 

 

Bob Brodd schrieb am Mittwoch, 3. Februar 2021 um 23:06:51 UTC+1:

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.

--
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/89c2128b-df62-4d99-86b4-fe19d0bbd5fen%40googlegroups.com.

--
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/DB8P191MB0668337E30039FFBD173E08EBEB29%40DB8P191MB0668.EURP191.PROD.OUTLOOK.COM.
12