The scenario is easy - I create PDFs with wkhhtmltopdf, and sometimes I struggle with things like
window.performance
not supported by this version.
So scripts are not fully executed.
Until now my way to find errors like that, was to use the very old Windows Safari browser, that helped me finding these errors.
But now I have a script error with the old wkhtmtlopdf, that does not even show in windows Safari.
I found it (or not really) with heavy and nasty script changing (comment out the half), but I would like to know if there is a way to get the correct error with wkhtmtlopdf while parsing.
Run wkhhtmltopdf with the command line using --debug-javascript argument.
I should mention that I originally posted this as an issue on Neovim's tracker, but it hasn't been getting a ton of traction there lately and I'm beginning to suspect that it's more an issue with my setup rather than Neovim itself.
Essentially, I had stopped building neovim nightlies for a few months. Having heard that it's getting integrated terminal support I decided to rebuild using the latest source, only to get a persistent, odd error. No matter what my build settings are, it always boils down to make hitting an error when it has to compile a file called loop.so. I hadn't noticed this issue with any other software I try to build, but I suspect it could be an issue with my environment.
Does anyone here know what this file's role is, and why the compilation could be failing at that point?
You might need to install the full Xcode app and not just the command line. This fixed the issue for me.
The issue turned out to be a bad typedef in a libuv header, object.h.
I am trying to help someone get setup running nose tests. They are running into an error I have never seen before. A google search seems to be yielding results for Java, but not Python.
Below is a screenshot of the error:
Any ideas on how to correct this error?
I have tried uninstalling and re-installing Python. I have verified that the settings are correct as well as the parameters for the nose test. The PATH variables for Python are likewise correct.
Not sure what is going on here.
After trying and failing to run the test from the terminal, I was able to determine that the PATH variables were incorrect after all. I fixed them, and then logged off and back on again, and the issue is fixed.
I've been trying to build linphone for android for a few days now but I've come to a point where I'm unable to fix the problem I encounter in the build process.
I've been following the provided readme step by step and also tried several ways explained here in SO questions but non get me passed this current point.
http://pastebin.com/gxmc2gwZ
The above pasbin link shows the output of my mingw32 window when I run make. At the end it just holds. It feels like make just goes into an infinite loop. I've left it running overnight but it stays at that exact spot. The only way to stop it is ctrl-c.
Sofar I've used 3 difirent android NDK builds thinking there might be an incompatability.
r8e, r7c and r7 dont work. r7 doesn't even get this far.
I've also tried running make with SHELL="sh -x" but the resulting output is hardly difirent (as expected).
I've tried searching on google but all hits always show an error in the logs. Mine does not.
If anyone has any idea what can cause it to hang that would be REALLY appriciated.
I fixed the problem by running ndk-build.cmd from the project root directory in a command prompt instead of using make in mingw wich called the linux version. my project is now happely compiling along.
I am reading through Informix 4GL By Example. Ex4 is giving a segmentation fault so I am attempting to use the debugger to find out where the program is failing, but the debugger is not working.
From within r4gl, I can compile forms and modules. But when I debug it shows a blank screen with
"Press Return to continue".
From the command line fgldb returns the following error:
fgldb: symbol lookup error: fgldb: undefined symbol: kw__numkws
DB is up and running, I can isql in and run queries.
System details:
OpenSuSE 12.1 32 bit
Informix RDS 7.50 UC6
Informix SQL DEV 7.50 UC6
Informix Growth Edition 11.70 UC5
Informix Interactive Debugger 7.50 UC6
I have searched the net, but have not found anything helpful. Any idea what's wrong?
UPDATE 1:
Thank you again for the assistance. I will be trying to install in a seperate directory and let you know. This is probably blonde but how do I install in a different directory. If I attempt to I get errors:
"INFORMIXDIR and working directory do not match."
"INFORMIXDIR = /usr/informix"
"Current working directory = /usr/informix/i4gl"
Can I edit $INFORMIXDIR to match where I want to install?
Many thanks,
Neill
UPDATE 2:
OK, so I got them both installed in /usr/informix/i4gl.
Set variables to point to that directory, not sure exactly which ones need to though because I still receive errors.
fgldb: -16326: Cannot open file 'fgldb.iem'
The /usr/informix/i4gl does contain a directory msg/en_us/0333, but that file does not exist there, while /usr/informix/msg/en_us/0333 does include the fgldb.iem file.
isql -> Query Language: Says SELECT DATABASE, but none or shown for me to select.
Kind regards
Neill
UPDATE 3:
OK, my blonde momnets are getting crazy now, but after installing into /usr/informix/i4gl, I never changed back the $INFORMIXDIR variable. I did this and then stopped and started the DB.
Now when trying to compile the demo f_custkey.per (using stores_demo db as before) form, I get errors -329 and -2810, which are to do with the database not found.
I am not sure if this is what you were talking about in your last statement. I am unsure if splitting these two into seperate directories has solved my debugger issue because now I can't compile anything, but I sense I am getting close.
Kind regards,
Neill
UPDATE 4 - Final!
OK, so it is working now.
Ran the dbaccessdemo7 command again to recreate the database and all is well in the land of nod.
Compiling and debugging ex4 now works.
Thank you so much for all the information. Learning as I go.
Kind regards
Neill
The kw_numkws issue is fixed post 7.50.UC6. So the next available fixpack will have the fix.
In the interim, IBM Technical Support has posted a "Tech Alert" advising customers to install I4GL (and ISQL) in a separate directory - option #2 suggested by Jonathan Leffler above.
The core dump/crash that you're hitting is an unfortunate bug that we found out about earlier this week. The ESQL/C code is fixed (as of today), but the fixed releases are not yet available, and won't be for a while (read 'until after Thanksgiving at the earliest'). The I4GL and ISQL code still has to be fixed (some separate, but closely related problems).
What's happened is that a structure changed size in the CSDK. I4GL will be compiling the code with the one size and the CSDK libraries are expecting another size; the difference is about 4 bytes.
This leads to hard to track memory overwriting.
The kw__numkws issue is an older problem that I thought was fixed in 7.50.UC6. I'll have to check whether that release did get the fix, and if so, how you are seeing that error still.
There are a couple of short-term options that should get you going until a fixed ensemble is available:
Reinstall I4GL (and ISQL) in the server directory. I've not proved that this will work. The concept is to make sure I4GL is using the CSDK libraries it was built with, rather than the updated 3.70.xC6 version.
Reinstall I4GL (and ISQL) in a separate directory (/opt/IBM/i4gl, perhaps). Have a suitable sqlhosts file in this directory; it might be a symlink to the one in the IDS directory. Point the I4GL programs at this alternative directory, setting LD_LIBRARY_PATH appropriately.
Option 2 ensures that I4GL is using the 'correct' CSDK. Option 1 may achieve the same result, but I'm not ready to guarantee it. Consequently, I suggest option 2.
If your I4GL code needs to run DB-Access or other programs found in the server $INFORMIXDIR, there are ways to deal with that — indicate in a comment and I'll explain, but I'd rather not confound you if there's no need. (It's not dreadfully hard, but it isn't completely trivial either.)
Option 3. is to discover what CSDK was used to create the 4GL tools and install THAT instead of the current one. In the case of 4GL 7.50FC6 it CSDK 3.70FC4.
I had problems splitting up the engine and the tools. This appears to work, so far.