I have been using Python Script for about a year and it helped a lot streamlining my work. Thanks a lot!
A recurring 2-part problem keeps recurring.
In STARTUP.py, a personalized version of 'addSaveStamp' apparently runs well.
It however is responsible for NPP to hang when I run certain other python scripts from NPP-menu as the problem goes away when I disable the " notepad.callback(addSaveStamp, [NOTIFICATION.FILEBEFORESAVE]) " line.
~~~~~~~
in STARTUP
import datetime
import os
def addSaveStamp(args):
FPN = notepad.getCurrentFilename()
FN = FPN.split("\")[-1]
EXT = FN.split(".")[-1].upper()
c = ""
if EXT == 'AHK': c = ";" + FPN
elif EXT == 'BAT': c = "rem " + FPN
elif EXT == 'TXT': c = FPN
elif EXT == 'EL': c = "//" + FN
elif EXT == 'PY': c = "#" + FPN
if c <> "":
CN = os.getenv('COMPUTERNAME')
UN = os.getenv('USERNAME')
s = str(datetime.datetime.today())
dt, ms = s.split(".")
l = editor.getLineCount()
b = editor.getTextLength()
s = c + " ;\t" + dt + " ;\t" + UN + " on " + CN + " ;\t" + str(l) + " lines ;\t" + str(b) + " bytes" + "\r\n"
line0 = editor.getLine(0)
#add line if beginning of line was changed OR file is edited on a different computer
if line0.find(c) == -1 or line0.find(CN) == -1 : editor.insertText(0, s)
else : editor.replaceWholeLine(0, s) #update line
#NB editor.deleteLine(0) # does not remove EOL on line0 as opposed to other lines!
notepad.callback(addSaveStamp, [NOTIFICATION.FILEBEFORESAVE])
sys.stdout = console
~~~~
NPP hangs when I run another script containing something like
aDict = {'cBlack' :'gBlack', 'cWhite' :'gWhite'}
for s, r in aDict.iteritems():
# console.write("")
editor.replace(s, r)
AND also something like
~~~~~~
ListS = ["cBlack", "cWhite"]
ListR = ["gBlack", "gWhite"]
if len(ListS) == len(ListR):
for i in range(0, len(ListR)):
s = ListS[i]
r = ListR[i]
console.write("")
editor.rereplace(s, r)
~~~~~
Strangely enough, the problem goes away if I insert a simple " console.write("") " line before calling the replace functions.
In summary, I have stumbled across a solution by trying to debug the problem but it is obviously not a logical solution!
I could find no reference to such a problem anywhere.
Perhaps somebody can explain what's happening?
Last edit: Kadner 2014-09-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry I hadn't seen this. There was an issue fixed with deadlocks in 1.0.7
- are you using that version?
If you are, then I'll try and reproduce the issue. Deadlocks are actually
quite easy to get with callbacks, as there is all manor of magic happening
to manage the global interpreter lock (internal python thing, bit like a
baton that you have to have to run). Normally it's down to some call not
giving the baton up before it does it's thing, and then as a result of
whatever it did, a callback gets called, and wants the baton. If you can
confirm the version, I'll check the calls you're making.
Yes, I installed PythonScript_1.0.7.0.msi on NPP 6.6.9.
By the way, searching for help I stumbled upon "Welcome to PythonScript’s documentation! — PythonScript 1_0_1_0 documentation.htm" which seems more up to date than "PythonScript v0.9.2.0 documentation.chm" that still comes along with the package!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, reproduced, and issue found (which incidentally may have been an issue in certain other unexplainable cases!)
The issue was that we were getting notifications from N++ for stuff that we're really not interested in (like when the toolbar sends a notification), and that was being triggered just at the point when we were calling an otherwise harmless "get" operation from N++. The knock on effect was that the callback needed to be checked (as soon as you register a callback, they're always checked), and to check them, we need the lock. We didn't used to give up the global interpreter lock (GIL) when we did "get" calls, but if a random notification was sent at the right moment, then we'd get a deadlock.
So, two things have changed.
I've made it so we always give up the GIL before calling into notepad or scintilla. This is probably overkill in 50% of the cases, but it stops deadlocks.
I've added a filter on the notifications, so we check if we're interested in the notification before we grab the GIL. This should help performance in the majority of cases (it actually adds a few cycles for a notification we are interested in, but it's so small it's not noticeable).
Expect a new version shortly. Many thanks for your detailed description, and code - it helped a lot to reproduce it.
Documentation
The file PythonScript.chm is included in the full.zip and the MSI version in the up to date 1.0.7 version. I don't know where you're getting either PythonScript 1_0_1 documentation.htm or PythonScript v0.9.2.0 documentation.chm from. The PythonScript.chm is the only chm included in any of the forms of the package. It's installed under Notepad++\plugins\doc\PythonScript\PythonScript.chm, which is where the plugin loads it from when you click on the "context help" menu option.
This is the most up to date version.
Cheers, and thanks again,
Dave.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update 1.0.8 solved several freezes I had. e.g.
in a startup def:
CV = notepad.getCurrentView()
and
CI = notepad.getCurrentDocIndex(CV)
or in a regular script, the sequence:
e.gotoPos(pCP)
wL = e.getWord(pCP)
One remaining 'problem' I noticed and you may care about. If a script starts with 'console.clear', it will hang on first run unless the console is opened. On subsequent runs, the console may be closed without any further freezing.
I also posted in 'discussion' an issue regarding the mapping of shortcuts.
Thanks Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been using Python Script for about a year and it helped a lot streamlining my work. Thanks a lot!
A recurring 2-part problem keeps recurring.
In STARTUP.py, a personalized version of 'addSaveStamp' apparently runs well.
It however is responsible for NPP to hang when I run certain other python scripts from NPP-menu as the problem goes away when I disable the " notepad.callback(addSaveStamp, [NOTIFICATION.FILEBEFORESAVE]) " line.
~~~~~~~
in STARTUP
import datetime
import os
def addSaveStamp(args):
FPN = notepad.getCurrentFilename()
FN = FPN.split("\")[-1]
EXT = FN.split(".")[-1].upper()
c = ""
if EXT == 'AHK': c = ";" + FPN
elif EXT == 'BAT': c = "rem " + FPN
elif EXT == 'TXT': c = FPN
elif EXT == 'EL': c = "//" + FN
elif EXT == 'PY': c = "#" + FPN
if c <> "":
CN = os.getenv('COMPUTERNAME')
UN = os.getenv('USERNAME')
s = str(datetime.datetime.today())
dt, ms = s.split(".")
l = editor.getLineCount()
b = editor.getTextLength()
s = c + " ;\t" + dt + " ;\t" + UN + " on " + CN + " ;\t" + str(l) + " lines ;\t" + str(b) + " bytes" + "\r\n"
line0 = editor.getLine(0)
#add line if beginning of line was changed OR file is edited on a different computer
if line0.find(c) == -1 or line0.find(CN) == -1 : editor.insertText(0, s)
else : editor.replaceWholeLine(0, s) #update line
#NB editor.deleteLine(0) # does not remove EOL on line0 as opposed to other lines!
notepad.callback(addSaveStamp, [NOTIFICATION.FILEBEFORESAVE])
sys.stdout = console
~~~~
NPP hangs when I run another script containing something like
aDict = {'cBlack' :'gBlack', 'cWhite' :'gWhite'} for s, r in aDict.iteritems(): # console.write("") editor.replace(s, r)AND also something like
~~~~~~
ListS = ["cBlack", "cWhite"]
ListR = ["gBlack", "gWhite"]
if len(ListS) == len(ListR):
for i in range(0, len(ListR)):
s = ListS[i]
r = ListR[i]
console.write("")
~~~~~
Strangely enough, the problem goes away if I insert a simple " console.write("") " line before calling the replace functions.
In summary, I have stumbled across a solution by trying to debug the problem but it is obviously not a logical solution!
I could find no reference to such a problem anywhere.
Perhaps somebody can explain what's happening?
Last edit: Kadner 2014-09-25
How do I get someone knowledgeable to comment/help ?
Last edit: Kadner 2014-09-25
Sorry I hadn't seen this. There was an issue fixed with deadlocks in 1.0.7
- are you using that version?
If you are, then I'll try and reproduce the issue. Deadlocks are actually
quite easy to get with callbacks, as there is all manor of magic happening
to manage the global interpreter lock (internal python thing, bit like a
baton that you have to have to run). Normally it's down to some call not
giving the baton up before it does it's thing, and then as a result of
whatever it did, a callback gets called, and wants the baton. If you can
confirm the version, I'll check the calls you're making.
Thanks,
Dave
On 25 Sep 2014 02:07, "Kadner" kadner@users.sf.net wrote:
Yes, I installed PythonScript_1.0.7.0.msi on NPP 6.6.9.
By the way, searching for help I stumbled upon "Welcome to PythonScript’s documentation! — PythonScript 1_0_1_0 documentation.htm" which seems more up to date than "PythonScript v0.9.2.0 documentation.chm" that still comes along with the package!
Ok, reproduced, and issue found (which incidentally may have been an issue in certain other unexplainable cases!)
The issue was that we were getting notifications from N++ for stuff that we're really not interested in (like when the toolbar sends a notification), and that was being triggered just at the point when we were calling an otherwise harmless "get" operation from N++. The knock on effect was that the callback needed to be checked (as soon as you register a callback, they're always checked), and to check them, we need the lock. We didn't used to give up the global interpreter lock (GIL) when we did "get" calls, but if a random notification was sent at the right moment, then we'd get a deadlock.
So, two things have changed.
I've made it so we always give up the GIL before calling into notepad or scintilla. This is probably overkill in 50% of the cases, but it stops deadlocks.
I've added a filter on the notifications, so we check if we're interested in the notification before we grab the GIL. This should help performance in the majority of cases (it actually adds a few cycles for a notification we are interested in, but it's so small it's not noticeable).
Expect a new version shortly. Many thanks for your detailed description, and code - it helped a lot to reproduce it.
Documentation
The file PythonScript.chm is included in the full.zip and the MSI version in the up to date 1.0.7 version. I don't know where you're getting either PythonScript 1_0_1 documentation.htm or PythonScript v0.9.2.0 documentation.chm from. The PythonScript.chm is the only chm included in any of the forms of the package. It's installed under Notepad++\plugins\doc\PythonScript\PythonScript.chm, which is where the plugin loads it from when you click on the "context help" menu option.
This is the most up to date version.
Cheers, and thanks again,
Dave.
Thank for looking into this!
I have other examples of "strange bugs" but will wait for next update and see if they are fixed before submitting them.
Re:Documentation
My apologies, I obviously did not look well enough in the NPP folders before googling!
http://www.brotherstone.co.uk/npp/ps/docs/1.0.1.0/scintilla.html is where Google found one file!
Again, thank you for Python Script
Ian
The update is there - try 1.0.8 and let me know!
The latest docs are always http://npppythonscript.sourceforge.net/docs/latest/
or http://www.brotherstone.co.uk/npp/ps/docs/latest/
Cheers,
Dave.
Update 1.0.8 solved several freezes I had. e.g.
in a startup def:
CV = notepad.getCurrentView()
and
CI = notepad.getCurrentDocIndex(CV)
One remaining 'problem' I noticed and you may care about. If a script starts with 'console.clear', it will hang on first run unless the console is opened. On subsequent runs, the console may be closed without any further freezing.
I also posted in 'discussion' an issue regarding the mapping of shortcuts.
Thanks Dave
Good to hear that the freezes are sorted.
I'll look into the console.clear issue - that should be fairly easy to
clear up (pun intended!) Thanks for reporting.
Dave.