Thanks for the responses. On Fri, Jun 28, 2019 at 5:50 PM Philip McGrath <phi...@philipmcgrath.com> wrote:
> If you're sure you want to get the raw program source and deal with it > manually, you can use the method `get-definitions-text > <https://docs.racket-lang.org/tools/drracket_unit.html#(meth._(((lib._drracket%2Ftool-lib..rkt)._drracket~3aunit~3aframe~3c~25~3e)._get-definitions-text))>` > on the DrRacket frame given as an argument to your button's callback > function. This will give you the editor object for the definitions window. > You can then use a method like `get-flattened-text > <https://docs.racket-lang.org/gui/editor___.html#(meth._(((lib._mred%2Fmain..rkt)._editor~3c~25~3e)._get-flattened-text))>` > to get the source as a sting or (probably better) the function ` > open-input-test-editor > <https://docs.racket-lang.org/gui/Editor_Functions.html#(def._((lib._mred%2Fmain..rkt)._open-input-text-editor))>` > to get an input port directly. > This is very helpful, thanks. > Again, this part works just fine. In particular, because of the way Racket's > submodules > <https://docs.racket-lang.org/reference/eval-model.html#%28part._submodules%29> > work, the code in the "main" submodule *does not* run when you > instantiate the parent module, whether via `scheme_dynamic_require`, > `dynamic-require`, `require`, or some other way: the compiled form of the > submodule need not even be loaded into memory. So you can use rendering > code in the main submodule without creating a dependency for your main > application. > Specifically, this means we can avoid byte-compiling and loading any graphics modules the main submodule depends on, yes? > It could certainly open a new GUI window, and it could also return a value > that renders as an embedded widget (snip) in the interactions pane. (See > the plot library for an example.) > Snips seem nice, but even browsing through the source for the 3d renderers for plot, I don't see any way to get an OpenGL context for a snip, since they appear to work on predefined DCs, rather than allowing you to construct a canvas. > I haven't looked at the DrRacket extension APIs enough to be sure whether > you could open a new pane in the DrRacket window, but it certainly seems > possible. > Are you aware of any projects that usefully manipulate the interactions pane that I could turn to for example code? It looks like it's possible to extend that class. On Sun, Jun 30, 2019 at 11:44 AM Robby Findler <ro...@cs.northwestern.edu> wrote: > May I ask why you need to have the C++ code embed Racket instead of > the other way around (ie using the FFI)? The short answer is this project is a very small part of a very large enterprise C++ code base, and it's not reasonable to rewrite every single program in our toolkit that needs to interact with our DSL to be a dynamic library with a Racket front-end. > Generally speaking, DrRacket (and other Racket tools) are going to work > better if they get to > "drive", I expect. Thankfully we're not trying to embed DrRacket - our applications are primarily command-line driven, so the editor enhancements are just for artist convenience. The rest of the time, Racket happily sits in its own stack <https://groups.google.com/d/msg/racket-users/yIZPLJJKUAI/gqdDCSSABwAJ>, and has no idea we've embedded in it (although since the time that was written, the Boost Coroutines library was deprecated, so we built our own <https://github.com/Geopipe/CxxBidirectionalCoroutines/>). -- 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/CA%2BHWosX%2BcPFjOTuKT6iWHoJh3M93fdOfYBijQedfkBkJszRxGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
