So, basically, I was wondering how one could go about requiring modules in
/usr/share/racket/collects from the embedded interpreter.
My current program links against a base.c file generated with raco ctool
base.c ++lib racket/base and simply runs REPL, it's essentially copied from
the Racket documentation that provides the same example:
int interpreter_run(Scheme_Env* env, int argc, char* argv[])
{
// set default collects path
scheme_set_collects_path(scheme_make_path("/usr/share/racket/collects"
));
// declare racket/base modules
declare_modules(env);
// require racket/base namespace
scheme_namespace_require(scheme_intern_symbol("racket/base"));
// require REPL symbols
Scheme_Object* symbols[2];
symbols[0] = scheme_intern_symbol("racket/base");
symbols[1] = scheme_intern_symbol("read-eval-print-loop");
// dynamically require function from racket/base
Scheme_Object* func = scheme_dynamic_require(2, symbols);
// invoke REPL
scheme_apply(func, 0, nullptr);
return EXIT_SUCCESS;
}
However, I have a few questions about this. Must all modules that one wants
to require be stated when doing the previous raco command (++lib)?
I'm not certain about the effect of doing *scheme_set_collects_path*
actually has in relation to how collections are required.
For example, from my REPL example:
> > $ ./racketeer
>
> > (find-system-path 'collects-dir)
> #<path:/usr/share/racket/collects>
>
Evidently it successfully sets the collection path.
However, the context trace of attempting to require anything else from the
REPL example seems to completely omit this.
Example:
> > $
> ./racketeer
> > (require racket/base)
> > (require racket/gui)
> stdin::32: collection not found
> for module path: racket/gui
> collection: "racket"
> *in collection directories:*
> context...:
> show-collection-err
> standard-module-name-resolver
> /usr/share/racket/collects/racket/private/misc.rkt:88:7
> > (find-system-path 'collects-dir)
> #<path:/usr/share/racket/collects>
>
It fails to require racket/gui and doesn't show any collection directories
at all. Is 'collects-dir completely separate from what the interpreter
actually uses to load modules from collections? If so, would I need to
register a proper collections directory prior to scheme_main_setup? From
what I can tell, it can only successfully (require racket/base) because it
was - for lack of accurate terminology - *compiled in* via raco's ++lib
option. Would that be a correct assumption to make?
My overall intention is to be able to do what racket's REPL can do from
command line, given a folder structure like this:
> > $ tree
> something
>
>
> something
> ├── compiled
> │ ├── main_rkt.dep
> │ ├── main_rkt.zo
> │ ├── other_rkt.dep
> │ └── other_rkt.zo
> ├── main.rkt
> └── other.rkt
>
Racket, from command line, ran from that the containing folder, can
(require something):
> $
> racket
> Welcome to Racket v6.12.
> > (require something)
> > (useless-func)
> Useless function
Yet, my REPL example can't do this but I suspect there's probably existent
scheme_* functions to do this (I seen one call something like
scheme_set_cmd and people pass argv[0] to it).
I just think it'd be useful to be able to dynamically require modules the
embedded interpreter but I can't seem to get it to work at all. I've
dabbled with things like dynamic-require and such, but due to my blatant
lack of understanding of how modules and collections are meant to work,
it's all just fell flat.
Any clarification on anything I've posted about would be much appreciated
as I'm currently going around in circles and manually purging files
generated by raco in a futile attempt to understand what's happening.
Out of interest, is it even possible to embed the Racket interpreter for
the purposes of interoperability? I've not seen anyone do it and the
documentation for scheme_* functions is sparing, to say the least. It seems
to me the only way to achieve interoperability would be to wrap C that
utilises native IPC to communicate with the intended application and then
load and execute the wrapper.
Sorry if my question is terribly unstructured or makes false assumptions or
assertions, I only started digging into Racket - and Lisp dialects overall
- recently.
As I say, any clarification on anything I've brought up would be much
appreciated.
Thanks.
--
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.
