I got an postscript file from a NCL script whit the mpDataBaseVersion = "HighRes" (high resolution map). and I got ImageMagick 6.2.8 run in RHEL 5.6 i386.
when I ran convert high-resolution.ps test.png, I got:
Error: /undefinedresult in --ashow--
Operand stack:
0 0 ( )
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop 1787 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval--
Dictionary stack:
--dict:1171/1684(ro)(G)-- --dict:0/20(G)-- --dict:143/200(L)--
Current allocation mode is local
Current file position is 629039
but the same postscript convert without error in RHEL 3 i386 with ImageMagick 5.5.6, how come?
I googled for a while, but I still have no idea for that undefinedresult in ashow error.
and what was the execution stack means?
[UPDATE]
Thanks, #Fred and #Ken !
I restructured my problem below:
I have a big PostScript file (9.3 MB): high_resolution.ps
PC A:
Red Hat Enterprise Linux ES release 3 (Taroon Update 3) i386
Convert Version: ImageMagick 5.5.6 04/01/03 Q16
Ghostscript Version: GNU Ghostscript 7.05 (2002-04-22)
PC B:
Red Hat Enterprise Linux Server release 5.6 (Tikanga) i386
Convert Version: ImageMagick 6.2.8 05/07/12 Q16
Ghostscript Version: GPL Ghostscript 8.70 (2009-07-31)
convert high_resolution.ps high_resolution.png works in PC A, but not in PC B.
the error was above.
and I check the Ghostscript changelog, I got nothing about that (maybe I just missed it ?)
A lots of appreciation!
謝謝！
Almost certainly you are using different versions of Ghostscript (which ImageMagick uses to deal with PostScript). What version of Ghostscript do you have installed on each ?
Undefinedresult means what it says, the result of an operation is undefined (this is usually caused by a divide-by-zero). The execution stack tells you what was on the execution stack at the point the interpreter encountered the error. Unless you understand Postscript (and to be honest, the Ghostscript interpreter) it doesn't tell you anything meaningful.
I can't say any more without seeing the file which causes the error. Remember, PostScript is a programming language, so error messages are just a starting point.
UPDATE
I've retrieved the file and I can confirm that I get the error when running it through a current version of Ghostscript. Adobe Acrobat Distiller gives a very similar error (undefinedresult with setcachedevice) so its practically certain that the file is illegal. I'll say more when I've had a chance to determine why.
On a side note, both these versions of Ghostscript are very elderly, the current version is 9.07
[Update 2]
The offending line is very near the beginning of the file :
/Helvetica 0 Fs 0 0 ( ) As Gr
Because PostScript is a programming language, this fragment uses some procedures defined in the program. What it does is find a font called 'Helvetica', scale it to a size of 0 then show the string ' ' adjusting the width of each glyph by 0.
Several parts of that are clearly nonsense; scaling a font to 0 will make it useless, at best a glyph will mark 1 pixel. showing a string using an operator to adjust the width of each glyph by 0 is clearly pointless. Smarter software wouldn't produce such a PostScript program, but the producer clearly isn't very smart about producing PostScript as can be seen from the rather simple prolog to the file.
Basically the problem is exactly what GS said, the x and y widths are adjusted by using a matrix, and the result of applying the matrix multiplication to a font size of 0 is genuinely undefined.
Your best bet is probably to go back to the original application and remove whatever is causing the text ' ' to be emitted.
If for some reason this is impossible, you can take advantage of the fact that PostScript is a programming language, you can redefine the /ashow operator yourself and have it do nothing if the font size is 0, eg:
/old_ashow /ashow load def
/ashow {currentfont /FontMatrix get aload pop pstack 0 1 4 {pop add} for 0 eq {pop pop pop}{old_ashow}ifelse} bind def
Normally I would suggest putting this in a new file and running it through Ghostscript in advance of the file you want to process (eg 'gs mod.ps high_resolution.ps') but because you are using ImagMagick you can't do that. So if you want to do this you will need to modify the high_resolution.ps file and put this at the top of the file. Whenever you modify PostScript files you must be careful to use an editor which can handle binary, and does not alter CR/LF line endings.
Please note that I don't recommend this, it would be better to fix the original file or script producing this PostScript program so that you can use it in other places (eg printing). As it stands it is producing illegal PostScript.
As to why the error does not occur with an (exteremely) old version of Ghostscript; this is almost certainly an oversight. The Adobe Postscript Language Reference Manual lists the possible errors for each operator, but not all the possible circumstances under which an error is raised. Clearly this error condition was added after the release of 7.05, almost certainly when the problem was brought to the developers attention.
The ashow displays text with added extra space to a character. The stack 0 0 tells the system to add zero extra space to the characters. The ( ) is the text to be displayed, which appears to be a single space, but without seeing the actual file in binary it could also be an none displayable character.
If the character is a special character which is not defined, such as a tab character or null, an undefinedresult would make sense. Having a single only a 1 character string might also not make sense.
As already mentioned, what version of ghostscript and seeing the actual file would be helpful.The postmortem dump isn't especially useful, but the execution stack appears like there is a more complex context the error is coming out of.
Related
I am trying to use the pipe character "|" in SPSS syntax with strange results:
In the syntax it appears like this:
But when I copy this line from the syntax window to here, this is what I get:
SELECT IF(SEX = 1 SEX = 2).
The pipe just disappears!
If I run this line, this is the output:
SELECT IF(SEX = 1 SEX = 2).
Error # 4007 in column 20. Text: SEX
The expression is incomplete. Check for missing operands, invalid operators,
unmatched parentheses or excessive string length.
Execution of this command stops.
So the pipe is invisible to the program too!
When I save this syntax and reopen it, the pipe is gone...
The only way I found to get SPSS to work with the pipe is when I edited the syntax (adding the pipe) and saved it in an alternative editor (notepad++ in this case). Now, without opening the syntax, I ran it from another syntax using insert command, and it worked.
EDIT: some background info:
I have spss version 23 (+service pack 3) 64 bit.
The same things happens if I use my locale (encoding: windows-1255) or Unicode (Encoding: UTF-8). Suspecting my Hebrew keyboard I tried copying syntax from the web with same results.
Can anyone shed any light on this subject?
Turns out (according to SPSS support) that's a version specific (ver. 21) bug and was fixed in later versions.
I'm learning COBOL programming and using GNUCobol (on Linux) to compile and test some simple programs. In one of those programs I have found an unexpected behavior that I don't understand: when reading a sequential file of records, I'm always getting one extra record and, when writing these records to a report, the last record is duplicated.
I have made a very simple program to reproduce this behavior. In this case, I have a text file with a single line of text: "0123456789". The program should count the characters in the file (or 1 chararacter long records) and I expect it to display "10" as a result, but instead I get "11".
Also, when displaying the records, as they are read, I get the following output:
0
1
2
3
4
5
6
7
8
9
11
(There are two blank spaces between 9 and 11).
This is the relevant part of this program:
FD SIMPLE.
01 SIMPLE-RECORD.
05 SMP-NUMBER PIC 9(1).
[...]
PROCEDURE DIVISION.
000-COUNT-RECORDS.
OPEN INPUT SIMPLE.
PERFORM UNTIL SIMPLE-EOF
READ SIMPLE
AT END
SET SIMPLE-EOF TO TRUE
NOT AT END
DISPLAY SMP-NUMBER
ADD 1 TO RECORD-COUNT
END-READ
END-PERFORM
DISPLAY RECORD-COUNT.
CLOSE SIMPLE.
STOP RUN.
I'm using the default options for the compiler, and I have tried using 'WITH TEST {BEFORE|AFTER}' but the result is the same. What can be the cause of this behavior or how can I get the expected result?
Edit: I tried using an "empty" file as data source, expecting a 0 record count, using two different methods to empty the file:
$ echo "" > SIMPLE
This way the record count is 1 (ls -l gives a size of 1 byte for the file).
$ rm SIMPLE
$ touch SIMPLE
This way the record count is 0 (ls -l gives a size of 0 bytes for the file). So I guess that somehow the compiled program is detecting an extra character, but I don't know how to avoid this.
I found out that the cause of this behavior is the automatic newline character that vim seems to append when saving the data file.
After disabling this in vim this way
:set binary
:set noeol
the program works as expected.
Edit: A more elegant way to prevent this problem, when working with data files created from a text editor, is using ORGANIZATION IS LINE SEQUENTIAL in the SELECT clause.
Since the problem was caused by the data format, should I delete this question?
I'm toying with Rakudo Star 2015.09.
If I try to stringify an integer with a leading zero, the compiler issues a warning:
> say (~01234).WHAT
Potential difficulties:
Leading 0 does not indicate octal in Perl 6.
Please use 0o123 if you mean that.
at <unknown file>:1
------> say (~0123<HERE>).WHAT
(Str)
I thought maybe I could help the compiler by assigning the integer value to a variable, but obtained the same result:
> my $x = 01234; say (~$x).WHAT
Potential difficulties:
Leading 0 does not indicate octal in Perl 6.
Please use 0o1234 if you mean that.
at <unknown file>:1
------> my $x = 01234<HERE>; say (~$x).WHAT
(Str)
I know this is a silly example, but is this by design? If so, why?
And how can I suppress this kind of warning message?
Is there a reason you have data with leading zeroes? I tend to run into this problem when I have a column of postal codes.
When they were first thinking about Perl 6, one of the goals was to clean up some consistency issues. We had 0x and 0b (I think by that time), but Perl 5 still had to look for the leading 0 to guess it would be octal. See Radix Markers in Synopsis 2.
But, Perl 6 also has to care about what Perl 5 programmers are going to try to do and what they expect. Most people are going to expect a leading 0 to mean octal. But, it doesn't mean octal. It's that you typed the literal, not how you are using it. Perl 6 has lots of warnings about things that Perl 5 people would try to use, like foreach:
$ perl6 -e 'foreach #*ARGS -> $arg { say $arg }' 1 2 3
===SORRY!=== Error while compiling -e
Unsupported use of 'foreach'; in Perl 6 please use 'for' at -e:1
------> foreach⏏ #*ARGS -> $arg { say $arg }
To suppress that sort of warning, don't do what it's warning you about. The language doesn't want you to do that. If you need a string, start with a string '01234'. Or, if you want it to be octal, start with 0o. But, realize that stringifying a number will get you back the decimal representation:
$ perl6 -e 'say ~0o1234'
668
I have what I feel should be a very simple bit of code in Common Lisp, all I want it to do is ask for an input from the user, then print it back.
This is my code (The "Before" and "After" printing is from trying to debug, and it showed something odd.
(defun get-input (prompt)
(clear-input)
(write-string prompt)
(finish-output)
(read-line)
)
(let (
(p1 (get-input "Enter: "))
)
(princ "Before")
(princ p1)
(princ "After")
)
When I run this I get the following
This is SBCL 1.2.1, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
WARNING: the Windows port is fragile, particularly for multithreaded
code. Unfortunately, the development team currently lacks the time
and resources this platform demands.
* (load "test.lisp")
Enter: This is my string.
AftereThis is my string.
T
As you can see, my "Before" string isn't even printed, and my "After" string has a strange "e" on the end? And why is it seemingly asking for input when I first run the program?
If anyone could help I would be grateful. Thanks
I believe this is what is happening, in order:
The program evaluates the expression to be bound to p1; this generates your prompt & reads your input
Then it prints "Before"
Then it prints the value of p1, which (I think) has a carriage return at the end, so that the next thing to be printed goes at the start of the line
Then it prints "After", overwriting the first 5 characters of "Before"
Additional Information from sam: SBCL under Windows.
Well, yeah. SBCL's port to Windows is very rough.
See the warning in your output:
WARNING: the Windows port is fragile, particularly for multithreaded
code. Unfortunately, the development team currently lacks the time
and resources this platform demands.
SBCL comes from the Linux/Unix/... world. The port to Windows makes assumptions which are valid for Linux/Unix/... but not for Windows.
One thing is line termination. Windows uses CRLF. Unix uses LF. SBCL under Windows uses LF, IIRC. Probably this can be configured somehow.
If you now use a shell under Windows which expects CRLF conventions and create direct output with SBCL using LF conventions, then you may get strange output...
Thus possible solutions are:
use a Lisp which support Windows conventions. Problem: there are not many. There are really good ones like LispWorks and Allegro CL, but they are relatively expensive. I don't know how Clozure CL does it - it also runs under Windows and is free...
find out how to configure SBCL to use Windows I/O conventions. -> SBCL mailing list
reconfigure your terminal/shell to use Unix LF conventions
I can't reproduce that (CLISP and SBCL in a terminal on the Mac):
CLISP
rjmba:~ joswig$ clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Welcome to GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010
Type :h and hit Enter for context help.
[1]> (load "/tmp/g.lisp")
;; Loading file /tmp/g.lisp ...
Enter: hello
BeforehelloAfter
;; Loaded file /tmp/g.lisp
T
[2]> (quit)
SBCL
rjmba:~ joswig$ sbcl
This is SBCL 1.1.16, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (load "/tmp/g.lisp")
Enter: hello
BeforehelloAfter
T
You might want to tell us your specific implementation and platform combination, plus where Common Lisp does its output...
I've been using Doxygen successfully to generate PDF documentation for a sizable Fortran 90 project since v1.6. After a recent upgrade to Doxygen 1.8, pdflatex is choking with an error I can't understand. From refman.log:
.
.
.
<use classfate__source_a022bf629bdc1d3059ebd5fb86d13b4f4_icgraph.pdf>
Package pdftex.def Info: classfate__source_a022bf629bdc1d3059ebd5fb86d13b4f4_ic
graph.pdf used on input line 607.
(pdftex.def) Requested size: 350.0pt x 65.42921pt.
)
(./classm__aerosol.tex
! Undefined control sequence.
<recently read> \LT#LL#FM#cr
l.25 ...1833ffa6f2fae54ededb}{ia\-\_\-nsize}), \\*
? ?
Type <return> to proceed, S to scroll future error messages,
R to run without stopping, Q to run quietly,
I to insert something, E to edit your file,
1 or ... or 9 to ignore the next 1 to 9 tokens of input,
H for help, X to quit.
Looking at the first 25 lines of classm__aerosol.tex, nothing obviously matches the error message:
\hypertarget{classm__aerosol}{\section{m\-\_\-aerosol Module Reference}
\label{classm__aerosol}\index{m\-\_\-aerosol#{m\-\_\-aerosol}}
}
Contains general aerosol-\/related constants and routines.
\subsection*{Public Member Functions}
\begin{DoxyCompactItemize}
\item
subroutine \hyperlink{classm__aerosol_aa06c1f39c6bd34f22be92d21535f0320}{aerdis} (I\-A\-E\-R\-O, M\-A\-E\-R\-O, V\-O\-L, A\-R\-E\-A, M\-U, T\-G\-A\-S, R\-H\-O, A\-G\-A\-M\-M\-A, X\-L\-A\-E\-R, D\-M\-E\-A\-N, N\-A\-E\-R, X\-N\-D\-A\-E\-R, L\-S\-D\-A\-E\-R)
\begin{DoxyCompactList}\small\item\em Return aerosol mass given a volume, based on aerosol size distribution function. \end{DoxyCompactList}\item
real(kind=wp) function \hyperlink{classm__aerosol_a2dff4ff413057e8788fba7270a30c093}{lamsed} (V\-O\-L, H, M\-U\-G, R\-H\-O\-A\-E\-R, A\-G\-A\-M\-M\-A, A\-C\-H\-I, A\-F\-E\-O, K\-O, M\-A\-E\-R, F\-M\-A\-E\-R, F\-A\-E\-R\-S\-S, F\-S\-E\-D\-D\-K)
\begin{DoxyCompactList}\small\item\em Calculate aerosol removal constant and interpolation factor between steady-\/state and decaying aerosol correlations. \end{DoxyCompactList}\item
pure real(kind=wp) function \hyperlink{classm__aerosol_a6d0a04004f49c404c67e0aa69dd39ee1}{fdbend} (V\-E\-L, H\-S\-E\-D, T\-G, R\-H\-O\-G, M\-U\-G, R\-H\-O\-P\-A\-R, C\-A\-E\-R\-O, X\-D\-B\-E\-N\-D, N90\-J)
\begin{DoxyCompactList}\small\item\em Find total impaction efficiency for aerosol deposition considering 90-\/degree bends in a flow path. \end{DoxyCompactList}\end{DoxyCompactItemize}
\subsection*{Public Attributes}
\begin{DoxyCompactItemize}
\item
integer, parameter \hyperlink{classm__aerosol_a8f604b7ffe3c1833ffa6f2fae54ededb}{ia\-\_\-nsize} = 30
\item
integer, parameter \hyperlink{classm__aerosol_ae71813ecf0c7768af9d6292efb14774f}{ia\-\_\-nmass} = 10
\item
real(kind=wp), dimension(\hyperlink{classm__aerosol_a8f604b7ffe3c1833ffa6f2fae54ededb}{ia\-\_\-nsize}), \\*
Nothing obviously matches the recently read chunk "\LT#LL#FM#cr" and I don't know enough low-level TeX to translate that into something that might actually be in the source text.
Suspecting this might have been fixed in a later version of Doxygen than the one shipping with Linux Mint (v1.8.1.2), I built & installed v1.8.3.1 from source, updated my doxyfile, blew away the old documentation and regenerated it. I get the same baffling error.
There's nothing obvious in refman.log that would indicate missing or broken LaTeX packages and I'm completely at a loss as to what's causing this.
As this still gets a hit on Google when you search:
doxygen missing $ inserted
I would like to add something.
Do not use a PROJECT_NAME containing underscores (_)!
After a brief look into the doxygen's current documentation (I am using 1.8.4) it does not make that explicit.
this will be difficult to solve unless you provide a bit more information - possibly using \errorcontextlines=9999 as suggested in the comments on the question.
as a first short though, the name of the control sequence that can't be found (i.e. \LT#LL#FM#cr) is one defined by the longtable package (documentation, p. 15) - thus adding:
\usepackage{longtable}
to the preamble of the document might help.
If so, according to the doxygen documentation here, adding the following to your configuration file should do the trick:
EXTRA_PACKAGES=longtable