Packaging Rant

Hi All,

I'm still fighting with packaging my Raspberry/Seaside program on V9.2.2.  I'm sure I will get it done but I keep hitting things that drive me nuts.  For example the packager complains:

SciSslContext>>#certificate: - No implementors of #osX509

There are no implementors of #osX509 included in the packaged image.

well #osX509 is a method of #SciSslX509Certificate which is a class in #SciSslSocketInterface.  The packaging rules in the #SciSslSocketInterface app say:

packagingRulesFor: aRuleCollector

"Do Not Reduce anything in this application or subapplications"

aRuleCollector doNotReduceSubApplicationNamed: #SciSslSocketInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterfaceSSL.

which says don't reduce me.  But the packager doesn't listen and reduces it anyway.

I have my own rule that says to include the class named #SciSslX509Certificate.  Again the packager doesn't care and removes the class.  Then, as if to add insult to injury, bitches that there are no implementers of #osX509.

I could add another rule telling the packager to ignore to call to #osX509 but who knows if it will ignore the method call or ignore my rule to ignore the method call.

Also, I don't make a specific call to #osX509 but who knows if something I call calls it and it is really needed.

As part of the save packaging rules there is a list of applications to package.  In my packaging rules, I run that list and tell the packager not to reduce any of them.  The packager doesn't care.

Lou

P.S.  Sorry for the rant but I do feel a little better.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" 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/9df442ad-3c9d-4827-b1b2-e96e53600da5n%40googlegroups.com.

Hi Louis, 

I don't know what is going on with your packaging, but I cannot reproduce it. See attached screenshots. I also have SciSslSocketInterface in the list of my packaged apps and everything seems correct: I see no reported problem and the method osX509 is indeed included. 

Maybe you can go to your image contents, go to that method and see what is the rule that is reducing it. Let me know if you need help with this step. 

Best,

Mariano

On Fri, May 7, 2021 at 11:40 AM Louis LaBrunda <[hidden email]> wrote:

Hi All,

I'm still fighting with packaging my Raspberry/Seaside program on V9.2.2.  I'm sure I will get it done but I keep hitting things that drive me nuts.  For example the packager complains:

SciSslContext>>#certificate: - No implementors of #osX509

There are no implementors of #osX509 included in the packaged image.

well #osX509 is a method of #SciSslX509Certificate which is a class in #SciSslSocketInterface.  The packaging rules in the #SciSslSocketInterface app say:

packagingRulesFor: aRuleCollector

"Do Not Reduce anything in this application or subapplications"

aRuleCollector doNotReduceSubApplicationNamed: #SciSslSocketInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterfaceSSL.

which says don't reduce me.  But the packager doesn't listen and reduces it anyway.

I have my own rule that says to include the class named #SciSslX509Certificate.  Again the packager doesn't care and removes the class.  Then, as if to add insult to injury, bitches that there are no implementers of #osX509.

I could add another rule telling the packager to ignore to call to #osX509 but who knows if it will ignore the method call or ignore my rule to ignore the method call.

Also, I don't make a specific call to #osX509 but who knows if something I call calls it and it is really needed.

As part of the save packaging rules there is a list of applications to package.  In my packaging rules, I run that list and tell the packager not to reduce any of them.  The packager doesn't care.

Lou

P.S.  Sorry for the rant but I do feel a little better.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" 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/9df442ad-3c9d-4827-b1b2-e96e53600da5n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com

Louis,

not that I actually know what I am talking about, but is it possible that your packaging instructions were created in an older VAST version (9.1 or such) and are not up to date?

I ask because I seem to remember having "strange" effects with an unfinished migration of my PackagingRules for Kontolino a few releases ago...

maybe this helps. likely not.

Joachim

[hidden email] schrieb am Freitag, 7. Mai 2021 um 17:03:21 UTC+2:

Hi Louis, 

I don't know what is going on with your packaging, but I cannot reproduce it. See attached screenshots. I also have SciSslSocketInterface in the list of my packaged apps and everything seems correct: I see no reported problem and the method osX509 is indeed included. 

Maybe you can go to your image contents, go to that method and see what is the rule that is reducing it. Let me know if you need help with this step. 

Best,

Mariano

On Fri, May 7, 2021 at 11:40 AM Louis LaBrunda <[hidden email]> wrote:

Hi All,

I'm still fighting with packaging my Raspberry/Seaside program on V9.2.2.  I'm sure I will get it done but I keep hitting things that drive me nuts.  For example the packager complains:

SciSslContext>>#certificate: - No implementors of #osX509

There are no implementors of #osX509 included in the packaged image.

well #osX509 is a method of #SciSslX509Certificate which is a class in #SciSslSocketInterface.  The packaging rules in the #SciSslSocketInterface app say:

packagingRulesFor: aRuleCollector

"Do Not Reduce anything in this application or subapplications"

aRuleCollector doNotReduceSubApplicationNamed: #SciSslSocketInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterfaceSSL.

which says don't reduce me.  But the packager doesn't listen and reduces it anyway.

I have my own rule that says to include the class named #SciSslX509Certificate.  Again the packager doesn't care and removes the class.  Then, as if to add insult to injury, bitches that there are no implementers of #osX509.

I could add another rule telling the packager to ignore to call to #osX509 but who knows if it will ignore the method call or ignore my rule to ignore the method call.

Also, I don't make a specific call to #osX509 but who knows if something I call calls it and it is really needed.

As part of the save packaging rules there is a list of applications to package.  In my packaging rules, I run that list and tell the packager not to reduce any of them.  The packager doesn't care.

Lou

P.S.  Sorry for the rant but I do feel a little better.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" 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/9df442ad-3c9d-4827-b1b2-e96e53600da5n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com

Hi Joachim,

That is quite possible.  Tomorrow I will try to recreate the packaging from the beginning.

That said, I have managed to get the packager to complete without any errors but and it is a very big BUT, the resultant image is only 3MBs, it should be over 5MBs and gives a walkback when I run it.  It seems to be missing pool dictionaries and classes.

Lou

On Friday, May 7, 2021 at 3:45:05 PM UTC-4 [hidden email] wrote:

Louis,

not that I actually know what I am talking about, but is it possible that your packaging instructions were created in an older VAST version (9.1 or such) and are not up to date?

I ask because I seem to remember having "strange" effects with an unfinished migration of my PackagingRules for Kontolino a few releases ago...

maybe this helps. likely not.

Joachim

[hidden email] schrieb am Freitag, 7. Mai 2021 um 17:03:21 UTC+2:

Hi Louis, 

I don't know what is going on with your packaging, but I cannot reproduce it. See attached screenshots. I also have SciSslSocketInterface in the list of my packaged apps and everything seems correct: I see no reported problem and the method osX509 is indeed included. 

Maybe you can go to your image contents, go to that method and see what is the rule that is reducing it. Let me know if you need help with this step. 

Best,

Mariano

On Fri, May 7, 2021 at 11:40 AM Louis LaBrunda <[hidden email]> wrote:

Hi All,

I'm still fighting with packaging my Raspberry/Seaside program on V9.2.2.  I'm sure I will get it done but I keep hitting things that drive me nuts.  For example the packager complains:

SciSslContext>>#certificate: - No implementors of #osX509

There are no implementors of #osX509 included in the packaged image.

well #osX509 is a method of #SciSslX509Certificate which is a class in #SciSslSocketInterface.  The packaging rules in the #SciSslSocketInterface app say:

packagingRulesFor: aRuleCollector

"Do Not Reduce anything in this application or subapplications"

aRuleCollector doNotReduceSubApplicationNamed: #SciSslSocketInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterfaceSSL.

which says don't reduce me.  But the packager doesn't listen and reduces it anyway.

I have my own rule that says to include the class named #SciSslX509Certificate.  Again the packager doesn't care and removes the class.  Then, as if to add insult to injury, bitches that there are no implementers of #osX509.

I could add another rule telling the packager to ignore to call to #osX509 but who knows if it will ignore the method call or ignore my rule to ignore the method call.

Also, I don't make a specific call to #osX509 but who knows if something I call calls it and it is really needed.

As part of the save packaging rules there is a list of applications to package.  In my packaging rules, I run that list and tell the packager not to reduce any of them.  The packager doesn't care.

Lou

P.S.  Sorry for the rant but I do feel a little better.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" 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/9df442ad-3c9d-4827-b1b2-e96e53600da5n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com

Hi All,

I have tried everything I can think of, clean image, loading just what is needed into the UNIX image, manually packaging, following the Seaside Traffic Light example, everything.  Every time the packager goes to completion without any errors.  But it produces a small 3MB image compared to my last version of the program which was 5.2MBs.

The new image throws a walkback because of a bug in: 

AbtMRIManager>registerStringsForApp:

That doesn't handle getting a nil from #findRequest: properly.  #findRequest: returning nil is probably because of whatever is missing from the image.  I fixed the bug, in the hope that things would go farther and help me learn what is missing.  The program now exits with a return code of 60 and no walkback.

I think the code is trying to set up the NLS stuff.  I'm sure it is all fine from the point of view of having all the NLS files in the right place and the .ini file pointing to them because the 5.2MB image works just fine.

I'm guessing that the saving of the packaged image goes wrong somehow because of the new code I have added to the program.  This new code accesses a web site to get the local weather, specifically the probability of rain for today.  I use the STON... stuff to parse it.  Seaside is know to be difficult to package.  The code to access web sites uses support packages that can also be difficult to package.

At this point I would love a circumvention, like building the UNIX image, saving it and using the (large) saved image.  I tried that but as expected it didn't work.  I expect something has to be done to it to get it to start with the right Seaside class.  This is normally set up with the packager.  Does anyone have any idea how that is done?

Lou

On Friday, May 7, 2021 at 5:34:29 PM UTC-4 Louis LaBrunda wrote:

Hi Joachim,

That is quite possible.  Tomorrow I will try to recreate the packaging from the beginning.

That said, I have managed to get the packager to complete without any errors but and it is a very big BUT, the resultant image is only 3MBs, it should be over 5MBs and gives a walkback when I run it.  It seems to be missing pool dictionaries and classes.

Lou

On Friday, May 7, 2021 at 3:45:05 PM UTC-4 [hidden email] wrote:

Louis,

not that I actually know what I am talking about, but is it possible that your packaging instructions were created in an older VAST version (9.1 or such) and are not up to date?

I ask because I seem to remember having "strange" effects with an unfinished migration of my PackagingRules for Kontolino a few releases ago...

maybe this helps. likely not.

Joachim

[hidden email] schrieb am Freitag, 7. Mai 2021 um 17:03:21 UTC+2:

Hi Louis, 

I don't know what is going on with your packaging, but I cannot reproduce it. See attached screenshots. I also have SciSslSocketInterface in the list of my packaged apps and everything seems correct: I see no reported problem and the method osX509 is indeed included. 

Maybe you can go to your image contents, go to that method and see what is the rule that is reducing it. Let me know if you need help with this step. 

Best,

Mariano

On Fri, May 7, 2021 at 11:40 AM Louis LaBrunda <[hidden email]> wrote:

Hi All,

I'm still fighting with packaging my Raspberry/Seaside program on V9.2.2.  I'm sure I will get it done but I keep hitting things that drive me nuts.  For example the packager complains:

SciSslContext>>#certificate: - No implementors of #osX509

There are no implementors of #osX509 included in the packaged image.

well #osX509 is a method of #SciSslX509Certificate which is a class in #SciSslSocketInterface.  The packaging rules in the #SciSslSocketInterface app say:

packagingRulesFor: aRuleCollector

"Do Not Reduce anything in this application or subapplications"

aRuleCollector doNotReduceSubApplicationNamed: #SciSslSocketInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterfaceSSL.

which says don't reduce me.  But the packager doesn't listen and reduces it anyway.

I have my own rule that says to include the class named #SciSslX509Certificate.  Again the packager doesn't care and removes the class.  Then, as if to add insult to injury, bitches that there are no implementers of #osX509.

I could add another rule telling the packager to ignore to call to #osX509 but who knows if it will ignore the method call or ignore my rule to ignore the method call.

Also, I don't make a specific call to #osX509 but who knows if something I call calls it and it is really needed.

As part of the save packaging rules there is a list of applications to package.  In my packaging rules, I run that list and tell the packager not to reduce any of them.  The packager doesn't care.

Lou

P.S.  Sorry for the rant but I do feel a little better.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" 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/9df442ad-3c9d-4827-b1b2-e96e53600da5n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" 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/9ea0897b-8ccc-4df1-a0db-3149b2ea7fe7n%40googlegroups.com.

Hi Louis, 

I recommend you to send an email to VAST support. Please send:

1) Your latest packaging instruction class fileout

2) The latest walkback you are currently getting 

3) If you can, a manager.dat + dev image so that we can trigger the packager ourselves

4) Please confirm which VAST version and build number you are using to package 

That way, we can allocate more engineering time and investigate. 

Best, 

On Mon, May 10, 2021 at 4:12 PM Louis LaBrunda <[hidden email]> wrote:

Hi All,

I have tried everything I can think of, clean image, loading just what is needed into the UNIX image, manually packaging, following the Seaside Traffic Light example, everything.  Every time the packager goes to completion without any errors.  But it produces a small 3MB image compared to my last version of the program which was 5.2MBs.

The new image throws a walkback because of a bug in: 

AbtMRIManager>registerStringsForApp:

That doesn't handle getting a nil from #findRequest: properly.  #findRequest: returning nil is probably because of whatever is missing from the image.  I fixed the bug, in the hope that things would go farther and help me learn what is missing.  The program now exits with a return code of 60 and no walkback.

I think the code is trying to set up the NLS stuff.  I'm sure it is all fine from the point of view of having all the NLS files in the right place and the .ini file pointing to them because the 5.2MB image works just fine.

I'm guessing that the saving of the packaged image goes wrong somehow because of the new code I have added to the program.  This new code accesses a web site to get the local weather, specifically the probability of rain for today.  I use the STON... stuff to parse it.  Seaside is know to be difficult to package.  The code to access web sites uses support packages that can also be difficult to package.

At this point I would love a circumvention, like building the UNIX image, saving it and using the (large) saved image.  I tried that but as expected it didn't work.  I expect something has to be done to it to get it to start with the right Seaside class.  This is normally set up with the packager.  Does anyone have any idea how that is done?

Lou

On Friday, May 7, 2021 at 5:34:29 PM UTC-4 Louis LaBrunda wrote:

Hi Joachim,

That is quite possible.  Tomorrow I will try to recreate the packaging from the beginning.

That said, I have managed to get the packager to complete without any errors but and it is a very big BUT, the resultant image is only 3MBs, it should be over 5MBs and gives a walkback when I run it.  It seems to be missing pool dictionaries and classes.

Lou

On Friday, May 7, 2021 at 3:45:05 PM UTC-4 [hidden email] wrote:

Louis,

not that I actually know what I am talking about, but is it possible that your packaging instructions were created in an older VAST version (9.1 or such) and are not up to date?

I ask because I seem to remember having "strange" effects with an unfinished migration of my PackagingRules for Kontolino a few releases ago...

maybe this helps. likely not.

Joachim

[hidden email] schrieb am Freitag, 7. Mai 2021 um 17:03:21 UTC+2:

Hi Louis, 

I don't know what is going on with your packaging, but I cannot reproduce it. See attached screenshots. I also have SciSslSocketInterface in the list of my packaged apps and everything seems correct: I see no reported problem and the method osX509 is indeed included. 

Maybe you can go to your image contents, go to that method and see what is the rule that is reducing it. Let me know if you need help with this step. 

Best,

Mariano

On Fri, May 7, 2021 at 11:40 AM Louis LaBrunda <[hidden email]> wrote:

Hi All,

I'm still fighting with packaging my Raspberry/Seaside program on V9.2.2.  I'm sure I will get it done but I keep hitting things that drive me nuts.  For example the packager complains:

SciSslContext>>#certificate: - No implementors of #osX509

There are no implementors of #osX509 included in the packaged image.

well #osX509 is a method of #SciSslX509Certificate which is a class in #SciSslSocketInterface.  The packaging rules in the #SciSslSocketInterface app say:

packagingRulesFor: aRuleCollector

"Do Not Reduce anything in this application or subapplications"

aRuleCollector doNotReduceSubApplicationNamed: #SciSslSocketInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterfaceSSL.

which says don't reduce me.  But the packager doesn't listen and reduces it anyway.

I have my own rule that says to include the class named #SciSslX509Certificate.  Again the packager doesn't care and removes the class.  Then, as if to add insult to injury, bitches that there are no implementers of #osX509.

I could add another rule telling the packager to ignore to call to #osX509 but who knows if it will ignore the method call or ignore my rule to ignore the method call.

Also, I don't make a specific call to #osX509 but who knows if something I call calls it and it is really needed.

As part of the save packaging rules there is a list of applications to package.  In my packaging rules, I run that list and tell the packager not to reduce any of them.  The packager doesn't care.

Lou

P.S.  Sorry for the rant but I do feel a little better.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" 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/9df442ad-3c9d-4827-b1b2-e96e53600da5n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" 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/9ea0897b-8ccc-4df1-a0db-3149b2ea7fe7n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com

Hi Mariano,

I was in the middle of doing just that when I saw this post.  I have added to the files I'm suppling, thanks to your suggestion.

Lou

On Wednesday, May 12, 2021 at 12:58:02 PM UTC-4 [hidden email] wrote:

Hi Louis, 

I recommend you to send an email to VAST support. Please send:

1) Your latest packaging instruction class fileout

2) The latest walkback you are currently getting 

3) If you can, a manager.dat + dev image so that we can trigger the packager ourselves

4) Please confirm which VAST version and build number you are using to package 

That way, we can allocate more engineering time and investigate. 

Best, 

On Mon, May 10, 2021 at 4:12 PM Louis LaBrunda <[hidden email]> wrote:

Hi All,

I have tried everything I can think of, clean image, loading just what is needed into the UNIX image, manually packaging, following the Seaside Traffic Light example, everything.  Every time the packager goes to completion without any errors.  But it produces a small 3MB image compared to my last version of the program which was 5.2MBs.

The new image throws a walkback because of a bug in: 

AbtMRIManager>registerStringsForApp:

That doesn't handle getting a nil from #findRequest: properly.  #findRequest: returning nil is probably because of whatever is missing from the image.  I fixed the bug, in the hope that things would go farther and help me learn what is missing.  The program now exits with a return code of 60 and no walkback.

I think the code is trying to set up the NLS stuff.  I'm sure it is all fine from the point of view of having all the NLS files in the right place and the .ini file pointing to them because the 5.2MB image works just fine.

I'm guessing that the saving of the packaged image goes wrong somehow because of the new code I have added to the program.  This new code accesses a web site to get the local weather, specifically the probability of rain for today.  I use the STON... stuff to parse it.  Seaside is know to be difficult to package.  The code to access web sites uses support packages that can also be difficult to package.

At this point I would love a circumvention, like building the UNIX image, saving it and using the (large) saved image.  I tried that but as expected it didn't work.  I expect something has to be done to it to get it to start with the right Seaside class.  This is normally set up with the packager.  Does anyone have any idea how that is done?

Lou

On Friday, May 7, 2021 at 5:34:29 PM UTC-4 Louis LaBrunda wrote:

Hi Joachim,

That is quite possible.  Tomorrow I will try to recreate the packaging from the beginning.

That said, I have managed to get the packager to complete without any errors but and it is a very big BUT, the resultant image is only 3MBs, it should be over 5MBs and gives a walkback when I run it.  It seems to be missing pool dictionaries and classes.

Lou

On Friday, May 7, 2021 at 3:45:05 PM UTC-4 [hidden email] wrote:

Louis,

not that I actually know what I am talking about, but is it possible that your packaging instructions were created in an older VAST version (9.1 or such) and are not up to date?

I ask because I seem to remember having "strange" effects with an unfinished migration of my PackagingRules for Kontolino a few releases ago...

maybe this helps. likely not.

Joachim

[hidden email] schrieb am Freitag, 7. Mai 2021 um 17:03:21 UTC+2:

Hi Louis, 

I don't know what is going on with your packaging, but I cannot reproduce it. See attached screenshots. I also have SciSslSocketInterface in the list of my packaged apps and everything seems correct: I see no reported problem and the method osX509 is indeed included. 

Maybe you can go to your image contents, go to that method and see what is the rule that is reducing it. Let me know if you need help with this step. 

Best,

Mariano

On Fri, May 7, 2021 at 11:40 AM Louis LaBrunda <[hidden email]> wrote:

Hi All,

I'm still fighting with packaging my Raspberry/Seaside program on V9.2.2.  I'm sure I will get it done but I keep hitting things that drive me nuts.  For example the packager complains:

SciSslContext>>#certificate: - No implementors of #osX509

There are no implementors of #osX509 included in the packaged image.

well #osX509 is a method of #SciSslX509Certificate which is a class in #SciSslSocketInterface.  The packaging rules in the #SciSslSocketInterface app say:

packagingRulesFor: aRuleCollector

"Do Not Reduce anything in this application or subapplications"

aRuleCollector doNotReduceSubApplicationNamed: #SciSslSocketInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterface.

aRuleCollector doNotReduceSubApplicationNamed: #SciSslOpenSSLInterfaceSSL.

which says don't reduce me.  But the packager doesn't listen and reduces it anyway.

I have my own rule that says to include the class named #SciSslX509Certificate.  Again the packager doesn't care and removes the class.  Then, as if to add insult to injury, bitches that there are no implementers of #osX509.

I could add another rule telling the packager to ignore to call to #osX509 but who knows if it will ignore the method call or ignore my rule to ignore the method call.

Also, I don't make a specific call to #osX509 but who knows if something I call calls it and it is really needed.

As part of the save packaging rules there is a list of applications to package.  In my packaging rules, I run that list and tell the packager not to reduce any of them.  The packager doesn't care.

Lou

P.S.  Sorry for the rant but I do feel a little better.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" 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/9df442ad-3c9d-4827-b1b2-e96e53600da5n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" 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/9ea0897b-8ccc-4df1-a0db-3149b2ea7fe7n%40googlegroups.com.

--

Mariano Martinez Peck Senior Software Engineer  [hidden email]  @MartinezPeck  /mariano-martinez-peck  instantiations.com