On 10/19/2011 10:31 AM, John Clements wrote:
On Oct 19, 2011, at 9:29 AM, John Clements wrote:
On Oct 19, 2011, at 4:03 AM, Robby Findler wrote:
(I'm sorry if you got this message already; I thought I sent it
already but I don't see it.)
What about the current-output/error-port? what about the
current-namespace? current-custodian?
There are lots of parameters that affect core functions in subtle ways
and if you do something like this in plot, it seems like it could lead
to serious confusion someday. Also, it can introduce leaks.
+1. I think this is not not not a good idea.
Robby's solution requires you to make one list of all of the plot-related parameters,
which looks to me like the "right" amount of work.
Furthermore, it has the unpleasant characteristic that when it breaks, it will
be exposed in an unwanted change to a parameter that will likely be entirely
unrelated to plot. Tracking this down will be horrible, and the axe-wielding
murderer of legend will be very unhappy when he (or she?) finally gets to your
doorstep.
Dangling pronoun. Of course, I meant to say
"Furthermore, [your solution] has the unpleasant characteristic..."
Look, as long as it's not Richard Stallman with the ax...
If I spawn a render thread that inherits the parent thread's parameters,
won't things like current-namespace and current-custodian have the right
values?
It's starting to look like that is the solution that is the most
maintainable and the least work. And it still allows users to
parameterize the functions they plot. If something breaks, it's not my
fault, because spawning a thread that waits on a channel for a "draw
now!" command, and then draws on a dc, should just work, right?
(There shouldn't be any contention over the dc because I'd have the
slideshow thread wait on an "all finished" reply over the channel.)
Neil T
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
