[Cuis-dev] [DEFECT] De-compling code uses #storeOn:

[Juan Vuletich]

I just added several implementors of #storeOn: . This addresses the 
example you gave. Maybe still others are needed.

Thanks,

On 12/15/2021 12:01 PM, Gerald Klix via Cuis-dev wrote:
>
>
> On 12/15/21 2:17 PM, Juan Vuletich via Cuis-dev wrote:
>> On 12/10/2021 12:22 PM, Gerald Klix via Cuis-dev wrote:
>>> Hi all, Hi Juan,
>>>
>>> There is a defect in de-compiling code.
>>> After de-compiling the resulting method node
>>> is pretty printed. Constants defined with
>>> a back-tick are "printed" by using #storeOn:,
>>> which -- IHMO -- is dangerous as this
>>> example method source proves:
>>>
>>> --- snip ---
>>> boom
>>>     "Decompile me ..."
>>>
>>>     ^ `Smalltalk asDictionary` size
>>> --- snap ---
>>>
>>> The problem got much worse, when #linesOfCode
>>> was based on #decompiledString.
>>> Just selecting a package containing such a
>>> method in the package browser
>>> will cause the VM or the OS to run out of memory.
>>>
>>> I think we need something like #printDecompiledOn:
>>> which should do something sensible,
>>> like sending #store: but limiting
>>> the output size.
>>>
>>>
>>> Best Regards,
>>>
>>> Gerald
>>
>> I see. I'm not too worried about that. I think backtick literals 
>> should only be used for very simple things that don't have a literal 
>> specific syntax (like for example, points, fractions, complex 
>> numbers). And they should produce the same object structure each time 
>> the method is compiled (and the expression is evaluated). The result 
>> should also be the same if the backticks were removed and the 
>> expression was evaluated every time.
> I would love to agree, but that one change kept me busy for more than
> 4 hours. I had `Module >> #PlanE` somewhere in a package. That
> innocent piece of code made the image hang once I selected the package
> in the package list. At the end of a long journey of disabling browser
> code etc. pp. I came along our latest lines-of-code change. Once I
> undid it, everything was fine again. I tracked the problem down
> to the pretty printing of decompiled code.
>
> The solution was to make #storeOn: an alias #printOn: in modules,
> otherwise the pretty printer tries to format the store-string of
> the whole module, which in this case includes huge dictionaries.
>>
>> More complex things like this, that could give very different results 
>> each time the expression is evaluated, should better live in a class 
>> variable (or a class instance variable), and set up in a class 
>> #initialize.
> Could have been done here, if I would have known beforehand.
>
> Please keep in mind, once you compile such a piece of code
> in a browser, the browser immediately computes its lines-of-code
> and the poor dude at the keyboard has no change to correct
> his mistake.
>>
>> Perhaps a warning "Dude, don't use backticks for this" would be nice. 
>> Anyway, anybody playing with this kind of stuff will quickly learn 
>> all this.
> IHMO, at least a warning should be displayed by the compiler
> if the "store-string" of the evaluation result of a backtick
> expression is not the same as its "print-string".
> Maybe the size of the "store-string should be considered, too.
>
>
> Just my 0.02 €,
>
> Gerald


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