Copperbox revision 2362.
I've added a toy sequencer. It supports concatenation much like the AdvanceGraphic in Wumpus.
Friday, April 29, 2011
Thursday, April 28, 2011
wumpus
Copperbox revision 2360.
I've updated Paths in Wumpus-Drawing to avoid name clashes with the new LocTrace module in Basic. I've also added a Path optimizer for AbsPath to coalesce successive straight line segments that move in the same direction.
In Wumpus-Tree I've finally got family connectors working for rotated trees. It turns out that there aren't really any abstractions in Wumpus that help much here as family tree connectors are so peculiar - end points of the lines are actually more tangible than start points because the starts are dependent on anchors.
I've updated Paths in Wumpus-Drawing to avoid name clashes with the new LocTrace module in Basic. I've also added a Path optimizer for AbsPath to coalesce successive straight line segments that move in the same direction.
In Wumpus-Tree I've finally got family connectors working for rotated trees. It turns out that there aren't really any abstractions in Wumpus that help much here as family tree connectors are so peculiar - end points of the lines are actually more tangible than start points because the starts are dependent on anchors.
wumpus-basic
Copperbox revision 2359.
I've finally added a turtle-like drawing monad to Wumpus-Basic.
I've been avoiding turtle drawing on principle - "favour functional, be compositional!", but I suspect some drawing styles are better off with Writer monad style "logging" to a turtle. Particularly ones that interpret their input heavily such as the Djembe drawing.
I've finally added a turtle-like drawing monad to Wumpus-Basic.
I've been avoiding turtle drawing on principle - "favour functional, be compositional!", but I suspect some drawing styles are better off with Writer monad style "logging" to a turtle. Particularly ones that interpret their input heavily such as the Djembe drawing.
Wednesday, April 27, 2011
wumpus-basic
Copperbox revision 2358.
I've added optimized mconcat definitions to the Monoid instances where I'd prefer the concatenation not to start with an initial mempty.
mempty is harmless for CtxPictures, LocGraphics etc. but these objects generally form blank elements that don't get thrown away until Wumpus-Core renders them - so I'd like to have as few around as possible. Also blank paths or text elements might not be strictly neutral, it's possibly they add extra blank lines to the output - something I've never properly investigated.
I've added optimized mconcat definitions to the Monoid instances where I'd prefer the concatenation not to start with an initial mempty.
mempty is harmless for CtxPictures, LocGraphics etc. but these objects generally form blank elements that don't get thrown away until Wumpus-Core renders them - so I'd like to have as few around as possible. Also blank paths or text elements might not be strictly neutral, it's possibly they add extra blank lines to the output - something I've never properly investigated.
wumpus-tree
Copperbox revision 2357.
I've done some work re-organizing the module layout and removed the TreeBuildMonad which no longer seems a valid abstraction.
I've done some work re-organizing the module layout and removed the TreeBuildMonad which no longer seems a valid abstraction.
wumpus-tree
Copperbox revision 2356.
First round of rework on Tree. Tree now generates a LocGraphic rather than TraceDrawing - as most drawing objects in Wumpus are LocGraphics this means that Trees are now more composable. I've also generalized the node type to be anything that supports anchors - though trees will need nodes to be homogeneous. Scaling context has also been removed, it is folded into the new data type TreeProps.
The TreeBuild monad is probably the next for the chop. Now that nodes can be arbitrary LocImages, tree designs no longer need to support annotation through the the TreeBuild monad - LocImages can be annotated instead.
I still want to support some post-building decoration (e.g. adding links that aren't parent-child) but I might have to do this with a dictionary of String keys. Tree building has scoping which doesn't work well with monadic bind, so the current attempt to copy Andy Gill's Dot library technique for Wumpus-Tree doesn't work so well. A map of String key to Anchor might not be safe (miss-spelt keys will cause bad output rather than compile time errors), but at least the anchors can be referenced outside a special-case run function.
First round of rework on Tree. Tree now generates a LocGraphic rather than TraceDrawing - as most drawing objects in Wumpus are LocGraphics this means that Trees are now more composable. I've also generalized the node type to be anything that supports anchors - though trees will need nodes to be homogeneous. Scaling context has also been removed, it is folded into the new data type TreeProps.
The TreeBuild monad is probably the next for the chop. Now that nodes can be arbitrary LocImages, tree designs no longer need to support annotation through the the TreeBuild monad - LocImages can be annotated instead.
I still want to support some post-building decoration (e.g. adding links that aren't parent-child) but I might have to do this with a dictionary of String keys. Tree building has scoping which doesn't work well with monadic bind, so the current attempt to copy Andy Gill's Dot library technique for Wumpus-Tree doesn't work so well. A map of String key to Anchor might not be safe (miss-spelt keys will cause bad output rather than compile time errors), but at least the anchors can be referenced outside a special-case run function.
Tuesday, April 26, 2011
wumpus
Copperbox revision 2355.
Updates to Dots - I've made both Dot modules export the same functions. The anchor dots take more calculating so one can chose which module to import depending on the use case.
Also I've updated Wumpus-Tree to work with the Dot changes.
Updates to Dots - I've made both Dot modules export the same functions. The anchor dots take more calculating so one can chose which module to import depending on the use case.
Also I've updated Wumpus-Tree to work with the Dot changes.
Monday, April 25, 2011
wumpus-drawing
Copperbox revision 2354.
I've updated the demos so they all compile again. At some point I'll have to update them so they are more representative of how to use Wumpus - some of them are getting out-of-date.
I've updated the demos so they all compile again. At some point I'll have to update them so they are more representative of how to use Wumpus - some of them are getting out-of-date.
wumpus
Copperbox revision 2353.
I've sorted out the parallelogram and trapezium shapes in Wumpus-Drawing at last (after re-working their primitive path generators in Wumpus-Basic). It's disappointing that this took all the bank holiday weekend to do. The Shapes are one of the clunkiest parts of Wumpus and at some point they will need a complete overhaul, but as I was barely touching them this time around consuming four days work to fix bugs was tiresome.
I've sorted out the parallelogram and trapezium shapes in Wumpus-Drawing at last (after re-working their primitive path generators in Wumpus-Basic). It's disappointing that this took all the bank holiday weekend to do. The Shapes are one of the clunkiest parts of Wumpus and at some point they will need a complete overhaul, but as I was barely touching them this time around consuming four days work to fix bugs was tiresome.
Max Mathews
Max Mathews has died, aged 84.
As I've spent a lot of time playing with computer synthesis over the last 15 years, I owe Max - who invented and expanded the field - a great debt of thanks. Thank you, Max.
http://www.artsjournal.com/slippeddisc/2011/04/breakthough_composer_signs_off.html
As I've spent a lot of time playing with computer synthesis over the last 15 years, I owe Max - who invented and expanded the field - a great debt of thanks. Thank you, Max.
http://www.artsjournal.com/slippeddisc/2011/04/breakthough_composer_signs_off.html
wumpus-basic
Copperbox revision 2352.
I've changed the trapezium path functions to only make isosceles trapeziums. It is much easier to just to think about isosceles trapeziums (trapezia?) than general ones.
I've changed the trapezium path functions to only make isosceles trapeziums. It is much easier to just to think about isosceles trapeziums (trapezia?) than general ones.
wumpus-basic
Copperbox revision 2351.
I've re-worked the code to build trapezium paths. The new code is wrong (as was the previous code) but I still want it under version control.
I've re-worked the code to build trapezium paths. The new code is wrong (as was the previous code) but I still want it under version control.
Sunday, April 24, 2011
wumpus-basic
Copperbox revision 2350.
I've removed the parallelogram quadrant alg. Some pathological parallelograms can have parts of three lines in a quadrant - this isn't handled by the current QuadrantAlgs.
This makes QuadrantAlgs look a bit less useful than I had initially imagined - rather than extending them to handle three lines or more, maybe something better is needed.
I've removed the parallelogram quadrant alg. Some pathological parallelograms can have parts of three lines in a quadrant - this isn't handled by the current QuadrantAlgs.
This makes QuadrantAlgs look a bit less useful than I had initially imagined - rather than extending them to handle three lines or more, maybe something better is needed.
wumpus-basic
Copperbox revision 2349.
I've added a QuadrantAlg for parallelograms. At the moment it is buggy, but I want it under version control before I tear my hair out trying to find the bug...
I've added a QuadrantAlg for parallelograms. At the moment it is buggy, but I want it under version control before I tear my hair out trying to find the bug...
wumpus-drawing
Copperbox revision 2348.
I've stopped caching synthetic properties in the Shapes. This was done to save repeatedly calculating them - potentially the properties can be quite expensive; but caching them introduced consistency problems after affine transformations that I'd overlooked.
I've stopped caching synthetic properties in the Shapes. This was done to save repeatedly calculating them - potentially the properties can be quite expensive; but caching them introduced consistency problems after affine transformations that I'd overlooked.
wumpus
Copperbox revision 2347.
I've fixed the line intersection bug. The problem was with tolerant ordering: because I have operators with horrible names - `tLTE` for (<=) - I hadn't spotted I was using the wrong ones. That said, I don't really want to use arbitrary ASCII squiggles for the tolerant operators, so I'll just have to be more careful in future.
The change fixes most of the shapes, but Trapezium is still wrong, and various shapes have SyntheticProps which is also wrong.
I've fixed the line intersection bug. The problem was with tolerant ordering: because I have operators with horrible names - `tLTE` for (<=) - I hadn't spotted I was using the wrong ones. That said, I don't really want to use arbitrary ASCII squiggles for the tolerant operators, so I'll just have to be more careful in future.
The change fixes most of the shapes, but Trapezium is still wrong, and various shapes have SyntheticProps which is also wrong.
wumpus-basic
Copperbox revision 2346.
I've added an Illustrate module to Basic.Geometry to draw the geometric objects Line, LineSegment etc.
Currently there is a bug in the line intersection code and I find making a drawing seems about the best way of making sure the input data matches what I think it is. Wumpus should be able to find an intersection for this drawing:
I've added an Illustrate module to Basic.Geometry to draw the geometric objects Line, LineSegment etc.
Currently there is a bug in the line intersection code and I find making a drawing seems about the best way of making sure the input data matches what I think it is. Wumpus should be able to find an intersection for this drawing:
Saturday, April 23, 2011
wumpus-basic
Copperbox revision 2344.
Initial work re-doing the Quadrant code. I'm trying to be more systematic this time around as this is one of the trickiest parts of Wumpus.
Initial work re-doing the Quadrant code. I'm trying to be more systematic this time around as this is one of the trickiest parts of Wumpus.
Friday, April 22, 2011
wumpus-drawing
Copperbox revision 2342.
I've updated the library modules to meet the changes to drawing primitives in Wumpus-Basic. I haven't looked at the updating the demos as I'm re-doing some of the objects in Wumpus-Drawing, so the demos can be re-done after this. The drawing primitive changes were actually a side-step whilst I'm re-working the dots in Wumpus-Drawing.
The motivation for changing the drawing primitives is that actually very few things are captured as paths that are either open or closed - perhaps only Paths themselves. Most objects are always closed (e.g Shapes), or always open (Connectors). Thus the dichotomy in drawing is between stroked, filled and filled-stroked, rather than open or closed. This is something present in TikZ but I didn't realize its importance until yesterday.
I've updated the library modules to meet the changes to drawing primitives in Wumpus-Basic. I haven't looked at the updating the demos as I'm re-doing some of the objects in Wumpus-Drawing, so the demos can be re-done after this. The drawing primitive changes were actually a side-step whilst I'm re-working the dots in Wumpus-Drawing.
The motivation for changing the drawing primitives is that actually very few things are captured as paths that are either open or closed - perhaps only Paths themselves. Most objects are always closed (e.g Shapes), or always open (Connectors). Thus the dichotomy in drawing is between stroked, filled and filled-stroked, rather than open or closed. This is something present in TikZ but I didn't realize its importance until yesterday.
wumpus-basic
Copperbox revision 2341.
I've changed the drawing primitives to use an enum DrawStyle ( STROKE, FILL, FILL_STROKE ) rather than provide different functions for drawing objects with each style. This makes things a bit closer to TikZ.
I've changed the drawing primitives to use an enum DrawStyle ( STROKE, FILL, FILL_STROKE ) rather than provide different functions for drawing objects with each style. This makes things a bit closer to TikZ.
Thursday, April 21, 2011
wumpus-drawing
Copperbox revision 2340.
I've updated the Shapes to use the new vertices code. At least the parallelogram and trapezium are not drawing correctly at the moment...
I've updated the Shapes to use the new vertices code. At least the parallelogram and trapezium are not drawing correctly at the moment...
Wednesday, April 20, 2011
Tuesday, April 19, 2011
wumpus - new releases
Copperbox revision 2335.
Updates to the Wumpus-Core guide.
Copperbox revision 2336.
New releases:
wumpus-core-0.50.0
wumpus-basic-0.17.0
wumpus-drawing-0.3.0
wumpus-tree-0.15.0
The major change to Wumpus-Core is the Picture API is no longer parametric on units.
Updates to the Wumpus-Core guide.
Copperbox revision 2336.
New releases:
wumpus-core-0.50.0
wumpus-basic-0.17.0
wumpus-drawing-0.3.0
wumpus-tree-0.15.0
The major change to Wumpus-Core is the Picture API is no longer parametric on units.
wumpus
Copperbox revision 2333.
I've removed round_corner_factors from the Drawing Context. I didn't like how this was arbitrarily applied to paths, so I removed it. To add rounded corners back to Shapes etc. I'll probably add extra constructors specifically for round corner version.
Also I've updated the demos in Wumpus-Drawing and updated the code and in Wumpus-Tree. Although the layers above Wumpus-Core are still not readily useful (they would be better off not being on Hackage) it's time the released versions were updated.
I've removed round_corner_factors from the Drawing Context. I didn't like how this was arbitrarily applied to paths, so I removed it. To add rounded corners back to Shapes etc. I'll probably add extra constructors specifically for round corner version.
Also I've updated the demos in Wumpus-Drawing and updated the code and in Wumpus-Tree. Although the layers above Wumpus-Core are still not readily useful (they would be better off not being on Hackage) it's time the released versions were updated.
wumpus-drawing
Copperbox revisions 2331 and 2332.
The new arrow tips now have all the functionality of the old tips, so I've removed the Wumpus.Drawing.Arrows modules.
Also I've added tip length to the the Arrow tip data type. To estimate good angles for tips on curved paths, you have to know the tip length (and halve it) rather than the retract distance. "Open" tips like barbs don't have a retract distance, so they were being drawn with the angle of the line end rather than the angle of the line at half the tip length - this doesn't look good on curved paths.
The new arrow tips now have all the functionality of the old tips, so I've removed the Wumpus.Drawing.Arrows modules.
Also I've added tip length to the the Arrow tip data type. To estimate good angles for tips on curved paths, you have to know the tip length (and halve it) rather than the retract distance. "Open" tips like barbs don't have a retract distance, so they were being drawn with the angle of the line end rather than the angle of the line at half the tip length - this doesn't look good on curved paths.
Monday, April 18, 2011
wumpus-drawing
Copperbox revision 2330.
I've reimplemented the arrow tips in the new style. The AbsPath builder turned out not to be useful for this, though the code is still an improvement on the previous version. The reason for this is prosaic - I'm now just more used to writing this sort of code.
I've reimplemented the arrow tips in the new style. The AbsPath builder turned out not to be useful for this, though the code is still an improvement on the previous version. The reason for this is prosaic - I'm now just more used to writing this sort of code.
wumpus-drawing
Copperbox revision 2329.
Initial work on new arrowheads.
I'd like the arrowhead code to be a lot simpler - probably by using the AbsPath builder. This work is the start.
Initial work on new arrowheads.
I'd like the arrowhead code to be a lot simpler - probably by using the AbsPath builder. This work is the start.
Sunday, April 17, 2011
wumpus-drawing
Copperbox revision 2327.
I've extended the monadic path builders with incline, and parallel and perpendicular relative moves and lines.
I've also added the derived operations to the AbsBuilder, though there are so many of them a class solution might be better.
I've extended the monadic path builders with incline, and parallel and perpendicular relative moves and lines.
I've also added the derived operations to the AbsBuilder, though there are so many of them a class solution might be better.
wumpus
Copperbox revision 2326.
I've implemented the first proper path vamp. Previously I'd only had a simulation that didn't account for the direction of the "span" vector.
The new vamp is the circle vamp, which might be the easiest vamp to think about. Accounting for the direction of the span vector will make rectangular vamps trickier.
I've implemented the first proper path vamp. Previously I'd only had a simulation that didn't account for the direction of the "span" vector.
The new vamp is the circle vamp, which might be the easiest vamp to think about. Accounting for the direction of the span vector will make rectangular vamps trickier.
wumpus-basic
Copperbox revision 2325.
I've added a PathAlg for proper arcs - i.e. that can handle interior angles greater than 90 degrees. This means I can finally add wedge paths to Wumpus - I've been meaning to do this for some time.
I've added a PathAlg for proper arcs - i.e. that can handle interior angles greater than 90 degrees. This means I can finally add wedge paths to Wumpus - I've been meaning to do this for some time.
wumpus-basic
Copperbox revision 2324.
Work on Path generation. The path representation here is just a list of vectors - a path algorithm - so these paths can be used by both the absolute and relative paths in Wumpus-Drawing to build polygons, circles and arcs, for instance:
Work on Path generation. The path representation here is just a list of vectors - a path algorithm - so these paths can be used by both the absolute and relative paths in Wumpus-Drawing to build polygons, circles and arcs, for instance:
wumpus
Copperbox revision 2323.
I've removed ScalingContext from Wumpus-Basic. It had become a loose end, as it's functionality is mostly superseded by snap-grid-factors in the DrawingContext.
The turtle drawing in Wumpus-Drawing was the main dependency and that's been updated. Wumpus-Tree will need checking.
I've removed ScalingContext from Wumpus-Basic. It had become a loose end, as it's functionality is mostly superseded by snap-grid-factors in the DrawingContext.
The turtle drawing in Wumpus-Drawing was the main dependency and that's been updated. Wumpus-Tree will need checking.
Saturday, April 16, 2011
wumpus-rhythm
Copperbox revision 2322.
I've updated Wumpus-Rhythm to use the new pivot paths, which work very well. This is reassuring as pivot paths were designed especially for the stems in Djembe notation.
I've updated Wumpus-Rhythm to use the new pivot paths, which work very well. This is reassuring as pivot paths were designed especially for the stems in Djembe notation.
wumpus
Copperbox revision 2321.
I've added pivoting to relative path building and a brace of "turtle" operations. Also I've renamed some of the displacement functions in Wumpus-Basic.
Pivoting gives the impression of drawing a path with its start point in the middle rather than at its left end:
I've added pivoting to relative path building and a brace of "turtle" operations. Also I've renamed some of the displacement functions in Wumpus-Basic.
Pivoting gives the impression of drawing a path with its start point in the middle rather than at its left end:
Friday, April 15, 2011
Thursday, April 14, 2011
wumpus-drawing
Copperbox revision 2319.
I've added in-line colour changing to monadic path building.
Strictly speaking, I've reimplemented in-line colour changing for RelPath, which had it when it built syntax (it now works directly), and added it to AbsPath which never had it.
I've added in-line colour changing to monadic path building.
Strictly speaking, I've reimplemented in-line colour changing for RelPath, which had it when it built syntax (it now works directly), and added it to AbsPath which never had it.
wumpus-drawing
Copperbox revision 2318.
I've made Vamp a data type and added a new module to fill out with a library of decorative paths vamps. Also I've fixed the moveto bug on relative paths mentioned in the previous post.
I've made Vamp a data type and added a new module to fill out with a library of decorative paths vamps. Also I've fixed the moveto bug on relative paths mentioned in the previous post.
wumpus-drawing
Copperbox revision 2317.
I've updated the monadic path builders so they both work in the same way. Unfortunately, as their states are rather different they can share very little code. Also, there's at least one bug in new code as relative paths don't seem to be handling moves and vamps properly.
I've updated the monadic path builders so they both work in the same way. Unfortunately, as their states are rather different they can share very little code. Also, there's at least one bug in new code as relative paths don't seem to be handling moves and vamps properly.
Wednesday, April 13, 2011
wumpus-drawing
Copperbox revision 2316.
I've resumed work on Paths after the interruption of the Tolerance changes.
The monadic builder for absolute paths has been updated to be more like the relative builder. However, the relative builder itself will change soon as will build with the monadic commands directly rather than interpreting syntax.
I've resumed work on Paths after the interruption of the Tolerance changes.
The monadic builder for absolute paths has been updated to be more like the relative builder. However, the relative builder itself will change soon as will build with the monadic commands directly rather than interpreting syntax.
wumpus
Copperbox revision 2315.
I've moved Tolerance into Wumpus-Core and made the Point2 and Vec2 Eq and Ord instances tolerant.
This was less invasive than I had thought it would be - if client code needs very accurate equality for Points it can wrap a unit as a new type and declare a Tolerance instance with high accuracy. Points or vectors themselves need no change or wrapping.
I've moved Tolerance into Wumpus-Core and made the Point2 and Vec2 Eq and Ord instances tolerant.
This was less invasive than I had thought it would be - if client code needs very accurate equality for Points it can wrap a unit as a new type and declare a Tolerance instance with high accuracy. Points or vectors themselves need no change or wrapping.
wumpus
Copperbox revision 2314.
I've changed the LengthTolerance class to Tolerance and added a member for equality - equality is expected to need more accuracy than length.
Note - the Tolerance class is probably better in Wumpus-Core than Wumpus-Basic, then Eq on Points and Vectors could be tolerant. However there might be cases where this behaviour is not wanted and I need to think about the consequences of doing this a bit more...
I've changed the LengthTolerance class to Tolerance and added a member for equality - equality is expected to need more accuracy than length.
Note - the Tolerance class is probably better in Wumpus-Core than Wumpus-Basic, then Eq on Points and Vectors could be tolerant. However there might be cases where this behaviour is not wanted and I need to think about the consequences of doing this a bit more...
Tuesday, April 12, 2011
wumpus-drawing
Copperbox revision 2313.
I've reorganized the Path modules as I'm about to redo the monadic construction modules - now called RelBuilder and AbsBuilder.
I've reorganized the Path modules as I'm about to redo the monadic construction modules - now called RelBuilder and AbsBuilder.
wumpus-basic
Copperbox revision 2312.
I've added a couple of simple composition operators to LocImage. Except for the type signatures these are equivalent to chain operators, however they are simpler to compute. Chains can do things that these LocImage operators can't of course - there is reason for them doing more computational work.
I've added a couple of simple composition operators to LocImage. Except for the type signatures these are equivalent to chain operators, however they are simpler to compute. Chains can do things that these LocImage operators can't of course - there is reason for them doing more computational work.
Monday, April 11, 2011
wumpus
Copperbox revision 2310.
I've tidied up Chains in Wumpus-Basic and updated the demos in Wumpus-Drawing to use the new Chains from Wumpus-Basic rather than the old ones from Drawing.
Copperbox revision 2311.
I've deleted the Chain modules from Wumpus-Drawing - they are superseded by the Chain module in Wumpus-Basic.
I've tidied up Chains in Wumpus-Basic and updated the demos in Wumpus-Drawing to use the new Chains from Wumpus-Basic rather than the old ones from Drawing.
Copperbox revision 2311.
I've deleted the Chain modules from Wumpus-Drawing - they are superseded by the Chain module in Wumpus-Basic.
wumpus-basic
Copperbox revision 2309.
I've changed the name of the module AdvanceGraphic to AdvObject so it is consistent with PosObject. Also, I've changed the primary concatenation operator from next to advance - next is too useful a name to purloin for an always exposed library function.
I've changed the name of the module AdvanceGraphic to AdvObject so it is consistent with PosObject. Also, I've changed the primary concatenation operator from next to advance - next is too useful a name to purloin for an always exposed library function.
wumpus-basic
Copperbox revision 2308.
I've reworked chains so they iterate some user defined state like unfoldr rather than just a point. The previous formulation made it difficult to implement circular chains:
I've reworked chains so they iterate some user defined state like unfoldr rather than just a point. The previous formulation made it difficult to implement circular chains:
Sunday, April 10, 2011
wumpus-basic
Copperbox revision 2307.
I've added a stepper primitive, which I called fork in the last post. Because the implementation was getting to complicated I've reverted to the inefficient but comprehensible point building function. The simple point builder may space bubble rather than space leak for pathologically constructed chains.
I've added a stepper primitive, which I called fork in the last post. Because the implementation was getting to complicated I've reverted to the inefficient but comprehensible point building function. The simple point builder may space bubble rather than space leak for pathologically constructed chains.
wumpus-basic
Copperbox revision 2306.
I've added a Chain demo and improved the interpretation function so it should produce elements properly on demand (previously it generated a prefix as a Hughes list).
The internals may change again though, as I want a fork primitive that runs a prefix chain then resumes at the prefix start point, rather than switch which runs the prefix chain and continues at the end point of the prefix.
I've added a Chain demo and improved the interpretation function so it should produce elements properly on demand (previously it generated a prefix as a Hughes list).
The internals may change again though, as I want a fork primitive that runs a prefix chain then resumes at the prefix start point, rather than switch which runs the prefix chain and continues at the end point of the prefix.
wumpus-basic
Copperbox revision 2305.
Initial work on a replacement for Chains - which I've put in Wumpus-Basic as Chains seem to be the analogue for LocGraphic, to Concat on PosObject.
Like DocText, I'm experimenting with making Chains syntax rather than functions, so they can have introspective composition operators.
Initial work on a replacement for Chains - which I've put in Wumpus-Basic as Chains seem to be the analogue for LocGraphic, to Concat on PosObject.
Like DocText, I'm experimenting with making Chains syntax rather than functions, so they can have introspective composition operators.
wumpus
Copperbox revision 2304.
More work to get Wumpus-Drawing up to date with Wumpus-Basic. All the demos in Wumpus-Drawing should now be working again.
Note - there is still quite a bit of commented out code in Wumpus-Basic, that was not polished up enough to actually be used (the composition operators for LocGraphic are the main ones). When I sort out chains, I'll have to sort out this code too.
More work to get Wumpus-Drawing up to date with Wumpus-Basic. All the demos in Wumpus-Drawing should now be working again.
Note - there is still quite a bit of commented out code in Wumpus-Basic, that was not polished up enough to actually be used (the composition operators for LocGraphic are the main ones). When I sort out chains, I'll have to sort out this code too.
Saturday, April 9, 2011
wumpus-drawing
Copperbox revision 2303.
More work updating Wumpus-Drawing to match the Wumpus-Basic changes. Chains and grids have been updated, although Chains are likely to be removed or substantially revised soon.
More work updating Wumpus-Drawing to match the Wumpus-Basic changes. Chains and grids have been updated, although Chains are likely to be removed or substantially revised soon.
wumpus-drawing
Copperbox revision 2302.
I've updated the shapes to work with the anchor changes in Wumpus-Basic.
I've updated the shapes to work with the anchor changes in Wumpus-Basic.
wumpus
Copperbox revision 2301.
First work updating Wumpus-Drawing to work with changes to Wumpus-Basic. Dots and DocText have been updated. Generally the changes were fairly minimal, although the elaborate and decorate functions now have to be an arity family - previously they worked as single definitions that used fmap to work on the underlying functors of the family of context functions CF1 CF2, CF3.
First work updating Wumpus-Drawing to work with changes to Wumpus-Basic. Dots and DocText have been updated. Generally the changes were fairly minimal, although the elaborate and decorate functions now have to be an arity family - previously they worked as single definitions that used fmap to work on the underlying functors of the family of context functions CF1 CF2, CF3.
wumpus-basic
Copperbox revision 2300.
More work updating to the new ContextFun representation.
I've reworked AdvanceGraphic so it follows the style of PosObject and tidied up the combinators.
More work updating to the new ContextFun representation.
I've reworked AdvanceGraphic so it follows the style of PosObject and tidied up the combinators.
Friday, April 8, 2011
wumpus-basic
Copperbox revision 2299.
I've changed the ContextFun representation removing the specific arity wrappers, so:
is now just a type where DrawingContext is still contained by the newtype CF:
I had this formulation last year, but felt I was introducing too many new combinators. However after the changes to PosObject, the old representation started to look simpler and more uniform. The arity versions hadn't been as uniform as hoped, with PosObject clearly not fitting the scheme at all.
At present quite a lot of code is stubbed, although the VerySimple example compiles.
I've changed the ContextFun representation removing the specific arity wrappers, so:
newtype CF1 r1 a = CF1 { getCF1 -> DrawingContext -> r1 -> a }
is now just a type where DrawingContext is still contained by the newtype CF:
type C1 r1 a = CF (r1 -> a)
I had this formulation last year, but felt I was introducing too many new combinators. However after the changes to PosObject, the old representation started to look simpler and more uniform. The arity versions hadn't been as uniform as hoped, with PosObject clearly not fitting the scheme at all.
At present quite a lot of code is stubbed, although the VerySimple example compiles.
Thursday, April 7, 2011
wumpus-basic
Copperbox revision 2297.
I've reworked the CtxPicture module. PosObject has compatible concat types, so I've been able to add an overloaded API again provided by the new module Concat. PosObject needs updating to provide instances of the Concat classes.
I've reworked the CtxPicture module. PosObject has compatible concat types, so I've been able to add an overloaded API again provided by the new module Concat. PosObject needs updating to provide instances of the Concat classes.
Wednesday, April 6, 2011
wumpus-drawing
Copperbox revision 2296.
I've updated the demos to work with the font loader changes in Wumpus-Basic.
I've updated the demos to work with the font loader changes in Wumpus-Basic.
wumpus
Copperbox revision 2295.
I've added support for bold and italic in DocText. To the user these are simple operations - they work with the bold and italic weights of the current "font family" which abstracts away from having to know the font name for the bold weight. I've had to change the font loader in Wumpus-Basic to accommodate the idea of "font family", so some demos will currently be broken.
I've added support for bold and italic in DocText. To the user these are simple operations - they work with the bold and italic weights of the current "font family" which abstracts away from having to know the font name for the bold weight. I've had to change the font loader in Wumpus-Basic to accommodate the idea of "font family", so some demos will currently be broken.
Tuesday, April 5, 2011
wumpus
Copperbox revision 2294.
I've added background highlighting to Doc Text and made vertical alignment Doc combinators rather than rendering functions. This has meant changing the vertical PosObject concat combinators - they were stacking above, when they should stack below.
I've added background highlighting to Doc Text and made vertical alignment Doc combinators rather than rendering functions. This has meant changing the vertical PosObject concat combinators - they were stacking above, when they should stack below.
wumpus-drawing
Copperbox revision 2293.
Initial work adding underline and strikethrough text effects to Doc Text.
Interpretation is now back in a monad - for once going from the pure world to the monadic one is actually a relief as it justifies the use of syntax in DocText rather than direct combinators.
Initial work adding underline and strikethrough text effects to Doc Text.
Interpretation is now back in a monad - for once going from the pure world to the monadic one is actually a relief as it justifies the use of syntax in DocText rather than direct combinators.
wumpus-drawing
Copperbox revision 2292.
More work on Doc text. I've re-instated mono-spaced number printing - though all the "core 12" fonts have even width numbers anyway.
More work on Doc text. I've re-instated mono-spaced number printing - though all the "core 12" fonts have even width numbers anyway.
Monday, April 4, 2011
wumpus-drawing
Copperbox revision 2291.
I've updated Text so it works with the changes to PosObject. DocText is now so direct that it hardly merits building syntax - I'll have to think of some features to add to justify building syntax rather than using the PosObject combinators. Not using PosObject directly does mean that it's harder to create documents with bizarre formatting, though that's a bit of a meek reason to favour the status quo.
I've updated Text so it works with the changes to PosObject. DocText is now so direct that it hardly merits building syntax - I'll have to think of some features to add to justify building syntax rather than using the PosObject combinators. Not using PosObject directly does mean that it's harder to create documents with bizarre formatting, though that's a bit of a meek reason to favour the status quo.
wumpus-basic
Copperbox revision 2290.
I've added padding (aka fill) directly to the PosObject. This is the problematic operation for DocText, so moving it to PosObject should allow a simpler evaluation of DocText.
I've added padding (aka fill) directly to the PosObject. This is the problematic operation for DocText, so moving it to PosObject should allow a simpler evaluation of DocText.
wumpus-basic
Copperbox revision 2289.
I've changed the representation of PosObject so it always returns the BoundingBox of its orientation. This makes it easier to extend the shape (or pad it) as only the orientation and (possibly) the movement vector need changing. The resulting bounding box is calculated at rendering time.
The only real use case I have for PosObject needed the result to a bounding box, so this is no real loss of expressiveness.
I've changed the representation of PosObject so it always returns the BoundingBox of its orientation. This makes it easier to extend the shape (or pad it) as only the orientation and (possibly) the movement vector need changing. The resulting bounding box is calculated at rendering time.
The only real use case I have for PosObject needed the result to a bounding box, so this is no real loss of expressiveness.
wumpus-basic
Copperbox revision 2288.
I decided that the PosObject was wrong after all and its now modified so the same DrawingContext is passed to the evaluation of the orientation and the graphic function.
In practice, this hasn't actually improved matters for DocText in Wumpus-Drawing - it seems that evaluating a Doc's orientation with the DrawingContext of the EvalM monad is just the wrong thing to do.
I decided that the PosObject was wrong after all and its now modified so the same DrawingContext is passed to the evaluation of the orientation and the graphic function.
In practice, this hasn't actually improved matters for DocText in Wumpus-Drawing - it seems that evaluating a Doc's orientation with the DrawingContext of the EvalM monad is just the wrong thing to do.
Sunday, April 3, 2011
wumpus-drawing
Copperbox revision 2287.
I've improved DocText so the passing of updates to the DrawingContext from the Doc evaluation is not so drastic - previously the whole DrawingContext was copied, or perhaps just shared but even so it seemed wrong.
Apropos the comment in the last post - I'm not sure that PosObject is wrong per se, but it does seem to be much less generally useful than I originally hoped.
I've improved DocText so the passing of updates to the DrawingContext from the Doc evaluation is not so drastic - previously the whole DrawingContext was copied, or perhaps just shared but even so it seemed wrong.
Apropos the comment in the last post - I'm not sure that PosObject is wrong per se, but it does seem to be much less generally useful than I originally hoped.
wumpus-drawing
Copperbox revision 2286.
I've re-implemented DocText as an interpretation like the new relative path drawing. This means I can implement left and right fills properly. One problem, at the moment, is that the code to change drawing properties is convoluted - this indicates that the PosObject in Wumpus-Basic is not right.
I've re-implemented DocText as an interpretation like the new relative path drawing. This means I can implement left and right fills properly. One problem, at the moment, is that the code to change drawing properties is convoluted - this indicates that the PosObject in Wumpus-Basic is not right.
wumpus-drawing
Copperbox revision 2285.
I've added curveto operation and replaced pen-up and pen-down with moveto. I wonder how I didn't initially spot that moveto is as expressive as pen-up / pen-down, less complicated and already present in PostScript...
Also I've added "vamps" on paths - these are basically a moveto combined with a drawn decorative path. Only the moveto forms part of the accumulated path - the dotted square in the doodle below is drawn with a vamp:
I've added curveto operation and replaced pen-up and pen-down with moveto. I wonder how I didn't initially spot that moveto is as expressive as pen-up / pen-down, less complicated and already present in PostScript...
Also I've added "vamps" on paths - these are basically a moveto combined with a drawn decorative path. Only the moveto forms part of the accumulated path - the dotted square in the doodle below is drawn with a vamp:
Saturday, April 2, 2011
wumpus-drawing
Copperbox revision 2284.
I've extended the path command syntax to include multiple segments with DrawingContext changes. This allows paths to change pen colour, line width etc. "during" drawing:
I've extended the path command syntax to include multiple segments with DrawingContext changes. This allows paths to change pen colour, line width etc. "during" drawing:
wumpus-drawing
Copperbox revision 2283.
I've added pen-up and pen-down commands for drawing relative paths. This means the drawing of stroked paths can be broken and resumed - this is something I've not been able to model with a more functional approach. Hopefully this increases the expressiveness of path drawing quite a bit - enough to compensate for the representation change of building with commands rather than functions.
I've added pen-up and pen-down commands for drawing relative paths. This means the drawing of stroked paths can be broken and resumed - this is something I've not been able to model with a more functional approach. Hopefully this increases the expressiveness of path drawing quite a bit - enough to compensate for the representation change of building with commands rather than functions.
wumpus-drawing
Copperbox revision 2282.
Initial work on building relative paths.
Currently paths are built with commands that are interpreted rather than combinators. This might turn out to be simpler - the monad that interprets the commands is quite complicated, and it should be more memory efficient (whether or not this will matter much in practice). At the moment the code can just extend the path and decorate the path with insert patterned after the TikZ command of the same name.
Initial work on building relative paths.
Currently paths are built with commands that are interpreted rather than combinators. This might turn out to be simpler - the monad that interprets the commands is quite complicated, and it should be more memory efficient (whether or not this will matter much in practice). At the moment the code can just extend the path and decorate the path with insert patterned after the TikZ command of the same name.
Friday, April 1, 2011
wumpus-core
Copperbox revision 2281.
I've exposed relative path building functions in the Picture API. Internally, paths are relative in Wumpus-Core but I'd overlooked building them directly in the API.
I've exposed relative path building functions in the Picture API. Internally, paths are relative in Wumpus-Core but I'd overlooked building them directly in the API.
wumpus-drawing
Copperbox revision 2280.
It looks like a relative path is merited. The current path models building a connector between known points, but it is doesn't work for building paths that might want to be drawn as a LocGraphic. This would be the job for a relative path that builds when supplied a start point.
I've renamed the Base module in Drawing.Paths to Absolute so relative alternative can be added.
It looks like a relative path is merited. The current path models building a connector between known points, but it is doesn't work for building paths that might want to be drawn as a LocGraphic. This would be the job for a relative path that builds when supplied a start point.
I've renamed the Base module in Drawing.Paths to Absolute so relative alternative can be added.
Subscribe to:
Posts (Atom)
Blog Archive
-
▼
2011
(650)
-
▼
April
(81)
- zsyn
- wumpus
- wumpus
- wumpus-basic
- wumpus-basic
- wumpus-tree
- wumpus-tree
- wumpus
- wumpus-drawing
- wumpus
- Max Mathews
- wumpus-basic
- wumpus-basic
- wumpus-basic
- wumpus-basic
- wumpus-drawing
- wumpus
- wumpus-basic
- wumpus-basic
- wumpus-basic
- wumpus
- wumpus-drawing
- wumpus-basic
- wumpus-drawing
- wumpus
- zsyn
- zsyn
- wumpus - new releases
- wumpus
- wumpus
- wumpus-drawing
- wumpus-drawing
- wumpus-drawing
- wumpus
- wumpus-drawing
- wumpus
- wumpus-basic
- wumpus-basic
- wumpus
- wumpus-rhythm
- wumpus
- wumpus
- wumpus-drawing
- wumpus-drawing
- wumpus-drawing
- wumpus-drawing
- wumpus
- wumpus
- wumpus-drawing
- wumpus-basic
- wumpus
- wumpus-basic
- wumpus-basic
- wumpus-basic
- wumpus-basic
- wumpus-basic
- wumpus
- wumpus-drawing
- wumpus-drawing
- wumpus
- wumpus-basic
- wumpus-basic
- wumpus-basic
- wumpus-basic
- wumpus-drawing
- wumpus
- wumpus
- wumpus-drawing
- wumpus-drawing
- wumpus-drawing
- wumpus-basic
- wumpus-basic
- wumpus-basic
- wumpus-drawing
- wumpus-drawing
- wumpus-drawing
- wumpus-drawing
- wumpus-drawing
- wumpus-drawing
- wumpus-core
- wumpus-drawing
-
▼
April
(81)
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.