Copperbox revision 725.
Most of the examples have be changed to work with the Picture type. Arrow still needs doing.
Friday, July 31, 2009
Wumpus
Copperbox 724.
I've changed the Path example to use the Picture type. The Path example is the tardiest of the examples, but converting it did highlight a couple of improvements to make in Drawing.Basic so that Wumpus.PostScript can be hidden from client code at some point in the future.
I've changed the Path example to use the Picture type. The Path example is the tardiest of the examples, but converting it did highlight a couple of improvements to make in Drawing.Basic so that Wumpus.PostScript can be hidden from client code at some point in the future.
Wumpus
Copperbox revision 723.
More work on operations with the Picture type. I've updated the Basic example to build a composite Picture rather than use arbitrary monadic actions. Changing all the other examples is going to be a lot of work, and most of them aren't particularly exemplary (they are more visual tests that something works that examples of how to do something) but it will need to be done.
More work on operations with the Picture type. I've updated the Basic example to build a composite Picture rather than use arbitrary monadic actions. Changing all the other examples is going to be a lot of work, and most of them aren't particularly exemplary (they are more visual tests that something works that examples of how to do something) but it will need to be done.
Thursday, July 30, 2009
Wumpus
Copperbox revision 722.
I've sorted out the Frame module and made a type class that encompasses most of the relevant operations on frames. I suspect there will never be a lot of operations on frames in Wumpus. The most important one is coord which extracts the coordinates of a point in a frame into the standard Cartesian frame.
Something that I didn't really appreciate until today is that in points and coordinates are not synonymous in coordinate-free geometry (i.e the work of Tony DeRose and others at the University of Waterloo). This is a parallel of how vectors and points are different in affine geometry. One is free to use points as one likes in the coordinate-free approach but until they are extracted relative to a fixed frame they are considered "arbitrary".
For Wumpus this means I'm now happy with the types for creating lines that are Point -> Line. After I'd changed the Picture type to have Frame as the domain rather than Point, I was wondering what to do about the other types with Point as the domain (but where it seemed more natural) - I've concluded that they are fine.
I've sorted out the Frame module and made a type class that encompasses most of the relevant operations on frames. I suspect there will never be a lot of operations on frames in Wumpus. The most important one is coord which extracts the coordinates of a point in a frame into the standard Cartesian frame.
Something that I didn't really appreciate until today is that in points and coordinates are not synonymous in coordinate-free geometry (i.e the work of Tony DeRose and others at the University of Waterloo). This is a parallel of how vectors and points are different in affine geometry. One is free to use points as one likes in the coordinate-free approach but until they are extracted relative to a fixed frame they are considered "arbitrary".
For Wumpus this means I'm now happy with the types for creating lines that are Point -> Line. After I'd changed the Picture type to have Frame as the domain rather than Point, I was wondering what to do about the other types with Point as the domain (but where it seemed more natural) - I've concluded that they are fine.
Wumpus
Copperbox revision 721.
Minor updates - CDiagram.hs compiles again, and some type signatures have been simplified. I haven't found a way to get rid of undecidable instances in Core.Line though.
Minor updates - CDiagram.hs compiles again, and some type signatures have been simplified. I haven't found a way to get rid of undecidable instances in Core.Line though.
Wednesday, July 29, 2009
Wumpus
Copperbox revision 720.
I've added a couple of new Picture combinators, plus I've removed the code for the previous Picture type. I thought I did this with the last commit, but I'd actually commented it out.
I've added a couple of new Picture combinators, plus I've removed the code for the previous Picture type. I thought I did this with the last commit, but I'd actually commented it out.
Wumpus
Copperbox revision 719.
I've changed replaced the original Picture type with the new one. So of the replacement code (especially the functions for drawing dots) is quite convoluted, which makes me think I need some more combinators for working with frames.
I've changed replaced the original Picture type with the new one. So of the replacement code (especially the functions for drawing dots) is quite convoluted, which makes me think I need some more combinators for working with frames.
Wumpus
Copperbox revision 718.
Added more operations on the revised Picture type. Next time I'll delete the original type, but as that will result in quite a lot of changes I'd like the current code check-pointed in the repository.
Added more operations on the revised Picture type. Next time I'll delete the original type, but as that will result in quite a lot of changes I'd like the current code check-pointed in the repository.
Wumpus
Copperbox revision 717.
An experiment with a new Picture type that is a function from Frame -> PostScript rather than Point -> PostScript.
I've an intuition that the Image type in Haven (Point -> Colour) is actually equivalent to an affine frame with the caveat that the basis vectors are orthonormal: affine frames are represented by the triple (o,vec-x,vec-y) - o is the origin, vec-x and vec-y are the basis vectors; if the basis vectors are orthonormal then you get a standard grid, if they aren't orthonormal you get scaling, shearing, or rotation.
I've previously decided that a generalization of Point -> Colour doesn't work too well for PostScript (as PostScript images are discrete), but I've been stumped as to what a better type might be. Introducing Frame as the function's domain does seem to be more aligned with the coordinate free approach developed by Tony DeRose and others which is one of my reference points in designing Wumpus.
An experiment with a new Picture type that is a function from Frame -> PostScript rather than Point -> PostScript.
I've an intuition that the Image type in Haven (Point -> Colour) is actually equivalent to an affine frame with the caveat that the basis vectors are orthonormal: affine frames are represented by the triple (o,vec-x,vec-y) - o is the origin, vec-x and vec-y are the basis vectors; if the basis vectors are orthonormal then you get a standard grid, if they aren't orthonormal you get scaling, shearing, or rotation.
I've previously decided that a generalization of Point -> Colour doesn't work too well for PostScript (as PostScript images are discrete), but I've been stumped as to what a better type might be. Introducing Frame as the function's domain does seem to be more aligned with the coordinate free approach developed by Tony DeRose and others which is one of my reference points in designing Wumpus.
Tuesday, July 28, 2009
Wumpus
Copperbox revision 716.
Removed the PSSkeletons module. The worthwhile code from it has gone into the Basic module.
Removed the PSSkeletons module. The worthwhile code from it has gone into the Basic module.
Wumpus
Copperbox revision 715.
I've remade the Wumpus monad to be ReaderT over WriterT rather than StateT over WriterT.
While the original is a more accurate model of PostScript - changes to the graphics context are global (or a least delimited by gsave/grestore), the new monad allows me to control effects better. In Haskell changes are delimited by the Reader monad's local and are translated into PostScript within gsave/grestore blocks.
Also, I've gone through all the examples and made sure they compile and do something. Sometimes this has meant commenting out drawing operations that have become outdated but aren't yet replaced.
I've remade the Wumpus monad to be ReaderT over WriterT rather than StateT over WriterT.
While the original is a more accurate model of PostScript - changes to the graphics context are global (or a least delimited by gsave/grestore), the new monad allows me to control effects better. In Haskell changes are delimited by the Reader monad's local and are translated into PostScript within gsave/grestore blocks.
Also, I've gone through all the examples and made sure they compile and do something. Sometimes this has meant commenting out drawing operations that have become outdated but aren't yet replaced.
Wumpus
Copperbox revision 714.
I've generalized the bounds function to work on any type where you can extractPoints. Also I've renamed the ExtractPoints typeclass to HasPoints.
I've generalized the bounds function to work on any type where you can extractPoints. Also I've renamed the ExtractPoints typeclass to HasPoints.
Wumpus
Copperbox revision 713.
I've changed Path - it's now a simple first order datatype. Also I've extracted BoundingBox from the Polygon module and put it into a new module.
I've changed Path - it's now a simple first order datatype. Also I've extracted BoundingBox from the Polygon module and put it into a new module.
Monday, July 27, 2009
Wumpus
Copperbox revision 712.
I've removed all the 'Co' data types - CoLineSegment, CoCurve - that were functions from Point -> ...
The classic functional way of describing continuous images is type Image = Point -> Colour - this is used in Clastic, Chalkboard (with minor differences), Conal Elliott's Pan, and other programs. For continuous images the Image type can be seen as a generalization of the characteristic function (e.g type Shape = Point -> Bool) that indicates whether a point is within the boundary of a shape.
The Image type is a natural fit for continuous images - it essentially captures the type of a rendering function. But it doesn't seem to be as directly useful for discrete images built from vector primitives (in my case - PostScript). In Clastic images genuinely are functions, whereas in Wumpus they were only functions in so much as a they allowed a certain coordinate free style. For instance, generating horizontal lines could be a function hline :: Length -> (Point -> LineSegment), but line segments were always represented concretely by their start and end points. I could change to represent lines as equations, but that would have problems for rendering especially if I do the same for curves - lines would need discovering (as in polygonization and ray-tracing).
Note - I haven't changed the Picture type yet as it is more fully realized - it was 'borrowed' from the Picture type in Haven.
I've removed all the 'Co' data types - CoLineSegment, CoCurve - that were functions from Point -> ...
The classic functional way of describing continuous images is type Image = Point -> Colour - this is used in Clastic, Chalkboard (with minor differences), Conal Elliott's Pan, and other programs. For continuous images the Image type can be seen as a generalization of the characteristic function (e.g type Shape = Point -> Bool) that indicates whether a point is within the boundary of a shape.
The Image type is a natural fit for continuous images - it essentially captures the type of a rendering function. But it doesn't seem to be as directly useful for discrete images built from vector primitives (in my case - PostScript). In Clastic images genuinely are functions, whereas in Wumpus they were only functions in so much as a they allowed a certain coordinate free style. For instance, generating horizontal lines could be a function hline :: Length -> (Point -> LineSegment), but line segments were always represented concretely by their start and end points. I could change to represent lines as equations, but that would have problems for rendering especially if I do the same for curves - lines would need discovering (as in polygonization and ray-tracing).
Note - I haven't changed the Picture type yet as it is more fully realized - it was 'borrowed' from the Picture type in Haven.
Sunday, July 26, 2009
Wumpus
Copperbox revision 711.
I've added a class for approximate equality, and with it I've defined a better characteristic function for the grid drawing code.
I've added a class for approximate equality, and with it I've defined a better characteristic function for the grid drawing code.
Wumpus
Copperbox revision 710.
Some work on grids. The results currently are not satisfactory - the bound of the grid is not shown down two sides because I've got my characteristic function wrong (I'm using < rather than <= to avoid equality on doubles).
Some work on grids. The results currently are not satisfactory - the bound of the grid is not shown down two sides because I've got my characteristic function wrong (I'm using < rather than <= to avoid equality on doubles).
Saturday, July 25, 2009
Wumpus
Copperbox revision 709.
Labels are now Pictures rather than an adhoc datatype. They are drawing inside a clipping rectangle which must be supplied by the user. This is inconvenient - a user must guess the text size and check the output to make sure the text has not been clipped. But it does mean that we can have an static bounding box and can then use the picture combinators to arrange labels. The only other way to get the bounding box would be some fancy bidirectional interface to GhostScript (PostScript has the reflective capability to get the bounding box of text output), but would add dependencies and make things far too complicated.
Labels are now Pictures rather than an adhoc datatype. They are drawing inside a clipping rectangle which must be supplied by the user. This is inconvenient - a user must guess the text size and check the output to make sure the text has not been clipped. But it does mean that we can have an static bounding box and can then use the picture combinators to arrange labels. The only other way to get the bounding box would be some fancy bidirectional interface to GhostScript (PostScript has the reflective capability to get the bounding box of text output), but would add dependencies and make things far too complicated.
Friday, July 24, 2009
Wumpus
Copperbox revision 708.
Dots are now pictures. This means I can get rid of the LineBag datatype, although it does break the Grid module which I need to look at.
Dots are now pictures. This means I can get rid of the LineBag datatype, although it does break the Grid module which I need to look at.
Wumpus
Copperbox revision 707.
I've added an elementary picture combinator `below` which does the obvious and draws one picture below another. More should follow e.g. above, and it does seem to validate the utility of the Picture type.
Also I've removed the code to explicitly manage the PostScript translation matrix. Current colour and other areas which the PostScript state is shadowed on the Haskell side need thinking about too.
I've added an elementary picture combinator `below` which does the obvious and draws one picture below another. More should follow e.g. above, and it does seem to validate the utility of the Picture type.
Also I've removed the code to explicitly manage the PostScript translation matrix. Current colour and other areas which the PostScript state is shadowed on the Haskell side need thinking about too.
Thursday, July 23, 2009
Wumpus
Copperbox revision 706.
I've added a Picture datatype for compositional images. The Picture type is derived from the one in Haven. I've rather overlooked Haven as a source of inspiration, largely because the geometrical stuff is on the foreign side of the FFI, but today I read then Haven chapter in Antony Courtney's thesis today and the Picture type seems very promising. I've been struggling to avoid composing images syntactically (i.e making a union algebraic datatype of the Line, Polygon etc. types). Haven's Picture type looks like a solution.
I've added a Picture datatype for compositional images. The Picture type is derived from the one in Haven. I've rather overlooked Haven as a source of inspiration, largely because the geometrical stuff is on the foreign side of the FFI, but today I read then Haven chapter in Antony Courtney's thesis today and the Picture type seems very promising. I've been struggling to avoid composing images syntactically (i.e making a union algebraic datatype of the Line, Polygon etc. types). Haven's Picture type looks like a solution.
Wednesday, July 22, 2009
Mullein
Copperbox revision 705.
Removed some code from the Mullein branch that was unlikely to be supported / developed further.
Removed some code from the Mullein branch that was unlikely to be supported / developed further.
Mullein
Copperbox revision 703.
Minor updates on the Mullein branch.
I've added the LilyPond duration rewrite where successive durations are left unprinted if they are the same. However I don't like the code very much, and it has highlighted problems with the Duration data type and traversals within bars/beam groups, that need some thought.
Minor updates on the Mullein branch.
I've added the LilyPond duration rewrite where successive durations are left unprinted if they are the same. However I don't like the code very much, and it has highlighted problems with the Duration data type and traversals within bars/beam groups, that need some thought.
Tuesday, July 21, 2009
Mullein
Copperbox revision 701.
Work on the user guide in the Mullein branch.
The work on the user guide was actually a mini guide to the ABC format (it would be rather presumptuous to document Mullein itself as its changing so much). It's high time I started collecting my knowledge of ABC and LilyPond and how one might generate them.
Work on the user guide in the Mullein branch.
The work on the user guide was actually a mini guide to the ABC format (it would be rather presumptuous to document Mullein itself as its changing so much). It's high time I started collecting my knowledge of ABC and LilyPond and how one might generate them.
Monday, July 20, 2009
Mullein
Copperbox revision 700.
I've improved the handling of pitch respelling in the Mullein branch. There is now an fmap/Functor like type class PitchMap to access the pitch content in arbitrary structures. With this I can now traverse all the pitches in a chord or the single pitch in a note and respell them as necessary.
I've improved the handling of pitch respelling in the Mullein branch. There is now an fmap/Functor like type class PitchMap to access the pitch content in arbitrary structures. With this I can now traverse all the pitches in a chord or the single pitch in a note and respell them as necessary.
Mullein
Copperbox revision 698.
I've changed the Pitch type in the Mullein2 branch. There is now a distinction between having no accidental and having a natural accidental. I need this distinction to output valid ABC after respelling the pitches according to the key of the tune.
I've changed the Pitch type in the Mullein2 branch. There is now a distinction between having no accidental and having a natural accidental. I need this distinction to output valid ABC after respelling the pitches according to the key of the tune.
Sunday, July 19, 2009
Mullein
Copperbox revision 697.
I've added a meaningful split operation to durations in the Mullein branch. Only compound durations can be split - notes with compound durations should be printed as repeated notes with ties joining them (they aren't yet). As it seems reasonable to let them span bar lines, they need to support splitting.
I've added a meaningful split operation to durations in the Mullein branch. Only compound durations can be split - notes with compound durations should be printed as repeated notes with ties joining them (they aren't yet). As it seems reasonable to let them span bar lines, they need to support splitting.
Mullein
Copperbox revisions 695 & 696.
Added the ABC output module - duration handling is currently stubbed.
Added the ABC output module - duration handling is currently stubbed.
Mullein
Copperbox revision 694.
Mullein branch - durations are now represented with a symbolic type internally. The type just enumerates the permissible durations from longa to 128th, and doesn't allow numeric operations, so unprintable durations can't be constructed.
Mullein branch - durations are now represented with a symbolic type internally. The type just enumerates the permissible durations from longa to 128th, and doesn't allow numeric operations, so unprintable durations can't be constructed.
Saturday, July 18, 2009
Mullein
Copperbox revision 693.
First attempt at symbolic durations in the Mullein2 branch.
Durations that can be represented in scores are fairly limited - in LilyPond I think their lengths span from longa to 128th and they can be dotted and double-dotted (maybe triple dotted or more I haven't really looked). Representing them as rationals gives plenty of opportunity to create unprintable durations and allows numeric operations (+,-,etc.) that aren't defined. As I'm no longer trying to be compatible with Haskore it seems worthwhile to try representing them symbolically.
This first draft still represents durations internally as rationals - I think I ought to go further and represent then as an algebraic type.
First attempt at symbolic durations in the Mullein2 branch.
Durations that can be represented in scores are fairly limited - in LilyPond I think their lengths span from longa to 128th and they can be dotted and double-dotted (maybe triple dotted or more I haven't really looked). Representing them as rationals gives plenty of opportunity to create unprintable durations and allows numeric operations (+,-,etc.) that aren't defined. As I'm no longer trying to be compatible with Haskore it seems worthwhile to try representing them symbolically.
This first draft still represents durations internally as rationals - I think I ought to go further and represent then as an algebraic type.
Friday, July 17, 2009
Mullein
Copperbox revision 692.
I've started a branch of Mullein, to experiment with simplifying the internal syntax.
I don't like how Mullein represents musically structures larger than a bar as motifs, phrases and parts. These structures are pretty arbitrary, so it seems better to do away with them altogether and somehow print structure with functions - at its simplest this will mean adding functions to print sequences of bars and repeats. Also within a bar it would be nice to avoid the overlay syntax if the particular score doesn't use then, so I want to try and make overlays optional.
I've started a branch of Mullein, to experiment with simplifying the internal syntax.
I don't like how Mullein represents musically structures larger than a bar as motifs, phrases and parts. These structures are pretty arbitrary, so it seems better to do away with them altogether and somehow print structure with functions - at its simplest this will mean adding functions to print sequences of bars and repeats. Also within a bar it would be nice to avoid the overlay syntax if the particular score doesn't use then, so I want to try and make overlays optional.
Thursday, July 16, 2009
Mullein
Copperbox revision 691.
I've implemented new bar splitting and beam grouping algorithms based on skipping apomorphisms. The new algorithms use new datatypes for bars, beam-groups etc. that aren't yet used in the rest of the code so the example Bulgarian6 no longer works.
DataObscura has been updated as well to add some wrapped constructors.
I've implemented new bar splitting and beam grouping algorithms based on skipping apomorphisms. The new algorithms use new datatypes for bars, beam-groups etc. that aren't yet used in the rest of the code so the example Bulgarian6 no longer works.
DataObscura has been updated as well to add some wrapped constructors.
Wednesday, July 15, 2009
DataObscura
Copperbox revision 690.
I've filled the optional type to be a set of types representing the Kleene algebra. Haskell's Maybe type represents zero-or-one, I've added modules to model the other combinations: zero-or-many, one-or-many and zero-one-many.
I've filled the optional type to be a set of types representing the Kleene algebra. Haskell's Maybe type represents zero-or-one, I've added modules to model the other combinations: zero-or-many, one-or-many and zero-one-many.
Tuesday, July 14, 2009
DataObscura
Copperbox revision 689.
Working on Mullein, I wanted to be able to represent types with one-or-many elements and lists with one or more elements. I thought I'd done this already in some draft committed to Copperbox, but I couldn't find either of them, so it seems like time for a new library...
Given that the data types are really just versions of type in the hierarchical libs but with different construction patterns 'Data Obscura' seemed like a fun name.
Working on Mullein, I wanted to be able to represent types with one-or-many elements and lists with one or more elements. I thought I'd done this already in some draft committed to Copperbox, but I couldn't find either of them, so it seems like time for a new library...
Given that the data types are really just versions of type in the hierarchical libs but with different construction patterns 'Data Obscura' seemed like a fun name.
Monday, July 13, 2009
Mullein
Copperbox revision 688.
I've started a user guide for Mullein. Currently it is more for me working out the design of Mullein (writing why I'm designing it in a certain way helps the actual design) rather than help for users - as the exposed interface is likely to change drastically.
I've started a user guide for Mullein. Currently it is more for me working out the design of Mullein (writing why I'm designing it in a certain way helps the actual design) rather than help for users - as the exposed interface is likely to change drastically.
Sunday, July 12, 2009
Mullein
Copperbox revision 687.
Cosmetic changes to Mullein. I'm looking at it again and I wanted to familiarize myself with the code.
Cosmetic changes to Mullein. I'm looking at it again and I wanted to familiarize myself with the code.
Friday, July 10, 2009
Wumpus
Copperbox revisions 685 & 686.
Initial attempt at creating paths (i.e. concatenations of curves and line segments) by function composition.
The current code is fairly ugly, but I can't think of any other code bases to crib from so I'm stuck for inspiration. As far as I can tell, Clastic and other functional graphics programs that are 'functions from Point to ...' generally have the same type as the image of the function. At the moment Wumpus has functions from Point to various types of object (polygon, curve, line segment etc.), which are drawn to PostScript some time later. For paths Wumpus uses a sum of LineSegment and Curve - it generates yet more syntax rather than an image.
Initial attempt at creating paths (i.e. concatenations of curves and line segments) by function composition.
The current code is fairly ugly, but I can't think of any other code bases to crib from so I'm stuck for inspiration. As far as I can tell, Clastic and other functional graphics programs that are 'functions from Point to ...' generally have the same type as the image of the function. At the moment Wumpus has functions from Point to various types of object (polygon, curve, line segment etc.), which are drawn to PostScript some time later. For paths Wumpus uses a sum of LineSegment and Curve - it generates yet more syntax rather than an image.
Thursday, July 9, 2009
Wumpus
Copperbox revision 684.
I've removed the BasicCF module. The coordinate free types (functions from Point -> ...) are now mostly in their respective core modules like Line or Curve. The dots have gone into the Drawing.Basic module.
I've removed the BasicCF module. The coordinate free types (functions from Point -> ...) are now mostly in their respective core modules like Line or Curve. The dots have gone into the Drawing.Basic module.
Wumpus
Copperbox revision 683.
I've added a function to create bezier tildes ~, plus a bit of tidying up.
I've added a function to create bezier tildes ~, plus a bit of tidying up.
Wumpus
Copperbox revision 682.
I've made Radian a concrete type (newtype over Double) rather than a parametric type. This is so I can implement equality and ordering with an error epsilon, then at least I know what the predicates like complementary and obtuse are doing.
I've made Radian a concrete type (newtype over Double) rather than a parametric type. This is so I can implement equality and ordering with an error epsilon, then at least I know what the predicates like complementary and obtuse are doing.
Wednesday, July 8, 2009
Wumpus
Copperbox revision 681.
At last! Decent arrowheads for curves and solved by my favourite method.
The method is to really just functional decomposition - but the decomposition should be so small that the parts are obviously correct[1] and the parts should correspond to catalogued functions whenever possible (by catalogued I mean functions that exist already, say in a geometry text, rather than my own invention). In this case getting decent arrows was largely a case of recognizing I needed a bisector function that returns the besecting vector between its two arguments.
[1] I'm careless here, as I haven't been systematic in my handling of angles. It might be that angles greater then 180 degrees will cause me problems. But they do look correct...
At last! Decent arrowheads for curves and solved by my favourite method.
The method is to really just functional decomposition - but the decomposition should be so small that the parts are obviously correct[1] and the parts should correspond to catalogued functions whenever possible (by catalogued I mean functions that exist already, say in a geometry text, rather than my own invention). In this case getting decent arrows was largely a case of recognizing I needed a bisector function that returns the besecting vector between its two arguments.
[1] I'm careless here, as I haven't been systematic in my handling of angles. It might be that angles greater then 180 degrees will cause me problems. But they do look correct...
Wumpus
Copperbox revision 679.
More work on arrowheads for curves. I've got the perpendicular arrowhead working satisfactorily, after fixing a problem with vangle in the Core.Vector module. Vee arrowheads still need some work.
More work on arrowheads for curves. I've got the perpendicular arrowhead working satisfactorily, after fixing a problem with vangle in the Core.Vector module. Vee arrowheads still need some work.
Tuesday, July 7, 2009
Wumpus
Copperbox revision 678.
I've changed the type of the affine combination functions and weighted points again. I've a better idea now of how these functions should work - weights ought to be integers or rationals so they follow typical cases in affine geometry, to make examples such as p = 3/4a + 1/4b.
I've changed the type of the affine combination functions and weighted points again. I've a better idea now of how these functions should work - weights ought to be integers or rationals so they follow typical cases in affine geometry, to make examples such as p = 3/4a + 1/4b.
OpenVG binding
Copperbox revisions 675, 676 & 677.
Fixed the problem with VGHandle - the type had changed in ShivaVG 0.2.1.
Running the example now fails on Windows - runhaskell complains that the symbol _vgMask cannot be found. This is one of the several functions that weren't implemented in ShivaVG 0.2.0 and are now stubbed in 0.2.1. This makes me suspect that the runhaskell Setup.hs steps to build the Haskell binding are linking to an old library on my system, but I can't see how this can be happening.
MacOSX doesn't seem to have this problem and I'll put the 0.2 binding on Hackage once I've tested the sdist (again) on OSX.
Fixed the problem with VGHandle - the type had changed in ShivaVG 0.2.1.
Running the example now fails on Windows - runhaskell complains that the symbol _vgMask cannot be found. This is one of the several functions that weren't implemented in ShivaVG 0.2.0 and are now stubbed in 0.2.1. This makes me suspect that the runhaskell Setup.hs steps to build the Haskell binding are linking to an old library on my system, but I can't see how this can be happening.
MacOSX doesn't seem to have this problem and I'll put the 0.2 binding on Hackage once I've tested the sdist (again) on OSX.
OpenVG binding
Copperbox revision 674.
First set of changes to update the Haskell OpenVG / ShivaVG binding to work with the current release of ShivaVG - version 0.2.1.
These changes are mostly administrative - changing the copyright notice, and changing the license to BSD3. There is a bug that breaks the compilation as the VGHandle type seems to have changed, I'm about to investigate this.
First set of changes to update the Haskell OpenVG / ShivaVG binding to work with the current release of ShivaVG - version 0.2.1.
These changes are mostly administrative - changing the copyright notice, and changing the license to BSD3. There is a bug that breaks the compilation as the VGHandle type seems to have changed, I'm about to investigate this.
Monday, July 6, 2009
Wumpus
Copperbox revision 673.
I've improved and generalized the affine combination functions, as they've become a lot more important now I'm working on bezier curves. Unfortunately the other work I did today with curves hasn't got very far. Again, as soon as I switch to working on curves the coding almost stops as I scribble pages of equations trying to decode the lecture notes and papers I'm referencing.
I've improved and generalized the affine combination functions, as they've become a lot more important now I'm working on bezier curves. Unfortunately the other work I did today with curves hasn't got very far. Again, as soon as I switch to working on curves the coding almost stops as I scribble pages of equations trying to decode the lecture notes and papers I'm referencing.
Sunday, July 5, 2009
Wumpus
Copperbox revision 672.
Some more work on arrowheads for bezier curves. There's no improvement in the drawing but I have implemented some more curve functions (particularly approximating the arc length with Gravesen's algorithm).
Some more work on arrowheads for bezier curves. There's no improvement in the drawing but I have implemented some more curve functions (particularly approximating the arc length with Gravesen's algorithm).
Wumpus
Copperbox revision 671.
First attempt at adding arrowheads to bezier curves. The result is not so good with the vee of the arrowhead skewed. Currently I'm just using the tangent of the end point (via the last control point), maybe I need to be a bit more mathematically sophisticated and take a derivative of the curve instead.
First attempt at adding arrowheads to bezier curves. The result is not so good with the vee of the arrowhead skewed. Currently I'm just using the tangent of the end point (via the last control point), maybe I need to be a bit more mathematically sophisticated and take a derivative of the curve instead.
Saturday, July 4, 2009
Wumpus
Copperbox revision 670.
Commuting Diagram!
I've added an example that draws a that Haskell favourite a commuting diagram - CDiagram.hs. Plus there is quite a bit of new functionality added, primarily to work with bounding boxes.
Commuting Diagram!
I've added an example that draws a that Haskell favourite a commuting diagram - CDiagram.hs. Plus there is quite a bit of new functionality added, primarily to work with bounding boxes.
Wumpus
Copperbox revision 669.
I've changed the representation of the polygon generating functions (square, rectangle, isoscelesTriangle) so that they are functions from Point -> Polygon. This seems an improvement on the previous where they were fixed at the origin and needed a translation to be placed somewhere else.
I've changed the representation of the polygon generating functions (square, rectangle, isoscelesTriangle) so that they are functions from Point -> Polygon. This seems an improvement on the previous where they were fixed at the origin and needed a translation to be placed somewhere else.
Wumpus
Copperbox revision 668.
I've reworked the triangle arrowhead, trying to do it a more coordinate free style. However while I've commit the result, I don't think its really an improvement.
I've reworked the triangle arrowhead, trying to do it a more coordinate free style. However while I've commit the result, I don't think its really an improvement.
Friday, July 3, 2009
Wumpus
Copperbox revision 666.
I've changed the name of Core.VSExtra to Core.Geometric. While the new name is pretty arbitrary, I wanted a place in the module hierarchy to add (dependency-free) type classes - the old VSExtra suited this.
I've added a new class Congruent - unfortunately the current instance for line segments is bringing in OverlappingInstances and UndecidableInstances as I can't work out how to get the type class constraints smaller than the instance head.
I've changed the name of Core.VSExtra to Core.Geometric. While the new name is pretty arbitrary, I wanted a place in the module hierarchy to add (dependency-free) type classes - the old VSExtra suited this.
I've added a new class Congruent - unfortunately the current instance for line segments is bringing in OverlappingInstances and UndecidableInstances as I can't work out how to get the type class constraints smaller than the instance head.
Wumpus
Copperbox revision 665.
I've added a couple of predicates to the Polygon and Point modules, though I'm concerned about their numerical stability due to floating-point equality. So I don't use (==) directly on floating point numbers I cast first with toRational, but I don't know how wise this hack is.
I've added a couple of predicates to the Polygon and Point modules, though I'm concerned about their numerical stability due to floating-point equality. So I don't use (==) directly on floating point numbers I cast first with toRational, but I don't know how wise this hack is.
Thursday, July 2, 2009
Wumpus
Copperbox revision 664.
I've moved the existing polygon construction function regularPolygon into the new Polygon module and done some more tidying after all the file moves in the last commit.
I've moved the existing polygon construction function regularPolygon into the new Polygon module and done some more tidying after all the file moves in the last commit.
Wumpus
Copperbox revision 663.
I've move the PostScript modules into Wumpus.Drawing from Wumpus.Core. As Wumpus.Core is now focused on geometry Wumpus.Drawing seems a better place. Also I've added a Polygon core module.
I've move the PostScript modules into Wumpus.Drawing from Wumpus.Core. As Wumpus.Core is now focused on geometry Wumpus.Drawing seems a better place. Also I've added a Polygon core module.
Wumpus
Copperbox revision 662.
I've added an affine combination function that takes a list of weighted points rather than a pair.
I've added an affine combination function that takes a list of weighted points rather than a pair.
Wumpus
Copperbox revision 661.
Added an affine combination operation to weighted points, though it probably needs generalizing to lists of points (currently it operates on pairs of points).
Added an affine combination operation to weighted points, though it probably needs generalizing to lists of points (currently it operates on pairs of points).
Wednesday, July 1, 2009
Wumpus
Copperbox revision 660.
Added a distinct Radian type (a newtype wrapper over parametric on some numeric type a).
Added a distinct Radian type (a newtype wrapper over parametric on some numeric type a).
Wumpus
Copperbox revision 659.
Added center-markers to arrow drawing (center markers are arrow heads in the center of a line).
Added center-markers to arrow drawing (center markers are arrow heads in the center of a line).
stream-calculus
Copperbox revision 658.
I've added quite a few of tests, which found a bug in the composition operator <.>.
I've added quite a few of tests, which found a bug in the composition operator <.>.
Subscribe to:
Posts (Atom)
About Me
- Stephen Tetley
- Disambiguating biog as there are a few Stephen Tetley's in the world. I'm neither a cage fighter or yachtsman. I studied Fine Art in the nineties (foundation Bradford 1992, degree Cheltenham 1992 - 95) then Computing part-time at Leeds Met graduating in 2003. I'm the Stephen Tetley on Haskell Cafe and Stackoverflow.