You need to run it in global scope at compile time, so that the value is
constant when later running AFunction:
module HiThere
const AConstant = compute_anything()
function AFunction()
ccall((:a_cfunction, AConstant), Void, ())
end
end
On Fri, Sep 18, 2015 at 5:10 PM 'Bill Hart' via julia-users <
[email protected]> wrote:
> 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.
>>>>>>>
>>>>>>
>>>>>
>>>
>
