GSoC and Charts: Where are we?

[Dom]

Can someone summarise where we are with regard to charts and GSoC?

1. We'd all like the ability to draw charts.
   
2. We have at least one volunteer who would like to implement something.
   
3. dcharts looks a pretty good start.
4. There are some issues to do with fonts (raised several times by Tim Docker - thanks).
5. I read http://www.gwern.net/Haskell%20Summer%20of%20Code and it seems that to maximise success, the goal of the project must be very clear and not too ambitious.
6. That's it as far as I understand it but would it be possible for someone more knowledgeable than me to summarise where we are and come up with a clear and not too ambitious goal for GSoC?

Dominic.

[Jan Bracker]

Some thoughts:

2. Yep :-)

3. dcharts: http://patch-tag.com/r/mf/dcharts/home - I have not had a close look, but for what I can see it seems to be specialized on certain types of charts (excuse me if I am wrong, but it supports solely bar and bubble charts?). I also had a skim look at the Charts library from Tim Docker (http://dockerz.net/twd/HaskellCharts / http://hackage.haskell.org/package/Chart). It looks mature and quite general. Maybe it would be good to use its API as a guide or even generalise it to a degree that its is independent of cairo and compatible with diagrams.

4. As mentioned in others threads SVGFonts (http://hackage.haskell.org/package/SVGFonts) may be a good solution for this problem. But they are limited to the SVG backend right?

Jan

2013/3/27 Dom <idontge...@googlemail.com>

--
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.
 
 

[Brent Yorgey]

On Thu, Mar 28, 2013 at 10:49:06AM -0500, Jan Bracker wrote:
>
> 3. dcharts: http://patch-tag.com/r/mf/dcharts/home - I have not had a close
> look, but for what I can see it seems to be specialized on certain types of
> charts (excuse me if I am wrong, but it supports solely bar and bubble
> charts?). I also had a skim look at the Charts library from Tim Docker (
> http://dockerz.net/twd/HaskellCharts /
> http://hackage.haskell.org/package/Chart). It looks mature and quite
> general. Maybe it would be good to use its API as a guide or even
> generalise it to a degree that its is independent of cairo and compatible
> with diagrams.

It sounds like Tim is interested in this, but there are some
nontrivial issues to be worked out (see the previous thread here:
https://groups.google.com/forum/?fromgroups=#!topic/diagrams-discuss/cGlNL5ZEEnI).

> 4. As mentioned in others threads SVGFonts (
> http://hackage.haskell.org/package/SVGFonts) may be a good solution for
> this problem. But they are limited to the SVG backend right?

Not at all! The 'SVG' in SVGFonts just refers to the fact that it
reads fonts in the SVG format. But it can convert text into paths
which can then be rendered by any backend.

-Brent

>
> 2013/3/27 Dom <idontge...@googlemail.com>
>
> > Can someone summarise where we are with regard to charts and GSoC?
> >
> >

> > 1. We'd all like the ability to draw charts.
> > 2. We have at least one volunteer who would like to implement
> > something.
> > 3. dcharts looks a pretty good start.
> > 4. There are some issues to do with fonts (raised several times by Tim
> > Docker - thanks).
> > 5. I read http://www.gwern.net/Haskell%20Summer%20of%20Code and it

> > seems that to maximise success, the goal of the project must be very clear
> > and not too ambitious.

> > 6. That's it as far as I understand it but would it be possible for

[Carter Schonwald]

Indeed, as brent points out, theres a challenging question of managing scope with some of the project ideas, and the hallmark

of a good GSOC project is that it is both *tractible* for a student to successfully do over the summer, and theres a clear path of that student's work being used by the associated community.

I *hope* to have some helpful ideas in this space for tractible projects out the door in another week or so, maybe.  

[Jan Bracker]

After looking at the other thread that Brent pointed out, I don't really see any major issues. The problem of rendering font and working with its metrics can be solved by using SVGFonts and by pulling out this kind of information. Maybe I am underestimating the issue here. Are there any other issues I should be aware of?

Managing the scope might be a problem with this project, as the Charts API seems to be quite big and versatile. I have no doubt that the this work will be used and appriciated by the community (There are several references here that this has been requested a few times already). What worries me a little bit is that the mentor page of haskell.org on the GSoC website says:

For this year's Google Summer of Code, Haskell.org is particularly
keen to see proposals for work on libraries, compilers, and tools, that
is, infrastructure to support the growth of the language, rather than
(say) applications that merely use Haskell.
  -- http://www.google-melange.com/gsoc/org/google/gsoc2013/haskell

I am not sure if that rules out work on non-core language stuff like charts or diagrams.

2013/3/30 Carter Schonwald <carter.s...@gmail.com>

[Brent Yorgey]

On Tue, Apr 16, 2013 at 12:16:23PM -0500, Jan Bracker wrote:
>
> For this year's Google Summer of Code, Haskell.org is particularly
> keen to see proposals for work on libraries, compilers, and tools, that
> is, infrastructure to support the growth of the language, rather than
> (say) applications that merely use Haskell.
> -- http://www.google-melange.com/gsoc/org/google/gsoc2013/haskell

The Haskell GSoC page always says that. Diagrams, I think, falls
somewhere in between -- it is not just an "application that merely
uses Haskell", especially since we are trying to push into spaces like
documentation (with diagrams-haddock). I hope it can also be a sort
of "killer app" for Haskell that will attract people. So in that
sense it does support the growth of the language. But I think
proposals relating to diagrams will have to make a clear case for
this.

-Brent

[Dom]

Hi Jan,

Given that we seem to have a way forward, can you draft up a proposal? Is there someone who could volunteer to do the mentoring?

Dominic.

[Carter Schonwald]

Let me throw out another idea that fits all the goals, but has a (potentially) more manageable scope and a more compelling community usage:

a d3 backend for Diagrams + some basic example plotting utilities on top would in some ways be a bit narrower. Likewise, there are many many folks in the haskell community who would love a declarative way to embed d3 style visuals into their websites / html based documents.

This would be less prescriptive than "designing a good plotting / data vis tool"  (thats really hard, anyone who says otherwise is lying lying lying), and  there'd be a lot of really tractable incremental steps.

Eg a first step could be just writing a haskell plotting layer than maps directly to the trifacta vega tool (which is simpler to target than d3 directly)

https://github.com/trifacta/vega

and then after that, some work could be done building a diagrams backend for d3 itself. Not full d3, I think that might be tricky until we have ghcjs or the like working nicely sometime this fall or later, but just having a working d3 backend (which is sort of an abstraction layer over html5 canvas) would be pretty exciting for a lot of folks, myself included.

also D4 would be a cute name for a  Diagrams D3 backend.

for things like Data Vis / Plotting / most data analysis tools, theres a really tight coupling between the API you provide, and how easily you can support doing interesting work... so in some ways, work that enriches diagrams as a substrate is more likely to be work that can be built on by subsequent folks, or outright used.

Any work at the data vis / plotting layer requires really really heavily using it and getting lots of feedback who'll be using it *intensly* and *regularly*.  I think that sort of extra footwork is a bit much for a GSOC sized project... but thats just me and my data vis hacking. (which should move along more soonish, but not in time to be helpful for GSOC proposals).

I hope what i'm saying is helpful...

cheers

-Carter

[Jan Bracker]

Hi,

Let me throw out another idea that fits all the goals, but has a (potentially) more manageable scope and a more compelling community usage:

a d3 backend for Diagrams + some basic example plotting utilities on top would in some ways be a bit narrower. Likewise, there are many many folks in the haskell community who would love a declarative way to embed d3 style visuals into their websites / html based documents.

By d3 you mean [6] ? Why a backend using that library? Diagrams is a drawing library and it seems like that library does a lot more specific things then drawing. Besides there is a backend to generate SVG (which can be embedded) and it would also be possible to generate JavaScript for drawing on a canvas element as done by diagrams-canvas [1] and could be done with Sunroof [2,3].

 

This would be less prescriptive than "designing a good plotting / data vis tool"  (thats really hard, anyone who says otherwise is lying lying lying), and  there'd be a lot of really tractable incremental steps.

I won't argue with that, but: My suggestion would have been to adopt/port the Charts API [4]. Which means there would not be to much design involved, as that step is already done.

 

Eg a first step could be just writing a haskell plotting layer than maps directly to the trifacta vega tool (which is simpler to target than d3 directly)

https://github.com/trifacta/vega 

Doesn't this kick Diagrams out of the loop?

 

and then after that, some work could be done building a diagrams backend for d3 itself. Not full d3, I think that might be tricky until we have ghcjs or the like working nicely sometime this fall or later, but just having a working d3 backend (which is sort of an abstraction layer over html5 canvas) would be pretty exciting for a lot of folks, myself included.

also D4 would be a cute name for a  Diagrams D3 backend.

How does the work with Vega [5] help here?

Also this seems like a lot of prototyping without a sure result or contribution to any project. Though I might be misunderstanding your idea.

for things like Data Vis / Plotting / most data analysis tools, theres a really tight coupling between the API you provide, and how easily you can support doing interesting work... so in some ways, work that enriches diagrams as a substrate is more likely to be work that can be built on by subsequent folks, or outright used.

Any work at the data vis / plotting layer requires really really heavily using it and getting lots of feedback who'll be using it *intensly* and *regularly*.  I think that sort of extra footwork is a bit much for a GSOC sized project... but thats just me and my data vis hacking. (which should move along more soonish, but not in time to be helpful for GSOC proposals).

As said that process is already done if we are just talking about porting Charts. 

Jan

[1] https://github.com/ku-fpg/diagrams-canvas

[2] http://www.ittc.ku.edu/csdl/fpg/software/sunroof.html

[3] http://hackage.haskell.org/package/sunroof-compiler

[4] http://hackage.haskell.org/package/Chart

[5] http://trifacta.github.io/vega/

[6] http://d3js.org/

[Jan Bracker]

PS: First draft of a proposal: https://gist.github.com/jbracker/9c24df36a8dc1ba4bafe

2013/4/17 Jan Bracker <jan.b...@googlemail.com>

[Carter Schonwald]

oh ok, porting Charts make sense / is managable. 

(my in my head thread cache was stale / hadn't read that suffix of the thread properly, my apologies)

hrm for your proposal, you should make it more explicit that a *HUGE* upside is a basic charting lib that would be portable across every major OS. (thats actually a big deal!)

looks like a solid proposal. I'll stare at stuff and see if I can come up with any other suggestions. 

[Jan Bracker]

I have updated the proposal: https://gist.github.com/jbracker/9c24df36a8dc1ba4bafe

2013/4/17 Carter Schonwald <carter.s...@gmail.com>

[Carter Schonwald]

the phrasing of of "Like this the Charts library will be easy to install on every plattform supported by Haskell. The support for backends is also growing constantly. This will also make it easy to compose charts with other diagrams."

maybe something more like "Because of Diagrams is easy to install on every plattform supported by Haskell, so will a Charting Library built upon Diagrams. The support for backends is also growing constantly. This will  make it easy for Haskellers to add charting capabilities to their own applications and libraries in a manner portable across all platforms without any pain."

the focus has to be on upside for the *general* haskell community, not just the folks who are playing with diagrams already.

[Carter Schonwald]

and of course replacer plattform with platform

[Tim Docker]

Whilst I'd like to see Haskell charting capabilities more broadly available, I'm worried about creating a fork of the existing charting library. Will it have an ongoing maintainer? Will existing users migrate if it's not 100% feature compatible with the existing one? Etc.

An alternative approach that might be considered would be to modify the existing library to abstract the drawing API, and then create backend instances of this abstraction for the existing Cairo/gtk capabilities and for diagrams also.

This would keep a single library visible to the community, whilst giving all the benefits of the proposed GSOC project.

Tim

[Jan Bracker]

I  agree with you. That would be a nicer approach. But there still is the problem that some parts of the public API make direct use of Cairo data types and expose them to the user. So there will be incompatibilities in either approach, because those types should not be exposed anywere anymore when generalising.

2013/4/21 Tim Docker <t...@dockerz.net>

[Tim Docker]

On 23/04/13 01:01, Jan Bracker wrote:
> I agree with you. That would be a nicer approach. But there still is
> the problem that some parts of the public API make direct use of Cairo
> data types and expose them to the user. So there will be
> incompatibilities in either approach, because those types should not
> be exposed anywere anymore when generalising.
>

I think this only happens for these Cairo datatypes:

FontWeight
FontSlant
LineCap
LineJoin

These are all simple enums, with only a handful of used values. These
could easily be defined locally in the Chart code.

Nearly all releases of Chart have been incompatible at the API in one
way or another. I wouldn't be worried if a new version had a few API
breakages. I'm more concerned with keeping existing functionality
complete, keeping existing output looking exactly the way it does now, etc.

Tim

[Brent Yorgey]

On Tue, Apr 23, 2013 at 06:45:40AM +1000, Tim Docker wrote:
> On 23/04/13 01:01, Jan Bracker wrote:
> >I agree with you. That would be a nicer approach. But there still
> >is the problem that some parts of the public API make direct use of
> >Cairo data types and expose them to the user. So there will be
> >incompatibilities in either approach, because those types should
> >not be exposed anywere anymore when generalising.
> >
>
> I think this only happens for these Cairo datatypes:
>
> FontWeight
> FontSlant
> LineCap
> LineJoin
>
> These are all simple enums, with only a handful of used values. These
> could easily be defined locally in the Chart code.

In fact, diagrams-lib itself already defines corresponding enum types,
in Diagrams.Attributes and Diagrams.TwoD.Text, which are identical to
the corresponding Cairo datatypes. So they could simply be re-exported
from Chart in place of the Cairo types. Any client code that made use
of those types would continue to work since all the constructor names
etc. are the same.

-Brent

[Tim Docker]

On 23/04/13 07:35, Brent Yorgey wrote:
> In fact, diagrams-lib itself already defines corresponding enum types,
> in Diagrams.Attributes and Diagrams.TwoD.Text, which are identical to
> the corresponding Cairo datatypes. So they could simply be re-exported
> from Chart in place of the Cairo types

That would work. However, rather that switching the API from exporting
cairo types, to exporting diagrams types, I think I'd prefer to see the
API independent of either backend.

Tim

[Brent Yorgey]

Fair enough. If there ends up being enough of this sort of stuff we
could even consider moving it into a separate package which both
diagrams and Chart can depend on.

-Brent

[Jan Bracker]

Brent, Tim,

I agree with all of the points made. Carter, I also incorporated your suggestions.

I have updated my proposal accordingly: https://gist.github.com/jbracker/9c24df36a8dc1ba4bafe/fe17fde87b45e2563f8fc60e9a551bd9a366b095

Charts should definitly be generalised to use any possible backend not just a chosen one.

I like the idea of maybe providing a package that provides common data types of several rendering platforms.

Jan

2013/4/22 Brent Yorgey <byo...@seas.upenn.edu>

[Jan Bracker]

I have updated my proposal with a small plan of milestones: https://gist.github.com/jbracker/9c24df36a8dc1ba4bafe/1d0bed2e5eee7ae3b839b3de495a8355b9ec92eb

The SUBMISSION DEADLINE is NEXT FRIDAY the 3. May:

 * Are there any other remarks you have to my proposal? 

 * Where do I submit my proposal? I can not find any place to put it on the GSoC 2013 page, though I am logged in.

2013/4/22 Jan Bracker <jan.b...@googlemail.com>

[Carter Schonwald]

Jan,

you may want to ask the folks on the #haskell-gsoc or ask/email edward kmett if you're having troubling figuring registering on the google GSOC website (make sure you're trying to register on the google gsoc site, not the haskell.org gsoc site).

[Jan Bracker]

I just found out how to register. I will submit my proposal this weekend.

2013/4/25 Carter Schonwald <carter.s...@gmail.com>

[Dominic Steinitz]

Do we have someone to mentor this? Brent, do you have time? I think this project's chance of getting accepted would be enhanced if the mentor were Brent. I am happy to help out but I am merely a user of diagrams who would like to be able to use it to draw charts easily. Dominic.

[Andy Gill]

I would be happy to mentor this.

[Brent Yorgey]

Great, Andy will probably make a better official mentor than me for
this. Though of course I will be around and happy to help however I
can.

-Brent

[Tim Docker]

I would also be happy to mentor this - either way, I also am happy to
help as required.

Tim

[Andy Gill]

Thanks Tim. Like you, I am happy either way. It looks like an interesting project.

[Dom]

Great news that you, Tim and Brent can help out / mentor.

Jan, For your answer to this question:

In what ways do you envisage interacting with the wider Haskell

community during your project? e.g. How would you seek help on

something your mentor wasn't able to deal with? How will you get

others interested in what you are doing?

I think you can say that there already is a core group of experienced

members of the Haskell community who are keen and eager to help. It

might help to link to some of these

e.g. http://www.ittc.ku.edu/csdl/fpg/users/andygill.html

http://www.cis.upenn.edu/~byorgey/

Andy, Brent, Are you comfortable with this?

Tim, I tried dockerz.net but got a timeout.

[Andy Gill]

Tim - I am fine with a link to my webpage being added to the proposal.

[Dom]

I have been called many things in my life but never Tim :-) Do you have to register as a mentor now (perhaps you already are) or do we wait until the proposal is accepted?

Dominic.

[Andy Gill]

Sorry Dominic - I saw the cc: to Tim Docker, and assumed that Dom was an alias for Tim Docker. My wrong.

Good question regarding registration. Jan, do you know?

Andy

[Jan Bracker]

I added the links to the proposal: https://gist.github.com/jbracker/9c24df36a8dc1ba4bafe

I have no idea how the process for mentors works. I registered on the GSoC 2013 site as a student. Below the link for applying as a student there is one to register as possible mentor: http://www.google-melange.com/gsoc/homepage/google/gsoc2013

2013/4/28 Andy Gill <andy...@ittc.ku.edu>

[Jan Bracker]

PS: As Tim is the main developer on Charts, I think he would be best to mentor the project.

2013/4/28 Jan Bracker <jan.b...@googlemail.com>

[Tim Docker]

On 29/04/13 04:12, Dom wrote:
>
> I think you can say that there already is a core group of experienced
> members of the Haskell community who are keen and eager to help. It
> might help to link to some of these
> e.g. http://www.ittc.ku.edu/csdl/fpg/users/andygill.html
> http://www.cis.upenn.edu/~byorgey/
>
> Andy, Brent, Are you comfortable with this?
>
> Tim, I tried dockerz.net but got a timeout.
>

Yikes. Not sure why dockerz.net was down. I've rebooted it and all seems
normal.

However, I don't really have much of an online presence to reference. In
addition to the chart stuff at dockerz.net I have a sporadic haskell
related blog at:

http://twdkz.wordpress.com/

Tim

[Tim Docker]

I am ok doing this. Let me know what I have to do now (if anything).

However, my knowledge of the diagrams library is limited to reading of the tutorials and a small amount of tinkering. So it would be great to have input from others in this area.

Tim

[Brent Yorgey]

My understanding is that the role of the mentor is to ensure the
student is making adequate progress, to give advice and help as
needed, and to serve as the official point of contact with Google.
But there is not any expectation that the mentor will be able to help
with all aspects of the project. Of course, there are many of us with
more knowledge of diagrams itself who would be happy to offer guidance
as well.

Tim, in order to sign up as a mentor, go to

http://www.google-melange.com/gsoc/homepage/google/gsoc2013

and click the link at the bottom to sign up as a mentor. It's a bit
confusing but once you have an account, you find the haskell.org
organiztion and "initiate a connection" or something like that (I
forget the exact wording).

-Brent

On Mon, Apr 29, 2013 at 08:41:09AM +1000, Tim Docker wrote:
> I am ok doing this. Let me know what I have to do now (if anything).
>
> However, my knowledge of the diagrams library is limited to reading
> of the tutorials and a small amount of tinkering. So it would be
> great to have input from others in this area.
>
> Tim
>
>
> On 29/04/13 04:39, Jan Bracker wrote:
> >PS: As Tim is the main developer on Charts, I think he would be
> >best to mentor the project.
> >
> >
> >2013/4/28 Jan Bracker <jan.b...@googlemail.com

> ><mailto:jan.b...@googlemail.com>>

> >
> > I added the links to the proposal:
> > https://gist.github.com/jbracker/9c24df36a8dc1ba4bafe
> >
> > I have no idea how the process for mentors works. I registered on
> > the GSoC 2013 site as a student. Below the link for applying as a
> > student there is one to register as possible mentor:
> > http://www.google-melange.com/gsoc/homepage/google/gsoc2013
> >
> >
> > 2013/4/28 Andy Gill <andy...@ittc.ku.edu

> > <mailto:andy...@ittc.ku.edu>>

> > <http://www.cis.upenn.edu/%7Ebyorgey/>

> > > >
> > > > Andy, Brent, Are you comfortable with this?
> > > >

> > > > Tim, I tried dockerz.net <http://dockerz.net> but got a

> > timeout.
> > > >
> > > > On Friday, 26 April 2013 23:52:49 UTC+1, Andy Gill wrote:
> > > > Thanks Tim. Like you, I am happy either way. It looks like
> > an interesting project.
> > > >
> > > > On Apr 26, 2013, at 4:57 PM, Tim Docker wrote:
> > > >
> > > > > I would also be happy to mentor this - either way, I
> > also am happy to help as required.
> > > > >
> > > > > Tim
> > > > >
> > > > >
> > > > > On 27/04/13 04:40, Brent Yorgey wrote:
> > > > >> Great, Andy will probably make a better official mentor
> > than me for
> > > > >> this. Though of course I will be around and happy to
> > help however I
> > > > >> can.
> > > > >>
> > > > >> -Brent
> > > > >>
> > > > >> On Fri, Apr 26, 2013 at 10:53:52AM -0500, Andy Gill wrote:
> > > > >>> I would be happy to mentor this.
> > > > >>>
> > > > >>> On Apr 26, 2013, at 10:00 AM, Dominic Steinitz wrote:
> > > > >>>
> > > > >>>> Do we have someone to mentor this? Brent, do you have
> > time? I think this project's chance of getting accepted would
> > be enhanced if the mentor were Brent. I am happy to help out
> > but I am merely a user of diagrams who would like to be able
> > to use it to draw charts easily. Dominic.
> > > > >>>>
> > > > >>>> On 26 Apr 2013, at 04:30, Jan Bracker

> > <jan.b...@googlemail.com <mailto:jan.b...@googlemail.com>> wrote:
> > > > >>>>
> > > > >>>>> I just found out how to register. I will submit my
> > proposal this weekend.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> 2013/4/25 Carter Schonwald <carter.s...@gmail.com

> > <mailto:carter.s...@gmail.com>>

> > > > >>>>> Jan,
> > > > >>>>> you may want to ask the folks on the #haskell-gsoc
> > or ask/email edward kmett if you're having troubling figuring
> > registering on the google GSOC website (make sure you're
> > trying to register on the google gsoc site, not the

> > haskell.org <http://haskell.org> gsoc site).

> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On Thu, Apr 25, 2013 at 12:15 PM, Jan Bracker
> > <jan.b...@googlemail.com <mailto:jan.b...@googlemail.com>> wrote:
> > > > >>>>> I have updated my proposal with a small plan of
> > milestones:
> > https://gist.github.com/jbracker/9c24df36a8dc1ba4bafe/1d0bed2e5eee7ae3b839b3de495a8355b9ec92eb
> > > > >>>>>
> > > > >>>>> The SUBMISSION DEADLINE is NEXT FRIDAY the 3. May:
> > > > >>>>>
> > > > >>>>> * Are there any other remarks you have to my proposal?
> > > > >>>>> * Where do I submit my proposal? I can not find any
> > place to put it on the GSoC 2013 page, though I am logged in.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> 2013/4/22 Jan Bracker <jan.b...@googlemail.com

> > <mailto:jan.b...@googlemail.com>>

> > > > >>>>> Brent, Tim,
> > > > >>>>>
> > > > >>>>> I agree with all of the points made. Carter, I also
> > incorporated your suggestions.
> > > > >>>>>
> > > > >>>>> I have updated my proposal accordingly:
> > https://gist.github.com/jbracker/9c24df36a8dc1ba4bafe/fe17fde87b45e2563f8fc60e9a551bd9a366b095
> > > > >>>>>
> > > > >>>>> Charts should definitly be generalised to use any
> > possible backend not just a chosen one.
> > > > >>>>> I like the idea of maybe providing a package that
> > provides common data types of several rendering platforms.
> > > > >>>>>
> > > > >>>>> Jan
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> 2013/4/22 Brent Yorgey <byo...@seas.upenn.edu

> > <mailto:byo...@seas.upenn.edu>>

> > <mailto:diagrams-discu...@googlegroups.com>.

> > > > >>>> For more options, visit
> > https://groups.google.com/groups/opt_out.
> > > > >>>>
> > > > >>> --
> > > > >>> 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

> > <mailto:diagrams-discu...@googlegroups.com>.

> > > > >>> For more options, visit
> > https://groups.google.com/groups/opt_out.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >
> > > > > --
> > > > > 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

> > <mailto:diagrams-discu...@googlegroups.com>.

> > > > > For more options, visit
> > https://groups.google.com/groups/opt_out.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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

> > <mailto:diagrams-discu...@googlegroups.com>.

> > > > For more options, visit
> > https://groups.google.com/groups/opt_out.
> > > >
> > > >
> > >
> > >
> > > --
> > > 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

> > <mailto:diagrams-discuss%2Bunsu...@googlegroups.com>.

> > > For more options, visit
> > https://groups.google.com/groups/opt_out.
> > >
> > >
> >
> > --
> > 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

> > <mailto:diagrams-discuss%2Bunsu...@googlegroups.com>.

[Jan Bracker]

The proposal is submitted: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/jbracker/1

2013/4/28 Brent Yorgey <byo...@seas.upenn.edu>