Yes, I fear that you are right. I had a hack through the code last night.

It looks to me like the metadata is set in the
Compiler.load(Reader,String,String) method. This is called from only a
couple of places. From within Compiler, it's called from loadFile.



public static Object loadFile(String file) throws IOException{
//      File fo = new File(file);
//      if(!fo.exists())
//              return null;

        FileInputStream f = new FileInputStream(file);
        try
                {
                return load(new InputStreamReader(f, RT.UTF8), new 
File(file).getAbsolutePath(), (new File(file)).getName());
                }
        finally
                {
                f.close();
                }
}

Here the string file name is absolute using the File class.

However, it's also called from ....

RT.loadResourceScript(Class c, String name, boolean failIfNotFound)

Which gets the file metadata like so...

        int slash = name.lastIndexOf('/');
        String file = slash >= 0 ? name.substring(slash + 1) : name;

And reads the input stream through the classloader. 

This is a bit messy; it should be consistent I think!

Phil


Michael Wood <esiot...@gmail.com> writes:

> Just s guess: Maybe the classpath is absolute in one case and relative in
> the other.
>
> On 07 Nov 2013 7:15 PM, "Phillip Lord" <phillip.l...@newcastle.ac.uk> wrote:
>>
>>
>> I find myself confused by the metadata on a var. Consider this code:
>>
>> (def a-test-var 10)
>>
>> (pritnln (meta #'a-test-var))
>>
>> Now when run under "lein test" (by stuffing it into a test namespace), I
>> get this....
>>
>>
>> {:ns #<Namespace tawny.util-test>, :name a-test-var, :column 1, :line
> 102, :file tawny/util_test.clj}
>>
>>
>> But, when evaled in a live REPL I get this...
>>
>>
>> {:ns #<Namespace tawny.util-test>, :name a-test-var, :column 1, :line
> 102, :file
> "/home/phillord/src/knowledge/tawny-owl/test/tawny/util_test.clj"}
>>
>>
>> So, how come the :file is fully qualified in one case, and relative in
>> the other?
>>
>> Phil
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
> -- 

-- 
Phillip Lord,                           Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics,             Email: phillip.l...@newcastle.ac.uk
School of Computing Science,            
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to