Mac support #7
Comments
|
There are a few things off the top of my head that would need to be tweaked or taken a look at. First, the logic at would need to be made mac-aware. There may be a few other similar path-related issues here and there.Also, There is a python script that is used to inject a small python snippet that configures the remote debugger in the fusion process. I had based the script off of an existing script from the IDEA source, and that script had 2 different branches, depending on whether it was running on windows, or linux/mac. I tried to maintain the mac branch, based on the style from the original script, but I have no way of verifying if it actually works or not. See: fusionIdea/src/main/python/inject.py Line 132 in 7a781a1 |
|
I don't remember offhand exactly how I had debugged issues with the python script when I was working on it, but I do recall it being difficult to debug, due to the nature of how it is run. e.g. it's hard to even know when an exception happens, and what the exception is. One hacky workaround might be to wrap that section in a try/except: clause, and then write out the exception details to a file somewhere. I'm happy to help you get your development environment set up so you can work on the plugin and run it, but I need a bit more detail about where you're getting stuck :) |
|
I am interested in helping with the mac port. Spyder has been driving me nuts :) Can you explain the build process workflow I would need to do test it is working? |
|
For anyone looking to port this to mac, I think the first thing to do would be to see if IDEA's native "attach to process" functionality can attach to fusion 360. It won't show fusion's process by default, but you can change the process filter in settings. In IDEA, the setting is at "Build, Execution, Deployment"->"Python Debugger"->"For Attach To Process show processes with names including". If that doesn't work, then it may be somewhat difficult to get this plugin to work. But if it does work, then hopefully it's just a matter of tweaking the launch script used by this plugin, or something like that. |
|
I have spent quite a bit of time on this but have been unsuccessful. That said I don't really have any clue what I'm doing haha. If anybody has any ideas on how to do this i think i could get the rest of the port done. When I do it, my problem is that it is launching a second instance of Fusion 360 rather than connecting to the one that is already running. Also then it tries to simply "open" the python script, which maybe is supported on windows, but doesn't look to be supported on Mac? |
|
As a first thing I would be super happy if I could get auto completion :) |
|
You don't even need the plugin for that :). Just create a python module and add the python stub apis as a dependency |
|
|
More precisely here is what appears in the log: Then a new instance of Fusion 360 is spawned. |
|
As a workaround, it's possible to use the debugger on Mac without this plugin. You can create a Python Remote Debug configuration in the IDE, then add the given code snippet to your script. It looks like this (please update to reflect the path and port on your system): Then you have to launch the debugger from the IDE, it will display "Waiting for process connection...". Tested with Fusion 360 2.0.6670 and PyCharm Pro 2019.2.4. In my experience you can relaunch the script multiple times, but if you close/restart the debugging session in the IDE, for some reason it won't work anymore. Restarting Fusion 360 solves the problem, but just don't kill the debugging session and it should be ok. |
|
I've been having a play with getting this to work, after fixing up the paths I can get the extension configured and working in the editor with autocomplete. However, I'm now stuck at an odd point. When I try to run the script, the extension fails to get the PID of fusion 360 due to some sort of synchronisation issue: My best guess is that the I'm using IDEA ultimate 2019.3.3. |
|
I'm also struggling a bit to understand how the
where is |
|
Ok, worked out the Unfortunately, it looks like in the current state that this can't work on mac. The reason is that lldb cannot attach to the fusion360 process: This may be because the kernel is preventing the attach for security reasons, or fusion 360 is preventing it for copy protection reasons. The actual attaching to the python interpreter once it is running is fine as per @jlirochon 's workaround, but there doesn't seem to be a way to launch the python debug client inside fusion using pycharm so that step will need to happen manually. @tapnair it looks like you work for autodesk. If you would like to push this forward, something like the following would be needed. Or alternatively some local RPC socket service that can be sent commands (and one of the commands is to run a script). This part might be possible with a fusion addin? |
|
Another problem is that I believe the python remote debug is not available in IDEA community edition, only ultimate edition. But yeah, having an add-in that manages some sort of socket to facilitate the communication between IDEA and Fusion is probably the way to go, at least, until/unless the command line functionality you mentioned is implemented. The add-in would need to load the pydevd implementation that IDEA expects, and then listen on a socket for a connection from IDEA. That socket would only need a very basic protocol, that accepts a port and script name, and then it essentially runs the same code that inject.py otherwise injects, which sets up another port for the debug connection and then launches the script. |
|
At least when I was running it, it seemed to be ok in the community edition. When debugging the plugin from ultimate, it launches inside the community edition and seems to behave as expected. It just hangs on the lldb attach. |
|
Ok, I have this working on mac (and it should be cross platform too, but I haven't checked windows). It just uses an addin inside fusion 360 to allow remote running of scripts. You can find the addin here: https://gist.github.com/jeremyherbert/c82e2733f0d8e3a1621684bfd38ddb3d It's not pretty, more of a rough proof of concept. By default the server listens on localhost at port 8181. To use it, you simply set the addin to run on startup inside fusion, restart fusion, and then do a HTTP request with the relevant info. To test, I just set up a remote debug session in pycharm (listening on port 7681), started the remote debug server and set a breakpoint. Then with curl, ran this to do a POST request to the server in the addin: At which point the script runs and the breakpoint is triggered in pycharm. @JesusFreke I must admit that the java side of things is not exactly my forte, do you want to try to work together to get something like this integrated in your extension? Or if you want to just run with this it's also fine by me ;) Also one issue is that detach seems to not work properly, so keeping detach as |
|
Hey, this is great. Couple of points:
|
|
Yep, I do have Xcode command line tools installed (without it there would be no lldb installed anyway I’m pretty sure). I suspect this is more to do with the recent clampdown on this sort of functionality in Catalina. As for using the code, it’s pretty simple. You just
The curl call is simply to trigger a HTTP request to the server to run a script. You could use any other tool or language that supports HTTP requests to do this part. |
|
Yeah, this is probably a less troublesome approach even for the non-mac case. Attaching seems to be broke in current versions of IDEA. I was able to get it to work on my machine, but it involved some hackery with modifying the pydevd implementation provided by IDEA, so not really a solution that could be used more widely. |
|
What did you need to change to get it to work? The detach problem is due to a old version of pydev in pycharm which was not backported correctly: https://youtrack.jetbrains.com/issue/PY-40359 I have observed this problem in IDEA on mac too. I'm thinking that bundling a more modern version of pydev from the main repo: https://github.com/fabioz/PyDev.Debugger/blob/master/pydevd.py with the extension may solve the problem |
|
Yeah, I reported the same issue, with the same diagnosis re: the bad backport, and it was duplicated to that one :) https://youtrack.jetbrains.com/issue/PY-40928 PyCharm has a working pydevd, so I think I overwrote IDEA's pydevd with the current version of PyCharm's (2019.2.3), and then made one or two needed fixes. I'll do a diff to refresh my memory and report back the needed fixes. |
|
Actually, looking at it now, I don't think that's what I did... but if not, I don't recall exactly how I got it working. Trying to figure that out now.. haha |
|
Ah, there we go, I found it. I did copy it from PyCharm, but it was from a source checkout I had, not from the installed version of 2019.2.3. It's from the pycharm/193.5233.15 tag. I basically copied over the entire <pycharm_source>/python/helpers/pydev to /.IdeaIC2019.3/config/plugins/python-ce/helpers/pydev The only tweak I had to make was in pydev/_pydevd_bundle/pydevd_comm.py: |
This updates the version if IDEA that we're building against to 2019.3.3, and includes some minor fixes needed to be used with this version. Note that 2019.3.3 has a broken version of pydev/pydevd that prevents attaching and debugging fusion scripts. It's possible to get it to work, but it's a bit hacky. See #7 (comment) for more info.
|
I also just uploaded an idea-2019.3.3 branch of this plugin, with some needed fixes to get it working with that version. |
|
I just tidied this up into an addin: https://github.com/jeremyherbert/fusion360_python_debug_addin I'm not set up to build binary python extensions on windows, but if someone can checkout PyDev.Debugger, run |
|
Does the stock PyDev.Debugger work with PyCharm/IDEA? I thought they used a modified version of it. I was actually looking at this a bit for the plugin today. From the perspective of using something like this from the plugin, it's probably best to have the IDE send the location of the pydevd that is bundled with IDEA/PyCharm to the add-in and let it load it from there, to minimize the chances of version mismatches/incompatibilities between a pydevd bundled with the add-in and that used by IDEA/PyCharm. I'm also a bit wary of opening up a long-running port in fusion 360 with no protections in place. It definitely seems like something that could be used for cross-user execution, privilege escalation, etc. Although it is listening on localhost at least, so it shouldn't be able to be connected to remotely. But even just local access seems potentially risky. I was thinking of having the add-in pop up some UI the first time a debugger connects, asking the user to confirm the connection. Maybe have the plugin generate some sort of session key or more permanent key that could be used for further operations, so the user doesn't have to confirm every single connection. |
|
Yes, it seems to work without issue for everything I tested. The problem with the version of pydevd that is shipped with the jetbrains stuff is (as you know) that it is simply broken for this use case, it cannot detach and restart properly (at least on mac); that is not the case with the latest version of pydevd. I figured it could just include the egg until jetbrains fixes the problem, and then remove it and change over to using the included one. I thought about the security for a bit but I figured given that it is only really supposed to be run in a development environment it didn't bother me too much. But the UI confirmation is probably a good idea anyway. |
|
Yeah, I don't think the attaching issue should be a problem with this, since we're not actually attaching to a process -- instead using the HTTP server as a way to bypass the need to attach to the process. The newest version of the python plugin for IDEA seems to have a fix for the attaching problem, but there's still some problem that prevents breakpoints from working. Not sure what the deal is. But my workaround of copying the pydevd from that one version of PyCharm still works. shrug. I'm not sure if that will still be a problem when using the http server to initiate the connection. I'm hoping to have a quick proof-of-concept working this weekend, although the fleshed out implementation will take longer. |
|
The attaching problem is one issue, but the one I am referring to is that at least on mac if you ever detach the debugger (with the stop button inside pycharm/IDEA) then you can never attach the debugger again. The problem is that pydevd is still running inside fusion360 basically as a zombie thread that blocks it from restarting but also from debugging. The culprit is this section in In the jetbrains version, they never backported the |
|
no changes on the python side, debugging/running scripts works. It's all working and packet shows up on |
|
Weird. Doesn't work on windows though. hah! |
|
Dang. That would be too easy... |
|
Okay, one last try. I just uploaded new versions of both that add support for ipv6 multicasting. Here's the test command: crosses fingers |
|
fusion addin can't start anymore unfortunately (also attaching images to github is broken?)
|
|
|
|
sigh. thanks. I suspect the problem may be that the network interface must be specified, instead of using 0 to indicate auto-assignment (see, e.g. sccn/liblsl#36) Can you try setting the network index here. I think you can find the network index by If that works, then I'll hopefully be able to fix it up and get it working. Note: at least on windows, using the loopback interface doesn't seem to work. I have to use one of the actual interfaces. But the multicast address itself is an interface-local address, so it will never be routed elsewhere. If that doesn't work, I'm pretty much out of ideas with respect to using a multicast approach. Maybe we can explore a file-based approach like you suggested. |
|
I couldn't work out how to get the interface index easily, so I just brute forced it. Index 1, 4, 6, 7, 12, 15 don't cause an exception, but it also don't work. All other indices up to 15 give an exception on fusion startup (exception is "invalid argument" on that line). For the indices that do start without an exception, error in idea is:
At this point, we can either go for the previous approach and just basically do if (windows) { or do the file based approach, though I think the file based approach is probably simpler as it doesn't have to deal with firewalls either. |
|
I finally just got a VM running so I could investigate directly. Got it all working, and pushed a new version of both things. Give it a shot and let me know if you find anything off :) The plugin should now fully support the various mac-specific paths, and debugging/etc. should all work. |
|
Unfortunately no :( |
|
This code is the problem as it works on all interfaces, but some interfaces generate a no route to host exception |
|
Yeah, probably just need to wrap the inner part of the loop in an exception handler |
|
Pushed a4adba2 to fix it, hopefully |
|
back to this one unfortunately |
|
hmm seems like the python server isn't listening according to lsof and netstat. I'm also not getting a log file from the addin anymore |
|
I can confirm. I'm getting the same. I must have screwed up something in the addin before pushing the changes. |
|
https://github.com/JesusFreke/fusion_idea_addin/blob/4f7daf1be6dd95a2e1f68167c8afa0a56e6d94e1/fusion_idea_addin.py#L508 is a syntax error, a single double quote instead of two double quotes (or two single quotes) |
|
also it looks like that line does nothing? Or perhaps some code is missing? |
|
Yeah, I have no idea what happened there. I specifically remember fixing/changing exactly those things, shortly before pushing everything. Maybe I forgot to push a change between machines at some point or something. |
|
I just pushed JesusFreke/fusion_idea_addin@194671c, and verified it's working in my VM. |
|
Yep, works fully on this end too now. Great work! |
|
Yay, finally. heh. I'll take another look at everything tomorrow, make sure I'm not missing something stupid, and hopefully release a new version this weekend. Hmm. I'll need to figure out the best way to communicate the need to install the add-in, since that will be a new requirement for existing users. |
|
Great. Maybe if the SSDP fails, print some text in the console like “have you installed the fusion addon from here: https:...” I guess this ends my yak shaving, can finally get back to writing a script to export DXF files with construction lines on a separate layer... |
|
Sounds good. Thanks for all the help and back-and-forth. haha :) |
|
No worries. Keep up the good work, and stay safe wherever you are. |
This updates the version if IDEA that we're building against to 2019.3.3, and includes some minor fixes needed to be used with this version. Note that 2019.3.3 has a broken version of pydev/pydevd that prevents attaching and debugging fusion scripts. It's possible to get it to work, but it's a bit hacky. See #7 (comment) for more info.
|
I've released v0.6.0 that adds support for Mac. The new version of the plugin (v0.6.0) has been submitted to IDEA's plugin repository, but it may take a few days to be published. In the meantime, you can download the plugin here for manual installation. |
I am wondering if the answer to Mac support is as simple as removing the ".exe" filter from the input box in settings? Probably not. But thought id try. I couldn't figure out how to get my forked copy of your plugin to run to test. I'd be happy to do so.
In: FusionConfigurable.java, Line 85
The text was updated successfully, but these errors were encountered: