Great, thanks for all of that digging. Ya, i think i will go the
non-declare_modules, non-ctool route for now as i think this fits my
use-case pretty well. I want to allow access to the full racket library for
racket code that changes often.
Nate
On Mon, Jul 13, 2020 at 8:32 PM Matthew Flatt wrote:
> 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: #
> > 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
> > 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
> 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 <
> > >> sa...@cs.indiana.edu>
> > >> > 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,
