[gstreamer-bugs] [Bug 600195] dynamic fragment shader filter and variables parser/loader
bugzilla at gnome.org
Sat Apr 24 07:23:17 PDT 2010
GStreamer | gst-plugins-gl | git
--- Comment #11 from Luc <luc.deschenaux at freesurf.ch> 2010-04-24 14:23:12 UTC ---
(In reply to comment #10)
> > Why do you need a parser to load files without validation nor uniform
> > loading ? open() and read() do the same job.
> Uh, obviously I don't need it, I was just pointing you to that since you
> mentioned you wasn't able to find it anymore. Also from your comment it seemed
> that if that parser was still available you wouldn't have had to write a new
> one from scratch
Oh i remember now, thanks ! But it was before writing one from scratch, it's
coming too late :)
> > I'm in Thailand since a few months, i just started to update my gstreamer
> > and gst-plugins-gl sources the other day because i need to finish Kifu.
> > But I'm in holidays and payed work allowing me to stay longer is my
> > priority.
> Sure, no hurry, I just wanted to know if you were still available and willing
> to work on this.
I'm still alive and i still need it :)
> I'm not sure if you ever worked on maintaining a free software project. People
> wanting to add cool feature or to scratch their itch come every day.
Fortunately i never ran into it, since i'm usually alone to maintain my free
software projects :)
> They write their cool code and then disappear and the maintainer is left with
> more code to keep track of.
Everybody disappear one day.
> I'm not talking particularly about you so no
Oh don't worry i lost my ego long time ago :)
> I'm just saying that sometimes a documented patch really helps the
> people who will have to look at your code in the future.
I know it's true, and i didn't do it. Bitching is welcome, i deserve it :)
> > To understand the parser the easy way, i suggest you to write a test application calling
> > gst_gl_shadervariables_parse(0,"uniform int test=(int)10;",0) from
> > gstglshadervariables.c and use a debugger and 'step into' to see what happends.
> Are you serious?
Unfortunately yes :) I cannot see a quicker way to totally understand the
parser right now.
> > Maybe I'm gonna add comments so that you just feel better and waste less time
> > and energy while trying to understand something you dont need to.. (but is it
> > really necessary to waste OUR time and energy before theres a real need ?)
> Again I'm pretty sure your code works fine and doesn't have any bug.
I would not bet on "doesn't have any bug", but I did not see a bug after the
last I did fix; and since it has not been commited i have no user feedback.
> But that's just not enough. I cannot believe you think your patch is ready to
> be committed as is.
For beta testing and waiting for motivating feedback, it seems me it could have
been commited 'as is' without demotivating bitching when i did post it. It
doesn't break existing plugin functionalities. Now in addition to adding
comments and cleaning code, i need time to adapt it for the current plugin
> Would you at least split your big patch into single self contained commits?
> For example, all the new functions you added to gstglshader are ready to be
> committed. Also could you move the shader loading code into gstglshader so that
> it's reusable by other plugins? Remove all that commented code? Add at least a
> comment to each function to explain what's supposed to do?
Sure, i will do this.
> There is a thing that puzzles me without looking at the code:
> "type name[arraysize]=type[arraysize](value[,value]);"
> Why do you need the type cast after the "="? can the type of the rvalue be
> different from the variable type you just declared? Sorry if it is something
> silly... maybe I'm just too tired to see the reason.
It is just strict syntax. Maybe it was easier to implement(?) or my ATI driver
shader compiler require the same explicit type cast after the affectation
operator and i mirrored the behaviour(?)... I made this choice for one of those
reasons or both but i cannot remember exactly today.
> > Regards from the kingdom of smile,
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs