Sorry for letting this thread lapse. Wrt to your third option mentioned below, would it work to make that option accessible via the FFI? If so, then maybe you could make the "essentially phase shifted everything" into "actually phase shifted everything" and then when you get the result program have your #%module-begin call into the FFI to actually run the program. Does that seem like a viable option?
Robby On Mon, Jul 1, 2019 at 3:35 PM Thomas Dickerson <thomas_dicker...@alumni.brown.edu> wrote: > > On Mon, Jul 1, 2019 at 2:23 PM Philip McGrath <phi...@philipmcgrath.com> > wrote: >> >> >> I believe the main submodule will still be compiled the enclosing module is >> loaded from source, but that should be trivial: it really only needs a >> `require` and a function call. If the file has already been compiled to >> bytecode, the bytecode for the main submodule won't be loaded, nor for any >> of its transitive dependencies. >> >> Depending on how you are distributing your code, you may or may not want to >> add an indirection via `dynamic-require` to prevent the distribution >> building tools from shipping graphics libraries that you only need for the >> main submodule. (Basically this would be the reverse of what >> `racket/runtime-path` does.) I haven't done much with the tools for >> distributing built artifacts beyond toy experiments, but I think some of >> them may be able to do that stripping automatically or with e.g. a >> command-line flag, without needing a `dynamic-require`. At the maximum, you >> could put the graphics modules in their own package, analogous to the >> `foo`+`foo-lib`+`foo-doc`+`foo-test` convention: in that case, the support >> library for your main submodule (what I called >> `hypothetical-lanugage/private/render`) would just be a stub to >> `dynamic-require` the `render` function or do something useful if the >> graphics package isn't installed, like print a message to standard error. > > > I'll chew on this, but if the dependencies for the main submodule need to be > available at the time that it is compiled, then the easiest thing may just be > doing a dynamic-require. > >> >> I haven't used OpenGL, from Racket or otherwise, but it might be possible >> to use a bitmap from `make-gl-bitmap` as a buffer for your OpenGL drawing >> and copy it to the canvas via `draw-bitmap`. If you have an existing foreign >> library that does the actual drawing, you can get a platform-specific >> pointer via `gl-context<%>`. > > > That's an interesting possibility, and I shouldn't actually need the > gl-context pointer, just to make it current before calling the foreign > rendering code. > >> >> I suspect, though, that a solution would involve your support library >> cooperating with an extension set up by your #lang. > > Right, this is what we originally hand in mind. > >> >> On the whole, though, either returning a snip or creating a new `frame%` >> would probably be easier. Using a new `frame%` would also be entirely >> independent of DrRacket: I expect it would work with racket-mode for Emacs, >> for example. > > frame% is portable, but also not a very nice UI. I'll see what can be done > with a snip. > > On Mon, Jul 1, 2019 at 2:56 PM Robby Findler <ro...@cs.northwestern.edu> > wrote: >> >> I think I'm missing a bit more context so I'll continue this line of >> questions. The path that you seem to be heading down seems to be one >> where you'll duplicate a lot of work that's already gone into >> DrRacket, and it seems unlikely to me that it is the most productive > > > Perhaps you could elaborate on the mechanisms you think we would be > duplicating, because those may provide either the entry points we're looking > for, or clarify a potential miscommunication on our end. > >> >> Can you say a little more about what you want to do with DrRacket? > > > Currently, most of our DSL programs are constructed automatically from > inferred geometry, and it's fine, because an artist/programmer doesn't need > to do any design work. > Going forward, we would like to also be able to model reusable parametric > object classes that we can plug in to our scenes, and here it would be very > helpful to be able to visualize the geometry generated by our DSL programs > interactively. > Rather than reinventing the wheel, and writing our own editor, we would like > to bend DrRacket to our will for that purpose; however, the current "Run" > button doesn't seem like quite the right UI for that. > >> Do you expect to be able to run these programs? If so, does it >> make sense to run them when you aren't in the >> embedded-in-the-huge-C++-code-base mode? How about compilation of the >> programs (i.e. macro expansion)? > > > We've essentially phase shifted everything, so that Racket's Phase 0 is > really Phase 1 in a DSL library implemented with C++, which provides our > "core language", so the result of "running" the Racket program is a pointer > to an opaque C++ type which represents the fully expanded syntax for our > program, ready to be evaluated by the C++ geometry library. > Racket's Phase 1 handles type checking + inference of the surface language, > converting pretty surface syntax into a lot of horrific FFI code, and > providing a consistent API to the resulting modules to make it easy to grab > the C++ representation of the DSL program. > > We currently can then either just run this as a Racket program, which works, > but is basically useless, or further stuff the Racket interpreter into a C++ > library for reading, writing, and executing our DSL programs from elsewhere > in the C++ code base. We would like to have a third option which is "allow > DrRacket to invoke the final C++ evaluation step of the DSL, and then allow > for interactive rendering of the resulting geometry, in a friendly UI". > -- 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/CAL3TdOM3fcVn9171dHa%3DLHkGniLXpRiF97aiPGdaQ-kZv3ahiA%40mail.gmail.com.
