search

GIRA / PhysicalBits

A web-based programming environment for educational robotics that supports live coding and autonomy using a hybrid blocks/text programming language.
https://gira.github.io/PhysicalBits/
MIT License
18 stars 5 forks source link

Define some remaining blocks with translation msgs #28

Closed kristiank closed 4 years ago

kristiank commented 4 years ago

I found some more blocks that were not defined using initBlock. This branch relies on the previous pull request #26, I am unsure if this creates a problematic situation in git depending on the order of merging.

kristiank commented 4 years ago

I wanted to define also the block with the dropdown for π, e, φ etc. But I can't find it defined in the 'blocks.js' code. Where is it defined?

kristiank commented 4 years ago

I found the block named math_constant in the file web/ide/toolbox.xml but I still can't find where it is defined.

RichoM commented 4 years ago

It seems I forgot to implement the math_constant block and was still using the one that came with blockly. The same mistake happened for math_arithmetic. If you want to implement them yourself please go ahead. Otherwise I'll do it as soon as I find some time.

kristiank commented 4 years ago

I can try implement them tomorrow evening. This way we'd get a (hopefully) complete translation base for the next release. For the release I can also put an effort on making all the translation messages use %labels instead of %1-numbers.

kristiank commented 4 years ago

I was hesitating whether to push this change or not. It's not finished and it breaks code generation. But it does include all translation messages, though. I will take a deep dive into the code generation code this evening. It will be fun.

kristiank commented 4 years ago

I now got the code generation to work for the math_constant block. I will do the same for the math_arithmetic this evening.

kristiank commented 4 years ago

Sorry for delay. I have now defined the blocks, but they seem to be in conflict with what is available in the blocks_compressed.js. The conflict is because I changed the names of the fields from "OP" -> "operator", "A" -> "left", "B" -> "right", "CONSTANT" -> "constant". As a hack I have tried changing the corresponding field names in the blocks_compressed.js file, but it didn't give any results. Probably it is solved by running build.py provided by Blockly, but I can't find it in the repo. Do you have it available somewhere?

Code generation works for both blocks, but math_arithmetic doesn't have any initial numerical blocks when you open the toolbox and drag the block to the table.

RichoM commented 4 years ago

This looks great! I see you already got the hang of the blocks->code generation :)

Code generation works for both blocks, but math_arithmetic doesn't have any initial numerical blocks when you open the toolbox and drag the block to the table.

This is very easy to fix, you just need to tweak the toolbox a little so that the field names match your block definition (I fixed it already, see dc88ff43bbb90d2404f771f85af91fe37636c0a1).

I have now defined the blocks, but they seem to be in conflict with what is available in the blocks_compressed.js.

As for the conflicts with blocks_compressed.js I don't think we need that file anymore. It was there at the beginning because we were using some of the blockly's built-in blocks but now that we have reimplemented them all we can just remove it and don't worry about it. We can also remove javascript_compressed.js, in fact I don't think we ever needed that file because it contains the javascript code generator which we never used. Anyway, I removed both files and nothing seems to break so I guess we're safe (71981f27a106a8a87526c1a28ffabd4fd8e6bf55)

Thank you so much for this work. I'm very sorry it took me so long to review these changes. We've been really busy lately trying to port all the smalltalk code to clojure so I didn't have much time to test this properly until this morning. We have most of the parser, compiler, and communication protocol already rewritten so I think we're close to being able to replace squeak completely. If you're interested you can see our progress on the clojure-port branch.