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>?

Yes, it does! So the issue is just that <myprogram> itself takes ~3 seconds
to compile. Having other sources consumed even more time to compile,
I did not figure that. Thank you.

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 that, and... got the hash table error that is the same as with
(dynamic-require <myprogram> #f).

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

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 are right, it is in the configure-runtime. Here is the source of
my slon/lang/configure-runtime.rkt file. It has not changed since 2011
when I wrote it. It probably reflects my incompetence in implementing
languages, but anyway:

#lang racket/base

(require slon/slon-parser)
(provide configure)

(define (configure data)
  (current-read-interaction even-read))

;; Taken from Datalog source, which says "This is almost certainly wrong."
;; So we are going to be wrong too.
(define (even-read source-name input-port)
    (slon-read-syntax source-name input-port)
    (current-read-interaction odd-read)))

(define (odd-read src ip)
  (current-read-interaction even-read)

slon/slon-parser.rkt requires slon/slon-compiler.rkt, which, in turn,
requires those "functions" and "functions-table" modules that make
the error happen.

So, how bad is this all, really? :)

Oh, I see that the upstream Racklog source [1] has changed and no
longer uses the odd-read/even-read hack. I will borrow the
implementation from there, again, effectively removing the parser
dependency in configure-runtime,and see how it goes.

Best regards,



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