I think it would be nice if there were a new library, pulled out of the current slideshow/base that exported more pict-making functions and didn't depend on these various things.
I've looked into this before and I came to the conclusion that it didn't belong in pict because of the way it does font configuration (and the various parameters it uses), but I didn't try to keep something in the slideshow that avoided the racket/gui/base dependency. Robby On Tue, Apr 9, 2019 at 5:02 PM Stephen Foster <step...@thoughtstem.com> wrote: > > P.S. I guess it's mainly just the para, item, and subitem functions. The > rest of the text functions (e.g. (tt ...)) seem pretty straightforward to get > pict to do -- and in many cases the pict translation is specified in the docs. > > On Tue, Apr 9, 2019 at 2:57 PM Stephen Foster <step...@thoughtstem.com> wrote: >> >> Thanks, Matthew. That does help me understand what's going on a bit better. >> >> I do want to point out that, as far as I know, there are some pict functions >> that are only provided through slideshow. For example, the (para ...) >> function -- which was what I was using when I ran into the aforementioned >> error. This function is also provided by scribble/base. But doing (require >> scribble/base) does not fix the raco setup error. >> >> Is the best path forward to move such functions into pict? >> >> A lot of the functions on this page that return picts are really quite nice: >> https://docs.racket-lang.org/slideshow/Primary_Slide_Functions.html >> None of them seem to be provided by pict. >> >> >> >> >> >> On Tue, Apr 9, 2019 at 12:55 PM Matthew Flatt <mfl...@cs.utah.edu> wrote: >>> >>> At Tue, 9 Apr 2019 14:50:15 -0400, Matt Jadud wrote: >>> > On Tue, Apr 9, 2019 at 2:44 PM Stephen Foster <step...@thoughtstem.com> >>> > wrote: >>> > >>> > > >>> > > I've always assumed that any correct Racket code can be run during >>> > > setup's >>> > > documentation-building time. If this isn't true, how can I know which >>> > > Racket code can be used in this way and which can't? >>> > > >>> > > >>> > I just wanted to +1 this thread; as I've been working on documentation >>> > where I'd like to either 1) procedurally generate images as part of the >>> > docs, or 2) have parts of the library that generate graphical output, I >>> > run >>> > into import issues at setup time that cause the build to fail. >>> >>> The `pict` library should not have that problem. >>> >>> The `plot` library does that have problem, but `plot/no-gui` avoids it. >>> >>> > I've been considering moving to a two-phase documentation build process, >>> > where I have a Makefile to run Racket code to generate static images, and >>> > then drive Scribble to generate the documentation. This way, the >>> > documentation build process will succeed. In the end, that might be more >>> > portable/easier for distribution anyway... >>> >>> Are you running into problems where you really need GUI functionality >>> to create the image? Or it is just a library is bundled with GUI >>> functionality --- like `plot`, and maybe the `plot/no-gui` analog is >>> missing? Or is it more a question of keeping track of which libraries >>> imply a GUI and which do not? >>> >> >> >> -- >> >> >> Stephen Foster >> ThoughtSTEM Co-Founder >> 318-792-2035 > > > > -- > > > Stephen Foster > ThoughtSTEM Co-Founder > 318-792-2035 > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
