Subject: Re: Packages extension queries.

From: Rajendra Patil <[email-masked]>
Date: Thu, 6 Jul 2000 10:17:04 +0530

Hi

 Lex-Yacc code may not be MT safe.

May be you can try reguler expressions lib.
Check regcmp/regex functions available in libgen.h

Hope this helps

Regards/
Rajendra

Panditha Govindraj <[email-masked]> on 07/06/2000 09:21:47 AM

Please respond to Panditha Govindraj <[email-masked]>

To:   [email-masked]
cc:

Subject:  Re: Packages extension queries.

Hi All,

Can some body give some design suggestions about Megaco Parser , Which can
really be efficient,

Can we use lex yacc

Govind

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 6 Jul 2000 21:03:05 -0400

Some folks are indeed using a yacc/lex based parser.
Others are constructing an LL(1) parser.  I wouldn't
be surprised if there were others out there.

Yacc/Lex is likely to be easy, but is also likely to
be pretty big (code size).  LL(1) is likely to be
pretty small and efficient.  I doubt that parsing
is going to be a big deal, although I suspect when
we talk about binary vs text, that issue will come
up.

If you are good at parser construction, I'd probably
suggest looking at something like LL(1).  If you aren't,
yacc/lex (or the GNU equivalents) are likely to work
best for you -- YMMV.

Brian

> -----Original Message-----
> From: Panditha Govindraj [mailto:[email-masked]]
> Sent: Wednesday, July 05, 2000 11:52 PM
> Can some body give some design suggestions about Megaco
> Parser , Which can really be efficient,
>
> Can we use lex yacc
>
> Govind
>
>
> Michael Brown wrote:
>
> > Ooops... My comment about ill defined package hierarchy was
> based on a misread on my part. John and Christian have set the
> > record straight. Sorry for the confusion.
> >
> > Michael
> >
> > John Segers wrote:
> >
> > > Hi,
> > >
> > > My understanding of the package extension mechanism is
> the same as that
> > > of Tom, Mike and Christian.  One addition: if B and C
> both extend A, and
> > > B and C (independently) define a property x1, then B/x1
> and C/x1 are
> > > different properties (as Christian indicated).  So a
> change to B/x1 does
> > > not result in C/x1 changing as well.
> > >
> > > I don't completely that the package hierarchy is
> ill-defined per se in
> > > such a situation.  It could be the case that B and C
> define regional
> > > extensions to an international package, and that my GW is
> a multi-region
> > > device.
> > >
> > > Cheers,
> > >
> > > John
> > >
> > > Christian Groves wrote:
> > > >
> > > > G'Day Michael and Tom,
> > > >
> > > > Please see my comments below marked CHG.
> > > >
> > > > Cheers, Christian
> > > >
> > > > Michael Brown wrote:
> > > > >
> > > > > Comments inline.
> > > > >
> > > > > Michael
> > > > >
> > > > > "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >      -----Original Message-----
> > > > > >      From:   Madhu Babu [SMTP:[email-masked]]
> > > > > >      Sent:   Thursday, June 29, 2000 1:36 AM
> > > > > >      Subject:        Packages extension queries.
> > > > > >
> > > > > >      There are two packages A and B. Package B extends A,
> > > > > >      Say, properties a1 and a2 are in package A and
> x1 in package B.
> > > > > >
> > > > > >      1) If a termination realizes package B, does
> it mean that it
> > > > > >      also realizes
> > > > > >      package A?
> > > > > >      [PTT]
> > > > > >      Yes.
> > > > > >
> > > > > >      2) Can property of package A be addressed as
> B/a1? If 1) is
> > > > > >      true, is it that
> > > > > >      only A/a1 is possible?
> > > > > >      [PTT]
> > > > > >      This was discussed in Red Bank when we
> finalized our package
> > > > > >      schema, but I can't remember the conclusion.
> Christian, John,
> > > > > >      or Michael, do you remember?
> > > > > >
> > > > >
> > > > > I remember that the answer (consensus) was that the
> preferable way to
> > > > > refer to a1 is as B/a1. One could use A/a1, because
> there really is
> > > > > only one property defined where both names refer to it.
> > > >
> > > > [CHG] That's what I understand.
> > > >
> > > > >
> > > > > >
> > > > > >      Lets there be third package C, which also
> extends A. and it
> > > > > >      also defines a
> > > > > >      property x1
> > > > > >      3) Can a termination realize packages B and C ?
> > > > > >
> > > > >
> > > > > Well, I would say that the answer is yes that a
> termination COULD
> > > > > realize both, but my feeling is that this situation
> would be due to a
> > > > > poor definition of  the packages hierarchy. Given
> your hypothetical
> > > > > description rather than a real example where this
> would appear to be a
> > > > > desirable approach, I would think that C should
> extend B rather than
> > > > > A.
> > > >
> > > > [CHG] I'm not sure of the question or the response but
> to me even if two
> > > > packages B & C extend A with a property x1 then the two
> instances of x1
> > > > are uniquely identified by the package name B&C. The
> two instances of x1
> > > > could be completely different functions but
> (unfortunately) have the
> > > > same name.
> > > >
> > > > >
> > > > > >
> > > > > >      -
> > > > > >
> --------------------------------------------------------------
> --------------------------------------------------
> > > > > >
> > > > > >      Lets there be a third package C, which also
> extends A. and it
> > > > > >      also defines a
> > > > > >      property c1
> > > > > >      A termination realizes both package B and C.
> > > > > >      4) what will be value of A/a1 which is
> referred by both B/a1
> > > > > >      and C/a1.
> > > > > >      If B/a1 value is changed is it that the value
> of C/a1 is also
> > > > > >      changed?
> > > > > >
> > > > >
> > > > > Based on my previous two responses, C/a1 would be
> changed, but this
> > > > > situation is one that to me would indicate that the
> package hierarchy
> > > > > has not been properly defined. I don't think this
> should ever happen.
> > > >
> > > > [CHG] I think A/al, B/al and C/al will all change
> because they are the
> > > > same property.
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >      -Madhubabu
> > > > > >
> > >
> > > --
> > > John Segers                                  email:
> [email-masked]
> > > Lucent Technologies
>  Room HE 303
> > > Dept. Forward Looking Work                      phone:
> +31 35 687 4724
> > > P.O. Box 18, 1270 AA  Huizen                      fax:
> +31 35 687 5954
>
>