Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

Hi! On 2016-01-13 at 18:29 (CET), Larry Gritz wrote: > I don't understand it completely, but I have a theory. > > Can you try an experiment for me? > > In imagecache.cpp, line 2113, you'll see ImageCache::check:max_mem(). > Please add the following at the very start of the function body,

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

Hi! On Tue, Jan 12, 2016 at 9:26 AM Matteo F. Vescovi wrote: > I guess I'm gonna try it later today (CET), since I'm at work place now. > Feel free to have some sleep now ;-) > I'll let you know if it works when you wake up. > So, it builds... almost. It fails on the

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

I don't understand it completely, but I have a theory. Can you try an experiment for me? In imagecache.cpp, line 2113, you'll see ImageCache::check:max_mem(). Please add the following at the very start of the function body, immediately BEFORE the DASSERT of line 2113: #ifndef NDEBUG if

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

I think I understand what's going wrong. How about this: https://github.com/OpenImageIO/oiio/pull/1315 That's a fix against 1.6. Can you give that a try? > On Jan 11, 2016, at 11:29 PM, Matteo F. Vescovi wrote: > > Hi! > > On Mon, Jan 11, 2016 at 2:52 PM, Matteo F.

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

For those worried about binary size, under Linux you can do something like the following, which builds with the '-g' flag thus has all the debug information in the object, then extracts the debug info to a separate file and then strips it from the main object and adds back a reference to the debug

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

That sounds to me like a small price to pay in order to always have a clean stack trace and be able to profile without a recompile. We can add a build-time flag to force not using -g, for those who really don't want to pay for the 70M. Does that sound reasonable? Or do you think the default

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

I think it should be the other way around as I expect production builds to be smallest possible to speed up any IO when software is installed on network storage. It’s a bit like saying your expecting the software to crash so make the library 3x bigger.. OIIO is pretty stable in most places I

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

Hi! On Mon, Jan 11, 2016 at 2:52 PM, Matteo F. Vescovi wrote: > Hi! > > On Mon, Jan 11, 2016 at 5:54 AM, Larry Gritz wrote: >> * Almost always, the Debian build breaks are "warnings" that are treated as >> errors. You may wish to consider compiling

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

On Mon, Jan 11, 2016 at 9:26 AM, Thiago Ize wrote: > There's a difference between symbols (-g), -DNDEBUG, and "debug mode" > (-O0, -g). If you're actually building in debug mode and then stripping > symbols, all your users are now getting a really slow and crappy OIIO >

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

There's a difference between symbols (-g), -DNDEBUG, and "debug mode" (-O0, -g). If you're actually building in debug mode and then stripping symbols, all your users are now getting a really slow and crappy OIIO without any optimizations. What you want is to just add the debug symbols (-g) to

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

So you'd want to also add in -DNDEBUG. There's a bunch of other flags that OIIO sets which you probably would also want to include. On Mon, Jan 11, 2016 at 9:29 AM, Richard Shaw wrote: > On Mon, Jan 11, 2016 at 9:26 AM, Thiago Ize wrote: > >>

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

The build is still ultimately using cmake, no? That should still create an optimized build by default, including -DNDEBUG. I agree that if policy is simply to have symbols, we should just make an option to add -g, not make a full DEBUG build. A true debug build absolutely kills performance.

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

I think profile mode should be the same as release mode but with -g added in, otherwise it's possible I'll waste time trying to optimize a hotspot in -O2 that doesn't exist in the -O3 build. Furthermore, this would make it simple for the fedora/debian/etc... builds to build with symbols -- they

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

Is there a down-side to using -g to include the symbols for all optimized builds? Does it make the library or binaries dramatically bigger? (You can always strip binaries to fix that.) There are no secrecy- or security-based reasons to avoid symbols, as you might for a commercial product.

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

There is nothing sacred about the current profile mode. If a different set of flags would be more useful, let's change it. -- lg > On Jan 11, 2016, at 7:26 AM, Thiago Ize wrote: > > There's a difference between symbols (-g), -DNDEBUG, and "debug mode" (-O0, >

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

For the Fedora debug builds, is it merely required to have -g symbols (so you can tell which OIIO functions are being called or get a readable stack trace in case of a crash), or do you need full line-by-line symbol-by-symbol debugging ability WITHIN the OIIO library? > On Jan 11, 2016, at

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

Based on those logs, I think the specific problem has already been fixed. Can you try the current "top" of RB-1.6 to verify? If it works, I'll tag the current top and declare a new release if you need. We just recently started having the Travis-CI tests include a debug build (and that's why it

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

Hi! On Fri, Jan 8, 2016 at 8:55 AM, Ghislain Vaillant wrote: > Works if you disable error on warnings with -DSTOP_ON_WARNING=OFF. I believe > I mentioned this fix in the private email exchange we had yesterday. Well, it sounds to me like a workaround more than a fix and I