diagrams 2.0 proposal

[Christopher Chalmers]

As some of you know I've been working on a rewrite of the diagrams library for a while now. Unfortunately I've been very busy and won't really have time to work on it until at least September (probably later). However, I think now is good time to discuss the direction of the rewrite so when I'm finally ready to work on it again we're all on the same page.

You can find the full list of changes in the READMEs of geometry and diagrams. The big changes are:

1. Splitting out a separate library, geometry, for all things geometry based (paths etc.). In addition diagrams-core would be merged with the remaining parts of diagrams-lib.

2. Removal of the backend token in the Diagram type.

It would be great if I could get everyone's opinions on at least the main points. If you like I can do a writeup about why I'd like the backend token to go. We can discuss the smaller changes over the next few months, either here or github or on irc.

If everyone's happy with splitting out geometry I can move it over to the diagrams organisation. It still needs some finishing touches but it's pretty much there.

[Brent Yorgey]

Thanks for kicking this off --- sorry I failed to follow up on my promise to send out such an email myself!

Personally I am all for splitting out a 'geometry' library (and merging the rest of diagrams-core with diagrams-lib then sounds fine).  This is something people have long been asking for, but I had never figured out a good way to do it.

I would be interested to read a fuller writeup of your rationale for getting rid of the backend token type.

-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/d/optout.

[Christopher Chalmers]

No problem. I think last time we talked about this I mentioned I was going to post something on the mailing list and it just took me few weeks to do it :)

I'll get writing my reasons for wanting to get rid of the token. I'll try to get it done in the next week or so.

While I remember, one thing you did promise me was trying to get an automatic differentiation diagram example. I think it was premature when I said specialising Diagram to Double didn't make much difference. I've since run benchmarks where not specialising can make envelope calculations significantly slower. If everything inlines and all the specialise rules kick in then there isn't much difference but it's very easy some optimisation to not kick in or some function remain polymorphic and it slows everything down considerably. (In my benchmark I wrote path10 = foldMap stroke . take 10 in a let clause. If stroke isn't specialised to Double or path10 isn't given a type signature, getting the diameter of the resulting diagram is 5-20x slower).

[Christopher Chalmers]

That part of the proposal is really just splitting out the geometric stuff diagrams uses into a new library (and making it faster). I hadn’t considered adding abstract geometry to it but I’m certainly open to the idea in the future. I have very basic support for polar coordinates in plots but it would be nice to have more exotic things like those in your post.

On 28 Jun 2017, at 08:00, idontgetoutmuch wrote:

Is the idea to have an abstract geometry package which can be rendered by the diagrams package or have I completely misunderstood?

Is this a first step or are there other steps? The geometry proposal looked very biased towards 2D and 3D Euclidean geometry. For the sort of things possible take a look at http://sagemanifolds.obspm.fr/. It is absolutely brilliant for doing and rendering differential geometry. I wrote a little article on the mercator projection using it: https://idontgetoutmuch.wordpress.com/2016/11/24/mercator-a-connection-with-torsion/. I am sad I can't do this in Haskell but I can dream.

[Jeffrey Rosenbluth]

I'm also in favor of splitting out a geometry library. I'm anxious to hear about getting rid of the backend token. It certainly has vexed me in the past when trying to ride code that is polymorphic over the backend.

[Christopher Chalmers]

It seems that everyone's happy with `geometry` so I've moved it over to the diagrams organisation on github. I'll make some issues for things that still need to be done.

I've finished my write-up about the backend token and uploaded it here. Let me know what you think.

[Brent Yorgey]

Hi Chris,

Thanks for taking the time to write up your thoughts on the backend
token.  I finally sat down and read through them today.  I would still like to take a closer look at your rewrite and
see how you have handled things, but I think I am pretty much
convinced.  I personally have found the backend tokens annoying too,
and agree they are not pulling their weight.

-Brent

--

[Christopher Chalmers]

Great! Glad to hear it. If you do look though my code bear in mind it's not quite finished. I got it a level where I think I can do what I need but really I need to have working versions of things like diagrams-builder, diagrams-pandoc etc. before I can be sure. Also the names I've given things probably need changing and the documentation isn't great. Do ask if you have any questions and suggestions are very welcome.

[Daniel Bergey]

+1 to making it easier to use the geometry modules without pulling in
Diagrams' particular choices around Attributes, Measure, DUALTree.

I don't have a strong opinion about the Backend type parameter.

bergey

On 2017-07-30 at 08:40, Christopher Chalmers <c.cha...@me.com> wrote:
> Great! Glad to hear it. If you do look though my code bear in mind it's not quite finished. I got it a level where I think I can do
> what I need but really I need to have working versions of things like diagrams-builder, diagrams-pandoc etc. before I can be sure.
> Also the names I've given things probably need changing and the documentation isn't great. Do ask if you have any questions and
> suggestions are very welcome.
>
> On Wednesday, July 26, 2017 at 3:53:42 AM UTC+1, Brent Yorgey wrote:
>
> Hi Chris,
>
> Thanks for taking the time to write up your thoughts on the backend
> token.  I finally sat down and read through them today.  I would still like to take a closer look at your rewrite and
> see how you have handled things, but I think I am pretty much
> convinced.  I personally have found the backend tokens annoying too,
> and agree they are not pulling their weight.
>
> -Brent
>
> On Sun, Jul 2, 2017 at 10:37 AM Christopher Chalmers <c.cha...@me.com> wrote:
>
> It seems that everyone's happy with `geometry` so I've moved it over to the diagrams organisation on github. I'll make some
> issues for things that still need to be done.
>
> I've finished my write-up about the backend token and uploaded it here. Let me know what you think.
>
> On Monday, June 26, 2017 at 8:47:47 PM UTC+1, Christopher Chalmers wrote:
>
> As some of you know I've been working on a rewrite of the diagrams library for a while now. Unfortunately I've been very
> busy and won't really have time to work on it until at least September (probably later). However, I think now is good
> time to discuss the direction of the rewrite so when I'm finally ready to work on it again we're all on the same page.
>
> You can find the full list of changes in the READMEs of geometry and diagrams. The big changes are:
>

> 1. Splitting out a separate library, geometry, for all things geometry based (paths etc.). In addition diagrams-core

> would be merged with the remaining parts of diagrams-lib.
>

> 2. Removal of the backend token in the Diagram type.

[Nao Fujinaga]

Maybe a bit off topic, but I just want to share my thought on diagrams-2.0 as a user of diagrams.

Also I have some questions on the development of backend of diagrams-2.0.

I have been developing GUI application using diagrams for some time and I'm quite a fan of diagrams.

So I'm very excited to hear that the diagrams-2.0 is being developped especially since the diagrams-2.0 seems to be focusing on the performance improvement while my current impediment using diagrams for GUI application is all about performance.

My experience with developing GUI application with diagrams convinced me that the diagrams have the potential to be used as the basis for framework to build GUI application which is a lot more flexible compared to the widget based framework (such as gtk) or html based web application.

Currently I have been developing the application using cairo + gtk backend of diagrams.

At first I was thinking of using widgets provided by gtk for GUI components such as scroll bars, pulldown menu, radio buttons etc. But since diagrams are so powerful and expressive I end up with rendering all the components using diagrams. (I was so lazy to remember the specific of each widget of GTK and also manage them in IO monad.)

Also the architecture of my application end up with the one which is similar to "Elm Architecture" (I'm not sure you are familiar with Elm Architecture though) as in:

data Msg = Button1Press | Button2Press ..

update :: Msg -> Model -> Model

view :: Model -> Diagrams

where Elm Archtecture is essentially

update :: Msg -> Model -> Model

view :: Model -> Html

While Elm is good for web frontend application usage, html has limitation on expressiveness compared to diagrams (especially for my particular application).

I believe that there are much demand for such Ready-to-use GUI application framework for Haskell (Obviously I have been hoping for such framework ever since), and hoping to develop such framework as a haskell package on top of diagrams-2.0.

To begin with the development of the framework, I have been thinking of changing my backend from cairo + gtk to OpenGL + sdl2, and considering to develop 2D OpenGL + sdl2 backend for diagrams 2.0.

(I think GTK is overqualified for my application considering the fact that I'm only using DrawArea widget of GTK for my application, Also gtk is notorious for hard-to-install on Windows.)

Regarding to 2D OpenGL + sdl2 backend for diagrams-2.0, you already seems to have been developing them as diagrams-gl, diagrams-sdl package. 

https://github.com/cchalmers/diagrams-sdl

https://github.com/cchalmers/diagrams-gl

While 2D OpenGL backend seems to be planned, it seems to be not in active development currently.

Question:

Do you have any roadmap for the 2D OpenGL and sdl2 backend development?

I'm willing to participate if I could (Although I'm not quite sure whether I could be of any help due to my lack of knowledge in OpenGL and sdl2).

Any comments on my thought above is welcome.

Nao Fujinaga

[chalmers.c...@gmail.com]

2D OpenGL is certainly something I'd like but it turns out that using OpenGL to render 2D vector graphics is tricky. OpenGL likes drawing triangles, it doesn't do curved paths very well. It is possible to approximate Bezier curves with lots of triangles but it doesn't look that great.

I did get a nanovg backend working, (adapted from https://github.com/cocreature/diagrams-nanovg). NanoVG doesn't support a lot things I'd like like clipping and dashed paths but it's better than nothing. The only fully featured vector graphics libraries I was able to find where too big / too hard to install for what I want. I'm open to alternatives if you know anything suitable.

As it stands my plan is to get the nanovg backend in a usable state for the diagram-2.0 release just to have something. Long term, it would be nice to roll our own renderer that can handle all the features we support, but it's a lot of work. 

I guess in a about a month or two the diagrams-2.0 / diagrams-gl should be in a usable state for other people to try it out. I'll post on here once I'm at that stage, if you're looking to help it would be good if you could try it out at that point.

[Nao Fujinaga]

I don't mean to rush you, but would you let me know the current status of the development? I have not heard from you sometime and I just can't wait to try it out!

[chalmers.c...@gmail.com]

Sorry for taking so long to reply. Development is ongoing but slow. I'm now at the stage of getting all the tests for the backends working again. I guess once I've got all the backends passing the tests it'll be a stage you can start trying it out with the regular backends. This should be done in the next few weeks.

The OpenGL backend is still a bit of a mess. I'm using my own FreeType/Harfbuzz bindings for the text rendering on the 3D side and they might now be easy to install right now. The way to do animations/interactivity is also very raw. While I certainly want to get the OpenGL backend in a better state, it's not critical for diagrams-2.0 and I've been much busier than I expected so it's hard to say when I'll get round to making it better. I'll try to get in a state where people can at least install it and try out some of the examples I've made but much more than that could be a while.

[lyle...@gmail.com]

Hi Christopher,

I'm sure you've figured out a way to get rid of the backend token in the Diagram type. (The B in Diagram B.)

But, it occurred to me that it's a perfect application of Backpack, which is available as of GHC 8.2 and using new-cabal.

You can make a Diagram "signature" then make different implementations of that signature for backends. Then different parts of the same program could use different backends, by wiring up implementations using dependencies.

- Lyle

[Nao Fujinaga]

Hi Christopher,

Now I have been trying diagrams-2.0 using your diagrams-dev repository in github.

I have made sample GUI application using diagrams-2.0 + sdl2 + cairo to compare it with diagrams-1.4 + gtk2hs application:

https://github.com/wkoiking/diagrams-sdl-sample

https://github.com/wkoiking/diagrams-gtk-sample

The result was quite impressive and rendering speed seems 5-10 times faster in diagrams-2.0. So I'm currently trying to migrate my application to diagrams 2.0 (I know this is a bit too early since diagrams-2.0 is still in development but I can not wait for the release). While the migration work, I encountered some problems so I just would like some advice from you regarding these problems:

1. How can I apply a name to a diagram? The named function in diagrams-1.4 to apply name to diagram seems to be changed to Traversal of the name in diagrams-2.0 and I could not find the corresponding function in diagrams 2.0.
2. It seems the clipping functions have not been implemented yet. Is it going to be implemented any time soon?

Nao Fujinaga

2018年4月26日木曜日 15時55分30秒 UTC+9 Christopher Chalmers:

[Nao Fujinaga]

BTW, the following is the gif of the sample application by diagrams-2.0 + sdl2 + cairo I have made if anyone is interested:

https://gyazo.com/7fd212b1ffcd013e60afa44b252b8218

Nao Fujinaga

2019年3月30日土曜日 14時14分48秒 UTC+9 Nao Fujinaga:

[chalmers.c...@gmail.com]

That's great! I'm glad we're starting to get eager people using diagrams-2.0. You're gui applications look cool, I'm happy my performance improvements are noticeable in real applications.

Sorry about the change to named, when I made it I was just playing around with really thinking about it. You can still use the (.>>) operator (in Diagrams.Types.Names). Hopefully this stuff will be cleared up soon.

Which clipping functions are you missing? There's clip in Diagrams.TwoD.Attributes (can't remember why I moved it, maybe I should export it from both places).

Do keep giving feedback and asking questing, it's very helpful. Especially concerning names, we're considering giving them a complete overhaul.

[Nao Fujinaga]

Thank you for the quick and very helpful response!

> You can still use the (.>>) operator (in Diagrams.Types.Names)

I didn't know (.>>) operator. Does this operator behave the same as named function in diagrams-1.4?

> Which clipping functions are you missing? There's clip in Diagrams.TwoD.Attributes (can't remember why I moved it, maybe I should export it from both places).

I have just found that clip function you mentioned myself. I could not find it since I was searching clipBy function. Sorry for the disturbance.

> Do keep giving feedback and asking questing, it's very helpful. Especially concerning names, we're considering giving them a complete overhaul.

I'm really happy to hear that! I wish I could be of any help to this project since I have been a big fan of Diagrams for some time.

Nao Fujinaga

2019年3月30日土曜日 16時31分42秒 UTC+9 Christopher Chalmers:

[Nao Fujinaga]

I have encountered one issue:

Currently the clipping function you mentioned have the following type:

clip :: Path V2 Double -> Diagram V2 -> Diagram V2

But I would like it to have more general type so that I can clip a diagram which can be sampled, as in:

clip :: Monoid m => Path V2 Double -> QDiagram V2 Double m -> QDiagram V2 Double m

(BTW old clipBy function was clipBy :: (HasStyle a, V a ~ V2, N a ~ n, TypeableFloat n) => Path V2 n -> a -> a)

Even after the modification, at least the code seems to compile fine while I have not tried how the sampling the point outside of clip will result (I expect that should result in mzero).

PS

Is it better for me to report these issues to your github repository rather than mailing list?

Nao Fujinaga

2019年3月30日土曜日 16時31分42秒 UTC+9 Christopher Chalmers:

That's great! I'm glad we're starting to get eager people using diagrams-2.0. You're gui applications look cool, I'm happy my performance improvements are noticeable in real applications.

[chalmers.c...@gmail.com]

Yes, I believe the (.>>) operator is essentially the same as named. However, the behaviour of named things has changed a bit and still in flux so be aware. You might need to do a little research (or ask us) if you're looking to do something with the named thing.

Yeah sorry, that was just laziness on my part. I just needed to give the type signature a more general type (fixed with af9184e). Note that this doesn't affect the envelope, trace or query (just like clipBy). The fact that it's no longer on any `HasStyle a` is intentional. Before clips where part of the type (so backends might have ended up applying the same clip to each leaf instead of only applying where it was needed). Now the clip is a static Annotation, which we don't have a class for, so it's only for diagrams now. I'll probably work on porting the behaviour of the other clip functions like soon.

Yes, I think GitHub is a better place for issues like this.

[Nao Fujinaga]

> Yes, I think GitHub is a better place for issues like this.

I have encountered some issue in diagrams-2.0 and reported as below:

https://github.com/cchalmers/diagrams-dev/issues/2

I will report the issue to your repository from now on.

Thanks.

Nao Fujinaga.

2019年3月30日土曜日 22時49分47秒 UTC+9 chalmers....@gmail.com: