[racket-dev] single-instantiation trick: kludgy workaround for planet packages?
A couple of weeks ago, you showed me the trick that rackunit uses to allow single-instantiation of a modules. I'm now trying to do this for a planet package, and it looks like I have to change the required module from being a relative to being an absolute path. That is: (require (prefix-in drlink: private/drracket-link)) must become (require (prefix-in drlink: (planet drracket-link.rkt (clements rsound.plt) private))) This works, but seems extremely fragile. Does it make sense to you that this would be required? Without it, I get the error below: namespace-attach-module: unknown module (in the source namespace): #resolved-module-path:/Users/clements/clements/planet-collects/rsound/private/drracket-link.rkt === context === /Users/clements/plt/collects/drracket/private/rep.rkt:1660:6: initialize-console method in ...cket/private/rep.rkt:508:4 /Users/clements/plt/collects/drracket/private/unit.rkt:4755:4: create-new-drscheme-frame /Users/clements/plt/collects/drracket/private/main.rkt:663:0: make-basic /Users/clements/plt/collects/drracket/tool-lib.rkt: [running body] /Users/clements/plt/collects/drracket/private/drracket-normal.rkt: [running body] /Users/clements/plt/collects/drracket/drracket.rkt: [running body] semi-happy, John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] single-instantiation trick: kludgy workaround for planet packages?
John, See this-package-in, found both in the cce/scheme planet package and in unstable/require. If you write (prefix-in drlink: (this-package-in private/drracket-link)) you should get the behavior you want, and it should be less fragile than the explicit planet path. Carl Eastlund On Tue, Oct 5, 2010 at 5:59 PM, John Clements cleme...@brinckerhoff.org wrote: A couple of weeks ago, you showed me the trick that rackunit uses to allow single-instantiation of a modules. I'm now trying to do this for a planet package, and it looks like I have to change the required module from being a relative to being an absolute path. That is: (require (prefix-in drlink: private/drracket-link)) must become (require (prefix-in drlink: (planet drracket-link.rkt (clements rsound.plt) private))) This works, but seems extremely fragile. Does it make sense to you that this would be required? Without it, I get the error below: namespace-attach-module: unknown module (in the source namespace): #resolved-module-path:/Users/clements/clements/planet-collects/rsound/private/drracket-link.rkt === context === /Users/clements/plt/collects/drracket/private/rep.rkt:1660:6: initialize-console method in ...cket/private/rep.rkt:508:4 /Users/clements/plt/collects/drracket/private/unit.rkt:4755:4: create-new-drscheme-frame /Users/clements/plt/collects/drracket/private/main.rkt:663:0: make-basic /Users/clements/plt/collects/drracket/tool-lib.rkt: [running body] /Users/clements/plt/collects/drracket/private/drracket-normal.rkt: [running body] /Users/clements/plt/collects/drracket/drracket.rkt: [running body] semi-happy, John _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] single-instantiation trick: kludgy workaround for planet packages?
On 10/05/2010 03:59 PM, John Clements wrote: A couple of weeks ago, you showed me the trick that rackunit uses to allow single-instantiation of a modules. I'm now trying to do this for a planet package, and it looks like I have to change the required module from being a relative to being an absolute path. That is: (require (prefix-in drlink: private/drracket-link)) I assume (hope) you meant (require (prefix-in drlink: private/drracket-link.rkt)) for the relative require. must become (require (prefix-i ;; -- Another thing to consider, if you're going to be distributing this code via PLaneT, is that users will have to restart DrRacket after installing the package so the tool can take effect. n drlink: (planet drracket-link.rkt (clements rsound.plt) private))) This works, but seems extremely fragile. Does it make sense to you that this would be required? Without it, I get the error below: From what I recall, the call to namespace-module-attach must use the correct absolute module path, but the require can be relative. I confirmed that that's how the last PLaneT version of schemeunit that included the tool (version (2 12)) did it. 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 Ryan _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] single-instantiation trick: kludgy workaround for planet packages?
I seem to have mangled my response right before sending it. Here it is again, hopefully straightened out. On 10/05/2010 03:59 PM, John Clements wrote: A couple of weeks ago, you showed me the trick that rackunit uses to allow single-instantiation of a modules. I'm now trying to do this for a planet package, and it looks like I have to change the required module from being a relative to being an absolute path. That is: (require (prefix-in drlink: private/drracket-link)) I assume (hope) you meant (require (prefix-in drlink: private/drracket-link.rkt)) for the relative require. must become (require (prefix-in drlink: (planet drracket-link.rkt (clements rsound.plt) private))) This works, but seems extremely fragile. Does it make sense to you that this would be required? Without it, I get the error below: From what I recall, the call to namespace-module-attach must use the correct absolute module path, but the require can be relative. I confirmed that that's how the last PLaneT version of schemeunit that included the tool (version (2 12)) did it. 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 ;; -- Another thing to consider, if you're going to be distributing this code via PLaneT, is that users will have to restart DrRacket after installing the package so the tool can take effect. Ryan _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] single-instantiation trick: kludgy workaround for planet packages?
John Clements wrote: On Oct 5, 2010, at 3:25 PM, Ryan Culpepper wrote: I seem to have mangled my response right before sending it. Here it is again, hopefully straightened out. On 10/05/2010 03:59 PM, John Clements wrote: A couple of weeks ago, you showed me the trick that rackunit uses to allow single-instantiation of a modules. I'm now trying to do this for a planet package, and it looks like I have to change the required module from being a relative to being an absolute path. That is: (require (prefix-in drlink: private/drracket-link)) I assume (hope) you meant (require (prefix-in drlink: private/drracket-link.rkt)) for the relative require. yes, of course. My mistake. must become (require (prefix-in drlink: (planet drracket-link.rkt (clements rsound.plt) private))) This works, but seems extremely fragile. Does it make sense to you that this would be required? Without it, I get the error below: From what I recall, the call to namespace-module-attach must use the correct absolute module path, but the require can be relative. I confirmed that that's how the last PLaneT version of schemeunit that included the tool (version (2 12)) did it. 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. Ryan _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
