Re: [Haskell-cafe] Re: ANN: diagrams 0.2
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 ___ 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 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. -- 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 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
___
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 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 ("![](" ++ 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
___
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
