I've compiled Inkscape 0.92.2 (on Slackware64-current Linux), and I can't export to PNG.
I found some references that libpng could be the culprit. Indeed, I found that the inkscape executable was linked with two versions of libpng (1.5 and 1.6).
A lot of tracing and debugging showed that the probleem seems to be that the executable is linked with two versions of libMagick (6 and 7), which import different versions of libpng.
Checking the Inkscape config.log file shows that indeed both libs are accessed:
pkg_cv_IMAGEMAGICK_LIBS='-lMagick++-6.Q16 -lMagickWand-7.Q16HDRI -lMagickCore-7.Q16HDRI'
Edit: As per emcconville's suggestion, I added --with-magick-plus-plus=yes and recompiled everything (both ImageMagick and Inkscape. No luck though:
$ ldd /usr/bin/inkscape | grep Magick
libMagick++-6.Q16.so.5 => /usr/lib64/libMagick++-6.Q16.so.5 (0x00007f5ee46f3000)
libMagickWand-6.Q16.so.2 => /usr/lib64/libMagickWand-6.Q16.so.2 (0x00007f5ee43d3000)
libMagickCore-6.Q16.so.2 => /usr/lib64/libMagickCore-6.Q16.so.2 (0x00007f5ee3d23000)
libMagickWand-7.Q16HDRI.so.5 => /usr/lib64/libMagickWand-7.Q16HDRI.so.5 (0x00007f5ee2e9b000)
libMagickCore-7.Q16HDRI.so.5 => /usr/lib64/libMagickCore-7.Q16HDRI.so.5 (0x00007f5ee27a3000)
Maybe there's another library pulling in version 6. Though I can't seem to find which.
Edit2: Before applying emcconville's steps, I wanted to understand what was going on...
These are the actual libs and their links:
libMagick++ so -> so.5.0.0
so.5 -> so.5.0.0
so.5.0.0
libMagick++-6.Q16 a la so -> so.5.0.0
so.5 -> so.5.0.0
so.5.0.0
libMagick++-7.Q16HDRI a la so -> so.4.0.0
so.4 -> so.4.0.0
so.4.0.0
libMagickCore-6.Q16 a la so -> so.2.0.0
so.2 -> so.2.0.0
so.2.0.0
libMagickCore-7.Q16HDRI a la so -> so.5.0.0
so.5 -> so.5.0.0
so.5.0.0
libMagickWand-6.Q16 a la so -> so.2.0.0
so.2 -> so.2.0.0
so.2.0.0
libMagickWand-7.Q16HDRI a la so -> so.5.0.0
so.5 -> so.5.0.0
so.5.0.0
libMagickCore so -> so.5.0.0
so.5 -> so.5.0.0
so.5.0.0
libMagickWand so -> so.5.0.0
so.5 -> so.5.0.0
so.5.0.0
This seems acceptable, except for the (unversioned) libMagic++, libMagickCore, and libMagicWand which I suspect are version 5.xxx and can be removed.
The .PC files are a little more complicated:
---- Version 6 pc files ---------Version 7 pc files ------
ImageMagick-6.Q16.pc ImageMagick-7.Q16HDRI.pc
ImageMagick++-6.Q16.pc
Magick++-6.Q16.pc Magick++-7.Q16HDRI.pc
MagickCore-6.Q16.pc MagickCore-7.Q16HDRI.pc
MagickWand-6.Q16.pc MagickWand-7.Q16HDRI.pc
--- Relationships:
ImageMagick.pc -> ImageMagick-6.Q16.pc
Magick++.pc is same as Magick++-7.Q16HDRI.pc (not a link!)
MagickCore.pc is same as MagickCore-7.Q16HDRI.pc (not a link!)
MagickWand.pc is same as MagickWand-7.Q16HDRI.pc (not a link!)
Note: ImageMagic.pc is pointing to version 6,
and there is no ImageMagick++-7.Q16HDRI.pc generated (even enabling the ++ compile option)
Edit3: Today I recompiled the last version of ImageMagick once again, this time monitoring much more closely which files it generates, and installs. #emcconville's suggestion to use symlinks for the pc-files does not seem to be entirely practical, as each install will overwrite those symlinks.
(see the last table in edit2). Still, while this system is as it is, there doesn't seem any other solution.
I think I know what's going on, but it's more of a "hunch" than an answer.
I'm suspecting that an extra .pc script is floating around, and you just need to delete it.
Find the location of ImageMagick.pc & ImageMagick++.pc. This is usually under /usr/share/pkgconfig/, /usr/local/share/pkgconfig/, /usr/lib/pkgconfig/, /usr/lib64/pkgconfig/, & etc etc etc.
Don't just stop at the first match, but scan everything with locate, or find utility.
find /usr/ -name "ImageMagick*.pc" -type f
You should have a list that looks something like ....
/usr/local/share/pkgconfig/ImageMagick++.pc
/usr/local/share/pkgconfig/ImageMagick.pc
/usr/local/share/pkgconfig/ImageMagick++-6.Q16.pc
/usr/local/share/pkgconfig/ImageMagick-6.Q16.pc
/usr/local/share/pkgconfig/ImageMagick++-7.Q16HDRI.pc
/usr/local/share/pkgconfig/ImageMagick-7.Q16HDRI.pc
Nuke the offending files.
# Create a backup place
mkdir -p ~/backups
# Archive `.pc' files for future investigations.
gzip < /usr/local/share/pkgconfig/ImageMagick.pc > ~/backups/ImageMagick.pc.gz
gzip < /usr/local/share/pkgconfig/ImageMagick++.pc > ~/backups/ImageMagick++.pc.gz
# Remove
sudo rm /usr/local/share/pkgconfig/ImageMagick.pc
sudo rm /usr/local/share/pkgconfig/ImageMagick++.pc
# Repeat as nessasry for duplicate instances,
# but KEEP files with version prefixes (i.e `-6.Q16' & `-7.Q16HDRI')
Create symbolic links (assuming ImageMagick-7 is the default version for your system).
sudo ln -s /usr/local/share/pkgconfig/ImageMagick-7.Q16HDRI.pc /usr/local/share/pkgconfig/ImageMagick.pc
sudo ln -s /usr/local/share/pkgconfig/ImageMagick++-7.Q16HDRI.pc /usr/local/share/pkgconfig/ImageMagick++.pc
Rebuild inkscape, and confirm issue is resolved.
Write a note to your future self describing what you did, and steps repeat/restore. Some programs haven't migrated to IM-7, so it's more than possible that you'll need to updated the generic .pc files to point to IM-6 (or other way around).
Related
I am attempting to use math symbols that don't exist by default as part of existing packages in Options for notes (eg. amsmath). I tested the below code in TeXworks (pdfLaTeX) with no issues.
\DeclareSymbolFont{matha}{OML}{txmi}{m}{it}% txfonts
\DeclareMathSymbol{\varv}{\mathord}{matha}{118}
...
$ \varv = 0 $
Upon adding the \DeclareSymbolFont... and \DeclareMathSymbol... lines to
Tools => Manage Note Types => Options, and inserting the lines before \begin{document}, I tried below lines in Ankiweb app Card
\( \varv = 0 \) or [$] \varv = 0 [/$],
but ankiweb app doesnt convert this to the right symbol as it does with TeXworks
Is there something I need to do specifically? Or is the above steps not allowed in Ankiweb app.
Ankiweb app details:
Version 2.1.54 (b6a7760c)
Python 3.9.7 Qt 5.15.2 PyQt 5.15.5
Update 2
I think #faré is right, it's an output translation problem.
So I declared the evironment variable ASDF_OUTPUT_TRANSLATIONS and set it to E:/. Now (asdf:require-system "my-system") yields a different error: Uneven number of components in source to destination mapping: "E:/" which led me to this SO-topic.
Unfortunately, his solution doesn't work for me. So I tried the other answer and set ASDF_OUTPUT_TRANSLATIONS to (:output-translations (t "E:/")). Now I get yet another error:
Invalid source registry (:OUTPUT-TRANSLATIONS (T "E:/")).
One and only one of
:INHERIT-CONFIGURATION or
:IGNORE-INHERITED-CONFIGURATION
is required.
(will be skipped)
Original Posting
I have a simple system definition but can't get ASDF to load it.
(asdf-version 3.1.5, sbcl 1.3.12 (upgraded to 1.3.18 AMD64), slime 2.19, Windows 10)
What I have tried so far
Following the ASDF manual: "4.1 Configuring ASDF to find your systems"
There it says:
For Windows users, and starting with ASDF 3.1.5, start from your
%LOCALAPPDATA%, which is usually ~/AppData/Local/ (but you can ask in
a CMD.EXE terminal echo %LOCALAPPDATA% to make sure) and underneath
create a subpath config/common-lisp/source-registry.conf.d/
That's exactly what I did:
Echoing %LOCALAPPDATA% which evaluates to C:\Users\my-username\AppData\Local
Underneath I created the subfolders config\common-lisp\source-registry.conf.d\ (In total: C:\Users\my-username\AppData\Local\config\common-lisp\source-registry.conf.d\
The manual continues:
there create a file with any name of your choice but with the type conf, for instance 50-luser-lisp.conf; in this file, add the following line to tell ASDF to recursively scan all the subdirectories under /home/luser/lisp/ for .asd files: (:tree "/home/luser/lisp/")
That’s enough. You may replace /home/luser/lisp/ by wherever you want to install your source code.
In the source-registry.conf.d folder I created the file my.conf and put in it (:tree "C:/Users/my-username/my-systems/"). This folder contains a my-system.asd.
And here comes the weird part:
If I now type (asdf:require-system "my-system") in the REPL I get the following error:
Can't create directory C:\Users\my-username\AppData\Local\common-lisp\sbcl-1.3.12-win-x86\C\Users\my-username\my-systems\C:\
So the problem is not that ASDF doesn't find the file, it does -- but (whatever the reason) it tries to create a really weird subfolder hierarchy which ultimately fails because at the end it tries to create the folder C: but Windows doesn't allow foldernames containing a colon.
Another approach: (push path asdf:*central-registry*)
If I try
> (push #P"C:/Users/my-username/my-systems/" asdf:*central-registry*)
(#P"C:/Users/my-username/my-systems/"
#P"C:/Users/my-username/AppData/Roaming/quicklisp/quicklisp/")
> (asdf:require-system "my-system")
I get the exact same error.
I don't know what to do.
Update
Because of the nature of the weird path ASDF was trying to create I thought maybe I could bypass the problem by specifying a relative path instead of an absolute one.
So I tried
(:tree "\\Users\\my-username\\my-systems")
in my conf file. Still the same error.
Ahem. It looks like an output-translations problem.
I don't have a Windows machine right now, but this all used to work last time I tried.
Can you setup some ad hoc output-translations for now that will make it work?
I am running firefox 38.0.5 on linux KDE (OpenMandriva 2014.1). When I open my firefox-os project under webIDE, I cannot edit its files. I can see the project directory structure on the left but when selecting a file (index.html for example) it is not opened in the editor panel. I keep on seeing the general description of the app. I cannot either navigate in the project subdirectory.
I have enabled the logging and this is the error I can see:
A promise chain failed to handle a rejection. Did you forget to '.catch', or did you forget to 'return'?
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise
Date: Sun Jun 28 2015 12:03:54 GMT+0200 (CEST) Full Message: destroy
Full Stack: JS frame :: resource://gre/modules/Promise.jsm ->
resource://gre/modules/Promise-backend.js :: PendingErrors.register :: line 162 JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: this.PromiseWalker.completePromise :: line 675 JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: Handler.prototype.process :: line 903 JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: this.PromiseWalker.walkerLoop :: line 746 JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: this.PromiseWalker.scheduleWalkerLoop/> :: line 688 native frame :: unknown filename :: TOP_LEVEL :: line 0
Only the webIDE editor is not working. The rest of the functionalities are working fine.
I have tried to open and edit with webIDE the same project with another computer (MS Windows) and it works perfectly.
Any hint would be welcome. Thank you!
EDIT: This problem will be fixed with Firefox 44.0. As sugested in bugzilla bug 1208713 I have tested it successfully with the Firefox Nightly (44 at that time).
This problem will be fixed with Firefox 44.0. As sugested in bugzilla bug 1208713 I have tested it successfully with the Firefox Nightly (44 at that time).
I have set up my subversion/trac environment on Windows (Now Win7, previously tried on Vista) and all works perfectly. But I can't get my post-commit to work.
Here's the setup (using VisualSVN and Trac running on Apache):
C:\Users\Martin\Repositories\test_svn\hooks:
post-commit.bat:
call %~dp0\trac-post-commit-hook.cmd %1 %2
trac-post-commit-hook.cmd:
#ECHO OFF
::
:: Trac post-commit-hook script for Windows
::
:: Contributed by markus, modified by cboos.
:: Usage:
::
:: 1) Insert the following line in your post-commit.bat script
::
:: call %~dp0\trac-post-commit-hook.cmd %1 %2
::
:: 2) Check the 'Modify paths' section below, be sure to set at least TRAC_ENV
:: ----------------------------------------------------------
:: Modify paths here:
:: -- this one *must* be set
SET TRAC_ENV=C:\Users\Martin\Trac\test_svn
:: -- set if Python is not in the system path
SET PYTHON_PATH=
:: -- set to the folder containing trac/ if installed in a non-standard location
SET TRAC_PATH=
:: ----------------------------------------------------------
:: Do not execute hook if trac environment does not exist
IF NOT EXIST %TRAC_ENV% GOTO :EOF
set PATH=%PYTHON_PATH%;%PATH%
set PYTHONPATH=%TRAC_PATH%;%PYTHONPATH%
SET REV=%2
Python "%~dp0\trac-post-commit-hook" -p "%TRAC_ENV%" -r "%REV%"
trac-post-commit-hook:
Grabbed from http://trac.edgewall.org/browser/branches/0.11-stable/contrib/trac-post-commit-hook
I have tested the scripts in a cmd window and they work all the way. But on a TortoiseSVN commit, nothing happens, which makes me believe that Tortoise never runs the post-commit.bat.
I have also tested a simple pre-commit, and that works.
The strange thing is that is HAS worked before, but I think I used an earlier release of VisualSVN then.
Does anyone have any idea on what's going on here?
Thanks a lot!
/Martin
The post-commit hook is run server side. If the hook is implemented correctly, it should work for any Subversion client. You'll want to take a look at this chapter from the SVN book.
Follow-up: You might take a look at this blog entry.
I am trying to evaluate the answer provided here, and am getting the error: "A file with name ASDF-INSTALL does not exist" when using clisp:
dsm#localhost:~$ clisp -q
[1]> (require :asdf-install)
*** - LOAD: A file with name ASDF-INSTALL does not exist
The following restarts are available:
ABORT :R1 ABORT
Break 1 [2]> :r1
[3]> (quit)
dsm#localhost:~$
cmucl throws a similar error:
dsm#localhost:~$ cmucl -q
Warning: #<Command Line Switch "q"> is an illegal switch
CMU Common Lisp CVS release-19a 19a-release-20040728 + minimal debian patches, running on crap-pile
With core: /usr/lib/cmucl/lisp.core
Dumped on: Sat, 2008-09-20 20:11:54+02:00 on localhost
For support see http://www.cons.org/cmucl/support.html Send bug reports to the debian BTS.
or to pvaneynd#debian.org
type (help) for help, (quit) to exit, and (demo) to see the demos
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
* (require :asdf-install)
Error in function REQUIRE: Don't know how to load ASDF-INSTALL
[Condition of type SIMPLE-ERROR]
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(REQUIRE :ASDF-INSTALL NIL)
Source:
; File: target:code/module.lisp
(ERROR "Don't know how to load ~A" MODULE-NAME)
0] (quit)
dsm#localhost:~$
But sbcl works perfectly:
dsm#localhost:~$ sbcl -q
This is SBCL 1.0.11.debian, 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.
* (require :asdf-install)
; loading system definition from
; /usr/lib/sbcl/sb-bsd-sockets/sb-bsd-sockets.asd into #<PACKAGE "ASDF0">
; registering #<SYSTEM SB-BSD-SOCKETS {AB01A89}> as SB-BSD-SOCKETS
; registering #<SYSTEM SB-BSD-SOCKETS-TESTS {AC67181}> as SB-BSD-SOCKETS-TESTS
("SB-BSD-SOCKETS" "ASDF-INSTALL")
* (quit)
Any ideas on how to fix this? I found this post on the internet, but using that didn't work either.
The instructions you got mentioned SBCL explicitely, so it's expected that they'll work better using SBCL, I suppose. Some other Lisps don't come with ASDF or don't hook it up to CL:REQUIRE. In the former case, you'll have load ASDF yourself beforehand. In the latter case, you'll need to call (asdf:oos 'asdf:load-op ) instead of (require ).
wget http://cclan.cvs.sourceforge.net/checkout/cclan/asdf/asdf.lisp
It worth checking out clbuild. http://common-lisp.net/project/clbuild/
To get a lisp webserver up and running. You only need:
darcs get http://common-lisp.net/project/clbuild/clbuild
cd clbuild
chmod +x ./clbuild
./clbuild check
./clbuild build slime hunchentoot
./clbuild preloaded
Now a lisp repl will start. There you write:
* (hunchentoot:start-server :port 8080)
Testing that the server answer:
wget -O - http://localhost:8080/
<html><head><title>Hunchentoot</title></head>
<body><h2>Hunchentoot Default Page</h2>
<p>This is the Hunchentoot default page....
try this before anything else:
(require :asdf)
you can steal some ideas from the environment we use. it's available at: darcsweb
see environment.lisp that loads and sets up asdf for us. (sbcl has asdf already loaded)
use clc:clc-require in clisp. Refer to 'man common-lisp-controller'. I had the same error in clisp and resolved it by using clc:clc-require. sbcl works fine with just require though.