Packaging problem

139 views
Skip to first unread message

Louis LaBrunda

unread,
Jan 29, 2021, 5:48:51 PM1/29/21
to VA Smalltalk
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.

Marcus Wagner

unread,
Jan 30, 2021, 12:44:23 PM1/30/21
to VA Smalltalk
Hi Lou,
sounds that the referenced class is not defined in an application being part of the chain of the prerequisites of all apps you have added to package instructions. It is saying "add .. to the list of application to package".
Packager will not add a class to the package if it is "out of scope", where the scope consists of all apps added to the list to package including the closure of all prerequite apps. Even using any kind of include directive will not help.
My advice: run Envy Q/A over your code and check all "out of prequisite chain" references.
This kind of error is even worse if the referenced missing item is not a class but a pool entry, silently breaking associtions in methods.
Marcus

Louis LaBrunda

unread,
Jan 30, 2021, 6:23:44 PM1/30/21
to VA Smalltalk
Hi   Marcus ,

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

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

(1)  include class named #OldObjectLoader
[defined by KscCheckBookApp class>>#packagerIncludeClassNames]

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

Lou

Joachim Tuchel

unread,
Jan 31, 2021, 4:52:57 AM1/31/21
to VA Smalltalk
Hi Lou,

does the packaged image contents browser give any hints?


Joachim

Marcus Wagner

unread,
Jan 31, 2021, 5:57:24 AM1/31/21
to VA Smalltalk
Hi Lou,

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

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

Might this rule be contributing to the conflict?

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

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

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

Marcus


L...@Keystone-Software.com schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Marcus Wagner

unread,
Jan 31, 2021, 6:17:58 AM1/31/21
to VA Smalltalk
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

L...@Keystone-Software.com schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:

Louis LaBrunda

unread,
Jan 31, 2021, 10:44:56 AM1/31/21
to VA Smalltalk
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

Louis LaBrunda

unread,
Jan 31, 2021, 11:18:07 AM1/31/21
to VA Smalltalk
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

Louis LaBrunda

unread,
Jan 31, 2021, 11:52:38 AM1/31/21
to VA Smalltalk
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

Marcus Wagner

unread,
Jan 31, 2021, 1:22:18 PM1/31/21
to VA Smalltalk
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].

Louis LaBrunda

unread,
Jan 31, 2021, 2:09:06 PM1/31/21
to VA Smalltalk
Hi  Marcus ,

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

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

Lou

Marcus Wagner

unread,
Jan 31, 2021, 3:46:23 PM1/31/21
to VA Smalltalk
Hi Lou,
did you register SstHttpUrl in SstHttpCommunications via loading the feature "ST: Server Smalltalk (SST) - HTTP"?
(SstHttpCommunications contains this
The class named #SstHttpUrl will be included in the packaged image, because of an inferred rule (see below).

The following rules infer an effect on the component:

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


I created a simply visual part with a method referencing (nonsense code, but nethertheless)
    OldObjectLoader new.
    ObjectLoader new.
    SstEndpoint new sstAsUrl fetch
run the  Make Executable and my image is ok!
-> SstTcpCommunications is NOT sufficient, SstHttpCommunications [or SstHttpsCommunications] is required...
Good luck!
Marcus

Louis LaBrunda

unread,
Feb 1, 2021, 10:29:08 AM2/1/21
to VA Smalltalk
Hi Marcus,

Thanks for all the help.

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

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

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

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

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

Lou

Louis LaBrunda

unread,
Feb 1, 2021, 10:45:32 AM2/1/21
to VA Smalltalk
Hi,

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

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

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

Lou

Marcus Wagner

unread,
Feb 1, 2021, 11:58:43 AM2/1/21
to VA Smalltalk
Hi Lou,

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

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

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

The later, I fear, won't work.

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

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

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

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

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

And I inspected your example

'...' sstAsUrl fetch

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

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

Check if 

('...' sstAsUrl) isKindOf: SstHttpUrl

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

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

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

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

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

Marcus

Louis LaBrunda

unread,
Feb 1, 2021, 2:17:17 PM2/1/21
to VA Smalltalk
Hi Marcus,

Problem solved, many, many thanks.

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

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

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

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

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

Lou

Marcus Wagner

unread,
Feb 1, 2021, 2:32:03 PM2/1/21
to VA Smalltalk
Hi Lou,
attached you will find my demo gui attached in the zip. Please take a fresh image.
Import the single app WamKSCGuiApp [2021-02-01] MW 1.1 out of it into your respository of choice.
Load feature "ST: Server Smalltalk (SST) - HTTP" using menu tools from Transcript.
Load this application WamKSCGuiApp .
Goto Visual Organizer. Select this app.
Run Make Executable...
Select WamKSCGui as Windows to show at startup in the package dialog.
Run the package process. Store the results in a place of your choice.
Run myapp.exe from there. It will display the text from the link. See method display of WamKSCGui.
Marcus
L...@Keystone-Software.com schrieb am Freitag, 29. Januar 2021 um 23:48:51 UTC+1:
ksc.zip

Marcus Wagner

unread,
Feb 1, 2021, 2:37:01 PM2/1/21
to VA Smalltalk
Hi Lou,
I am glad that you had success. Thank you for you checkbook.msi, I will look at it tomorrow, as I am late to leave office now (8:35 pm here) to go home to my family. Thank you for your patience
Marcus

Louis LaBrunda

unread,
Feb 2, 2021, 8:41:58 AM2/2/21
to VA Smalltalk
Hi Marcus,

Thank you for all the help.

I forgot to ask, what is  s.th?

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

Lou

Joachim Tuchel

unread,
Feb 2, 2021, 10:33:23 AM2/2/21
to VA Smalltalk
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

Mariano Martinez Peck

unread,
Feb 2, 2021, 10:46:20 AM2/2/21
to VA Smalltalk
Interesting Joachim. I think you should really look https://github.com/instantiations/ci-examples-vast  as I am automating that very same/similar process. 

--
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 va-smalltalk...@googlegroups.com.
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.

Louis LaBrunda

unread,
Feb 2, 2021, 1:41:45 PM2/2/21
to VA Smalltalk
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

Joachim Tuchel

unread,
Feb 2, 2021, 1:55:12 PM2/2/21
to VA Smalltalk
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

Louis LaBrunda

unread,
Feb 2, 2021, 7:17:24 PM2/2/21
to VA Smalltalk
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

Joachim Tuchel

unread,
Feb 3, 2021, 9:21:13 AM2/3/21
to VA Smalltalk
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

Louis LaBrunda

unread,
Feb 3, 2021, 1:49:54 PM2/3/21
to VA Smalltalk
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:


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


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

Bob Brodd

unread,
Feb 3, 2021, 5:06:51 PM2/3/21
to VA Smalltalk
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 jtu...@objektfabrik.de wrote:

Joachim Tuchel

unread,
Feb 4, 2021, 2:53:53 PM2/4/21
to VA Smalltalk
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

David Gregory

unread,
Feb 4, 2021, 7:10:01 PM2/4/21
to va-sma...@googlegroups.com

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: va-sma...@googlegroups.com <va-sma...@googlegroups.com> On Behalf Of Joachim Tuchel
Sent: Friday, 5 February 2021 05:54
To: VA Smalltalk <va-sma...@googlegroups.com>
Subject: Re: Packaging problem

 

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

Reply all
Reply to author
Forward
0 new messages