[gst-devel] parsing problems

[Benjamin Otte]

A workaround for the bison bug is in CVS.

Benjamin

On Wed, 23 Apr 2003, Benjamin Otte wrote:

> On Wed, 23 Apr 2003, Thomas Vander Stichele wrote:
>
> > I'm getting increasingly confused and annoyed by the problems we're
> > currently experiencing in HEAD wrt pipeline parsing.
> >
> This has to be going on for as long as 24 hours now. I'm not aware of that
> bug much longer. You seem to be easily frustrated :)
>
> > A simple gst-launch filesrc ! fakesink is running infinite loops without
> > ever getting started.
> >
> > I've been told this is due to bison.
> >
> I currently think this is due to bison. I have success stories from people
> upgrading bison to 1.875 who had that bug before. I have 1.875 and never
> had that bug. Pipeline parsing works perfectly here.
>
> > Firstly, I must honestly say I've never ran into bugs with the old parsing
> > syntax.  Company said there was something wrong with it, did a lot of work
> > (for which we of course thank you), then came up with something new that
> > has a different syntax which we probably don't fully get yet - but it is
> > irritating that we have to force a change.
> >
> The old pipeline parsing only worked because of a bug that was
> intentionally left in. Fixing that bug required fixing parsing which made
> me so annoyed at what we had that I decided to rewrite it. Other things
> the old parsing had were memory leaks (it never freed anything, just kept
> on allocating) and a weird grammar, where spaces sometimes mattered and
> sometimes not.
> As for differences I would say that you haven't really tried getting the
> new concept. There's still the doc which you could have tried reading that
> would have explained it to you.
> But because people seem to be lazy, I will now tell you all of the
> incopatible changes that I've made and that you definitely will have to
> have a hard time learning:
> 1) explicit references (that is what you use to specify what pads to link)
> require a dot now in any case. So you don't say "pipeline audiopad!
> osssink" anymore but say "pipeline .audiopad! osssink".
> This change is absolutely necessary because the new parser would try to
> parse the pipeline as "pipeline audiopad ! osssink" and tell you that
> there is no element of type "audiopad".
> 2) If you specify pads (you don't have to anymore) you specify them by
> name, not by name of the padtemplate unless you use request pads, where
> you have to use the padtemplate name (because only in that case there is
> no pad yet). So you would use "filesink0.src" (normal pad) "tee0.src%d"
> (request pad) or "mpegdemux0.audio_00" (sometimes pad). The last case
> could be done differently before I think. (You can in all cases omit the
> audio pad; "filesink0.", "tee0." and "mpegdemux0." should work, too.
> This was done because I removed the AI to do padname->pad matching from
> the pipeline parsing and moved it to gst_element_link_pads_filtered, which
> is used for every gst_element_link_* function.
> If that function should match padtemplate names in addition to pad names
> when matching pad names this incompatibility would be gone, but I do not
> know if that is desired or would break some applications using that
> function. I would prefer it but didn'T get around to ask this question
> yet.
>
> > What's worse though is that apparently it does not work with my very
> > recent rh9-included bison.
> >
> > So something is wrong, and I don't understand what it is.
> >
> > I see two options:
> > - we revert back to the old parsing grammar, which I don't know what was
> > wrong with, but worked fine
> > - somebody does the work to properly make our new parsing stuff work on
> >   reasonably standard bison versions (I count rh8's and rh9's bison
> >   as "standard", and you all are welcome to declare some debian and
> >   other distro versions as standard).
> >
> I see a third option:
> - we require bison 1.875 in HEAD and include the generated files in the
>   tarballs of releases for now - if bison really is the cause of the bug
>   and it's not me. In the case GStreamer is at fault we should fix it. And
>   afaik it's bison's fault.
>
> > Basically I'm saying that we shouldn't start enforcing people to upgrade
> > standard old development tools when chances are part of the problem is
> > ours and it can be fixed more elegantly.
> >
> I remember a time where HEAD required cvs libtool.
>
> > Also, this really tells us that we should work at getting some osort of
> > regression testing going, because this is the sort of thing we really need
> > to avoid.  If the simplest of pipelines fails, we probably cannot begin to
> > assess what else might go wrong.
> >
> There is a pipeline testsuite in testsuite/parse which gets updated as I
> find new bugs.
> If it currently does not work it might be because Wim broke GstAggregator
> to not signal EOS anymore and hasn't fixed it yet. All other pipelines in
> those tests should work fine, I tested them the last time I changed
> something.
>
> Benjamin
>
> > So, Leif, where you at ? :) Let's get together and set up a test suite.
> >
> > Thomas
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>