[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Looking for an appropiate parser generator

Iñaki Baz Castillo

3/15/2008 11:22:00 PM

Hi, I'm new in this maillist so hello to all.

I want to do a SIP protocol parser in Ruby (SIP protocol is very similar to=
=20
HTTP) so I'm looking for the most appropiate parser in Ruby. Also, it's the=
=20
first time I try to do something like this so I need first lot of doc readi=
ng=20
(yacc, lex, LARL, LL, BNF...).

I'd just like to know with parser is a good option for my purpose since I'v=
e=20
found "too much" of them:

=2D rex
=2D ruby-lex
=2D racc
=2D ruby-yacc
=2D coco-rb
=2D TreeTop
=2D Ragel

=46or now I don't look for the fastest and most efficient parser, maybe jus=
t for=20
the easiest one. I will read those days about Yacc and Lex since I assume=20
they are the base of all of them, and I know that typically Yacc is used in=
=20
conjunction with Lex so:
If I choose Racc, will I need Rex?
If I choose Ruby-Yacc, will I need Ruby-Lex?
Note that I want to get Ruby code, not C, C++ or others.

My purpose is just receiving SIP requests (similar to HTTP requests) and pa=
rse=20
them (maybe into Ruby objects) to work with them (implement a SIP stack).

They are lots of options and I'm getting a little "lost" with so many doc t=
o=20
read. Any orientation please?

Thanks a lot and best regards.




=2D-=20
I=C3=B1aki Baz Castillo

5 Answers

Eleanor McHugh

3/16/2008 1:30:00 AM

0

On 15 Mar 2008, at 23:21, I=F1aki Baz Castillo wrote:
> Hi, I'm new in this maillist so hello to all.
>
> I want to do a SIP protocol parser in Ruby (SIP protocol is very =20
> similar to
> HTTP) so I'm looking for the most appropiate parser in Ruby. Also, =20
> it's the
> first time I try to do something like this so I need first lot of =20
> doc reading
> (yacc, lex, LARL, LL, BNF...).
>
> I'd just like to know with parser is a good option for my purpose =20
> since I've
> found "too much" of them:
>
> - rex
> - ruby-lex
> - racc
> - ruby-yacc
> - coco-rb
> - TreeTop
> - Ragel
>
> For now I don't look for the fastest and most efficient parser, =20
> maybe just for
> the easiest one. I will read those days about Yacc and Lex since I =20
> assume
> they are the base of all of them, and I know that typically Yacc is =20=

> used in
> conjunction with Lex so:
> If I choose Racc, will I need Rex?
> If I choose Ruby-Yacc, will I need Ruby-Lex?
> Note that I want to get Ruby code, not C, C++ or others.
>
> My purpose is just receiving SIP requests (similar to HTTP requests) =20=

> and parse
> them (maybe into Ruby objects) to work with them (implement a SIP =20
> stack).
>
> They are lots of options and I'm getting a little "lost" with so =20
> many doc to
> read. Any orientation please?


The SIP protocol is in principle simple enough that you could probably =20=

get by rolling your own custom parser by hand. My colleague =20
implemented a console-driven SIP stack this way and whilst the code is =20=

inefficient compared to a table-driven parser it's eminently more =20
readable.

However if you do want to go down the parser-generator route for =20
performance reasons then look at the Ragel parser in Mongrel as that's =20=

very efficient and highly conformant with the HTTP RFC specs (given =20
some of the boundary cases in SIP conformance is probably high on your =20=

list of priorities). As far as I'm aware Ragel produces parsers in C, =20=

but the Mongrel code will show you how to turn that into a Ruby native =20=

extension.


Ellie

Eleanor McHugh
Games With Brains
----
raise ArgumentError unless @reality.responds_to? :reason



Iñaki Baz Castillo

3/16/2008 2:43:00 AM

0

El Domingo, 16 de Marzo de 2008, Eleanor McHugh escribi=F3:

> The SIP protocol is in principle simple enough

opss, sure it's not simple at all, a lot of amiguations, each header has it=
s=20
own format, lots of extensions in lot of RFC's.... buff... simple?


> that you could probably=20
> get by rolling your own custom parser by hand.=20
It's what I'm doing for now but maybe it's better using an existing one. No=
=20
idea.


> My colleague=20
> implemented a console-driven SIP stack this way and whilst the code is
> inefficient compared to a table-driven parser it's eminently more
> readable.
>
> However if you do want to go down the parser-generator route for
> performance reasons then look at the Ragel parser in Mongrel as that's
> very efficient and highly conformant with the HTTP RFC specs (given
> some of the boundary cases in SIP conformance is probably high on your
> list of priorities). As far as I'm aware Ragel produces parsers in C,
> but the Mongrel code will show you how to turn that into a Ruby native
> extension.

AFAIK Ragel can write to Ruby since verison 6.0:
http://www.devchix.com/2008/01/13/a-hello-world-for-ruby-o...



Thanks a lot, I'll try Ragel.


=2D-=20
I=F1aki Baz Castillo

Eleanor McHugh

3/16/2008 6:01:00 PM

0

On 16 Mar 2008, at 02:42, I=F1aki Baz Castillo wrote:
> El Domingo, 16 de Marzo de 2008, Eleanor McHugh escribi=F3:
>
>> The SIP protocol is in principle simple enough
>
> opss, sure it's not simple at all, a lot of amiguations, each header =20=

> has its
> own format, lots of extensions in lot of RFC's.... buff... simple?

I've probably spent too much time hanging around SIP obsessives ;)

>> However if you do want to go down the parser-generator route for
>> performance reasons then look at the Ragel parser in Mongrel as =20
>> that's
>> very efficient and highly conformant with the HTTP RFC specs (given
>> some of the boundary cases in SIP conformance is probably high on =20
>> your
>> list of priorities). As far as I'm aware Ragel produces parsers in C,
>> but the Mongrel code will show you how to turn that into a Ruby =20
>> native
>> extension.
>
> AFAIK Ragel can write to Ruby since verison 6.0:
> http://www.devchix.com/2008/01/13/a-hello-world-for-ruby-o...
>
> Thanks a lot, I'll try Ragel.

I'll have to take a look at that myself.


Ellie

Eleanor McHugh
Games With Brains
----
raise ArgumentError unless @reality.responds_to? :reason



Daniel Brumbaugh Keeney

3/17/2008 12:22:00 AM

0

T24gU2F0LCBNYXIgMTUsIDIwMDggYXQgNjoyMSBQTSwgScOxYWtpIEJheiBDYXN0aWxsbyA8aWJj
QGFsaWF4Lm5ldD4gd3JvdGU6Cj4gIEknZCBqdXN0IGxpa2UgdG8ga25vdyB3aXRoIHBhcnNlciBp
cyBhIGdvb2Qgb3B0aW9uIGZvciBteSBwdXJwb3NlIHNpbmNlIEkndmUKPiAgZm91bmQgInRvbyBt
dWNoIiBvZiB0aGVtOgo+Cj4gIC0gcmV4Cj4gIC0gcnVieS1sZXgKPiAgLSByYWNjCj4gIC0gcnVi
eS15YWNjCj4gIC0gY29jby1yYgo+ICAtIFRyZWVUb3AKPiAgLSBSYWdlbAo+Cj4gIEZvciBub3cg
SSBkb24ndCBsb29rIGZvciB0aGUgZmFzdGVzdCBhbmQgbW9zdCBlZmZpY2llbnQgcGFyc2VyLCBt
YXliZSBqdXN0IGZvcgo+ICB0aGUgZWFzaWVzdCBvbmUuCgpJZiB5b3Ugd2FudCBlYXN5LCBUcmVl
dG9wIHdpbnMgaW4gdGhhdCByZWdhcmQgYnkgYSBsb25nIHNob3QgdmVyc3VzCnJhY2MsIHJ1Ynkt
eWFjYywgb3IgcmFnZWwuCgpEYW5pZWwgQnJ1bWJhdWdoIEtlZW5leQo=

ThoML

3/17/2008 5:32:00 AM

0

> If you want easy, Treetop wins in that regard by a long shot versus
> racc, ruby-yacc, or ragel.

In rubyquiz 155 (http://rubyquiz.com/qu...), Grammar performed
pretty well. I haven't tried it out myself yet but the code looks
quite readable (see "some" submissions by E Mahurin).

Regards,
Thomas.