On Sun, Mar 14, 2010 at 9:03 AM, david fries wrote:
> Hello Café
>
> Some time ago I wrote a parser for a project of one our customers. The
> format was proprietary and binary. The data was structured as a tree
> with tables pointing to sub tables farther in the file. (Well actually
> there was o
Stephen Tetley wrote:
hi wren
Where I've used it, random access does seem conceptual more
satisfactory than trying to avoid it.
I was thinking more about performance issues (avoiding disk seeks) which
would also alleviate the problem of needing random access when it's not
available.
For
hi wren
Where I've used it, random access does seem conceptual more
satisfactory than trying to avoid it.
Well designed binary formats are deterministic - so wherever you are
inside the file you should know what you are parsing. One example of
this determinism is that parsing "local" alternatives
david fries wrote:
My my concern was how you would perform random access in a functional
parser. You're points are interesting too. I guess if we really had
wanted to work with parsed objects, retaining the shared references
would have been a must.
Out of curiosity, was there *really* a need fo
Hi Ryan,
1) Retaining shared references was not important to us at the time. We
were only interested in the correctness of the values that were written.
2) Performance wasn't a big issue either. The parser was part of a
debugging tool we wrote for internal use.
My my concern was how you would p
Thanks for the links!
I didn't realize that Iteratee can also do random access. I looked at
Oleg's slides a while back, but I haven't wrapped my head around it.
On Mon, 2010-03-15 at 08:57 -0500, John Lato wrote:
> Hi Dave,
>
> > From: david fries
> >
> > Hello Café
> >
> > Some time ago I wrot
Here are some questions you have not answered that are quite important
for your design:
1) How important is retaining shared references? In particular, is
the structure mutable after being read-in to memory? If it is, and
you mutate an object, do you expect other references to that object to
be
Hi Dave,
> From: david fries
>
> Hello Café
>
> Some time ago I wrote a parser for a project of one our customers. The
> format was proprietary and binary. The data was structured as a tree
> with tables pointing to sub tables farther in the file. (Well actually
> there was one or two cases where
Yep, That's what I had in mind. Thanks for the link.
On Sun, 2010-03-14 at 19:09 +, Stephen Tetley wrote:
> Hi David
>
> Ah ha - this form of binary file layout is quite common (e.g. PECOFF
> object files and OpenType / TrueType fonts).
>
> Parsec and other parsing libraries are perhaps not
Hi David
Ah ha - this form of binary file layout is quite common (e.g. PECOFF
object files and OpenType / TrueType fonts).
Parsec and other parsing libraries are perhaps not ideal for the task,
as they consume input as they parse. I have my own alternative to
Parsec - Kangaroo [1] - for parsing b
Hi Stephen
Perhaps my description of the format was a bit unclear. When I said
pointer I simply meant a number which is the position in the stream.
Imagine the tables looking something like this:
RootTable
HeaderMagicNumber (1Byte): 0x50
VersionNumber (2 Bytes): 1234
SubTablePointer (4
On 14 March 2010 16:03, david fries wrote:
[SNIP]
> Oddly enough, our customer never bothered to write a parser of their
> own. I wonder why.
Hi David
If the binary structure was previously used only with C programs its
quite common just to use casting to unpack the data into a struct -
though
Hello Café
Some time ago I wrote a parser for a project of one our customers. The
format was proprietary and binary. The data was structured as a tree
with tables pointing to sub tables farther in the file. (Well actually
there was one or two cases where branches joined together, so I guess it
was
13 matches
Mail list logo