-
-
Notifications
You must be signed in to change notification settings - Fork 886
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
NP- 327 emscripten communication #2131
Conversation
Contribute to NP-327
Contribute to NP-327
Refactored conditional compilation to enable Emscripten-specific behavior in the communication module. Updated CMakeLists.txt to handle Emscripten build settings and refactored EmscriptenCommunication to properly manage progress handling and command-line arguments. Contribute to NP-327
This commit adds support for handling slice info callbacks through Emscripten, alongside progress callbacks. Additionally, functions to create slice info messages using rapidjson were implemented to prepare JSON data for slice information. Contribute to NP-327
Replaced raw pointers with `std::shared_ptr` for better memory management. Standardized variable names to follow consistent naming conventions, improving code readability and maintainability. This was needed because the reference to Slice was otherwise out-of-scope when calling `Emscripten::sliceNext()` Contribute to NP-327
Replaced unique_ptr with shared_ptr in various components to facilitate shared ownership of resources and prevent manual memory management. This change affects communication objects, `Slice` instances, and related test cases to ensure smooth integration. Contribute to NP-327
… into NP-327_emscripten_communication
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oooooooooh
Nice improvement, some minor remarks but apart from that I do like it very much 👍
Added detailed documentation comments for the EmscriptenCommunication class, including descriptions for member variables and methods. This improves code readability and ease of maintenance. Contribute to NP-327
… into NP-327_emscripten_communication
Contribute to NP-327
The return type of getTotalExtraLayer function on Raft is casted to the value_type to prevent underflow. This previously resulted in method xl to generate invalid gcode.
NP-351
Contribute to NP-327
There has been many commits on this PR recently, is it ready for review again ? Unit tests are failing though. |
…roduces-unexpected-results' into NP-327_emscripten_communication
@wawanbreton This now also integrate #2134 since we're building our Working package of this branch |
Contribute to NP-327
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one nitpicky remark about naming, which got me confused. Otherwise looks good.
Renamed `gcode_prefix_handler_` to `gcode_header_handler_` for clarity. Updated corresponding usage in `EmscriptenCommunication.h`, `CommandLine.cpp`, and `EmscriptenCommunication.cpp`. Contribute to NP-327
Ensure the prefix argument is correctly formatted as a string in JavaScript function calls. This change prevents potential issues with GCode prefix handling in the communication module as it starts with ';' NP-327
…r/CuraEngine into NP-327_emscripten_communication
@wawanbreton @jellespijker I removed the type cast; I gave it additional tests and it seems that the |
Implemented a `convertTobase64` function to encode strings to base64, ensuring they can be safely transmitted in JavaScript. Updated `EmscriptenCommunication::sendGCodePrefix` to use this new encoding method and modified relevant tests accordingly to check this functionality. NP-327
Co-authored-by: Erwan MATHIEU <erwan.mathieu@ultimaker.com>
assuming that cloud slicer does not create multiple mesh groups, but one. NP-351
What is the status of this PR ? There has been a few significant changes since the last approval (which I would ask you to avoid as much as possible), is it now stable enough for a final review ? |
Yes it can be reviewed as final |
With these proposed changes I am still able to reproduce the method xl slicing issues. I think the cast is still needed for wasm. (FYI @0x5844) |
That's strange, if we want to keep that cast we have to adjust it in all it's occurrences (I don't think this is the way to go about it). Currently there are multiple changes to how we compile wasm (flags passed to the compiler); I would much rather wait for the merge and have a fresh test again. Removing the typecast while enabling the compiler flag seemed to tackle to issue (?) which seem to be no longer the case (this was tested last week). |
Description
Add an extra communication option when using Emscripten and compiling for wasm. This is based on the cmdline communication layer and uses a callback function to be executed on the JS side, providing slice information and possibly in the future preview information.
Type of change
How Has This Been Tested?
Test Configuration:
Checklist: