[Cuis-dev] [help] Debugging Morph failures

[Juan Vuletich]

Maybe for some cases, we could improve the situation. At least, errors 
in #drawOn: should never crash the image. Not sure for other methods, 
though. If you post a UserChanges file that results in this behavior, 
I'll try to take a look.

Cheers,

On 08/02/2022 02:55 p.m., Hernan Wilkinson via Cuis-dev wrote:
> Juan is the best one to answer this question (he's on vacation for a 
> couple of weeks).
> It is not easy to debug Morph because of the meta-circularity of it 
> that you already know...
> I know that Juan uses the logs that are saved when an error occurs 
> (that is disabled in CuisUniversity just in case you are using it, 
> there is a preference to enable it).
> It would be great to find a way to break the circularity when doing 
> this kind of thing. For example, if you want to make changes in the 
> debugger, the best way to do it is to subclass it, work in the 
> subclass so if an error occurs the original debugger appears, and when 
> finish push up the changes to the debugger class, but I do not see how 
> to do something similar in Morph... maybe creating a new world with a 
> different hierarchy of morphs that are the one you are working on?... 
> or try to use a "stack of the morph framework" in the same way some 
> people work with a stack of compiler when working with meta-circular 
> languages?...
> I'm sorry I can not provide concrete solutions but just some ideas...
>
> On Tue, Feb 8, 2022 at 1:43 PM Nicolás Papagna Maldonado via Cuis-dev 
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>
>     Aloha folks!
>
>     From time to time It happens to me that, for some reason (an
>     Exception I believe), when I open a Morph I'm developing the image
>     freezes.
>     The cursor usually alternates between the pointer and the clock
>     and stays stuck there.
>
>     Cmd + . usually does not help, and I end up killing the VM from
>     the command line/activity monitor.
>
>     When I reopen the image, I get to restore the changes, and by
>     looking at what was not "committed" I can tell if there is
>     something wrong (but I have to "execute it in my head").
>
>     Is there a better way to debug this kind of situation?
>     I found that putting a halt on a method usually leads to the same
>     situation.
>
>     Best,
>     Nico PM
>     -- 
>     Cuis-dev mailing list
>     Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>     https://lists.cuis.st/mailman/listinfo/cuis-dev
>
>
>
> -- 
> <https://10pines.com/>
>
>
>   Hernán Wilkinson
>
>
>     Software Developer & Coach
>
> Alem 896, Floor 6, Buenos Aires, Argentina
>
> +54 11 6091 3125
>
> @HernanWilkinson
>


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220208/63c5e1cc/attachment-0001.htm>