Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path to dynamic-place misbehaves when in executable #2278

Closed
pmatos opened this issue Sep 20, 2018 · 3 comments
Closed

Path to dynamic-place misbehaves when in executable #2278

pmatos opened this issue Sep 20, 2018 · 3 comments

Comments

@pmatos
Copy link
Collaborator

pmatos commented Sep 20, 2018

Initially I discussed with @mflatt the issue of passing a modpath created with define-runtime-module-path-index to dynamic-place. @mflatt suggested using collapse-module-path-index before passing it to dynamic-place, which work unless you are in compiled code.

For example:
main.rkt:

#lang racket

(require racket/runtime-path
         syntax/modcollapse)

(define-runtime-module-path-index mod-for-place '(file "place-print.rkt"))

(void 
  (dynamic-place
   (collapse-module-path-index mod-for-place)
   'print))

(printf "Place created.~n")

place-print.rkt:

#lang racket

(provide print)

(define (print ch)
  (printf "Hello from another place~n"))

It works in the command line:

$ racket main.rkt
Place created.

But when it comes to running in a compiled environment:

$  raco exe -o pl-print.exe main.rkt
$  ./pl-print.exe 
dynamic-place: not a filesystem or predefined module-path
  module path: ''#%embedded:g3861:place-print
  context...:
   /home/pmatos/installs/racket-7.0/collects/racket/place.rkt:120:0: start-place*
   /home/pmatos/installs/racket-7.0/collects/racket/place.rkt:93:0: dynamic-place7
   '#%mzc:main: [running body]
   for-loop
   run-module-instance!125
   perform-require!78
   top-level: [running body]
   loop
   [repeats 1 more time]

If this is a really tricky one, is there a workaround I can use in the meantime?

@pmatos
Copy link
Collaborator Author

pmatos commented Sep 22, 2018

@mflatt I have a feeling you have been in a path related to this issue before resulting in commit 3bffcae given the commit title.

@mflatt
Copy link
Member

mflatt commented Sep 23, 2018

Thanks! It looks like I had done most of the work to wire things up in v7.0, but I forgot to get rid of a stub is_predefined_module_path and call scheme_is_predefined_module_path. That latter function is almost (but not quite) ready to work.

@mflatt mflatt closed this as completed in 45af149 Sep 23, 2018
@pmatos
Copy link
Collaborator Author

pmatos commented Sep 24, 2018

Thanks for the fix. It works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants