[racket-dev] separate plot library into gui-requiring and non-gui-requiring

From: Neil Toronto (neil.toronto at gmail.com)
Date: Wed Oct 9 12:08:33 EDT 2013

I'm splitting up the "plot" package today.

Stephen: You'll be able to install "plot-lib", then (require plot/pict) 
to get a `plot' function work-a-like that outputs picts instead of 
snips, or (require plot/bitmap) to get one that outputs bitmaps. You 
could easily make a "plot-no-gui-lib" package that contains only a 
"plot/main.rkt" that wraps one of those modules, if/when you make a 
web-only Racket distribution.

Anyone: Is it worth the extra complexity to make a "plot-typed-lib" and 
a "plot-typed-gui-lib"? Or should I put the typed interface in 
"plot-lib" and "plot-gui-lib"?

Also, what's a good name for the module that exports `plot-file', 
`plot-pict', `plot-bitmap', `plot/dc', and the 3d versions of those 
functions? Something like plot/no-gui?

Neil ⊥

On 10/08/2013 01:08 PM, Robby Findler wrote:
> I think it is worth having a plot/pict or pict/plot library that doesn't
> depend on racket/GUI/base (or maybe it would be better to disentangle
> snips). In any case, we have many others such libraries that turn on
> avoiding racket/gui/base for exactly this reason.
> Robby
> On Tuesday, October 8, 2013, Neil Toronto wrote:
>     On 10/08/2013 11:22 AM, Stephen Chang wrote:
>         Short question:
>         Is there a way to separate the gui-requiring parts of plot from the
>         non-gui-requiring parts?
>         Long question:
>         Many people have expressed pleasant surprise with the
>         plot-evaluating
>         ability of the racket pastebin Sam and I are working on.
>         Most of the effort is due to scribble's nice sandbox evaluation
>         capabilities but to get it fully working, I had to hack the plot
>         library in my racket install.
>         The problem is that plot uses racket/gui/base too eagerly but the
>         server has no display, resulting in a gtk initialization error. I
>         ultimately got around it by just commenting out all the gui parts of
>         plot, knowing that it would never get invoked, but obviously this is
>         an ugly solution.
>         I should say that I don't think plot is at fault. The plot library
>         does lazy-require racket/gui/base but that's not good enough because
>         the laziness has to propagate to other requires that also require
>         racket/gui/base (ie plot/snip) which isnt the case. But this cannot
>         work anyways because lazy-require only works with functions and some
>         of the things imported by plot/snip are classes.
>         I spent awhile trying to separate the gui-requiring parts of
>         plot but
>         was unsuccessful. Maybe the change has to be in racket/gui/base
>         itself
>         (related to PR 12465) I don't really know. I guess I'm just looking
>         for additional insight. Naively, slideshow/pict and 2htdp/draw
>         do not
>         have this problem so it seemed like it should be possible.
>     Right, racket/gui/base is necessary for snips. In all the
>     documentation that uses plots (plot, math, images) I've used the
>     following hack when setting up the evaluators:
>        (eval '(require (rename-in (except-in plot plot plot3d)
>                                   [plot-pict  plot]
>                                   [plot3d-pict  plot3d])))
>     You could also rename `plot-bitmap' and `plot3d-bitmap'. (The docs
>     use picts because they look better rendered in a PDF.) It wouldn't
>     be hard to make a module that does that and provides everything.
>     (Except possibly `plot-snip', `plot-frame', etc.)
>     I'm reluctant to single out one way of rendering when the GUI isn't
>     available. Picts look nicer when scaled, but bitmaps look nicer when
>     unscaled (plots are subpixel-rendered in this case). Picts take much
>     more time to redraw, but for bitmaps it's just a blit.
>     Neil ⊥
>     _________________________
>       Racket Developers list:
>     http://lists.racket-lang.org/__dev <http://lists.racket-lang.org/dev>

Posted on the dev mailing list.