Copperbox revision 1389.
I've implemented scatter plots in the new style. Again it seems an improvement, but I haven't looked at background grids yet, so I haven't removed the old code.
Monday, May 31, 2010
Sunday, May 30, 2010
PSC
Copperbox revision 1387.
Some reworking to get grids. I haven't changed the Geom data type as much as I was expecting to. Maybe it will still need re-working though, as the grid code is very rough.
Some reworking to get grids. I haven't changed the Geom data type as much as I was expecting to. Maybe it will still need re-working though, as the grid code is very rough.
Saturday, May 29, 2010
PSC
Copperbox revision 1386.
This one is a checkpoint before I look to change the Geom type in RenderMonad.
Currently, I'm finding it a bit confusing as to whether I'm using picture coordinates (of the output) or coordinates of the input (before rescaling and within the axes ranges). I'll have to do something to make the distinction clearer.
This one is a checkpoint before I look to change the Geom type in RenderMonad.
Currently, I'm finding it a bit confusing as to whether I'm using picture coordinates (of the output) or coordinates of the input (before rescaling and within the axes ranges). I'll have to do something to make the distinction clearer.
PSC
Copperbox revision 1385.
Some tidying up of the axis code. I've reworked the data types a bit so the font properties are common for the x and y axes.
Some tidying up of the axis code. I've reworked the data types a bit so the font properties are common for the x and y axes.
PSC
Copperbox revision 1384.
Adding y-axis to scatter plots and sorted out the coordinates so both axes draw close to the origin.
Friday, May 28, 2010
Thursday, May 27, 2010
PSC
Copperbox revision 1382.
I've changed the scatter plot to use the monadic machinery. This means I should now be able to add multiple layers relatively easily.
I've changed the scatter plot to use the monadic machinery. This means I should now be able to add multiple layers relatively easily.
PSC
Copperbox revision 1381.
More reworking, I've made the rescaling calculation a bit simpler. This also means that the API can support a slightly simpler way of mandating ranges.
More reworking, I've made the rescaling calculation a bit simpler. This also means that the API can support a slightly simpler way of mandating ranges.
Wednesday, May 26, 2010
PSC
Copperbox revision 1380.
I've moved the Render monad into a separate module so it can be used by the scatter plot and other charts when I add them.
I've moved the Render monad into a separate module so it can be used by the scatter plot and other charts when I add them.
PSC
Copperbox revision 1379.
I've reworked the Sparkline module to use a reader / logger monad. Otherwise the functions were taking too many parameters to handle the drawing properties and the rescaling functions.
I've reworked the Sparkline module to use a reader / logger monad. Otherwise the functions were taking too many parameters to handle the drawing properties and the rescaling functions.
Tuesday, May 25, 2010
PSC
Copperbox revision 1378.
More work on sparklines. I've made the length of the spark line depend on the word_length attribute rather than the number of points. The number of points wouldn't be very good for many examples in Edward Tufte's Beautiful Evidence, word length still has correspondence with the idea that a sparkline is an in-text dataword.
I'll look at plotting multiple lines soon, this will mean some revision of the SparkLineProps data type.
More work on sparklines. I've made the length of the spark line depend on the word_length attribute rather than the number of points. The number of points wouldn't be very good for many examples in Edward Tufte's Beautiful Evidence, word length still has correspondence with the idea that a sparkline is an in-text dataword.
I'll look at plotting multiple lines soon, this will mean some revision of the SparkLineProps data type.
PSC
Copperbox revision 1377.
I've improved the spark line module and worked out how I want to control the size of the drawing and where the responsibility lies in the API for interpolating the data into a drawable range. Next, I'll have give the implementation some style as it is still pretty rough.
How it works:
The drawing size is mind-full of purpose of sparklines to be datawords in Edward Tufte's terminology.
Y-values are drawn as percentages of the font height, the client should supply a function that interpolates the y-value into the range [0.0 .. 100.0].
Each point is considered a letter, so the x-value is scaled according to that. Again the client must supply an interpolating function.
I've improved the spark line module and worked out how I want to control the size of the drawing and where the responsibility lies in the API for interpolating the data into a drawable range. Next, I'll have give the implementation some style as it is still pretty rough.
How it works:
The drawing size is mind-full of purpose of sparklines to be datawords in Edward Tufte's terminology.
Y-values are drawn as percentages of the font height, the client should supply a function that interpolates the y-value into the range [0.0 .. 100.0].
Each point is considered a letter, so the x-value is scaled according to that. Again the client must supply an interpolating function.
Monday, May 24, 2010
poor small chart (PSC)
Copperbox revision 1376.
I've started a new library - Poor Small Chart - for charting on top of wumpus. I've no intention to make the library particularly comprehensive - hence the name. It was going to be Poor Man's Chart, but that didn't seem very inclusive, so I called it Poor Small Chart after the record label PSF. But then I checked on the internet and PSF actually stands for Poor Strong Factory not Poor Small Factory...
I'm going to avoid using wumpus-extra as it is still too much in flux. This may further limit the scope of PSC.
I've started a new library - Poor Small Chart - for charting on top of wumpus. I've no intention to make the library particularly comprehensive - hence the name. It was going to be Poor Man's Chart, but that didn't seem very inclusive, so I called it Poor Small Chart after the record label PSF. But then I checked on the internet and PSF actually stands for Poor Strong Factory not Poor Small Factory...
I'm going to avoid using wumpus-extra as it is still too much in flux. This may further limit the scope of PSC.
wumpus-core-0.19.0, wumpus-extra-0.12.0
Copperbox revision 1375.
I've made a new release of wumpus-core - there are quite a few changes between 0.18.0 and 0.19.0, so rather than add more, it seems wise to release the current one.
A twinned release of wumpus-extra is on the Copperbox downloads page.
I've made a new release of wumpus-core - there are quite a few changes between 0.18.0 and 0.19.0, so rather than add more, it seems wise to release the current one.
A twinned release of wumpus-extra is on the Copperbox downloads page.
Sunday, May 23, 2010
wumpus-extra
Copperbox revision 1374.
I'm looking at drawing arrow tips again. Rather than use the old code, which wasn't very good, I've started a new sub-library Wumpus.Extra.Arrow.
I'm looking at drawing arrow tips again. Rather than use the old code, which wasn't very good, I've started a new sub-library Wumpus.Extra.Arrow.
wumpus-extra
Copperbox revision 1373.
I've updated the ShapesPic example now that drawing in wumpus-core respects zorder.
I've updated the ShapesPic example now that drawing in wumpus-core respects zorder.
wumpus-core
Copperbox revision 1372.
I've added in the OneList module from Neume, and fixed the zorder bug.
I've added in the OneList module from Neume, and fixed the zorder bug.
wumpus-core
Copperbox revision 1371.
I've changed frameMulti so that the order the list is drawn corresponds to the zorder of the drawing - i.e. the front of the list is the top layer of the drawing, the tail of the list the bottom.
UPDATE - actually I haven't - the changes don't work. This will need some more work/thought as it might be better to change how the list is drawn rather than the obvious fix of reversing it...
I've changed frameMulti so that the order the list is drawn corresponds to the zorder of the drawing - i.e. the front of the list is the top layer of the drawing, the tail of the list the bottom.
UPDATE - actually I haven't - the changes don't work. This will need some more work/thought as it might be better to change how the list is drawn rather than the obvious fix of reversing it...
wumpus-extra
Copperbox revision 1370.
More work unifying the Shape code. TextLine has now become FreeLabel as it can no longer use a rectangle as an underlying primitive. I've added a diamond shape but haven't looked at how to calculate the cardinals (north east, south east, etc.).
More work unifying the Shape code. TextLine has now become FreeLabel as it can no longer use a rectangle as an underlying primitive. I've added a diamond shape but haven't looked at how to calculate the cardinals (north east, south east, etc.).
Saturday, May 22, 2010
wumpus-extra
Copperbox revision 1368.
Finally I can draw rectangles with interior text labels - other shapes to follow...
Finally I can draw rectangles with interior text labels - other shapes to follow...
wumpus-extra
Copperbox revision 1367.
More work towards adding interior text labels to shapes. All the code that was undefined or commented out in revision 1365 has been reinstated.
More work towards adding interior text labels to shapes. All the code that was undefined or commented out in revision 1365 has been reinstated.
wumpus-core
Copperbox revision 1366.
I've added a new class Transform to apply a matrix transformation directly. Without this Shapes in wumpus-extra couldn't communicate transformations on TextLabels to wumpus-core (labels have slightly different transformation behaviour in wumpus-core, because they are special in PostScript).
I've added a new class Transform to apply a matrix transformation directly. Without this Shapes in wumpus-extra couldn't communicate transformations on TextLabels to wumpus-core (labels have slightly different transformation behaviour in wumpus-core, because they are special in PostScript).
wumpus-extra
Copperbox revision 1365.
Work towards supporting text labels inside shapes, though currently I've only looked at labelling rectangles and I've had to mark a few things as undefined.
Work towards supporting text labels inside shapes, though currently I've only looked at labelling rectangles and I've had to mark a few things as undefined.
Friday, May 21, 2010
wumpus-extra
Copperbox revision 1364.
I've added cardinal anchors to circle. Plus I've unified some of the code for the various shapes (coordinate, rectangle, circle) so they are using the same idiom for working with the geometry in context of the transformations applied to the CTM.
I've added cardinal anchors to circle. Plus I've unified some of the code for the various shapes (coordinate, rectangle, circle) so they are using the same idiom for working with the geometry in context of the transformations applied to the CTM.
wumpus-extra
Copperbox revision 1363.
Trivial updates - mostly due to bezierCurve now going into wumpus-core. Also I've added a circle shape.
Trivial updates - mostly due to bezierCurve now going into wumpus-core. Also I've added a circle shape.
wumpus-core
Copperbox revision 1362.
I've revised the bezierCircle function taking it out of Core.PictureInternal and making it an exported function from Core.Geometry.
I've revised the bezierCircle function taking it out of Core.PictureInternal and making it an exported function from Core.Geometry.
wumpus-extra
Copperbox revision 1361.
I've put the shapes (coordinate, rectangle, text line) into separate modules. If I follow TikZ's example there are likely to be a lot of shapes, so one module would be unmanageable.
I've put the shapes (coordinate, rectangle, text line) into separate modules. If I follow TikZ's example there are likely to be a lot of shapes, so one module would be unmanageable.
wumpus-extra
Copperbox revision 1360.
Textline is now a shape. This is possibly provisional, as all (or most?) shapes in TikZ can have text as a property so it isn't a distinct shape type (xy-pic doesn't seem to have the concept of shapes, ps-tricks does seem to have a distinct label type).
Textline is now a shape. This is possibly provisional, as all (or most?) shapes in TikZ can have text as a property so it isn't a distinct shape type (xy-pic doesn't seem to have the concept of shapes, ps-tricks does seem to have a distinct label type).
wumpus-core
Copperbox revision 1359.
Cosmetic changes...
I've removed the CMinMax type class which only had one instance - for Points - and implemented minPt and maxPt directly.
Where type signatures had Point2, Vec2 etc. I've changed instances where the type parameter was labelled _a_ to label it _u_. This should be more indicative that the type parameter represents the unit of Points, Vectors etc. usually a Double.
e.g.
Becomes:
Cosmetic changes...
I've removed the CMinMax type class which only had one instance - for Points - and implemented minPt and maxPt directly.
Where type signatures had Point2, Vec2 etc. I've changed instances where the type parameter was labelled _a_ to label it _u_. This should be more indicative that the type parameter represents the unit of Points, Vectors etc. usually a Double.
e.g.
frameProduct :: (Num a, InnerSpace (Vec2 a))
=> Frame2 a -> Frame2 a -> Frame2 a
Becomes:
frameProduct :: (Num u, InnerSpace (Vec2 u))
=> Frame2 u -> Frame2 u -> Frame2 u
Thursday, May 20, 2010
wumpus-extra
Copperbox revision 1358.
I've reformulated the Path code as a monad. This should make it a bit more flexible, e.g. points along a path could be made addressable like the cells in the Matrix monad.
I've reformulated the Path code as a monad. This should make it a bit more flexible, e.g. points along a path could be made addressable like the cells in the Matrix monad.
wumpus
Copperbox revision 1357.
I've added new examples to wumpus-core and wumpus-extra.
The new example in wumpus-core is a simple drawing using frameMulti. I was thinking frameMulti might generate bad PostScript (extraneous concat operations), but that doesn't seem to be the case, so I won't have to optimize wumpus-core like I was expecting to.
The new example in wumpus-extra uses the Path combinators from AffineTestBase.hs. I'm developing a module in Wumpus.Extra for paths, but a monadic formulation of the combinators looks to have advantages over the original one.
I've added new examples to wumpus-core and wumpus-extra.
The new example in wumpus-core is a simple drawing using frameMulti. I was thinking frameMulti might generate bad PostScript (extraneous concat operations), but that doesn't seem to be the case, so I won't have to optimize wumpus-core like I was expecting to.
The new example in wumpus-extra uses the Path combinators from AffineTestBase.hs. I'm developing a module in Wumpus.Extra for paths, but a monadic formulation of the combinators looks to have advantages over the original one.
wumpus-core-0.18.0, wumpus-extra-0.11.0
Copperbox revision 1356.
New releases. Demos changed to create ./out/ directory if it is missing.
New releases. Demos changed to create ./out/ directory if it is missing.
wumpus-extra
Copperbox revision 1355.
Revisions to use wumpus-core-0.18.0, mostly adding Floating typeclass constraints.
Next commit will be new releases.
Revisions to use wumpus-core-0.18.0, mostly adding Floating typeclass constraints.
Next commit will be new releases.
wumpus-core
Copperbox revision 1354.
Some cosmetic changes on the way to a new release - updating the cabal description, making sure the AffineTest modules don't import hidden modules.
Some cosmetic changes on the way to a new release - updating the cabal description, making sure the AffineTest modules don't import hidden modules.
wumpus-core
Copperbox revision 1353.
I've reworked the affine test code and extended it to cover all for of the affine classes Scale, Translate, Rotate and RotateAbout.
Also I've added createDirectoryIfMissing to the main of the other examples so it will create the ./out/ directory.
I've reworked the affine test code and extended it to cover all for of the affine classes Scale, Translate, Rotate and RotateAbout.
Also I've added createDirectoryIfMissing to the main of the other examples so it will create the ./out/ directory.
Wednesday, May 19, 2010
wumpus-core
Copperbox revision 1352.
I've added path drawing tests to AffineTest01.hs.
At the moment Pictures calculate larger bounding boxes than primitives after rotation transforms. This is probably because pictures calculate the bounding box new bounding box after a transformation by preforming transformation on the previous bounding box, rather than the primitives within the picture... Though, if its another reason it is certainly a bug.
Like the circle bounding box problem I posted about yesterday, I might by happy that this is a quirk rather than try to do anything about it. Uniformity would definitely be nice, but I don't want to complicate the implementation.
I've added path drawing tests to AffineTest01.hs.
At the moment Pictures calculate larger bounding boxes than primitives after rotation transforms. This is probably because pictures calculate the bounding box new bounding box after a transformation by preforming transformation on the previous bounding box, rather than the primitives within the picture... Though, if its another reason it is certainly a bug.
Like the circle bounding box problem I posted about yesterday, I might by happy that this is a quirk rather than try to do anything about it. Uniformity would definitely be nice, but I don't want to complicate the implementation.
Tuesday, May 18, 2010
wumpus-core
Copperbox revision 1351.
The boundary calculations for ellipses weren't right in the last commit - they had a special case for circles that was wrong.
Circles are still problematic with the code in this revision - because I take the tangent at specific points, a circle rotated 45 degrees about its center will have a different bounding box to a non rotated circle of the same area. This is the same effect as a diamond having a larger bounding box the a square with the same side length.
I'm not sure what to do about this. I don't mind that the bounding box of an ellipse is the bounding box of its control points rather than a tighter bounding box taking tangents to the arcs - calculating this would take some maths I don't know. However, for circles my laxness does seem less justified as the visual mis-match is so apparent.
The boundary calculations for ellipses weren't right in the last commit - they had a special case for circles that was wrong.
Circles are still problematic with the code in this revision - because I take the tangent at specific points, a circle rotated 45 degrees about its center will have a different bounding box to a non rotated circle of the same area. This is the same effect as a diamond having a larger bounding box the a square with the same side length.
I'm not sure what to do about this. I don't mind that the bounding box of an ellipse is the bounding box of its control points rather than a tighter bounding box taking tangents to the arcs - calculating this would take some maths I don't know. However, for circles my laxness does seem less justified as the visual mis-match is so apparent.
wumpus-core
Copperbox revision 1350.
Calculating the bounding box of (rotated) ellipses now looks like it is working correctly. I had to add some new functions to picture to draw control points so that I could visually check it. These new functions will need a bit of tidying as I hacked them together quite quickly - particularly drawing the control points of a curved path doesn't work yet.
Calculating the bounding box of (rotated) ellipses now looks like it is working correctly. I had to add some new functions to picture to draw control points so that I could visually check it. These new functions will need a bit of tidying as I hacked them together quite quickly - particularly drawing the control points of a curved path doesn't work yet.
wumpus-core
Copperbox revision 1349.
I've improved the calculation of bounding boxes for ellipses. I think it is still wrong, but I'll have to put in some code to draw the control points on Bezier curves to visually check my intuition.
I've improved the calculation of bounding boxes for ellipses. I think it is still wrong, but I'll have to put in some code to draw the control points on Bezier curves to visually check my intuition.
wumpus-core
Copperbox revision 1348.
I've extended the tests to rotation on circles and ellipses. Circles work, ellipses don't.
I've extended the tests to rotation on circles and ellipses. Circles work, ellipses don't.
wumpus-core
Copperbox revision 1347.
First round of work testing affine transformations on primitives. I've added a few new helpers to Core.Picture so I can draw simple tests (without needing Extra.PictureLanguage). Rotating text as a primitive seems to work.
First round of work testing affine transformations on primitives. I've added a few new helpers to Core.Picture so I can draw simple tests (without needing Extra.PictureLanguage). Rotating text as a primitive seems to work.
Monday, May 17, 2010
wumpus-core
Copperbox revision 1346.
I've added support for affine translations on Primitives (paths, labels and ellipses) and instances for the affine classes.
As yet this code is untested, and there are a lot of places to go wrong. Tomorrow I'll have to work out how to test it.
I've added support for affine translations on Primitives (paths, labels and ellipses) and instances for the affine classes.
As yet this code is untested, and there are a lot of places to go wrong. Tomorrow I'll have to work out how to test it.
wumpus-core-0.17.0, wumpus-extra-0.10.0
Copperbox revision 1345.
I've made new releases of wumpus-core and wumpus-extra before I attempt to change wumpus-core's internals so it can support affine transformations on Primitives.
I've made new releases of wumpus-core and wumpus-extra before I attempt to change wumpus-core's internals so it can support affine transformations on Primitives.
wumpus-core
Copperbox revision 1344.
I've removed the dependency on 'old-time' and switched to 'time'. I rather regret doing this as I'm not a fan of the new time library, however it is one less dependency to chase from Hackage.
I've also updated the user guide - no new info but it needed changing to reflect that PictureLanguage has changed its namespace.
I've removed the dependency on 'old-time' and switched to 'time'. I rather regret doing this as I'm not a fan of the new time library, however it is one less dependency to chase from Hackage.
I've also updated the user guide - no new info but it needed changing to reflect that PictureLanguage has changed its namespace.
wumpus-core
Copperbox revision 1343.
I've moved Core.PictureLanguage to Extra.PictureLanguage - this module needs a bit more thought and is higher-level than the rest of Wumpus.Core, so it fits moving into the Wumpus.Extra namespace.
I've also added a module Core.WumpusTypes to collect the Types that are exported opaquely at the top-level. This makes the generated Haddock docs more cohesive.
I've moved Core.PictureLanguage to Extra.PictureLanguage - this module needs a bit more thought and is higher-level than the rest of Wumpus.Core, so it fits moving into the Wumpus.Extra namespace.
I've also added a module Core.WumpusTypes to collect the Types that are exported opaquely at the top-level. This makes the generated Haddock docs more cohesive.
Sunday, May 16, 2010
wumpus-core
Copperbox revision 1342.
I've simplified the Primitive data type by putting the Ellipse properties from the PEllipse constructor into their own type - PrimEllipse.
I've simplified the Primitive data type by putting the Ellipse properties from the PEllipse constructor into their own type - PrimEllipse.
wumpus
Copperbox revision 1341.
I've changed the argument order of textlabel and ztextlabel so that point is the last argument. This has cascaded quite a few changes.
More controversially, I'm wondering if I can accommodate affine transformations on Primitives in wumpus-core. This will be a good optimization for wumpus-extra, but I'm not sure if it makes sense. Wumpus-core has an implementation simplicity because it transmits all affine transformations to PostScript - (bounding boxes are a slight caveat). But this has quite a overhead for making pictures out of many dots (e.g. scatter plots), and I've already added a hack frameMulti to allow primitives to be composed into Pictures. Maybe I can extend this by allowing primitives to be transformed 'on the Haskell side'...
I've changed the argument order of textlabel and ztextlabel so that point is the last argument. This has cascaded quite a few changes.
More controversially, I'm wondering if I can accommodate affine transformations on Primitives in wumpus-core. This will be a good optimization for wumpus-extra, but I'm not sure if it makes sense. Wumpus-core has an implementation simplicity because it transmits all affine transformations to PostScript - (bounding boxes are a slight caveat). But this has quite a overhead for making pictures out of many dots (e.g. scatter plots), and I've already added a hack frameMulti to allow primitives to be composed into Pictures. Maybe I can extend this by allowing primitives to be transformed 'on the Haskell side'...
wumpus-extra
Copperbox revision 1340.
I've added a new shape - Coordinate which is just a circular point. Also I've added anchor points as addressable locations of a shape - center, north, south, etc.
I've added a new shape - Coordinate which is just a circular point. Also I've added anchor points as addressable locations of a shape - center, north, south, etc.
wumpus-extra
Copperbox revision 1339.
I've added a module for Shapes to Wumpus extra - only shape so far the rectangle!...
After looking at shapes in TikZ / PGF, I think the BasicObjects in wumpus-extra are too primitive, so I'm making a library of shapes as an alternative.
I've added a module for Shapes to Wumpus extra - only shape so far the rectangle!...
After looking at shapes in TikZ / PGF, I think the BasicObjects in wumpus-extra are too primitive, so I'm making a library of shapes as an alternative.
wumpus-core-0.16.0, wumpus-extra-0.9.0
Copperbox revision 1338.
New release of wumpus-core for Hackage - the most important update is escaping special characters in PostScript output. A wumpus-extra revision put on the download page of
http://code.google.com/p/copperbox/
New release of wumpus-core for Hackage - the most important update is escaping special characters in PostScript output. A wumpus-extra revision put on the download page of
http://code.google.com/p/copperbox/
Saturday, May 15, 2010
wumpus-extra
Copperbox revision 1336.
Some work on the Matrix module. I've started to remake the drawing code so I can center nodes and draw better arrows. Centering is in place but the code is still a bit rough. Placing arrows will need some thought - at the moment the go right into the center of the node rather than to its boundary.
Some work on the Matrix module. I've started to remake the drawing code so I can center nodes and draw better arrows. Centering is in place but the code is still a bit rough. Placing arrows will need some thought - at the moment the go right into the center of the node rather than to its boundary.
Thursday, May 13, 2010
precis-0.4.0
Copperbox revision 1335.
I've made a new release of Precis. The HTML report still needs some styling, but this version is substantially better than the one on Hackage.
Unfortunately I can't put full HTML pages on this blog or I'd post the report of changes between 0.3.1 and 0.4.0.
I've made a new release of Precis. The HTML report still needs some styling, but this version is substantially better than the one on Hackage.
Unfortunately I can't put full HTML pages on this blog or I'd post the report of changes between 0.3.1 and 0.4.0.
Precis
Copperbox revision 1334.
More work on the HTML report. I think all the functionality is now in place - the report just needs to to look prettier and be more explanatory (e.g. mentioning that it only diffs Haskell source not FFI code).
More work on the HTML report. I think all the functionality is now in place - the report just needs to to look prettier and be more explanatory (e.g. mentioning that it only diffs Haskell source not FFI code).
Wednesday, May 12, 2010
Precis
Copperbox revision 1333.
I've substantially reworked the HtmlReport module. Its now doing pretty much want I want and the code is quite tidy - I just need to prettify the output before a making new release.
All in all today's been a productive day.
I've substantially reworked the HtmlReport module. Its now doing pretty much want I want and the code is quite tidy - I just need to prettify the output before a making new release.
All in all today's been a productive day.
Precis
Copperbox revision 1332.
Further work on console reporting. Most of the code is now written, the logging functions just need calling from the ReportM code in HtmlReport.
Further work on console reporting. Most of the code is now written, the logging functions just need calling from the ReportM code in HtmlReport.
Precis
Copperbox revisions 1330 & 1331.
More work on console output. I've reinstated PPShowS - the pretty print combinators for ShowS as it looks like I'll need to do quite a bit of text handling (even though the full report will be HTML).
More work on console output. I've reinstated PPShowS - the pretty print combinators for ShowS as it looks like I'll need to do quite a bit of text handling (even though the full report will be HTML).
Precis
Copperbox revision 1329.
I've added a data type ChangeStats to count changes that oblige an increase to the package major version number.
I've added a data type ChangeStats to count changes that oblige an increase to the package major version number.
Precis
Copperbox revision 1328.
Some more tidying up - I've shifted the in-line style sheet code into a new module so I'll think about it later, rather than keep tweaking styles when I should be doing something more important.
I've simplified the comparison code in ModuleProperties - it wasn't very well thought out in the first instance.
Some more tidying up - I've shifted the in-line style sheet code into a new module so I'll think about it later, rather than keep tweaking styles when I should be doing something more important.
I've simplified the comparison code in ModuleProperties - it wasn't very well thought out in the first instance.
Precis
Copperbox revision 1327.
I've changed the Properties module into a simpler module Diff. When I coded Properties, I was thinking that collecting properties might be more useful than just for diffs (i.e. later collecting metrics from properties). However the code was too convoluted, so it it had to go.
I've changed the Properties module into a simpler module Diff. When I coded Properties, I was thinking that collecting properties might be more useful than just for diffs (i.e. later collecting metrics from properties). However the code was too convoluted, so it it had to go.
Precis
Copperbox revision 1326.
Some progress - I've worked out how to add in-line sytle sheets so I only need to generate one file.
Unfortunately the code is starting to get rather clumsy, this is always suggestive that the fundamentals aren't right. For one thing some edit lists are better suited to three values ADD, EQUAL, DELETE rather than four ADD, EQUAL, DIFF, DELETE. Also generating so much of the report code from inside the monad feels unnatural - I need to read files as I go, so some code has to be in the monad, but a suite of "bigger" combinators (i.e. that make specialized document fragments) than the XHtml ones might be useful.
Some progress - I've worked out how to add in-line sytle sheets so I only need to generate one file.
Unfortunately the code is starting to get rather clumsy, this is always suggestive that the fundamentals aren't right. For one thing some edit lists are better suited to three values ADD, EQUAL, DELETE rather than four ADD, EQUAL, DIFF, DELETE. Also generating so much of the report code from inside the monad feels unnatural - I need to read files as I go, so some code has to be in the monad, but a suite of "bigger" combinators (i.e. that make specialized document fragments) than the XHtml ones might be useful.
Tuesday, May 11, 2010
Precis
Copperbox revision 1325.
The code is now in place to generate HTML reports. Some bits don't seem to be working as expected though - its not printing a 'short report' to the console, when there is code to do that.
The code is now in place to generate HTML reports. Some bits don't seem to be working as expected though - its not printing a 'short report' to the console, when there is code to do that.
Precis
Copperbox revision 1324.
More work towards HTML reporting for Precis. I've added a report monad that works like Writer to collect HTML fragments as the cabal file and individual modules are processed.
More work towards HTML reporting for Precis. I've added a report monad that works like Writer to collect HTML fragments as the cabal file and individual modules are processed.
Monday, May 10, 2010
precis
Copperbox revision 1323.
I've started work on adding HTML reporting to Precis. This is an obvious step given that the output is currently overwhelming, but whilst I intended to use HTML reporting when I started, I forgot about it until now.
I've started work on adding HTML reporting to Precis. This is an obvious step given that the output is currently overwhelming, but whilst I intended to use HTML reporting when I started, I forgot about it until now.
wumpus-core
Copperbox revision 1322.
I've added automatic escape character handling for special characters in PostScript text output.
I've added automatic escape character handling for special characters in PostScript text output.
wumpus
Copperbox revision 1321.
I've added rudimentary support for cell connectors in Matrix.Extra. The drawing isn't very good yet as I don't center the labels within the grid, or account for the bounding box when drawing the label.
Working on the GridPic example has turned up a serious bug with wumpus-core that it doesn't escape the special characters it sends to PostScript in a (...) show command. This can cause the whole drawing to fail to render not just the particular text. I'll have to look at fixing this fairly urgently.
I've added rudimentary support for cell connectors in Matrix.Extra. The drawing isn't very good yet as I don't center the labels within the grid, or account for the bounding box when drawing the label.
Working on the GridPic example has turned up a serious bug with wumpus-core that it doesn't escape the special characters it sends to PostScript in a (...) show command. This can cause the whole drawing to fail to render not just the particular text. I'll have to look at fixing this fairly urgently.
Sunday, May 9, 2010
wumpus-extra
Copperbox revision 1320.
I've reprieved Grid from being in the Wumpus.Doodle name space - its now back in Wumpus.Extra although its renamed Matrix to be more familiar to the name from TikZ.
I've put in some work generalizing it so that I'll be able to add a monadic operation to bind lines to cell coordinates. This will mean making the writer part of the monad handle accumulating lines, which is currently missing...
I've reprieved Grid from being in the Wumpus.Doodle name space - its now back in Wumpus.Extra although its renamed Matrix to be more familiar to the name from TikZ.
I've put in some work generalizing it so that I'll be able to add a monadic operation to bind lines to cell coordinates. This will mean making the writer part of the monad handle accumulating lines, which is currently missing...
wumpus-extra
Copperbox revision 1319.
I've replaced the old grid code with a new implementation based on the code in the last blog post that tracks the matrix width at the type level. This means that rows are now force to have the same width.
I've replaced the old grid code with a new implementation based on the code in the last blog post that tracks the matrix width at the type level. This means that rows are now force to have the same width.
Type level success #2
I've long wanted to have an analogue to TikZ's "matrix" command in Wumpus. The matrix command introduces named nodes and blanks within a list of equal sized rows. To introduce new names, something monadic seemed good in Haskell; but I couldn't work out how to enforce that each row should have the same width - especially when I only wanted to bind names to nodes and not blanks.
Currently wumpus-extra has a doodle that doesn't even try to enforce row size, its just about useful as it tracks a coordinate space with a state monad - each new node gets attributed with its coordinate position from the current state and 1 gets added to the column number. The row command resets the column count and adds 1 to the row number.
Here's one with type level naturals measuring a snoc list that does enforce row width. Currently its via an Identity monad with an extra shape parameter. Hopefully it will extend to a state monad to track coordinates:
Currently wumpus-extra has a doodle that doesn't even try to enforce row size, its just about useful as it tracks a coordinate space with a state monad - each new node gets attributed with its coordinate position from the current state and 1 gets added to the column number. The row command resets the column count and adds 1 to the row number.
Here's one with type level naturals measuring a snoc list that does enforce row width. Currently its via an Identity monad with an extra shape parameter. Hopefully it will extend to a state monad to track coordinates:
{-# LANGUAGE EmptyDataDecls #-}
module GridTemp03 where
data Z
data S a
newtype Id sh a = Id a
runId :: Id sh a -> a
runId (Id a) = a
instance Monad (Id sh) where
return a = Id a
Id a >>= f = Id $ (runId . f) a
nil :: Id Z ()
nil = Id ()
blank :: Id sh a -> Id (S sh) a
blank (Id acc) = Id acc
node :: Int -> Id sh a -> Id (S sh) (a,Int)
node i (Id acc) = Id (acc,i)
infixl 5 &
(&) :: Id sh a -> (Id sh a -> Id (S sh) b) -> Id (S sh) b
tl & h = h tl
elem0 :: Id sh () -> Id sh ()
elem0 (Id ()) = Id ()
elem1 :: Id sh ((),a) -> Id sh a
elem1 (Id ((),a)) = Id a
elem2 :: Id sh (((),a),b) -> Id sh (a,b)
elem2 (Id (((),a),b)) = Id (a,b)
elem3 :: Id sh ((((),a),b),c) -> Id sh (a,b,c)
elem3 (Id ((((),a),b),c)) = Id (a,b,c)
-- Rows must have the same width and the number of
-- nodes in the row content must match the respective
-- elemN function.
--
demo1 = runId $ do
r1 <- elem3 $ nil & node 1 & blank & node 2 & node 3
r2 <- elem0 $ nil & blank & blank & blank & blank
return (r1,r2)
Saturday, May 8, 2010
wumpus
Copperbox revision 1317.
Some work towards supporting rounded corners. This brought up a bug in Wumpus.Core.Geometry's langle, and highlighted some 'missing' functions that I've now added.
I've moved the Lines code from Wumpus.Extra to Wumpus.Doodle as it wasn't very good.
Some work towards supporting rounded corners. This brought up a bug in Wumpus.Core.Geometry's langle, and highlighted some 'missing' functions that I've now added.
I've moved the Lines code from Wumpus.Extra to Wumpus.Doodle as it wasn't very good.
wumpus-core-0.15.0, wumpus-extra-0.8.0
Copperbox revision 1316.
New releases of wumpus-core and wumpus-extra.
wumpus-core only has new files added - safe fonts and colour schemes from wumpus-extra and version number.
wumpus-extra has the folder re-organisation where all the code has been moved out of the Wumpus.Geometry namespace.
New releases of wumpus-core and wumpus-extra.
wumpus-core only has new files added - safe fonts and colour schemes from wumpus-extra and version number.
wumpus-extra has the folder re-organisation where all the code has been moved out of the Wumpus.Geometry namespace.
Friday, May 7, 2010
wumpus
Copperbox revision 1315.
I've updated the user guide in wumpus-core and moved the Grid module in Wumpus.Doodle in wumpus-extra.
I've updated the user guide in wumpus-core and moved the Grid module in Wumpus.Doodle in wumpus-extra.
wumpus-extra
Copperbox revisions 1313 & 1314.
I've moved all the code out of Wumpus.Geometry, so now the code is all under Wumpus.Extra (except for the very provisional stuff which is in Wumpus.Doodle).
One of the examples is now broken (GeometryPic.hs) as I don't think I want to maintain LineSegment as a type (currently it is dropped).
I've moved all the code out of Wumpus.Geometry, so now the code is all under Wumpus.Extra (except for the very provisional stuff which is in Wumpus.Doodle).
One of the examples is now broken (GeometryPic.hs) as I don't think I want to maintain LineSegment as a type (currently it is dropped).
wumpus-extra
Copperbox revision 1312.
First steps towards tidying up wumpus-extra - I've moved the trivial modules for scatter plots and colour charts into the name space Wumpus.Doodle.
First steps towards tidying up wumpus-extra - I've moved the trivial modules for scatter plots and colour charts into the name space Wumpus.Doodle.
wumpus-core
Copperbox revision 1311.
I've added a version number file to wumpus-core and a userHook in the cabal Setup file to remind me to keep it up to date. I've also bumped up the copyright notice on all the source files.
I've added a version number file to wumpus-core and a userHook in the cabal Setup file to remind me to keep it up to date. I've also bumped up the copyright notice on all the source files.
wumpus-extra
Copperbox revision 1310.
I've updated wumpus-extra as the stable modules Extra.SafeFonts, Extra.SVGColours, and Extra.X11Colours have been moved to wumpus-core.
I've updated wumpus-extra as the stable modules Extra.SafeFonts, Extra.SVGColours, and Extra.X11Colours have been moved to wumpus-core.
wumpus-core
Copperbox revision 1309.
I've added the stable modules Extra.SafeFonts, ExtraSVGColours and Extra.X11Colours from wumpus-extra. The modules are unlikely to change and possibly useful, so it seems better to rescue them from the unstable and unreleased wumpus-extra package.
I've added the stable modules Extra.SafeFonts, ExtraSVGColours and Extra.X11Colours from wumpus-extra. The modules are unlikely to change and possibly useful, so it seems better to rescue them from the unstable and unreleased wumpus-extra package.
Thursday, May 6, 2010
tonos
Copperbox revision 1308.
Work on enharmonic spelling.
Notionally, the enharmonic spelling I have to do is simpler than typical results presented in research papers. I know the key I'm in, all I have to do is account for all 12 pitches when I'm converting from one pitch representation to another. Usually I'd expect pitches to be spelled correctly but the initial pitch rep represents accounts for accidentals as an integer - the final pitch rep has them as an enumeration with 5 levels - Natural Sharp, Flat, Double Sharp, Double Flat. So I want a total function that can eliminate non-representable accidentals.
I've worked out an 'on paper' algorithm to map the Z12 pitch numbers to particular spellings, though I don't know how to compute it:
Firstly account for the notes in the scale - taking G major
G 7, A 9, B 11, C 0, D 2, E 4, F# 6
Sorted gives: [0, 2, 4, 6, 7, 9, 11]
Secondly, "prefer naturals" - so as we have F# in the scale we take F at 5 rather than E#.
[0, 2, 4, 5, 6, 7, 9, 11] - are now accounted for.
For the remaining numbers calculate the interval from the tonic G to the challengers for the number:
For 1 - C# and Db are the challengers; G -> C# is Aug4, G -> Db is dim5 - no winner.
For 3 - D# and Eb are the challengers; G -> D# is (5,8) an unnamed interval; G -> Eb is min6 so Eb wins.
For 8 - Ab and G# are the challengers; G -> Ab is min2, G -> G# is unnamed (1,1); Ab wins.
For 10 - A# and Bb are the challengers; G -> A# is unnamed (1,3); G -> Bb is min3; Bb wins.
As all the winners are flats - I resolve the no winner (C# or Db) as Db for consistency.
This accounts for all the numbers in Z12.
Work on enharmonic spelling.
Notionally, the enharmonic spelling I have to do is simpler than typical results presented in research papers. I know the key I'm in, all I have to do is account for all 12 pitches when I'm converting from one pitch representation to another. Usually I'd expect pitches to be spelled correctly but the initial pitch rep represents accounts for accidentals as an integer - the final pitch rep has them as an enumeration with 5 levels - Natural Sharp, Flat, Double Sharp, Double Flat. So I want a total function that can eliminate non-representable accidentals.
I've worked out an 'on paper' algorithm to map the Z12 pitch numbers to particular spellings, though I don't know how to compute it:
Firstly account for the notes in the scale - taking G major
G 7, A 9, B 11, C 0, D 2, E 4, F# 6
Sorted gives: [0, 2, 4, 6, 7, 9, 11]
Secondly, "prefer naturals" - so as we have F# in the scale we take F at 5 rather than E#.
[0, 2, 4, 5, 6, 7, 9, 11] - are now accounted for.
For the remaining numbers calculate the interval from the tonic G to the challengers for the number:
For 1 - C# and Db are the challengers; G -> C# is Aug4, G -> Db is dim5 - no winner.
For 3 - D# and Eb are the challengers; G -> D# is (5,8) an unnamed interval; G -> Eb is min6 so Eb wins.
For 8 - Ab and G# are the challengers; G -> Ab is min2, G -> G# is unnamed (1,1); Ab wins.
For 10 - A# and Bb are the challengers; G -> A# is unnamed (1,3); G -> Bb is min3; Bb wins.
As all the winners are flats - I resolve the no winner (C# or Db) as Db for consistency.
This accounts for all the numbers in Z12.
Neume
Copperbox revision 1307.
I've renamed the SpellingMap type to AbcSpellingMap. This is to qualify that the spelling map is only concerned with ABC spelling i.e. rewriting F# to F when in G major, rather than a more general idea of enharmonic spelling.
Tonos needs more general enharmonic spelling, hence the motivation to do the renaming now.
I've renamed the SpellingMap type to AbcSpellingMap. This is to qualify that the spelling map is only concerned with ABC spelling i.e. rewriting F# to F when in G major, rather than a more general idea of enharmonic spelling.
Tonos needs more general enharmonic spelling, hence the motivation to do the renaming now.
Wednesday, May 5, 2010
wumpus-core
Copperbox revision 1305.
A new release of wumpus-core - the salient feature is the first draft of a user guide, 5 pages so far so it might actually be useful.
A new release of wumpus-core - the salient feature is the first draft of a user guide, 5 pages so far so it might actually be useful.
wumpus-core
Copperbox revision 1304.
More work on the manual. I've added the pdf generated from Guide.lhs into the svn repository, unfortunately Google's code view doesn't make it a browsable link (binary - not plaintext).
More work on the manual. I've added the pdf generated from Guide.lhs into the svn repository, unfortunately Google's code view doesn't make it a browsable link (binary - not plaintext).
wumpus-core
Copperbox revision 1303.
Minor updates - some comments updated, removed dependency on Data.DList. More importantly I've started a new guide/manual, which includes an eps figure generated by wumpus (self- reflexivity!).
Minor updates - some comments updated, removed dependency on Data.DList. More importantly I've started a new guide/manual, which includes an eps figure generated by wumpus (self- reflexivity!).
Tuesday, May 4, 2010
tonos
Copperbox revision 1302.
I've added a Num instance for PitchLetters (as they are just Z7 integers in disguise) and a Distance type class which should model a metric space, except perhaps the triangle equality rule - I don't know how it applies to PitchLetters.
PitchLetters have a distance according to their semitone count, e.g. C to D is 2, but B to C is 1 (as considering a piano there is no black key between them).
I've added a Num instance for PitchLetters (as they are just Z7 integers in disguise) and a Distance type class which should model a metric space, except perhaps the triangle equality rule - I don't know how it applies to PitchLetters.
PitchLetters have a distance according to their semitone count, e.g. C to D is 2, but B to C is 1 (as considering a piano there is no black key between them).
tonos
Copperbox revision 1301.
I've started a new project tonos for pitch calculations and manipulation. It will probably replace bala-core and subsume utt at some point.
I've started a new project tonos for pitch calculations and manipulation. It will probably replace bala-core and subsume utt at some point.
Monday, May 3, 2010
utt
Copperbox revision 1300.
I can now render triads to LilyPond via Neume. Unfortunately the code to do this isn't satisfactory. I make things quite convoluted because I'm using Neume's pitch representation which doesn't support arithmetic (e.g. adding intervals). Also its exposed a bug in Neume's chord printing, where the relative pitch isn't calculated correctly after the chord.
I can now render triads to LilyPond via Neume. Unfortunately the code to do this isn't satisfactory. I make things quite convoluted because I'm using Neume's pitch representation which doesn't support arithmetic (e.g. adding intervals). Also its exposed a bug in Neume's chord printing, where the relative pitch isn't calculated correctly after the chord.
Sunday, May 2, 2010
Tactus
Copperbox revision 1298.
I've improved the divide2 and divide3 combinators so I can now describe all the manipulations of the [2,2,3] meter pattern in the hijaz example. Picture on Mr_Wumpus's Flickr page...
http://www.flickr.com/photos/44929957@N03/4571078223/
I've improved the divide2 and divide3 combinators so I can now describe all the manipulations of the [2,2,3] meter pattern in the hijaz example. Picture on Mr_Wumpus's Flickr page...
http://www.flickr.com/photos/44929957@N03/4571078223/
tactus
Copperbox revision 1297.
I've added a fraction type that doesn't eagerly reduce to the lowest terms. This seems necessary for the divide2 and divide3 combinators - though I haven't worked the implementation out yet.
I've added a fraction type that doesn't eagerly reduce to the lowest terms. This seems necessary for the divide2 and divide3 combinators - though I haven't worked the implementation out yet.
tactus
Copperbox revision 1296.
More work on the hijaz demo, though it looks like I'll have to consider fractions more seriously as a type.
tactus
Copperbox revision 1295.
More work on the hijaz demo. I've changed the meter pattern type in tactus to use pairs of Ints rather than Rationals to represent fractions. Rationals reduce the fraction (e.g. 2%4 -> 1%2) which is a problem for tactus.
More work on the hijaz demo. I've changed the meter pattern type in tactus to use pairs of Ints rather than Rationals to represent fractions. Rationals reduce the fraction (e.g. 2%4 -> 1%2) which is a problem for tactus.
Saturday, May 1, 2010
tactus
Copperbox revision 1294.
I've taken the meter pattern code from bala-core and put it into a new mini-project tactus.
For tactus, I've changed the representation of meter patterns to use Rational rather than Int - this should allow something that improves the current div2 operation, and added code to render to LilyPond via Neume as percussion notation.
I've taken the meter pattern code from bala-core and put it into a new mini-project tactus.
For tactus, I've changed the representation of meter patterns to use Rational rather than Int - this should allow something that improves the current div2 operation, and added code to render to LilyPond via Neume as percussion notation.
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.