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.