Hurdle

Copperbox revision 1062.

A round of renaming - the PECOFF parser is still pretty unkempt but I've improved it a little. It looks like the the function names in my VC++ test DLL are in the .rdata section, currently I've no idea how the data here is laid out as it isn't in the PECOFF spec.

Hurdle

Copperbox revision 1061.

I've changed the COFF parser to use the do-notation.

I've decided I prefer having intermediate names for the parse results rather than long applicative chains. This is because I'm finding the specifications for binary formats too lax for my taste - for instance the PECOFF spec doesn't mention the IMAGE_DOS_HEADER - it doesn't have to as it isn't strictly part of the format, but the IMAGE_DOS_HEADER is at the start of all DLLs - what documentation actually specifies this? No doubt it exists but I certainly can't easily find it.

Similarly for (ar) archive files, the only full spec I could find was for AIX Unix. It looks like GNU ar uses the same conventions, but where do I get a definitive answer from rather than my own conjecture?

Hurdle

Copperbox revisions 1058, 1059 and 1060.

I've renamed the Pecoff source folder to Coff. The object files inside MinGW .a files are in pe-i386 format which is COFF (though without the header of Windows PECOFF files); so I might as well reuse the PECOFF machinery to look inside them.

Hurdle

Copperbox revision 1057.

Hurdle now peeks into ar archive files properly - I was interpreting a document wrongly in the last revision and expecting a symbol table to appear before the archives.

Hurdle

Copperbox revision 1056.

I've started work adding support to peek into ar files - however I'm finding the documentation on them very frustrating.

Mullein

Copperbox revision 1055.

A minor round of changes. I wanted to check that Mullein builds with GHC 6.12.1 and I've removed the dependency on Groupoid.

OpenVG

Copperbox revision 1054.

The VG demo is working again. Next stop is looking at how the OpenGL binding handles enums etc.

OpenVG

Copperbox revision 1051.

OpenVG, the now higher-level package, has been updated to use OpenVGRaw for the actual FFI calls.

Revisions 1052 & 1053 - some repository admin, moving and deleting obsolete code.

OpenVGRaw

Copperbox revision 1050.

More work on the Raw package. All the bits are seemingly in place, so the next move is to change the OpenVG 'high-level' binding to use OpenVGRaw.

OpenVGRaw

Copperbox revision 1049.

I've now added wrapper / export modules corresponding to all the modules in the original binding.

OpenVGRaw

Copperbox revision 1048.

I've added some module that partition the exports provided by Raw.VG.Core101. These correspond to the modules in the old binding Blending, DrawingContext etc.

OpenVGRaw

Copperbox revision 1047.

I've started to remake the OpenVG binding to follow Sven Panne's 'Raw' convention - i.e. have one package implement the API 1:1 and a second package to add Haskell types, state vars etc.

Hurdle-0.2.0

Copperbox revision 1046.

A new release of Hurdle. It doesn't fix the problem parsing Visual C++ generated DLLs but it does print an error message acknowledging the problem.

As Hurdle depends on kangaroo, I've had to make a somewhat premature release of kangaroo.

Hurdle

Copperbox revision 1045.

Some work towards preventing the runtime exception that occurs when parsing VC++ generated DLLs. It almost looks like the sample DLL I'm using doesn't have an ".edata" section, but pexports copes fine and produces a .def file.

kangaroo

Copperbox revision 1044.

I've sorted a bug in the genericManyTill parser and made the opt parser backtrack on failure.

Hurdle

Copperbox revision 1043.

Hurdle almost working again now it has been changed to use Kangaroo, but it doesn't parse the export names for same reason (and the error on VC++ generated dlls is still present).

Hurdle

Copperbox revision 1042.

Hurdle can't seem to parse DLL's created with Visual C++. I've started to look at problem, the first step is I've changed Hurdle to use kangaroo so I can add logging to see where the parse fails.

SFont

Copperbox revision 1041.

I think I can now parse format 4 'cmap' sub tables. I know the cmap data is used match glyphs to code points, but I don't know how so.

kangaroo

Copperbox revision 1040.

I've changed the 'region' parsers - giving them Italian names (hopefully grammatically correct ones). The idea was to use the music terms 'da capo', 'dal segno' but they didn't quite fit my purposes so I contrived my own dalpunto, alfine (there is the musical term 'al fine') and alfermata.

alfermata is a new one - and alfine which was interecto had the wrong behaviour so it has been corrected.

1. dalpunto - 'from the point'
Run the parser within a region and return to where you came from.

2. alfine - 'to the end'
Run the parser within a region and jump to the right-end of the region after the parse.

3. alfermata - 'to the stop'
Run the parser within a region, the cursor remains wherever the parse finished.

SFont

Copperbox revision 1039.

I can parse one cmap subtable (only for type 4 subtables) but parsing many subtables is causing an out of range error (fonts can have many cmap subtables).

SFont

Copperbox revision 1038.

Work on the cmap table. At this point I feel my interest waning a bit as the specs aren't so explicit as to how various arrays are sized... I'll see if I get much further tomorrow as I could do with spending time on other things (Wumpus, OpenVG binding).

SFont

Copperbox revision 1037.

Compound glyph parsing now implemented. Whether either simple or compound parsing actually works is moot as I don't yet know how to extract particular glyphs.

SFont

Copperbox revision 1036.

I think I can now decode simple glyphs. The new code to do it is a lot sharper than the code in the original SFont, so I must be getting better.

SFont

Copperbox revision 1035.

I've simplified the syntax tree that represents the font tables. I now consider it a concrete syntax tree so anything like enumerating bit-fields can be done at a post-processing step rather than at parse time.

SFont

Copperbox revision 1034.

Some work on the glyf table.

SFont

Copperbox revision 1033.

I can now get to the text labels inside the 'name' table - I don't think I managed this with the original SFont or OTFont.

SFont and kangaroo

Copperbox revision 1032.

I've removed more old files from SFont so I can start to use Kangaroo as its parser machinery.

kangaroo

Copperbox revision 1031.

The MIDI example is now working with the new combinators. Quite a few of the combinators in the ParseMonad weren't implemented correctly either getting the index wrong or not putting the boundary region in a (virtual) stack.

kangaroo

Copperbox revision 1030.

More work on the example MIDI parser which is currently working (caveat - on well formed files), but doesn't use the runOn and region combinators.

kangaroo

Copperbox revision 1029.

I've devised quite a few new combinators to golf the MIDI parser - unfortunately the new ones seem to have problems parsing the MIDI track bodies at the moment.

kangaroo

Copperbox revision 1028.

I've added support for IEEE 754 floats to Kangaroo. The code is the same as I posted to the beginners list a few days ago so the effort wasn't wasted.

kangaroo

Copperbox revision 1027.

I've added a Reader-Writer-State top level module to Kangaroo. The implementation uses a triple for (r,w,s) and remains a plain state monad but sections the operations so ask only operates on r, tell on w, and get and put on s.

SFont and kangaroo

Copperbox revision 1026.

I've removed the old files from SFont and added a new error operation to Kangaroo that rewrites a low-level error e.g. a withinRegion failure with a specific message, much like Parsec's (questionMark).

kangaroo

Copperbox revision 1025.

Kangaroo is now big enough to replace the parse monad that I developed for SFont, so I now use it there. Unfortunately SFont really has some ugly code that I'm not sure what to do with.

kangaroo

Copperbox revision 1024.

I've now added the withinRegion operation - this is the important one as it enables random access. I've decided to allow it to only access regions within the current region rather than regions anywhere in the file. This is so that the nesting in the program reflects the region movement - i.e. the top level parser sees the whole file (array) and nesting within the parser nests the accessible regions with the array.

kangaroo

Copperbox revision 1023.

I've changed the parse state so it tracks both current position and 'end'. End isn't end-of-file per-se but end of region, which coupled with a function like local in the Reader monad will allow me to jump around the file.

kangaroo

Copperbox revision 1022.

More work on kangaroo. The MIDI example compiles again but doesn't work. I'd taken this out of run function of the Kangaroo monad, because I didn't need the result, but it I still need to perform the action.

  ; _rsz        <- hGetArray handle arr  (fromIntegral sz)

I'll put this line back in on the next commit.

kangaroo

Copperbox revision 1021.

I've made the parse monad parametric on user state rather than a transformer. IO is at the bottom of the Kangaroo so it can't be a 'proper' transformer. I tried to make it parametric with a transformer t that's obliged to be an instance of MonadIO but this was complicating things and I didn't really want a dependency on mtl anyway.

kangaroo

Copperbox revision 1020.

A bit of work on kangaroo. I think I'm going to have to turn the monad into a transformer, so I'm check-pointing the work now.

OpenVG binding

Copperbox revision 1019.

I've moved the Utils - Color and PathCommands out of the library proper and into the examples. Also started work improving the VG.Paths module.

Hurdle-0.1.0

Copperbox revision 1017.

Hurdle now can extract the dll name, so it can generate a correct .def file for dlltool. It can print ordinals or other things that pexports can. Maybe I'll add them sometime.

Copperbox revision 1018.

I've changed the cabal file to put Hurdle in System, previously it was in Graphics as I had copied pasted the initial text from elsewhere.

Hurdle

Copperbox revision 1016.

DLLexports is now called Hurdle - (H)askell (U)tility (R)egarding (DL)l (E)xports.

I've just to find the dll name in the binary before its ready for release. The dll name is visible in the binary file just before the function name exports, but I haven't worked out which RVA (relative virtual address) actually points to it yet.

OpenVG 0.4.0

Copperbox revision 1014.

Release archive for Hackage.


Copperbox revision 1015.

Deleted files NEWS as it is now called Changes.

OpenVG binding

Copperbox revision 1013.

unbits utility function now sorted out and renamed unbits32.

Paths remain...

OpenVG binding

Copperbox revision 1012.

More haddocking and error handling in VGU sorted out. Regrettably, I'd copied a large chunk of Sven Panne's HOpenGL code into the ErrorsInternal module in VG while I got my binding up and running. I had forgotten I was using this and hadn't attributed it either - I've now removed all Sven's code. Sincerest apologies to Sven.

The only outstanding work now is to rewrite bitwiseOr in Utils and sort out the Path.hs module.

OpenVG binding

Copperbox revision 1011.

More work on Haddock docs. Also the a couple of the matrix functions don't look very good in retrospect - bad type signatures, and the Paths module looks dodgy too.

OpenVG binding

Copperbox revision 1010.

Yet more haddock. I've now done Paint which I think was the largest remaining module.

OpenVG binding

Copperbox revision 1009.

More improvement to the haddock docs - alphabetically I'm up to Images.hs so there is still a lot to do.

OpenVG binding

Copperbox revision 1008.

Another round of point-free golf.

OpenVG binding

Copperbox revision 1007.

I've removed the Marshal and Unmarshal type classes that were only used internally and "tidied" some functions with a bit of point-free golf to keep things interesting.

OpenVG binding

Copperbox revision 1006.

A round of Haddock improvements, some modules done, plenty left to do though...

Changed the status from highly unstable to just unstable.

OpenVG 0.2.1 and 0.3.0

Copperbox revisions 1004 and 1005.

New revisions of the OpenVG bindings. One works with the OpenGL in the platform, the other uses the new split OpenGL packages.

kangaroo

Copperbox revision 1003.

I've extracted the Parser monad from DLLexports into a new library - kangaroo. Thus named because it supports jumping around (random access) during the parse.

DLLexports

Copperbox revision 1002

Finally I can get a list of exported function names from the .DLL.

DLLexports

Copperbox revision 1001.

Improvements to the random access parse monad.

DLLexports

Copperbox revision 1000.

Hardly a milestone commit for the 1000, but DLLexports now uses a random access monad over an array rather than a bytestring. This is so it can jump about following RVA's - relative virtual addresses.

DLLexports

Copperbox revision 999.

More work on the pretty printer in DLLexports. Actually getting to the function names is taking some doing...

DLLexports

Copperbox revision 998.

I've started a new tool to extract DLL signatures vis pexports. I hoped it was going to be a one day job (at least to get something working), but its going to be a bit more than that.

Wumpus

Copperbox revision 997.

Wumpus-extra examples are now working with the latest data-aviary and wumpus-core.

lhs2TeX on Windows

I used lhs2TeX for the first time in ages today.

One thing I had forgotten was that pdflatex prefers files with Unix end-of-line[1] and was throwing this error:

! Undefined control sequence.
l.30   }\SkipToFmtEnd

? q
OK, entering \batchmode

A solution is to run dos2unix on the generated .tex file after running lhs2TeX:

 
$ lhs2TeX -o HelloWorld.tex HelloWorld.lhs
$ dos2unix HelloWorld.tex
$ pdflatex HelloWorld.tex

[1] Generally I use LaTeX and dvips, pvipdfm on Windows which seem agnostic about linefeed format.

Wumpus

Copperbox revision 996.

I've changed the argument orders for the ellipse and zellipse functions in Wumpus.Core.Picture.

It seems a bit tardy to upload this to Hackage, so work on wumpus-extra for the time being won't be compatible will the latest proper release of wumpus-core. Work on wumpus-extra will be compatible with wumpus-core-0.13.90 source - the revision currently heading the Subversion repository.

data-aviary-0.2.1

Copperbox revision 995.

A new release of data-aviary - some new combinators dup and the "combiners". Plus I've finally inter-defined the Data.Function function on.

Wumpus

Copperbox revision 994.

I've changed arrowheads to use the new Mark type class.

Wumpus

Copperbox revision 993.

I've made a new type class for drawing marks Mark that makes sizing dots via the "current" stroke width more convenient (of course there is no graphics state in Wumpus so the notion of current is a bit wonky).

Wumpus

Copperbox revision 992.

All the examples in wumpus-extra are working again. Plus tiny bit of work for drawing grids.

Wumpus

Copperbox revision 991.

More work on dots - I've been imitating TikZ's plot marks with a new drawing DotPic.hs.

Wumpus

Copperbox revision 990.

I've separated the coordinate generating functions into their own module in wumpus-extra and added a simple new one to generate calendar grids.

Wumpus

Copperbox revision 989.

Some work on backgrounds and an underwhelming new picture on Flickr:

http://www.flickr.com/photos/44929957@N03/

Wumpus

Copperbox revision 988.

More work on arrowheads - I've improved the bend function to make curves, but the curved arrow tip still isn't right.

Wumpus

Copperbox revision 987.

More work on arrowheads, though I'm still just tinkering as the way I'm constructing them doesn't feel right.

Wumpus

Copperbox revision 986.

I've started writing the manual for wumpus-core. The intention is to work on it when I get 'writers block' with wumpus-extra.

Wumpus

Copperbox revision 985.

I've added a new prototype arrowhead for 'hooks'. I'm still no clearer on how I should represent lines at a level above Wumpus.Core's representation, so the arrowheads are very much doodles at the moment.

wumpus-core-0.13.1

Copperbox revision 984.

Bug fix for SVG curve drawing - I was using the S path command in SVG when I should have been using C (C is the command that matches PostScript's curveto).

Plus some doodling with arrowheads which is how I found the bug.

Wumpus

Copperbox revision 983.

Trivial changes - all the license lines in wumpus-extra have been changed to 'BSD3'.

wumpus-core-0.13.0 and wumpus-extra0.5.0

Copperbox revision 982.

Wumpus core and extra release archives. Core is Hackage bound as the version currently on Hackage is a lot more hokey than I realized.

Wumpus

Copperbox revision 981.

I've re-implemented multilabel in Core.Picture and updated wumpus-extra to work with the latest wumpus-core.

Wumpus

Copperbox revision 980.

Last bit of haddocking for wumpus-core. Tomorrow I'll make a new release for Hackage.

Wumpus

Copperbox revision 979.

More haddock docs for wumpus core - two modules to go. I've also divided Core.TextEncoding into two modules, one for the 'outside world' interface and the other for internal functionality.

Wumpus

Copperbox revision 978.

And more haddock docs for wumpus-core. Still three and a half modules to go.

Wumpus

Copperbox revision 977.

More Haddock docs for wumpus-core.

Wumpus

Copperbox revision 976.

More Haddock docs for wumpus-core, plus unifying the license clause in all the source files.

Wumpus

Copperbox revision 975.

More Haddock docs for wumpus-core. Plus improvements to VectorSpace instances of Wumpus.Core.Colour.

Wumpus

Copperbox revision 974.

First round of haddocking wumpus-core. The version on Hackage has quite a bit of documentation but it isn't comprehensive.

wumpus-core-0.12.0 and wumpus-extra-0.4.0

Copperbox revision 973.

I've made new releases of wumpus-core and wumpus-extra. I'm going to upload this revision of wumpus-core to Hackage. I've made a download of the wumpus-extra release available on Copperbox as it is too rough for Hackage.

Wumpus and data-aviary-0.2.0

Copperbox revision 972.

I've got wumpus-core, wumpus-extra and data-aviary all working together (as wumpus-core is now pretty stable wumpus-extra only needed one change).

Data-aviary-0.2.0 is Hackage bound, then I can look at writing a summary for wumpus-core and uploading that too.

Wumpus

Copperbox revision 971.

Wumpus optimized!

Wumpus now generates efficient (straight line) PostScript. The only calls to gsave and grestore are now bookends of the file (which is necessary for EPS files). Changing the CTM or the graphics state no longer needs to be done in gsave ... grestore block - changes to CTM are undone by applying the matrix inverse of the transformation on exit of a 'block' this is much more efficient than putting the graphics state on the stack. Similarly, changes of stroke width, dash pattern, ... are undone after a path is drawn.

Colour and font changes are slightly different - here Wumpus uses the fact that all leaves in the tree have a colour attribute and all label leaves have a Font attribute. Wumpus can avoid an undo because the next leaf will do a set-property anyway.

With a bit of tidying up and checking that the examples in wumpus-extra still work, wumpus-core should be ready for Hackage.

Wumpus

Copperbox revision 970.

Dash patterns sorted for SVG output. Dash patterns in SVG are equivalent to PostScript as far as Wumpus is concerned: a list of on-off lengths and a start offset that discards an initial length.

Wumpus

Copperbox revision 969.

Minor changes, but the point calculating functions for matrices now feel right so are worth committing. The names are currently a bit clunky though.

Wumpus

Copperbox revision 968.

Some more work on colour charts, though I still don't have the abstraction right when I'm calculating points.

Wumpus

Copperbox revision 967.

I've added a new demo in wumpus-extra to draw colour charts for the X11 and SVG colours.

Wumpus

Copperbox revisions 965 and 966.

More work on scatter plots overlays are working to a degree, but the code still isn't very good. Plus some new work to print colour charts.

Wumpus

Copperbox revision 964.

Initial work on a module for drawing scatter plots. It's not too sparkling at the moment as I can't have data sets super-imposed on each other.

I've been trying to draw this one, but as each layer changes the frame according to the data I can currently only render one colour per plot.

http://en.wikipedia.org/wiki/File:Anderson's_Iris_data_set.png

wumpus-core-0.11.0 & wumpus-extra-0.3.0

Copperbox revision 963.

New release archives for wumpus-core and wumpus-extra. I've made the archives at the same time this time, so I know they are working together (the last wumpus-core archive had neither a revision version or a release archive of wumpus-extra that worked with it).

Wumpus

Copperbox revision 962.

Latin1 extended characters are now implemented for SVG as well (the last commit implemented them for PostScript).

The admittedly simple test in LabelPic.hs shows the implementation works.

Wumpus

Copperbox revision 961.

I've extended the PostScript monad to be a ReaderT carrying the TextEncoder lookup table. This should mean Latin1 text is now implemented for PostScript. I haven't tested it yet as if still to extended the SVG monad.

Wumpus

Copperbox revision 960.

More work on enabling Latin1 extended characters - hopefully the work is general enough to allow other encodings using the same mechanisms.

I think all the code is now in place, except for extending the PostScript and SVG monads with ReaderT so they can take a consult TextEncoder during operation. A TextEncoder is a pair of functions for translating extended character directives between the named representation (PostScript) and the integer code representation (SVG).

Wumpus

Copperbox revision 959.

I've started work on extending wumpus-core to handle extended characters. I plan to do this very simplistically, not using much more than a lookup table to get either integer character code for SVG or character name for PostScript, plus a minimal tokenizer that interprets text labels looking for special character directives (the intention being to use XML style directives following SVG).

Wumpus

Copperbox revision 958.

I've moved the decent bounding box calculation for text labels from Wumpus.Extra.Text to a new module Wumpus.Core.Font. This obliges a Fractional constraint on the DUnit of all pictures, but is otherwise a good improvement.

Wumpus

Copperbox revision 957.

I've implemented OpenGL style joining points (lines, loops, triangle strips). The implementation is a bit deficient compared to OpenGL - triangle strips and fans have too sharp edges and there is no way to interpolate colour changes or whatever during the drawing.

Wumpus

Copperbox revision 956.

Changes to get wumpus-core and wumpus-extra in sync. I've advanced wumpus-core since the 0.10.0 archive which isn't ideal as there was no commit of wumpus-extra that worked with it. But there was an interface change that I'd missed for quite a while, so I decided to do it now while it was on my mind.

wumpus-core-0.10.0

Copperbox revision 955.

I've made a new release archive for wumpus-core. Outputting PostScript and SVG has been generalized so that the unit type (of points, line widths etc.) does not have to be a double.

Wumpus

Copperbox revision 954.

Various minor changes to wumpus-extra. I started work on drawing lines from vertex lists as-per OpenGL's GL_POINTS, GL_LINES etc, however its somewhat complicated as simple analogues to the GL operations would create objects of different types (pictures, paths, lists of paths).

Also I want the Path and PathSeg types in wumpus-core to hide their constructors, this has meant changes to quite a few modules in wumpus-extra.

Wumpus

Copperbox revision 953.

I've fixed a bug in SVG output for circles and ellipses where I was emitting attributes x and y for the center point. Seemingly I should have been using cx and cy.

Wumpus

Copperbox revision 952.

I've simplified wumpus-core so it just outputs RGB in the genereated PostScript. Other colour formats (HSB and gray scale) are converted to RGB before printing.

At some point I'll have to make the PostScript output more efficient regards graphics state changes for colours and line styles. Having the graphics state data types as simple as possible will be helpful for this.

Wumpus

Copperbox revision 951.

Somw work on regular polygons. I've made the circular function which generates equal spaced points on a circle more regular.

Wumpus

Copperbox revision 950.

I've added module signatures to the Wumpus.Geometry modules in wumpus-extra. I've also factored some operations into type classes.

wumpus-core-0.9.0

Copperbox revision 949.

I've made a new release of wumpus-core, changing the Boundary class to use the DUnit type family and hiding a function (extractFrame). Methinks the version numbers of wumpus-core are cursed to get very large with the current way I'm developing it as the changes are getting minor, but I like having it compiled to run wumpus-extra against.

Wumpus

Copperbox revision 948.

Work on better bounding boxes in wumpus-extra. The new text label functions (textline and colouredTextline) use metrics from Courier to calculate a more accurate bounding box.

Wumpus

Copperbox revision 947.

I've started a new module Wumpus.Extra.Text that will include better calculations for a text label's bounding box. Its minimal at the moment as most of my energy has gone into a bit of hand-crafted PostScript - wumpus-extra/doc/courier48.ps. This file does some of the guesswork on bounding Courier - I'm only going to address Courier as it's a fixed width font.

Wumpus

Copperbox revision 946.

I've extended the FontAttr data type in wumpus-core so it can handle SVG style attributes (e.g. italic, bold, oblique). This means that the safe fonts in wumpus-extra are now 'safe' except for the a caveat on Symbol which renders in Chrome but not Firefox.

Wumpus

Copperbox revision 945.

I've added a module for SafeFonts to wumpus-extra. 'SafeFonts' are fonts that should be present in GhostScript / PostScript and SVG and at sizes present in PostScript - PostScript fonts only have certain sizes encoded e.g. 10pt, 12pt, 18pt, other sizes like 41pt can be achieved by doing an uniform scaling on the drawn text.

Due to SVG's font naming convention being completely different to PostScript most of the safe fonts aren't safe yet.

Wumpus

Copperbox revision 944.

Minor but useful work on dots. Its induced a couple of useful extra operations for Wumpus.Core.AffineTrans and clarified somewhat a useful construction mechanism - i.e. if we can do any affine transformations on the components of dots (points, line segments) before we assemble them into Wumpus Pictures, then the calculations are done in advance rather then transmitted to PostScript inside gsave ... grestore blocks.

wumpus-core-0.8.0

Copperbox revision 943.

I've made another release archive of wumpus-core so I can develop wumpus-extras against a frozen version. The examples in wumpus-extra are working again.

Hy-lists and Wumpus

Copperbox revision 942.

I've made added a cut-down OneList to Wumpus and removed the dependency on Hy-lists. The development of hylomorphisms was turning into a mania, so Hy-lists is kicked into touch for the time being.

hy-lists

Copperbox revision 941.

More work on hy-lists, although the hylomorphisms aren't really bootstrapped yet - i.e. I haven't got far enough to replace the (someFunctional . toList) compositions in Wumpus with hylomorphisms that do the two parts at once.

Hy-lists and Wumpus

Copperbox revision 940.

I've added some more functionality to hy-lists, mainly Foldable and Traversable instances for OneList.

The Picture type in wumpus-core has been changed again to make it a rose tree. Lists of child nodes are represented with OneList to prevent empty pictures being constructed. The change from binary tree to rose tree is so I can build multi-pictures - ones that share the same affine frame - more easily.

hy-lists

Copperbox revision 939.

I've started a new library / package for the minor lists snoc-list, one-list, ...

The salient feature of the library is that I'm trying to implement the list manipulations (filter, etc.) as hylomorphisms converting snoc-lists or one-lists to regular lists during the manipulation. There is a conceptual distinction between the construction of the inital snoc- and one-lists (which involves some restriction - non-empty for one-lists, suffixing for snoc-lists) and their subsequent manipulation.

The next step is seeing if non-empty one-lists work for the Multi constructor inside Wumpus's picture type.

joinlist-0.2.0

Copperbox revision 938.

I've made a new release of joinlist and uploaded it to Hackage - looking at the last release it was, ahem, not very good. This one at least improves things, though there are still quite a few functions that are a easy to add but not yet done (head, tail etc.) and I haven't done any test cases yet.

I've added a snoc list and a non-empty OneList to the joinlist project in Copperbox though I'll keep them away from Hackage for a bit.

Wumpus

Copperbox revision 937.

I've changed grid construction to be monadic in Wumpus-extra, though currently grids are still insubstantial as I haven't really formulated how to work with them.

Wumpus

Copperbox revision 936.

I've updated the examples in wumpus-extra to work with wumpus-core-0.7.0 and added a couple of picture transformers for clipping.

wumpus-core-0.7.0

Copperbox revision 935.

I've made a release archive of the current wumpus-core with the simplifications to the bounding box and picture types (no empty).

Also it now depends on algebra-0.0.0.1 rather than groupoid and I've reduced many of the associated types to a single type family DUnit, representing 'dimension'.

Wumpus

Copperbox revision 934.

I've simplified bounding box. As the last set of change altered the picture type (no empty Picture!), so bounding box no longer needs represent the empty bounds.

Wumpus

Copperbox revision 933.

I've simplified the Picture type so that it is non-empty. I thought this would make difficulties for the Picture Language (i.e. the module of picture composition operators), but this hasn't been the case.

The 'multiple' operations that layout series of pictures have been changed from [a] -> a to [a] -> a -> a. The simplest to explain is stack which overlays pictures on top of each other. Stack is now considered stackOnto and stacks a list of pictures onto a 'background' picture. By always having a background it doesn't matter if the list of pictures stacked onto it is empty - we will always have a picture (never an empty picture - which we can't construct).

This should simplify the obligations on bounding box as it never need represent the bounds of an empty picture - changing this is the next step.

I've also simplified the AffineTrans module to use a single type family declaration for the unit type of transformable things. Previously each class had its own associated type for the unit.

Wumpus

Copperbox revision 932.

I've added an example that throws an error when rendering due to it manipulating an empty picture. I'd known the empty picture was going to be a problem, but I've needed to construct enough functionality before feeling able to look at it. I think I'm going to need the picture tree type to be a non-empty tree. This might well simplify my bounding box problems but it won't be pain free; the list concatenation operations on the Picture language (stack, hcat, vcat) depend on the notion of an empty Picture. If I get rid of the empty Picture these operations will have to throw an error themselves on the empty list.

Wumpus

Copperbox revision 931.

I've added a module for drawing dots (the original Wumpus had quite a few dots so I've got a bit of code already written).

There's one problem though - the Multi constructor in Wumpus.Core.PictureInternal is meant to be a optimisation for drawing many primitives in one affine frame. Unfortunately + and X dots are both made of two independent line segments - they are multi-pictures already when multi-picture was supposed to represent many simple pictures (e.g. dots). I'm going to have to work out some trick (maybe dots as higher order functions) to accommodate many dots in one multi-picture.

Wumpus

Copperbox revision 930.

Another minor reorganization of wumpus-extra. I've split Geometry.Line into two modules: Geomtry.LineEquation and Geometry.LineSegment.

Wumpus

Copperbox revision 929.

I've reorganized wumpus-extra and little and brought all the examples up to date (they now run again).

wumpus-core-0.6.0

Copperbox revision 928.

I've made a release archive of the current wumpus-core, as the work on Core.PictureLanguage has significantly increased wumpus-core's functionality.

Wumpus-extra hasn't had much attention so I'm not going to make a release archive at the moment. Hopefully I can add quite a bit to wumpus-extra while leaving wumpus-core at 0.6.0.

Wumpus

Copperbox revision 927.

Quite a bit of work on the picture language, separators and alignment are now implemented. Also I've shrunk the number of functions in Core.BoundingBox's interface.

Wumpus

Copperbox revision 926.

More work on the picture language - some more combinators and I've finally got round to using some of the existing ones (which hadn't entirely been working as expected).

Wumpus

Copperbox revision 925.

I've simplified Core.Picture by having only one type family for the unit type of pictures (which is really the unit type of points - usually Double). Before I had horizontal (HUnit) and and vertical (VUnit) types. But as I've move these associated types out of their respective classes to become type families it seemed overcooked to have two different units.

Wumpus

Copperbox revision 924.

I've implemented hspace and vspace combinators for the picture language. Their implementation justifies adding Blank as a picture constructor.

The following simple definition of hspace is invalid:

-- > hspace n a b = a ->- (moveH n b)

The movement due to moveH n is annulled by the (->-) operator which moves relative to the bounding box. Somehow changing the bounding box of picture b seems more complicated than sandwiching a blank picture between them:

-- > hspace n a b = a ->- blankH n ->- b

Wumpus

Copperbox revision 923.

I've added a Blank constructor to the picture type. This is to implement composing pictures with gaps (vis hsep in PPrint). However I'm not convinced Blank is better than using pmove so this change might be repealed.

More usefully I have improved some of the naming and documentation in Core.PictureInternal.

Wumpus

Copperbox revision 922.

I've changed the composite typeclass to have functions over and beneath. These names better describe the (expected) behaviour than the previous composite.

Wumpus

Copperbox revision 921.

I've split Core.Picture into 2 modules - Core.Picture is now for user-level operations and Core.PictureInternal for the data types and type class instances. Outside Wumpus.Core the Picture data types should probably be opaque, but I haven't done this yet.

Also I've added bimap functions to data-aviary - previously called prod in fun-extras.

data-aviary-0.1.0

Copperbox revision 920.

I've tidied up and packaged up a release of data-aviary for Hackage.

data-aviary

Copperbox revision 919.

More work on the inter-defined combinators plus I've added a few 'prime' ones.

data-aviary

Copperbox revision 918.

I had assigned the wrong type to the vireo bird (and V* and V**) and hence had typing problems.

Now fixed in both Birds and BirdsInter.

data-aviary

Copperbox revision 917.

I've added a module of inter-defined bird combinators. This has been useful in spotting transcription errors, but it's brought up some problems with the definitions I'm using - particularly apply aka Haskell's ($) which seemingly has a definition as S (SK) but then has a typing problem and the V* and V** combinators.

I was hoping this would be a one-day job at least for the birds, but it isn't going to be.

data-aviary

Copperbox revision 916.

More work on the combinator birds.

I've worked out what I want the package to be - the Data.Aviary module is for combinators that have already escaped into the wild but aren't in 'standard' libraries. For example the (#) combinator in Wash, which is the thrush combinator bird. This is the module to include in programs. The Data.Aviary.Birds module is more a reference collecting as many combinators as I can type - it will need more comprehensive documentation of course. I'm not sure yet whether the pairing functions will have a place in this library or not.

data-aviary

Copperbox revision 915.

I've started a new package data-aviary to replace fun-extras. I aim to be a bit more systematic (and less subjective) in collecting combinators in data-aviary and when Wumpus is ready for Hackage, data-aviary should make a better companion library (the present incarnation of fun-extras could really be called stephens-favourite-functions and otherwise be rolled into Wumpus).

wumpus-core-0.5.0, wumpus-extra-0.2.0

Copperbox revision 914.

As the demos are currently working (if somehow unimpressive) I've made release archives of the current Wumpus parts.

Some changes to wumpus-core are due and I'd like a recent marker where things at least work.

Wumpus

Copperbox revision 913.

I've updated wumpus-extras do the examples run again. At this point I'd like to add an example SVG file but Blogger is thwarting me.

Wumpus

Copperbox revision 912.

I've tidied up the LabelPic example and got coloured text working in SVG output - this means using the span element inside a text element rather than trying to assign the colour to the text element itself.

Wumpus

Copperbox revision 911.

I've tidied up the interface provided by Core.Picture. The bad label functions - picLabel, picLabel1 - have been moved into the example LabelPic.hs where they are pending removal once I've something better.

I've also added a lot more instances for the builder smart constructor classes - Stroke, Fill, TextLabel and Ellipse - that create primitives and allow some eliding of default attributes.

Revision 910 was a mistake where I didn't run svn status and I hadn't put all the new changes in my local repository.

Wumpus

Copperbox revision 909.

Work tidying up Picture in wumpus-core. There was an oversight where ellipses could be created with open strokes, I've corrected this. More haddock docs though there is still plenty to do, also I need to do more instances for the smart constructors - the classes Fill, Ellipse, Stroke etc.

Wumpus

Copperbox revision 908.

I've finished tidying up Core.OutputSVG. Wumpus-core is getting pretty near 'prime-time'!

Wumpus

Copperbox revision 907.

I've done some tidying up work on the OutputSVG module in wumpus-core, though it's still a bit tardy and more tidying is due. I've implemented all the attributes for stroked paths except dash pattern, as I'm not sure how SVG dash patterns correspond to PostScript ones.

Also I've moved the circular function from wumpus-core to wumpus-extra as I think its doing the wrong thing (currently it is a transformer rather than a generator) and doesn't merit being in wumpus-core.

Clean, Sections, Partial Application

Got this one slightly wrong:

http://www.haskell.org/pipermail/haskell-cafe/2009-November/068820.html

Unhappy...

module nonsense

import StdEnv



nonsense = map (^ 2)

Start = nonsense [1,2,3]

Error [nonsense.icl,7,]: ^ first argument of infix operator missing

Happy...

module nonsense

import StdEnv



nonsense = map (flip (^) 2)

Start = nonsense [1,2,3]

"nonsense"
flip :: !.(.a -> .(.b -> .c)) .b .a -> .c
flip :: !.Int !.Int -> Int
nonsense :: .([.Int] -> .[Int])
Start :: .[Int]

Clean can partially apply functions (of course!) but it doesn't appear to support sectioning infix operators. Arrow maniacs might be concerned...

Wumpus

Copperbox revision 906.

The Core.SVG and Core.PostScript modules now have Haddock documentation for all (?) the exported functions.

Wumpus

Copperbox revision 905.

Wumpus-core - all modules now have an export list and all have the beginnings of Haddock documentation.

Wumpus

Copperbox revision 904.

A round of tidying on wumpus-core, though this is still plenty to clean up.

wumpus-core-0.4.0, wumpus-extra-0.1.0

Copperbox revision 902.

The examples in wumpus-core and wumpus-extra working are again, so I've made release archives of both these packages. I've let wumpus-core inherit the version number from Wumpus before the package split, otherwise I wouldn't feel like I was making progress.

Copperbox revision 903.

I've deleted the original Wumpus directory tree, now that Wumpus is split into wumpus-core and wumpus-extra.

Wumpus

Copperbox revision 901.

I've split Wumpus into two Cabal packages.

wumpus-core which is just the SVG and PostScript output, the picture language and basic geometry (points, vectors, frames, affine transformations, bounding boxes), i.e. enough to make pictures but no more.

wumpus-extras which is geometry above what is needed for SVG and PostScript (e.g. curves and lines in parametric representation), and composite objects built on top of wumpus-core (e.g. arrows, grids).

Hopefully wumpus-core should be stabilizing quite soon, though wumpus-extras won't. The examples in both packages are unlikely to work at the moment.


Copperbox revision 900.

The module Wumpus.Core.AffineTrans was missing from the repository - I've added it now. The examples in demo/Picture.hs and demo/LabelPic.hs should work, others won't.

Wumpus

Copperbox revision 899.

I've sorted out the coordinate changes for SVG including text which was previously upside down. Now SVG output and PostScript output should pretty much match.

Next up, I'm going to divide Wumpus into to cabal packages - one for Wumpus.Core which hopefully won't change much from now on; and the other for Wumpus.Extras and Wumpus.Geometry. This will probably mean Subversion commit numbers go a bit mad as I shift directory contents about.

Wumpus

Copper box revision 898.

I've implemented labelling for clipping paths in SVG output via a state monad.

Also I've attempted a change of coordinates transformation for SVG, as SVG considers the origin to be at the top left rather than the bottom left (PostScript and Wumpus). Unfortunately it doesn't work.

Wumpus

Copperbox revision 897.

First round of changes for work on monadifying SVG output. To generate clipping paths I need fresh labels, hence a monad.

Wumpus

Copperbox revision 896.

I've added alternative type classes to create filled and stroked paths. These lift a path to the Primitive data type (which is an intermediate of Picture) rather lift all the way up to a Picture (which the PicPath class does).

I don't intend keeping both alternative lifters so I'll have to see which is the most convenient to program with.

Wumpus

Copperbox revision 895.

I've added a Boundary type class to Core.BoundingBox, and made instances for the useful things - pictures, paths...

Wumpus

Copperbox revision 894.

I've changed the DrawProps data type so only strokes are attributed with pen styles (e.g. dash pattern, miter length). This matches PostScript's behaviour - fills just fill, strokes trace the boundary of a path with a pen.

Wumpus

Copperbox revision 893.

I've tidied up the path construction code in Core.Picture by adding two type classes PicPath and MultiPath that wrap up path attributes. I haven't done this for labels yet, as I'm wondering whether or not the current label type needs improving first.

The PicPath and MultiPath classes were inspired by the Node class in Iavor S. Diatchki's nice XML.Light library.

Wumpus

Copperbox revision 892.

A round of tidying up, I've added export lists to some core modules and put the affine transformations from Core.Geometry into their own module.

Wumpus

Copperbox revision 891.

I've made a minor tweak to the Path data type so that it isn't attributed with a drawing style (Fill, Stroke, ...). This is in line with the previous change that made a distinction between paths for clipping and paths for drawing.

Also, I've a clearer opinion on yesterday's changes to the Picture type. The Picture type changed from having attributes stored on both nodes and leaves to having attributes only on leaves. For generating PostScript it is better to have only nodes attributed then the number of gsave ... grestore blocks in the output can be minimized. However node attribution seems unnatural for construction, and I've decided that I prefer easy construction and 'not so good' PostScript. So yesterdays changes are satisfactory - at some point I could do a tree transformation to optimize the PostScript but I don't see that as a priority.

A few of the demos don't work any more, as I'm due to improve the path and picture constructors.

Wumpus

Copperbox revision 890.

I've changed the Picture type to make clipping more tangible - i.e. it should now be easier to account for clipping paths when considering the picture language operations (horizontal concatenation, etc.). PostScript output should support clipping, SVG output doesn't yet as I'll have to make it monadic to handle tagging with a counter for clip-path references.

I haven't done anything about the problems that yesterday's changes to the Picture type uncovered. I'm still thinking about the consequences.

Wumpus

Copperbox revision 889.

Some tidying up after the changes to the picture types.

Unfortunately I didn't fully work through the changes to the pictures types, and I've realized that in the current form I'll be sending a lot of redundant graphics state changes to PostScript. Essentially I've put all attribute data in the leaves of the tree (the picture type is a tree; paths, labels are the leaves); this is fine for SVG but not good for PostScript. With PostScript I use gsave ... grestore like local in Haskell's reader (environment) monad, but as I've distributed everything to the leaves effectively I'll only ever be running one command inside local.

Wumpus

Copperbox revision 888.

I've simplified the attributes on elements of the Picture type (paths, labels...). Currently this means I write quite a lot of redundant graphics state changes in the PostScript output - I plan to solve this by adding an environment to the Wumpus monad and only write the update when there is a difference with the current environment. The attribute changes do make writing SVG easier.

Wumpus

Copperbox revision 887.

I've made some more changes to SVG output code before I start work on changing the Picture types.

Wumpus

Copperbox revision 886.

A checkpoint commit - after this one I'm going to change some of the attributes in the Picture data types (again).

The salient feature of these changes is that SVG drawings are now scaled reasonably (but still in the wrong coordinate system). I shouldn't have been adding a viewPort attribute to the top level svg element.

Wumpus

Copperbox revision 885.

More work on SVG output particularly text labels, currently multiple lines are printed in the wrong vertical order. It looks like another difference between SVG and PostScript - coordinate (0,0) is bottom left in PostScript, from a cursor reading it looks like it is top left in SVG.

These arbitrary differences are really rather disappointing - should I simply transform the coordinate frame [1 0 0 -1] before creating the picture? It's easy for me to do, but potentially confusing for anyone deciphering their output if they're expecting normal SVG.

-- Update - the [1 0 0 -1] transformation won't work of course, as text (well, the Beziers and lines that make text) will be translated along with the location point, thus the characters will be printed upside down.

Wumpus

Copperbox revision 884.

More work on SVG output - pictures with frame transformations now draw, but they are huge. SVG evidently uses a different default unit to PostScript.

Wumpus

Copperbox revision 883.

I've started work on adding SVG output support to Wumpus. I was hoping not to bother with SVG, envisaging that there would be some readily available PS to SVG converters. The one I found had substantial dependencies when I installed it into Cygwin and although it worked I wasn't happy with the output, so I'm doing it myself.

Wumpus

Copperbox revision 882.

I've changed the bounding box type so it has a 'zero' element and thus can support monoid rather than groupoid.

I want to change the picture type slightly so it can support pictures that have some size but no content. This is to draw lines that have a parametric representation Ax + By + C = 0. To draw a line the function must supply an area for the line to be drawn in - if the line doesn't actually enter the area the function should still return a picture without content (but still with a bounding box). I don't want to make the picture type more complicated so I've shifted some of the complexity (bounding boxes of empty pictures) to the bounding box type.

Wumpus

Copperbox revision 881.

I've added collective import modules for the Geometry and Core libraries. Also I've started a new set of examples where I'm trying to replicate some of the examples in the Processing book.

Wumpus

Copperbox revision 880.

I've fixed the %%BoundingBox error in eps files. I've also done some tidying of the Core.OutputPostScript module.

Wumpus

Copperbox revision 879.

Wumpus can now output .eps files and multiple page PostScript documents (one picture per page).

Note to self - I've just noticed the EPS bounding box inside the %%BoundingBox comment is wrong.

Wumpus

Copperbox revision 878.

This is the first round of work towards getting the PostScript output to follow the DSC (Document Structure Conventions), it also includes the start of work on outputting EPS files.

Wumpus

Copperbox revision 877.

More picture combinators - centring one picture on top of another. Plus I've changed the lexical format of the infix combinators (always crucially important in Haskell) - the convention is the operator is enclosed in dashes e.g. centre -@-, place right ->- etc.

Wumpus

Copperbox revision 876.

I've extracted the picture composition code into a new module Core.PictureLanguage and made the operations over type classes rather than a concrete type (previously Picture). Then intention is that some of the operations will be applicable to other types - label text is the immediate candidate.

Wumpus-0.3.0

Copperbox revision 875.

I've added a release tar.gz of the current Wumpus. I'm about to re-work the Picture operators (<||>), (<..>) etc. so the function signatures in Wumpus.Core are going to change significantly.

Wumpus

Copperbox revision 874.

I've made ellipse a drawing primitive alongside path and label. This is for efficiency reasons. Circles can be simulated with Bezier curves but it takes 8 sections to get a reasonable approximation.

Adding arc to the primitive path type (with curve and line segment) would follow how PostScript works but it would make affine transformations on paths very difficult. Similarly finding the bounding box of a path would also be difficult.

Wumpus

Copperbox revision 873.

I've added some of the curve drawing code back in from the original Wumpus.

Wumpus

Copperbox revision 872.

I've differentiated between lines (infinite, described by their equation) and line segments (between two points) in the Geometry.Line module.

More golf...

Update - I submitted it after all, and as a message to self, I really should write emails for public distribution in a separate editor and proof read them properly before pressing send.

Old post begins...

Currently on haskell-beginners there's a thread 'list monad question' with more golf practice. I'd go further than the current pointfree version, but decided not to submit after typing it up. I'm not sure of the merits of posting incomprehensible code on a beginners list.

-- combinations :: Int -> [a] -> [[a]]
-- combinations = (foldr ((. (. (:)) . flip map) . (>>=)) [[]]  .) . replicate

-- The pointfree version can be golfed even further if you consider
-- some useful combinators not found in the standard libraries

combinations :: Int -> [a] -> [[a]]
combinations = foldr (<:>) [[]] `oo` replicate

-- | Applicative 'cons'.

(<:>) :: Applicative f => f a -> f [a] -> f [a]
(<:>) a b = (:) <$> a <*> b



-- | Compose an arity 1 function with an arity 2 function.
--
-- I call this combinator 'specs' (aka glasses) due to its infix
-- appearance `oo` 

oo :: (c -> d) -> (a -> b -> c) -> a -> b -> d
oo f g = (f .) . g

Wumpus

Copperbox revision 871.

Adding back some of the geometrical code that was in the original version of Wumpus, staring with operations on lines: creating them from vectors and points, calculating the midpoint...

Wumpus

Copperbox revision 870.

Changing the frame is working again. I've decided it make a lot more sense to communicate a change of frame immediately to PostScript (as a concat operation) as it is encountered during the top-down traversal. Trying to do the translations on the Haskell side was too flaky. It also generated more obscure PostScript, being much harder to map a sub-picture in the Haskell code to a sub-picture in the PostScript code.

Wumpus

Copperbox revision 869.

I've added substantial haddock docs describing the matrix representations used in Wumpus - Matrix3'3 in the core geometry module and CTM in the PostScript module.

For the record - Wumpus represents an affine frame as columns in a matrix whereas PostScript represents the frame as rows.

Wumpus

Copperbox revision 868.

I've change the order of parameters inside the Frame2 data type so they match the order of concatenation when constructing a matrix from a frame - i.e. the parameters are now (e0, e1, origin), rather than (origin, e0, e1).

I've also changed the matrix code to be more illustrative of the fact that I'm storing matrices in row-major form.

... I still have problems with calculating the correct CTM to send to PostScript though.

Wumpus

Copperbox revision 867.

I've made CTM a concrete datatype - this is so I can define the conversion from frames and 3x3 matrices to the CTM in one place, getting the presentation in the right order (column-major or row-major). That said I've a bit of research to do to verify which order the PostScript CTM actually is.

Wumpus

Copperbox revision 866.

I've added matrix inversion so I can invert the transformation on the affine frame, however it is still not working correctly.

Wumpus

Copperbox revision 865.

Affine transformations are currently working for paths as they are temporarily using pointInFrame and transforming each point before sending it to PostScript (as opposed to sending the calculated current translation matrix to PostScript with a concat command).

This does mean that labels are not transformed properly - I have no access to their paths/control points so cannot pre-translate them. They need to be evaluated in PostScript within the context of a concat command that has set the current translation matrix.

Wumpus

Copperbox revision 864.

I'm having trouble with affine frames again. I revised the rendering of the picture type so that instead of composing a function that represents a point in the current frame (and with function composition I had nested frames) I've gone to a first order representation and consider the affine frame as a transformation matrix. Unfortunately it isn't working correctly - rotations for instance go in the wrong direction. Time to check my geometry again...

Wumpus

Copperbox revision 863.

I've changed the picture type slightly to make multi-line labels easier to work with.

Wumpus

Copperbox revision 862.

Initial work on adding grids of nodes/labels. The matrix command is one of TikZ's most useful operations and it is something I'd want to provide an analogue of for Wumpus. It builds a grid of nodes that are addressable. Nodes can obviously have labels, and by being addressable they can be easily connected together with lines or arrows.

Wumpus-0.2

Copperbox revision 860.

I've made a release library of Wumpus - the main modules Core.Geometry, Core.Picture and Core.PostScript have taken shape and seem to be working. I haven't done any documenting or tidying for Haddock, but making a release now at least fixes the general functionality that these modules should have - extensions should go into other modules. Indeed, I moved the (currently rather superficial) polygon code out of Core.Picture into a new module for this release.

There was no Wumpus-0.1 release - the first version of Wumpus had more features than Wumpus-2.0 but it collapsed when I tried to make the picture type parametric over coordinate type to handle polar coordinates and I never packaged a release from it.


Copperbox revision 861

Adding a release tar.gz of fun-extras as Wumpus-0.2 depends on it.

Wumpus

Copperbox revision 858.

I've changed the font attribute so that an update from Wumpus changes both font name and size. GhostScript (if not PostScript generally) seems unhappy processing a change of either rather than both.

Copperbox revision 859 - removed Fun.hs from Wumpus.Core. This file should have been deleted yesterday.

Wumpus

Copperbox revision 857.

I've added the named colour modules that were in the original to the new Wumpus, and added a better function/interface for setting colours.

Wumpus

Copperbox revision 856.

I've changed how the picture type is labelled with graphics state update commands. The changes should make it easier to label pictures during construction.

Wumpus

Copperbox revision 855.

I've added graphics state changes to the label and path constructors of the Picture type, so now pictures can be coloured, have changes of line width etc. That said, I'm sure what a reasonable way of setting these attributes is going to be. Currently there is a simple prototype hack to change font properties but that isn't very good. As the picture type is really a tree, maybe I'll have to use downwards inheritance as per attribute grammars.

Wumpus

Copperbox revision 854.

First round of changes towards adding graphics state operations (colour change, line width change etc.) to the revised Wumpus.

The original Wumpus had a rather confused evaluation mechanism that attempted, via a reader monad, to track differences between the local graphics state and the world state during rendering and only transmit changes to PostScript. The new version has changed the environment data types of the original into 'update commands' that will instead be part of the syntax of pictures, paths and labels.

Wumpus

Copperbox revision 853.

Minor code restructuring after the directory restructuring - deleted all the unused functions from Core.Utils and put the code from Core.GraphicsState into Core.PostScript.

Wumpus

Copperbox revisions 849, 850, 851 & 852.

I've changed Wumpus, replacing the out-of-date original version with the code developed as Wumpus-alt. I rather messed up the commit as I should have run svn cleanup on my local copy, hence the three commits. Also I missed deleting Wumpus.Drawing.

Wumpus

Copperbox revision 848.

I've sorted out the overlapping instances problem on the affine transformation type classes.

Wumpus

Copperbox revision 847.

I've fixed the bug where label pictures were displaced wrongly after affine transformations - the problem was from calculating the wrong initial height of the label.

Wumpus

Copperbox revision 846.

An attempt to implement the full set of affine transformations on pictures - rotates, scales, translations (not yet shears!). There is a bug somewhere - pictures are displaced when they shouldn't be - possibly I am changing the origin in the affine frame when I shouldn't.

There's also a problem with the type classes - incoherent / overlapping instances - which needs fixing.

Wumpus

Copperbox revision 845.

Labels now respect the affine frame of the picture they are hosted in. This means they can now be moved and rotated.

Wumpus

Copperbox revision 844.

I've added initial support for text labels to Wumpus-alt's picture type. At the moment they aren't drawn with respect to their affine frame, I think I can solve this by deferring transformations (for labels only) to PostScript.

Wumpus

Copperbox revision 843.

More work on arrowheads and modifications to the picture type to better handle compounds of paths within the same affine frame.

Wumpus

Copperbox revision 842.

I've added the arrowheadVee drawing code from the original Wumpus to Wumpus-alt.

Wumpus

Copperbox revision 841.

I've changed the picture type in the revised Wumpus to be made from paths rather than polygons. This a better match to PostScript - it allows curves, choice of fill, stroke or clip etc.

Wumpus

Copperbox revision 840.

I've updated Wumpus to use fun-extras and added an extra combinator to fun-extras - twine. Twine maybe needs a name change - it is the dovekie or D2 combinator with the arguments reordered to be more Haskell-like.

fun-extras

Copperbox revision 839.

I've renamed pair-extras fun-extras so it can accommodate other functions that don't operate on pairs. It seems like the best place for the functions I commonly define for each project e.g. the specs.

pair-extras

Copperbox revision 838.

A cabalized library for the useful functions on pairs prod and fork, plus a few less useful functions.

Wumpus

Copperbox revision 837.

I've specialized the Picture type in the Wumpus-Alt to be polymorphic only on the unit type. Also I've tidied up the placement combinators.

Wumpus

Copperbox revision 836.

I've added a bounding box module to Wumpus-alt. It replicates the functionality of Wumpus.Core.BoundingBox, but removes the type classes. With reflection the type classes in Core.BoundingBox weren't right, but I don't want to change the old Wumpus code at the moment, when I'll looking to replace it altogether.

metric-space

Copperbox revision 835.

I've added a new library to represent metric spaces - i.e some set (Haskell Type) with an operation distance (d :: A -> A -> Real), though I've generalized the result from Real to an associated type.

I think I'll spare Hackage, at least until I have some noteworthy derived functions. My last contribution to Hackage - groupoid - was somewhat tardy.

Wumpus

Copperbox revision 834.

I've chosen the polygon-with-points implementation of pictures as the best version of the current round, so I've deleted the others. As this representation carries around affine frames to model displacement of one picture within a composite picture, it can also use the affine frames for transformations - i.e. transform the frame rather than the points within it. One of the examples uses this to rotate a line of squares.

Wumpus

Copperbox revision 833.

I've changed the picture type in the latest experiment to model displacement (from composition operators like (<>)) within an affine frame rather than with a displacement vector. This seems a bit more geometrical.

Wumpus

Copperbox revision 832.

Another version of the picture type - this time polygons are lists of points rather than lists of vectors. Naturally, affine transformations (here rotation) seem more natural on points, so this looks like the best of the three experiments.

Wumpus

Copperbox revision 831.

I've added rotation to the current toy picture type. It's not satisfactory, for affine transformations I'd be happier working on points rather than vectors - all the literature I've read on affine spaces uses points to illustrate the affine transformations rather than vectors.

I've also worked through a version of the (vector) polygon and picture types that use displacement from some common origin rather than displacement from the last point in the vertex list. Neither seem to make the affine transformations more tangible.

Wumpus

Copperbox revision 830.

I've extracted the core types and operations from Wumpus main into a geometry module for Wumpus-alt - points, vectors, matrices, affine transformations etc. Yesterdays experiment with Wumpus-alt suggests I can build pictures, but I need to be able to transform them as well.

Wumpus

Copperbox revision 829.

I've added a toy implementation of a new approach to vector drawing with a new the picture type. Currently it just has one geometric primitive (polygon) and one composition operator (<>) horizontal concatenation.

Its derived from Peter Henderson's original functional approach to pictures in that the primitives (polygons) are represented solely as vectors (no points not even an origin). Polygons are become pictures inside a binary tree which tracks the bounding rectangle (i.e. the coordinate free measures of width and height rather than alternate corners which would mean points and induce coordinates) of the child nodes and their displacement (again a vector). The only appearance of points so far is supplying the origin to the drawing / evaluation procedure. Adding other composition operators should be easy, but it remains to be seen whether this approach handles the affine transformations convincingly (scale, rotate, translate etc.).

MT

Copperbox revision 828

Interval multiset calculation.

MT

Copperbox revision 827.

I've reached a dead end with the current incarnation of Bala. The current examples do an adequate job of generating LilyPond, but they are poor models of music - the LilyPond output is shorter, more concise than the program code to generate it. So I'm going to work on something else - MT. I don't plan to make MT into a usable library, but keep it as a set of sketches translating some pieces of (mathematical) music theory into code. The first sketches are modules implementing the T/I (translation - inversion) and PLR groups.

Bala, JoinList

Copperbox revision 826.

Updates to Bala to use a new beat pattern notation. Added snoc and cons to joinlist.

Mullein

Copperbox revision 825.

I've updated Mullein to use the 'official' definition of the class Groupoid from Data.Groupoid.

groupoid-0.1.0

Copperbox revision 824.

I've been working on 1-dimensional geometry which hasn't been going too well, but it did make me finally package up my Groupoid class and put it on Hackage.

Bala

Copperbox revision 823.

I've added fret diagrams to the Blues example. This was done by making beat patterns parametric so they can carry chord names or drum beats.

Bala

Copperbox revision 822.

Some refactoring - I've taken the more general functions out of the example Blues.hs.

Bala and Mullein

Copperbox revision 821.

More work on LilyPond output - extra pretty printers and type to represent time signatures.

Bala and Mullein

Copperbox revision 820.

I've added a new Bala example Blues. The definition of the bass and melody is a good bit more compact than in Afoxe.

Mullein and Bala

Copperbox revision 819.

Minor tidying up - I've added a new type synonym StdGlyph that shortens a few type signatures. Also added a new LilyPond pretty printer for the override command.

Mullein and Bala

Copperbox revision 818.

Improvements to annotations in Mullein. For Mullein, annotations now seem to be adequate - following the examples in the module Extended its simple enough to create and render new annotations. Annotations don't place much burden on other code - I've got rid of a the MakeNote typeclass that was a burden previously.

Annotations in Bala are still unsatisfactory - I've added temporary functionality (distAnnos) to annotate notes after they have been assembled into tunes, but really I need a comfortable means* to annotate whilst I construct tunes.

* i.e. some means that lets me separate pitch content from string numbers at least til I want to zip them.

Mullein and Bala

Copperbox revision 817.

Some work on making annotations (e.g. string number, finger number) in Mullein more usable.

It still needs some working out - string number annotations in the Afoxe example are a long way off being exemplary.

joinlist-0.1.0

Copperbox revision 816.

I've added haddock docs and packaged up joinlist. To Hackage or not to Hackage?

It's slimmer on functionality than similar libraries (DList, RandomAccessList), but not as slim as the low-tide mark* ones.




* Struggling for a non-judgemental term here.

JoinList

Copperbox revision 815.

I've added a new library implementing a JoinList. The Kleene list in Bala was too complicated to traverse, a JoinList is simpler but it is still amenable to bottom-up construction.

Bala

Copperbox revision 814.

A new version of BeatPattern. This one is first-order and based on a novel sequence type - a Kleene list. Repetition, alternation and sequencing (concatenation) are represented as constructors in the list type so the representation is compact for beat patterns that have a very regular construction. Hopefully the Kleene list will be useful for building other patterned data such as the chord lists as working out abstractions for them has been a big struggle recently.

Bala

Copperbox revision 813.

I've added two type classes PitchContent and IntervalContent for extracting pitches and intervals from objects (e.g. chords, tunings and chord diagrams).

Bala

Copperbox revision 812.

I've added module signatures / export lists to all the modules.

Bala

Copperbox revision 811.

I've removed the RetroInt module which used to handle counting arithmetic distances. Arithmetic distance counting should be localized to the Interval module (but it isn't quite yet, so code in Pitch is due a refactoring).

Bala

Copperbox revision 810.

Further tidying up as per the previous comment.

Bala

Copperbox revision 809.

A round of tidying up on the Afoxe example, deleting redundant modules and moving useful functions from Afoxe.hs into library modules.

Bala

Copperbox revision 808.

Work making the Afoxe more compact by using 'expansion patterns' of the chord sequence. At the moment the expansion patterns aren't very tangible...

Mullein

Copperbox revision 807.

More work generalizing annotations (string number and fingering). Printing a string number annotation is now possible for any glyph type that has an instance of the HasStringNumber class (previously only TabGlyphs could be printed with string annotations). Finger numbers have been similarly generalized.

Mullein

Copperbox revision 806.

I've unwound note annotations in the glyph type. Previously the glyph type had two parameters pch and drn for Pitch and Duration. To represent say a note with string number the pitch would be wrapped with the string number, something like type SPitch = (Pitch,StringNumber). I've now separated out the pitch annotations so the glyph type now has three parameters.

Mullein and Bala

Copperbox revision 805.

I've changed the function that pretty prints glyphs - renderPhrase - to dispatch on a function passed in as an argument rather than a type class. This means particular glyph types can now be rendered in multiple ways - e.g. a note with string number for tablature can also be rendered as a normal note in standard notation.

Mullein and Bala

Copperbox revision 804.

I've renamed various functions now that the Mullein major version number has incremented. Also it looks like rendering to LilyPond or ABC (the function renderPhrase) will be more useful with a passed-in function for rendering glyphs rather than dispatch via a type class.

Mullein-0.3.0

Copperbox revision 803.

I've added a new release archive of Mullein that supports dividing into bars without beam grouping.

Mullein is due some API changes, so it seems wise to release the current version as is and bump up to the next version number. Note that the Afoxe example in Bala generates good LilyPond with this revision (803) , with 802 the LilyPond output ran but generated warnings.

Mullein and Bala

Copperbox revision 802.

Guitar tab is now mostly working - the output works, but there a LilyPond warnings as it is rendered. The warnings are due to stems interfering with each other even though they aren't printed. Mullein needs extending so that it can just segment music into bars rather than segmenting into both bars and pulsations (beam groups within bars).

Mullein and Bala

Copperbox revision 801.

Work towards supporting LilyPond guitar tab notation (still some more to do).

Bala and Mullein

Copperbox revision 800.

I've added SpacerMark as an alternative glyph type. This gives an easy mechanism to add fretboard diagrams to scores - a staff can be divided into two context one contains the melody as normal the other fretboard diagrams timed with spacer rests. This gives a useful separation between the fretboard diagrams and the melody - the diagrams don't have to be attached to a specific note (which would mean elaborating the glyph type with some annotation mechanism).

Bala and Mullein

Copperbox revision 799.

I've changed the examples Afoxe and BossaNova to output MIDI as well as notation from their LilyPond scores.

Bala2 - Bala

Copperbox revision 797 & 798.

I've replaced the original Bala (that worked with HNotate) with Bala2 (that works with Mullein). As Bala2 wasn't a proper Subversion branch I've just done a delete on Bala (revision 797) and a directory rename Bala2 to Bala (revision 798).

Bala2 and Mullein

Copperbox revision 796.

The bossa nova drum notation example now produces drum chords, so it is now working.

Bala2 and Mullein

Copperbox revision 795.

I've added a new example that to generate a bossa nova rhythm with LilyPond drum output.

It doesn't work properly at the moment as I need a mechanism to merge beat patterns into drum chords rather than list each one as an overlay.

Bala2

Copperbox revision 794.

Some tidying up - moving general functions out of the Afoxe example.

Bala2

Copperbox revision 793.

I've added a new module Bala.BeatPattern which is intended to replace Bala.RhythmPattern. BeatPattern takes a different view of specifying rhythms, which is a bit higher level. So far it seems easier to work with.

Bala2 and Mullein

Copperbox revision 792.

More work on the Bala2 examples. Afoxe now produces the output I want, thought the code to do it is desperate for some golfing. Also, I've changed the export modules for ABC and LilyPond in Mullein to bit a bit more careful vis name clashes.

Bala2

Copperbox revision 791.

I've made more use of streams in RhythmExample. The code is pretty dense (its not really clear how it works, or what its doing), but it is nearer to how I wanted it to work. I'll have to look at factoring it into some decent combinators which will increase readability.

Bala2 and Mullein

Copperbox revision 790.

More minor changes. I've added a duration module to Bala2.

Bala2 and Mullein

Copperbox revision 789.

Some minor changes, plus a bugfix to LilyPond chord output which was returning the wrong pitch as the initial state.

Bala2 and Mullein

Copperbox revision 788.

Work on the interface between Bala and Mullein - functions to covert Bala pitch and duration to Mullein pitch and duration, simple templates for music in free meter.

Bala2 and Mullein

Copperbox revision 787.

More work on rhythm patterns - I'm actually using the subset pattern with this revision (rather than ignoring it).

Mullein

Copperbox revision 786.

I've changed tie status to be a element of the Note and Chord constructors in the Glyph type, rather than have it as a separate constructor. This allows bracketing (beam grouping and bar splitting) to be oblivious of ties. Previously during bar splitting, ties were enqueue at the front of a new bar rather than at the end of an old bar.

Bala2

Copperbox revision 785.

I've reworked rhythm patterns - though the code is better, its not useful - it was easier to ignore the rhythm pattern in the example!

What I want to do is distribute pitch material over a rhythm with some fmap like device. At the moment I haven't discovered what a rhythm is (or a least how to usefully and succinctly define it).

Bala2

Copperbox revision 784.

I've added functions to generate scales and modes from a root pitch and some complementary functions to generate triad sets for major and minor scales.

Bala2

Copperbox revision 783.

Work on the chord building using the grammar presented in Francois Pachet:
An Object-Oriented Representation of Pitch-Classes, Intervals, Scales and Chords: The basic MusES.

I'm a bit unhappy with my implementation as it seems ambiguous in a couple of cases, I'll have to think about this code again and it might change significantly.

Bala2

Copperbox revision 782.

Initial work on chord and scale modules - a chord is a root note plus a map of intervals, a scale is a root note plus a list of intervals.

Bala2

Copperbox revision 781.

I've reimplemented the affine pitch/interval operations. The new versions are simpler as I don't consider negative intervals. I allowed negative intervals before, as they indicated the direction and seemed to make more sense for the affine operations. Now I think it is arithmetically sound not to consider them.

Bala2

Copperbox revision 780.

I put the interval code into a separate module, and added arbitrary instances for Pitch and Interval.

Bala2

Copperbox revision 779.

More work on pitch and intervals, mainly improving the AdditiveGroup instance for Interval and new functions for printing the interval quality.

Bala2

Copperbox revision 778.

I've realized that the arithmetic on intervals is too simple-minded to handle the zero interval properly. This is a checkpoint commit before I attempt to tackle its shortcomings.

Bala2

Copperbox revision 777.

Some more pitch and pitch-class operations.

Bala2

Copperbox revision 776.

Work on affine operations on pitch and intervals. The AffineSpace might now work, but they aren't pretty (they're polluted by 'carrys' to handle negative intervals). This code will need some quick checking.

Bala2

Copperbox revision 775.

I've added new modules for Z12 & Z7 modular arithmetic and pitch names. Improving the vectorial operations on pitch and intervals is on going.

Bala2

Copperbox revision 774.

I've added cabal files to Bala2 so that I can run Haddock on it.

Also I corrected two errors with the interval/pitch addition and difference code (the AffineSpace instances) - but I still don't like the code. I'll have to think about how to make these instances simple enough to be obviously correct.

Bala2

Copperbox revision 773.

Initial work for representing fretboard / chord diagrams. There is some work on this in the original Bala package but it wasn't very good, so I've had to start again from scratch.

Mullein-0.2.0

Copperbox revision 772.

I've added a release binary of Mullein - marking the current version at 0.2.0.

Mullein

Copperbox revision 771.

I'm now satisfied with the beam grouping code. I'm using the SnocWriter monad again, which has simplified the accumulator (the accumulator is now just the current be group, processed beam groups are hidden collected by the SnocWriter).

Mullein

Copperbox revision 770.

I've redone beam grouping with a double accumulator (all processed beam groups, current beam group). This one handles flushing the accumulator at the end of the note list correctly but it is rather ugly. Beaming still needs some work...

Mullein

Copperbox revision 769.

Another marginal improvement to beam grouping. This one tidies up the code quite nicely but it doesn't solve the problem whereby the last accumulation of beamed elements might start or end with rests rather than notes.

Mullein

Copperbox revision 768.

An 'improvement' to beam grouping stopping beam groups beginning or ending with rests. This improvement is unsatisfactory, though. It needs some more thought.

Bala2 and Mullein

Copperbox revision 767.

I've removed the previous models of rhythm patterns from Bala.RhythmPattern that didn't capture duration. Also I've tidied up the RhythmExample making it output a two-part overlay rhythm.

'Concat-ing' overlays was missing in Mullein, so I've added a function overlayPhrases, though this is just the function longZip.

Bala2

Copperbox revision 766.

I've revised RhythmPattern to be a list of events (notes) or rests. Events and rests have a duration, this means the new RhythmPattern has more information than the previous one. The previous version tried to synthesize the duration of events (effectively by zipping a list of durations into the onset list); it is easier to have them as part of the data structure.

Bala2 and Mullein

Copperbox revision 764.

I've added a module to Bala for rhythmic patterns and a 'collective import' module for LilyPond to Mullein.

Unfortunately the RhythmPattern module doesn't really live up to the comment I made yesterday about making Bala stringent. The main datatype just captures the onsets of the rhythm which is fine (this is in accordance with definitions elsewhere), but the interpretation function needs duration as well - a scored rhythm might subdivide an onset with a note an a rest rather than a long sustained note. Currently how I handle this is unsatisfactory.


Copperbox revision 765.

Added a collective import module for ABC to Mullein.

Bala2 and Mullein

Copperbox revision 763.

I've started a new version of Bala, my library of music operations, constructions...

The previous version of Bala was tied to HNotate which is now obsolete (superseded by Mullein). I'll try to be a bit more stringent with the new version, for instance the Pitch module is built on Conal Elliott's VectorSpace so it supports reasonable subtraction of Pitches to make an Interval, addition of Pitch + Interval to make a Pitch, addition of Intervals (making an Interval).

Mullein

Copperbox revisions 760, 761 & 762.

I've deleted the original bala/Mullein (760) and renamed the new branch from bala/Mullein2 to bala/Mullein (761). Also I've added cabal files (762).

Mullein

Copperbox revision 759.

Mullein branch - the first examples now output renderable scores. There is a problem with the LilyPond score that beam groups ending with a rest beam the rest, so it looks like Bracket module will have to be improved.

Mullein

Copperbox revision 758.

More work on the ABC pretty printer in the Mullein branch.

Mullein

Copperbox revision 757.

More work on the LilyPond pretty printer. I've decided against the slightly-typed combinators that I had in Bala and HNotate a while ago to keep things simple. The new pretty printers use only Doc plus existing Mullein types like Pitch, Duration and PitchLabel.

Mullein

Copperbox revision 756.

I've started adding some output pretty printers.

Mullein

Copperbox revision 755.

I've tidied up the last two modules on the Mullein branch - LilyPondOutput and AbcOutput.

Mullein

Copperbox revision 754.

More tidying up - Bracket, Utils and Core modules done this time.

Mullein

Copperbox revision 753.

I've tidied up the Pitch and Duration modules adding modules sigs, some haddock docs and removing no longer needed functions.

Mullein

Copperbox revision 752.

I've added a note type with fingering annotations on the Mullein branch. I had to added an extra type class and change some signatures for the LilyPond rewrite functions, so the types I came up with yesterday weren't quite adequate. The changes aren't too bad though, I think I still manage to be flexible and (not too far from) simple.

Mullein

Copperbox revision 751.

I've simplified the type classes in AbcOutput and LilyPondOutput and as a whole the types and their type classes obligations now seem right. Tomorrow I'll add a note type with fingering annotations, this should go a good way to seeing if I've hit a sweet spot where the types are right and flexible enough to handle extensions.

Mullein

Copperbox revision 750.

I've revised the types for the rewrite functions so that they are now polymorphic on glyph / element type on the Mullein branch.

This means I've been able to get rid of the PitchMap class which gave fmap like access to the pitch component in glyphs etc.

Mullein

Copperbox revision 749.

This is a checkpoint commit before I change the code that works on the glyph types again. I think I can now the rewriteDuration and rewritePitch functions usefully polymorphic by following the example of monad transformer constructor classes.

The monad transformers have there arguments carefully ordered so they have made instances of the important classes - the answer type of the transformer is always the last argument (satisfying the signature of Monad) and the monad parameter m is always the next to last (satisfying the signature of MonadTrans).

Mullein

Copperbox revision 748.

I've added LilyPond percussion output to the Mullein branch.

Mullein

Copperbox revision 747.

I've changed ABC output making it a two stage process, with the first stage being a duration transformation. This now matches how the LilyPond output works.

Mullein

Copperbox revision 746.

More work on LilyPond output. Also removed setDuration from the HasDuration type class as bracketing now works without trying to split (and therefore change) durations.

Mullein

Copperbox revision 745.

I've reimplemented the LilyPond duration transformation. Unfortunately, while the new version descends into grace notes properly it is type specific on the Glyph type. I'm not sure at the moment how to make it polymorphic.

Mullein

Copperbox revision 744.

I've implemented the relative pitch transformation for LilyPond in the Mullein2 branch - though the initial octave calculation seems wrong.

Mullein

Copperbox revision 743.

I've changed the order of parameters in the glyph type to be note-duration rather than duration-note.

Mullein

Copperbox revision 742.

Changed LilyPondOutput to use MonadLib.

Mullein

Copperbox revision 741.

I've implemented new beam grouping and bar splitting functions. These versions don't attempt to split and tie a note if it is too long, though they do run in a arbitrary monad that could throw an error or log a message when metric fitting fails.

Mullein

Copperbox revision 740.

I've removed the dependency on Data-Obscura, making concrete types for Bars and Pulsations (i.e. single notes or beam groups).

Mullein

Copperbox revision 739.

Wumpus - while this weeks changes make sense, they've added up to make Wumpus too complicated. I'm taking a break from it while I think of how to simplify things.

Back to Mullein then, where I've simplified the duration data type by putting the obligation to handle tied notes on the glyph type (previously durations could be composite to represent tied notes).

Wumpus

Copperbox revision 738.

I've changed the polygon creation functions in Core.Polygon so they create the polygon at the origin rather than at a passed in point.

Wumpus

Copperbox revision 737.

Matrix transformations are working again thanks to heavy use of Type Families, it makes me wonder how I managed without them.

Wumpus

Copperbox revision 736.

I've renamed the Transformations module Transform. I'm about to make it work again and thought a shorter name would be better.

Also I've cleaned up a few more type signatures.

Wumpus

Copperbox revision 735.

I've removed the Num instances for Vec2 and Vec3 as vectors don't seem have a natural multiplication (i.e. one where vec * vec -> vec, rather dot product which produces a scalar).

Also I've improved the polar coordinate conversion code so that the range is [0,2pi).

Wumpus

Copperbox revision 734.

Big changes. I've made the geometric objects - polygon, curve, line, bounding box - parametric on point type. Previously they were parametric on unit type - i.e. the point type was fixed at Point2 a where the a was some unit - usually Double. This means it's possible to create geometric objects with polar coordinates. Maybe this isn't a massive advantage in practice but it does seem conceptually better for polygon etc. to be parametric on point rather than unit.

Unfortunately the code is now pretty messy - Picture has had the minimum changes just to get some examples working again, and transformations have stopped working. There is still quite a bit of design needs to be done on the geometric objects (deciding what can be written once and what needs type classes to accommodate different point types). More positively I'm getting the hang of type families, so some of the type signatures have been simplified.

Wumpus

Copperbox revision 733.

I've changed the internals of Picture so that it stores a list of Picture elements Paths or Labels along with there graphic attributes (colour, pen width, etc.).

This increases uniformity but creating paths and labels is somewhat cumbersome because graphic attributes have to be specified, it would perhaps be preferable if attributes could represent the change to the graphic state or no change. The later is of course what PostScript does with its graphics context and it is what Wumpus moved away from for its syntactic view of pictures. This suggests I need to find a balance between the two.

Wumpus

Copperbox revision 732.

I've changed the examples and the drawing code to use the new syntactic Picture type (Pictures are essentially lists of Paths and Labels).

Also I've done some preliminary work on grids / matrices with adressable elements. This is one of the most import features of TikZ for drawing commuting diagrams and the like.

Wumpus

Copperbox revision 731.

I've remade the Node example with a simplified Picture type where everything is a path. It looks certainly promising, although the source tree will be messy for a while as I'm having to keep around two versions of the Path module and may have to do this with other modules.

Wumpus

Copperbox revision 730.

The Path module has been moved from Core to Drawing...

I've been reading the TikZ manual and guides. In TikZ everything is a path (apart for nodes with text labels and no doubt some other exceptions that I haven't discovered yet). This is a rather profound idea as far as Wumpus is concerned. In other systems - Kamin and Hyatt's FPic, PiScript... - pictures are commands, commands that change the graphics state, extend a path etc. While paths are, of course, prominent they aren't primary, and there are a lot of commands.

Following these examples is why Wumpus is Wumpus - Writer Monad PostScript. PostScript seemed too large to work with syntactically (build an abstract syntax tree and pretty print it), so I made it a command language - write it out as you go. It was quickly apparent that working with commands is unsatisfactory for geometry, hence all the work in Wumpus.Core for points, polygons, curves etc. But I struggled to work out the vector graphics equivalent of CSG or scene graphs for 3D - how to combine elements into a larger structure.

Although the code in Drawing.Basic isn't so good, it does have a mechanism to combine elements - it uses Wumpus as is, turning geometric primitives into a stream of commands and packaging up the stream with it's bounding box as a picture. Essentially this combines elements by making them anonymous. TikZ points to another way, and one that appears to have significant advantages. Paths can be represented syntactically as algebraic types - they already are in the Core.Path module but it isn't used much. Having everything a path would make Pictures much more tangible, possibly removing the need for the Picture Reader monad that I struggled with over the last couple of days.