Thanks for the example! I did not guess correctly about your mixture of
embedded modules and `dynamic-require`.
The short answer is that you should either embed modules or reference
them through an external paths like "/Applications/Racket
v7.7/collects", but not both. Otherwise, the two worlds collide in
confusing ways, in this case along the lines Sam suggested.
Longer answer: When you embed a module, it pulls along a copy of
anything that module depends on. Your "test.rkt" pulls along
`racket/base`, which pulls along `racket/private/promise`, which
defines `force` and the promise datatype. But it doesn't
`racket/promise`, which defines `delay/sync`, and that leads to a
mismatch.
Very long answer: When `server` starts, there are two possible
`racket/private/promise`s available: the emebded copy and the one in
"/Applications/Racket v7.7/collects". As an artifact of the way that
`racket/promise` references `racket/private/promise`, the
`racket/promise` in "/Applications/Racket v7.7/collects" will always
refer to the `racket/private/promise` there. And so `delay/sync` as
used in `setup/private/dirs` will refer to the promise datatype there.
But the `force` used in `setup/private/dirs` goes through `racket/base`
and ends up referring the the embedded `racket/private/promise`, which
has its own promise datatype; since `force` doesn't recognize the
result of `delay/sync` as a promise, it doesn't force the (othe rkind
of) promise, and it instead just returns it. Finally, `planet/config`
is unhappy to get back a promise, because it expects a path.
If you expect a full "collects" directory and more to be around at run
time, then there's no reason to embed code, and just use
racket_dynamic_require(Sstring("test.rkt"), Sfalse);
to load the module. But if you want to embed everything, then avoid
`dynamic-require` or use `++lib` or `define-module-path-index` to carry
along the dynamically required modules.
Matthew
At Mon, 13 Jul 2020 15:20:18 -0500, Nate Griswold wrote:
> I put up a repo with the bug at https://github.com/nwg/racket-expo
>
> The stack trace is this:
>
> build-path: contract violation
> expected: (or/c path-string? path-for-some-system? 'up 'same)
> given: #<promise:config:installation-name>
> context...:
> do-raise-argument-error
> loop
> build
> proc
> call-in-empty-metacontinuation-frame
> call-with-module-prompt
> body of "/Applications/Racket v7.7/collects/planet/config.rkt"
> temp35_0
> for-loop
> run-module-instance!
> for-loop
> [repeats 1 more time]
> run-module-instance!
> for-loop
> [repeats 1 more time]
> run-module-instance!
>
> Nate
>
>
> On Mon, Jul 13, 2020 at 1:03 PM Ryan Culpepper <[email protected]>
> wrote:
>
> > I don't know if it helps, but config:installation-name is a promise
> > defined by setup/private/dirs.
> >
> > Ryan
> >
> >
> > On Mon, Jul 13, 2020 at 7:23 PM Matthew Flatt <[email protected]> wrote:
> >
> >> I'm not sure how it could be in `dynamic-require` itself, as opposed to
> >> a library that is loaded by `dynamic-require`, but it sounds like a bug
> >> at some level. Can you provide a small example?
> >>
> >> At Mon, 13 Jul 2020 11:03:41 -0500, Nate Griswold wrote:
> >> > Sam, thanks
> >> >
> >> > To be clear, this crash happened DURING a dynamic-require and judging by
> >> > the stack trace looked to be part of the dynamic-require machinery (and
> >> > this seems to depend on the installation name).
> >> >
> >> > I actually wasn't depending on anything but racket/base, so i don't
> >> believe
> >> > anything i was using was causing a separate dependency on promise.
> >> >
> >> > Nate
> >> >
> >> >
> >> > On Mon, Jul 13, 2020 at 9:32 AM Sam Tobin-Hochstadt <
> >> [email protected]>
> >> > wrote:
> >> >
> >> > > My guess, not having looked further than your email, is that when you
> >> > > don't include racket/promise, something is supplying a promise to
> >> something
> >> > > else but there are two different instantiations of the promise
> >> library,
> >> > > causing the force call from one not to recognize the promise from the
> >> > > other. Then force just becomes the identity function, and passes
> >> through a
> >> > > promise to somewhere that isn't expecting one.
> >> > >
> >> > > Is it possible that some library you're using features promises?
> >> > > Alternatively, it might be that the embedding code needs an explicit
> >> > > dependency on promises.
> >> > >
> >> > > Sam
> >> > >
> >> > > On Mon, Jul 13, 2020, 10:18 AM Nate Griswold <[email protected]>
> >> > > wrote:
> >> > >
> >> > >> Hello.
> >> > >>
> >> > >> I noticed something and was wondering what the list thinks:
> >> > >>
> >> > >> I am using an embedded racket Ics) and i noticed that if i embed a
> >> file
> >> > >> and don't include any libraries (for a very bare bones c file) i have
> >> > >> problems with a crash on a promise on any dynamic-require:
> >> > >>
> >> > >> build-path: contract violation
> >> > >> expected: (or/c path-string? path-for-some-system? 'up 'same)
> >> > >> given: #<promise:config:installation-name>
> >> > >>
> >> > >> but if i do a (require racket/promise) in my rkt argument to
> >> --c-mods OR
> >> > >> if i do a ++lib racket/promise i get no crash.
> >> > >>
> >> > >> So is this expected behavior? Should racket/promise always be
> >> included or
> >> > >> no? And what exactly is going on under the hood here?
> >> > >>
> >> > >> Nate
> >> > >>
> >> > >> --
> >> > >> 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 [email protected].
> >> > >> To view this discussion on the web visit
> >> > >>
> >> >
> >>
> https://groups.google.com/d/msgid/racket-users/CAM-xLPpg_0Ef8ByjS01Y1pKEeeFMVkF
> >> > k3dvGcdpRaYo3ZqDb9A%40mail.gmail.com
> >> > >>
> >> > <
> >>
> https://groups.google.com/d/msgid/racket-users/CAM-xLPpg_0Ef8ByjS01Y1pKEeeFMVk
> >> > Fk3dvGcdpRaYo3ZqDb9A%
> >> 40mail.gmail.com?utm_medium=email&utm_source=footer>
> >> > >> .
> >> > >>
> >> > >
> >> >
> >> > --
> >> > 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 [email protected].
> >> > To view this discussion on the web visit
> >> >
> >>
> https://groups.google.com/d/msgid/racket-users/CAM-xLPpaOSxvPEDYzmkAXdFg%2BLTMA
> >> > H1mw57kJt7%3DCe6ipXmXDw%40mail.gmail.com.
> >>
> >> --
> >> 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 [email protected].
> >> To view this discussion on the web visit
> >>
> https://groups.google.com/d/msgid/racket-users/20200713112340.24e%40sirmail.smt
> p.cs.utah.edu
> >> .
> >>
> >
>
> --
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/CAM-xLPoKbgtUGTFoRSvK0D2M%2BX_EE
> 38z0bwuW-p3MptyWHkCnw%40mail.gmail.com.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/20200713193245.24%40sirmail.smtp.cs.utah.edu.
