Re: [racket-users] Path to file in dynamic-place

[Philip McGrath]

When the thing you want to refer to at runtime is specifically a module,
using define-runtime-module-path-index or
define-runtime-module-path (also from racket/runtime-path) may be even
better choice than define-runtime-path.

-Philip

On Tue, Jan 23, 2018 at 10:03 PM, Jack Firth  wrote:

> A rule of thumb you can follow to avoid tricky bugs like this: *never use
> string literals as dynamic module names.* Anywhere you see a dynamic /
> reflective function on modules called with a literal string, a
> contradiction exists between the programmer and the dynamic function:
>
> 1. The programmer intends to use a specific module referenced in the
> context of the program source code.
> 2. The dynamic function intends to operate on an arbitrary unknown module
> referenced in the context of the program execution environment.
>
> This is why define-runtime-path exists. It acts as a bridge between the
> two worlds of the module system used to compile a program source and the
> module system that compiled program interacts with at runtime. The two
> systems cannot be assumed identical because 1) a program may be compiled on
> one machine and executed on another and 2) modules only used at compilation
> time may be excluded from the compiled form of a program.
>
> The "place-worker.rkt" example in the places docs is somewhat misleading
> since it refers to the place-launching code as if it wasn't in a module
> (note that no file names are mentioned in the example other than
> "place-worker.rkt"). It would be clearer if it named the launcher code
> "place-launcher.rkt", clarified that "place-launcher.rkt" and
> "place-worker.rkt" must be in the same directory, and used
> (define-runtime-path worker-mod "place-worker.rkt") to refer to the worker
> module from the launcher module.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Path to file in dynamic-place

[Jack Firth]

A rule of thumb you can follow to avoid tricky bugs like this: *never use 
string literals as dynamic module names.* Anywhere you see a dynamic / 
reflective function on modules called with a literal string, a 
contradiction exists between the programmer and the dynamic function:

1. The programmer intends to use a specific module referenced in the 
context of the program source code.
2. The dynamic function intends to operate on an arbitrary unknown module 
referenced in the context of the program execution environment.

This is why define-runtime-path exists. It acts as a bridge between the two 
worlds of the module system used to compile a program source and the module 
system that compiled program interacts with at runtime. The two systems 
cannot be assumed identical because 1) a program may be compiled on one 
machine and executed on another and 2) modules only used at compilation 
time may be excluded from the compiled form of a program.

The "place-worker.rkt" example in the places docs is somewhat misleading 
since it refers to the place-launching code as if it wasn't in a module 
(note that no file names are mentioned in the example other than 
"place-worker.rkt"). It would be clearer if it named the launcher code 
"place-launcher.rkt", clarified that "place-launcher.rkt" and 
"place-worker.rkt" must be in the same directory, and used 
(define-runtime-path worker-mod "place-worker.rkt") to refer to the worker 
module from the launcher module.


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Path to file in dynamic-place

['Royall Spence' via Racket Users]

Bah, I spoke too soon. Setting the current-load-relative-directory has no 
effect on the file loading behavior of dynamic-place.

On Mon, Jan 22, 2018, at 12:02 PM, 'Royall Spence' via Racket Users wrote:
> Thanks, this makes more sense now. I'll just slap this at the type of my 
> place-creating modules for my own sanity:
> (current-load-relative-directory (current-directory))
> 
> On Mon, Jan 22, 2018, at 11:52 AM, Sam Tobin-Hochstadt wrote:
> > `dynamic-place` works like (I believe) `dynamic-require`, which starts
> > in `(current-load-relative-directory)`. If you want to use it in a
> > file and get consistent file-relative behavior, I suggest using
> > `define-runtime-path` or `quote-module-path`.
> > 
> > Sam
> > 
> > On Mon, Jan 22, 2018 at 11:48 AM, 'Royall Spence' via Racket Users
> >  wrote:
> > > In the docs for places 
> > > (https://docs.racket-lang.org/reference/places.html),
> > > the example shows creating a place like so:
> > > (dynamic-place "place-worker.rkt" 'place-main)
> > >
> > > When I do this on LInux (haven't tried other systems yet), the search path
> > > starts at my home directory and fails to find the file. It's not a huge
> > > problem since I can invoke it with the full path:
> > > (dynamic-place (build-path (current-directory) "place-worker.rkt")
> > > 'place-main)
> > >
> > > but this does seem like either an error in the docs or in the behavior of
> > > the dynamic-place procedure. At first I was thinking our other 
> > > `path-spec?`
> > > procedures start with the current module's directory, but then I noticed 
> > > it
> > > actually uses a `module-spec?`. The only other time I really use that,
> > > though, is for `require`, which certainly does start in the current 
> > > module's
> > > directory.
> > >
> > > Should I submit a change in the docs? In the procedure? Am I barking up 
> > > the
> > > wrong tree?
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "Racket Users" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an
> > > email to racket-users+unsubscr...@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Path to file in dynamic-place

['Royall Spence' via Racket Users]

Thanks, this makes more sense now. I'll just slap this at the type of my 
place-creating modules for my own sanity:
(current-load-relative-directory (current-directory))

On Mon, Jan 22, 2018, at 11:52 AM, Sam Tobin-Hochstadt wrote:
> `dynamic-place` works like (I believe) `dynamic-require`, which starts
> in `(current-load-relative-directory)`. If you want to use it in a
> file and get consistent file-relative behavior, I suggest using
> `define-runtime-path` or `quote-module-path`.
> 
> Sam
> 
> On Mon, Jan 22, 2018 at 11:48 AM, 'Royall Spence' via Racket Users
>  wrote:
> > In the docs for places (https://docs.racket-lang.org/reference/places.html),
> > the example shows creating a place like so:
> > (dynamic-place "place-worker.rkt" 'place-main)
> >
> > When I do this on LInux (haven't tried other systems yet), the search path
> > starts at my home directory and fails to find the file. It's not a huge
> > problem since I can invoke it with the full path:
> > (dynamic-place (build-path (current-directory) "place-worker.rkt")
> > 'place-main)
> >
> > but this does seem like either an error in the docs or in the behavior of
> > the dynamic-place procedure. At first I was thinking our other `path-spec?`
> > procedures start with the current module's directory, but then I noticed it
> > actually uses a `module-spec?`. The only other time I really use that,
> > though, is for `require`, which certainly does start in the current module's
> > directory.
> >
> > Should I submit a change in the docs? In the procedure? Am I barking up the
> > wrong tree?
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Path to file in dynamic-place

[Sam Tobin-Hochstadt]

`dynamic-place` works like (I believe) `dynamic-require`, which starts
in `(current-load-relative-directory)`. If you want to use it in a
file and get consistent file-relative behavior, I suggest using
`define-runtime-path` or `quote-module-path`.

Sam

On Mon, Jan 22, 2018 at 11:48 AM, 'Royall Spence' via Racket Users
 wrote:
> In the docs for places (https://docs.racket-lang.org/reference/places.html),
> the example shows creating a place like so:
> (dynamic-place "place-worker.rkt" 'place-main)
>
> When I do this on LInux (haven't tried other systems yet), the search path
> starts at my home directory and fails to find the file. It's not a huge
> problem since I can invoke it with the full path:
> (dynamic-place (build-path (current-directory) "place-worker.rkt")
> 'place-main)
>
> but this does seem like either an error in the docs or in the behavior of
> the dynamic-place procedure. At first I was thinking our other `path-spec?`
> procedures start with the current module's directory, but then I noticed it
> actually uses a `module-spec?`. The only other time I really use that,
> though, is for `require`, which certainly does start in the current module's
> directory.
>
> Should I submit a change in the docs? In the procedure? Am I barking up the
> wrong tree?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Path to file in dynamic-place

['Royall Spence' via Racket Users]

In the docs for places 
(https://docs.racket-lang.org/reference/places.html), the example shows 
creating a place like so:
(dynamic-place 

 "place-worker.rkt" 'place-main)

When I do this on LInux (haven't tried other systems yet), the search path 
starts at my home directory and fails to find the file. It's not a huge 
problem since I can invoke it with the full path:
(dynamic-place (build-path (current-directory) "place-worker.rkt") 
'place-main)

but this does seem like either an error in the docs or in the behavior of 
the dynamic-place procedure. At first I was thinking our other `path-spec?` 
procedures start with the current module's directory, but then I noticed it 
actually uses a `module-spec?`. The only other time I really use that, 
though, is for `require`, which certainly does start in the current 
module's directory.

Should I submit a change in the docs? In the procedure? Am I barking up the 
wrong tree?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.