That would be cool if it was merged! I haven't yet looked into the breaking changes from 1.4 to 1.5. I have my bindings for the Go language, and a colleague is using them happily so far on 1.4, which is the current version at the studio. I may need to do another pass and have a 1.5 branch. My bindings still don't have all of the algorithms exposed yet, so there is work to be done anyways :-)
On Sat, 29 Nov 2014 10:39 AM Larry Gritz <[email protected]> wrote: > Aha, interesting, I'd forgotten about that. > > I will see if I can cleanly cherry-pick those commits. If I can do so > without breaking anything (and double checking that the changes don't alter > any public APIs), I'll merge it. > > The other alternative is that you could pick a recent tag in the master > branch, where this has already been fixed. Any place where I have tagged it > (e.g., "Release-1.5.6dev") will be pretty solid, and we're very close to > branching a stable 1.5 anyway. > > -- lg > > > On Nov 28, 2014, at 1:16 PM, Justin Israel <[email protected]> wrote: > > > I spent some time looking at this, and I realized that you had actually > done some work on the error reporting, but they aren't picked into the 1.4 > branch: > > https://github.com/OpenImageIO/oiio/commit/73af64b64867785e8c1ccca1ad3a8dff87777f0e > > https://github.com/OpenImageIO/oiio/commit/65eeee465edf030867ed7468632a5e6dcadfbb5b > > I see that you now have an error() function that exits non-zero, and it > gets called in the output logic when there is a write error. Can this stuff > get merged into 1.4? > > > > On Sat Nov 29 2014 at 6:58:12 AM Larry Gritz <[email protected]> wrote: > >> If you look in oiiotool.cpp, in action_diff, you'll see something like: >> >> if (ret != DiffErrOK && ret != DiffErrWarn) >> ot.return_value = EXIT_FAILURE; >> >> This is the value that's eventually returned when oiiotool exits. >> >> There may be other places, and other error conditions, where we should be >> doing this. >> >> >> On Nov 28, 2014, at 2:44 AM, Justin Israel <[email protected]> >> wrote: >> >> I can definitely take a look at it tomorrow. Just wanted to check the >> intention. As long as oiiotool exits non-zero when there are write errors, >> that would be a win. >> >> >> On Fri, 28 Nov 2014 8:36 PM Larry Gritz <[email protected]> wrote: >> >>> I think returning 0 from this function is fine, but I agree that if some >>> output file is unable to write, a flag should be set so that oiiotool as a >>> whole gives a shell return code indicating an error (i.e., not zero). >>> >>> This is not intentional, and returning an error code so it can be >>> scripted with error checks is a good thing. So it should definitely be >>> fixed. >>> >>> I can do it if you want, or feel free to give it a stab. Let me know >>> which you prefer. >>> >>> -- lg >>> >>> >>> >>> On Nov 27, 2014, at 4:09 PM, Justin Israel <[email protected]> >>> wrote: >>> >>> I'm curious about some behaviour I am seeing, and whether or not anyone >>> has encountered this and found it to be problematic? >>> >>> oiiotool seems to exit with an exitcode 0 even if the file it was >>> writing failed: >>> https://github.com/OpenImageIO/oiio/blob/master/ >>> src/oiiotool/oiiotool.cpp#L540 >>> >>> So what I end up seeing in my render pipeline process is that oiiotool >>> kind of blows through a sequence "successfully" even if the output >>> directory did not exist. Is this expected behaviour or a bug? Do most >>> people tack on a post check that all of the frames are there? I had assumed >>> I could rely on the exitcode to know if the call to oiiotool failed to do >>> the job. >>> >>> Is this something that would break people if it were corrected to return >>> a non-zero exit code if the write fails? >>> >>> >>> -- >>> Larry Gritz >>> [email protected] >>> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> >> -- >> Larry Gritz >> [email protected] >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > > -- > Larry Gritz > [email protected] > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
