[gst-devel] parsing problems

[Thomas Vander Stichele]

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 :)

I was expressing confusion over all of the problems resulting from the 
change combined, not only my current bug.

> > 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.

memleaks are bad but fixable I think.  The spaces (or rather lack of 
spaces) were important when chaining a pad off of a plugin to a partial 
pipeline, and that's it.  Don't think it was too difficult, gst-launch-ext 
has a whole bunch of pipelines that demonstrate that.

I can understand people not wanting to maintain other people's code, but I 
think effort should be made to ensure :
- the end user changes are minimal (ie, right now we have a new "syntax"
for pipelines that probably breaks gst-launch-ext as well as possibly
some apps that relied on partial pipeline parsing (even our gconf keys are
parsed, btw)
- the stuff should be buildable with tools that aren't too cutting edge 
unless it absolutely cannot be avoided
- one chunk of code that was only maintainable by the author isn't
  replaced by another chunk of code maintainable only by it's new author
  which will end up being rewritten the next time someone wants to change
  it

I'm not complaining or flaming or anything; I just want to avoid making 
the situation worse or only a status-quo, it should become better.

> 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.

I'm not even at the point where I can try out the changes :) I first need 
to get the basic problem fixed.
All I know is that there *are* differences and the benefits of having them 
should outweigh the costs of inflicting the changes.

> > 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.

So, wouldn't it be possible for you to install a reasonably old but also 
reasonably new (say, 1.35) version of bison to verify or deny that the 
problem really is bison ? I understand why you didn't see the problem, but 
I hope you agree that it ought to work sanely on a reasonbly new version 
of bison.  You might have used a feature that wasn't working right or 
available in previous versions of bison.  Or, you might be making a 
mistake in gst that is prevented in a newer bison.  

But I find it hard to 
believe that it really is bison that is to blame when bison's code has 
been around for a longer time than our new parsing code.  I'm not doubting 
your ability as a coder, far from it ! :) I'm just saying - as long as you 
ahven't checked what is going wrong between gst and bison < 1.875, chances 
are our code is to blame and not theirs.


> > 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.

Yes.  I also remember a lot of attempts at trying to make it work with 
non-cvs libtool (it wasn't cvs libtool that was required btw, it was a 
simple patch applied to libtool that was required) and the pain involved 
in all of that.  So that showed us it was worth investing some effort in 
finding a better solution than that so as to not decrease our developer 
base.

All this just MO of course, but I think it is important to keep the 
threshold to developing with gst low.

Thomas

-- 

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
Don't you see that my heart's on fire
wicked wings that you spread round me sometimes
All I know is we've got to aim higher
Babe I wish that we'd go for the great escape
<-*- thomas  (at) apestaart (dot) org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/