I am using the latest version of schemacrawler (16.1.2) to generate SVG diagrams embedded in HTML output. However it is not creating the diagrams but only printing the table information in text form. If I use an older version of schemacrawler, it works fine. I have Graphviz installed on my machine. What am I doing wrong that is not outputting the diagram?
For Version 16.1.2 this version of the command line I use is not working
source schemacrawler.sh --server=postgresql --host=hostname --database=db_name --user=username --password=password_name --info-level=standard --schemas=schema_name --command=schema --outputformat=htmlx --log-level=CONFIG > schemaGraph.html
For Version 14.17, this version of the command works fine for me
source schemacrawler.sh -server=postgresql -host=hostname -database=db_name -user=username -password=password_name -infolevel=minimum -command=schema -outputformat=htmlx -loglevel=CONFIG > schemaGraph.html
Please try --output-format and see if it works.
Related
I am trying to use Doxygen to generate the documentation of my c++ program, and I wish to have the dependency graph as well. So I installed graphviz-2.40.1, the path to graphviz is shown below:
which dot
/usr/local/bin/dot
I turned on the HAVE_DOT to YES, and also set the DOT_PATH to be /usr/local/bin/.
However if I run doxygen, it fails to generate the dependency graph and throws me the error:
Format: "png" not recognized. Use one of: canon cmap cmapx cmapx_np dot dot_json eps fig gv imap imap_np ismap json json0 mp pic plain plain-ext pov ps ps2 svg svgz tk vml vmlz xdot xdot1.2 xdot1.4 xdot_json
error: Problems running dot: exit code=1, command='/usr/local/bin/dot', arguments='"/home/shiqihe/Documents/code/cpp/docs/doxygen/html/dg__main_8cpp__incl.dot" -Tpng -o "/home/shiqihe/Documents/code/cpp/docs/doxygen/html/dg__main_8cpp__incl.png"'
I have searched for the solution and find this: soluiton
I tried sudo dot -c but it did not work. Still gave me the same error.
Any help? Thank you!
You already mentioned the "solution" which says:
It looks like there is a bug in the official install. After running the command 'dot -c', the problem has been solved.
The version you use does not support png, so:
search for an executable that contains the png format
create an executable yourself based on the graphviz dot code
use another format in doxygen (when you use HTML as output you can use e,g. svg as DOT_IMAGE_FORMAT. (see documentation in e.g. http://doxygen.nl/manual/customize.html#minor_tweaks_dynsection)
I am trying to compile a source file with icc compiler and MAGMAmic library. However I get the following error:
icc -c -o direct.o direct.c -O3 -openmp -DADD_ -Wall -DHAVE_MIC -I/opt/intel/mic/coi/include -I/usr/include/intel-coi -I/opt/intel/compilers_and_libraries_2017.2.174/linux/mkl/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/ipp/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/mkl/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/tbb/include:/opt/intel/compilers_and_libraries_2017.2.174/linux/daal/include -I/home/dslavchev/install/magmamic-1.4.0/include -I/home/dslavchev/install/magmamic-1.4.0/contol
icc: command line remark #10411: option '-openmp' is deprecated and will be removed in a future release. Please use the replacement option '-qopenmp'
In file included from /home/dslavchev/install/magmamic-1.4.0/include/magma_types.h(134),
from /home/dslavchev/install/magmamic-1.4.0/include/magmablas_z.h(17),
from /home/dslavchev/install/magmamic-1.4.0/include/magmablas.h(12),
from /home/dslavchev/install/magmamic-1.4.0/include/magma.h(17),
from direct.c(21):
/opt/intel/compilers_and_libraries_2017.2.174/linux/compiler/include/complex(30): catastrophic error: cannot open source file "complex"
#include_next <complex>
^
The MAGMAmic library has compiled correctly and I can run it's test ok.
I have looked at the way testing_dgesv_mic.cpp example compiles and used the same includes and link, however in my case I get the above error.
I have added the following in my .bashrc file in order to get the Intel compilers' and libraries' enviromental variables:
#for MAGMA mic
export MAGMA_PATH=/home/dslavchev/install/magmamic-1.4.0
source /opt/intel/bin/compilervars.sh intel64
source /opt/intel/mkl/bin/mklvars.sh intel64
Any ideas what might cause icc to be unable to include the "complex" file?
The file complex really exists in "/opt/intel/compilers_and_libraries_2017.2.174/linux/compiler/include/complex"
icc vesrion is:
[dslavchev#sl051 results]$ icc -v
icc version 17.0.2 (gcc version 4.4.7 compatibility)
magmamic version is magmamic-1.4.0
EDIT: Removed unnecessary code comment
EDIT2: Added version info.
MAGMAmic is a C++ library and it cannot be used with C code directly.
When icc detects that you want to compile .c++ file it automatically switches to icpc (Intel C++ compiler) which in turn results in the above error.
Solution: Either switch to icpc or rename your files to .c++
This question was answered by mark on the MAGMA forums. Link:
http://icl.cs.utk.edu/magma/forum/viewtopic.php?f=2&t=1587&p=4442#p4442
We have for the past year been running a batch script I wrote to call a series of XQuery Updates from the Windows command line using Saxon. It worked fine while we were on oXygen 16, but after all the machines in our department were upgraded to oXygen 17.1, the script is now throwing an error that I can't seem to fix. Any thoughts would be greatly appreciated.
This used to work when oXygen 16 was installed:
java -cp "C:\Program Files\Oxygen XML Editor 16\lib\saxon9ee.jar" net.sf.saxon.Query -update:on -t -q:"C:\Users\%USERNAME%\Documents\SVN Working Copies\trunk\rbscXSL\Locations2015\AbID2dsc-items.xq"
I have confirmed that the .jar file is in the same relative location (with the oXygen version number being the only change to the path) and has the same name as before. Nevertheless, after updating the class path to "C:\Program Files\Oxygen XML Editor 17\lib\saxon9ee.jar" the script throws the following error:
Saxon-EE 9.6.0.7J from Saxonica
Java version 1.8.0_92
java.lang.UnsupportedOperationException: XQuery Update is not supported in this Saxon Configuration
at net.sf.saxon.s9api.XQueryCompiler.setUpdatingEnabled(XQueryCompiler.java:212)
at net.sf.saxon.Query.doQuery(Query.java:281)
at net.sf.saxon.Query.main(Query.java:111)
Fatal error during query: java.lang.UnsupportedOperationException: XQuery Update is not supported in this Saxon Configuration
The filename, directory name, or volume label syntax is incorrect.
Java 8 is installed on my machine. I have also ensured that the XQuery Update still works when called from within the oXygen editor.
After reading up on http://www.saxonica.com/documentation9.6/index.html#!using-xquery/commandline and http://www.saxonica.com/documentation9.6/index.html#!conformance/update, I added the -tree:linked flag and the -qversion:1.0 flag (they result in the same error message):
java -cp "C:\Program Files\Oxygen XML Editor 17\lib\saxon9ee.jar" net.sf.saxon.Query -qversion:1.0 -tree:linked -update:on -t -q:"C:\Users\%USERNAME%\Documents\SVN Working Copies\trunk\rbscXSL\Locations2015\AbID2dsc-items.xq"
According to the documentation, XQuery Update should run if the -update:on flag is set, which it is, and the XML is read in using the doc() or collection() function, which is also the case--these are the variables from my XQuery file:
declare variable $EAD as document-node()* := doc("sample_input.xml");
declare variable $ITEMS as document-node()* := doc("sample_input.AbID.xml");
I'm at a loss what else to try. If anyone can see what's going wrong here, I'd greatly appreciate any pointers!
Do you have your own Saxon-EE license, or are you relying on the license that comes with oXygen? The oXygen license does not cover use of Saxon-EE outside of oXygen itself (so it doesn't cover the way you are running Saxon from the command line). Perhaps you found a loophole in the way oXygen handles the Saxon activation that worked in earlier releases but has since been fixed, either in oXygen or in Saxon.
I am using Modelsim ALTERA STARTER EDITION 10.1d and am importing a waveform file but am getting the following error.
The WLF file version is 132.Modelsim 10.1d can read up to and including WLF file version 121.
I have tried importing the same file into Modelsim 13.1 and am still receiving similar problems. If anybody knows what version of Modelsim I need to open this file version your help would be most appreciated. Thanks!
It looks like the version number is the fourth byte in the WLF header (121 = 0x79). I manually edited a version 121 file to bump up this field and got the same version warning you are seeing. Your version 132 file should have 0x84 in its fourth byte. You could manually edit the file to reduce its version and hope the format is otherwise compatible with the older version of Modelsim but there are no guarantees.
My developer friend who has the luxury of developing in a non-Windows environment has been raving about Compass. I finally decided I wanted to give it a try. I'm tired of trying to keep up with all of the intricacies of cross-browser CSS.
So, I found it on NuGet, and installed it.
I installs to my solutions root directory in the packages directory:
$(SolutionDir)packages\Ruby.Compass.0.12.2.3\
It comes with a Readme that states the following message:
Ruby Compass v. 0.12.2
Compass is installed in its own NuGet package dir, and available by
'compass' command in "packages\Ruby.Compass.0.12.2.3" folder.
To compile Compass files during build, add the next line to the
project pre-build events:
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile
"$(ProjectDir)."
So, I placed the line in my pre-build events, saved, and tried to build my project. However, I get an error as follows:
The command
""$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)."" exited with code 1.
Notice: It actually shows the full path to the ProjectDir and SolutionDir as it's supposed too in the error message. I replaced them with the tokens to keep the project name unanimous.
Let me mention that I tried variations of the suggestion pre-build line:
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)"
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)css"
"$(SolutionDir)packages\Ruby.Compass.0.12.2.3\compass" compile "$(ProjectDir)css\test.scss"
The first one just removed that trailing .. The second one pointed it to the directory where all my css files are stored. The third one pointed it to the exact file I was trying to compile was located.
I opened up compass.cmd which is the file it is calling, and it looks like the following:
#echo off
"%~dp0ruby\bin\compass" %*
I'm assuming this calls the compass file in the ruby/bin folder, which looks like this:
#!C:/downloads/ruby-2.0.0-p247-x64-mingw32/ruby-2.0.0-p247-x64-mingw32/bin/ruby.exe
#
# This file was generated by RubyGems.
#
# The application 'compass' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'rubygems'
version = ">= 0"
if ARGV.first
str = ARGV.first
str = str.dup.force_encoding("BINARY") if str.respond_to? :force_encoding
if str =~ /\A_(.*)_\z/
version = $1
ARGV.shift
end
end
gem 'compass', version
load Gem.bin_path('compass', 'compass', version)
From there, I'm not sure what is going on. I'm not a Ruby person.
Is there an issue that I'm overlooking here?
Has anyone else been able to install Ruby.Compass via NuGet?
How can I get this working in Visual Studio without having to fight with Ruby?
From: http://codewith.us/automating-css-generation-in-visual-studio-using-sasscompass/
"Note that, if there are issues with your SCSS files, you will receive some variation of the error below.
Error 36 The command "del "C:Projectspubliccss*.css" /S
compass compile "C:Projectspublic" --force" exited with code 1.
Open your Output window (click View -> Output or press Ctrl+W, O), and select “Build” in the “Show output from:” menu. Scroll up until you find your command in the log and you should get a little more insight into what portion of the command failed."