Core types and utilities
Home Page: https://diagrams.github.io/
License: Other
The core modules defining the basic data structures and algorithms for diagrams, a Haskell embedded domain-specific language for compositional, declarative drawing.
(Imported from http://code.google.com/p/diagrams/issues/detail?id=35. Original issue from [email protected] on June 13, 2011, 01:03:58 AM UTC)
In order to get consistent sizes between multiple diagrams, some support for absolute sizes would be useful. For these situations, the backend should have an option to only center and not resize the diagram.
(Imported from http://code.google.com/p/diagrams/issues/detail?id=80. Original issue from [email protected] on April 16, 2012, 02:05:29 PM UTC)
cairo and SVG both support a notion of "grouping" so that grouped things will have their transparency set as a group -- i.e. as if everything were drawn first and then the resulting bitmap made transparent. It would be nice if diagrams supported this as well, though it's not entirely obvious how this should work. At a minimum we need to work out how to expose more tree structure to backends first.
(Imported from http://code.google.com/p/diagrams/issues/detail?id=62. Original issue from [email protected] on December 22, 2011, 12:13:00 AM UTC)
What steps will reproduce the problem?
What version of the product are you using? On what operating system?
0.4 , os x lion
The <a> element generated by the href function in diagrams-core contains a xlink:href attribute.
However, the xlink namespace has been deprecated since SVG 2.
Currently, every time an Envelope is queried it has to do O(n) work (where n is the number of primitives) since it has to evaluate a tree of n-1 applications of max. Envelopes ought to be memoized to cut down on the asymptotic time needed to e.g. lay out a list of diagrams using cat.
Today I tried to build diagrams-core with the dependency versions listed as lower bounds in the .cabal. Results below. Now I'm looking for some guidelines for deciding which versions to bump, and when to instead change the code to build with older versions.
My own feeling is that it's good to support the current version and at least one earlier; but supporting older versions is less important if the current version has been out a long time (vector-space) and more for frequent releases (semigroups).
Containers is the only non-obvious one here. But I'd like general advice so I can do the same for diagrams-lib.
{-# LANGUAGE NoMonomorphismRestriction #-}
import Diagrams.Prelude
aCircleNamedBob :: D R2
aCircleNamedBob = circle 1 # named "bob"
whatIsTheNameOfThisCircle
= case lookupName "bob" aCircleNamedBob of
Nothing -> error "this doesn't happen"
Just c -> getSub c
itTurnsOutTheCircleAboveHasNoName
= case lookupName "bob" whatIsTheNameOfThisCircle of
Nothing -> putStrLn "wah!"
Just bob -> putStrLn "found bob"
main = itTurnsOutTheCircleAboveHasNoNameI would argue that the above program ought to print found bob, though I am open to other opinions. This bit me when building some animations via keyframing---the diagrams used to build the actual animation are looked-up subdiagrams, so one can no longer use frames of the animation as keyframes for building further animations (since there are no longer any names to match up).
I've been trying to understand the inner workings of diagrams-core when I ran into this nugget ;)
diagrams-core/src/Diagrams/Core/Envelope.hs
Line 157 in 1e9e2cc
Any possibility @byorgey, @cchalmers or someone else could elaborate on how this works?
(Imported from http://code.google.com/p/diagrams/issues/detail?id=65. Original issue from [email protected] on January 23, 2012, 04:01:35 AM UTC)
What steps will reproduce the problem?
Prelude Diagrams.Prelude> :t transform (translation zeroV) . P
transform (translation zeroV) . P
:: (Data.MemoTrie.HasTrie (Data.Basis.Basis a),
Data.MemoTrie.HasTrie (Data.Basis.Basis (V (Point a))),
Data.Basis.HasBasis a,
Data.Basis.HasBasis (V (Point a))) =>
a -> Point a
Prelude Diagrams.Prelude> :m + Graphics.Rendering.Diagrams.Points
Prelude Diagrams.Prelude Graphics.Rendering.Diagrams.Points> :t transform (translation zeroV) . P
transform (translation zeroV) . P
:: (Data.MemoTrie.HasTrie (Data.Basis.Basis a),
Data.Basis.HasBasis a) =>
a -> Point a
(Imported from http://code.google.com/p/diagrams/issues/detail?id=61. Original issue from [email protected] on November 13, 2011, 08:34:39 PM UTC)
I've never really liked the locution "bounding function", and now that Taejo is working on an implementation of "boundary functions" (to give you points actually on the boundary), the terminology situation looks quite dire. I propose renaming "bounding function" to "envelope" and calling the new "boundary function" just the "boundary".
Concretely, this would mean changing
These changes would be annoying and tedious, but I fear otherwise users will just be confused. Suggestions for alternative names are also welcome.
So I am learning diagrams for like 2 days. At first it was smooth sailing, but then I decided to
split some diagram definitions out from the Main module. This is when I met type errors like
these:
src/Draw.hs:10:74: error:
• Couldn't match type ‘V t0’ with ‘V2’
arising from a use of ‘circle’
The type variable ‘t0’ is ambiguous
• In the expression: circle 0.1
In the expression:
let r = (sqrt $ fromIntegral $ Graph.size graph :: Double)
in circle 0.1
In an equation for ‘node’:
node
= let r = (sqrt $ fromIntegral $ Graph.size graph :: Double)
in circle 0.1
• Relevant bindings include node :: t0 (bound at src/Draw.hs:10:5)
src/Draw.hs:1:1: error:
solveWanteds: too many iterations (limit = 4)
Unsolved: WC {wc_simple =
[W] $dTrailLike_a27Vn {0}:: TrailLike
(QDiagram backEnd s0 s1 Any) (CDictCan)
[D] _ {2}:: base-4.12.0.0:Data.Typeable.Internal.Typeable
s0 (CDictCan)
[D] _ {2}:: RealFloat s0 (CDictCan(psc))
[D] _ {1}:: Renderable (Path V2 s0) backEnd (CDictCan(psc))
[WD] $dFloating_a27Vo {2}:: Floating s0 (CDictCan)
[WD] $dOrd_a27Vp {2}:: Ord s0 (CDictCan)
[W] $dMetric_a27Vq {1}:: Metric s0 (CDictCan)
[WD] $dFractional_a27Vr {0}:: Fractional s0 (CDictCan)
[D] _ {0}:: Num s0 (CDictCan)
[D] _ {2}:: Eq s0 (CDictCan)
[D] _ {2}:: RealFrac s0 (CDictCan)
[D] _ {2}:: Real s0 (CDictCan)
[WD] hole{co_a27Vk} {8}:: s0 ~ V2 (CNonCanonical)}
Set limit with -fconstraint-solver-iterations=n; n=0 for no limit
I would probably be struggling with them for a lot longer, have I not found this awesome Stack
Overflow answer from Daniel @bergey. In short, there is defined a type synonym like this:
type Back b = (V b ~ V2, N b ~ Double,
Renderable (Path V2 Double) b, Renderable (Text Double) b)
dia2 :: Back b => Diagram b
dia2 = circle 1 # fc blue
I tried it and it actually solves all those type errors!
I understand that this type synonym only covers 2D back ends. But is it not nevertheless awesome?
I propose that type synonyms like this are included in Diagrams.Prelude and written about in the
awesome official manual.
This is especially useful for drop shadows.
See SVG spec: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feGaussianBlur
(Imported from http://code.google.com/p/diagrams/issues/detail?id=56. Original issue from [email protected] on September 23, 2011, 10:58:07 PM UTC)
We now use the term "query", rather than "annotation", to refer to the function assigning monoidal values to points in a diagram, so it is odd to still have the type called AnnDiagram. QDiagram is shorter anyway.
Update user manual to match.
To make embedded hyperlinks (created via the href function) in an SVG clickable within a web page, the <object data="path-to-file.svg"> element must be used instead of the <img src="path-to-file.svg"> element. The links are not clickable if the <img> element is used, although if the SVG file is opened on its own in a new browser tab (outside of embedding in a HTML page), the links are clickable.
However, when using the <object> element, the SVG element exists in its own "iframe". If a hyperlink is clicked, only the iframe content changes, rather than navigating the root page to the link destination.
This behavior can be overridden with the target="_top" attribute (see StackOverflow answer). However, since I haven't seen a way to specify the target attribute via the diagrams API, I ended up modifying the <a> elements in the SVG dynamically when the page loads:
var svg_element = document.getElementById("my-svg-element");
var svg_document = svg_element.contentDocument;
var anchor_elements = svg_document.getElementsByTagName("a");
for (var i=0; i<anchor_elements.length; i++) {
anchor_elements[i].setAttribute("target", "_top");
}
Note that this dynamic solution does not work when testing locally, due to browser security policy; in Chrome, I observe the following error message:
Uncaught SecurityError: Failed to read the 'contentDocument' property from 'HTMLObjectElement': Blocked a frame with origin "null" from accessing a frame with origin "null". Protocols, domains, and ports must match.
This can be bypassed by executing Google Chrome with the --allow-file-access-from-files command-line option.
(Imported from http://code.google.com/p/diagrams/issues/detail?id=41. Original issue from [email protected] on August 30, 2011, 02:39:41 PM UTC)
What steps will reproduce the problem?
Either an error message telling that .jpg filetype is unsupported or a foo.pdf that contains
image instead of blank
(Imported from http://code.google.com/p/diagrams/issues/detail?id=34. Original issue from [email protected] on June 10, 2011, 05:18:21 AM UTC)
For example, consider
(circle 2 |||
square 1.5 # rotateBy (1/8) # withBounds (square 1 :: Diagram Cairo R2))
which should display a circle next to a slightly overlapping diamond. Instead the output is mostly blank (with a hint of a line on the left).
The problem is that a Forgetful monoid is not the right way to override u annotations traveling up the diagram tree (such as bounds). A Forgetful value ends up annihilating not only u values from below it in the tree, but also any from subtrees to the right.
Perhaps the solution is to allow applying extra u annotations both on the left and the right, then making a special monoid (like Forgetful) that can annihilate a "bracketed" section. A ForgetR value kills values to its right, and ForgetL kills to its left, and when they meet they turn into the identity.
There's three different types of Attribute but all attributes can be used with the standard Attribute.
It's an easy mistake to wrap up an attribute incorrectly, I've seen (and done) it a few times. After spending over an hour debugging to find out splitAttr does this too I want this to be fixed :)
One way is to use data kinds:
data AttrKind = Attr | MAttr | TAttr
class AttributesClass where
type AttrType :: AttrKind
applyAttribute :: (AttributeClass a, AttrType a ~ Attr, HasStyle d) => a -> d -> d
applyTAttribute :: (AttributeClass a, AttrType a ~ TAttr, HasStyle d) => a -> d -> d
atAttr :: (AttributeClass a, AttrType a ~ Attr) :: Lens' (Style v n) (Maybe a)
I defined some unique diagram and I want to show it to a friend. If I rasterize (or vectorize) it, it will inevitably lose some of its wondrous qualities. I see that a diagram is a complicated data type, so I am not sure how to go about this task.
(Imported from http://code.google.com/p/diagrams/issues/detail?id=43. Original issue from [email protected] on September 2, 2011, 07:58:27 PM UTC)
We need generic tools for taking diagrams code and turning it into images, which can be called either as a library or from the command line. There is already code for doing this in the diagrams-hint project, as well as in two places in the diagrams-doc repository (one for building diagrams in the web gallery, the other for building inline diagrams in the documentation). This code ought to be factored out into one library+executable that provides a diagram-building service. Perhaps the library should be in one package which is somehow backend-agnostic; and we could then have one package providing an executable for each particular backend.
Currently, the explanation of Envelope in its Haddock documentation is horrible: it uses a bunch of math and then insults the reader. The reference to Galois connections should be taken out and the description improved to be more readable (while still being technically accurate). One starting point might be the explanation of envelopes in the monoids pearl.
(Imported from http://code.google.com/p/diagrams/issues/detail?id=73. Original issue from [email protected] on March 11, 2012, 05:14:51 PM UTC)
Hi,
All of the Backends that I have seen so far flatten the UD-tree to produce output. Using a program like Inkscape to further edit an SVG image, it would be better to preserve this structure.
I also need to have such a structure to make a 3d-Backend. At first I aimed at WebGL using SceneJS, for which I need a SceneGraph (a tree structure). It seems easier to first make a Backend with lambdacubeengine (I roughly understand how the scenegraph works there) and then involve the other people here on the mailing list for the right structures for 3d.
The announcement for diagrams-0.5 mentions a new SVG-Backend. Is it preserving the structure? If yes, I would like to see the code.
Documentation about UD-trees would also help a lot.
We should look into adding a Typeable constraint, in order to be able to cast things out of Prim wrappers. On the one hand, one could argue that you "shouldn't do that" and that you could just write a backend... but that's probably a pretty weak argument (it's impossible to predict how people will want to use diagrams) and adding a Typeable constraint and some convenience functions for extracting primitives from diagrams wouldn't actually be very difficult.
Relevant IRC conversation:
(07:03) < gordon88> Hi all! let x = foobar :: Prim NullBackend R2. I know it's a Path R2. How do I extract the path from the Prim with an ordinary function?
(07:05) < gordon88> writing a backend instance just for extracting the content of a primitive sounds insane to me
(07:09) < gordon88> so I'd like to have something like a cast, is it possible in spite of the wall of typeclass-maddness that is going on?
(07:38) < fryguybob> gordon88: What are you doing that is forcing the type of foobar to be Prim?
(07:40) < gordon88> foobar d = (prims d !! 0) (but with a transform thrown in)
(07:41) < fryguybob> gordon88: Perhaps you could make the parameter d be something PathLike instead of a Diagram?
(07:42) < gordon88> basically, would just like to map prims to a more deeply embedded format, suitable for further processing. I'll investigate that
(07:42) < fryguybob> gordon88: By the way we do want to allow for more interesting queries on diagrams that should let you extract specific parts of the diagram.
(07:43) < fryguybob> gordon88: If that is the case, perhaps you really do want to write a backend.
(07:43) < fryguybob> gordon88: It isn't too complicated.
(07:44) < gordon88> yes, that's what I had to do and did. but it's a bit insane
(07:45) < gordon88> (conceptually really ugly imho)
(07:47) < fryguybob> gordon88: Sure. I think we could provide some sort of extractPaths :: Diagram b v -> Path v which gives absolute paths in order and ignores the styles.
(Imported from http://code.google.com/p/diagrams/issues/detail?id=7. Original issue from [email protected] on December 24, 2010, 10:15:48 PM UTC)
See the attached test file.
The ellipse is rotated the wrong way and intersects with the square. Note that adding a rotation to the square (even a very small one) causes the ellipse to suddenly flip the correct way around and everything seems correct.
This comment ends mid-sentence, and I'm not sure how to finish it:
-- A minimal complete definition consists of 'Result', 'Options',
-- and 'renderRTree' (though most backends will want to implement
-- 'adjustDia' as well; the default definition does nothing and is probably
class HasLinearMap v => Backend b v wherehttps://github.com/diagrams/diagrams-core/blob/master/src/Diagrams/Core/Types.hs#L875
(Imported from http://code.google.com/p/diagrams/issues/detail?id=4. Original issue from [email protected] on December 23, 2010, 10:20:15 PM UTC)
Need to add Haddock documentation to a bunch of the core and standard libraries.
Could the (patch) release be made with that fix?
I made a revision for 1.4.1 so there aren't an install plan lens-4.16 and diagrams-1.4 for GHC-7.8/7.6 now. (other diagrams-core-1.4 versions have lens <4.16).
For diagrams-core:
Is there a branch I should be looking at? Or another repo?
The build seems to succeed fine, it's just a matter of bumping the upper version bound in the Cabal file(s).
(Imported from http://code.google.com/p/diagrams/issues/detail?id=67. Original issue from [email protected] on February 20, 2012, 03:18:29 PM UTC)
The following two commands give slightly different output:
The only difference in the commands being the resolution of the final
PNG image, this shouldn't be so. The most noticable difference is the
blank triangle enclosed by the 'A' and the rectangle lines.
I'm using Diagrams 0.4 via cabal on Debian "testing".
A thought after the discussion on #diagrams:
Maybe we need a way of specifying final size explicitly? In TeX,
there's a way of rendering a font at a given resolution and then scale
it: I can either use "cmr12" or "cmr10 at 12pt", which both give fonts
of the same height, but slightly different characters.
Given that TeX knows the size on paper (and Diagrams doesn't), that
might be what we need. How about a way of specifying either
resolution (as in pixels per inch) or the printed size of the final
output? The latter would allow my two examples to look exactly the
same since the printed size is the same, only the number of pixels
changes.
Any chance of a Hackage release with 7.10 compatibility? We need new releases of
as well as
And moreover the upper bound on lens needs to be relaxed to allow for version 4.9.
I just had a hard time debugging a problem here; the reason was that
newtype WordN = WordN Int deriving (Show, Ord, Eq, Typeable, IsName)
did not make WordN 1 and 1 :: Int different names. The proper code would be
newtype WordN = WordN Int deriving (Show, Ord, Eq, Typeable)
instance IsName
I think the documentation of IsName should comment on that, and maybe give the latter as the suggested way to have dedicated names.
For completeness' sake it might be nice to add a function to Diagrams.Core.Transform which converts from a "matrix" (probably a list of vectors, one for each basis element, + a vector for the translation component) to a Transformation. Note, however, this requires being able to perform general matrix inversion. Perhaps we could use http://hackage.haskell.org/package/bed-and-breakfast, not sure how many new dependencies that would pull in.
(Imported from http://code.google.com/p/diagrams/issues/detail?id=55. Original issue from [email protected] on September 23, 2011, 10:42:16 PM UTC)
This has several benefits:
Of course, the downside is that if all you want is the point you have to use a projection function to get it out. But you already had to pattern match on a pair to get at it anyway, so maybe this isn't a downside at all -- with a projection function you don't have to remember which of the two components comes first in the tuple!
Don't forget to update the user manual to match.
Currently there is no functionality to let you modify a named subdiagram. The problem is that name maps are represented as just a finite map from names to subdiagrams---in particular the information about where a subdiagram sits within the tree corresponding to its parent diagram is not stored. One idea is to store along with each subdiagram the path from the root to the subdiagram. Modifying a given subdiagram is then just a matter of following the path into the tree, replacing the subdiagram, and rebuilding the spine of the tree (along upwards monoidal annotations) along the path. It seems like this should work in principle though there may be some trickiness involved that I haven't thought of.
>>> radius unitX (circle 1 :: D R2)
1.1102230246251565e-16
wat.
See this discussion for context.
(Imported from http://code.google.com/p/diagrams/issues/detail?id=89. Original issue from [email protected] on August 4, 2012, 05:52:42 PM UTC)
What steps will reproduce the problem?
What is the expected output? What do you see instead?
"On the left is an untransformed circle drawn with a line 0.1 units thick. The next circle is a scaled version of the first: notice how the line thickness is the same. The third circle was produced by first freezing, then scaling the first circle, resulting in a line twice as thick. The last two circles illustrate a non-uniform scale applied to an unfrozen circle (which is drawn with a uniform line) and to a frozen one (in which the line gets thicker and thinner according to the non-uniform scale)."
Sadly the line thickness is the same between the frozen and unfrozen versions.
What version of the product are you using? On what operating system?
OSX Snow Leopard (10.6), newest diagrams (0.5).
Please provide any additional information below.
Discovered at hac-phi.
See https://groups.google.com/d/topic/diagrams-discuss/X1biQvpM-Vs/discussion for some discussion and motivation.
We would like to update lens to version 4.x in NixOS, but this update would cause trouble with diagrams-core:
src/Diagrams/Core/Transform.hs:279:16:
`wrapped' is not a (visible) method of class `Wrapped'
The complete build log is at http://hydra.cryp.to/build/41357/nixlog/1/raw. Is there an easy way to fix that?
(Imported from http://code.google.com/p/diagrams/issues/detail?id=1. Original issue from [email protected] on December 23, 2010, 10:15:17 PM UTC)
Currently there are some ad-hoc tests in the cairo repo, but we ought to start developing some more principled test suites in the core and lib repos.
(Imported from http://code.google.com/p/diagrams/issues/detail?id=32. Original issue from [email protected] on May 24, 2011, 10:09:35 PM UTC)
I was surprised today to find that
hcat' with {sep = 1} [square, mempty, square]
and
hcat' with {sep = 1} [square, square]
produce the same output. However, the first ought to produce two squares with two units of space between them: one unit between the first square and mempty, and one unit between mempty and the second square.
The impetus for this ticket is the unfortunate code
scale :: (Transformable t, Fractional (Scalar (V t)), Eq (Scalar (V t)))
=> Scalar (V t) -> t -> t
scale 0 = error "scale by zero! Halp!" -- XXX what should be done here?(currently found here: https://github.com/diagrams/diagrams-core/blob/master/src/Diagrams/Core/Transform.hs#L286).
What should be done, indeed?
One idea (from @mgsloan, in a comment here), is to add a tzero method to Transformable, like
class Transformable t where
...
tzero :: twhere tzero is defined to be the result of applying a singular transformation.
It also occurs to me we might be able to move this even closer to the source by having a special representation for singular transformations. Then tzero is implicit in the fact that Transformable instances have to decide what to do about singular transformations.
One important thing to note is that not all singular transformations are equal. (To be clear, by "singular" I mean "linear transformation whose corresponding matrix is non-invertible".) For example, scale 0 and scaleX 0 are both singular, but they are not the same and it may be useful to distinguish them. For example, scaleX 0 can usefully be applied to any Path R2 (resulting in the "projection" of the path onto the y-axis). But scale 0 and scaleX 0 have the same result on Diagrams (that is, currently, bottom; but ideally, mempty).
(Imported from http://code.google.com/p/diagrams/issues/detail?id=81. Original issue from [email protected] on April 29, 2012, 02:28:27 AM UTC)
The Transform module in diagrams-core ought to export function(s) for converting a Transformation into a matrix form. It's generally useful and not difficult. See the cairo backend for an example of how it's done for T2:
To make it work generically over the vector space requires a tiny bit more work -- i.e. get a list of basis vectors and then apply the transformation to them. Maybe it ought to result in a Map from basis vectors to result vectors, plus an extra vector representing translation.
We can then also put a specialized version for T2 (and for T3) into diagrams-lib.
Running cabal install diagrams fails with the following:
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: diagrams-1.3.0.1 (user goal)
trying: base-4.9.0.0/installed-4.9... (dependency of diagrams-svg-1.4.0.1)
next goal: diagrams-contrib (dependency of diagrams-1.3.0.1)
rejecting: diagrams-contrib-1.3.0.10, diagrams-contrib-1.3.0.9,
diagrams-contrib-1.3.0.8, diagrams-contrib-1.3.0.7, diagrams-contrib-1.3.0.6,
diagrams-contrib-1.3.0.5, diagrams-contrib-1.3.0.4, diagrams-contrib-1.3.0.3,
diagrams-contrib-1.3.0.2, diagrams-contrib-1.3.0.1, diagrams-contrib-1.3.0
(conflict: base==4.9.0.0/installed-4.9..., diagrams-contrib => base>=4.2 &&
<4.9)
rejecting: diagrams-contrib-1.1.2.6, diagrams-contrib-1.1.2.5,
diagrams-contrib-1.1.2.4, diagrams-contrib-1.1.2.3, diagrams-contrib-1.1.2.2,
diagrams-contrib-1.1.2.1, diagrams-contrib-1.1.2, diagrams-contrib-1.1.1.5,
diagrams-contrib-1.1.1.4, diagrams-contrib-1.1.1.3, diagrams-contrib-1.1.1.2,
diagrams-contrib-1.1.1.1, diagrams-contrib-1.1.1, diagrams-contrib-1.1.0.1,
diagrams-contrib-1.1, diagrams-contrib-1.0.0.1, diagrams-contrib-1.0,
diagrams-contrib-0.7, diagrams-contrib-0.6.1, diagrams-contrib-0.6.0.4,
diagrams-contrib-0.6.0.3, diagrams-contrib-0.6.0.2, diagrams-contrib-0.6.0.1,
diagrams-contrib-0.6, diagrams-contrib-0.1.1.1, diagrams-contrib-0.1.1.0,
diagrams-contrib-0.1.0.0 (conflict: diagrams => diagrams-contrib>=1.3 && <1.4)
Dependency tree exhaustively searched.
Is this something to do with the fact that I'm running the latest GHC (version 8.0.1 on OSX) ?
Any workarounds?
Update
I got the 'hello-world' (drawing a unit-circle) program to work by using the stack build system instead (which picked the lts-6.2 & hence GHC version 7.10.3 by default)
(Imported from http://code.google.com/p/diagrams/issues/detail?id=15. Original issue from [email protected] on April 2, 2011, 05:58:00 PM UTC)
Currently when composing diagrams, applying transformations, etc. we forget all structure and just flatten everything into a list of primitives paired with attributes. It would be much nicer to retain as much structure as possible, so we end up with a tree where leaves are primitives, and internal nodes correspond to composition of diagrams, transformations, or applications of attributes. The transformation and set of attributes corresponding to any particular leaf node can be reconstructed by computing an appropriate mconcat along the path from the root.
Benefits include:
(Imported from http://code.google.com/p/diagrams/issues/detail?id=79. Original issue from [email protected] on April 9, 2012, 12:14:09 PM UTC)
newtype D2 a = D2 (a, a)
type R2 = D2 Double
Stackage nightly doesn't have the diagrams packages, due to the lens upper bound. (This applies elsewhere, too, e.g. diagrams-lib, but...) See also #97 (which seems closable).
(Imported from http://code.google.com/p/diagrams/issues/detail?id=39. Original issue from [email protected] on July 25, 2011, 06:27:00 AM UTC)
The tutorial (http://projects.haskell.org/diagrams/tutorial/DiagramsTutorial.html) contains links into an old version of the diagrams package.
For example, the links for Diagrams.Attributes, Diagrams.TwoD.Combinators, Diagrams.TwoD.Align and Diagrams.Prelude direct you to the 0.1 version of the package.
Hi,
I tried to package diagrams-core in NixOS, but failed because we have updated to monoid-extras 0.3.x already, which diagrams-core doesn't support:
Building diagrams-core-0.6.0.2...
Preprocessing library diagrams-core-0.6.0.2...
src/Diagrams/Core/Trace.hs:48:18:
Could not find module `Data.Monoid.PosInf'
Perhaps you meant Data.Monoid.Inf (from monoid-extras-0.3.0.0)
Use -v to see a list of the files searched for.
Is there maybe a simple fix for this issue?
Hello, could you upload a new release on Hackage to be able to compile the diagrams-* libraries with GHC 8.8.1?
Thanks for the great work!
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.