I think I've discovered an error in the later v9 builds

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

I think I've discovered an error in the later v9 builds

Russ Whaley
(Overall, this error does not occur in v8 - even the latest snapshot.1140.  It did not exist in the v9 image from February - I don't know how to tell what build it is.  But the latest Official Distribution for v9 and the latest snapshot.840 - the following error occurs:).

This error appears to be around the transmitTo: within SpPresenterWithModel>>connectPresenters.  I haven't been able to (yet) trace why, but the debug message is in the 2nd 'transform:' below -- erroring saying that 'each' is nil - and doesn't understand the #method2 message.

Here is the scenario:

(aSpTablePresenter(1) transmitTo: aSpTablePresenter(2))
transform: [ :each | ((each #method asOrderedCollection ) sorted: #title ascending ) ].

"transmit aSpTablePresenter(2) to aSpTablePresenter(3)"
(aSpTablePresenter(2) transmitTo: aSpTablePresenter(3))
transform: [ :each | ((each #method2 asOrderedCollection) sorted: #number ascending )].

The UI populates just fine - when I click a row in the first aSpTablePresenter(1) - it fills the 2nd aSpTablePresenter(2), but it looks like the code above attempts to do the 2nd transmitTo: to populate aSpTablePresenter(3) and is trying to do so without data from aSpTablePresenter(2) - there could be a number of reasons for this.  

Behavior-wise, I would prefer that SpTablePresenters default to a first row selected and populate (transmitTo:) to each of their SpTablePresenters in kind (defaulting to first row, then transmitTo: the next tablePresenter).  

Through the Inspector, all three SpTablePresenters have their lists populated - and the UI shows these lists - even after punching through error.

Another observable - when I click on column headers to sort, the transmitTo:'s get called again and also error out - even the first transmitTo:... could be one simple change will correct all these anomalies.

I will try and mock-up a simpler version to share.  Please let me know if you have any questions or items I should specifically include.

Thanks!
Russ

--
Russ Whaley
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: I think I've discovered an error in the later v9 builds

Stéphane Ducasse
Thanks can you enter a bug entry in the spec project?

S. 

On 1 Jul 2020, at 16:58, Russ Whaley <[hidden email]> wrote:

(Overall, this error does not occur in v8 - even the latest snapshot.1140.  It did not exist in the v9 image from February - I don't know how to tell what build it is.  But the latest Official Distribution for v9 and the latest snapshot.840 - the following error occurs:).

This error appears to be around the transmitTo: within SpPresenterWithModel>>connectPresenters.  I haven't been able to (yet) trace why, but the debug message is in the 2nd 'transform:' below -- erroring saying that 'each' is nil - and doesn't understand the #method2 message.

Here is the scenario:

(aSpTablePresenter(1) transmitTo: aSpTablePresenter(2))
transform: [ :each | ((each #method asOrderedCollection ) sorted: #title ascending ) ].

"transmit aSpTablePresenter(2) to aSpTablePresenter(3)"
(aSpTablePresenter(2) transmitTo: aSpTablePresenter(3))
transform: [ :each | ((each #method2 asOrderedCollection) sorted: #number ascending )].

The UI populates just fine - when I click a row in the first aSpTablePresenter(1) - it fills the 2nd aSpTablePresenter(2), but it looks like the code above attempts to do the 2nd transmitTo: to populate aSpTablePresenter(3) and is trying to do so without data from aSpTablePresenter(2) - there could be a number of reasons for this.  

Behavior-wise, I would prefer that SpTablePresenters default to a first row selected and populate (transmitTo:) to each of their SpTablePresenters in kind (defaulting to first row, then transmitTo: the next tablePresenter).  

Through the Inspector, all three SpTablePresenters have their lists populated - and the UI shows these lists - even after punching through error.

Another observable - when I click on column headers to sort, the transmitTo:'s get called again and also error out - even the first transmitTo:... could be one simple change will correct all these anomalies.

I will try and mock-up a simpler version to share.  Please let me know if you have any questions or items I should specifically include.

Thanks!
Russ

--
Russ Whaley
[hidden email]

--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

Reply | Threaded
Open this post in threaded view
|

Re: I think I've discovered an error in the later v9 builds

Russ Whaley
I'd be happy to, but um... I don't know how/where (color me embarrassed...).  Can you point me in the right direction?  I've not submitted a bug report before.

I've created a sample Class, App, & Presenter that demonstrates the error consistently.  I was kindof hoping when I created this example I would find it was something in my code...  I'll attach the fileout here but will also include it in the bug report.  Also attached are the screenshots before and after I clicked on the first row.

Is there a way to tell the build number of an image I'm using?  I'd like to go back to a fresh image of the image I'm using... it has inflated to over 350MB and I'd like to start fresh with an image that doesn't have this defect.  If I can get hold of the build of the image I'm using, that would be great.

Thanks,
Russ


On Wed, Jul 1, 2020 at 1:42 PM Stéphane Ducasse <[hidden email]> wrote:
Thanks can you enter a bug entry in the spec project?

S. 

On 1 Jul 2020, at 16:58, Russ Whaley <[hidden email]> wrote:

(Overall, this error does not occur in v8 - even the latest snapshot.1140.  It did not exist in the v9 image from February - I don't know how to tell what build it is.  But the latest Official Distribution for v9 and the latest snapshot.840 - the following error occurs:).

This error appears to be around the transmitTo: within SpPresenterWithModel>>connectPresenters.  I haven't been able to (yet) trace why, but the debug message is in the 2nd 'transform:' below -- erroring saying that 'each' is nil - and doesn't understand the #method2 message.

Here is the scenario:

(aSpTablePresenter(1) transmitTo: aSpTablePresenter(2))
transform: [ :each | ((each #method asOrderedCollection ) sorted: #title ascending ) ].

"transmit aSpTablePresenter(2) to aSpTablePresenter(3)"
(aSpTablePresenter(2) transmitTo: aSpTablePresenter(3))
transform: [ :each | ((each #method2 asOrderedCollection) sorted: #number ascending )].

The UI populates just fine - when I click a row in the first aSpTablePresenter(1) - it fills the 2nd aSpTablePresenter(2), but it looks like the code above attempts to do the 2nd transmitTo: to populate aSpTablePresenter(3) and is trying to do so without data from aSpTablePresenter(2) - there could be a number of reasons for this.  

Behavior-wise, I would prefer that SpTablePresenters default to a first row selected and populate (transmitTo:) to each of their SpTablePresenters in kind (defaulting to first row, then transmitTo: the next tablePresenter).  

Through the Inspector, all three SpTablePresenters have their lists populated - and the UI shows these lists - even after punching through error.

Another observable - when I click on column headers to sort, the transmitTo:'s get called again and also error out - even the first transmitTo:... could be one simple change will correct all these anomalies.

I will try and mock-up a simpler version to share.  Please let me know if you have any questions or items I should specifically include.

Thanks!
Russ

--
Russ Whaley
[hidden email]

--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France



--
Russ Whaley
[hidden email]

YourExample.st (20K) Download Attachment
2020-07-01 06.17.32 pm.png (197K) Download Attachment
2020-07-01 06.18.20 pm.png (321K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: I think I've discovered an error in the later v9 builds

Ben Coman


On Thu, 2 Jul 2020 at 06:20, Russ Whaley <[hidden email]> wrote:
I'd be happy to, but um... I don't know how/where (color me embarrassed...).  Can you point me in the right direction?  I've not submitted a bug report before.

I would guess Stef means... https://github.com/pharo-spec/Spec/issues 

 
I've created a sample Class, App, & Presenter that demonstrates the error consistently.  I was kindof hoping when I created this example I would find it was something in my code...  I'll attach the fileout here but will also include it in the bug report.  Also attached are the screenshots before and after I clicked on the first row.

Is there a way to tell the build number of an image I'm using?  I'd like to go back to a fresh image of the image I'm using... it has inflated to over 350MB and I'd like to start fresh with an image that doesn't have this defect.  If I can get hold of the build of the image I'm using, that would be great.

You are able to get build info using... World > System > System Reporter 

 

Thanks,
Russ


On Wed, Jul 1, 2020 at 1:42 PM Stéphane Ducasse <[hidden email]> wrote:
Thanks can you enter a bug entry in the spec project?

S. 

On 1 Jul 2020, at 16:58, Russ Whaley <[hidden email]> wrote:

(Overall, this error does not occur in v8 - even the latest snapshot.1140.  It did not exist in the v9 image from February - I don't know how to tell what build it is.  But the latest Official Distribution for v9 and the latest snapshot.840 - the following error occurs:).

This error appears to be around the transmitTo: within SpPresenterWithModel>>connectPresenters.  I haven't been able to (yet) trace why, but the debug message is in the 2nd 'transform:' below -- erroring saying that 'each' is nil - and doesn't understand the #method2 message.

Here is the scenario:

(aSpTablePresenter(1) transmitTo: aSpTablePresenter(2))
transform: [ :each | ((each #method asOrderedCollection ) sorted: #title ascending ) ].

"transmit aSpTablePresenter(2) to aSpTablePresenter(3)"
(aSpTablePresenter(2) transmitTo: aSpTablePresenter(3))
transform: [ :each | ((each #method2 asOrderedCollection) sorted: #number ascending )].

The UI populates just fine - when I click a row in the first aSpTablePresenter(1) - it fills the 2nd aSpTablePresenter(2), but it looks like the code above attempts to do the 2nd transmitTo: to populate aSpTablePresenter(3) and is trying to do so without data from aSpTablePresenter(2) - there could be a number of reasons for this.  

Behavior-wise, I would prefer that SpTablePresenters default to a first row selected and populate (transmitTo:) to each of their SpTablePresenters in kind (defaulting to first row, then transmitTo: the next tablePresenter).  

Through the Inspector, all three SpTablePresenters have their lists populated - and the UI shows these lists - even after punching through error.

Another observable - when I click on column headers to sort, the transmitTo:'s get called again and also error out - even the first transmitTo:... could be one simple change will correct all these anomalies.

I will try and mock-up a simpler version to share.  Please let me know if you have any questions or items I should specifically include.

Thanks!
Russ

--
Russ Whaley
[hidden email]

--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France



--
Russ Whaley
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: I think I've discovered an error in the later v9 builds

Russ Whaley
Thanks Ben, I'll head over to the link tomorrow.  I have done a bit of testing and have been able to isolate in which build the error(s) were introduced.  I have yet to follow through the debugger and determine what's going wrong.  It looks like something was (attempted to be) fixed with the sorting of the columns that jacked up the clicks for the transmitTo: transform: ... but that's just a guess due to the number of errors around sorting and transmitTo:/transform:

I was able to use a Smalltalk method to get what I needed on which build I was using - good to know about the System Reporter as well.

Thanks!
Russ

On Tue, Jul 7, 2020 at 2:18 PM Ben Coman <[hidden email]> wrote:


On Thu, 2 Jul 2020 at 06:20, Russ Whaley <[hidden email]> wrote:
I'd be happy to, but um... I don't know how/where (color me embarrassed...).  Can you point me in the right direction?  I've not submitted a bug report before.

I would guess Stef means... https://github.com/pharo-spec/Spec/issues 

 
I've created a sample Class, App, & Presenter that demonstrates the error consistently.  I was kindof hoping when I created this example I would find it was something in my code...  I'll attach the fileout here but will also include it in the bug report.  Also attached are the screenshots before and after I clicked on the first row.

Is there a way to tell the build number of an image I'm using?  I'd like to go back to a fresh image of the image I'm using... it has inflated to over 350MB and I'd like to start fresh with an image that doesn't have this defect.  If I can get hold of the build of the image I'm using, that would be great.

You are able to get build info using... World > System > System Reporter 

 

Thanks,
Russ


On Wed, Jul 1, 2020 at 1:42 PM Stéphane Ducasse <[hidden email]> wrote:
Thanks can you enter a bug entry in the spec project?

S. 

On 1 Jul 2020, at 16:58, Russ Whaley <[hidden email]> wrote:

(Overall, this error does not occur in v8 - even the latest snapshot.1140.  It did not exist in the v9 image from February - I don't know how to tell what build it is.  But the latest Official Distribution for v9 and the latest snapshot.840 - the following error occurs:).

This error appears to be around the transmitTo: within SpPresenterWithModel>>connectPresenters.  I haven't been able to (yet) trace why, but the debug message is in the 2nd 'transform:' below -- erroring saying that 'each' is nil - and doesn't understand the #method2 message.

Here is the scenario:

(aSpTablePresenter(1) transmitTo: aSpTablePresenter(2))
transform: [ :each | ((each #method asOrderedCollection ) sorted: #title ascending ) ].

"transmit aSpTablePresenter(2) to aSpTablePresenter(3)"
(aSpTablePresenter(2) transmitTo: aSpTablePresenter(3))
transform: [ :each | ((each #method2 asOrderedCollection) sorted: #number ascending )].

The UI populates just fine - when I click a row in the first aSpTablePresenter(1) - it fills the 2nd aSpTablePresenter(2), but it looks like the code above attempts to do the 2nd transmitTo: to populate aSpTablePresenter(3) and is trying to do so without data from aSpTablePresenter(2) - there could be a number of reasons for this.  

Behavior-wise, I would prefer that SpTablePresenters default to a first row selected and populate (transmitTo:) to each of their SpTablePresenters in kind (defaulting to first row, then transmitTo: the next tablePresenter).  

Through the Inspector, all three SpTablePresenters have their lists populated - and the UI shows these lists - even after punching through error.

Another observable - when I click on column headers to sort, the transmitTo:'s get called again and also error out - even the first transmitTo:... could be one simple change will correct all these anomalies.

I will try and mock-up a simpler version to share.  Please let me know if you have any questions or items I should specifically include.

Thanks!
Russ

--
Russ Whaley
[hidden email]

--------------------------------------------
Stéphane Ducasse
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France



--
Russ Whaley
[hidden email]


--
Russ Whaley
[hidden email]