VA9.1 packaging bug: SstEnhancedSelect>>packagingRulesFor:

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

VA9.1 packaging bug: SstEnhancedSelect>>packagingRulesFor:

Steven LaFavor
All of the methods listed are implemented as self subclassResponsibility
EXCEPT the last one:

excludeMethod: #timeout: inClassNamed: #SstSocketDemultiplexor

You can't remove that one since it is the setter for the instance variable. 
The subclass SstWinsockSocketDemultiplexor>>initialize goes boom because the method was removed in the packaging process.

*Steve*

--
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 post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: VA9.1 packaging bug: SstEnhancedSelect>>packagingRulesFor:

Seth Berman
Thank you Steven,

We are aware of this issue and it will be fixed in our first patch release which is scheduled for September.
Removing the #timeout: exclusion rule is what we are doing.

The notes from the case on this issue says:
Some changes made in 9.1 (probably was #63500) , removed #timeout and #timeout: methods from SstSocketDemulitplexor (WIN and UNIX ) and now inherits implementations from SstEnhancedSelect.  SstEnhancedSelect has packaging rules that exclude the timeout: method as it used to be a 'implemented by subclass' stub, and the subclass defined it and thus included it.  We need to remove the exclude #timeout: rule from SstEnhancedSelect since it is now implemented there.

Thanks for reporting

-- Seth

On Thursday, August 30, 2018 at 6:43:52 PM UTC-4, Steven LaFavor wrote:
All of the methods listed are implemented as self subclassResponsibility
EXCEPT the last one:

excludeMethod: #timeout: inClassNamed: #SstSocketDemultiplexor

You can't remove that one since it is the setter for the instance variable. 
The subclass SstWinsockSocketDemultiplexor>>initialize goes boom because the method was removed in the packaging process.

*Steve*

--
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 post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: VA9.1 packaging bug: SstEnhancedSelect>>packagingRulesFor:

jtuchel
In reply to this post by Steven LaFavor
Steven,


in case you are not sure how to fix this (I had this problem), take a look at Norbert's instructions here: https://groups.google.com/d/msg/va-smalltalk/Qcgqhzywyv0/tdgO58ZjAQAJ


Joachim

Am Freitag, 31. August 2018 00:43:52 UTC+2 schrieb Steven LaFavor:
All of the methods listed are implemented as self subclassResponsibility
EXCEPT the last one:

excludeMethod: #timeout: inClassNamed: #SstSocketDemultiplexor

You can't remove that one since it is the setter for the instance variable. 
The subclass SstWinsockSocketDemultiplexor>>initialize goes boom because the method was removed in the packaging process.

*Steve*

--
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 post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: VA9.1 packaging bug: SstEnhancedSelect>>packagingRulesFor:

Steven LaFavor

I had not seen this in the groups before.  I had assumed that the correction was to just remove the line in the SstEnhancedSelect>>packagingRulesFor: method.

If one does not want to modify the existing Instantiations code (perhaps to keep the image more pristine for future updates), one could always add an extension in your own image (perhaps in a FutureInstantiationsFixesApp) and extend theSstWinsockSocketDemultiplexor class.  Then add SstWinsockSocketDemultiplexor>>timeout: to have the same code as SstSocketDemultiplexor>>timeout: and voila!  Then once you get the fixpak from Instantiations, one could just run the check for "methods that are the same as the inherited ones" (which for some reason I know that I have seen, but cannot remember if this is in the Refactoring Browser or the Envy QA code), and safely remove it.

*Steve*

--
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 post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: VA9.1 packaging bug: SstEnhancedSelect>>packagingRulesFor:

jtuchel
Steven,

Am Freitag, 31. August 2018 17:47:20 UTC+2 schrieb Steven LaFavor:

I had not seen this in the groups before.  I had assumed that the correction was to just remove the line in the SstEnhancedSelect>>packagingRulesFor: method.

well, it is. But for some reason I couldn't decode the posts given about the error at that time ;-)

If one does not want to modify the existing Instantiations code (perhaps to keep the image more pristine for future updates), one could always add an extension in your own image (perhaps in a FutureInstantiationsFixesApp) and extend theSstWinsockSocketDemultiplexor class.  Then add SstWinsockSocketDemultiplexor>>timeout: to have the same code as SstSocketDemultiplexor>>timeout: and voila!  Then once you get the fixpak from Instantiations, one could just run the check for "methods that are the same as the inherited ones" (which for some reason I know that I have seen, but cannot remember if this is in the Refactoring Browser or the Envy QA code), and safely remove it.

Hmm. isn't that also a change to product code? I know this kind of discussion from several projects and I must say I rather try to integrate the known fixes from Instantiations than go another route. The reason is simple: when you do the next migration, you'll spend two hours or so in a changes Browser anyways, trying to figure out if a change that has been made to product code is still relevant and needs to be integrated in the new version. The picture you see when you apply a suggested (but not yet shipped) fix from Instantiations is easier to understand than some other fix at another place for the very same problem. Changes that clearly have been fixed teh same way we did mak eme much mroe confident than fixes that look as if they attack the same problem that I have solved differently, because there are severa questions to answer during migration:
  • do these two code changes reeally solve the same problem?
  • Which one is the better fix, takes more side effects into account?
  • does our application rely on some side effect of the fix that is not prvided by the other one? Will my applicatio break if I use "their" fix? If so, isn't it better to fix my App than keep that old fix of mine?
 This thought process is much to expensive for "just a migration" and is better spent in new features. Migrations between VAST versions are a strange beast for project management. No immediate outcome (the application will just work like before) but a bunch of risks and some cost (you spend a day or two for migrating rather than building new features). The positive side effects of a migration (new features, long-standing bugs are gone) will eventually pay back (I already love 9.1 for its GRVastUtf8Codec and 64 bits VM for lInux alone), but often there is no immediate gain.


Joachim


*Steve*

--
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 post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: VA9.1 packaging bug: SstEnhancedSelect>>packagingRulesFor:

Steven LaFavor
Upon further reflection, it makes more sense to just correct the packaging rule since technically all that does is lets the method that Instantiations has already coded to be used correctly.

I sometimes enjoy the esoteric discussions along these lines and there was a consultant on-site who was recently let go that I enjoyed having these sorts of discussions with.  Most of the time, the pragmatic choice is best, but figuring out what the "edges" of those discussions are can lead to self -discoveries....

On Saturday, September 1, 2018 at 12:09:31 AM UTC-5, Joachim Tuchel wrote:
Steven,

Am Freitag, 31. August 2018 17:47:20 UTC+2 schrieb Steven LaFavor:

I had not seen this in the groups before.  I had assumed that the correction was to just remove the line in the SstEnhancedSelect>>packagingRulesFor: method.

well, it is. But for some reason I couldn't decode the posts given about the error at that time ;-)

If one does not want to modify the existing Instantiations code (perhaps to keep the image more pristine for future updates), one could always add an extension in your own image (perhaps in a FutureInstantiationsFixesApp) and extend theSstWinsockSocketDemultiplexor class.  Then add SstWinsockSocketDemultiplexor>>timeout: to have the same code as SstSocketDemultiplexor>>timeout: and voila!  Then once you get the fixpak from Instantiations, one could just run the check for "methods that are the same as the inherited ones" (which for some reason I know that I have seen, but cannot remember if this is in the Refactoring Browser or the Envy QA code), and safely remove it.

Hmm. isn't that also a change to product code? I know this kind of discussion from several projects and I must say I rather try to integrate the known fixes from Instantiations than go another route. The reason is simple: when you do the next migration, you'll spend two hours or so in a changes Browser anyways, trying to figure out if a change that has been made to product code is still relevant and needs to be integrated in the new version. The picture you see when you apply a suggested (but not yet shipped) fix from Instantiations is easier to understand than some other fix at another place for the very same problem. Changes that clearly have been fixed teh same way we did mak eme much mroe confident than fixes that look as if they attack the same problem that I have solved differently, because there are severa questions to answer during migration:
  • do these two code changes reeally solve the same problem?
  • Which one is the better fix, takes more side effects into account?
  • does our application rely on some side effect of the fix that is not prvided by the other one? Will my applicatio break if I use "their" fix? If so, isn't it better to fix my App than keep that old fix of mine?
 This thought process is much too expensive for "just a migration" and is better spent in new features. Migrations between VAST versions are a strange beast for project management. No immediate outcome (the application will just work like before) but a bunch of risks and some cost (you spend a day or two for migrating rather than building new features). The positive side effects of a migration (new features, long-standing bugs are gone) will eventually pay back (I already love 9.1 for its GRVastUtf8Codec and 64 bits VM for lInux alone), but often there is no immediate gain.


Considering that the migration that I am doing is part of a larger "get ready for Windows 10" thing that is going on at my company, this is just one thing in a long line of stuff that needs correcting to make that all happen.  Mostly stuff that our application communicates/integrates with as opposed to the app directly, but that is usually the case with most apps.   

*Steve*

Joachim

--
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 post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: VA9.1 packaging bug: SstEnhancedSelect>>packagingRulesFor:

jtuchel
In reply to this post by jtuchel
Steven,

not sure what you want to say by "esoteric discussions"... in German, this would mean you think my arguments are completele nonsense, unless you wear an aluminium hat and / or believe in an almighty Spaghetti monster... ;-)))

Of course that's alright with me, because we all try to do things the most effective way we can and often there is no objectively correct way.

In the end, if you go for the fix of the Packaging Rules, I am right anyways, no matter what the reasons are ;-)

Joachim


Am Samstag, 1. September 2018 07:09:31 UTC+2 schrieb Joachim Tuchel:
Steven,

Am Freitag, 31. August 2018 17:47:20 UTC+2 schrieb Steven LaFavor:

I had not seen this in the groups before.  I had assumed that the correction was to just remove the line in the SstEnhancedSelect>>packagingRulesFor: method.

well, it is. But for some reason I couldn't decode the posts given about the error at that time ;-)

If one does not want to modify the existing Instantiations code (perhaps to keep the image more pristine for future updates), one could always add an extension in your own image (perhaps in a FutureInstantiationsFixesApp) and extend theSstWinsockSocketDemultiplexor class.  Then add SstWinsockSocketDemultiplexor>>timeout: to have the same code as SstSocketDemultiplexor>>timeout: and voila!  Then once you get the fixpak from Instantiations, one could just run the check for "methods that are the same as the inherited ones" (which for some reason I know that I have seen, but cannot remember if this is in the Refactoring Browser or the Envy QA code), and safely remove it.

Hmm. isn't that also a change to product code? I know this kind of discussion from several projects and I must say I rather try to integrate the known fixes from Instantiations than go another route. The reason is simple: when you do the next migration, you'll spend two hours or so in a changes Browser anyways, trying to figure out if a change that has been made to product code is still relevant and needs to be integrated in the new version. The picture you see when you apply a suggested (but not yet shipped) fix from Instantiations is easier to understand than some other fix at another place for the very same problem. Changes that clearly have been fixed teh same way we did mak eme much mroe confident than fixes that look as if they attack the same problem that I have solved differently, because there are severa questions to answer during migration:
  • do these two code changes reeally solve the same problem?
  • Which one is the better fix, takes more side effects into account?
  • does our application rely on some side effect of the fix that is not prvided by the other one? Will my applicatio break if I use "their" fix? If so, isn't it better to fix my App than keep that old fix of mine?
 This thought process is much too expensive for "just a migration" and is better spent in new features. Migrations between VAST versions are a strange beast for project management. No immediate outcome (the application will just work like before) but a bunch of risks and some cost (you spend a day or two for migrating rather than building new features). The positive side effects of a migration (new features, long-standing bugs are gone) will eventually pay back (I already love 9.1 for its GRVastUtf8Codec and 64 bits VM for lInux alone), but often there is no immediate gain.


Joachim


*Steve*

--
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 post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: VA9.1 packaging bug: SstEnhancedSelect>>packagingRulesFor:

Steven LaFavor

not sure what you want to say by "esoteric discussions"... in German, this would mean you think my arguments are completele nonsense, unless you wear an aluminium hat and / or believe in an almighty Spaghetti monster... ;-)))

This is most DEFINITELY not what I meant.   Even though I enjoy the Pastafarians  :-) 

I was more leaning toward a meaning of discussions/debates where there really is no wrong way to do it, but the minute details of one method vs another can be discussed and disassembled to delve into deeper thought processes....
 
Of course that's alright with me, because we all try to do things the most effective way we can and often there is no objectively correct way.
In the end, if you go for the fix of the Packaging Rules, I am right anyways, no matter what the reasons are ;-)

*Steve* 

 

--
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 post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.