-
Notifications
You must be signed in to change notification settings - Fork 106
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
Segfault and lesser issues with autoreload #43
Comments
Looks like this might be related to #37 as far as
For item 3, just curious but are you using |
I agree with your summary.
#37 does indeed seem to be related to item 2.
I am using a single monitor, with fvwm for a window manager and focus under mouse. Fvwm allows focus stealing, and I have to move the pointer outside the window and back in to regain focus.
|
Ok thanks for the details, I may have some time this week to look into making some improvements to |
Well, how does fstl know the file is complete. What should happen is the program generating the file should write it to a temp file, then rename it to the file fstl is trying to reload. Renames are atomic. So something like "mv -f tempfile.stl file-fstl-is-viewing.stl" |
Seems like this one is mostly solved by #107. In case anyone else like me is still hitting raciness with the 100 ms threshold, it can be worked around by the classic "write to a temp file, move to the final file", like here in the export from my CadQuery script: # Workaround issue with fstl reading the file mid-rewrite
def safe_write_stl(obj, fname):
cq.exporters.export(obj, fname + ".tmp", exportType="STL")
os.replace(fname + ".tmp", fname) I guess CadQuery just has some >100 ms pauses to think whilst it's writing out a large STL. |
I am using fstl to display designs for 3D printing that are frequently modified and regenerated. The default-enabled autoreload feature has some drawbacks in that use case.
First, fstl frequently crashes while the .stl is being regenerated. This is because in Loader::read_stl_ascii(), the size of the vector returned by split() is not checked before using the elements. When a vertex row has not yet been completely written, fstl crashes.
Additionally it would be really neat if fstl either waited before autoreloading until the file size does not change any more, or if it reloaded again without an error pop-up in that case. Otherwise I have had to click away several message dialogs from the same reload.
Finally the focus stealing on autoreload is a pain when one does not want to switch to fstl despite regenerating the .stl.
The text was updated successfully, but these errors were encountered: