I have some MagickWand code where the MagickReadImage() fails (returns MagickFalse) on one system where it works on the other.
Now there is no exception occuring, MagickGetException() returns an empty string which means no exception if I understood the documentation correctly.
The file I want to open is there, I can open it with other tools under the same user, and the magick_wand I use is not NULL.
The code around the call is essentially this:
// read image
MagickBooleanType status = MagickReadImage(magick_wand, fn_selector);
// make sure it worked
if (status == MagickFalse)
{
char *description;
ExceptionType severity;
description=MagickGetException(magick_wand,&severity);
fprintf(stderr,"%s %s %lu :%s: %u\n",GetMagickModule(),description,severity);
description=(char *) MagickRelinquishMemory(description);
fprintf(stderr, "magickwand couldn't read file %s\n", fn_selector);
exit(1);
}
Is there any way to find out why the function call fails? MagickReadImage() seems to call an internal function which is not easily debuggable, and I don't want to build the MagickWand library myself with added debug stuff if not absolutely necessary.
Using MagickWand version 6.8.9.9 (debian jessie)
Turns out (after going through an strace) the PDF reading part of ImageMagick requires the ghostscript executable (/usr/bin/gs) to be installed on the system. Now when installing ImageMagick via the Debian apt package manager, ghostscript is not a dependency, only a recommend of the Magick library. Unfortunately Magick does not think it's necessary to inform you in any way that a library component is missing when the read call fails.
After installing the ghostscript package, everything works as expected.
Related
I'm currently facing an issue on a project using libvpx v1.10.0 ( https://github.com/webmproject/libvpx/releases ).
I have successfully built the library for Visual Studio 16 on Windows 10 (PC x64).[I must build libvpx by my own since I need it to run on a Windows 10 ARM64 / VS16 as well (Hololens 2) and a such build is not officially provided]
I've made a C++ DLL that uses the static libs from libvpx (to be used as a native plugin in Unity).
While the VP9 encoding part seems to work correctly in a sample app using my DLL, I cannot initialize the VP9 decoder. Maybe I am missing something in the configuration step of libvpx?
To build the libvpx static libraries, I have launched MSYS2 from the x64 Native Tools Command Prompt of Visual Studio 2019.
Then, I have set the configuration as follows, inspired by what we can find in an ArchLinux AUR package ( https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=libvpx-git ):
./configure --target=x86_64-win64-vs16 --enable-libyuv \
--enable-vp8 --enable-vp9 --enable-postproc --enable-vp9-postproc \
--enable-vp9-highbitdepth --enable-vp9-temporal-denoising
make -j
At the end of the compilation, the build succeeds with 0 error but 2 warnings. The --help of the configure scripts indicates that the --enable-vp9 option enables both the VP9 encoder and decoder.
Then, when I run my app using the C++ DLL that performs the encoding and decoding stuff, I get this error message from libvpx:
Codec does not implement requested capability .
It occurs when I call the vpx_codec_dec_init() function. I don't understand why it cannot be initialized as I think that the VP9 codec is fully built. The error appears as well when I add the --enable-vp9-encoder and --enable-vp9-decoder` options and all other VP9 related options to the configuration.
Is there something to do in the code itself before initializing the VP9 decoder? I have not seen a such thing in the samples of code. Notice that the problem occurs if I use VP8 as well (encoding OK / decoding KO, same error).
Here is the beginning of my function for decoding a frame:
vpx_codec_err_t resultError;
vpx_codec_ctx_t codec;
const vpx_codec_iface_t* decoderInterface = vpx_codec_vp9_cx(); // >>> OK!
if (!decoderInterface)
{
return "libvpx: unsupported codec (decoder)";
}
resultError = vpx_codec_dec_init(&codec, decoderInterface, nullptr, 0); // >>> KO...
if (resultError)
{
std::cout << vpx_codec_error(&codec) << std::endl; // outputs "Codec does not implement requested capability"
return "libvpx: failed to initialize decoder";
}
vpx_codec_iter_t iter = nullptr;
vpx_image_t* yuvFrame = nullptr;
resultError = vpx_codec_decode(&codec, compressedFrame, (unsigned int)compressedFrameSize, nullptr, 0);
if (resultError)
{
return "libvpx: failed to decode frame";
}
// ....
Any help would be great! Thank you. :)
OK, I've figured it out! :)
The line:
const vpx_codec_iface_t* decoderInterface = vpx_codec_vp9_cx();
must be replaced by (+ #include <vpx/vp8dx.h>):
const vpx_codec_iface_t* decoderInterface = vpx_codec_vp9_dx();
The reason I have made this error is due to a previous experience in encoding/decoding videos. I've developed a webcam streaming app using the H.264 codec, which needs a set up "context" structure. So, because of the name of the vpx_codec_vp9_cx() function, I've thought it was creating a such context for VP9. In fact, cx matches for encoding and dx for decoding... Not really obvious though. I don't like this kind of function names.
Anyway, I hope it will help anybody in a same situation. ;)
I am trying to use ocamldebug with my project, to understand why a 3rd party lib I'm using is not behaving the way I expected.
https://ocaml.org/manual/debugger.html
The OCaml debugger is invoked by running the program ocamldebug with the name of the bytecode executable file as first argument
I have added (modes byte exe) to my dune file.
When I run dune build I can see the bytecode file output, alongside the exe, as _build/default/bin/cli.bc
When I pass this to ocamldebug I get the following error:
ocamldebug _build/default/bin/cli.bc
OCaml Debugger version 4.12.0
(ocd) r
Loading program... done.
Fatal error: debugger does not support channel locks
Lost connection with process 33035 (active process)
between time 170000 and time 180000
Restart from time 170000 and try to get closer of the problem ? (y or n)
If I choose y the console seems to hang indefinitely.
I found the source of the error here:
https://github.com/ocaml/ocaml/blob/f68acd1a618ac54790a8347fad466084f15a9a9e/runtime/debugger.c#L144
/* The code in this file does not bracket channel I/O operations with
Lock and Unlock, so fail if those are not no-ops. */
if (caml_channel_mutex_lock != NULL ||
caml_channel_mutex_unlock != NULL ||
caml_channel_mutex_unlock_exn != NULL)
caml_fatal_error("debugger does not support channel locks");
...but I don't know what might be triggering it.
My project is using cmdliner and lwt ...I think at this early point of execution it hasn't hit any lwt code though.
Is ocamldebug incompatible with cmdliner?
If that's the case then I will need to make a new entrypoint just for debugging I guess. (currently the bin/cli is the only executable artefact in my project, the code I need to debug is all under lib/s)
It looks like that the OCaml debugger is broken for your version of macOS. Please, report the issue to the OCaml issue tracker including the detailed information on your system. I can't reproduce it on my machine, but I am using a pretty old version of macOS (10.11.6) and I have the 4.12 debugger working flawlessly.
As a workaround, try using an older version of OCaml, as this channel lock test was introduced very recently you can install any version prior to 4.12,
opam switch create 4.11.0
eval $(opam env)
Then, do not forget to rebuild your project (previously installing the required dependencies),
opam install lwt cmdliner
dune build
and then you can use the debugger to your taste.
I need an opengl loader, extension or core. I know I am suppose to use gl code inside after gl context has been called. My problem is actually setting up this opengl development environment.
I tried glew, and failed horribly.
Next one on my list is gl load generator. It generates specific opengl core, so all i have to do is include them to use those core functions.
However, I can not get this to install and feel like giving up and moving onto gl3w soon...
This is the error I am recieving when I try to make a simple file:
C:\MinGW64\glLoadGen_2_0_2>lua LoadGen.lua -style=pointer_c -spec=gl -version=3.
3 -profile=core core_3_3
lua: ./modules/Styles.lua:37: attempt to index local 'lfs' (a boolean value)
stack traceback:
./modules/Styles.lua:37: in main chunk
[C]: in function 'require'
./modules/GetOptions.lua:28: in main chunk
[C]: in function 'require'
LoadGen.lua:17: in main chunk
[C]: ?
C:\MinGW64\glLoadGen_2_0_2>cd C:\MinGW64\glLoadGen_2_0_2
Environment:
Windows 7 64 bit, running cmd as adminstrator, luafilesystem 1.5.0-1
There's a little syntax mistake. However, if you did some researches on this you would have found this Ticket
You have to replace
local lfs = pcall(require, "lfs")
if(lfs and lfs.attributes("modules/UserStyles.lua", "mode") == "file") then
with
local status, lfs = pcall(require, "lfs")
if(status and lfs.attributes("modules/UserStyles.lua", "mode") == "file") then
This fixes the errors.
Cheers
I get the exact same error message on Ubuntu 14.04 with default lua with glLoadGen_2_0_2. The only way I have been able to use glLoadGen is to download the glLoadGen_1_9 distribution and run the exact same lua command. It generates the gl .h and .c files fine. I'm assuming something is badly broken in the glLoadGen_2_0_2 distribution to get identical errors in such very different environments.
Seems it is trying to use mingw compiler suite to do the build. You either need to install mingw, or you need to tell luarocks (or whatever command you're using for the installation) how to find it, or you need to tell that command to use MSVC (or whatever build tool chain you want to use).
I have run into another in a long stream of obstacles attempting to build Qt5 with the VS2012 compiler.
When ICU is enabled ("-icu" on the configure command line, along with a proper 32-bit build of ICU in VS2012 and proper inclusion of all ICU paths (header, .lib, and .dll)), Line 688 of qtbase\src\corelib\codecs\qtextcodec.cpp returns a NULL codec (ICU fails to return a codec) when asked for a codec whose name is "US-ASCII".
Specifically:
QTextCodec* QTextCodec::codecForLocale()
{
QCoreGlobalData *globalData = QCoreGlobalData::instance();
if (!globalData)
return 0;
QTextCodec *codec = globalData->codecForLocale.loadAcquire();
if (!codec) {
#ifdef QT_USE_ICU
// THIS BLOCK IS REACHED WHEN ICU IS ENABLED
textCodecsMutex()->lock();
// ***
// The following codec returned is NULL!!!
// (Internally, it sets the codec name to "US-ASCII",
// and fails to find a codec with this name)
// ***
codec = QIcuCodec::defaultCodecUnlocked();
textCodecsMutex()->unlock();
#else
// setupLocaleMapper locks as necessary
codec = setupLocaleMapper();
#endif
}
return codec;
}
Later, the NULL codec variable noted above is dereferenced (in the code for the "lrelease.exe" utility), and when the "lrelease.exe" utility runs as part of the Qt5 build process and attempts to perform a translation, it crashes due to this NULL dereference and causes the Qt build to stop with an error.
Stepping into the above QIcuCodec::defaultCodecUnlocked() function reveals that the codec name is being set to US-ASCII, and that a codec with this name is not found.
It therefore seems to be impossible to include ICU support with a VS2012-compiler 32-bit build of Qt5.
Worse, because Webkit depends on ICU within Qt5, this means that Webkit cannot be built, either.
Can someone please tell me if this is reasonably likely to be a bug with Qt5 with VS2012, or is there something I am not setting up properly in my build environment?
Of use, also, would be knowing whether anybody has been able to build Qt5 with the VS2012 compiler with ICU support enabled.
I have also posted a comment in a relevant, ongoing thread in the Qt forum.
Qt uses UTF-8 as the default. Assuming ICU 51.2, rebuild ICU with U_CHARSET_IS_UTF8 defined to 1. Either: #define it in source\common\unicode\platform.h (see comment starting about around line 523), or you could also add it to the build in all ICU projects in allinone.sln (e.g. right click, select properties, select Configuration Properties>C/C++>Preprocessor and add it to Preprocessor Definitions).
I've been experimenting with embedding different scripting languages in a C++ application, currently I'm trying Stackless Python 3.1. I've tried several tutorials and examples, what few I can find, to try and run a simple script from an application.
Py_Initialize();
FILE* PythonScriptFile = fopen("Python Scripts/Test.py", "r");
if(PythonScriptFile)
{
PyRun_SimpleFile(PythonScriptFile, "Python Scripts/Test.py");
fclose(PythonScriptFile);
}
Py_Finalize();
For some odd reason, running this piece of code results in an access violation at:
PyRun_SimpleFile(PythonScriptFile, "Python Scripts/Test.py");
I've searched online for others with a similar problem and found only one. Their only solution was a workaround that only seems possible in an older version of Python: Creating a python file object and returning the FILE* from that python file object into PyRun_SimpleFile. Such function calls are not available however, the Python 3.1 API creates file objects from a file descriptor and returns file descriptors, but the PyRun_SimpleFile function still requires a FILE*.
I'm at a loss as to how to run any scripts from file, short of loading the entire file into memory manually and running it as a giant string, certainly not a practical solution.
What gives? How can I accomplish this task if the API has an internal error?
Update:
I've managed to build Stackless Python 3.1 from the source and yet the crash remains completely unchanged, despite using the same C runtime library. Both my project and the Stackless Python 3.1 source are built with Visual Studio 2010's C++ compiler and C runtime. I no longer have any inkling as to what might solve this problem, short of modifying Python to use a file name and not a FILE*. Another terrible workaround.
This works for me on Python 3:
PyObject *obj = Py_BuildValue("s", "test.py");
FILE *file = _Py_fopen_obj(obj, "r+");
if(file != NULL) {
PyRun_SimpleFile(file, "test.py");
}
I hope It would be useful.
I was getting a similar crash & did the below:
PyObject* PyFileObject = PyFile_FromString("test.py", "r");
PyRun_SimpleFileEx(PyFile_AsFile(PyFileObject), "test.py", 1);
Note that this was in python 2.7 though. I don't know if the API has changed in 3.x.
Your code works correctly on my installed version of Python 2.6. I also built stackless 3.1.2 from source and it worked correctly. This was with g++ 4.4.3 on Ubuntu 10.04. If you're on windows, you might want to check that both stackless and your code are built against the same C runtime.
This sounds like a problem of mismatched APIs. If your code and the Python runtime were compiled with different compilers, or even different compiler options, then accessing the FILE* could result in an access violation. Can you double-check that you've build your C code properly?
You mention that you're embedding Python into your C++ application. Keep in mind that Python is C code, compiled as C code. Perhaps that is the source of the problem?
If you built your test with VC 2010, you will definitely have problems - VC9 (VS 2008) and VC10 (VS 2010) have mutually incompatible support DLLs that are usually required (implement printf, file i/o and that sort of thing). You cannot mix them if they include the standard libraries, which the python build does.
You always have the option of using gcc (e.g. Cygwin or mingw) or downloading Visual Studio 2008 express, which should work fine for experimentation into python embedding. I have used both with the standard Python 2.7.6 build.
And what about this solution:
Py_SetProgramName(argv[0]);
Py_Initialize();
PyRun_SimpleString("execfile(\"ex30.py\")");
Py_Finalize();
Where ex30.py it the name of the python script I am running.
The below code will execute the test.py module. Python will search the module in the path set. So the path should be handled first.
Py_Initialize();
string path = "Python Scripts/";
//Set the path
PyRun_SimpleString("import sys");
string str = "sys.path.append('" + path + "')";
PyRun_SimpleString(str.c_str());
//Dont use test.py as it actually searches sub module test>>py
PyObject * moduleName = PyUnicode_FromString("test");
PyObject * pluginModule = PyImport_Import(moduleName);
if (pluginModule == nullptr)
{
PyErr_Print();
return "";
}
//Do the executions here
//clean up
Py_DECREF(moduleName);
Py_DECREF(pluginModule);
Py_DECREF(transformFunc);
Py_DECREF(result);
Py_Finalize();