Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:
Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What is the last letter in the word "SlickEdit":
How many LETTERS are in the following? "a1b2c3":
Which number is missing?  "12345689":

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: patrick
« on: November 13, 2020, 05:00:22 PM »

Hard to say if the wrapper script made any difference for me, but I did manage to reproduce it a couple more times.

There's a fix in the next 25.0.0 hotfix.
Posted by: patrick
« on: November 12, 2020, 09:04:22 PM »

The entries in the Project Properties Live Errors panel only override what profile to use for a language while that project is active.  They don't enable it or disable it for that project.  So, if you don't have an entry for for Python in your C++ project, it just falls back to whatever the default profile is set to in the Python Language Options -> Live Errors page.

   
Posted by: rowbearto
« on: November 12, 2020, 08:47:11 PM »

Found another strange behavior.

I switched workspaces and the new workspace is all C++ projects and not python. I don't have live errors enabled in this new workspace.

I forgot I had switched workspaces and I edited the python file and live errors was still active. I don't think it should have been active when in a different workspace that doesn't have it enabled?

When I first reported this issue, I am sure I was in the workspace with my python project and having live errors enabled.

In my workspace with the python project, I have other projects in this workspace that are C++ projects.

Does the python project need to be the active one for Live errors to work? I'm sure that when it wasn't running my python project was the active one. I switched to make the C++ project the active one in my SE workspace and live errors still ran on my python file that is in a different project in the workspace.
Posted by: patrick
« on: November 12, 2020, 07:59:37 PM »

I'm not ready to declare victory yet, but I think I've found some code that decides whether a profile is valid/installed or not that has a problem specific with project overrides.  Possibly in such a way that it caches a bad answer when it fails.  If this is it, it is hot-fixable. 

I'll try with a wrapper script to see if I can reproduce it more often that way. 
Posted by: rowbearto
« on: November 12, 2020, 07:48:29 PM »

Instead of running pylint I'm running a bash script that eventually calls pylint (after this bash script sets PYTHONPATH).

Perhaps try with a wrapper bash script?

When I sent the first mail, I did try restarting the patched version a few times and kept seeing it not run. I don't see anything in my se.log.

After your last post I ran with strace and it did start running.

I turned off strace, reran and now it is running.

Strange.
Posted by: patrick
« on: November 12, 2020, 06:19:07 PM »

I don't see any code added in the patch that should interact with live errors.

In 25.0.9-gold, I had set it up so my default live errors for python was wrong, and added a entry in the Project Live Errors to use the only pylint I have installed currently.  Verified it worked, and then switched to the patched version.  I had what you saw happen only one time, but haven't had it happen again.  So there is something weird going, but I don't think it specific to the patched version.

I'm going to mess with it more and see if I can find a way to make it happen again when I have a debugger attached.

So I'm going to guess it might work for you if you try the patched version again.  If not, check your se.log and see if anything dribbled out on stdout/stderr.  (not expected, but not impossible).  And if you can reproduce it consistently, maybe give it a run under strace and look at the execve() calls to see if any are for pylint, if they're for the correct one, etc...
Posted by: patrick
« on: November 12, 2020, 05:03:36 PM »

Wait for a bit.  I didn't think there would be anything in there that would change the live errors behavior.  I'll check it out and see what's going on.
Posted by: rowbearto
« on: November 12, 2020, 03:29:15 PM »

Indeed when I go to run the original 25.0.0.9 the live errors is running.

Should I continue running the patch, or wait for another patch?
Posted by: rowbearto
« on: November 12, 2020, 03:27:51 PM »

Yesterday python live errors was working for me. I have it configured in my project properties and my python live errors options.

I just upgraded to the 25.0.0.9 patch that fixed my core dump. Maybe it is this new version that has issue with live errors?

In the config/25.0.0./rte directory I don't see the output of my pylint script. I can run pylint manually (and through build tool), but live errors seems not to run.

I suspect it is due to the 25.0.0.9 patch I just upgraded to.