Date   

Review: Adds build option to use boost ptr instead of tr1

Jeremy Selan <jeremy...@...>
 

https://github.com/imageworks/OpenColorIO/pull/96

This adds a compile-time option to use boost ptr instead of tr1. The
tr1 ptr is defaut, but for folks who had already locked off on OCIO
0.7s ABI before the removal of boost (such a Imageworks), this lets us
compile without breaking binary compatibility. This code path will
also be necessary for windows support, which apparently does not have
tr1 support yet.

-- Jeremy


Re: Review: Build Nuke stuff into lib/nuke6.2

Malcolm Humphreys <malcolmh...@...>
 

LGTM

long live the bubbles system ;)

On 04 Apr, 2011,at 11:25 PM, dbr/Ben <...@...> wrote:

https://github.com/imageworks/OpenColorIO/pull/94

Comment should explain the change best:

// Nuke aims to maintain API compatibilty between "v" releases, so
// compiling for 6.1v1 will work with 6.1v2 etc (but not
// 6.2v1). Only exception has been 5.1v5 and 5.1v6 (because it was
// supposed to be 5.2v1)
Mirrors how The Foundry's plugins are supplied (e.g Ocula downloads for 6.1/6.2). The info on 5.1v5-6 was from a message to nuke-dev a while ago.

Combined with the CMAKE_INSTALL_EXEC_PREFIX change, OCIO can now compile perfectly into RSP's project deployment/package management stuff \o/


Review: Build Nuke stuff into lib/nuke6.2

dbr/Ben <b...@...>
 

Comment should explain the change best:

// Nuke aims to maintain API compatibilty between "v" releases, so
// compiling for 6.1v1 will work with 6.1v2 etc (but not
// 6.2v1). Only exception has been 5.1v5 and 5.1v6 (because it was
// supposed to be 5.2v1)
Mirrors how The Foundry's plugins are supplied (e.g Ocula downloads for 6.1/6.2). The info on 5.1v5-6 was from a message to nuke-dev a while ago.

Combined with the CMAKE_INSTALL_EXEC_PREFIX change, OCIO can now compile perfectly into RSP's project deployment/package management stuff \o/


Review: OCIOCDLTransform node

dbr/Ben <b...@...>
 

As per #60 - a OCIOCDLTransform Nuke node, along with a bunch of buttons to import/export .cc/.ccc files

Not entirely sure about the node name, but OCIOCDLTransform seemed more consistent with CDLTransform in the config

There are buttons in the node to import and export a .cc file. Also a new Color > OCIO > Utils menu, to create a node for each ColorCorrection in a .ccc, and to export a bunch of nodes as a .ccc

If you import a .ccc file in the node, it'll display a "select a cccid" dialog - was planning to use the same dialog for the OCIOFileTransform, when a .ccc file is loaded


Re: OCIO for Windows

Marie Fétiveau <m...@...>
 

Hello Jeremy !

Thanks for your reply ;)

The IDT/ODTs we made are not already expressed in CTL. They are simple "matrix + transfer function" that can also be computed into 3DLUT.
I also have some samples (created by IIF) that are in CTL. I looked at some of them and it seems that they also describes matrix + function or LUT.

So, as I don't have a CTL_ToSthElse function for now, I think I'll just formulate them in OCIO vocabulary (firstly).

I made a branch but I never used Git before. 
That's a good oppotunity to become familiar with it.
I've just created a GitHub account and started to watch the OCIO project.
I merge my current version of the code with the last version on the remote master branch (good git training) but I didn't have time to check if it still compiles on MSVC. I guess it's not.
Please be aware that my modifications are tests draft ;p


Cheers,

Marie

On Fri, Apr 1, 2011 at 1:40 AM, Jeremy Selan <jeremy...@...> wrote:
Marie,

Thanks for the email.   In terms of testing OCIO with new IDT/ODTs,
are your transforms CTL programs, or have you formulated them in the
OCIO vocabulary. (luts, matricies, etc).

I believe you are the first to attempt to use it on Windows, though it
was always in our plan to add eventual support.  I suppose now is the
time to get it in.

Have you made a branch of the git repository?  Are you on github? I'd
love to see all the changes you've made. If you aren't familiar with
git and would prefer to send me diffs, that will be fine as well.

I'll try to find a Windows machine at work, so we can work through the
remaining compilation issues together.  Then if any changes are needed
for cross-platform compatibility, we can get them in before the 0.8
API lockdown.

Cheers,
Jeremy



2011/3/30 Marie Fétiveau <m...@...>:
> Hello all !
> I finally have some time to have look at OCIO ;)
> In a few words, I'd like in a near future to set up in my studio a Color
> Pipeline integrating IIF and OCIO improvements.
> I'm part of a french project (HD3D²) which is already working on IIF. I'd
> like to make a proof of concept and give one of my partner (using Windows) a
> chance to test OCIO with some IDT/ODT we made.
> For now my first goal is : compile OCIO tools (ociodisplay, ociocheck,
> ocio2icc, ociobakelut, ocioconvert) for Windows.
> My usual tools for building on Windows are Eclipse + Boost.build + Mingw
> ; I'm not used to MSVC and Cmake so much.
> I first started with my favorite toolset with Cmake instead of boost.build.
> But I quickly realized that to make OCIOdisplay works I'll have to compile
> all OIIO plugins with Mingw (meaning a lot of dependencies which isn't
> impossible but very time consuming).
> Furthermore, as Nuke's dll are built with MSVC I might encounter some
> troubles trying to mix MSVC and Mingw libraries.
> On other projects, I tried pexports and friends, it did work but not always.
> Consequently, as I needed some test tools fast, I changed my mind and
> started to build everything using MSVC2010.
> OIIO happened to be really easy to compile (thanks to pre-compiled
> libraries).
> For OCIO, I had to change some piece of code :
> - use boost::rand48 instead of srand48
> - comment part between  the "#pragma GCC visibility" in OCIOYaml.h
> - use _fullPath instead of ::realpath
> - use  boost::shared_ptr + boost::dynamic_pointer_cast instead
> of std::tr1::shared_ptr  + std::tr1::dynamic_pointer_cast
> - comment setStringVar and getStringVar because of some errors on
>  StringMap::iterator iter = getImpl()->envMap_.find(name) -> error C2440:
> 'initialisation' : impossible to convert from 'std::_Tree_iterator<_Mytree>'
> to 'std::_Tree_iterator<_Mytree>' (in Context.cpp)
> - ... (some stuff about srand, isNan...)
> I guess that these changes may have a bad impact but for the moment it
> doesn't matter to me because I just need to see if I can get everything
> compiled.
> I 'm not so aware of the GCC's visibility pragmas.
> So that may be bad to have this part commented.
> Anyway it builds and I get OCIO libs (static and dynamic) and exes.
> But when I try to run OCIOcheck (static link with OpenColorIO.lib), I find
> out that no LUT file formats are recognized.
> Each Lut format registers itself via the AutoRegister static variable but it
> seems that this function is not even present it my exe whereas it is present
> in the original .lib. This prevents my formats to be registered at startup.
> I tried debugging and the file format list was actually empty.
> I tried some options in the Visual project properties ( /OPT:NOREF for
> example) but didn't find any that works.
> So I tried to link dynamically with openColorIO and added  in
> opencolorabi.h :
> #if defined  _MSC_VER
> #if defined EXPORT_DLL
>     #define OCIOEXPORT __declspec(dllexport)
> #else
>   #define OCIOEXPORT  __declspec(dllimport)
> #endif
> #endif
> It creates a .lib for the corresponding OpenColorIO.dll.
> But when I run OCIOCheck.exe I get a crash when the program tries to load
> OpenColorIO.dll...
> So here I am, I won't have time to work on this until next week but I
> thought that some people may have build this for Windows or/and may have
> some advices for me ;)
> Thanks for reading :)
> Cheers,
> Marie
>
>


Review: Add CMAKE_INSTALL_EXEC_PREFIX option

dbr/Ben <b...@...>
 


Re: OCIO for Windows

Jeremy Selan <jeremy...@...>
 

Marie,

Thanks for the email. In terms of testing OCIO with new IDT/ODTs,
are your transforms CTL programs, or have you formulated them in the
OCIO vocabulary. (luts, matricies, etc).

I believe you are the first to attempt to use it on Windows, though it
was always in our plan to add eventual support. I suppose now is the
time to get it in.

Have you made a branch of the git repository? Are you on github? I'd
love to see all the changes you've made. If you aren't familiar with
git and would prefer to send me diffs, that will be fine as well.

I'll try to find a Windows machine at work, so we can work through the
remaining compilation issues together. Then if any changes are needed
for cross-platform compatibility, we can get them in before the 0.8
API lockdown.

Cheers,
Jeremy



2011/3/30 Marie Fétiveau <m...@...>:

Hello all !
I finally have some time to have look at OCIO ;)
In a few words, I'd like in a near future to set up in my studio a Color
Pipeline integrating IIF and OCIO improvements.
I'm part of a french project (HD3D²) which is already working on IIF. I'd
like to make a proof of concept and give one of my partner (using Windows) a
chance to test OCIO with some IDT/ODT we made.
For now my first goal is : compile OCIO tools (ociodisplay, ociocheck,
ocio2icc, ociobakelut, ocioconvert) for Windows.
My usual tools for building on Windows are Eclipse + Boost.build + Mingw
; I'm not used to MSVC and Cmake so much.
I first started with my favorite toolset with Cmake instead of boost.build.
But I quickly realized that to make OCIOdisplay works I'll have to compile
all OIIO plugins with Mingw (meaning a lot of dependencies which isn't
impossible but very time consuming).
Furthermore, as Nuke's dll are built with MSVC I might encounter some
troubles trying to mix MSVC and Mingw libraries.
On other projects, I tried pexports and friends, it did work but not always.
Consequently, as I needed some test tools fast, I changed my mind and
started to build everything using MSVC2010.
OIIO happened to be really easy to compile (thanks to pre-compiled
libraries).
For OCIO, I had to change some piece of code :
- use boost::rand48 instead of srand48
- comment part between  the "#pragma GCC visibility" in OCIOYaml.h
- use _fullPath instead of ::realpath
- use  boost::shared_ptr + boost::dynamic_pointer_cast instead
of std::tr1::shared_ptr  + std::tr1::dynamic_pointer_cast
- comment setStringVar and getStringVar because of some errors on
 StringMap::iterator iter = getImpl()->envMap_.find(name) -> error C2440:
'initialisation' : impossible to convert from 'std::_Tree_iterator<_Mytree>'
to 'std::_Tree_iterator<_Mytree>' (in Context.cpp)
- ... (some stuff about srand, isNan...)
I guess that these changes may have a bad impact but for the moment it
doesn't matter to me because I just need to see if I can get everything
compiled.
I 'm not so aware of the GCC's visibility pragmas.
So that may be bad to have this part commented.
Anyway it builds and I get OCIO libs (static and dynamic) and exes.
But when I try to run OCIOcheck (static link with OpenColorIO.lib), I find
out that no LUT file formats are recognized.
Each Lut format registers itself via the AutoRegister static variable but it
seems that this function is not even present it my exe whereas it is present
in the original .lib. This prevents my formats to be registered at startup.
I tried debugging and the file format list was actually empty.
I tried some options in the Visual project properties ( /OPT:NOREF for
example) but didn't find any that works.
So I tried to link dynamically with openColorIO and added  in
opencolorabi.h :
#if defined  _MSC_VER
#if defined EXPORT_DLL
    #define OCIOEXPORT __declspec(dllexport)
#else
  #define OCIOEXPORT  __declspec(dllimport)
#endif
#endif
It creates a .lib for the corresponding OpenColorIO.dll.
But when I run OCIOCheck.exe I get a crash when the program tries to load
OpenColorIO.dll...
So here I am, I won't have time to work on this until next week but I
thought that some people may have build this for Windows or/and may have
some advices for me ;)
Thanks for reading :)
Cheers,
Marie


Re: 0.7.8 Released

Jeremy Selan <jeremy...@...>
 

A big heads up I forgot to mention, 0.7.8 is not binary compatible
with 0.7.7 due to the boost ptr change. My hope (and intent) is for
this to be the final binary incompatible change before locking off on
0.8.x stable releases (hopefully in the next week or two).

-- Jeremy

On Thu, Mar 31, 2011 at 3:41 PM, Jeremy Selan <jeremy...@...> wrote:
Version 0.7.8:
   * Iridas lut (.cube) bugfix, DOMAIN_MIN / DOMAIN_MAX now obeyed
   * Exposed GPU functions in python (needed for Mari)
   * Nuke OCIODisplay cleanup: Fixed knob names and added envvar support
   * ociobaker cleanup
   * tinyxml ABI visibility cleaned up
   * Removed Boost dependency, tr1::shared_ptr now used instead

-- Jeremy


0.7.8 Released

Jeremy Selan <jeremy...@...>
 

Version 0.7.8:
* Iridas lut (.cube) bugfix, DOMAIN_MIN / DOMAIN_MAX now obeyed
* Exposed GPU functions in python (needed for Mari)
* Nuke OCIODisplay cleanup: Fixed knob names and added envvar support
* ociobaker cleanup
* tinyxml ABI visibility cleaned up
* Removed Boost dependency, tr1::shared_ptr now used instead

-- Jeremy


OCIO for Windows

Marie Fétiveau <m...@...>
 

Hello all !

I finally have some time to have look at OCIO ;)

In a few words, I'd like in a near future to set up in my studio a Color Pipeline integrating IIF and OCIO improvements.
I'm part of a french project (HD3D²) which is already working on IIF. I'd like to make a proof of concept and give one of my partner (using Windows) a chance to test OCIO with some IDT/ODT we made.

For now my first goal is : compile OCIO tools (ociodisplay, ociocheck, ocio2icc, ociobakelut, ocioconvert) for Windows.

My usual tools for building on Windows are Eclipse + Boost.build + Mingw ; I'm not used to MSVC and Cmake so much.

I first started with my favorite toolset with Cmake instead of boost.build.
But I quickly realized that to make OCIOdisplay works I'll have to compile all OIIO plugins with Mingw (meaning a lot of dependencies which isn't impossible but very time consuming). 
Furthermore, as Nuke's dll are built with MSVC I might encounter some troubles trying to mix MSVC and Mingw libraries.
On other projects, I tried pexports and friends, it did work but not always.

Consequently, as I needed some test tools fast, I changed my mind and started to build everything using MSVC2010.

OIIO happened to be really easy to compile (thanks to pre-compiled libraries).

For OCIO, I had to change some piece of code :
- use boost::rand48 instead of srand48
- comment part between  the "#pragma GCC visibility" in OCIOYaml.h 
- use _fullPath instead of ::realpath
- use  boost::shared_ptr + boost::dynamic_pointer_cast instead of std::tr1::shared_ptr  + std::tr1::dynamic_pointer_cast
- comment setStringVar and getStringVar because of some errors on  StringMap::iterator iter = getImpl()->envMap_.find(name) -> error C2440: 'initialisation' : impossible to convert from 'std::_Tree_iterator<_Mytree>' to 'std::_Tree_iterator<_Mytree>' (in Context.cpp)
- ... (some stuff about srand, isNan...)

I guess that these changes may have a bad impact but for the moment it doesn't matter to me because I just need to see if I can get everything compiled. 
I 'm not so aware of the GCC's visibility pragmas.
So that may be bad to have this part commented. 

Anyway it builds and I get OCIO libs (static and dynamic) and exes.

But when I try to run OCIOcheck (static link with OpenColorIO.lib), I find out that no LUT file formats are recognized. 
Each Lut format registers itself via the AutoRegister static variable but it seems that this function is not even present it my exe whereas it is present in the original .lib. This prevents my formats to be registered at startup. I tried debugging and the file format list was actually empty.
I tried some options in the Visual project properties ( /OPT:NOREF for example) but didn't find any that works.

So I tried to link dynamically with openColorIO and added  in opencolorabi.h :
#if defined  _MSC_VER
#if defined EXPORT_DLL
    #define OCIOEXPORT __declspec(dllexport)
#else
  #define OCIOEXPORT  __declspec(dllimport)
#endif
#endif
It creates a .lib for the corresponding OpenColorIO.dll.

But when I run OCIOCheck.exe I get a crash when the program tries to load OpenColorIO.dll...

So here I am, I won't have time to work on this until next week but I thought that some people may have build this for Windows or/and may have some advices for me ;)

Thanks for reading :)

Cheers,

Marie



Review: Iridas (.cube) lut bugfix

Jeremy Selan <jeremy...@...>
 

https://github.com/imageworks/OpenColorIO/pull/90

Bugfix in Iridas (.cube) lut support. DOMAIN_MIN / DOMAIN_MAX now supported.
(also fixes a bug in Lut3DOp. from_min, from_max are now obeyed when
using linear interpolation.)

Thanks to Alex F. for providing lut example.

-- Jeremy


Review: Exposed Processor GPU functions to python

Jeremy Selan <jeremy...@...>
 

https://github.com/imageworks/OpenColorIO/pull/89

First step in the development of the Mari OCIO viewer plugin.

-- Jeremy


Review: Benign header cleanup

Jeremy Selan <jeremy...@...>
 

https://github.com/imageworks/OpenColorIO/pull/88

Removed OpenColorABI.h. Simpler just to put all the compiler specific
stuff in one header, OpenColorTypes.h
This doesnt effect ABI or code compatibility.

closes GH-57


Review: First pass at a ICCTransform

Malcolm Humphreys <malcolmh...@...>
 

https://github.com/imageworks/OpenColorIO/pull/87

Had sometime on the plane so did a first pass at a ICCTransform, which will be needed for 'iv color profiles/LUTs' on the https://github.com/OpenImageIO/oiio/wiki/GSoC-Idea-Page.

Would like some feedback on where the filepath resolution should be? It's easy for me to add this in the Op but most other things have this in the Transform, is this where this logic should sit?

I have not implemented the setInputMem(const void * inputPtr, int size) functions yet, but have added these to the transform interface, these would be used when loading icc profile embedded in file headers.

.malcolm


Review: Updated Nuke OCIODisplay, added config.getCacheID(), context.getCacheID(), ClearAllCaches()

Jeremy Selan <jeremy...@...>
 

https://github.com/imageworks/OpenColorIO/pull/84

nuke ociodisplay: ocio_populate_viewer works again
nuke ociodisplay: Renamed viewer knobs to "gain" and "gamma". This
allows them, when used as ViewerOps, to be driven by the existing
monitor interface.
nuke ociodisplay: added prototype for channel swizzling support. This
can't be enabled though until the OCIO cpu path supports alpha channel
handling (otherwise 'alpha' visualization wont be supported)
nuke ociodisplay: Added context support (per shot support)
core library: configs, and contexts can report cacheIDs.
Added OCIO::ClearAllCaches(), which will drop all cached information
about files on disk. (Will cause luts to be reloaded on next use)

closes GH-46
closes GH-15

-- Jeremy


Interesting article: How to use github effectively

Jeremy Selan <jeremy...@...>
 

Not directly related to OCIO, but I thought those github users on the
list may enjoy this article:
http://lumberjaph.net/dancer/2011/03/06/how_to_use_github_effectively_for_your_project.html

My favorite tip: if you include in your commit comment text such as,
"closes GH-123", it will automatically close the specified issue, and
link to the commit. How cool!

-- Jeremy


Review: FormatRegistry cleanup

Jeremy Selan <jeremy...@...>
 

https://github.com/imageworks/OpenColorIO/pull/82

This adds a bit more infrastructure behind the internal FormatRegistry. This checkin fixes the make test error in Baker.cpp, so format ordering is longer at the mercy of the static registration order. This also allows clients (such as ociobakelut) to report supported lut formats for both reading and writing.

There's some code cleanup related to Formats too. FileFormats only need to implement the Write function if they want to support writing. Otherwise, they can leave the implementation blank.

This checkin maintains both binary and source compatibility.


-- Jeremy


Review: removing boost as a dependency

Malcolm Humphreys <malcolmh...@...>
 

https://github.com/imageworks/OpenColorIO/pull/81

Removed boost dep from the code based, you now need gcc >= 4 to get access to std::tr1::shared_ptr

This has only been tested on OSX, doing a bit of reading we might need a different #include for different gcc versions. "#include (GCC 4.1) or #include (GCC 4.3)"

.malcolm


Re: Review: First pass at TruelightTransform and TruelightOp

Malcolm Humphreys <malcolmh...@...>
 


As I'm guessing Ben has access to the cinespace sdk so it would also be possible to add a <!CineSpaceTransform> as well in the same spirit as this one.

...hm, I do indeed. Might have a look at this when I have a bit of spare time - could be useful in conjuction with the Houdini LUT Baker! Should be straight-forward enough, although last time I done something with cineSpaceAPI, I lost several days to an incredibly obscure linker bug *mutters*

If you can send me the header, I'm happy to flesh something out.

I didn't get around to it before I left DRD but I was hoping to use the lut baker to build a tool to take advantage of the lutio table which you might find interesting.


You could effectively have something like this.
.ocio "ocioToHoudini '%s' stdout.lut" "ocioFromHoudini stdin.lut '%s'"

If you did this you could support per shot dynamic grades, where you could feed houdini the ocio profile and it could spit out a lut baked for the current context. This would save rendering out graded plates or baking out luts for everyshot for lighting.

.malcolm

On 23/02/2011, at 6:03 PM, Malcolm Humphreys wrote:

Hi,

I think you can add additional pull requests if they are on uniquely named 'topic' branches.

How interesting! - a Truelight Transform...

Only quickly glancing at the code (always dangerous), does this add Truelight as an optional or required dependency?  

Optional link dependancy, but all the profile serialisation will work the same all the time. You will only get an exception thrown when creating a processor with a truelight transform but have no support. If host apps are written correctly this shouldn't cause problems.

I agree that this would be better as a plugin, but the runtime implications of plugins vs. optional compile-time functionality are essentially the same. And in this case, as we at SPI do not actively use Truelight, we'll probably want to address the compatibility implications in the short-term.

What's the advantage of using this plugin as opposed to - say - baking it into a baked 3d lut representation at ocio profile generation time?  Would you expect the end user (artist) to dynamically modify the input arguments?   If not, and the transforms inputs are essentially locked for each configuration, what would you think of adding this functionality not to the core library but instead to some of the helper apps?

Depending on how many display devices are in play it's nice to have this dynamic. But most of the time the transform will be used in defining a colorspace to be used with ociobakelut into different lut formats.

You obviously implemented this with a workflow in mind, would you elaborate?

From time to time new display devices come into play and truelight can be used for device -> device mapping eg. a whole heap of diffrent monitors turnup halfway through a production, which need to look the same/similar to the current set.

I prefer that all the tools for modelling these transforms and baking luts are all in one place.

I really want a ocio profile to describe all the color decisions on a show + ways to regenerate luts formats even ones that the ocio profile uses. 

My largest compatibility concern is that in the near future, commercial apps will be shipping with native OCIO support. (Yay!)  But, this native support won't compile with Truelight functionality. So we'll essentially have a schism in support, where some people's internal pipelines support ocio+truelight, while the common commercial apps only support ocio-plain.

I have written it so that you can have profiles with the <!TruelightTransform> even if OCIO hasn't been built with it. In most host apps this wont be a problem as these wouldn't be used directly in production display lookups.

An OCIO transform plugin API would obviously help to alleviate this issue, but both implements open the pandora's box of profile compatibility issues.  Once plugins (or optional build dependencies) are in use .ocio profiles are no longer generically interchangeable between facilities. You would have to share the profiles, all plugins, potentially plugin source, etc...   And then one would have to consider the licensing aspect as well.

Agreed, I think this is a happy middle ground. Profiles are still interoperable while opening up the opportunity for 3rdParty OCIO enabled commercial apps to get truelight support if they wanted it.

As I'm guessing Ben has access to the cinespace sdk so it would also be possible to add a <!CineSpaceTransform> as well in the same spirit as this one.

...

I did say I wanted a plugin interface :)

.malcolm

In the current system if you create a valid profile you know it really can be used in any app, on any OS, and easily shared (emailed!) to other vendors.

-- Jeremy

On Tue, Feb 22, 2011 at 8:14 PM, Malcolm Humphreys <malcolmh...@...> wrote:
Can't seem to send more than one pull request while one is in the queue.

https://github.com/malcolmhumphreys/OpenColorIO/commit/c1abbcb4061cd55461d90dfb29a41cbf0989fc20

I can send another pull request once the Baker stuff makes it in. This transform is one that I would have added as a plugin.

.malcolm






0.7.7 Released

Jeremy Selan <jeremy...@...>
 

Version 0.7.7 (March 1 2011):

    * Lut baking API + standalone app (ociobakelut)
    * Truelight runtime support (optional)
    * Cinespace (3d) lut writing
    * CSP prelut support
    * Boost argparse dependency removed
    * SanityCheck is more exhaustive
    * FileTransform supports relative path dirs
    * Python enhancements (transform kwarg support)
    * Makefile enhancements (OIIO Path)
    * Processor API update (code compatible, binary incompatible)

-- Jeremy

1741 - 1760 of 2233