I downloaded the Factor programming language for Mac. I can now launch the command factor from the command line successfully. I read in a book covering this language (Seven More Languages in...) that, to run standalone programs I need to indicate the root paths from which Factor will search for vocabularies. I thus have to create a .factor-roots file in my home directory indicating the full paths to the root directories where I have my Factor source files, one path per line. My factor folder is in the /Applications folder. factor directory contains:
Factor.app git-id
README.md libfactor-ffi-test.dylib
basis libfactor.dylib
core license.txt
extra misc
factor work
factor.image
What should I exactly write in the .factor-roots file, to make it work?
SOLVED: I have to write into the .factor-roots file the path to the directory into which I write my standalone programs, not the path to the Factor installation directory.
Related
Background, I currently use Izpack for my Windows installer, I bundle a java runtime and use winrun4j as a wrapper both for the installation and the actual program once installed. It worked for a long time but there are a number of problems with the installer that I have not been able to solve and have been looking to replace it.
Oracle now provide the JPackage installer so it seems like a sensible choice. But the folder structure created by the installer is different to what I currently have, I have a number of config and non java files and I have not been able to get the .exe that JPackage creates to do anything.
So is it possible to use JPackage to create the installer but in a strcuture better matching my existing structure, and use continue to use WInRun4j to actyally run my application
Existing Folder Structure
ROOT
---App.exe
---Config Files
---lib
-------jar files
---JVM64
------- Java runtime
---help
JPackage structure
ROOT
---App.exe
---Runtime Dlls
---app
----- jar files
Config files
--runtime
------Java runtime
------Runtime Dlls (again)
The structure of directories generated by jpackage is mainly set up for you and does not seem possible to change, and makes installation of Java app dependencies very easy with self contained JRE. The basic structure for Windows is as you say:
ROOT
---App.exe (for --main-class parameter)
---xyz.exe (for each --add-launcher parameter)
---Runtime Dlls (these appear to be unused except for applauncher.dll, see SO 62607300)
---app/
------App.cfg (for --main-class)
------xyz.cfg (for per --add-launcher)
---runtime/
------Java runtime
------Runtime Dlls
With --input and --main-jar params you are free to setup additional directory structure under app/ folder for anything else you want for your application. So if you used lib/myappjar.jar it would add:
---app/
-------lib/
----------myappjar.jar
If you used --input build\mypath it would copy the entire tree of files under that folder, so if build\mypath dir contained
bin/
---Scripts
---xyz.properties
README.txt
Then app would also contain:
---app/
------bin/
---------Scripts
---------xyz.properties
------README.txt
By the way the Runtime DLLs placed at top level appear to be copies of some of the DLLs under runtime/bin
[https://stackoverflow.com/questions/62607300/why-is-java-jpackage-installing-windows-dll-files-in-two-places]
In both Hydrogen and using a plug-in terminal platform, the default directory is one folder up from where my code file resides.
E.g., I’ll be working on a file with path, say, parent/code/file.py. When I run pwd in the plug-in's terminal or the equivalent via Hydrogen in the python script I get parent/, but I need it to be parent/code/ to import files etc.
Perhaps the default directory for Atom is the project that is folder of the project that is open?
Any ideas how to change the default current directory for Atom (or is it package specific) to the file i’m working on/executing in Hydrogen?
In the hydrogen settings you can choose the location where the kernel should be started.
The default is the 'First started project's directory'. You can choose 'Current directory of the file' there, which should give you what you want.
How can I add a path to my current path in Julia, so that I can organize files and modules in folders, but still access them?
Note: the following paths may be Unix-specific.
You can add the file .juliarc.jl to your home directory, and include the line
#everywhere push!(LOAD_PATH,"/path/to/my/code")
The #everywhere ensures that it will work even if you've started julia with multiple workers.
This is an updated and extended version of the answer by tholy and ederag. On Linux and Windows with Julia 1.0 one can add the folder myproject/src in the user homefolder to the Julia LOAD_PATH by adding
using Distributed
#everywhere push!(LOAD_PATH, joinpath(homedir(), "myproject", "src"))
to <homedir>/julia/config/startup.jl. For a fresh Julia install, startup.jl nor the folder config exists (on Linux at least). Just create the file and folder and Julia will read startup.jl automatically.
I have a project in directory A and files that I use in all my projects are in directory B.
When I moved a .sty file from A to B, the main .tex file does not compile anymore.
The error is that the .sty file was not found. I am puzzled because:
Directory B is included in the path of the project.
I cleaned (deleted manually) all the auxiliary files used in the previous compilations.
I refreshed the project folders .
Did anyone had similar problems? Suggestions?
The file LaTeX.sublime-build, within the Sublime Text folder . . . /Packages/LaTeXTools, contains a $PATH for different operating systems.
For example, Sublime Text 2 on an OSX operating system, has a file located at ~/Library/Application Support/Sublime Text 2/Packages/LaTeXTools/LaTeX.sublime-build. The relevant line of code for a MacTeX TexLive 2012 installation is "path": "$PATH:/usr/texbin:/usr/local/bin",. The plugin LaTeXTools looks in that path for *.sty files that are a part of the TexLive installation. While it may be possible (under some circumstances) to place the *.sty files within the working directory of the *.tex file, this particular plugin looks to the path mentioned hereinabove. So one option would be to add additional locations to the $PATH to suit the needs of the user, or simply place the *.sty files within the path that is pre-defined by the plugin developer.
I have an erlang application I have been writing which uses the erldis library for communicating with redis.
Being a bit of a newbie with actually deploying erlang applications to production, I wanted to know if there was anyway to 'bundle' these external libraries with the application rather than installing into my system wide /usr/lib/erlang/lib/ folder.
Currently my directory structure looks like...
\
--\conf
--\ebin
--\src
I have a basic Makefile that I stole from a friend's project, but I am unsure how to write them properly.
I suspect this answer could involve telling me how to write my Makefile properly rather than just which directory to plonk some external library code into.
You should really try to avoid project nesting whenever possible. It can lead to all sorts of problems because of how module/application version is structured within Erlang.
In my development environment, I do a few things to simplify dependancies and multiple developed projects. Specifically, I keep most of my projects sourced in a dev directory and create symlinks into an elibs dir that is set in the ERL_LIBS environmental variables.
~/dev/ngerakines-etap
~/dev/jacobvorreuter-log_roller
~/dev/elib/etap -> ~/dev/ngerakines-etap
~/dev/elib/log_roller -> ~/dev/jacobvorreuter-log_roller
For projects that are deployed, I've either had package-rpm or package-apt make targets that create individual packages per project. Applications get boot scripts and init.d scripts for easy start/stop controls but libraries and dependancy projects just get listed as package dependencies.
I use mochiweb-inspired style. To see example of this get your copy of mochiweb:
svn checkout http://mochiweb.googlecode.com/svn/trunk/ mochiweb
and use
path/to/mochiweb/scripts/new_mochiweb.erl new_project_name
to create sample project of the structure (feel free to delete everything inside src afterwards and use it for your project).
It looks like this:
/
/ebin/
/deps/
/src/
/include/
/support/
/support/include.mk
Makefile
start.sh
ebin contains *.beam files
src contains ***.erl files and local *.hrl files
include contains global *.hrl files
deps contains symlinks to root directories of dependencies
Makefile and include.mk takes care of including appropriate paths when project is built.
start.sh takes care of including appropriate paths when project is run.
So using symlinks in deps directory you are able to fine tune the versions of libraries you use for every project. It is advised to use relative paths, so afterwards it is enough to rsync this structure to the production server and run it.
On more global scale I use the following structure:
~/code/erlang/libs/*/
~/code/category/project/*/
~/code/category/project/*/deps/*/
Where every symlink in deps points to the library in ~/code/erlang/libs/ or to another project in the same category.
The simplest way to do this would be to just create a folder named erldir and put the beams you need into it and then in your start script just use the -pa flag to the erlang runtime to point out where it should fetch the beams.
The correct way (at least if you buy into the OTP distribution model) would be to create a release using reltool (http://www.erlang.org/doc/man/reltool.html) or systools (http://www.erlang.org/doc/man/systools.html) which includes both your application and erldis.
Add the external libraries that you need, anywhere you want them, and add them to your ERL_LIBS environment variable. Separate the paths with colon in unix or semicolon in dos.
Erlang will add the "ebin"-named subdirs to its code loading path.
Have your *.app file point out the other applications it depends on.
This is a good halfway-there approach for setting up larger applications.
Another way is put your lib path in ~/.erlang.
code:add_pathz("/Users/brucexin/sources/mochiweb/ebin").
code:add_pathz("/Users/brucexin/sources/webnesia/ebin").
code:add_pathz("./ebin").
code:add_pathz("/Users/brucexin/sources/erlang-history/ebin/2.15.2").