Andrew Coppin wrote:
[design of a bitwise binary library]
(This would all be so trivial in an OO language. Just make an Encoder
object that updates its own state internally and talks to a Source
object and a Destination object for its data...)
I guess it's on the same level of trivialness in
> I could try GHC's new debugger. But my experiences with it so far have
> shown that for all but the most trivial programs possible, it becomes
> intractably difficult to figure out what the debugger is actually
> showing you.
GDB is to C as
(a) GHCi debugger :: Haskell
(b) Pigs :: Farmers
(
I have a similar piece of code at http://code.haskell.org/gmap/serial/
which is fairly well tested. It currently only outputs lists of words
but its based on Data.Binary so it should be fairly easy to get
bytestrings out it (bytestrings worked up till 2-3 weeks ago, I just
havent bothered to keep t
andrewcoppin:
> I could try GHC's new debugger. But my experiences with it so far have
> shown that for all but the most trivial programs possible, it becomes
> intractably difficult to figure out what the debugger is actually
> showing you. I actually tried to debug a "normal" LZW implementatio
OK, so I just spent an entire day trying to write some code, and after
hours of struggling I have something that's semi-working but very ugly
and rather unreliable. My usual guideline for Haskell programming is "if
it seems hard, you're doing it wrong"...
After many hours of effort, I came up