On Tue, May 7, 2013 at 2:41 AM, Janne Liljeblad <janne.liljeb...@gmail.com> wrote: > Hello Dan, > > I was doing some edits for upcoming 1.0 Flowblade release. > > I discovered that when setting parameter values for frei0r plugins MLT > 0.8.8 converts string expressions of float values to 0 or 1 instead of the > intended float value. > > So anything < "1.0" is converted to 0 and "1.0" is converted to 1.0, as the > previous behaviour was that "0.5678" was converted to 0.5678 and not to 0.
No, it does not: See the unit test DoubleFromString() https://github.com/mltframework/mlt/blob/master/src/tests/test_properties/test_properties.cpp If I change the values used in that test to "0.567800" and 0.5678, it still passes. Maybe you are affected by numeric locale. See test RadixRespondsToLocale() in the same file. If you are running in an environment that defines the radix as a comma, then indeed "0.5678" will get converted to 0. > When float paramater values are converted from strings to MLT plugins, the > behaviour remains the correct one, string expressions of floats are > converted to float values so "0.5678" is converted to 0.5678. > > This breaks Flowblade on all systems with MLT 0.8.8. > > I'm writing out parameter values with the same function for string parameter > values and float parameter values, and have been doing so since 2009-2010 > and it has always worked, I've used the method below: > > def write_mlt_property_str_value(self, str_value): > # mlt property value > filter_object = self._get_filter_object() > filter_object.mlt_filter.set(str(self.name), str(str_value)) > > I can fix this for frei0r parameters with float values by changing the > method to: > > def write_mlt_property_str_value(self, str_value): > # mlt property value > filter_object = self._get_filter_object() > filter_object.mlt_filter.set(str(self.name), float(str_value)) # > <----- str( ) changed to float( ) here > > but this breaks all plugins using the same method for string values. > > I need to know: > 1) Is this a bug? What bug? It would help if you make a simple example demonstrating the problem. > 2) If not, what is the purpose of the change? If it is the locale that causes the change, then the purpose is to behave correctly according to the locale. > 3) If it is a bug, when will it be fixed, and when will the fixed MLT be > available on the popular distributions? I have no idea when distributions will get things, but I know it is generally not good. The next release of MLT is not soon because it will be a major new release with API changes. > Further more: > 1) Do you have test suits that are supposed to prevent this kind of > regressions from happening? we do now -- +-DRD-+ ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Mlt-devel mailing list Mlt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mlt-devel
