Thanks! Moving the gui code separate from the tool has made development a lot more pleasant.
On Fri, Oct 10, 2014 at 7:40 AM, Robby Findler <ro...@eecs.northwestern.edu> wrote: > There should be no way to cross between a program running inside > DrRacket and the implementation of DrRacket (there are known bugs that > make it possible to cross, but they aren't going to lead to a pleasant > REPL experience). > > You can ask DrRacket to make a simpler REPL for you via the PLTDRREPL > environment variable. > > As far as units go, you need to be able to satisfy the imports to be > able to get at the insides of the unit. And for the unit you have in > particular, you would need to essentially provide the entire > implementation of DrRacket to satisfy the imports. > > But, some of your functions may no depend on DrRacket proper, but only > on, say, GUI controls or other things like that. In that case, you can > move them outside of the unit and test and run them and just have > small amounts of code that calls into those functions from inside the > unit. I find that to be a useful mode of development for some things I > add to DrRacket. > > hth, > Robby > > > On Thu, Oct 9, 2014 at 9:51 PM, Adam C.M. Solove <asol...@gmail.com> > wrote: > > Thank you for the clarification. > > > > Before I abandon myself to working this way, let me try another > possibility. > > I'd like to interactively try out the functions I'm writing, but I run > into > > two conceptual blocks that expose some of my ignorance on Racket. First, > as > > the functions are wrapped in a unit which has some imports, I can't seem > to > > "get at" those functions from the repl, though I have a reference to the > > unit itself. Second, I assume that even if I could get to the functions > in > > the repl, they would be running within the user program space rather than > > the DrRacket UI space. Is there any way to cross that bridge? > > > > On Thu, Oct 9, 2014 at 10:30 PM, Robby Findler < > ro...@eecs.northwestern.edu> > > wrote: > >> > >> Unfortunately, there is not. Depending on what your plugin does, it > >> isn't clear that it is really possible. In particular, if you're > >> mixing something new into the DrRacket frame then it is hard to know > >> what to do with all of the old frames now they should have a new > >> class. > >> > >> I agree it can be tedious, tho, and there could be a better design of > >> an extension API that would make that kind of thing easier (and also > >> make it easier to dynamically stop and start plugins) but we're not > >> there yet. > >> > >> Robby > >> > >> > >> On Thu, Oct 9, 2014 at 8:09 PM, Adam C.M. Solove <asol...@gmail.com> > >> wrote: > >> > Hello all, > >> > > >> > I'm new to the Racket ecosystem and poking around with the plugin > system > >> > to > >> > see how hard it would be to build a minikanren debugger tool in > >> > DrRacket. > >> > But first, a much more basic question: > >> > > >> > Is there a good way to interactively write and test DrRacket plugins? > >> > > >> > I'm currently going through the plugin docs by making a small change, > >> > quitting and restarting DrRacket, seeing that it doesn't quite work, > >> > making > >> > another small change, etc. It's a bit frustrating. Is there a way to > >> > simply > >> > reload the plugin I'm working on while leaving my DrRacket session > >> > alive? > >> > > >> > Thanks, > >> > > >> > Adam > >> > > >> > ____________________ > >> > Racket Users list: > >> > http://lists.racket-lang.org/users > >> > > > > > >
____________________ Racket Users list: http://lists.racket-lang.org/users
