May I ask why you need to have the C++ code embed Racket instead of the other way around (ie using the FFI)? Generally speaking, DrRacket (and other Racket tools) are going to work better if they get to "drive", I expect. (Put another way, I think Philip is giving you good advice here, fwiw.)
Robby On Wed, Jun 26, 2019 at 11:05 AM Thomas Dickerson <thomas_dicker...@alumni.brown.edu> wrote: > > Hi, > > Chiming in here, because Kshitij is working on this project for me. > It sounds like Philip has answered (3) and most of (2). > > On Tuesday, June 25, 2019 at 10:06:07 PM UTC-4, Philip McGrath wrote: >> >> The functionality you describe—in particular, setting up clean evaluation >> contexts—sounds a lot like what the "Run" button already does. Unless you >> have some other notion of "running" in mind for programs in your DSL, I >> think what you describe could be accomplished nicely with a "main" >> submodule, which (as you may know) is run only when its enclosing module is >> invoked as a main program, not when it is required as a library. One benefit >> is that this would make this functionality independent of DrRacket. > > > A couple additional bits of context: > > The DSL he is working on is embedded in a C++ application and strongly typed, > so we have several different notions of "running", which are orthogonal to > DrRacket's run button: > > The language is a language for describing parametric 3D models, not for > rendering, and the final result of being evaluated by Racket is a module > containing a provided result value, which is a pointer to a C++ object which > represents some a low level program evaluated by our C++ runtime to produce a > triangle mesh. > Our C++ applications obtain the result value from a DSL program by calling > scheme_dynamic_require in the inner loop of a Racket interpreter we've > stuffed into a coroutine. > When the toolbar button is pushed in DrRacket we want to evaluate the program > in a fresh namespace, (dynamic-require ''module-name 'result), and then pass > that result value into a C++ FFI function that will handle the C++ side of > evaluation and doing the actual OpenGL calls to visualize it in the editor. > This should have similar behavior to the run button from an evaluation > standpoint, but after evaluating the program, enter a render loop until, e.g. > the button is pushed again to stop rendering. Here, the DrRacket plugin is > responsible for creating the OpenGL context, which could be in a separate > window, but as Kshitij said it would be ideal if we could figure out how to > add a pane below the REPL. > > >> >> >> To illustrate what I mean, your source program: >> #lang hypothetical-lanugage >> (hypothetical-code) >> would be transformed by the reader into: >> (module example hypothetical-lanugage >> (#%module-begin >> (hypothetical-code))) >> Then, your `#%module-begin` macro might expand to something like: >> (module example hypothetical-lanugage >> (#%plain-module-begin >> (provide shape) >> (define shape (hypothetical-code)) >> (module* main racket/base >> (require (submod "..") >> hypothetical-lanugage/private/render) >> (render shape)))) >> >> What I'm most unsure of about your question is that you say you want to use >> a "C++ library that contains a function that takes in a module object as >> input." Do you mean that you want to use the Racket C API to create a new >> primitive module or something? That is not a very common thing to do. Racket >> modules are not first-class values. While you can produce a value >> representing the compiled form of a module (`compiled-module-expression?`) >> by doing something like: >> (compile '(module foo racket/base)) >> that is rarely what you want to do. In particular, the result of calling >> `eval` is not a module (unless of course you do something like `(eval >> '(compile '(module foo racket/base)) (make-base-namespace))`. >> >> Calling `eval` on a module form, compiled or otherwise, merely declares the >> module: it doesn't immediately do anything. For example, this expression: >> (let ([ns (make-base-namespace)]) >> (eval '(module effects racket/base >> (println "running")) >> ns) >> (println "module evaluated") >> (eval '(require 'effects) ns)) >> prints: >> "module evaluated" >> "running" >> because the module isn't run until the `require` form is evaluated. Also, >> `eval` handles expanding the program already: manual expansion is only >> needed if you want to do some kind of static analysis. > > > What is the "correct" way to get the current program source code from the > DrRacket editor to pass into eval? > drracket:eval:expand-program seemed closest, given the type of the first > argument, but the plugin documentation is not clear and we don't actually > know how to get the relevant input port or text-pos. > > > > > On Wednesday, June 26, 2019 at 12:06:36 AM UTC-4, Jack Firth wrote: >> >> This sounds very similar to pict3d, particularly if you adopt the approach >> suggested by Phillip of using a main submodule to render things instead of a >> drracket plugin. Is pict3d close to what you're trying to do? Not saying you >> should use pict3d or do things a similar way—I'm just curious about your use >> case. > > > pict3d looks quite interesting, but isn't quite what we want - see the > earlier use case discussion in my reply to Philip. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/279abcad-9dc7-4224-b6de-ef6fd0209a83%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAL3TdOMoBg8k_ec2hQarMvUcfQ9e2k3-Ln2nJJNhoREd4dFyAQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
