On Oct 5, 2010, at 7:37 PM, Ryan Culpepper wrote:

> John Clements wrote:
>> On Oct 5, 2010, at 3:25 PM, Ryan Culpepper wrote:
>>> It looks like you're using a PLaneT development link. Perhaps that's the 
>>> source of the problem?
>>> How about dropping the following code into drracket-link.rkt so it prints 
>>> out its (absolute) resolved module path when it gets required from the tool.
>>> (eprintf "drracket-link.rkt = ~s\n"
>>>          (resolved-module-path-name
>>>           (variable-reference->resolved-module-path
>>>            (#%variable-reference))))
>> wait... isn't that part of the error message I attached earlier?  Viz:
>> namespace-attach-module: unknown module (in the source namespace): 
>> #<resolved-module-path:"/Users/clements/clements/planet-collects/rsound/private/drracket-link.rkt">
> No, that's based on the absolute module path you passed to namespace-attach 
> module.
> What I'm wondering about is, when you use the relative require, what does the 
> module think its resolved module path is. That's what the expression above is 
> designed to show.

Fooey.  Okay, here's what I get:

pcp062719pcs:~/git-clements clements$ drracket-link.rkt = 
namespace-attach-module: unknown module (in the source namespace): 


The difference between these is a symbolic link from ~/clements/planet-collects 
to ~/git-clements/clements/planet-collects.

.... aaand, sure enough, re-creating the link using a fully-expanded path 
solves this problem.

So, it looks like planet is broken wrt planet-links containing symbolic links.  
Maybe you could solve this by just putting a fully-expand-path-mumble somewhere 
very early in the signal chain? ... Hmm, actually that might not be such a 
great idea; you break the abstraction of the symbolic link from the standpoint 
of the user.



Attachment: smime.p7s
Description: S/MIME cryptographic signature

  For list-related administrative tasks:

Reply via email to