Merged. I haven't tagged a release with it yet, but it is now included in RB-1.5.
On Nov 28, 2014, at 1:45 PM, Justin Israel <[email protected]> wrote: > 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 -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
