ostinelli / SublimErl

An Erlang Plugin for Sublime Text 2, which enables code completion and allows you to run tests within the editor itself.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Python processes not quitting when Sublime closed

aberman opened this issue · comments

  1. Download HEAD
  2. Open Sublime Text 2
  3. Close Sublime Text 2
  4. run ps ax | grep python

Result:

python sublimerl_libparser.py /Users/andrew/Documents/workspace /Users/andrew/Library/Application Support/Sublime Text 2/Packages/SublimErl/completion/Current-Project
python sublimerl_libparser.py /usr/local/Cellar/erlang/R15B01/lib/erlang/lib /Users/andrew/Library/Application Support/Sublime Text 2/Packages/SublimErl/completion/Erlang-Libs

Expected result:

Should have exited when Sublime exited.

I see that the parser is using my entire workspace instead of just the project directory. As a result, it's going through every project I have and is causing extremely high CPU as well on Mac OS X 10.7.3.

Expected result:

Should have exited when Sublime exited.

this is intended. it will finish the parsing and update the files. do you believe this should be interrupted?

I see that the parser is using my entire workspace instead of just the project directory. As a result, it's going through every project I have and is causing extremely high CPU as well on Mac OS X 10.7.3.

how can you say that it is going through every project? I believe this statement is wrong.

To be sure of this, check Current-Project.sublime-completions, dies it contain "every project you have"?

If not, the I believe you are experiencing something different. The parser will update ONCE all the erlang libs the first time it is started. Then, unless Erlang is updated, it won't do anything anymore.

This single parsing takes around 4 minutes on my machine.

r.

Looking at the first process: python sublimerl_libparser.py /Users/andrew/Documents/workspace

It's passing in .../Documents/workspace instead of ..../Documents/workspace/myProject. I assume as a result it is parsing everything underneath workspace.

The parsing of my project never completes and Current-Project.sublime-completions never gets written. It goes for 30+ minutes and still has not completed. I have to kill it as it's sucking up too much CPU.

The second parser which does the Erlang libs does complete after 15 minutes but runs every time I close and reopen Sublime. Is this intended?

Please provide code to reproduce.

Thank you.

Hmmm, I'm not really sure how you want me to do that. There's nothing code specific. Prior to this last release, everything was working perfectly. Can you tell me where you set the directory to pass to sublimerl_libparser.py?

My dir structure is pretty simple:

~/Documents/workspace/[all my projects are here including non-Erlang projects]

Does passing ~/Documents/workspace to sublimerl_libparser mean it will search that entire directory?

I've debugged a bit and the project_root is incorrect. It's going too high in the directory structure. Instead of ~/Documents/workspace/myProject, it's set at ~/Documents/workspace, which is not correct.

Where did you find this?

If I am to help I need to be able to reproduce this. I simply do not have enough information.

https://github.com/ostinelli/SublimErl/blob/master/sublimerl_completion.py#L155

The project_root per above is yielding the directory above the actual project's base dir. Let me know what info you need. As I said, my directory structure is pretty basic on my Mac: ~/Documents/workspace/[all my projects]

My Erlang projects are laid out like this:

  • src
  • ebin
  • deps
  • priv
  • rebar.config

Do you have a rebar.config in ~/Documents/workspace/ ?

No, there is no rebar.config in there, only other directories.

I figured out the issue. I had a src dir in the workspace dir. I'm not sure I understand why that would matter at all, but once I renamed that directory the project_root is correct. Can you explain the logic behind determining the project_root? Thanks!

It parses directories up in the root from the open file, until it finds rebar.config. If it doesn't find it, it will use the first /src directory it finds (which usually contains the file itself).

Hmmm, well, I definitely have a rebar.config in the project's directory, so it shouldn't ever have gone up to the higher directory then. Perhaps an issue with this?

Again, if you can build up some code to reproduce, that will make it easier for me to fix it. Otherwise, will do my best.

Thank you,

r.

I've created a project for you: https://github.com/aberman/sublimerl_test

thank you, will look into this asap.

Hello @aberman, I've looked into this and it seems that sublimerl is doing what is expected to do.

rebar.config is often used in subdirs, so what the search algorithm does to find project root is find the deepest level of a /src directory or of a rebar.config file.

I don't see why you would have a configuration where you have separate projects into /test/, and then at the same level another /src directory, unless you are having zombie directories or such.

Therefore, I don't see how this can be fixed unless you force a user to open up all of a project directory in Sublime Text to know which one is the directory that he refers to.

That's fair, we can close this issue.