I have reason to believe that my iPython interpreter is causing my kernel to die and restart similar to the issues logged in this link and that link.
The latter link indicates that the error is caused by the fact that the debugger outputs step-by-step ipdb content into the interpreter. One user reported that the behavior stopped when he (and I quote)
disabled logging to console before running in debug mode
How does one "disable logging to console" in Spyder IDE/IPython? I really need to do this so I can at least step through my code....
EDIT
I would like to suppress this kind of output
ipdb> > d:\temp\other const models\plaxis\output\plotparfile.py(16)PlotParFile()
14 with open(filename,'r') as fid:
15 lines = fid.readlines()
---> 16 fid.close()
17 #split first line get header and pop it out
18 header = lines[0].split()
> d:\temp\other const models\plaxis\output\plotparfile.py(18)PlotParFile()
16 fid.close()
17 #split first line get header and pop it out
---> 18 header = lines[0].split()
19 lines.pop(0)
20
(Spyder developer here) That output is generated automatically and its purpose is to tell you where are you placed in your code while debugging.
Right now there are no options in Spyder to deactivate it. Besides, I really doubt that output could be the cause of any kernel failures.
Related
Pylint exited with code 28 on Linux run. What does this error code mean?
I know it doesn't mean low on space as I tried the same command on a empty VM.
Answer + Examples:
(Note the pylint exit codes table below from pylint official site.
pylint exit codes conforms to 2 to the power of x (x = 0 to 5)
This is a crystal clear sign that they use a binary system for exit codes, this means that (as mentioned in the example within the image below) if exit code is:
28 - in binary: 0001 1100 (exit code 4, 8, 16 was triggered at least once for each)
63 - in binary: 0011 1111 (all error codes was triggered at least once for each which is the maximum errors combined)
Pyline exit code 28 on Linux and exit code 30 on Windows both mean that the config file that you are feeding in has an invalid configuration.
For me that was having underscores separating words instead of dashes. I had changed this because the wheel build deprecated dashes for flake8 and mypy but pylint needs to remain with dashes separating the words.
I had some difficulty posing my problem in a way that the Title filter found pleasing. The real problem is that modifying only the GhostPDF.PDD file in the GS9.26 installation in Windows 10 doesn't seem to affect the output after a re-installation using Windows 10 Device Installer.
I print to a networked Sun SPARCprinter 1 which is controlled by Ghostprint (script?) compiled to run on SunOS 4.1.4. This has worked successfully for some years printing output from Windows XP using Adobe's PS driver and a SPARCstation PPD cobbled together from samples found on the net.
I've installed Artifex's 9.26 on Windows 10 and output to an LPR printer (The Sun). The output works, is recognized as PS output by the Sun, but produces a number of FATAL errors.
I need to edit the Windows Ghostscript installation to output PS files which are more suitable for the Sun.
So to my simple question: Do I need to modify anything in the Ghostscript Windows 10 installation other than the Ghostpdf.PPD file?
additional info:
SPARCstation 10 information:
SunOS 4.1.4
arcad# gcc -dumpversion
2.95.2 Note: I had to bootstrap this version up from the early GCC which could be compiled with the SunOS 4.1.4 C compiler. I had the impression I couldn't bring it up any further but could be mistaken.
arcad# gs --help
Aladdin Ghostscript 6.01 (2000-03-17)
Copyright (C) 2000 Aladdin Enterprises ...
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
-dNOPAUSE no pause after page | -q `quiet', fewer messages
-g<width>x<height> page size in pixels | -r<res> pixels/inch resolution
-sDEVICE=<devname> select device | -dBATCH exit after last file
-sOutputFile=<file> select output file: - for stdout, |command for pipe,
embed %d or %ld for page #
Input formats: PostScript PostScriptLevel1 PostScriptLevel2 PDF
.....
For more information, see /usr/local/share/ghostscript/6.01/doc/Use.htm.
Note: I think this is the most recent GS version I can compile with this gcc version
printcap section:
gp|GhostPrinter:\
:lp=/dev/lpvi0:sd=/var/spool/gsprintspool:lf=/var/spool/gsprintspool/log:\
:mx#0:sh:if=/usr/local/libexec/lpfilter-gps:
Typical spool file - "....." indicates stuff not included here"
arcad# more dfA004DESKTOP-M8C5I86
%!PS-Adobe-3.0
%%Title: Document
%%Creator: PScript5.dll Version 5.2.2
%%CreationDate: 12/14/2018 19:56:8
%%For: jferg
%%BoundingBox: (atend)
%%Pages: (atend)
%%Orientation: Portrait
%%PageOrder: Special
%%DocumentNeededResources: (atend)
%%DocumentSuppliedResources: (atend)
%%DocumentData: Clean7Bit
%%TargetDevice: (Ghostscript) (3010) 815
%%LanguageLevel: 3
%%EndComments
%%BeginDefaults
%%PageBoundingBox: 0 0 612 792
%%ViewingOrientation: 1 0 0 1
%%EndDefaults
.....
%%EndResource
userdict /Pscript_WinNT_Incr 230 dict dup begin put
%%BeginResource: file Pscript_FatalError 5.0 0
userdict begin/FatalErrorIf{{initgraphics findfont 1 index 0 eq{exch pop}{dup
length dict begin{1 index/FID ne{def}{pop pop}ifelse}forall/Encoding
{ISOLatin1Encoding}stopped{StandardEncoding}if def currentdict end
/ErrFont-Latin1 exch definefont}ifelse exch scalefont setfont counttomark 3 div
cvi{moveto show}repeat showpage quit}{cleartomark}ifelse}bind def end
%%EndResource
userdict begin/PrtVMMsg{vmstatus exch sub exch pop gt{[
quires more memory than is available in this printer.)100 500
more of the following, and then print again:)100 485
put format, choose Optimize For Portability.)115 470
ce Settings page, make sure the Available PostScript Memory is accur--More--(2%)
ce the number of fonts in the document.)115 440
ocument in parts.)115 425 12/Times-Roman showpage
Error: Low Printer VM ]%%)= true FatalErrorIf}if}bind def end
2016 ge{/VM?{pop}bind def}{/VM? userdict/PrtVMMsg get def}ifelse
.....
SPARCprinter PDD file which works with Adobe PS in Windows XP:
john#hp2:~/sun-stuff/cups-sparc$ more SPARCprinter2.ppd
*PPD-Adobe: "4.1"
*% PostScript(R) Printer Description File for SPARCprinter
*% Date: 94/01/14
*% Copyright 1994 Sun Microsystems, Inc. All Rights Reserved.
*% Permission is granted for redistribution of this file as
*% long as this copyright notice is intact and the contents
*% of the file is not altered in any way from its original form.
*% End of Copyright statement
*% Changed margins on SPARCprinter JAF 3-3-2017
*FormatVersion: "4.1"
*FileVersion: "1.10"
*LanguageEncoding: ISOLatin1
*LanguageVersion: English
*PCFileName: "SPRN.PPD"
*Product: "(SPARCprinter)"
*PSVersion: "(3.000) 0"
*ModelName: "SPARCprinter"
*ShortNickName: "SPARCprinter"
*NickName: "SPARCprinter"
*% ==== Device Capabilities ===============
*LanguageLevel: "3"
*Extensions: CMYK Composite
*FreeVM: "4194304"
*ColorDevice: False
*DefaultColorSpace: Gray
*VariablePaperSize: False
*TTRasterizer: None
*FileSystem: False
..... more of the usual stuff
I don't really understand why you have installed Ghostscript on Windows. Windows is perfectly capable of producing PostScript files all of its own. In addition, the PPD file doesn't actually do very much, it is simply a text file with descriptions of the capabilities of the printer.
So the real problem is, or seems to be, that your SUN setup doesn't like the PostScript being produced by the new version of Windows.
You don't say how you are printing the PostScript file. not how your printer is 'controlled by Ghostscript' (I'm not aware of any product called Ghostprint, there is a GSPrint as part of GSView, but that's really for Windows).
Assuming you are using Ghostscript on your Sparc workstation to drive the pritner, then the most likely problem I would say is that you are using an old version of Ghostscript on the workstation, and it doesn't like the PostScript being generated by the newer version of Windows.
If you had included the transcript from the workstation Ghostscript installation it might be possible to say more but without that I'm rather guessing.
Another possibility is that you are using the ps2write device in Ghostscript to produce PostScript files on Windows. I can't think why you would be doing that, but it sort of fits your description. In that case editing the PPD file will have no effect, because Ghostscript doesn't use it.
Now the ps2write device emits level 2 PostScript, the clue is in the name, and its possible again that your Sparc setup is so elderly that it doesn't understand level 2, or doesn't fully implement it. In which case you will probably get errors. Again, if you were to provide the text of the error messages this would help!
In the latter case, you are frankly out of luck. We dropped support for level 1 PostScript output some time ago, what with level 2 being 28 years old now and level 3 coming up on 20. If you need language level 1 output you will have to go back to a very old version of Ghostscript. Something like 9.07 (from 5 and a half years ago) was the last version that included the pswrite device.
With effort you could take the pswrite device and upgrade it so that it works with the current version of Ghostscript
[EDIT]
My word, that's a really old version of Ghostscript!
You could try building a new version to replace it, but I also don't know if current code will compile on gcc 2.95. It 'should' because we only expect C89, but the third party libraries (which are essential) may very well not compile.
The PostScript file you quoted has been produced by Windows, not by Ghostscript (%%Creator: PScript5.dll Version 5.2.2). So it seems likely to me that your problem is the PostScript being produced by the newer version of Windows doesn't work with your 18 year old version of Ghostscript. That's not actually entirely surprising.
If you look at the DSC comments it says:
%%LanguageLevel: 3
And your Ghostscript information says that it supports language levels 1 and 2. At the time the level 3 spec had only just been published (1999), and clearly the maintainers back then hadn't had time to fully implement it.
Note that the ghostpdf.ppd file is intended for use with Ghostscript as a 'print to PDF' printer along with the RedMon port monitor.
Now its not obvious to me which PPD file you are using, but..... Both the ghostpdf.ppd file and the sparcprinter ppd file have :
*LanguageLevel: "3"
That tells the PostScript driver that it can use language level 3, which your Sparc Ghostscript doesn't support. You could try changing that to:
*LanguageLevel: "2"
and see if that makes a difference (you will have to uninstall the printers from Windows and re-install them with the modified PPD file).
If it doesn't work, the only other thing I can think of is to use the Ghostscript you installed on the Windows system, and preprocess the PostScript file produced by Windows before you send it on. You can use the ps2write device in Ghostscript 9.26 to take in the level 3 file, and produce a level 2 file. It might be a bit bigger, but it ought to work.
To do that on Windows you would use something like:
gswin64c -sDEVICE=ps2write -sOutputFile=out.ps <input.ps>
The file 'out.ps' should then be a level 2 PostScript file. I can't guarantee that the output will then work the old version of Ghostscript on your Sparc, but you stand a chance!
I'm trying to use DOSBox with debug.exe on a 64-bit system. It works perfectly fine if I enter the commands manually. When I redirect input from a file with:
debug < [file]
it doesn't work. On every line except for the first it displays an error similar to this:
DOSBox will eventually hang and crash. Is there any way to fix this?
The input file I am trying to process as commands is:
a 100
jmp 145
db 'Hello, World!', 0D, 0A, 'Press any key to continue . . .$'
a 145
mov ah, 09
mov dx, 102
int 21
mov ah, 08
int 21
int 20
rcx
100
n hello.com
w
q
I can reproduce the behavior you are seeing in this scenario:
DOSBox 0.74 on Windows and Linux
DEBUG.EXE from Windows XP copied to DOSBox
DEBUG.EXE from various versions of MS-DOS will cause problem including unexpected hangs. See this Stackoverflow question for another related problem.
I found a version of DEBUG.COM from FreeDOS that works as expected. I have made DEBUG.COM available for download from my website. Alternatively you can download the ZIP File from Softpedia and extract DEBUG.COM.
When I run DEBUG.COM I get this:
S:\>debug.com <hello.asm
-a 100
0BFB:0100 jmp 145
0BFB:0102 db 'Hello, World!', 0D, 0A, 'Press any key to continue . . .$'
0BFB:0131
-a 145
0BFB:0145 mov ah, 09
0BFB:0147 mov dx, 102
0BFB:014A int 21
0BFB:014C mov ah, 08
0BFB:014E int 21
0BFB:0150 int 20
0BFB:0152
-rcx
CX 0000
:100
-n hello.com
-w
Writing 00100 bytes
-q
S:\>hello
Hello, World!
Had same problem in DosBox 0.74 with DEBUG.EXE script redirection. Discovered that it could be fixed by changing the end-of-line characters in the script file from [CR][LF] to just [CR] when redirecting into DEBUG.EXE.
Pasting your file into the Scite editor and viewing the line-end characters showed this:
a 100{CR][LF]
jmp 145[CR][LF].... et cetera
I used an option in Scite to change the EOL characters to [CR] alone, getting
a 100{CR]
jmp 145[CR].... et cetera
saved the file, and was able to redirect it into DEBUG.EXE with no problem.
Not sure why [CR][LF] causes the issue with DEBUG.EXE, but hope this helps.
DEBUG.COM handles either EOL sequence with no glitch, so makes sense to use it instead, especially with its extended features. But one can use DEBUG.EXE it seems, with this fix, FWIW. The Scite editor is a neat tool.
I found the same problem running a script file for Debug within Dosbox.
but I found another editor: Notepad2. runs great and small and changes color to highlight assembler words.
Had to use debug ver 1.25 though.
Than you Michael Petch. I was trying everything to get the output of FreeDos clone of MS-DEBUG to save into a text file. But it was not the path, the speed, or the memory allotment that was blocking the redirection of output. It was indeed the line feed and cursor return combination. I quickly wrote a program to take out cursor return and leave line feed. It now redirects! I can also take out the line feed and leave the cursor returns, and DEBUG redirects to file as well. The small glitch is I have to access Windows outside the or close the DosBox window, for the outputted DEBUG code to become visible in a directory listing.
This is how I redirect DEBUG output to a file:
DEBUG < game.dbg > game.lst
I'm using jupyter (or Ipython) notebook with firefox, and want to debug some python code in the cell. I am using 'import ipdb; ipdb.set_trace()' as kind of breakpoint, for example my cell has the following code:
a=4
import ipdb; ipdb.set_trace()
b=5
print a
print b
which after execution with Shift+Enter gives me this error:
--------------------------------------------------------------------------
MultipleInstanceError Traceback (most recent call last)
<ipython-input-1-f2b356251c56> in <module>()
1 a=4
----> 2 import ipdb; ipdb.set_trace()
3 b=5
4 print a
5 print b
/home/nnn/anaconda/lib/python2.7/site-packages/ipdb/__init__.py in <module>()
14 # You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.
15
---> 16 from ipdb.__main__ import set_trace, post_mortem, pm, run, runcall, runeval, launch_ipdb_on_exception
17
18 pm # please pyflakes
/home/nnn/anaconda/lib/python2.7/site-packages/ipdb/__main__.py in <module>()
71 # the instance method will create a new one without loading the config.
72 # i.e: if we are in an embed instance we do not want to load the config.
---> 73 ipapp = TerminalIPythonApp.instance()
74 shell = get_ipython()
75 def_colors = shell.colors
/home/nnn/anaconda/lib/python2.7/site-packages/traitlets/config/configurable.pyc in instance(cls, *args, **kwargs)
413 raise MultipleInstanceError(
414 'Multiple incompatible subclass instances of '
--> 415 '%s are being created.' % cls.__name__
416 )
417
MultipleInstanceError: Multiple incompatible subclass instances of TerminalIPythonApp are being created.
The same error appears if I use this code not in the jupyter notebook in the browser, but in jupyter qtconsole.
What does this error mean and what to do to avoid it?
Is it possible to debug code in the cell step-by-step, using next, continue, etc commands of pdb debugger?
Had this problem also and it seems to be related to versions of jupyter and ipdb.
Solution is to use this instead of the ipdb library set_trace call:
from IPython.core.debugger import Tracer
Tracer()() #this one triggers the debugger
Source: http://devmartin.com/blog/2014/10/trigger-ipdb-within-ipython-notebook/
Annotated screenshot:
Tracer() is deprecated.
Use:
from IPython.core.debugger import set_trace
and then place set_trace() where breakpoint is needed.
from IPython.core.debugger import set_trace
def add_to_life_universe_everything(x):
answer = 42
set_trace()
answer += x
return answer
add_to_life_universe_everything(12)
This works fine and brings us a little bit more comfort (e.g. syntax highlighting) than just using the built-in pdb.
source
If using Jupyter Notebook
begin your cell with magic command "%%debug".
Then a ipdb line will be shown at the bottom of the cell which will help you navigate through the debugging session. Following commands should get you started:
n- execute current line and go to next line.
c- continue execution until next break point.
Make sure you restart the kernel each time you decide on debugging, so that all variables are freshly assigned.You can check the value of each variable through the ipdb line and you will see that the variable is undefined until you execute the line that assigns a value to that variable.
%%debug
import pdb
from pdb import set_trace as bp
def function_xyz():
print('before breakpoint')
bp() # This is a breakpoint.
print('after breakpoint')
My version of Jupyter is 5.0.0 and my corresponding ipython version is 6.1.0. I am using
import IPython.core.debugger
dbg = IPython.core.debugger.Pdb()
dbg.set_trace()
Tracer is listed as deprecated.
Update:
I tried using the method from another answer https://stackoverflow.com/a/43086430/8019692 below but got an error:
MultipleInstanceError: Multiple incompatible subclass instances of TerminalIPythonApp are being created.
I prefer my method to the %%debug magic since I can set breakpoints in functions defined in other cells and run the function in another cell. Jupyter/IPython drops into the debugger in my function where the breakpoint is set, and I can use the usual pdb commands. To each his own...
#lugger1, the accepted answer is deprecated.
When I execute on Windows7+Ruby1.9.2+watir-webdriver this test script:
# encoding: utf-8
require "rubygems"
require "watir-webdriver"
ie = Watir::Browser.new :ie
ie.goto "www.tilde.eu"
ie.select_list(:name => "tr-direction").select "Latvian-English"
ie.select_list(:name => "tr-direction").selected? "Latvian-English"
ie.text_field(:class => "tr-area").set "skolas dārzā aug divas priedes"
ie.element_by_xpath("/html/body/div[3]/div/div/div/section/div/div/div/form/table/tbody/tr/td[3]/input").click
Watir::Wait.until { ie.text.include? "About Tilde Machine Translation" }
puts ie.div(:class => "translate_text_result").text
Script executes fine as it is in Firefox, but IE9 crashes when trying to set "ā" letter in text field and CMD shows following:
No translation for key. Assuming unicode input: 257
Timeout awaiting keypress: 82
Key up failed: 1400
Key down failed: 1400
Timeout awaiting keypress: 90
Key up failed: 1400
No translation for key. Assuming unicode input: 257
Key down failed: 1400
Script executes completely in Chrome, but still some warning in CMD are shown:
Started ChromeDriver
port=52409
version=14.0.836.0
[0825/095000:WARNING:webdriver_key_converter.cc(271)] No translation for key code. Code point: 257
[0825/095000:WARNING:webdriver_key_converter.cc(271)] No translation for key code. Code point: 257
Do I need to specify anything else apart from # encoding: utf-8 for it to work correctly in IE and Chrome?
I suggest to excecute above script on your computer to determine if this is common issue or just something in my configuration.
This is a known bug in the IE driver, which you can follow here. The warnings in Chrome are harmless, though they probably shouldn't be printed by default.
I've discovered that issue is actual only if non-windows keyboard layout is set.
If any of standard windows layouts is set e.g. "Latvian(QWERTY)" on script execution machine, IE doesn't crash anymore just outputs warnings similar to Chrome.
Temporary hack until IE driver bug is fixed could be to set standard windows keyboard layout before execution of test suite and to revert to previous one after execution.
How to get the keyboard layout on windows with ruby? - for inspiration.