[Haskell-cafe] here's my solution for scripting/interpreter approach

[Dennis Raddle]

On Sun, Feb 12, 2017 at 2:11 PM, <amindfv at gmail.com> wrote:

> Hi Dennis -- responses inline:
>
> > El 11 feb 2017, a las 23:06, Dennis Raddle <dennis.raddle at gmail.com>
> escribió:
> >
> > My application needed the flexibility of writing test code and running
> it, or configuring its job (playback of music) through Haskell code and
> immediately testing the result (i.e. making sound and listening). I thought
> I would use GHCI, but I ran into some trouble. For one thing, my program
> forks a thread to do the timed control of the music, while the main thread
> implements a REPL-like "control loop" -- i.e. let me enter commands to
> influence the playback or halt it. I think this was crashing GHCI, perhaps
> when an interpreted script forks a thread which is still alive when control
> returns to the GHCI prompt. Not sure.
> >
>
> Would you mind sharing your code? GHCi should certainly not be crashing
> just because there was a forked background thread. I have done lots of the
> interaction you're describing (for music, also) and never had a problem
> like that.
>
>
Thanks for your comments. I am not very organized.. I'm using git, but I
didn't tag or branch on my GHCi experiments so it will be hard to
reconstruct what I did. Note that I'm using Sound.PortMidi in the forked
thread, so maybe that's the issue. Also I thought about the possibility of
compiling with -dynamic when I was trying to get interpreted code working
with compiled code, but I never tried it and don't need to now.

D




>
> > Anyway here's what I did. Now the process that does real-time control of
> the playback is an entirely separate process. The control loop is started
> by me first, and depending on the command I enter, it builds the playback
> program with "ghc --make" and then spawns it. I send it signals from the
> control loop.
> >
> > This turns out to be great. I can make changes anywhere in my playback
> application, from the deepest utility library to the top-level
> configuration script, and it builds as needed before running.
> >
> > And, in the case it doesn't need to build anything, "ghc --make"
> finishes quickly so it doesn't feel inefficient to invoke it after every
> command I enter in the control loop.
> >
>
> This seems like a great solution, the only downside being that you can't
> directly share memory between the processes. If you'd like to do that, I
> recommend (careful use of!) the "foreign-store" library, which allows you
> to regain references you stored before a ":r" in ghci.
>
> Tom
>
>
> > D
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170212/9d989d0b/attachment.html>