[Cuis-dev] Morphic glitches out/hangs when adding faulty code to drawOn method on morphs that step

Alan Dao alan.n.dao at gmail.com
Sat Dec 17 23:20:09 PST 2022


Hey Juan,

So for a mistake on my end, I didn't realize updates from Git had to be
explicitly installed.. after installing the updates and doing your
test-case, I can see there's no glitches.

Unfortunately, my morph, BebopTransform, still hangs Morphic when I do
the below test case. If you have spare time, I've attached my package,
named Bebop, for you to reproduce. I apologize in advance if my morph is
not implemented correctly.

- Repos are pulled
- Started fresh Cuis.
- Installed updates.
- Loaded package 'Bebop'
- World / New morph... / Vector Graphics / BebopTransform
- In BebopTransformGraphLine >> drawOn:, add "aCanvas drawString: 1.0 at:
-13 @ 58 font: nil color: Color brown."

It looks like Morphic only hangs when we create BebopTransform and then
modify drawOn: later on.

Best,
Alan

On Fri, Dec 16, 2022 at 6:00 AM Juan Vuletich <juan at cuis.st> wrote:

> Hi Alan,
>
> - Repos are pulled
> - Started fresh Cuis.
> - Installed updates.
> - Changed string to Float in Sample09Clock >> drawOn:
> - added stepTime ^17
> - World / New morph... / Vector Graphics / Sample09Clock
>
> I just get a "faulty morph" (red square with yellow borders and cross). No
> debuggers. No glitches. Everything works as expected.
>
> If you can reliably reproduce the problem, please provided detailed enough
> steps so I can reproduce it.
>
> Thanks,
>
> On 12/16/2022 1:35 AM, Alan Dao via Cuis-dev wrote:
>
> Hi Juan,
>
> Thanks a bunch for looking into this! I've tested on Sample09Clock and the
> error handling works properly now. Unfortunately, I tried testing on my
> 60Hz step morph and still see issues. The image doesn't hang and I
> eventually see a debugger, but the Morphic rendering of the whole world
> breaks for the rest of the image runtime. I tested this in Sample09Clock
> and can reproduce it there. To reproduce, put the previous faulty code into
> the drawOn method add this method to Sample09Clock instance:
>
> ```
> stepTime
>     ^ 17
> ```
>
> Then create the clock.
>
> Looks like the fix is prone to race conditions :(
>
> Alan
>
> On Thu, Dec 15, 2022 at 2:54 PM Juan Vuletich <juan at cuis.st> wrote:
>
>> Hi All,
>>
>> I finally could reproduce and understand the problem. Fix is now at
>> GitHub.
>>
>> Thanks for reporting!
>>
>> Cheers,
>>
>> On 12/15/2022 9:50 AM, Juan Vuletich via Cuis-dev wrote:
>>
>> Hi Folks,
>>
>> I guess I need more precise steps to reproduce.
>>
>> I just fired a fresh Cuis, from an updated repo. Just installed updates
>> and opened a Sample09Clock. It works ok. Then I open a browser on it (from
>> the halo), went to the drawOn: method and added your line Alan. I get a
>> debugger "Instances of SmallFloat64 are not indexable". I close the
>> debugger and see the clock displayed now as a red box with yellow borders
>> and cross. Image is responsive. I go to the browser and correct the method.
>> Then I do World / Debug / Start drawing all again. The clock is correctly
>> drawn again.
>>
>> In short, I see the expected behavior. This means I need enough detail,
>> so I can reproduce the problem.
>>
>> Thanks,
>>
>>
>> On 12/15/2022 6:28 AM, Hilaire Fernandes via Cuis-dev wrote:
>>
>> Hi Alan,
>>
>> Thanks to report! I confirm the issue, even with non stepping morph. It
>> should not behave like that.
>>
>> The expected behavior with faulty code in a #drawOn: method is a broken
>> morph rendered as a red rectangle with yellow diagonals and stepping set in
>> pause, to avoid recurring debugger to pop up I guess. By the way there is
>> the WorldMenu>Debug  and Morph halo menus to restart stepping and rendering
>> once the broken code is fixed.
>>
>> It seems the Morph is not detected as broken, and rendering is tried
>> again and again.
>>
>> Juan recently introduced the HybridCanvas to speed up graphics rendering,
>> may be it is related, and a fix should come. I can't help more, sorry.
>>
>> Hilaire
>> Le 15/12/2022 à 07:43, Alan Dao via Cuis-dev a écrit :
>>
>> I know that the code I've put in is inherently flawed, but my development
>> process involves experimenting a lot and not always knowing what I'm doing.
>> Is there something I'm missing when it comes to not having mistakes break
>> Morphic? Any advice would be appreciated.
>>
>> --
>> GNU Dr. Geohttp://drgeo.euhttp://blog.drgeo.eu
>>
>>
>>
>> --
>> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>>
>>
>>
>> --
>> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>>
>>
>
> --
> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20221217/80895c21/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bebop.pck.st
Type: application/octet-stream
Size: 6335 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20221217/80895c21/attachment.obj>


More information about the Cuis-dev mailing list