Ah, replace is better thanks. You can tell I've been a C programmer for most of my life.
Anyway, so are you saying that if I call replace() with constant inputs, it will get called at compile time automatically? Or are you saying I need to use a macro to do that, to force it to be called at compile time? I think the first is what I meant by constant function. Sorry for what must seem like a really dumb question. Bill. On 18 September 2015 at 22:24, Jameson Nash <[email protected]> wrote: > That seems like an odd way to write replace(somdir, "\\", "\\\\"), but no, > those functions aren't const. You need to actually call them at compile > time and store the result in a global const variable. > > > On Fri, Sep 18, 2015 at 2:59 PM 'Bill Hart' via julia-users < > [email protected]> wrote: > >> Thanks, but this appears to be undocumented: >> >> http://julia.readthedocs.org/en/latest/stdlib/file/ >> >> Or am I looking in the wrong place in the documentation? >> >> I guess I also need to ask a stupid question now. So is it possible to >> compute a constant directory path (i.e. a constant string) made from a >> number of other constant strings? >> >> As I said, one needs to do things like join(split(somedir, "\\"), >> "\\\\"), which would require calling join and split on (constant) strings >> at compile time. Does Julia propagate constants at compile time, even >> through function calls to join and split, etc? >> >> Bill. >> >> On 18 September 2015 at 20:52, Jameson Nash <[email protected]> wrote: >> >>> You should be able to work out everything relative to source_path() at >>> compile time (this is what `include` does to find files relative to the >>> current file being included). >>> >>> >>> On Fri, Sep 18, 2015 at 2:47 PM 'Bill Hart' via julia-users < >>> [email protected]> wrote: >>> >>>> Sorry, I didn't explain that well. >>>> >>>> It is the location of deps/deps.jl that is not at a constant location >>>> _relative_ to the current working directory, which could be anything. I >>>> can't hard code it to an absolute path since that will just break on >>>> someone else's machine. >>>> >>>> The whole point of the deps/deps.jl fix suggested n the post above was >>>> to get around the fact that your external libraries might be in directories >>>> that can only be known at runtime, so you get build.jl to write them into >>>> deps/desp.jl and include it. >>>> >>>> But deps/deps.jl is also at a location that can only be known at >>>> runtime. Catch 22. >>>> >>>> I have to insert a cd() before include("deps/deps.jl") and need a >>>> different directory on Windows to Linux and lots of nasty things like that. >>>> Not to mention needing to pull apart the strings for the directories and >>>> insert \\\\ everywhere in build.jl when writing the directories out to the >>>> file deps/deps.jl so that they end up double quoted in deps/deps.jl. It >>>> just seems like an extremely messy solution to a simple problem. >>>> >>>> And then there's the problem that on Windows, directories apparently >>>> can't contain ".." as they can on Linux. So you have to canonicalise them, >>>> which means more manipulation, etc. >>>> >>>> What I was essentially suggesting is that we need a version of include >>>> that includes files relative to a given package dir. Yes, you can make such >>>> a directory yourself out of Pkg.dir("Mypackage"), etc. But then this is not >>>> a constant directory and so apparently can't be done from within __init__, >>>> at least not with precompilation enabled. In such a location, you >>>> apparently need constant strings. >>>> >>>> I did manage to make all this work in the end, but the code I ended up >>>> with feels pretty messy. >>>> >>>> As for Libdl.DL_LOAD_PATH, I am setting that. But again, (at least in >>>> the presence of precompilation), Julia is no longer able to find the >>>> libraries when called from __init__. Just setting Libdl.LD_LOAD_PATH in >>>> __init__ (or elsewhere) does not fix this problem. The libraries still >>>> require explicit, constant, canonicalised, absolute paths in the ccalls and >>>> cglobals in __init__, unlike anywhere else in Julia. >>>> >>>> Sorry, that seems like a rant. It's not intended to be. I'm just trying >>>> to list some of the issues. >>>> >>>> I appreciate there are some limitations on what is actually possible. >>>> But at present, it's really hard to find any solution, which makes it seem >>>> like there must be a better way. >>>> >>>> Bill. >>>> >>>> On 18 September 2015 at 20:27, Jameson Nash <[email protected]> wrote: >>>> >>>>> > * putting const library name strings in deps/deps.jl is problematic >>>>> because the working directory may be different depending on whether you >>>>> are >>>>> running the module test suite or just using the module from the Julia >>>>> console. >>>>> >>>>> presumably running the code in the code from the test suite and >>>>> running it from the console shouldn't be rearranging your filesystem? >>>>> regardless, the intent behind Libdl.DL_LOAD_PATH was to help handle this >>>>> case. >>>>> >>>>> >>>>> On Fri, Sep 18, 2015 at 10:13 AM Bill Hart < >>>>> [email protected]> wrote: >>>>> >>>>>> I managed to get it to work. The problem was obscure. >>>>>> >>>>>> * the patch someone had come up with for putting the -rpath in >>>>>> libpari was faulty >>>>>> * I thought libgmp.so.16 was resolving (when I did ldd) because part >>>>>> of the procedure to put the -rpath in the library was to put the library >>>>>> path in LD_LIBRARY_PATH >>>>>> * I was running Julia itself from a different terminal, where >>>>>> LD_LIBRARY_PATH was not set. >>>>>> >>>>>> So that problem is fixed. I can now initialise the Pari library from >>>>>> within __init__. >>>>>> >>>>>> Two issues remain: >>>>>> >>>>>> * the rpath was not needed in the library to run pari_init in the >>>>>> libpari library from outside __init__, only from inside (I checked this >>>>>> carefully). >>>>>> >>>>>> * putting const library name strings in deps/deps.jl is problematic >>>>>> because the working directory may be different depending on whether you >>>>>> are >>>>>> running the module test suite or just using the module from the Julia >>>>>> console. >>>>>> >>>>>> It would be nice to have a mechanism for including files from a given >>>>>> module with a constant string describing the location of the file to >>>>>> include, no matter what the current directory happens to be. >>>>>> >>>>>> As always, thanks for the help. >>>>>> >>>>>> Bill. >>>>>> >>>>> >>>> >>
