Thank you very much :slightly_smiling_face: But, hey, that’s a lot of hoops we have to jump through for such a simple task. Would there be interest for ‘save-image’ and ‘save-svg-image’ functions for pict, à la 2htdp/image?

@leafac yeah that would be great

:+1: I opened this issue, then: https://github.com/racket/pict/issues/35

It looks like picts are convertible, and that the convertible protocol implementation for picts accepts ’svg-bytes as a target format. Would that suffice here?

Unfortunately, I can’t tell, because I don’t know what “convertibles” are. But even if they suffice, I think there’s still room for some helper functions, or, at the very least, for some improvements to the documentation.

see http://docs.racket-lang.org/file/convertible.html?q=file%2Fconvertible — essentially, (convert your-pict 'svg-bytes) should give you a bytestring containing a valid svg

(not all the conversion targets are supported by all convertible things, annoyingly, but it looks like picts do support svg-bytes)

(someone else more knowledgeable about this should chime in here; I know just enough about convert to know that it exists, but I haven’t played around with picts very much)

Yes, this seems to be in the direction I’m thinking about…

@mflatt: Quick distro-build question: is make site guaranteed to exit with a non–0 return code if any of the build clients failed?

@stamourv It looks like the non–0 status may only happen with completely sequential builds. That could be fixed for builds that include parallel parts.

Ok, thanks for confirming! I’ll try implementing the change.

That turned out to be pretty easy, actually. I’ll push the change.

Great - thanks

@mflatt how nondeterministic is the distro-build process?

There’s non-determinism in bytecode compilation (reduced over time, but not eliminated outside the main “collects”) and in C compilation (because C compilers tend to have some non-determinism, too, if you’re not at Google)

@blerner does that mean I can remove metapict from the equation and just do all this directly?

I don’t think metapict was part of the issue. It’s just a library you used to create the pict, no? So for example, #lang racket (require pict file/convertible) (define p (filled-rectangle 40 40)) (convert p 'svg-bytes)

if you want to make a metapict-based pict, that’s your prerogative, but it doesn’t seem to have to do anything with how to convert the underlying pict to a svg, unless I misunderstand your problem scenario

I’m just trying to peel back the onion and see how much code this really takes. metapict is providing a lot of drawing… I wasn’t sure what type of thing I was getting back therefore didn’t know whether I could do the convertable (I can—so much cleaner than that bottom blob I had!)… now I’m trying to peel back the drawing code from metapict

I guess I should also poke at 2htdp/image

I suspect (but am not an expert here) that metapict is a convenience library over the underlying pict datatype. It makes it easier to construct sophisticated picts, but that’s orthogonal to how to save them. Likewise, 2htdp/images are convertible, which is ultimately how I save them, by converting them to png-bytes :slightly_smiling_face:

thanks!

http://soegaard.github.io/docs/metapict/metapict.html#%28part._reference-pict%29 documentation: “All images in MetaPict are represented as picts. A pict is a structure that holds information on how to draw a picture. A pict can be rendered to produce an image in various formats such as png, pdf, and, svg.”