Re: [diagrams] Interesting in participaiting in diagrams GSoC
35 views
Skip to first unread message
Brent Yorgey
Apr 27, 2013, 10:03:40 AM4/27/13
to diagrams...@googlegroups.com
Hi Daniil,
On Fri, Apr 26, 2013 at 06:35:00AM -0700, Daniil Frumin wrote:
> Hi everyone,
>
> my name is Daniil, I am an undergraduate CS student and I am
> interested in participating in diagrams GSoC and I am looking for a
> mentor. I have to admit, I am not yet familiar with all the nifty
> details of implementation of the library. My first encounter with
> diagrams was when I read Brent Yorgey's paper on monoids [1] and
> that's how I got interested in the library, so at least I know the
> details that were presented in the paper.
For making a paste site, familiarity with the internals of diagrams is
not very relevant. More relevant would be any experience you have
with Haskell in general and with creating websites in particular.
> I am interested in working on diagram's paste site (as been proposed
> on the wiki [2]), I actually wanted to do something similar with
> Graphviz, but after making some initial progress got carried away and
> never finished it [3]. I was thinking of making something more of a
> REPL (like tryhaskell, or ghc.io), rather than a simple
> pastebin+evaluator (like codepad).
I would very strongly encourage you to stick to the idea of a paste
site instead of a REPL, for several reasons:
1. As you point out, we already have several Haskell REPL sites; it
is not clear what would be all that distinctive about a REPL
which can also render diagrams. You would spend most of your
time reimplementing features that already exist in tryhaskell or
ghc.io.
2. In fact, during last year's GSoC there was a project to make a
web-based collaborative REPL (which could indeed render diagrams,
though that was not the main focus). It accomplished some things
but never really got to a state to be usable enough and is widely
regarded as something of a failure. So proposing a similar
project is not likely to be looked on very favorably.
3. Perhaps most importantly, in my opinion the diagrams project
would be best served by a paste site as opposed to a REPL. The
point is that I want to be able to easily share diagrams code and
its output with others. Also, a REPL interface is fun for
playing but not that useful because most often the code required
to make a diagram is much more than just a single line. In other
words, to be really useful a REPL interface would need to also
support (a) a way to also input larger blocks of code and (b) a
way to save and share code with others; but by that point you
have basically implemented a REPL plus also a paste site. So it
makes much more sense to *begin* with a paste site, and perhaps
add REPL-ish features afterwards as you have time.
Some general advice: we did not register diagrams as a separate
open-source project this year; any diagrams projects will be simply
under the general haskell.org organization. That means you need to
convince people why this project will be of benefit to the larger
Haskell community (and not just to people using diagrams).
Here's what I would advise: make a fork of the code for hpaste.org,
and add diagrams features to it. There's not really any point in
recreating your own foundation from scratch. Then ideally your
changes could even be merged back into hpaste.org itself.
Now, adding the ability to compile diagrams to hpaste would not take a
whole summer. It may be worth thinking about additional features that
would specifically make creating and sharing diagrams code easier.
Off the top of my head I am not sure what those might be. Perhaps
others will have some ideas.
-Brent
On Fri, Apr 26, 2013 at 06:35:00AM -0700, Daniil Frumin wrote:
> Hi everyone,
>
> my name is Daniil, I am an undergraduate CS student and I am
> interested in participating in diagrams GSoC and I am looking for a
> mentor. I have to admit, I am not yet familiar with all the nifty
> details of implementation of the library. My first encounter with
> diagrams was when I read Brent Yorgey's paper on monoids [1] and
> that's how I got interested in the library, so at least I know the
> details that were presented in the paper.
For making a paste site, familiarity with the internals of diagrams is
not very relevant. More relevant would be any experience you have
with Haskell in general and with creating websites in particular.
> I am interested in working on diagram's paste site (as been proposed
> on the wiki [2]), I actually wanted to do something similar with
> Graphviz, but after making some initial progress got carried away and
> never finished it [3]. I was thinking of making something more of a
> REPL (like tryhaskell, or ghc.io), rather than a simple
> pastebin+evaluator (like codepad).
I would very strongly encourage you to stick to the idea of a paste
site instead of a REPL, for several reasons:
1. As you point out, we already have several Haskell REPL sites; it
is not clear what would be all that distinctive about a REPL
which can also render diagrams. You would spend most of your
time reimplementing features that already exist in tryhaskell or
ghc.io.
2. In fact, during last year's GSoC there was a project to make a
web-based collaborative REPL (which could indeed render diagrams,
though that was not the main focus). It accomplished some things
but never really got to a state to be usable enough and is widely
regarded as something of a failure. So proposing a similar
project is not likely to be looked on very favorably.
3. Perhaps most importantly, in my opinion the diagrams project
would be best served by a paste site as opposed to a REPL. The
point is that I want to be able to easily share diagrams code and
its output with others. Also, a REPL interface is fun for
playing but not that useful because most often the code required
to make a diagram is much more than just a single line. In other
words, to be really useful a REPL interface would need to also
support (a) a way to also input larger blocks of code and (b) a
way to save and share code with others; but by that point you
have basically implemented a REPL plus also a paste site. So it
makes much more sense to *begin* with a paste site, and perhaps
add REPL-ish features afterwards as you have time.
Some general advice: we did not register diagrams as a separate
open-source project this year; any diagrams projects will be simply
under the general haskell.org organization. That means you need to
convince people why this project will be of benefit to the larger
Haskell community (and not just to people using diagrams).
Here's what I would advise: make a fork of the code for hpaste.org,
and add diagrams features to it. There's not really any point in
recreating your own foundation from scratch. Then ideally your
changes could even be merged back into hpaste.org itself.
Now, adding the ability to compile diagrams to hpaste would not take a
whole summer. It may be worth thinking about additional features that
would specifically make creating and sharing diagrams code easier.
Off the top of my head I am not sure what those might be. Perhaps
others will have some ideas.
-Brent
Daniil Frumin
Apr 27, 2013, 3:15:56 PM4/27/13
to diagrams...@googlegroups.com
Thanks for your comments, Brent!
> Some general advice: we did not register diagrams as a separate
> open-source project this year; any diagrams projects will be simply
> under the general haskell.org organization. That means you need to
> convince people why this project will be of benefit to the larger
> Haskell community (and not just to people using diagrams).
>
> Here's what I would advise: make a fork of the code for hpaste.org,
> and add diagrams features to it. There's not really any point in
> recreating your own foundation from scratch. Then ideally your
> changes could even be merged back into hpaste.org itself.
>
> Now, adding the ability to compile diagrams to hpaste would not take a
> whole summer. It may be worth thinking about additional features that
> would specifically make creating and sharing diagrams code easier.
> Off the top of my head I am not sure what those might be. Perhaps
> others will have some ideas.
Some features I was thinking about:
- Syntax highlighting, completion (when possible)
- Ability to draw simple diagrams visually (the generated code can be reused)
- Export to various diagrams backends
- Use diagrams to visualise things about non-diagrams code (haven't thought this one through)
I would be most glad to hear comments and ideas from you or anyone on this mailing list.
- Dan
> -Brent
>
> --
> You received this message because you are subscribed to the Google Groups "diagrams-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to diagrams-discu...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
Daniil Frumin
Apr 27, 2013, 4:07:30 PM4/27/13
to diagrams...@googlegroups.com
So here is a bunch of ideas we game up with on IRC:
* Main issues: safety + resource management
** mueval; using a single process to reduce startup time
* Extend hpaste with something that compiles and renders diagram to an .svg or a .png
* Use GHCJS to compile diagram to a piece of code runnable on a client
* Add different types of HTML widgets for functions
E.g.: (Double -> Diagram) would render into an input box + button,
(Bool -> Diagram) would have a checkbox, etc
* Try to create a very modular structure, so the results can be incorporated into Wolfgang or SoH
* Support for feedback from the resulting diagrams
* Drawing simple diagrams/paths using canvas or drag&drop things
(Thanks to Luite, Ryan, Brent)
* Main issues: safety + resource management
** mueval; using a single process to reduce startup time
* Extend hpaste with something that compiles and renders diagram to an .svg or a .png
* Use GHCJS to compile diagram to a piece of code runnable on a client
* Add different types of HTML widgets for functions
E.g.: (Double -> Diagram) would render into an input box + button,
(Bool -> Diagram) would have a checkbox, etc
* Try to create a very modular structure, so the results can be incorporated into Wolfgang or SoH
* Support for feedback from the resulting diagrams
* Drawing simple diagrams/paths using canvas or drag&drop things
(Thanks to Luite, Ryan, Brent)
Daniil Frumin
Apr 28, 2013, 7:09:26 AM4/28/13
to diagrams...@googlegroups.com
Hi, everyone!
Since some people have considered this idea to be valuable I took the liberty of writing a proposal draft: https://gist.github.com/co-dan/437e9694563c0c13dd8e
- Dan
Since some people have considered this idea to be valuable I took the liberty of writing a proposal draft: https://gist.github.com/co-dan/437e9694563c0c13dd8e
- Dan
Reply all
Reply to author
Forward
0 new messages