I think you're referring to the backend :)
I'm overriding the Lexer, it's just I didn't explain it well.
In your implementation, the structure you had to map was
static or dynamic (tree-like)? I'm considering Sablecc
because we have a family of formats, but they are
lexically the same.
Any other suggestion?
--
jacg
-----Mensaje original-----
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de S'orlok Reaves
Enviado el: Miércoles, 27 de Agosto de 2008 05:10 a.m.
Para: Discussion mailing list for the SableCC project
Asunto: Re: Line lexer...
I once made a binary file parser with SableCC, similar
to what you're describing. I had to use a custom Lexer
to read "X bytes" dynamically (although, I think
SableCC4 might be able to get around this.)
My opinion was that I didn't gain any real benefit
from using SableCC. (Note: This is the ONLY parser
project that I regretted using SableCC for.) In the
scenario you described, I'd hand-write a recursive
descent parser. But if there's a chance you'll be
switching formats (you mention XML) then stick to
SableCC --you'll be able to recycle your front-end.
Any other thoughts/experiences?
-->Seth
By the way, the standard approach when using a custom
lexer is NOT to change the lexer class, but to
override it.
--- Javier Abdul Cordoba Gandara <[EMAIL PROTECTED]> wrote:
>
> Hi all. I've been using SableCC for quite some time
> now. Now I'm facing a project where I need to
> process lines of data that represent transactions in
> very fixed formats (spaces are showed only for
> simplicity):
>
> FI 0001a 0104abcde 0209123456789 0302aa SE 0002ab
>
> where FI(RST), SE(COND) are headers of so called
> segments, and fields are marked as 00-01, 00 is the
> 'id' of the field and 01 is the lenght of the
> segment, a is the data. So it follows that in
> 0209123456789, 02 is the 'id', 09 is the length and
> 123456789 the data, etc.
>
> Next, I have that segments represent
> data/operations and there are some constraints on
> how they can be structured, the same applies to
> fields (that have real names, numbers are just
> codes).
>
> We have processors from plain C to annotated Java
> with fancy filters and so on, but all are hard coded
> monsters that you'll hate to meet. I want something
> simpler and higher level, ¿would you recommend me to implement a
> scanner for the line oriented thing? I started to change Lexer class
> to an interface, etc. you know the story, but I also want to evaluate
> speed and memory issues (millions of transactions
> you know). Then I stopped and wanted to know your
> opinion.
>
> Maybe next step is XML migration but thats why I
> want to get a real parser involved :) Or maybe this
> is overkill for such a dumb format and I must settle
> for good old C.
>
> Thank you and good luck with SableCC 4 I really
> want to play with it >.<
>
>
> Javier Abdul Córdoba Gándara
> Buró de Crédito
> Sistemas - Desarrollo
> Tel. 54494900 Ext. 5935
>
> El presente mensaje es confidencial, dirigido
> únicamente para el destinatario.
> Si usted no es el destinatario, no deberá copiarlo,
> revelarlo o distribuirlo.
> Cualquier acción realizada en este sentido, será
> ilegal. Si por error recibe el
> presente mensaje, por favor notifique al remitente.
>
> This communication is confidential and intended only
> for the addressee. If you
> are not the intended recipient, you may not copy,
> disclose, or distribute this
> message to anyone else; any such actions may be
> unlawful. If you have received
> this communication in error, please contact the
> sender of the message to inform
> him or her of the error.
>
> _______________________________________________
> SableCC-Discussion mailing list [email protected]
> http://lists.sablecc.org/listinfo/sablecc-discussion
>
_______________________________________________
SableCC-Discussion mailing list [email protected]
http://lists.sablecc.org/listinfo/sablecc-discussion
_______________________________________________
SableCC-Discussion mailing list
[email protected]
http://lists.sablecc.org/listinfo/sablecc-discussion
