Using Kawa 1.14.
I have tried opening the directory as a file (because file-exists? reports #t), and using read-line to read the "contents", but it does not work. I get an "Access denied" error.
At the Java level, there are two ways to list directories. You can use File.list or File.listFiles, or you can use Files.newDirectoryStream.
At the Kawa level, having briefly grepped through the source, it doesn't seem to use any of those interfaces. So it doesn't look like there's a built-in way to list directories in Kawa. You would need to use Kawa's Java method invocation features to invoke one of the above interfaces.
Looking through the source, I found kawa\lib\files.scm, which defines directory-files.
So, it is just a matter of:
(require <kawa.lib.files>)
(directory-files path)
Related
I'm trying to use Atom to run a Lua script. However, when I try to load files via the require() command, it always says it's unable to locate them. The files are all in the same folder. For example, to load utils.lua I have tried
require 'utils'
require 'utils.lua'
require 'D:\Users\Mike\Dropbox\Lua Modeling\utils.lua'
require 'D:\\Users\\Mike\\Dropbox\\Lua Modeling\\utils.lua'
require 'D:/Users/Mike/Dropbox/Lua Modeling/utils.lua'
I get errors like
Lua: D:\Users\Mike\Dropbox\Lua Modeling\main.lua:12: module 'D:\Users\Mike\Dropbox\Lua Modeling\utils.lua' not found:
no field package.preload['D:\Users\Mike\Dropbox\Lua Modeling\utils.lua']
no file '.\D:\Users\Mike\Dropbox\Lua Modeling\utils\lua.lua'
no file 'D:\Program Files (x86)\Lua\5.1\lua\D:\Users\Mike\Dropbox\Lua Modeling\utils\lua.lua'
no file 'D:\Program Files (x86)\Lua\5.1\lua\D:\Users\Mike\Dropbox\Lua Modeling\utils\lua\init.lua'
no file 'D:\Program Files (x86)\Lua\5.1\D:\Users\Mike\Dropbox\Lua Modeling\utils\lua.lua'
The messages says on the first line that 'D:\Users\Mike\Dropbox\Lua Modeling\utils.lua' was not found, even though that is the full path of the file. What am I doing wrong?
Thanks.
The short answer
You should be able to load utils.lua by using the following code:
require("utils")
And by starting your program from the directory that utils.lua is in:
cd "D:\Users\Mike\Dropbox\Lua Modeling"
lua main.lua
The long answer
To understand what is going wrong here, it is helpful to know a little bit about how require works. The first thing that require does is to search for the module in the module path. From Programming in Lua chapter 8.1:
The path used by require is a little different from typical paths. Most programs use paths as a list of directories wherein to search for a given file. However, ANSI C (the abstract platform where Lua runs) does not have the concept of directories. Therefore, the path used by require is a list of patterns, each of them specifying an alternative way to transform a virtual file name (the argument to require) into a real file name. More specifically, each component in the path is a file name containing optional interrogation marks. For each component, require replaces each ? by the virtual file name and checks whether there is a file with that name; if not, it goes to the next component. The components in a path are separated by semicolons (a character seldom used for file names in most operating systems). For instance, if the path is
?;?.lua;c:\windows\?;/usr/local/lua/?/?.lua
then the call require"lili" will try to open the following files:
lili
lili.lua
c:\windows\lili
/usr/local/lua/lili/lili.lua
Judging from your error message, your Lua path seems to be the following:
.\?.lua;D:\Program Files (x86)\Lua\5.1\lua\?.lua;D:\Program Files (x86)\Lua\5.1\lua\?\init.lua;D:\Program Files (x86)\Lua\5.1\?.lua
To make that easier to read, here are each the patterns separated by line breaks:
.\?.lua
D:\Program Files (x86)\Lua\5.1\lua\?.lua
D:\Program Files (x86)\Lua\5.1\lua\?\init.lua
D:\Program Files (x86)\Lua\5.1\?.lua
From this list you can see that when calling require
Lua fills in the .lua extension for you
Lua fills in the rest of the file path for you
In other words, you should just specify the module name, like this:
require("utils")
Now, Lua also needs to know where the utils.lua file is. The easiest way is to run your program from the D:\Users\Mike\Dropbox\Lua Modeling folder. This means that when you run require("utils"), Lua will expand the first pattern .\?.lua into .\utils.lua, and when it checks that path it will find the utils.lua file in the current directory.
In other words, running your program like this should work:
cd "D:\Users\Mike\Dropbox\Lua Modeling"
lua main.lua
An alternative
If you can't (or don't want to) change your working directory to run the program, you can use the LUA_PATH environment variable to add new patterns to the path that require uses to search for modules.
set LUA_PATH=D:\Users\Mike\Dropbox\Lua Modeling\?.lua;%LUA_PATH%;
lua "D:\Users\Mike\Dropbox\Lua Modeling\main.lua"
There is a slight trick to this. If the LUA_PATH environment variable already exists, then this will add your project's folder to the start of it. If LUA_PATH doesn't exist, this will add ;; to the end, which Lua fills in with the default path.
I am currently trying to figure out how to install the Common Music library: http://commonmusic.sourceforge.net/cm2/doc/cm.html, to run on Portacle, an IDE that integrates Emacs among other implementations to run Common LISP.
I was able to successfully download Common Music's source tree to my Portacle installation directory following these steps, found at http://commonmusic.sourceforge.net/cm2/doc/install.html#cvs :
Change directories to your Lisp installation directory.
$ cd /usr/local/lisp
Set the shell variable CVSROOT to point to the CVS repository:
$ export CVSROOT=":pserver:anonymous#commonmusic.cvs.sourceforge.net:/cvsroot/commonmusic"
Use cvs login to connect to the Sourceforge CVS server, press Enter when prompted for a password:
$ cvs login
CVS password:
Use cvs checkout to restore CM's source tree to your Lisp installation directory:
$ cvs checkout -P cm
.
Opening my Common Lisp REPL, portacle, I typed in the equivalent of (load "/usr/local/lisp/cm/src/cm.lisp") for my specific pathname for cm.lisp.
I recieved the following errors.
READ error during LOAD:
Symbol "UNIX-FILE-KIND" not found in the SB-UNIX package.
Line: 116, Column: 47, File-Position: 4278
Stream: #<SB-INT:FORM-TRACKING-STREAM for "file /usr/local/lisp/cm/cm.asd" {1004108F23}>
[Condition of type SB-C::INPUT-ERROR-IN-LOAD]
.
If anyone is familiar with Common Lisp and integrating Common Music, any help would be greatly appreciated.
Thanks.
The problem is that this system was written for a different world. Unix-file-kind was removed from sb-unix over 10 years ago.
Here, it is used to determine whether a pathname names an existing directory.
I am not sure how using cl-fad in that system loading context would work (this could be made much simpler nowadays, but that's some work), so maybe you could either inline whatever cl-fad:directory-exists-p does, or maybe this works for you (it's a little hacky though):
#+sbcl (let ((truename (probe-file dir)))
(and truename
(string= (namestring truename)
(directory-namestring truename))))
You'd replace the line in cm.lisp that currently says #+sbcl (eq :directory (sb-unix:unix-file-kind (namestring dir))) with this.
… but I expect that this is only the tip of the iceberg. Good luck!
Is it possible to tell ASDF that it should produce only one fas(l) file for entire system? This file should be concatenation (in right order) of all compiled files of the system, including all files of systems on which target system depends.
Yes, with compile-bundle-op (ASDF 3.1): http://common-lisp.net/project/asdf/asdf/Predefined-operations-of-ASDF.html
edit: Actually, monolithic-compile-bundle-op seemes to be asked for (as shown in other answers).
If you have to predict the extension, use uiop:compile-file-type.
And/or you can just call (asdf:output-files 'asdf:monolithic-compile-bundle-op :my-system) to figure out what is actually used.
Option monolithic-compile-bundle-op will create single compiled file which includes all dependencies, while compile-bundle-op creates a file for every system.
Example of use:
(asdf:operate 'asdf:monolithic-compile-bundle-op :my-system)
This command will create file my-system--all-systems.fas(l) in output directory of target project, as well as "bundle" files for every system, named like my-system--system.fas(l).
I have a project that contains a folder to manage file templates, but it doesn't look like Go provides any support for non-Go-code project files. The project itself compiles to an executable, but it needs to know where this template folder is in order to operate correctly. Right now I do a search for $GOPATH/src/<templates>/templates, but this feels like kind of a hack to me because it would break if I decided to rename the package or host it somewhere else.
I've done some searching and it looks like a number of people are interested in being able to "compile" the asset files by embedding them in the final binary, but I'm not sure how I feel about this approach.
Any ideas?
Either pick a path (or a list of paths) that users are expected to put the supporting data in (/usr/local/share/myapp, ...) or just compile it into the binary.
It depends on how you are planning to distribute the program. As a package? With an installer?
Most of my programs I enjoy just having a single file to deploy and I just have a few templates to include, so I do that.
I have an example using go-bindata where I build the html template with a Makefile, but if I build with the 'devel' flag it will read the file at runtime instead to make development easier.
I can think of two options, use a cwd flag, or infer from cwd and arg 0:
-cwd path/to/assets
path/to/exe -cwd=$(path/to/exe/assets)
Internally, the exectable would chdir to wherever cwd points to, and then it can use relative paths throughout the application. This has the added benefit that the user can change the assets without having to recompile the program.
I do this for config files. Basically the order goes:
process cmd arguments, looking for a -cwd variable (it defaults to empty)
chdir to -cwd
parse config file
reparse cmd arguments, overwriting the settings in the config file
I'm not sure how many arguments your app has, but I've found this to be very useful, especially since Go doesn't have a standard packaging tool that will compile these assets in.
infer from arg 0
Another option is to use the first argument and get the path to the executable. Something like this:
here := path.Dir(os.Args[0])
if !path.IsAbs(os.Args[0]) {
here = path.Join(os.Getwd(), here)
}
This will get you the path to where the executable is. If you're guaranteed the user won't move this without moving the rest of your assets, you can use this, but I find it much more flexible to use the above -cwd idea, because then the user can place the executable anywhere on their system and just point it to the assets.
The best option would probably be a mixture of the two. If the user doesn't supply a -cwd flag, they probably haven't moved anything, so infer from arg 0 and the cwd. The cwd flag overrides this.
am trying to extract to use all my box file to extract characters and when i try this line
unicharset_extractor *.box
it gives me an error that it cannot find *.box instead of loading all box files.
That specific program does not support such syntax. You have to chain the names of all the box files and feed to it, such as:
unicharset_extractor lang.fontname.exp0.box lang.fontname.exp1.box ...
You can write a script (e.g., train.ps1) to automate the process.
http://code.google.com/p/tesseract-ocr/wiki/TrainingTesseract3
I finally made my own tool for that .
[link]http://code.google.com/p/serak-tesseract-trainer/