search

luser-dr00g / xpost

A PostScript interpreter in C
Other
93 stars 12 forks source link

run with error:xpost_interpreter.c:688 _onerror() cannot load #33

Open linhuikui opened 8 years ago

linhuikui commented 8 years ago

I just ./configure; make; make install, then run with xpost, and get some error massages: " ERR: src/lib/xpost_interpreter.c:688 _onerror() cannot load $error dict for error: undefinedfilename" Is there any wrong with my installation step???

vtorri commented 8 years ago

Hello

I have indeed the same error

i'm waiting for Josh to see what the problem is

luser-dr00g commented 8 years ago

Hi. I missed this until just now. It looks like a problem finding the data/*.ps files. Are you guys having this problem on all OSes?

vtorri commented 8 years ago

i've tested on Windows, not on linux yet

luser-dr00g commented 8 years ago

"undefinedfilename" is the postscript error which means the specified path does not exist. And this is triggering a program error because the error handler information is not loaded (it's in the *.ps files that it's not finding).

The place to fix it is further down at xpost_interpreter.c:1003 loadinitps (). For the installed case, we need to make sure the macro has the correct path string. Or we could try more patterns in the backup program in the other case, which uses generated postscript code. On Oct 21, 2015 2:29 PM, "vtorri" notifications@github.com wrote:

i've tested on Windows, not on linux yet

— Reply to this email directly or view it on GitHub https://github.com/luser-dr00g/xpost/issues/33#issuecomment-150001547.

luser-dr00g commented 8 years ago

All the code in src/bin/xpost_pathname.c is trying to determine whether to use the installed case or the backup code. So it looks like on windows, is_installed () is returning true, but in xpost_interpeter.c it's not doing the same thing it was checking.

This had been a big thorny design problem for a while: how to install it on windows. Is VS setting the macro correctly, like autoconf would?

vtorri commented 8 years ago

in xpost_pathname, there is a nice TODO : remove: no longer needed (line 89)

IIRC you were doing this because you didn't want to install the program. Just compile and test without installing. IMHO, you should remove that feature and we must install xpost to use/test it. Not a big problem, just have 2 terminals for UNIX or MinGW. I do that.

For VS, we must have an installer. It's doable.

The search path could be (in this order of search) :

1) an environment variable : XPOST_DATA_DIR 2) if it does not exist, use dladdr() to determine the path of the current process and look in ../data/*** 3) if it fails use PACKAGE_DATA_DIR is defined, use it and try to find the ps files from that path

this way, with VS, we have the options 1) and 2) which will work anyway.

what do you think ?

luser-dr00g commented 8 years ago

Yes. That sounds like a good strategy. The play just ended so I should have some time to work on it this week. On Oct 22, 2015 12:52 AM, "vtorri" notifications@github.com wrote:

in xpost_pathname, there is a nice TODO : remove: no longer needed (line 89)

IIRC you were doing this because you didn't want to install the program. Just compile and test without installing. IMHO, you should remove that feature and we must install xpost to use/test it. Not a big problem, just have 2 terminals for UNIX or MinGW. I do that.

For VS, we must have an installer. It's doable.

The search path could be (in this order of search) :

1) an environment variable : XPOST_DATA_DIR 2) if it does not exist, use dladdr() to determine the path of the current process and look in ../data/*** 3) if it fails use PACKAGE_DATA_DIR is defined, use it and try to find the ps files from that path

this way, with VS, we have the options 1) and 2) which will work anyway.

what do you think ?

— Reply to this email directly or view it on GitHub https://github.com/luser-dr00g/xpost/issues/33#issuecomment-150114095.

luser-dr00g commented 8 years ago

As a point of fact, the installed /not - installed jury rig was for testing the ps files, not the c part. So I could just save and run like normal postscript workflow.

The rest is true. On Oct 25, 2015 6:13 PM, "luserdroog ." luser.droog@gmail.com wrote:

Yes. That sounds like a good strategy. The play just ended so I should have some time to work on it this week. On Oct 22, 2015 12:52 AM, "vtorri" notifications@github.com wrote:

in xpost_pathname, there is a nice TODO : remove: no longer needed (line 89)

IIRC you were doing this because you didn't want to install the program. Just compile and test without installing. IMHO, you should remove that feature and we must install xpost to use/test it. Not a big problem, just have 2 terminals for UNIX or MinGW. I do that.

For VS, we must have an installer. It's doable.

The search path could be (in this order of search) :

1) an environment variable : XPOST_DATA_DIR 2) if it does not exist, use dladdr() to determine the path of the current process and look in ../data/*** 3) if it fails use PACKAGE_DATA_DIR is defined, use it and try to find the ps files from that path

this way, with VS, we have the options 1) and 2) which will work anyway.

what do you think ?

— Reply to this email directly or view it on GitHub https://github.com/luser-dr00g/xpost/issues/33#issuecomment-150114095.

luser-dr00g commented 8 years ago

The is_installed parameter has been removed, and the search strategy has be reimplemented. You can now define the environment variable XPOST_DATA_DIR to locate the ps files. This should work on windows, too, even though we don't have an installer yet.

vtorri commented 8 years ago

and normally, on UNIX and MSYS, if installed, xpost should find the postscript files, now. The strategy is the one described in https://github.com/luser-dr00g/xpost/issues/33#issuecomment-150114095