I'm trying to set my .zshrc file to export ARQROOT for ARQ (jena) on a mac (mavericks), similar to what is shown on http://jena.sourceforge.net/ARQ/Tutorial/query1.html for windows and linux
tried all sorts of combinations with paths, quotes and syntax but none seems to work. Any thoughts on what the mac/zsh equivalent to export ARQROOT=$HOME/MyProjects/ARQ would be?
many thanks
ARQROOT isn't needed nowadays.
The scripts (in apache-jena-VERSION/bin or /bat) set paths themselves.
The Jena project is now at http://jena.apache.org/ (how did you get to the sourceforge page? It's supposed to redirect).
Related
I'm looking to compile OCCT 7.5 in Windows 10 (x64 via VS2019) for use with FreeCAD, to enable exporting glTF files, which requires RapidJSON support (in OCCT). I've checked out OCCT 7.5.3 and RapidJSON 1.1.0 from their git repos, then grabbed the FreeCAD libpack 12.5.2 (for OCCT 7.5). I started from FreeCAD's build docs, then attempted to follow OCCT's build docs.
When configuring the OCCT project in CMake-GUI, I've been able to find what I think are correct values for some variables (e.g. those regarding FREETYPE) within the FreeCAD libpack, as well as RapidJSON, but still get some errors in the config, seemingly no matter what values I try:
Could not find headers of used third-party products:
3RDPARTY_TCL_INCLUDE_DIR 3RDPARTY_TK_INCLUDE_DIR
...
Could not find DLLs of used third-party products: 3RDPARTY_TCL_DLL_DIR
3RDPARTY_TK_DLL_DIR
I've tried using *.lib, *.h and *.dll files found within the FreeCAD Libpack (and their corresponding directories) for *_LIBRARY/INCLUDE/DLL variables, but nothing is found. I see
Info: TCL is used by OCCT
Could NOT find Tclsh (missing: TCL_TCLSH)
even though tclsh86t.exe exists in the libpack/bin directory.
What should the 3RDPARTY_TCL_* & 3RDPARTY_TK_* CMake variables be set to, to use the FreeCAD libpack?
The problem was my lack of familiarity with CMake and Cmake-gui: the gui opened a dialog for a FILEPATH when specifying a PATH variable. I naively thought, "I don't know CMake, so I'll trust the gui". Totally wrong.
I manually edited the 3RDPARTY_* variable entries to point to the correct directories (or libs, when needed) in the FreeCAD libpack, using the variable name and description/hint for each to determine what the variable's value should be. Below are my entries, for reference:
I did need to check "Advanced", to edit the FREETYPE_LIBRARY_DEBUG & FREETYPE_LIBRARY_RELEASE variables (CMake set them to separate libs found in a jdk directory, presumably because it was added to the system path at some point).
I am getting started with Vulkan (vulkansdk-macos-1.1.126.0) on macOS (10.14.6), and have followed a tutorial in setting up an instance which all seems to go well however when I call vkEnumerateInstanceLayerProperties I get a returned layer count of 0.
At first I thought it could be my build arguments/variables, however when I run the vulkanInfo application supplied with the tar.gz it also reports there that there are no layers (Layers: count = 0). I then tried to add environment variables:
PATH=$PATH:$VULKAN_ROOT/bin
export VK_LAYER_PATH=$VULKAN_ROOT/etc/vulkan/explicit_layers.d
export VK_ICD_FILENAMES=$VULKAN_ROOT/etc/vulkan/icd.d/MoltenVK_icd.json
export VK_LAYER_PATH=$VULKAN_ROOT/etc/vulkan/explicit_layers.d
export VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_standard_validation vulkaninfo
#export VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation vulkaninfo
and launch vulkanInfo from the terminal. Maybe it is a Mac trying to be too secure issue or has something to do with file permissions. Any suggestions are appreciated since this will seriously hamper debugging.
So as you'd expect I was doing something wrong, just doing 2 different things wrong:
- for launching vulkanInfo from the terminal, you can see that I wasn't exporting the PATH variable.
- for VSCode (where I am building the application) I had the VK_ICD_FILENAMES and VK_LAYER_PATH as preprocessor definitions, not as launch environment variables (set in the launch.json, environment name/value map).
(Before downvote im aware how to do this using code thats inline to this command but not how to do it using a file that uses the --app="data:text/html,<sometags></sometags>)
How would I open a local html (mar.html) file using this command
C:\'Program Files (x86)'\Google\Chrome\Application\chrome.exe --profile-directory="Default" --app=
Specifically, the issue is my lack of familiarity with the --app flag
I tried
C:\'Program Files (x86)'\Google\Chrome\Application\chrome.exe --profile-directory="Default" --app="mar.html"
C:\'Program Files (x86)'\Google\Chrome\Application\chrome.exe --profile-directory="Default" --app="file:///mar.html"
Both don't work.
Giving me the error
Your file was not found
It may have been moved or deleted.
ERR_FILE_NOT_FOUND
You almost got it. The file descriptor path must be absolute and encoded.
Encoding the path correctly with cli tools like "urlencode"(gridsite-clients) did not work for me.
If you have NodeJS installed and would use a linux machine, you could use this command.
chromium --app=`node -e "console.log('file://'+encodeURI(process.argv[1]))" "$(realpath "/path/of/your/file.html")"`
This works also fine with relative paths.
For windows you have to rewrite this yourself.
I have unsuccessfully been trying to install some plugins for VIM for sometime. I have mostly been following the information in this reference. I've basically just been dropping the plugin files in various directories hoping something works, nothing has yet. I have a .vim directory at the following path:
/Users/{my_user_name}/.vim
I have tried adding my files to the directory above as well as a directory inside it called plugins. Can anyone suggest what I might be doing wrong?
When I enter
:help 'rtp'
I get
Unix: "$HOME/.vim,
$VIM/vimfiles,
$VIMRUNTIME,
$VIM/vimfiles/after,
$HOME/.vim/after"
Amiga: "home:vimfiles,
$VIM/vimfiles,
$VIMRUNTIME,
$VIM/vimfiles/after,
home:vimfiles/after"
PC, OS/2: "$HOME/vimfiles,
$VIM/vimfiles,
$VIMRUNTIME,
$VIM/vimfiles/after,
$HOME/vimfiles/after"
Macintosh: "$VIM:vimfiles,
$VIMRUNTIME,
$VIM:vimfiles:after"
The correct location is in a plugin subdirectory (not the plural plugins):
/Users/{my_user_name}/.vim/plugin/*.vim
You can check your actually used path with
:set rtp?
The trailing ? means query value, don't set. (:help rtp is just the general documentation, not what's actually used.)
The useful :scriptnames command will tell you what actually got sourced.
Note that all these instructions are valid for plain *.vim plugin scripts; some plugins are also distributed as (*.zip, or *.tar.gz) archives, or the Vim-specific Vimball (*.vba, *.vmb), which typically contain the subdirectory structure already.
For an hypothetical single-file plugin:
~/.vim/plugin/plugin.vim
For an hypothetical multi-file plugin:
~/.vim/autoload/plugin.vim
~/.vim/plugin/plugin.vim
~/.vim/doc/plugin.txt
If that hypothetical multi-file plugin comes with documentation, run the following command to add it to the :help index:
:helptags ~/.vim/doc
The :scriptnames shows you a list of sourced scripts.
Also, most plugins have some kind of README that details recommended installation procedures: read it.
Can phpDocumentor be used to generate HTML docs for some legacy code that does not necessarily conform to its standard?
I'd like to generate some preliminary documentation for an old code tree and later on start improving my comments and add the appropriate # tags as I get fluent with phpDocumentor. I've never used this piece of software before and the examples I've found focus on how to write new code that conforms to its syntax and generate HTML file by file with the -f parameter.
I've installed latest phpDocumentor through the PEAR command line installer and tried this little *.bat file on Windows XP:
#echo off
phpdoc ^
--directory "\\server\project\trunk" ^
--target "C:\tests\project-doc"
... but this is all I get:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
directory: '' not found
I've also tried mapping the UNC path to a drive letter:
#echo off
phpdoc ^
--directory "I:\" ^
--target "C:\tests\project-doc"
... but:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
a target directory must be specified
try phpdoc -h
This error message is the same if I create "C:\tests\project-doc" before.
What's exactly wrong in my syntax?
phpDocumentor can indeed run against "undocumented" code. It builds its docs based on the code itself, and uses the docblocks as additional info (and additional organization, in the case of #package and #subpackage tags).
I'd suggest starting with phpDocumentor against your existing code, and work towards clearing out the warnings you see in the errors.html file that results -- this file is generated in the top level of your output docs, but there isn't any link to it from the output docs.
Once you have those cleared, you can start running phpDocumentor with the -ue argument (--undocumentedelements), which will add new warnings to errors.html, highlighting (in much greater detail) things that still need to be documented in docblocks.
Now, as for the issue you're having trying to run the program against code on a shared drive, I'm not sure what's wrong there. The script is clearly able to execute PHP and find the phpDocumentor code itself. You might try putting the arguments in the same line, rather than using the ^ as a line-feed escape character, and perhaps remove the quotes around the paths (since no spaces exist in the paths).
I think I've found what the issue is. The parameter parser is very picky and it doesn't like neither UNC paths nor bare root directories. If I replace this:
--directory "I:\"
... with this:
--directory "I:\."
... it finally starts running.
I suppose it's a bug. Their bug tracker doesn't seem to be public so I don't know if it's a known issue.