Looks good to me. (I tested this, as well as all the related post-email updates). -- Jeremy <malcolmh...@...> wrote:

Do you think the 'reference' colorspace should in a separate section in the profile? This would be similar to the PCS in the icc world. It could be an extra line 'reference: !<ColorSpace> ...' before

- added yaml-cpp r443 which contains the new YAML::Newline emitter manipulator http://stackoverflow.com/questions/3982901/how-to-emit-a-blank-line-using-yaml-cpp - added some 'out << YAML::Newline' to

- fixed a bug with abs searchpath entries - empty '::' searchpaths now resolve to the profile

- removed the EnvExpand recusion limits as this didn't work in the production env which has more than 30 env vars. might want to add limits in later if this becomes a

Inital pass at searchpath impl - added environment variable string expansion code in PathUtils.h (GetEnvMap() & EnvExpand()) - added FileExists() function to PathUtils.h - added searchpath

- removed some #pragma's which were breaking the build on linux, there are a few more warnings now to do with template<> visibility in yaml-cpp but it should now link on linux (was working on

- Inital pass at GCC visibility http://gcc.gnu.org/wiki/Visibility to hide unnecessary public symbols in an effort to maintain ABI - Added -fvisibility-inlines-hidden and -fvisibility=hidden to the

Done. -- jeremy

The first release based on YAML is now ready for download. Thanks to Malcolm for his help on this. An updated set of 0.7-format color configs (with many more color spaces!) will be posted

All LGTM, sorry most of these were introduced by me in the switch

Yep, I was thinking about doing that but it's not straight forward if we don't want yaml-cpp in the public interfaces for the Transforms()s. It could also be possible if we have some form of

These commits fix a bunch of bugs we discovered when testing our in-house apps on real production color configurations. * Yaml serialization fix, resource_path is updated properly * Relative path

Thinking about this topic further, I think the right thing to do it to have __str__ call through to the C++ ostream implementation for each class. (If that happens to use yaml, great! But it's not a

Looking at this quickly it would be a pretty small patch to add out << YAML::NewLines(3); Something along the lines of: --emittermanip.h-- struct _NewLines { _NewLines(int value_): value(value_)

This looks all pretty good to me - Can we call AddBaseTransformPropertiesToYAMLMap = EmitBaseTransformKeyValues - Can we call ReadBaseTransformPropertiesFromYAMLMap = ReadBaseTransformKeyValues, and

A bunch of changes related to yaml serialization: * ColorSpace transform a base Transform, instead of GroupTransform. * GroupTransform Yaml serialization supports nesting * Direction is now

I did see that comment, forgot to address it in the last post. I'd prefer to not expose the exact yaml serialization using __str__(). I'm pretty biased against "non-obvious" operator overloading

looks good to me. <malcolmh...@...> wrote:

- Added missing NAME arg to add_test() as this was failing to work on linux (worked on OSX, small cmake