Web IDE vs Espruino Tools minification #3869
Replies: 1 comment
-
Posted at 2021-09-14 by @gfwilliams Wow,that is a strange one. Try re-installing now. It looks like the npm version of esmangle is broken (uses an old estraverse). Since EspruinoTools includes esmangle anyway, we now just use that version instead and it seems to work ok. Posted at 2021-09-15 by jgw That already is better, but...
with 'esprimaMod.js' as :
and the resulting error at line 29 and 42:
No idea where that 'unexpected token {' would be at in above simple code... I honestly thought Espruino Tools used the very same chain of tools as Web IDE does, but apparently this is not the case ? I'm trying to use the tools for distributing an app to multiple Bangle.js 2's, but if Espruino Tools builds 'something different' as compared to Web IDE (where the app was fully debugged), I do not feel particularly comfortable... Posted at 2021-09-16 by @gfwilliams Ok, that one is interesting. You may be able to get around it just by uninstalling the
Well, it uses the majority of the same stuff. However, as I remember (I could be wrong here) some developers came along and were saying "Why are you using built-in modules when there are ones on NPM that'll be better maintained?" so I ended up having this special case for those modules when running the CLI tool. As it happens, in this case the Posted at 2021-09-16 by @gfwilliams Just to say, I looked into your code and it does say Try updating again now. This should be miles better - more info at espruino/EspruinoTools#138 Posted at 2021-09-16 by jgw Yes, now it works ! The resulting number of bytes from the message 'No errors. Minified xxx bytes to yyy bytes.' is identical in both cases, so chances are both builds come up with the exact same result.
I also struggle with the 'wonderful world' of open source modules. One can usually only guess at things like quality and longevity, but hey, apart from time spent, it's free.... In the open source world, the Espruino project is a notable exception in terms of quality and support. Thank you again for the quick response. Posted at 2021-10-12 by jgw Hello again,
Unfortunately I ran into an issue with 'special character strings'. Consider the following code (this the double arrow image used in Bangle's menu) :
This is prepared for download with :
'testOut.js' looks like :
When downloading this to the bracelet, the error 'Too much data for file size' is returned. After some tracing it turns out the download is 69 byte, not 67 (attached image). The image on the bracelet is - obviously - 'mangled'. A dump() looks messed up :
Using the Web IDE and 'Send to Espruino' Flash, the file downloads OK and is 67 byte in size (attached). The dump () :
The difference are the codes for the 'ùð' characters. The strange thing is that the console dumps in Web IDE (development tools) show the same characters in the 'Sending' prompt, but result in a correct file being stored.
So obviously 'someone' is altering the output of the minified source before sending it down BLE. How then is it possible to just 'cat' an output file to a bracelet ? What are the additional modifications a minified source needs before 'just copying' to a Bangle.js 2 ? Attachments: Posted at 2021-10-13 by @gfwilliams How do you download that prepared file to Bangle.js? Using the command-line tools again? What's the command? I believe the issue is with So... You have a few options I think:
Posted at 2021-10-14 by jgw The 'testOut.js' file is sent down using c-code in our devices. These are industrial terminals using an ARM CPU. This download works as it should : connecting, waiting for the prompt then copying 'testOut.js' byte by byte down to Bangle.js 2. Bangle.js 2 responds as it should, so nothing wrong there. It is the 'testOut.js' file that is already 'wrong' : the erroneous bytes C3 B9 C3 B0 are the UTF8 representation for 'ùð' : ( https://onlineunicodetools.com/convert-unicode-to-utf8 ), and not the original F9 Fo. So using another way for download will not change anything I'm afraid. For now, I've changed my code to avoid strings with binary 'characters', using a btoa-version of the binary values. For the example above, this comes down to :
So I'm in the clear for now, but this is a bit of a clumsy workaround of course. Posted at 2021-10-14 by @MaBecker Maybe this could help: http://forum.espruino.com/comments/16160446/ Posted at 2021-10-18 by @gfwilliams Ahh, I see. This is a tricky one actually. In a way, nothing is actually wrong. What's happened is the command-line tools are writing the file to disk in UTF8 format. If you were also to load the files in UTF8 format and then send character by character everything would be fine. I believe you could use the Maybe the tools should write the file in the raw ISO8859-1 format, however they are expected to read files in UTF8 so the current behaviour of writing as UTF8 seems kind of reasonable. Posted at 2021-10-18 by jgw Yes I'm familiar with iconv (and libiconv), but to be able to convert UTF8 to what the (binary !) characters originally were, one needs to know the character encoding of the platform the UTF8 was generated on. That encoding was used to transform 0xF9 and oxF0 characters in the corresponding UTF8 characters and is needed to properly specify the 'decoding' libiconv must perform. It remains unexplainable that a string declared as
gets transformed into something UTF8 :
Why not just leave binary valued characters in strings as they are ? After all, the string for a drawImage call is not really a string anyhow ... (Just an opinion of someone totally unfamiliar with the inner workings of Espruino and the Web IDE.) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Posted at 2021-09-14 by jgw
Hi,
I'm building a 'command-line-script' to download an application to multiple Bangle.js 2 devices using Espruino Tools on Linux. I ran into a strange problem.
Consider this (isolated) piece of code :
When minifying this is the Web IDE, no problems (of course...).
When running minification with the Espruino Tools, a strange error is reported (line 62 below):
Platform is Ubuntu 18.04, Node version is V8.10.0, espruino (tools) is V0.1.38.
Beta Was this translation helpful? Give feedback.
All reactions