Mantis - Squeak
Viewing Issue Advanced Details
5285 Morphic major sometimes 10-24-06 10:08 12-04-08 22:33
closed 3.10  
none 3.10  
0005285: [Fix] In 7066 #rootInPasteUp is called but unimplemented.
For this one.
In a workspace type rootInPasteUp.
select it
from the popup menu request find senders
(you'll get TileMorph>>mouseMove:)
request implementors (you''ll get there aren't any)

get an object get a script for it
try to moving the mouse on a tile
sometimes you will get a series of debug boxes
This can be stopped with the user interupt key.

The method was implemented in 7022 (and maybe later I was just sampling old images until I found it)

There were also five senders instead of just one so I suspect it got removed when the other four senders did.

I've uploaded Morph>>rootInPasteUp.
This seemed to cure the problem.

This should be fixed before we release this to someone who might use etoys. Because its pretty likely to be stumbled across just as I did.

[OT] The rapid succession of debuggers is probably another bug. I'll wait to see if I stumble upon it in a solid fashion before reporting it to mantis.
child of 0004544closed  In 7054 there are 194 unimplementedCalls including some that look like they might be important [^] (366 bytes) 10-24-06 10:09
 UnimpFixForM5285-wiz.1.cs [^] (1,525 bytes) 09-23-07 04:22

09-20-07 03:42   
Reminder sent to: edgardec

Hi Edgar,

Here's another unimplemented call fix up that got missed.

I looked at 7143 and the problem still exists.

Cheers --Jer
09-23-07 04:27   
Hi Edgar,

UnimpFixForM5285-wiz.1.cs is the promised changeset.

From the preamble:

Change Set: UnimpFixForM5285-wiz
Date: 22 September 2007
Author: (wiz) Jerome Peace

wiz 9/22/2007 23:59

removes #rootInPasteUp unimplemented call in TileMorph this is taken directly from 3.8.1 only the backArrows were changed to protect the innocent. This is just two methods from 6564-0383smartTileMorph5-tak
(changeset in 3.8.1).

Both are needed to remove the call w/o creating more bugs.

I did not look more deeply into the cs to see if other methods needed to be harvested.
It looks like Marcus did harvest some but obviously missed some as well.
10-10-07 10:07   
This now is 7156UnimpFixForM5285-wiz.cs and was in updates for 3.10
Thanks Jerome !
12-01-08 23:28   
Edgar refers to update 7156 but I think he must mean [^]

however this loads EToys-edc.27.mcz and the changes between this version and EToys-edc.26.mcz don't appear to have any relevance to this issue, it certainly is not the content in the attached files.
12-04-08 01:54   
Hi Ken,

Thanks for your caution.

I checked my copy of 3.10.2

There are now no senders of root in pasteup.
The timestamp for TileMorph>>mouseMove: is the one in the
changeset loaded above.
I didn't actually check the other method in the change set but it seems that the changeset is in the image.

I am curious about Edgar's mysterious ways of loading it in without leaving an obvious audit trail.

Monticello is mysterious to me. And maybe it holds an explaination.

Anyway, thanks again for your concern.

This one is probably ok to reclose.

Yours in curiosity and service, --Jerome Peace
12-04-08 22:08   
OK, I was wrong. I added the earlier not and set this aside in frustration. I had planned to track down when the method was changed at some point. wiz's note triggered me to do that today. As he says the changes are in 3.10.2. I then started using Keith Hodges handy Dual Change Log for Monticello to manually bisect the EToys package history and track down in which version these changes occur. I quickly got confused.

It turns out that my memory is horrible (what a surprise): [^]

The Dual Change Log shows orphaned versions in the list (versions not installed in the current image), although in bold. I didn't realize what bold meant. It turns out that EToys-edc.27 is an ancestor of EToys-bf.24. I was comparing EToys-edc.27 to EToys-edc.26, which was conceptually wrong. When I do the proper comparison it matches up to the correct changed.
12-04-08 22:08   
Harvested as update 7155 and released with Squeak 3.10.
12-04-08 22:33   
oops, changed 'assigned to' to wiz so he would get the credit in the Change Log but didn't mean for the issue to be reopened.