-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ColorRemap block is generating NaN in first argument #434
Comments
The C code generator for the color_value_from block is returning a function call.
The C code generator for the OLED triangle block is expecting a hexadecimal value in RRGGBB format. The actual call to getColor() does return an appropriate value, so the call should be inlined in the C code output and not converted to a hex value. In this example project, using a color value generates reasonable code.
If the color value is replaced with the problematic color_value_from block, the code generated is now reasonable.
A workaround for this issue is to assign the value of the color_value_from block to a variable and then assign that variable to the color input of the OLED triangle block |
I tried your block-code exactly as you show with 'item' declared first and then used as the color and it still does not work and still gives 'not a number': // Libraries and Definitions #include "simpletools.h" // Global Variables and Objects screen *oledc; // Main Program int main() { |
The "get [color] value from" block is also not returning a 24 bit value as expected. It is instead returning a string that is a function call to convert the selected color. The previous patch applied to the OLED triangle block may work, but that patch will have to applied to each block that expects a color input. It seems reasonable that these two blocks should be updated to return a 24 bit value. |
Any idea when this will be resolved, such that I can use these blocks without error? |
@Automaxion The update that addresses this issue is running on our staging server, SoloCup. Please try running your project there and let me know if the issue is resolved. |
Thanks for the additional feedback. Digging deeper into the problem we discovered that the OLED blocks were incapable of handling input from variables under certain conditions. These blocks expected numeric inputs in the form 0xRRGGBB. Variable values were evaluated to NaN, which was the root issue. The code has been improved and is available for further testing on SoloCup. PR #450 contains the update for this issue. |
It appears to work now, both for the simple code, as above and in my project. |
I hope the update comes soon since using SoloCup keeps failing on download to Flip after compiling. It works once but then I need to restart and reconnect to Launcher (now v1.0.1) |
I have created a new issue for the download failures. We'll track it there. This issue appears to be resolved in v1.5.0-b4. |
@Automaxion - Please see Issue #452 to answer a question about the download problems. |
When does BlocklyProp Launcher or BlocklyProp Solo (whichever it is) get
upgraded to reflect the resolution to the OLED error so I don't have to
use SoloCup?
Stephen Bysouth
|
The simple project below is generating code with a 0x NaN in the remapColor() call.
The text was updated successfully, but these errors were encountered: