On Sat, Jan 31, 2009 at 6:45 PM, Brent Yorgey wrote:

On Sat, Jan 31, 2009 at 06:23:29PM -0500, Braden Shepherdson wrote:

...

Brent Yorgey wrote:

...

I am very pleased to announce the 0.2 release of the diagrams package,

Would this make a handy plugin for gitit? I'm currently putting diagrams together in xfig and saving them to my gitit tree while taking notes in gitit, but being able to write diagrams code into gitit would be great.

How easy or hard would this be to accomplish?

Well, the short answer is: I think diagrams would be very well-suited to this, and the difficulty probably depends more on gitit than diagrams. Perhaps someone who knows more about gitit can speak to this as well.

/me looks around. oh.

In theory, it should be easy to write a plugin which takes some Haskell code defining a top-level binding 'dia' (or something similar) of type Diagram, wraps it in some appropriate imports and an appropriate one-line definition for main, then compiles and runs it in a sandbox and sticks the generated image in the wiki output. The devil's in the details, of course: you'd probably want to cache the generated images indexed by a hash of the diagrams code that generated them, to avoid recomputing the image every time the page loads. And there are probably other considerations I'm not thinking of.

-Brent

As it happens, I recently got interested in plugins for Gitit/Pandoc since they're the most straightforward way to implement features I would like very much*. John discussed it briefly: http://groups.google.com/group/pandoc-discuss/browse_thread/thread/54272f922... The crucial part is the definition processWith & processWithM: processWith :: (Data a, Data b) => (a -> a) -> b -> b processWithM :: (Monad m, Data a, Data b) => (a -> m a) -> b -> m b If I understand Braden, he wants to write down some Haskell expression and see instead whatever image is generated. So suppose we have syntax like this: !!!! Basic Circle draw $ circle 50 10 !!!! We toss into gitit a call to 'processWith imageGenerator'. imageGenerator looks something like imageGenerator a = unsafePerformIO $ do expr <- filterPlugins a img <- Diagrams.run expr writeFile path img replace a ("![](" ++ path ++ ")") where path = "static/user/" ++ "Basic Circle.png" Obviously this is just pseudocode, as 'replace' and 'filterPlugins' are nontrivial to write, but you get the idea. We stream through the wikitext looking for our special symbols which denote Diagram code, then we pass it to Diagrams (I handwave over how to turn String into a function suitable for Diagrams - maybe this would be actually a call to a Diagram executable?), save the image to a known location, and then replace the Diagram code with the Markdown syntax for linking/including an image. I doubt I'll do this anytime soon, but I suspect that with this approach, such a plugin would be about an evening's work or so. * signatures, interwiki links, and possibly categories -- gwern

On Sun, Feb 1, 2009 at 1:37 AM, John MacFarlane wrote:

Not too hard, I think. Here's code for something similar (for graphviz diagrams), derived from plugins/DotPlugin.hs in SVN pandoc.

transform :: Block -> IO Block transform (CodeBlock (id, classes, namevals) contents) | "dot" `elem` classes = do let (name, outfile) = case lookup "name" namevals of Just fn -> ([Str fn], fn ++ ".png") Nothing -> ([], uniqueName contents ++ ".png") result <- readProcess "dot" ["-Tpng"] contents writeFile outfile result return $ Para [Image name (outfile, "")] transform x = return x

-- | Generate a unique filename given the file's contents. uniqueName :: String -> String uniqueName = showDigest . sha1 . fromString

The 'transform' function will transform delimited code blocks such as

~~~ {.dot name="diagram1"} digraph G {Hello->World} ~~~

into images generated by running the contents through graphviz's dot. To lift this into a transformation of Pandoc documents, you can use syb:

convertGraphviz :: Pandoc -> IO Pandoc convertGraphviz = everywhereM (mkM transform)

With minimal modifications, the same technique should work for diagrams...

Best, John

This certainly does seem reasonable, but I don't think the sandboxing/interpretation question is addressed. In your GraphViz example, you dump out to the 'dot' executable and it does things which you read back. But with Diagrams, we're interested in running arbitrary Haskell code - that's what makes Diagrams so useful, that we can exploit the full power of Haskell in our expressions. Now, to implement it, I would probably say to myself, "well, we'll create a temporary file, we'll write some basic imports into it, then we'll write the user's expression into it as the definition of a function 'foo', and main will be defined as 'main = renderFile foo'. Then we use 'runhaskell' on the temporary file to create the picture, delete the temp file, and bob's your uncle." Except of course there's nothing to prevent DoS attacks or other exploits in the arbitrary code. So do we accept this and say that this is a plugin one uses at one's own risk? -- gwern

On Fri, Feb 6, 2009 at 1:13 PM, Chaddaï Fouché wrote:

On Wed, Feb 4, 2009 at 4:56 PM, Gwern Branwen wrote:

...

Now, to implement it, I would probably say to myself, "well, we'll create a temporary file, we'll write some basic imports into it, then we'll write the user's expression into it as the definition of a function 'foo', and main will be defined as 'main = renderFile foo'. Then we use 'runhaskell' on the temporary file to create the picture, delete the temp file, and bob's your uncle."

Except of course there's nothing to prevent DoS attacks or other exploits in the arbitrary code. So do we accept this and say that this is a plugin one uses at one's own risk?

Hackage contains some packages for that sandboxing, like mueval which is now used by lambdabot on #haskell I believe.

Yes, I'm familiar with mueval, but it may not be the right approach in this case (quite aside from the fact that a fair number of changes would be necessary). See my comment on the Pandoc issue: http://code.google.com/p/pandoc/issues/detail?id=102#c9 -- gwern

On Sun, Feb 01, 2009 at 03:43:35AM +0100, Henning Thielemann wrote:

Brent Yorgey schrieb:

...

I am very pleased to announce the 0.2 release of the diagrams package, an embedded domain-specific language for creating simple graphics in a compositional style. This release includes a number of significant new features, including:

* support for arbitrary straight and curved paths * more shape primitives, including polygons and rounded rectangles * support for rendering text * PNG, PDF, PS, and SVG output * built-in color support replaced with external dependence on the feature-rich colour library

and many more!

Maybe this can become an alternative to HPDF?

Well, they have very different goals, I think. Certainly there are some things you can do with HPDF that you can do with diagrams as well, but diagrams will never have all the PDF-specific features that HPDF has. If you want to make a diagram, illustration, logo, or something of that sort, and it's convenient to have it in PDF format, use diagrams. If you actually want to create a PDF document, with text layout, multiple pages, hyperlinks, annotations, etc., use HPDF; diagrams will never have those features. -Brent