Copperbox revision 489.
A bit of work on type inference.
Saturday, February 28, 2009
HMinCaml
Copperbox revision 488.
Working on Hawa reminded me that I really don't have much of an idea about code generation and the other back end stuff of compilers (I'd like to think I'm reasonably handy at the front-end stuff, I've been writing parsers and parser tools for years).
I don't think that just by fiddling about with Hawa I'm going to have an epiphany and suddenly work out how to write a nice code generator, at least not any time soon. So I've decided to play with Eijiro Sumii's MinCaml and see what I can learn from it. Naturally my plan is to write a Haskell translation...
Hopefully this will be a fairly bounded project, it was my intention to spend the first part of this year doing solely graphics. I've done the parser today and a bit of the emitter.
Working on Hawa reminded me that I really don't have much of an idea about code generation and the other back end stuff of compilers (I'd like to think I'm reasonably handy at the front-end stuff, I've been writing parsers and parser tools for years).
I don't think that just by fiddling about with Hawa I'm going to have an epiphany and suddenly work out how to write a nice code generator, at least not any time soon. So I've decided to play with Eijiro Sumii's MinCaml and see what I can learn from it. Naturally my plan is to write a Haskell translation...
Hopefully this will be a fairly bounded project, it was my intention to spend the first part of this year doing solely graphics. I've done the parser today and a bit of the emitter.
Friday, February 27, 2009
Thursday, February 26, 2009
Hawa
Copperbox revision 486.
Hawa is a doodle where I'm trying to generate PostScript. I can generate lines, but I really don't know what shape the code should take at the moment.
Hawa is a doodle where I'm trying to generate PostScript. I can generate lines, but I really don't know what shape the code should take at the moment.
Wednesday, February 25, 2009
Tuesday, February 24, 2009
ZBitmap
Copperbox revision 484.
The ascii rendering module Asciitron now uses the new traversal forEachRowColM_.
The ascii rendering module Asciitron now uses the new traversal forEachRowColM_.
ZBitmap
Copperbox revision 483.
I've added a new module Traverse that does column/row traversals (i.e. zig zig). The important part of this is actually that it makes the coordinate system explicit with a newtype wrapper. For instance the arrays in Chalkboard have Cartesian coordinates, whereas the arrays in .bmp files have 'C array' coordinates. Next step - I'll rewrite the existing traversals in ZBitmap with the new scheme.
I've added a new module Traverse that does column/row traversals (i.e. zig zig). The important part of this is actually that it makes the coordinate system explicit with a newtype wrapper. For instance the arrays in Chalkboard have Cartesian coordinates, whereas the arrays in .bmp files have 'C array' coordinates. Next step - I'll rewrite the existing traversals in ZBitmap with the new scheme.
ZBitmap
Copperbox revision 482.
I've started work again on ZBitmap - it would be nice if I could create bmp bitmaps with Andy Gill's Chalkboard. Zbitmap has a bad case of indexitis though, so its going to take quite a bit of work getting it into a useable form.
I've started work again on ZBitmap - it would be nice if I could create bmp bitmaps with Andy Gill's Chalkboard. Zbitmap has a bad case of indexitis though, so its going to take quite a bit of work getting it into a useable form.
Sunday, February 22, 2009
SFont
Copperbox revision 481.
Work on decoding composite glyphs. I can now parse all the gylphs in my test font without errors, but I can't map them to glyph indexes yet. Also getting gylphs into OpenVG is going to be harder than I hoped - TrueType glyphs are represented as b-splines, whereas OpenVG works with beziers. I'll have to learn some geometry before I can do that conversion step.
Work on decoding composite glyphs. I can now parse all the gylphs in my test font without errors, but I can't map them to glyph indexes yet. Also getting gylphs into OpenVG is going to be harder than I hoped - TrueType glyphs are represented as b-splines, whereas OpenVG works with beziers. I'll have to learn some geometry before I can do that conversion step.
Saturday, February 21, 2009
SFont
Copperbox revision 480.
I've recast OTFont as SFont. The S stands for syntax - SFont has an explicit notion of a syntax tree for font files, whereas OTFont tried to stick close to a font files own representation as tables.
OTFont was hard work, I'm hoping SFont will be easier due to it being structured more like other syntax libraries. At the moment it is certainly neater, though I haven't covered all the tables that I did in OTFont (some of the tables I did do in OTFont we only done partially). Currently SFont can read the table directory, the head table, the loca table and can decode simple glyphs.
I've recast OTFont as SFont. The S stands for syntax - SFont has an explicit notion of a syntax tree for font files, whereas OTFont tried to stick close to a font files own representation as tables.
OTFont was hard work, I'm hoping SFont will be easier due to it being structured more like other syntax libraries. At the moment it is certainly neater, though I haven't covered all the tables that I did in OTFont (some of the tables I did do in OTFont we only done partially). Currently SFont can read the table directory, the head table, the loca table and can decode simple glyphs.
OTFont
Copperbox revision 479.
Work on extracting the glyphIndex from the cmap table. The bits seem to be in place, but it doesn't work yet.
Work on extracting the glyphIndex from the cmap table. The bits seem to be in place, but it doesn't work yet.
Friday, February 20, 2009
Thursday, February 19, 2009
OTFont
Copperbox revision 477.
Work on interpreting the name table. Named elements are implemented as a relation between the key and the text string. Unfortunately the key has four elements to make it unique (platformID, encodingID, languageID, and nameID) so it makes the implementation somewhat cluttered. Maybe I'll come up with a better scheme at some point.
Work on interpreting the name table. Named elements are implemented as a relation between the key and the text string. Unfortunately the key has four elements to make it unique (platformID, encodingID, languageID, and nameID) so it makes the implementation somewhat cluttered. Maybe I'll come up with a better scheme at some point.
OTFont
Copperbox revision 476.
A bit of tidying up. Mostly dos2unix-ing all the files, but removed some bits that have become redundant (e.g. the marshaling type classes).
A bit of tidying up. Mostly dos2unix-ing all the files, but removed some bits that have become redundant (e.g. the marshaling type classes).
Wednesday, February 18, 2009
OTFont
Copperbox revision 475.
Coded up the FontLoader, which can now load all the implemented tables except glyf. Glyf is a special case as it may be useful to only load particular glyphs rather than the whole table.
Coded up the FontLoader, which can now load all the implemented tables except glyf. Glyf is a special case as it may be useful to only load particular glyphs rather than the whole table.
OTFont
Copperbox revision 474.
Adding a missing file CSEMonad.hs that had been missing for some the last few revisions. Moving font loading code into the new module FontLoader. As table loading is starting to get a bit more comprehensive now that I can peek into the glyf table, I'll need to work out how I'm going to load and cache tables.
Adding a missing file CSEMonad.hs that had been missing for some the last few revisions. Moving font loading code into the new module FontLoader. As table loading is starting to get a bit more comprehensive now that I can peek into the glyf table, I'll need to work out how I'm going to load and cache tables.
OTFont
Copperbox revision 473.
Problems with delta vectors in the glyph decoding have been sorted - all coordinates after the first on are delta vectors not just two byte ones. Also I was decoding two byte numbers as little endian rather than big endian.
Problems with delta vectors in the glyph decoding have been sorted - all coordinates after the first on are delta vectors not just two byte ones. Also I was decoding two byte numbers as little endian rather than big endian.
Tuesday, February 17, 2009
OTFont
Copperbox revision 472.
Initial work on extracting glyph outlines. Currently I've got two problems - one I don't know how big a glyf is within the glyf table. The other is that decoding delta vectors doesn't work. Presumably because I've no idea what a delta vector is and the spec doesn't help.
Initial work on extracting glyph outlines. Currently I've got two problems - one I don't know how big a glyf is within the glyf table. The other is that decoding delta vectors doesn't work. Presumably because I've no idea what a delta vector is and the spec doesn't help.
OTFont
Copperbox revision 471.
With the machinery from the last few commits, I've now been able to implement the runOn parser combinator - this repeatedly parsers until the end of a range. A range will usually be a table - in the the table directory, tables have an offset and a length to locate them in the input stream. An example, one of the formats for the post table has a runOn of Pascal strings until the end of the table to give Unicode names.
With the machinery from the last few commits, I've now been able to implement the runOn parser combinator - this repeatedly parsers until the end of a range. A range will usually be a table - in the the table directory, tables have an offset and a length to locate them in the input stream. An example, one of the formats for the post table has a runOn of Pascal strings until the end of the table to give Unicode names.
OTFont
Copperbox revision 470.
I've added shift and reset to the parse monad. Well I think I have - the definitions type check and don't have any undefined's, but they are pretty far out. My test example works though it doesn't alter the state, which is the main doubt I have with the implementation. Also programming with shift and reset is hard work in Haskell (compared to say, Scheme) because you're already in a CPS monad, so I don't know if it will be very useful.
Still it was a fairly tough mental challenge to go so far, coding as sudoku.
I've added shift and reset to the parse monad. Well I think I have - the definitions type check and don't have any undefined's, but they are pretty far out. My test example works though it doesn't alter the state, which is the main doubt I have with the implementation. Also programming with shift and reset is hard work in Haskell (compared to say, Scheme) because you're already in a CPS monad, so I don't know if it will be very useful.
Still it was a fairly tough mental challenge to go so far, coding as sudoku.
Monday, February 16, 2009
OTFont
Copperbox revision 469.
The parser monad transformer in the last commit didn't handle MonadError / ErrorT properly. This revision improves that.
The parser monad transformer in the last commit didn't handle MonadError / ErrorT properly. This revision improves that.
OTFont
Copperbox revision 468.
The parse monad is now a transformer, this means I can add error handling and now do a range combinator - a parser that repeats until it exhausts the data in its range.
The parse monad is now a transformer, this means I can add error handling and now do a range combinator - a parser that repeats until it exhausts the data in its range.
OTFont
Copperbox revision 467.
Minor updates - the parse monad should probably be a transformer, so I've committed all my local changes before change the parse monad.
Minor updates - the parse monad should probably be a transformer, so I've committed all my local changes before change the parse monad.
Sunday, February 15, 2009
OTFont
Copperbox revision 466.
I've re-implemented the parsing with a 'random access' parse monad. Parser monads usually consume the input stream as they progress. The random access parse monad instead reads all the data into an array at the start, then changes the position as it parses (the position is the array index).
This seems an improvement on the previous parser which segmented the input byte string for each table, to give the effect of random access.
I've re-implemented the parsing with a 'random access' parse monad. Parser monads usually consume the input stream as they progress. The random access parse monad instead reads all the data into an array at the start, then changes the position as it parses (the position is the array index).
This seems an improvement on the previous parser which segmented the input byte string for each table, to give the effect of random access.
Saturday, February 14, 2009
OTFont
Copperbox revision 465.
Latest changes - more work on cmap and hhea tables, though I'm not really happy with the current work. I don't seem to be getting to the essence of the OpenType/TrueType font structure.
Latest changes - more work on cmap and hhea tables, though I'm not really happy with the current work. I don't seem to be getting to the essence of the OpenType/TrueType font structure.
Friday, February 13, 2009
Thursday, February 12, 2009
Wednesday, February 11, 2009
OTFont
Copperbox revision 462.
Working towards extracting contour data from glyphs. This is where things start to get tricky...
Working towards extracting contour data from glyphs. This is where things start to get tricky...
Tuesday, February 10, 2009
OTFont
Copperbox revision 461.
Adding the `Required Common Tables`. Most are implemented, though quite a bit in Hmtx is stubbed as this table is rather unique.
Adding the `Required Common Tables`. Most are implemented, though quite a bit in Hmtx is stubbed as this table is rather unique.
OTFont
Copperbox revision 460.
Work on representing the Head table. This has suggested a different way of doing things that has rather invalidated some of yesterday's work on the Name table. For the time being I've left Name table largely as it was.
Work on representing the Head table. This has suggested a different way of doing things that has rather invalidated some of yesterday's work on the Name table. For the time being I've left Name table largely as it was.
Monday, February 9, 2009
OTFont
Copperbox revision 459.
Added some decoding of Name tables, as they seemed to most obvious place to start.
Added some decoding of Name tables, as they seemed to most obvious place to start.
Sunday, February 8, 2009
OTFont
Copperbox revision 458.
I've added a new experiment - OTFont. As I've been working on the FreeType binding, I've been mindful that it might be actually not be that hard to read the font file directly (and keep everything in Haskell). For my purposes I want the vector outline of a font (so I can get it into OpenVG), which is stored in the font in the first place. As capable as FreeType is I don't really need it's power.
At least I think I don't need it, we'll see how far I get with OTFont.
I've added a new experiment - OTFont. As I've been working on the FreeType binding, I've been mindful that it might be actually not be that hard to read the font file directly (and keep everything in Haskell). For my purposes I want the vector outline of a font (so I can get it into OpenVG), which is stored in the font in the first place. As capable as FreeType is I don't really need it's power.
At least I think I don't need it, we'll see how far I get with OTFont.
Saturday, February 7, 2009
GLSL syntax library
Copperbox revision 457.
Work on the lexer for GLSL, though it is still incomplete.
One odd thing I found is I don't think the GLSL grammar admits the main function, at least not if its signature is
void main (void)
{ ...
I think the grammar would always want a parameter qualifier first after the left paren. To get round this I think I'll have to make main a keyword and give it a special production.
Work on the lexer for GLSL, though it is still incomplete.
One odd thing I found is I don't think the GLSL grammar admits the main function, at least not if its signature is
void main (void)
{ ...
I think the grammar would always want a parameter qualifier first after the left paren. To get round this I think I'll have to make main a keyword and give it a special production.
Friday, February 6, 2009
Haskell FreeType binding
Copperbox revision 455.
I've changed the representation of the type FT_Outline.
The corresponding C type is not an opaque handle, its a struct so it needs filling out. I hadn't really been sure what to do about this - most of the FFI examples I've looked at a fortunate enough to have to deal with opaque handles for a lot of the crossing over into C. I did find a nice example idiom that does what I want in the the Time library on Hackage (the getCTimeval function in the Data.Time.Clock.CTimeval module) .
I've changed the representation of the type FT_Outline.
The corresponding C type is not an opaque handle, its a struct so it needs filling out. I hadn't really been sure what to do about this - most of the FFI examples I've looked at a fortunate enough to have to deal with opaque handles for a lot of the crossing over into C. I did find a nice example idiom that does what I want in the the Time library on Hackage (the getCTimeval function in the Data.Time.Clock.CTimeval module) .
GLSL syntax library
Copperbox revision 454.
I've changed the syntax tree to use Data.Seq rather than lists, Seq allows snoc-ing (adding to the right), so this means that I can take out the revlist productions from the parser (which only reversed a backwards list). This gets the parser back to being almost identical to the grammar.
Also I've filled out the pretty printer so all the datatypes have a corresponding Pretty instance.
I've changed the syntax tree to use Data.Seq rather than lists, Seq allows snoc-ing (adding to the right), so this means that I can take out the revlist productions from the parser (which only reversed a backwards list). This gets the parser back to being almost identical to the grammar.
Also I've filled out the pretty printer so all the datatypes have a corresponding Pretty instance.
Thursday, February 5, 2009
GLSL syntax library
Copperbox revision 453.
The GLSL parser is now complete, that's to say all the productions of the grammar are implemented and there are no actions with undefined. There is one shift reduce conflict and there could certainly be errors.
The lexer isn't complete, and the abstract syntax tree isn't very abstract. It looks like I'll have to consider the current syntax tree to be nearer the concrete syntax and do a rewriting step after parsing. The main problem is declartors aren't very pleasing, the abstract syntax tree will probably have to remove coalescing so that:
becomes
The GLSL parser is now complete, that's to say all the productions of the grammar are implemented and there are no actions with undefined. There is one shift reduce conflict and there could certainly be errors.
The lexer isn't complete, and the abstract syntax tree isn't very abstract. It looks like I'll have to consider the current syntax tree to be nearer the concrete syntax and do a rewriting step after parsing. The main problem is declartors aren't very pleasing, the abstract syntax tree will probably have to remove coalescing so that:
int a, b = 0;
becomes
int a;
int b = 0;
GLSL syntax library
Copperbox revision 452.
The parser now compiles, but there are quite a lot of undefined's as actions. So it still is some way off working.
The parser now compiles, but there are quite a lot of undefined's as actions. So it still is some way off working.
GLSL syntax library
Copperbox revision 451.
More work on the parser. All the productions are now in place, but still quite a bit of the AST needs defining.
More work on the parser. All the productions are now in place, but still quite a bit of the AST needs defining.
Wednesday, February 4, 2009
GLSL syntax library
Copperbox revision 450.
More work on the parser - about half the productions are now stubbed.
More work on the parser - about half the productions are now stubbed.
GLSL syntax library
Copperbox revision 449.
More work on the parser and lexer. I'd forgotten how much work was involved in writing a parser with Happy and Alex - maybe I should have tried Parsec, though I've never used Parsec for a full language (especially when the grammar might have left recursion, which means grammar changes).
More work on the parser and lexer. I'd forgotten how much work was involved in writing a parser with Happy and Alex - maybe I should have tried Parsec, though I've never used Parsec for a full language (especially when the grammar might have left recursion, which means grammar changes).
Tuesday, February 3, 2009
GLSL syntax library
Copperbox revision 448.
Initial work on the lexer and parser for the GLSL syntax library.
Initial work on the lexer and parser for the GLSL syntax library.
Monday, February 2, 2009
GLSL syntax library
Copperbox revision 447.
Started a new syntax library for the OpenGL shading lang. The library should support parsing and pretty printing like Language.C and Language.Haskell.
I did some work on a Frown parser for Language.C a while ago - though I didn't get very far with it. Hopefully as GLSL is a C like language, there might be some opportunity to cannibalize this work.
Started a new syntax library for the OpenGL shading lang. The library should support parsing and pretty printing like Language.C and Language.Haskell.
I did some work on a Frown parser for Language.C a while ago - though I didn't get very far with it. Hopefully as GLSL is a C like language, there might be some opportunity to cannibalize this work.
Haskell OpenVG binding - ready for release
Copperbox revision 446.
Now that the binding builds on Windows and MacOSX - I think its time to see about putting it on Hackage.
Now that the binding builds on Windows and MacOSX - I think its time to see about putting it on Hackage.
OpenVG Windows install instructions
It is tedious to install ShivaVG on Windows with MinGW/Msys
(Idon't think Cygwin will work at all). With GHC-6.10.1 most
people appear to be following these instructions to install
HOpenGL and HGLUT - they are the ones I followed:
http://netsuperbrain.com/blog/posts/freeglut-windows-hopengl-hglut/
To get Shiva-VG to work under MinGW/Msys you have to do the same
trick of compiling directly with gcc rather than using the makefiles
as per *Compile and Install freeglut*.
Here's what I did:
I dropped the archive into my home directory
C:\msys\1.0\home\stephen
> tar xvfz shivavg-0.2.0.tar.gz
> cd shivavg-0.2.0/src
> gcc -O2 -c *.c -I../include/VG
That should build the *.o files.
> gcc -shared -o openvg32.dll *.o -Wl,--enable-stdcall-fixup,--out-implib,libopenvg32.a -lopengl32 -lglu32 -lgdi32 -lwinmm
That should create `openvg32.dll` and `libopenvg32.a`.
Put `libshivavg32.a` into your MinGW lib directory, on my system
it is here:
C:\MinGW\lib
Also copy the `vg` folder from `shivavg-0.2.0\include` to the
MinGW include directory, on my system it is here:
C:\MinGW\include
You should have folders for both the GL and OpenVG headers:
C:\MinGW\include\GL
C:\MinGW\include\vg
Now you should be able to build the Haskell binding to Shiva:
I dropped the archive into my home directory
C:\msys\1.0\home\stephen
> tar xvfz OpenVG-0.1.tar.gz
> cd OpenVG-0.1
> runhaskell Setup.hs configure
> runhaskell Setup.hs build
> runhaskell Setup.hs install
> runhaskell Setup.hs haddock
To run the test you need to copy `openvg32.dll` from
the shivavg src directory into OpenVG-0.1/examples.
The cd to examples and run with:
> runhaskell -lopenvg TestVgu.hs
This should display a white window with some line drawn
shapes.
Better examples of OpenVG capabilities are in the ShivaVG
examples. Particularly test_tiger which uses the famous
tiger from SVG tutorials.
Running ShivaVG's C examples
----------------------------
ShivaVG itself seems to have some problems with FreeGlut -
at least if the are both compiled through the direct gcc
(no makefile) hack as per the *netsuperbrain.com* blog tutorial.
Compiling should be straight-forward, the following command
compiles test_tiger.exe:
> gcc -o test_tiger test.c test_tiger_paths.c test_tiger.c -lm -lglut32 -lglu32 -lopengl32 -lopenvg32
To run the test_tiger.exe you will need to drop to put a copy of
the `openvg32.dll` that you compiled (in the src directory) into
the examples directory.
You will also need a copy of `glut32.dll` in the examples
directory - and here seems to be the snag.
I don't think the `glut32.dll` produced by FreeGlut works
- at least not if its compiled as per the *netsuperbrain.com*
guide. The `glut32.dll` compiled from FreeGlut is identifiable
as its 308KB in size (on my computer at least). If you try to
run test_tiger.exe with this it may fail with an
`Entry Point Not Found` dialog for the function
`_glutCreateMenuWithExit` (it certainly fails for me).
To get around this, I have to use the `glut32.dll` from my
Cygwin installation, this is 232KB in size and was in the folder:
C:\cygwin\bin
I copied this into the `examples` folder along with `openvg32.dll`
then double-clicking on test_tiger.exe should work.
Sunday, February 1, 2009
Haskell OpenVG binding
Copperbox revision 445.
The OpenVG binding now builds under cabal on Windows.
I've included a sdist package in the toplevel directory dist:
svn checkout http://copperbox.googlecode.com/svn/trunk/dist/
Although once I've checked it on MacOSX I'll see about getting it put on Hackage.
The OpenVG binding now builds under cabal on Windows.
I've included a sdist package in the toplevel directory dist:
svn checkout http://copperbox.googlecode.com/svn/trunk/dist/
Although once I've checked it on MacOSX I'll see about getting it put on Hackage.
Haskell OpenVG binding
Copperbox revision 444.
Some work on the cabal file. On Windows, it seems I can build and install with a Simple build provided I use MinGW and not Cygwin, but then the library has some problems with symbol names.
I should be getting a Linux machine set up over the next week, so I'd expect developing the cabal file on that will be easier.
Some work on the cabal file. On Windows, it seems I can build and install with a Simple build provided I use MinGW and not Cygwin, but then the library has some problems with symbol names.
I should be getting a Linux machine set up over the next week, so I'd expect developing the cabal file on that will be easier.
Subscribe to:
Posts (Atom)
About Me
- Stephen Tetley
- Disambiguating biog as there are a few Stephen Tetley's in the world. I'm neither a cage fighter or yachtsman. I studied Fine Art in the nineties (foundation Bradford 1992, degree Cheltenham 1992 - 95) then Computing part-time at Leeds Met graduating in 2003. I'm the Stephen Tetley on Haskell Cafe and Stackoverflow.