At Mon, 12 Feb 2018 16:38:32 +0300, Dmitry Pavlov wrote:
> > I'm not clear on why you're using `require-input-port` here instead of
> > `dyanmic-require` with <myprogram>'s path.
> Originally, I needed it to prepend "#lang <mylang>" to the source because I 
> did not have it in the file.
> That requirement is not so strict now and I will be able to lift it if it is 
> critical for performance.
> [...]
> >   Does the port `p` contain
> > the source text for <myprogram>, or does it contain the bytecode from
> > the ".zo" file created by `raco make <myprogram>?
> In this dedicated test, just the source text of <myprogram> and nothing else.

I think this is the main cause of the performance difference, but just
to make sure, does

  raco make <myprogram>; rm <myprogram.zo>; time racket <myprogram>

take ~4 seconds, where <myprogram.zo> is in a "compiled" dierctory
relative to <myprogram>?

If so, then the solution could be to use `require-input-port` on a port
that has bytecode for <myprogram>, instead of the program source.

> I just tried to check what I get with (dynamic-require <myprogram> #f) 
> instead 
> of require-input-port.
> In turns out that I get a "hash-ref: no value found for key" error 
> originating 
> from <mylang> implementation.
> It indicates that something went not as is was supposed to go in the 
> dependent 
> modules loading.
> There is a certain module (I will call it "functions") that, when loaded, 
> fills up the hash table in another module ("functions-table"), and this hash 
> table is being used by the language implementation. Of course, the language 
> implementation does (require) "functions-table" and then "functions".
> Something went wrong with that scheme when I used the (dynamic-require 
> <myprogram> #f) approach.
> It never went that way when I used (require-input-port) or "racket 
> <myprogram>".

I'm stumped here.

I can imagine a problem where the "language implementation" is in the
reader, in which case it wouldn't get run when loading from bytecode,
but that doesn't explain why `racket <myprogram>` works --- unless the
initialization is also triggered by a `main` or `configure-runtime`
submodule, which would be run by `racket <myprogram>`.

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 
For more options, visit

Reply via email to