When trying to use an mpd interface for common lisp, the corresponding asdf system having been named simply "mpd", I came across a peculiar problem. When I loaded the system, it would appear to succeed, yet when I tried to use the functions, it would claim they were undefined. Experimentally, I tried to rename the system "cl-mpd", and load that, only to find that it worked. I therefore concluded that ASDF were loading a different system, also named "mpd". Generally wanting to avoid such hackery as renaming systems, I looked for the offending system in the installation directories for quicklisp, to no avail. I searched for it in my home folder, with no success.
So now I ask you: is there a way to get the location of an ASDF system on disk?
Is this what you're looking for?
(asdf:system-relative-pathname :foo "foo/bar/baz.lisp")
(asdf:component-pathname (asdf:find-component :foo '("bar" "baz")))
find the system
get the components
look at one of them
Example:
(describe (first (asdf:module-components (asdf:find-system "mpd"))))
Related
I have a module I wrote here:
# Hello.jl
module Hello
function foo
return 1
end
end
and
# Main.jl
using Hello
foo()
When I run the Main module:
$ julia ./Main.jl
I get this error:
ERROR: LoadError: ArgumentError: Hello not found in path
in require at ./loading.jl:249
in include at ./boot.jl:261
in include_from_node1 at ./loading.jl:320
in process_options at ./client.jl:280
in _start at ./client.jl:378
while loading /Main.jl, in expression starting on line 1
There is a new answer to this question since the release of Julia v0.7 and v1.0 that is slightly different. I just had to do this so I figured I'd post my findings here.
As already explained in other solutions, it is necessary to include the relevant script which defines the module. However, since the custom module is not a package, it cannot be loaded as a package with the same using or import commands as could be done in older Julia versions.
So the Main.jl script would be written with a relative import like this:
include("./Hello.jl")
using .Hello
foo()
I found this explained simply in Stefan Karpinski's discourse comment on a similar question. As he describes, the situation can also get more elaborate when dealing with submodules. The documentation section on module paths is also a good reference.
EDIT: Updated code to apply post-v1.0. The other answers still have a fundamental problem: if you define a module and then include that module definition in multiple places, you will get unexpected hard-to-understand errors. #kiliantics' answer is correct as long as you only include the file once. If you have a module that you're using across multiple files, make that module into a package, use add MyModule, and then type using MyModule in as many places as you want, letting Pkg handle module identity for you.
Though 张实唯's answer is the most convenient, you should not use include outside the REPL (or just once per included file as a simple practice to organize large modules, as in the first example here). If you're writing a program file, go through the trouble of adding the appropriate directory to the LOAD_PATH. Remy gives a very good explanation of how to do so, but it's worth also explaining why you should do so in the first place. (Additionally from the docs: push!(LOAD_PATH, "/Path/To/My/Module/") but note your module and your file have to have the same name)
The problem is that anything you include will be defined right where you call include even if it is also defined elsewhere. Since the goal of modules is re-use, you'll probably eventually use MyModule in more than one file. If you call include in each file, then each will have its own definition of MyModule, and even though they are identical, these will be different definitions. That means any data defined in the MyModule (such as data types) will not be the same.
To see why this is a huge problem, consider these three files:
types.jl
module TypeModule
struct A end
export A
end
a_function.jl
include("types.jl")
module AFunctionModule
using ..TypeModule
function takes_a(a::A)
println("Took A!")
end
export takes_a
end
function_caller.jl
include("a_function.jl")
include("types.jl") # delete this line to make it work
using .TypeModule, .AFunctionModule
my_a = A()
takes_a(my_a)
If you run julia function_caller.jl you'll get MethodError: no method matching takes_a(::A). This is because the type A used in function_caller.jl is different from the one used in a_function.jl. In this simple case, you can actually "fix" the problem by reversing the order of the includes in function_caller.jl (or just by deleting include("types.jl") entirely from function_caller.jl! That's not good!). But what if you wanted another file b_function.jl that also used a type defined in TypeModule? You would have to do something very hacky. Or you could just modify your LOAD_PATH so the module is only defined once.
EDIT in response to xji: To distribute a module, you'd use Pkg (docs). I understood the premise of this question to be a custom, personal module. It's also fine for distribution if you know the relative path of the directory containing your module definition from each file that needs to load that module, e.g. if all your files are in the same folder then you'd just have push!(LOAD_PATH, #__DIR__).
Incidentally, if you really don't like the idea of modifying your load path (even if it's only within the scope of a single script...) you could symlink your module into a package directory (e.g. ~/.julia/v0.6/MyModule/MyModule.jl) and then Pkg.add(MyModule) and then import as normal. I find that to be a bit more trouble.
This answer has been OUTDATED. Please see other excellent explanations.
===
You should include("./Hello.jl") before using Hello
This answers was originally written for Julia 0.4.5. There is now an easier way of importing a local file (see #kiliantics answer). However, I will leave this up as my answer explains several other methods of loading files from other directories which may be of use still.
There have already been some short answers, but I wanted to provide a more complete answer if possible.
When you run using MyModule, Julia only searches for it in a list of directories known as your LOAD_PATH. If you type LOAD_PATH in the Julia REPL, you will get something like the following:
2-element Array{ByteString,1}:
"/Applications/Julia-0.4.5.app/Contents/Resources/julia/local/share/julia/site/v0.4"
"/Applications/Julia-0.4.5.app/Contents/Resources/julia/share/julia/site/v0.4"
These are the directories that Julia will search for modules to include when you type using Hello. In the example that you provided, since Hello was not in your LOAD_PATH, Julia was unable to find it.
If you wish to include a local module, you can specify its location relative to your current working directory.
julia> include("./src/Hello.jl")
Once the file has been included, you can then run using Hello as normal to get all of the same behavior. For one off scripts, this is probably the best solution. However, if you find yourself regular having to include() a certain set of directories, you can permanently add them to your LOAD_PATH.
Adding directories to LOAD_PATH
Manually adding directories to your LOAD_PATH can be a pain if you wish to regularly use particular modules that are stored outside of the Julia LOAD_PATH. In that case, you can append additional directories to the LOAD_PATH environment variable. Julia will then automatically search through these directories whenever you issue an import or using command.
One way to do this is to add the following to your .basrc, .profile, .zshrc.
export JULIA_LOAD_PATH="/path/to/module/storage/folder"
This will append that directory onto the standard directories that Julia will search. If you then run
julia> LOAD_PATH
It should return
3-element Array{ByteString,1}:
"/path/to/module/storage/folder"
"/Applications/Julia-0.4.5.app/Contents/Resources/julia/local/share/julia/site/v0.4"
"/Applications/Julia-0.4.5.app/Contents/Resources/julia/share/julia/site/v0.4"
You can now freely run using Hello and Julia will automatically find the module (as long as it is stored underneath /path/to/module/storage/folder.
For more information, take a look at this page from the Julia Docs.
Unless you explicitly load the file (include("./Hello.jl")) Julia looks for module files in directories defined in the LOAD_PATH variable.
See this page.
I have Julia Version 1.4.2 (2020-05-23). Just this using .Hello worked for me.
However, I had to compile the Hello module before just using .Hello. It makes sense for both the defined and using scripts of Hello is on the same file.
Instead, we can define Hello in one file and use it in a different file with include("./Hello.jl");using .Hello
If you want to access function foo when importing the module with "using" you need to add "export foo" in the header of the module.
In the package inferred system, you can specify a dependency on a package of the form "a/b/c" where a is the package name and there is a lisp file at "b/c.lisp" that defines the "a/b/c" package.
Is there a way to specify a different path for the file for the package inferred system? For example say the file is at "src/b/c.lisp" instead of "b/c.lisp".
It's probably a bug that package-inferred-system uses system-source-directory instead of component-pathname. If you think it is, please file a bug against https://bugs.launchpad.net/asdf
Unhappily, bug or not, any fix isn't going to be released then made universal for a while. So at least for the next two years, you can't rely on it unless you provide your own fixed ASDF.
As for a workaround — why not place your .asd file in src/ if you want all source under there???
You can use register-system-packages to specify which packages a system provides. You can read more here
Since in http://julia.readthedocs.org/en/latest/manual/modules/ there's no much info about modules, I would like to ask the following.
I want to try two modules via ijulia. Both modules are in my working directory as
name-of-files.jul. I will call them generically module_1.jul and module_2.jul.
module_1.jul uses module_2.jul and I load it with
using module_2
On ijulia session, if I try
using module_1
gives an error. I also tried
include("module_1.jul")
This last sentence, when executed, rises an error because the module_1.jul cannot find
variable "x" that I know is contained in module_1.jul (in this case I "loaded" the module
using include("module2.jul") inside module_1.jul
Julias module system assumes some things that aren't necessarily obvious from the documenation at first.
Julia files should end with .jl extensions.
Julia looks for module files in directories defined in the LOAD_PATH variable.
Julia looks for files in those directories in the form ModuleName/src/file.jl
If using module_1 fails then I'm guessing it's because it's source files fail one of the above criteria.
Some time has passed since this question. Recently, Noah_S wrote the solution in the comments of the previous answer; this means that it is a recurrent doubt for people starting to learn the language. For their sake, I will re-write it here Noah_S' answer along with my most novel solution.
I am a mess with the julia versions and which commands work with the specific ones, so for older julia versions we have to look for the \path and then include in the julia module
push!(LOAD_PATH, "/path")
In newer versions this can be improved. Forget about looking by hand the path and just do
path = readstring(`pwd`)
push!(LOAD_PATH, chomp(path))
I hope this can be useful to many julians newcomers.
I have got a memory image, that i can't find the source for and I want to get the code out of it again. What do i have to do to achieve that? I can obviously load the image, but then i'd need to guess the function names.
You may get "interesting" symbols with (apropos ""), and the function names with WITH-PACKAGE-ITERATOR and FBOUNDP. But the source code is (probably) lost: try DISASSEMBLE on functions and see the information which is there.
In addition to DISASSEMBLE, you might try EXT:UNCOMPILE. Note, however, that it will only work on functions compiled in an interactive session (i.e., from REPL), not on those loaded from a compiled .fas file.
So, the suggested procedure is:
LIST-ALL-PACKAGES - figure out which packages are interesting.
DO-EXTERNAL-SYMBOLS - figure out which symbols in the interesting packages are interesting.
DISASSEMBLE or EXT:UNCOMPILE on those interesting symbols.
However, the easiest way is to contact your vendor. Remember, CLISP is distributed under the GNU GPL.
I'm new to using Common Lisp and currently using Lispbox.
I would like to add a color-theme package to Lispbox running on OSX to change the color theme.
I'm currently trying to use the command:
(add-to-list 'load-path "~/desktop/colortheme/")
However I keep getting the same error:
Undefined function ADD-TO-LIST called with arguments (LOAD-PATH "/desktop/colortheme/").
Can someone please help me as to what to do from here?
Thanks in advance,
Cameron
As far as I know, Lispbox is simply a preconfigured bundle of Emacs, Slime, and Clozure CL. I think that you might be confusing the Emacs Lisp and the Common Lisp parts of that bundle. You need to put the snippet you showed into the Emacs Lisp part, i.e. (to get that configuration at startup) the .emacs configuration file. The REPL, that is, the CL-USER > prompt, is the Common Lisp interface and has nothing to do with Emacs' inner workings.