Re: [Haskell-cafe] Re: ANN: diagrams 0.2
On Wed, Feb 4, 2009 at 4:56 PM, Gwern Branwen gwe...@gmail.com 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. -- Jedaï ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: diagrams 0.2
On Fri, Feb 6, 2009 at 1:13 PM, Chaddaï Fouché chaddai.fou...@gmail.com wrote: On Wed, Feb 4, 2009 at 4:56 PM, Gwern Branwen gwe...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: diagrams 0.2
On Sun, Feb 1, 2009 at 1:37 AM, John MacFarlane j...@berkeley.edu 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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: diagrams 0.2
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. 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: diagrams 0.2
On Sat, Jan 31, 2009 at 6:45 PM, Brent Yorgey byor...@seas.upenn.edu 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/54272f922c80b7b0 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 () 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
