Hi Eliot,


> It looks correct.  Can you check it against the old bytecode set too?  We don’t want it to break old-style blocks.

Good point. I ran

(Object >> #asOrderedCollection) decompile generate valueWithReceiver: 42 arguments: #().

for both bytecode sets, and both were fine.

But:

(Collection >> #asArray) decompile generate valueWithReceiver: {42} asOrderedCollection arguments: #().

breaks - in both bytecode sets. This is weird.
I will have a look into it, maybe I can discover what's wrong.

In addition, I propose to write tests for this. But it's not the goal of the decompiler to yield exactly the same parse tree or source code as the original method consisted of? In this case, we will need to write a lot of fixtures for the tests.

Best,
Christoph


________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Eliot Miranda <eliot.miranda at gmail.com>
Gesendet: Freitag, 27. März 2020 21:33 Uhr
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [Etoys, Compiler] Help wanted: Trying to embed SyntaxMorphs into other tiles

Hi Christoph,

On Mar 27, 2020, at 12:45 PM, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:



Hi all! :-)

Just an update of the decompilation question:
Christoph Thiede wrote
I don't know how to use #generate: exactly, but other senders usually appear to recompile a method before passing it to #generate:.
For comparison:

[ (Collection >> #asArray) decompile generate: CompiledMethodTrailer empty ] fails, but

[ m := (Collection >> #asArray) decompile.

  m := Compiler new compile: m in: Collection notifying: nil ifFail: #foo.
  m generate: CompiledMethodTrailer empty ] works.
Why is that recompilation required but decompilation is insufficient? Is this some bug, or is it expected behavior?
The general approach seems to be correct, but I think I found an error in the decompilation of literal variables such as Array. I sent Compiler-ct.425 to the inbox which should fix this issue.

I moved this to inbox.  It looks correct.  Can you check it against the old bytecode set too?  We don’t want it to break old-style blocks.

<http://www.hpi.de/>

I am going to complete the implementation of SyntaxMorph >> #parseNode :-)

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Thiede, Christoph
Gesendet: Dienstag, 15. Oktober 2019 21:08:24
An: squeak-dev at lists.squeakfoundation.org
Betreff: [squeak-dev] [Etoys, Compiler] Help wanted: Trying to embed SyntaxMorphs into other tiles


Hi all,


I'm currently trying to implement #parseNodeWith: on SyntaxMorph, in order to embed SyntaxMorphs into regular tiles. (Did this ever work in past?)

I'm afraid the attempt in the commit below does not work yet; you can create a script editor, but parsing is erroneous, so you cannot execute the script.


To reproduce:

Compile the following:

MyPlayer >> examplePlayerCode

self forward: 6 * 7.

self turn: (11 raisedTo: 13 modulo: 97)

and evaluate:

| e p |
p := Morph new openInWorld assuredPlayer.
e := (MyPlayer >> #examplePlayerCode) decompile asScriptEditorFor: p.
e openInHand.


In Player>>#acceptScript:for:, #generate: is called on node, and when I decompile the result, I get a strange result:


examplePlayerCodeTest

self forward: 6 * 7.

self

forward: (#forward: forward: #forward:).


I don't know how to use #generate: exactly, but other senders usually appear to recompile a method before passing it to #generate:.

For comparison:

[ (Collection >> #asArray) decompile generate: CompiledMethodTrailer empty ] fails, but

[ m := (Collection >> #asArray) decompile.

  m := Compiler new compile: m in: Collection notifying: nil ifFail: #foo.
  m generate: CompiledMethodTrailer empty ] works.

Why is that recompilation required but decompilation is insufficient? Is this some bug, or is it expected behavior?


However, in the case of SyntaxMorph, I don't know how to recompile the node before, as a SyntaxMorph should be able to represent a node of an arbitrary type that must not be constrained to a MessageNode. So how could I solve the problem to generate code from SyntaxMorphs?


tl;dr: What is the full story of #generate: and how can it be made to work in this example?

Many thanks in advance! :-)


Best,

Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von commits at source.squeak.org <commits at source.squeak.org>
Gesendet: Dienstag, 15. Oktober 2019 14:46 Uhr
An: squeak-dev at lists.squeakfoundation.org
Betreff: [squeak-dev] The Inbox: EToys-ct.367.mcz

A new version of EToys was added to project The Inbox:
http://source.squeak.org/inbox/EToys-ct.367.mcz

==================== Summary ====================

Name: EToys-ct.367
Author: ct
Time: 15 October 2019, 2:46:24.862129 pm
UUID: 1394344f-b1e3-5640-a13a-70c5dffd51f4
Ancestors: EToys-mt.361

Allow for embedding SyntaxMorphs into test tiles.

=============== Diff against EToys-mt.361 ===============

Item was added:
+ ----- Method: SyntaxMorph>>parseNodeWith:asStatement: (in category '*Etoys-Squeakland-code generation') -----
+ parseNodeWith: encoder asStatement: aBoolean
+
+        ^ self parseNode!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200327/04988ec6/attachment.html>