Thank you so much, that solved the issue with requiring local collections.
I'll mark as complete since I kinda went off-topic near the end anyway.
Thanks again.

On Wednesday, May 9, 2018 at 4:12:40 PM UTC+1, Ondřej Majerech wrote:
>
> Hi,
>
> after calling scheme_set_collects_path, you also need to call 
> scheme_init_collection_paths 
> <https://docs.racket-lang.org/inside/embedding.html?q=scheme_init_collection_paths#%28cpp._scheme_init_collection_paths%29>(env,
>  
> scheme_null) to initialise the current-library-collection-paths parameter.
>
> On Tuesday, 8 May 2018 20:07:07 UTC+2, Colin James wrote:
>>
>> 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.

Reply via email to