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

[Gerald Klix]

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