tag:www.nabble.com,2006:forum-3701Nabble - Aqsis Renderer2008-11-24T21:40:55ZAqsis is a Renderman(tm) compliant 3D rendering toolkit. Aqsis is based on the Reyes rendering architecture. Features include : Programmable Shading True Displacements NURBS CSG Motion Blur Subdivision Surfaces Aqsis Renderer home is <a href="http://sourceforge.net/projects/aqsis/" target="_top" rel="nofollow">here</a>.tag:www.nabble.com,2006:post-20675511Re: Bucket refactor thoughts2008-11-24T21:40:55Z2008-11-24T21:40:55ZChris FosterOn Fri, Nov 21, 2008 at 09:54:11PM +0000, Paul Gregory wrote:
<br>> [...]
<br>>
<br>> Currently, there is a lot of unnecessary information associated with a
<br>> bucket (I'll not get into data ownership yet, the data is shared between
<br>> CqBucket and CqBucketData, for now we'll treat them as one). This
<br>> information can be pared down to the following...
<br>>
<br>> [...]
<br><br>I think we discussed this on IRC - generally I agree wholeheartedly with
<br>what you're saying. Some of our classes have become quite unfocused
<br>over time and end up doing a lot of separate things, and data is often
<br>stored redundently in various places the pipeline. The proposed cleanup
<br>sounds great to me :-)
<br><div class='shrinkable-quote'><br>> Once this is established, we need to think about data ownership. In the
<br>> proposed system, you can see from the diagrams in the wiki page that the
<br>> buckets are not uniform in size, the top left corner is bigger in both x and
<br>> y, and the top row, and left column are bigger in y and x respectivley. As
<br>> such, it's going to be important that the buckets themselves hold the Origin
<br>> and S/D-Region's, while the heavy data should be stored on the bucket data
<br>> class, as they only get instantiated when a bucket is actually being
<br>> processed.
<br>>
<br>> A more radical idea. the only reason for the necessity to instantiate all
<br>> buckets up front is to provide somewhere to put primitive references as they
<br>> are processed. The other downside to this approach is that it forces a
<br>> processing order for the buckets. An alternative approach, as suggested by
<br>> Chris on IRC, may be to use a completely separate space partitioning
<br>> structure to record primitive references. This way, a primitive is put into
<br>> the cell at the appropriate level that completely encapsulates the
<br>> primitive. Then during processing, any bucket that is within that cell is
<br>> able to grab the primitive for further processing.
</div><br>I've been thinking more about this, and I think it's would be the way to
<br>go, _provided_ we can think of a data structure which allows us to
<br>answer the important question
<br><br>"What is the topmost surface for the current bucket?"
<br><br>for arbitrary bucket orders. If we can answer this question efficiently
<br>I think we've also solved the threading problem, apart from some locking
<br>of the data structures.
<br><br>Unfortunately I haven't managed to think of a way to do this yet. As
<br>mentioned by Paul above, we could imagine putting the surfaces into a
<br>spatial partition of some kind, but there seems to be some reasons why a
<br>tree-like structure won't work easily:
<br> * Primitives which are localized in screen space should not effect
<br> buckets which are a long way away from them. However, if tree nodes
<br> were to fully contain a bounding box, then even small primitives
<br> which sit on top of the top-level subdivision of the tree would have
<br> to sit in the root node of the tree, and effect all buckets.
<br> * Primitives should be sorted so that the topmost surface is
<br> accessible in O(1) time. If we maintain multiple lists of
<br> primitives in different tree nodes, then at best we have to compare
<br> the topmost surface from each node which overlaps a bucket to get
<br> the topmost surface in the bucket.
<br><br>A possible way to avoid the first objection is to allow surfaces to be
<br>placed into multiple tree nodes, and to choose a tree level which is
<br>consistent with the size of the object bounding box, so that the
<br>primitive never gets placed in more than 4 nodes at once (say). Keeping
<br>such redundent lists up to date seems like an unnecessary amount of work
<br>though. In all, I'm starting to become less keen on the spatial
<br>subdivision idea, since it seems like we have the "perfect" scheme at
<br>the moment for a single thread, and and I want to avoid loosing that for
<br>the single-threaded case.
<br><br>If we continue to store surfaces in buckets, we may be able to get
<br>arbitrary bucket orders working by computing the bucket order in
<br>advance. We could probably use that precomputed list to work out which
<br>bucket to place a primitive in so that it is encountered in the correct
<br>order.
<br><br>I read some sourcecode from a few other renderers which do
<br>bucket-rendering: Pixie, blender and sunflow. It turns out that only
<br>Pixie is relevant, since the reyes splitting procedure presents unique
<br>challanges (continuous creation of new primitives as rendering
<br>proceeds). Pixie doesn't support arbitrary bucket orderings, but they
<br>do have a scheme for multithreading which I haven't fully understood
<br>yet. AFAICT it revolves around an extension of the straightforward
<br>left-to-right, top-to-bottom scheme which is used in aqsis.
<br><br>> What about MPGs?
<br><br>Well, I think we should get rid of MPGs as distinct objects, and deal
<br>entirely with grids. Andrew suggested something like this ages ago on
<br>IRC and I tend to agree. The main reason is that a lot of decisions
<br>about which code path to take should be made at the grid level, rather
<br>than for individual micropolygons. For instance, motion is on or off
<br>for an entire grid, not for individual micropolys. (I'll also note that
<br>this happens to be the way that Pixie works, not that this is
<br>necessarily a good thing in itself.)
<br><div class='shrinkable-quote'><br>> If a primitive passes the dicable check, and produces
<br>> micropolygons that cover multiple buckets, without the buckets being ready
<br>> to go there is nowhere to put the MPGs ready for sampling. It's possible to
<br>> store the MPG references in the same structure. One possible advantage of
<br>> this is that it may be possible to choose the best next bucket to process by
<br>> looking at which cells in the structure have waiting Primitives or MPGs to
<br>> process. So, instead of arbitrarily chosen bucket orders, the system would
<br>> process the buckets in the most efficient order determined by which buckets
<br>> are in most need of processing. The core could then choose buckets based on
<br>> which have the most waiting, if there are any with MPGs, they get priority
<br>> in order to reduce memory overhead, if not, then the next bucket with the
<br>> most primitives. When there are no buckets with stuff waiting we're done,
<br>> and any buckets that didn't get processed just get passed as empty buckets
<br>> to the display. This approach would also mean that bucket/bucketdata can be
<br>> combined again, as we don't need the buckets around at the start to hold
<br>> primtives, so they can just be built when they get processed.
</div><br>This all sounds very nice, provided we can think of an appropriate
<br>heiarchial scheme for the storage of gprims...
<br><br>~Chris.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20675511&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-20630157Bucket refactor thoughts2008-11-21T13:54:11Z2008-11-21T13:54:11ZPaul GregoryI've been spending some train journeys this week thinking over the current and future bucket code. As mentioned on the bucket overlap cache, the current implementation of buckets is overly complex and confusing, and is marked as one of the areas for refactoring. I've been mulling over some ideas about how they might change.<br>
<br>I've been trying to consider the implementation while I'm doing this, so I'd like to come up with a solution that can be implemented in phases, so it has to fit quite well into the current approach at least to begin with during the refactor. I think some of the ideas I've come up with warrant discussion, so before I put anything on the Wiki, I thought I'd put some information up here on the mailing list for some discussion, in case anyone has any better ideas or could form it into a better shape.<br>
<br>Currently, there is a lot of unnecessary information associated with a bucket (I'll not get into data ownership yet, the data is shared between CqBucket and CqBucketData, for now we'll treat them as one). This information can be pared down to the following...<br>
<br><ul><li>Origin</li><ul><li> The raster space coordinates of the upper left pixel of the bucket, as integer values. All sample positions are stored relative to this origin.</li></ul><li>S-Region</li><ul><li>The area of the bucket that is used for valid sampling. This area is subject to reduction by the crop window, and to enlargement by the filter expansion. The bucket processor will use this information to determine the valid extents when placing primitives and micro-polygons into the bucket.<br>
The S-Region is represented as real values, expanding only enough to provide the necessary sample space. For example, a filter width of 1.0 will only expand the S-Region by 0.5 in each direction to accommodate the samples, not the full 1 pixel. This reduces the load when sampling, avoiding MPGs and primitives that are not appropriate being added to the bucket list forconsideration.<br>
The S-Region is calculated by applying the following steps to the original bucket position and size.</li><ol><li>Crop the region to the display extents.</li><li>Crop the region to the specified crop window.</li><li>Expand to accommodate extra samples required during filtering.</li>
<li>Reduce to skip cached samples.</li></ol><li>The S-Region is stored as a 3D bound, the Z values being the camera depth clipping planes, used to view cull micropolygons. This allows for simple clarity when culling micropolygons.</li>
</ul><li>D-Region</li><ul><li>This is the area that is passed to the display. It can be different to the S-Region as it represents the actual bucket position and size, which can include additional information from the overlap cache, and not include some information that is destined for the cache, or included only for the purpose of filtering.<br>
The D-Region is specified in integer raster values, as it makes no sense passing partial pixels to the display driver.<br>The D-Region is calculated by applying the following steps to the original bucket position and size.</li>
<ol><li>Crop the region to the display extents.</li><li>Crop the region to the specified crop window.</li></ol></ul><li>Samples</li><ul><li>The sample structure array will be configured to accommodate the largest bucket configuration, that is a bucket of the standard size, expanded to accommodate filter requirements. From this array the bucket will use what is necessary for it's requirements using the S-Region to crop the array of samples.<br>
When initialising a bucket, the cache will be use to fill in any areas of the sample array that match. This means that the filtering and code to pass the final data onto the display device doesn't need to care about where the data came from, only that it is valid. <br>
<i>Q: as it's only ever possible for cache values to be used in one further bucket, would it be possible to store them directly on that bucket, rather than in a separate cache structure?</i><br></li></ul></ul>Those 4 items of information should be enough to efficiently process a bucket, moreover, the amount of knowledge regarding filtering, bucketsizes etc. is reduced, the code that processes a bucket only needs know about the two regions and the origin, the fact that the two regions are different, and why is irrelevant. <br>
<br>Once this is established, we need to think about data ownership. In the proposed system, you can see from the diagrams in the wiki page that the buckets are not uniform in size, the top left corner is bigger in both x and y, and the top row, and left column are bigger in y and x respectivley. As such, it's going to be important that the buckets themselves hold the Origin and S/D-Region's, while the heavy data should be stored on the bucket data class, as they only get instantiated when a bucket is actually being processed. <br>
<br>A more radical idea. the only reason for the necessity to instantiate all buckets up front is to provide somewhere to put primitive references as they are processed. The other downside to this approach is that it forces a processing order for the buckets. An alternative approach, as suggested by Chris on IRC, may be to use a completely separate space partitioning structure to record primitive references. This way, a primitive is put into the cell at the appropriate level that completely encapsulates the primitive. Then during processing, any bucket that is within that cell is able to grab the primitive for further processing. <br>
<br>What about MPGs? If a primitive passes the dicable check, and produces micropolygons that cover multiple buckets, without the buckets being ready to go there is nowhere to put the MPGs ready for sampling. It's possible to store the MPG references in the same structure. One possible advantage of this is that it may be possible to choose the best next bucket to process by looking at which cells in the structure have waiting Primitives or MPGs to process. So, instead of arbitrarily chosen bucket orders, the system would process the buckets in the most efficient order determined by which buckets are in most need of processing. The core could then choose buckets based on which have the most waiting, if there are any with MPGs, they get priority in order to reduce memory overhead, if not, then the next bucket with the most primitives. When there are no buckets with stuff waiting we're done, and any buckets that didn't get processed just get passed as empty buckets to the display. This approach would also mean that bucket/bucketdata can be combined again, as we don't need the buckets around at the start to hold primtives, so they can just be built when they get processed.<br>
<br><br>Thoughts and suggestions welcome, please.<br><br><br>Cheers<br clear="all"><br>-- <br>Paul Gregory<br><a href="http://www.aqsis.org" target="_top" rel="nofollow">http://www.aqsis.org</a><br>
<br />-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br />_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20630157&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-20534516weekly update2008-11-16T22:47:32Z2008-11-16T22:47:32ZChris FosterHi all,
<br><br>I couldn't make it to the meeting earlier today since a thunderstorm
<br>fried our router on Sunday - my home machine now lacks a net connection
<br>:-( In the absence of that, here's what I did this week.
<br><br>I mainly spent a lot of time writing a code generator for RIB request
<br>handlers in the new RIB parser. I've finally got 95 of the request
<br>handlers generated, and wrote the remaining 11 which required custom
<br>implementations by hand. None of that's compiled yet, so there's
<br>probably plenty of work left to get that going smoothly. The work
<br>required significant rearrangment of the XML description in api.xml and
<br>I made some minor changes so that the generated ri.inl now looks much
<br>cleaner.
<br><br>I also spent some time writing on the wiki: I wrote a page detailing
<br>data storage changes for the pipeline and rearranged the remaining
<br>proposals on the beaker wiki page.
<br><br>Later,
<br>~Chris.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20534516&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-20374276Profiling with valgrind2008-11-06T19:39:51Z2008-11-06T19:39:51ZChris FosterHi all,
<br><br>I spent some time today trying to better understand the costs which
<br>valgrind presents after a cachegrind run. I've never spent the time to
<br>investigate this before, so I was moderately surprised to find that
<br>kcachegrind doesn't show the computation time on the call graph.
<br><br>Instead it shows (by default) a quantity called "Instruction Fetch"
<br>which is just a count of the number of processor instructions
<br>encountered inside each function call. If you turn on cache profiling
<br>in a callgrind run, you can also view a bunch of other costs, including
<br>L1 and L2 cache misses etc. If the computation is cache-bound,
<br>kcachegrind does provide a way to estimate the real cost
<br>- "Cycle Estimation" - which includes an estimate of the time lost due
<br>to cache misses.
<br><br>Note that to get any information about cache misses, callgrind has to be
<br>run with the --simulate-cache=yes option. For example:
<br><br>valgrind --tool=callgrind --simulate-cache=yes aqsis --progress capsules.rib
<br><br>Running valgrind using these options suggests that aqsis trunk has
<br>significant cache problems, one major culprit being
<br>CqOcclusionTree::updateDepths() (propagateDepths() is fine). This is
<br>unambiguously due to memory-incoherent accesses touching all the sample
<br>points in the bucket...
<br><br>Here's a helpful thread I found which discusses these issues:
<br><br><a href="http://thread.gmane.org/gmane.comp.debugging.valgrind/5997" target="_top" rel="nofollow">http://thread.gmane.org/gmane.comp.debugging.valgrind/5997</a><br><br>Cheers,
<br>~Chris.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20374276&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-20287470Re: Non-uniqeness of hashing2008-11-01T23:36:55Z2008-11-01T23:36:55ZChris FosterHi Andrew,
<br><br>On Sun, Nov 02, 2008 at 01:41:00AM -0400, <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20287470&i=0" target="_top" rel="nofollow">ajb@...</a> wrote:
<div class='shrinkable-quote'><br>> Quoting Chris Foster <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20287470&i=1" target="_top" rel="nofollow">foster@...</a>>:
<br>>
<br>> >Let me share a disturbing revelation with you...
<br>>
<br>> The hash collisions don't disturb me too much, though the hash function
<br>> could be better.
<br>>
<br>> However, this does disturb me:
<br>>
<br>> >Unfortunately our code has lots of instances of assuming that hashes are
<br>> >unique...
<br>>
<br>> That's a bug. Can you give some examples of places where this happens?
</div><br>Sure, search for CqString::hash() in ri.cpp and you'll find plenty, for
<br>instance in ProcessPrimitiveVariables(). There's probably other places
<br>in the code where this happens as well.
<br><div class='shrinkable-quote'><br>> Incidentally, some comments on the state of the art in hashing:
<br>>
<br>> Back in the day, it was thought that it was best to use a cheap hash
<br>> function, and make the size of the hash table to be prime. The prime
<br>> size meant that any weakness in the hash function could be compensated
<br>> for by the fact that there would be no factors in common between the
<br>> hash table size and the hash value most of the time.
<br>>
<br>> Modern thinking is that division is such an expensive operation on
<br>> today's CPUs that it's better to have a slightly more expensive hash
<br>> function if it means that your hash tables can be a power of 2 in
<br>> size. The final "modulo hash table size" then becomes a single-cycle
<br>> logical and instruction rather than a fairly expensive division.
</div><br>Interesting. I definitely agree that modulo should be avoided in
<br>performance-critical code if at all possible... Modulo is only 2x
<br>faster than computing sin() on my machine, which seems to be 100's of
<br>times slower than something like integer addition.
<br><br>> Try this one: <a href="http://www.azillionmonkeys.com/qed/hash.html" target="_top" rel="nofollow">http://www.azillionmonkeys.com/qed/hash.html</a><br><br>I read the page - from what they say it seems like a really nice hash
<br>function, and the writeup is good too. Thanks for pointing it out.
<br><br>~Chris.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20287470&i=2" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-20287151Non-uniqeness of hashing2008-11-01T21:56:46Z2008-11-01T21:56:46ZChris FosterHi all,
<br><br>Let me share a disturbing revelation with you...
<br><br>I was comparing the speed of our hashing algorithm today for finding a
<br>string in a set of strings, and at the same time I decided to test out
<br>how unique the hashes are. Of course, I know that there *will* be
<br>collisions given a sufficiently large number of strings, but it was
<br>scary to see the reality of it with strings of length 2.
<br><br>Consider the following test code, which finds hash collisions between
<br>two-character words and and the token "Pw"
<br><br>//------------------------------------------------------------------------------
<br>#include <iostream>
<br><br>typedef unsigned long hash_type;
<br><br>inline static hash_type hash(const char *strName)
<br>{
<br> hash_type retval = 0;
<br> const char *p = strName;
<br> retval = *p;
<br><br> if(retval)
<br> {
<br> for (p += 1; *p != '\0'; p++)
<br> {
<br> retval = (retval << 5) - retval + *p;
<br> }
<br> }
<br> return retval;
<br>}
<br><br>int main()
<br>{
<br> // Find hash collisions of two-letter printable words with "Pw"
<br> hash_type h = hash("Pw");
<br> for(unsigned char c1 = 32; c1 < 127; ++c1)
<br> {
<br> for(unsigned char c2 = 32; c2 < 127; ++c2)
<br> {
<br> char str[] = {c1, c2, 0};
<br> if(hash(str) == h)
<br> {
<br> std::cout << "\"" << str << "\"\n";
<br> }
<br> }
<br> }
<br>}
<br>//------------------------------------------------------------------------------
<br><br>Results are
<br>"Pw"
<br>"QX"
<br>"R9"
<br><br>Unfortunately our code has lots of instances of assuming that hashes are
<br>unique... This doesn't seem very robust to me given that the user can
<br>provide any name as an input token. The functional
<br>boost::hash<std::string>() is more unique, but still collides with "Q6".
<br>boost::hash<T> seems very versatile and almost as fast as our
<br>CqString::hash() for strings.
<br><br><br>As an aside, comparing a given string with multiple strings is very fast
<br>when using prehashed values, since it's all inlined. strcmp() is
<br>competitive, but std::string::operator==() seems to be relatively slow
<br>with g++ since it's not inlined for some reason.
<br><br>~Chris.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20287151&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-20162693Re: [Aqsis-commits] SF.net SVN: aqsis:[2549] trunk/aqsis/misc/hairgen/CMakeLists.txt2008-10-25T02:47:18Z2008-10-25T02:47:18ZChris FosterOn Sat, Oct 25, 2008 at 09:39:40AM +0000, <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20162693&i=0" target="_top" rel="nofollow">pgregory@...</a> wrote:
<br>> Revision: 2549
<br>> <a href="http://aqsis.svn.sourceforge.net/aqsis/?rev=2549&view=rev" target="_top" rel="nofollow">http://aqsis.svn.sourceforge.net/aqsis/?rev=2549&view=rev</a><br>> Author: pgregory
<br>> Date: 2008-10-25 09:39:39 +0000 (Sat, 25 Oct 2008)
<br>>
<br>> Log Message:
<br>> -----------
<br>> Update the build for hairgen on Windows to include some important defines for the aqsis libraries to work.
<br><br>Hey Paul, Wouldn't both these defines be better in aqsis_compiler.h as
<br>mentioned the other day?
<br><br>~Chris.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20162693&i=1" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19986311Re: [Aqsis-commits] SF.net SVN: aqsis:[2521] trunk/aqsis/misc/hairgen2008-10-14T20:48:35Z2008-10-14T20:48:35ZChris FosterOn Wed, Oct 15, 2008 at 03:34:57AM +0000, <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19986311&i=0" target="_top" rel="nofollow">c42f@...</a> wrote:
<br>> Revision: 2521
<br>> <a href="http://aqsis.svn.sourceforge.net/aqsis/?rev=2521&view=rev" target="_top" rel="nofollow">http://aqsis.svn.sourceforge.net/aqsis/?rev=2521&view=rev</a><br>> Author: c42f
<br>> Date: 2008-10-15 03:34:56 +0000 (Wed, 15 Oct 2008)
<br>>
<br>> Log Message:
<br>> -----------
<br>> * Add a some documentation for the hairgen procedural
<br>> * Change the default install prefix for aqsis to be /usr/local in the cmake script.
<br><br>s/aqsis/hairgen/
<br><br>... oops.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19986311&i=1" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19982444Re: aqsis source tree rearrangement2008-10-14T14:19:11Z2008-10-14T14:19:11ZChris FosterOn Tue, Oct 14, 2008 at 09:19:55PM +0100, Matthias Baas wrote:
<div class='shrinkable-quote'><br>> Chris Foster wrote:
<br>> > aqsis/
<br>> > |-- config.h
<br>> > |-- ...
<br>> > |-- ri/ # <-- tranditional C headers for RI and friends
<br>> > | |-- ri.h
<br>> > | |-- ndspy.h
<br>> > | |-- slo.h
<br>> > | |-- ...
<br>> > |-- ...
<br>> > |-- types/ # <-- stuff that is currently in the aqsistypes library
<br>> > | |-- ...
<br>> > | |-- integer.h
<br>>
<br>> Personally, I'd vote for a structure where the files deeper down the
<br>> hierarchy are the more specialized files and files further up are the
<br>> generic ones that the user is supposed to include in his applications.
<br>> Then I could still decide myself if I wanted to add $INCLUDE/aqsis to
<br>> the include paths and just do a #include <ri.h> or if I'd rather want to
<br>> include via <aqsis/ri.h>. From a user's point of view, it also appears
<br>> to be cleaner to me as I could just have a look into the root directory
<br>> to get an overview of what is there and what the headers are that I may
<br>> want to include.
</div><br>I totally agree - having ri.h at aqsis/ri.h really makes sense to me.
<br>Unfortunately this is just plain in compatible with having generic names
<br>in the aqsis directory, so aqsis/types/ is out.
<br><br>aqsis/aqsistypes
<br>aqsis/aqsistex
<br>aqsis/aqsiscore
<br><br>it just looks plain ugly to me. Hence my thought of using aqsis-c or
<br>aqsis/ri/ or something. Argh, the tradeoffs are killing me ;-)
<br><div class='shrinkable-quote'><br>> But of course, with proper documentation I may not even have to look at
<br>> that directory at all (which would even be better) and I would then just
<br>> include whatever you tell me to include. :)
<br>>
<br>> > The extra complexity comes from exposing some of the aqsis internals for
<br>> > outside use. Imagine if you had a fully-fleged shader virtual machine
<br>> > to link to. Surely this would be useful and cool?
<br>>
<br>> Speaking of which, I had a look at the release notes of 3Delight 8.0 and
<br>> there seems to be just that now:
<br>>
<br>> "Introducing a new shader evaluation API and library: Sx. This API
<br>> exposes methods to load and execute RenderMan shaders, in SIMD."
</div><br>Sigh... those guys are a hard act to follow.
<br><br>In general I hear what you're saying, which mostly boils down to "keep
<br>things simple if possible".
<br><br>Unfortunately there's always the tradeoff between power and simplicity
<br>and I think we were looking at this from different sides of that
<br>tradeoff. You now have me quite worried about where the balance lies,
<br>but I think that's probably a good thing ;-)
<br><br>I guess this also underlines the difference between the apparent
<br>complexity of C and C++ headers. IMO, well-written C++ is very rich in
<br>user-defined types; this makes such an interface more complicated to
<br>understand but also more powerful. C interfaces OTOH tend to use arrays
<br>of the builting types, and some relatively simple structs. They have
<br>less ability to protect the user from stupid mistakes, but are much
<br>simpler at face value.
<br><br>So I will keep simplicity in mind. Thanks!
<br>~Chris.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19982444&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19981421Re: aqsis source tree rearrangement2008-10-14T13:19:55Z2008-10-14T13:19:55ZMatthias Baas-3Chris Foster wrote:
<div class='shrinkable-quote'><br>> aqsis/
<br>> |-- config.h
<br>> |-- ...
<br>> |-- ri/ # <-- tranditional C headers for RI and friends
<br>> | |-- ri.h
<br>> | |-- ndspy.h
<br>> | |-- slo.h
<br>> | |-- ...
<br>> |-- ...
<br>> |-- types/ # <-- stuff that is currently in the aqsistypes library
<br>> | |-- ...
<br>> | |-- integer.h
</div><br>Personally, I'd vote for a structure where the files deeper down the
<br>hierarchy are the more specialized files and files further up are the
<br>generic ones that the user is supposed to include in his applications.
<br>Then I could still decide myself if I wanted to add $INCLUDE/aqsis to
<br>the include paths and just do a #include <ri.h> or if I'd rather want to
<br>include via <aqsis/ri.h>. From a user's point of view, it also appears
<br>to be cleaner to me as I could just have a look into the root directory
<br>to get an overview of what is there and what the headers are that I may
<br>want to include.
<br>But of course, with proper documentation I may not even have to look at
<br>that directory at all (which would even be better) and I would then just
<br>include whatever you tell me to include. :)
<br><br>> The extra complexity comes from exposing some of the aqsis internals for
<br>> outside use. Imagine if you had a fully-fleged shader virtual machine
<br>> to link to. Surely this would be useful and cool?
<br><br>Speaking of which, I had a look at the release notes of 3Delight 8.0 and
<br> there seems to be just that now:
<br><br>"Introducing a new shader evaluation API and library: Sx. This API
<br>exposes methods to load and execute RenderMan shaders, in SIMD."
<br><br>But I haven't downloaded the new version yet.
<br><br>- Matthias -
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19981421&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19967560Re: aqsis source tree rearrangement2008-10-13T23:07:09Z2008-10-13T23:07:09ZChris FosterOn Mon, Oct 13, 2008 at 10:50:43PM +0100, Matthias Baas wrote:
<br>> > Ah, true (at least on g++/linux). I hadn't taken note about the way
<br>> > that including with "" quotes searches first from the directory of the
<br>> > parent include file. Note however that this is platform dependent - the
<br>> > C++ standard unfortunately doesn't specify the detailed behaviour of
<br>>
<br>> Ugh, that's bad, I wasn't aware of that.
<br><br>Yeah, it's ugly. I'm not claiming that anything I'm proposing really
<br>helps solve this problem.
<br><div class='shrinkable-quote'><br>> > If we consistently use the aqsis directory as a namespace this isn't
<br>> > really a problem. Note that many of the boost headers have generic
<br>> > names (some examples - any.hpp, array.hpp, assert.hpp, ...) and they
<br>> > don't seem to have problems with this.
<br>>
<br>> Well, I was mainly referring to the confusion it could cause on the
<br>> *people*, not the compiler. :) In emails you may refer to "math.h" and
<br>> newcomers may think you're talking about the system header.
<br>> Boost uses the suffix .hpp which already gives an indication that
<br>> assert.hpp is not the same as the system assert.h.
</div><br>If our headers are always included with the aqsis/ prefix, I think the
<br>confusion will be minimized. I really think this is a relatively minor
<br>consideration.
<br><br>> > (This is only a valid point if the content of ri.h etc actually
<br>> > resides in aqsis-c.) It also explicilty indicates to users which
<br>> > headers they may use in their C programs, and which are C++ only.
<br>> > Everyone knows that valid C is also valid C++,
<br>>
<br>> I tended to think the same, but then you sent me a patch for the RPly
<br>> lib in cgkit so that it can also be compiled with a C++ compiler. Before
<br>> that, it could only be compiled with a C compiler. :)
<br><br>Hehe, yeah I thought of that as I wrote the above. Note though that the
<br>problem in the case of rply.c resulted from gcc compiling something that
<br>is not standard C ;-)
<br><div class='shrinkable-quote'><br>> > Ok, so how about the following scheme instead. We could put the C
<br>> > includes in a subdirectory of $prefix/aqsis, for instance (as suggested
<br>> > by Tristan):
<br>> >
<br>> > $prefix/include/aqsis/ri/
<br>> > ri.h
<br>> > slx.h
<br>> > ndspy.h
<br>> > ...
<br>> >
<br>> > Unfortunately some of these C headers already depend on other headers
<br>> > (aqsis_config.h, aqsis_compiler.h, ri.inl); I'm not sure how to deal
<br>> > with these yet. Including by relative path is possible but not entirely
<br>> > portable.
<br>>
<br>> A relative path doesn't look right to me. Aren't the above names already
<br>> unique enough that it is quite unlikely that they will ever produce a clash?
</div><br>The point is that aqsis_config.h is needed by lots of the C++ aqsis
<br>libs, and it would be somewhat inappropriate (IMO) to place it in the
<br>same directory as C headers such as ndspy.h, especially since I'd like
<br>to rename it as (uh-oh) aqsis/config.h.
<br><br>In the case it's not in the same directory as the C headers, we either
<br>need to include it by relative path, or by a path rooted at the base of
<br>the aqsis include tree. Suppose that we have the following include
<br>layout inside $prefix/include:
<br><br>aqsis/
<br>|-- config.h
<br>|-- ...
<br>|-- ri/ # <-- tranditional C headers for RI and friends
<br>| |-- ri.h
<br>| |-- ndspy.h
<br>| |-- slo.h
<br>| |-- ...
<br>|-- ...
<br>|-- types/ # <-- stuff that is currently in the aqsistypes library
<br>| |-- ...
<br>| |-- integer.h
<br><br>Now, ndspy.h has two choices:
<br><br>#include <aqsis/config.h> // presumes that $prefix/include is in the compiler include path
<br>#include "../config.h" // Ugh.
<br><br>Now, you're probably going to counter that config.h should be called
<br>aqsis_config.h, and should go in the same directory as ri.h. I don't
<br>like this since I want to think of aqsis as a set of C++ libraries which
<br>happen to have some C interfaces - in that case the C++ directory
<br>structure is the right place for config.h to go.
<br><div class='shrinkable-quote'><br>> > I think this consideration is overruled by needing a standard way for
<br>> > external programs to include aqsis headers. Imagine that we distributed
<br>> > our headers in nested directories by default, and someone writes a
<br>> > program which expects to
<br>> >
<br>> > #include <aqsis/types/vector.h>
<br>> > #include <aqsis/ribparse/ribparser.h>
<br>> > // ... etc
<br>> >
<br>> > If a studio then goes and installs the aqsis headers all in one big
<br>> > directory then any program which includes aqsis as above will fail to
<br>> > compile without modifications.
<br>>
<br>> Correct. In this particular example, the studio would either *not*
<br>> install all headers in one big directory or change the headers of the
<br>> application.
<br>> However, in the scenario I was thinking of, the studio would decide to
<br>> install the Aqsis libs to be able to use them for *their own* plugins
<br>> and utilities and then they might have their own guidelines how headers
<br>> should be included (and this may or may not be the same as the official
<br>> guidelines).
</div><br>Is there any evidence that studios would want to rearrange headers from
<br>external libraries in such a way? This sounds quite odd from my
<br>perspective, but I've got no experience installing software at a
<br>company.
<br><br>Actually, there's a way to support odd situations like this without
<br>compromising our install tree: use forwarding headers. Imagine ri.h was
<br>installed into $prefix/install/aqsis/ri/ri.h but the studio wanted ri.h
<br>to go into $prefix/install. The easy way around this is to simply
<br>install a "forwarding" ri.h into $prefix/install containing a single
<br>line:
<br><br>#include <aqsis/ri/ri.h>
<br><br>That way people can have things both ways.
<br><div class='shrinkable-quote'><br>> Whereas if they only wanted to compile a *third-party*
<br>> application that uses the Aqsis libs, then all the effort of using
<br>> in-house build environments would probably not be worthwhile and they
<br>> would build that tool like everyone else does and just make the binaries
<br>> available.
<br>>
<br>> My point just is, enforce as much as necessary to get a consistent
<br>> layout, but still leave as much as possible open. (And don't make it
<br>> more complex than necessary. After all, Aqsis is not a gigantic
<br>> framework with dozens of components. I think there are only a few
<br>> components that will be of interest to other users)
</div><br>I disagree here, and this is the main sticking point I think. As
<br>described in previous mails, I'd love aqsis to become a generally useful
<br>set of C++ graphics libraries, but to do so we need a coherent policy on
<br>what to do with our header files. For aqsis-1.6, I'd really like to see
<br>the aqsistex headers installed, along with the new RIB parser as well as
<br>the traditional C headers.
<br><br>Now consider this: There's 52 header files in aqsistex alone, which
<br>makes for a very crowded include directory. What's more, to use the
<br>aqsistex library effectively in C++ you probably need to install most of
<br>these. A subset would only suffice for the limited set of filtering
<br>operations which are already supported for use in the shading language.
<br><div class='shrinkable-quote'><br>> > In any case, other libraries (again, boost) manage perfectly well with a
<br>> > builtin nested directory structure. What I'm proposing is exactly like
<br>> > what they've been doing for years.
<br>>
<br>> I'm actually only using a rather small subset of all the Boost libs, so
<br>> I don't have an overview of all of them. But at least in the case of
<br>> Boost.Python there actually is a sub-directory "python", but when I use
<br>> Boost.Python in my programs, I always include like this:
<br>>
<br>> #include <boost/python.hpp>
<br>>
<br>> I don't have to mention the "python" sub-directory explicitly, this is
<br>> all done within python.hpp.
<br>> Is there any Boost lib where you actually have to include files from the
<br>> sub-directory, i.e.:
<br>>
<br>> #include <boost/libname/lib.hpp>
</div><br>Plenty, for example anything in boost/iostreams/. Even without this,
<br>there's a good reason for being specific in the headers which you
<br>include: It decreases the compile times if you pull in less headers,
<br>especially when lots of template implementations are involved.
<br><br>> I would prefer if I could use the major Aqsis components just by
<br>> including stuff from <aqsis/component.h>. component.h could then still
<br>> include stuff from sub-directories.
<br><br>There's definitely something to be said for making it easy for the user
<br>in this way. I'll probably think about doing this for some parts of
<br>aqsistex.
<br><br>> I'd just like to avoid that things get too complex just for a few header
<br>> files. Speaking of which, how many of the header files really need to
<br>> get distributed? On Windows, Aqsis ships with 39 header files (205kb),
<br>> whereas Pixie just has 7 (32kb) and 3Delight 19 (178kb, in 2
<br>> directories). Not that it really matters, but I'm just wondering where
<br>> this additional complexity comes from?
<br><br>The extra complexity comes from exposing some of the aqsis internals for
<br>outside use. Imagine if you had a fully-fleged shader virtual machine
<br>to link to. Surely this would be useful and cool? Up until now, the
<br>extra stuff we distribute hasn't been very useful - I'm trying to change
<br>this.
<br><br>Typically other renderers expose only very specific details through a
<br>narrow set of well-defined interfaces. This is perfectly ok if the
<br>focus is on using the libs with the renderer itself, but the user cannot
<br>go further than this and use the libs in their own projects.
<br><br>~Chris.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19967560&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19963910Re: aqsis source tree rearrangement2008-10-13T14:50:43Z2008-10-13T14:50:43ZMatthias Baas-3Chris Foster wrote:
<br>>> Why is that? As long as the headers are in the same directory, they
<br>>> could include each other just by name:
<br>>>
<br>>> #include "math.h"
<br>>
<br>> Ah, true (at least on g++/linux). I hadn't taken note about the way
<br>> that including with "" quotes searches first from the directory of the
<br>> parent include file. Note however that this is platform dependent - the
<br>> C++ standard unfortunately doesn't specify the detailed behaviour of
<br><br>Ugh, that's bad, I wasn't aware of that.
<br><br>>> (but to prevent confusion, I wouldn't recommend naming header files
<br>>> after well-known system headers such as math.h, even when a "namespace"
<br>>> scheme such as the above is set up)
<br>>
<br>> If we consistently use the aqsis directory as a namespace this isn't
<br>> really a problem. Note that many of the boost headers have generic
<br>> names (some examples - any.hpp, array.hpp, assert.hpp, ...) and they
<br>> don't seem to have problems with this.
<br><br>Well, I was mainly referring to the confusion it could cause on the
<br>*people*, not the compiler. :) In emails you may refer to "math.h" and
<br>newcomers may think you're talking about the system header.
<br>Boost uses the suffix .hpp which already gives an indication that
<br>assert.hpp is not the same as the system assert.h.
<br><div class='shrinkable-quote'><br>>> If not, then
<br>>> ri.h is a perfectly valid C++ header file and the directory name is
<br>>> misleading, isn't it? (I still would have to use that directory even
<br>>> when I'm writing a pure C++ application) It's just that the library file
<br>>> uses C linkage, but that doesn't make the header a C-only header (or the
<br>>> library a C library). So in what way does the separation increase clarity?
<br>>
<br>> For one thing, it might help remind developers that anything going into
<br>> aqsis-c deserves special attention so that it's C-compatible rather than
<br>> C++ only.
</div><br>Fair enough.
<br><br>> (This is only a valid point if the content of ri.h etc actually
<br>> resides in aqsis-c.) It also explicilty indicates to users which
<br>> headers they may use in their C programs, and which are C++ only.
<br>> Everyone knows that valid C is also valid C++,
<br><br>I tended to think the same, but then you sent me a patch for the RPly
<br>lib in cgkit so that it can also be compiled with a C++ compiler. Before
<br>that, it could only be compiled with a C compiler. :)
<br>But I agree that for practical reasons, the above assumption is ok,
<br>especially as you are in control of the header files.
<br><div class='shrinkable-quote'><br>>> I can see the point you made earlier in your mail though, that having
<br>>> all headers in one directory may lead to name clashes at some point.
<br>>> But I think having sub-directories inside the main Aqsis include
<br>>> directory already fixes this, so that it is not necessary to have two
<br>>> separate "main" include directories.
<br>>
<br>> Ok, so how about the following scheme instead. We could put the C
<br>> includes in a subdirectory of $prefix/aqsis, for instance (as suggested
<br>> by Tristan):
<br>>
<br>> $prefix/include/aqsis/ri/
<br>> ri.h
<br>> slx.h
<br>> ndspy.h
<br>> ...
<br>>
<br>> Unfortunately some of these C headers already depend on other headers
<br>> (aqsis_config.h, aqsis_compiler.h, ri.inl); I'm not sure how to deal
<br>> with these yet. Including by relative path is possible but not entirely
<br>> portable.
</div><br>A relative path doesn't look right to me. Aren't the above names already
<br>unique enough that it is quite unlikely that they will ever produce a clash?
<br><div class='shrinkable-quote'><br>>> Some other things that haven't been mentioned in your mail:
<br>>>
<br>>> - As already indicated above I think it would be beneficial if the
<br>>> headers were written in a way that allows the user to package them up in
<br>>> a different way. Studios may have their own software installation scheme
<br>>> or OS distributions may have their own rules where to put header and
<br>>> library files and it would be good if they could do what they want
<br>>> without having to patch the header files.
<br>>
<br>> I think this consideration is overruled by needing a standard way for
<br>> external programs to include aqsis headers. Imagine that we distributed
<br>> our headers in nested directories by default, and someone writes a
<br>> program which expects to
<br>>
<br>> #include <aqsis/types/vector.h>
<br>> #include <aqsis/ribparse/ribparser.h>
<br>> // ... etc
<br>>
<br>> If a studio then goes and installs the aqsis headers all in one big
<br>> directory then any program which includes aqsis as above will fail to
<br>> compile without modifications.
</div><br>Correct. In this particular example, the studio would either *not*
<br>install all headers in one big directory or change the headers of the
<br>application.
<br>However, in the scenario I was thinking of, the studio would decide to
<br>install the Aqsis libs to be able to use them for *their own* plugins
<br>and utilities and then they might have their own guidelines how headers
<br>should be included (and this may or may not be the same as the official
<br>guidelines). Whereas if they only wanted to compile a *third-party*
<br>application that uses the Aqsis libs, then all the effort of using
<br>in-house build environments would probably not be worthwhile and they
<br>would build that tool like everyone else does and just make the binaries
<br>available.
<br><br>My point just is, enforce as much as necessary to get a consistent
<br>layout, but still leave as much as possible open. (And don't make it
<br>more complex than necessary. After all, Aqsis is not a gigantic
<br>framework with dozens of components. I think there are only a few
<br>components that will be of interest to other users)
<br><br>> In any case, other libraries (again, boost) manage perfectly well with a
<br>> builtin nested directory structure. What I'm proposing is exactly like
<br>> what they've been doing for years.
<br><br>I'm actually only using a rather small subset of all the Boost libs, so
<br>I don't have an overview of all of them. But at least in the case of
<br>Boost.Python there actually is a sub-directory "python", but when I use
<br>Boost.Python in my programs, I always include like this:
<br><br> #include <boost/python.hpp>
<br><br>I don't have to mention the "python" sub-directory explicitly, this is
<br>all done within python.hpp.
<br>Is there any Boost lib where you actually have to include files from the
<br>sub-directory, i.e.:
<br><br> #include <boost/libname/lib.hpp>
<br><br>I would prefer if I could use the major Aqsis components just by
<br>including stuff from <aqsis/component.h>. component.h could then still
<br>include stuff from sub-directories.
<br><br>I'd just like to avoid that things get too complex just for a few header
<br>files. Speaking of which, how many of the header files really need to
<br>get distributed? On Windows, Aqsis ships with 39 header files (205kb),
<br>whereas Pixie just has 7 (32kb) and 3Delight 19 (178kb, in 2
<br>directories). Not that it really matters, but I'm just wondering where
<br>this additional complexity comes from? It seems that quite a few of them
<br>are only necessary when building Aqsis itself.
<br><br>Cheers,
<br><br>- Matthias -
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19963910&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19949864Re: aqsis source tree rearrangement2008-10-13T00:17:09Z2008-10-13T00:17:09ZChris FosterHi Matthias,
<br><br>On Wed, Sep 24, 2008 at 05:56:36PM +0200, Matthias Baas wrote:
<div class='shrinkable-quote'><br>> > However, it requires significant changes to our source tree layout,
<br>> > since the above method of #inclusion must be reflected in the aqsis
<br>> > headers as well or they won't work for users of our libs. OTOH, they
<br>> > also need to work when we're building aqsis itself.
<br>> >
<br>> > That is, inside files such as vector3d.h, we would need to
<br>> >
<br>> > #include <aqsis/types/math.h>
<br>> >
<br>> > instead of
<br>> >
<br>> > #include "aqsismath.h"
<br>> >
<br>> > for example.
<br>>
<br>> Why is that? As long as the headers are in the same directory, they
<br>> could include each other just by name:
<br>>
<br>> #include "math.h"
</div><br>Ah, true (at least on g++/linux). I hadn't taken note about the way
<br>that including with "" quotes searches first from the directory of the
<br>parent include file. Note however that this is platform dependent - the
<br>C++ standard unfortunately doesn't specify the detailed behaviour of
<br>either form,
<br><br>#include <blah.h>
<br><br>or
<br><br>#include "blah.h"
<br><br>IIRC, about the only thing the standard guarantees is that "" searches
<br>using some extra method, followed by searching using the method of <> if
<br>no headers are found in the first step. On the systems I've used the
<br>extra method happens to be looking in the path of the parent header
<br>file.
<br><br>> (but to prevent confusion, I wouldn't recommend naming header files
<br>> after well-known system headers such as math.h, even when a "namespace"
<br>> scheme such as the above is set up)
<br><br>If we consistently use the aqsis directory as a namespace this isn't
<br>really a problem. Note that many of the boost headers have generic
<br>names (some examples - any.hpp, array.hpp, assert.hpp, ...) and they
<br>don't seem to have problems with this.
<br><br>> Using only the local names has the advantage that the directory
<br>> structure of the header files wouldn't be dictated by the header files
<br>> themselves. Instead, any user/packager could decide to use a different
<br>> scheme.
<br><br>If we expect people to use the aqsis headers in external projects we
<br>really need a standard way to package those headers - either all in one
<br>directory or in a well-organized directory heiarchy. Without
<br>consistency of the installed headers, people will have a lot of
<br>difficulty compiling any third party programs... So I don't think we
<br>want to support packagers who have weird and wonderful ways to rearrange
<br>the header directory structure. See also some additional comments at
<br>the end of this mail.
<br><br>> > [...]
<br>> > It seems prudent to separate the C and C++ headers for two reasons: 1)
<br>> > clarity, and 2) Traditionally programs expect to #include <ri.h> rather
<br>> > than #include <aqsis/ri.h>, so will need to add aqsis-c to their include
<br>> > path. We probably don't want generic names like the types directory
<br>> > (aqsis/types) in the global include path.
<br>>
<br>> I'm not so sure if I like this separation. Doesn't that mean I might
<br>> have to add both paths to the include search paths?
<br><br>It depends. On posix what I've written makes sense, since the files
<br>will typically be installed into /usr/include which is in the system
<br>include path by default. On windows it may make less sense however.
<br><br>> Will the C++ header directory also contain C++ versions of ri.h et al?
<br>> This would be consistent but probably somewhat impractical.
<br><br>Ugh, having duplicate versions of the same header sounds wrong to me.
<br>An alternative is to include a trivial "forwarding" header for the C
<br>directory to the C++ versions. Say we put ri.h into
<br>$prefix/include/aqsis/ri.h, then we could have
<br>$prefix/includ/aqsis-c/ri.h which simply includes the "real" ri.h:
<br><br>#include "../aqsis/ri.h"
<br><br>still... I'm not sure about that.
<br><br>> If not, then
<br>> ri.h is a perfectly valid C++ header file and the directory name is
<br>> misleading, isn't it? (I still would have to use that directory even
<br>> when I'm writing a pure C++ application) It's just that the library file
<br>> uses C linkage, but that doesn't make the header a C-only header (or the
<br>> library a C library). So in what way does the separation increase clarity?
<br><br>For one thing, it might help remind developers that anything going into
<br>aqsis-c deserves special attention so that it's C-compatible rather than
<br>C++ only. (This is only a valid point if the content of ri.h etc actually
<br>resides in aqsis-c.) It also explicilty indicates to users which
<br>headers they may use in their C programs, and which are C++ only.
<br>Everyone knows that valid C is also valid C++, so I don't think it's
<br>inconsistent to be including something from aqsis-c in a C++ project.
<br><br>> The second point only says that you have to add a search path to your
<br>> list of include search paths, but that's always the case, no matter if
<br>> the headers are separate or not.
<br><br>Not exactly, I think I was unclear on the point I was trying to make
<br>here. I was trying to say that having generic names in include/aqsis
<br>would be very convenient, but we cannot afford to do that if people
<br>should also add $prefix/include/aqsis to their include path to get at
<br>stuff like ri.h (because of name clashes).
<br><br>> I can see the point you made earlier in your mail though, that having
<br>> all headers in one directory may lead to name clashes at some point.
<br>> But I think having sub-directories inside the main Aqsis include
<br>> directory already fixes this, so that it is not necessary to have two
<br>> separate "main" include directories.
<br><br>Ok, so how about the following scheme instead. We could put the C
<br>includes in a subdirectory of $prefix/aqsis, for instance (as suggested
<br>by Tristan):
<br><br>$prefix/include/aqsis/ri/
<br> ri.h
<br> slx.h
<br> ndspy.h
<br> ...
<br><br>Unfortunately some of these C headers already depend on other headers
<br>(aqsis_config.h, aqsis_compiler.h, ri.inl); I'm not sure how to deal
<br>with these yet. Including by relative path is possible but not entirely
<br>portable.
<br><br>> Some other things that haven't been mentioned in your mail:
<br>>
<br>> - As already indicated above I think it would be beneficial if the
<br>> headers were written in a way that allows the user to package them up in
<br>> a different way. Studios may have their own software installation scheme
<br>> or OS distributions may have their own rules where to put header and
<br>> library files and it would be good if they could do what they want
<br>> without having to patch the header files.
<br><br>I think this consideration is overruled by needing a standard way for
<br>external programs to include aqsis headers. Imagine that we distributed
<br>our headers in nested directories by default, and someone writes a
<br>program which expects to
<br><br>#include <aqsis/types/vector.h>
<br>#include <aqsis/ribparse/ribparser.h>
<br>// ... etc
<br><br>If a studio then goes and installs the aqsis headers all in one big
<br>directory then any program which includes aqsis as above will fail to
<br>compile without modifications.
<br><br>In any case, other libraries (again, boost) manage perfectly well with a
<br>builtin nested directory structure. What I'm proposing is exactly like
<br>what they've been doing for years.
<br><br>> - What's the recommended way to have several versions of the Aqsis libs
<br>> installed?
<br><br>Good question; AFAIK there's no recommended way at present. However, we
<br>do have an INCLUDEDIR build variable which may be modified by the user
<br>at will; this should be enough to easily support multiple versions of
<br>the headers in different directories. In addition, our libraries use
<br>proper SO-versioning (at least on linux).
<br><br>> - Will OSX use exactly the same scheme as POSIX/Windows? Will the
<br>> libraries be available as Frameworks? Your proposed way to include files
<br>> via a directory name (or path) seems to fit nicely into Apple's
<br>> Framework scheme. But I think at least the installation procedure would
<br>> be quite a bit different. (I still need to read a bit more about how
<br>> exactly those Frameworks are set up)
<br><br>I'm afraid I can't really answer this question since I know very little
<br>about OSX frameworks. However, I'd like to stress that the method for
<br>including aqsis headers in any third party program should be consistent
<br>with our default install across platforms. If not, people will have
<br>unnecessary difficulty writing portable code which uses the aqsis
<br>headers.
<br><br>Thanks for your thoughts! I've started a wiki page on this topic, and
<br>will continue to fill it in as the issues become clearer. See
<br><a href="http://wiki.aqsis.org/dev/source_tree" target="_top" rel="nofollow">http://wiki.aqsis.org/dev/source_tree</a><br><br>~Chris.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19949864&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19911500Re: Contributor License Agreements2008-10-09T20:46:47Z2008-10-09T20:46:47ZChris FosterOn Thu, Oct 09, 2008 at 11:39:21PM +0100, Matthias Baas wrote:
<div class='shrinkable-quote'><br>> Chris Foster wrote:
<br>> >> As for the licensing issue, we could add an exemption to allow
<br>> >> linking to the public interfaces from non-GPL/OSS code, but I'm not
<br>> >> sure that is really needed. I don't think something linking to Aqsis
<br>> >> via the RI interface could be considered a derivative work of Aqsis,
<br>> >> any more than an application passing the Aqsis binary a lump of RIB
<br>> >> could.
<br>> >
<br>> > Again I agree. The RI interface isn't even our work!
<br>>
<br>> The RI interface specification is not your work, but this particular
<br>> implementation is.
</div><br>True, but I cannot see the difference between producing RIB as an
<br>intermediate step versus calling the RI directly. It seems pretty clear
<br>that commercial programs can produce RIB which is then rendered by
<br>aqsis; why not allow them the extra convenience?
<br><br>> It was always my understanding that it would be illegal to link GPL
<br>> libs against other code that uses a license which is incompatible with
<br>> the GPL (but of course, I'm not an expert on this subject).
<br><br>AFAICT this is pretty debatable. What is clear however is that the FSF
<br>intended that linking be disallowed, and they state so in the _appendix_
<br>to the GPL:
<br><br>"""
<br> This General Public License does not permit incorporating your program into
<br> proprietary programs. If your program is a subroutine library, you may
<br> consider it more useful to permit linking proprietary applications with the
<br> library. If this is what you want to do, use the GNU Library General
<br> Public License instead of this License.
<br>"""
<br><br>Note however that this is not part of the license terms, and it is the
<br>terms which are legally binding.
<br><br>(The FSF website is even more explicit; see
<br><a href="http://www.fsf.org/licensing/licenses/gpl-faq.html#LinkingWithGPL" target="_top" rel="nofollow">http://www.fsf.org/licensing/licenses/gpl-faq.html#LinkingWithGPL</a> )
<br><br><br>Some people think differently about this however, and (surprise
<br>surprise) Linus is one of them. Here's a nice post from Linus on the
<br>LKML describing his point of view:
<br><br><a href="http://lkml.org/lkml/2006/12/17/79" target="_top" rel="nofollow">http://lkml.org/lkml/2006/12/17/79</a><br><br>The discussion centres about the difference between "derived work" and
<br>"aggregate work", and argues that the act of linking doesn't imply one
<br>or the other, but depends on the situation.
<br><br><br>Finally, I'll note that the FSF does give a well-defined way to allow
<br>proprietry code to link with GPL'd code via a specific interface:
<br><br><a href="http://www.fsf.org/licensing/licenses/gpl-faq.html#LinkingOverControlledInterface" target="_top" rel="nofollow">http://www.fsf.org/licensing/licenses/gpl-faq.html#LinkingOverControlledInterface</a><br><br>it's pretty verbose though...
<br><br><br>~Chris.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19911500&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19909367Re: Contributor License Agreements2008-10-09T16:33:09Z2008-10-09T16:33:09Zajb-2G'day all.
<br><br>Quoting Chris Foster <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19909367&i=0" target="_top" rel="nofollow">foster@...</a>>:
<br><br>> I agree. It seems like the only reason to require a CLA would be to
<br>> allow relicensing in the future, and I don't think this is enough of an
<br>> issue to justify the pain.
<br><br>That's not the only reason. If someone infringes on the copyright of
<br>Aqsis (e.g. disobeys the open source licence), it helps in the legal
<br>fight if the copyright is held by one entity.
<br><br>Incidentally, I'd also be happy to assign copyright for anything I
<br>contributed to the project.
<br><br>Cheers,
<br>Andrew Bromage
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19909367&i=1" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19908686Re: Contributor License Agreements2008-10-09T15:39:21Z2008-10-09T15:39:21ZMatthias Baas-3Chris Foster wrote:
<br>>> As for the licensing issue, we could add an exemption to allow
<br>>> linking to the public interfaces from non-GPL/OSS code, but I'm not
<br>>> sure that is really needed. I don't think something linking to Aqsis
<br>>> via the RI interface could be considered a derivative work of Aqsis,
<br>>> any more than an application passing the Aqsis binary a lump of RIB
<br>>> could.
<br>>
<br>> Again I agree. The RI interface isn't even our work!
<br><br>The RI interface specification is not your work, but this particular
<br>implementation is. It was always my understanding that it would be
<br>illegal to link GPL libs against other code that uses a license which is
<br>incompatible with the GPL (but of course, I'm not an expert on this
<br>subject).
<br><br>A while ago I was also looking at this licensing stuff for cgkit (I even
<br>bought a book on this subject). For cgkit2 I switched from BSD to a
<br>GPL/LGPL/MPL tri-license. The MPL (which was used by Liquid) seemed to
<br>be quite reasonable to me and it allowed using the code in a commercial
<br>application as well (I didn't want to restrict usage to the Open Source
<br>world). But it is incompatible to the GPL, so I went for this
<br>tri-license which I took from the Mozilla project. My thinking was that
<br>Open Source projects who wanted to use cgkit could pick GPL or LGPL
<br>whereas commercial apps could pick the MPL.
<br><br>> Given what I said in the previous mail, I believe that the LGPL doesn't
<br>> offer much on the legal side of things. It does try to make the linking
<br>> issue clearer in a wishy-washy way, but we can do that just as easily by
<br>> simply stating so in our documentation or FAQ.
<br><br>That would be useful in any case. I guess the essence can always be
<br>expressed in a few simple sentences instead of several pages of
<br>lawyer-speak. And the rest should be common sense... :)
<br><br>- Matthias -
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19908686&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19896135Re: Contributor License Agreements2008-10-09T03:20:19Z2008-10-09T03:20:19ZTristan ColgateI think stating the fact that we aren't going to sue anyone for
<br>linking to Aqsis is probably a good idea. If we can put some legal
<br>element around that with a statment in the license (the GPL allows
<br>for this kind of thing), then even better, but I don't think it is
<br>needed.
<br><br> SImply stating somewhere that...
<br><br> "In our view, linking to the Aqsis libraries does not constitute
<br> a derivative work."
<br><br> We could limit that to the public interfaces or RI specifically if
<br> people prefer that, but I think we are only really doing it to ease
<br> the concerns of corporates.
<br><br>On Thu, Oct 09, 2008 at 08:02:52PM +1000, Chris Foster wrote:
<div class='shrinkable-quote'><br>> On Thu, Oct 09, 2008 at 09:01:57AM +0100, Tristan Colgate wrote:
<br>> > My take on this....
<br>> >
<br>> > Whilst I think I'm generally in favour of copyright assignment and
<br>> > CLAs (it just makes things clearer, and prevents the kind of issue
<br>> > around relicensing of legacy code that we face). But it is rather too
<br>> > late, and I suspect, rather too much pain, to implement it now.
<br>> > A CLA would also provide an additional barrier to entry for many
<br>> > potential contributors and I don't think that is wise at this time.
<br>>
<br>> I agree. It seems like the only reason to require a CLA would be to
<br>> allow relicensing in the future, and I don't think this is enough of an
<br>> issue to justify the pain.
<br>>
<br>> > As for the licensing issue, we could add an exemption to allow
<br>> > linking to the public interfaces from non-GPL/OSS code, but I'm not
<br>> > sure that is really needed. I don't think something linking to Aqsis
<br>> > via the RI interface could be considered a derivative work of Aqsis,
<br>> > any more than an application passing the Aqsis binary a lump of RIB
<br>> > could.
<br>>
<br>> Again I agree. The RI interface isn't even our work!
<br>>
<br>> > LGPL might make things a bit clearer, but I am not sure that
<br>> > the additional level of clarity is so great as to warrant the effort.
<br>>
<br>> Given what I said in the previous mail, I believe that the LGPL doesn't
<br>> offer much on the legal side of things. It does try to make the linking
<br>> issue clearer in a wishy-washy way, but we can do that just as easily by
<br>> simply stating so in our documentation or FAQ.
<br>>
<br>> ~Chris.
<br>>
<br>> -------------------------------------------------------------------------
<br>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>> Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>> Grand prize is a trip for two to an Open Source event anywhere in the world
<br>> <a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>> _______________________________________________
<br>> Aqsis-development mailing list
<br>> <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19896135&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br>> <a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a></div><br>--
<br>Tristan Colgate
<br>e-mail: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19896135&i=1" target="_top" rel="nofollow">tristan@...</a>
<br>---------
<br> "You can get all of your daily vitamins from
<br>42 pints of Guinness and a glass of milk"
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19896135&i=2" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19895890Re: Contributor License Agreements2008-10-09T03:02:52Z2008-10-09T03:02:52ZChris FosterOn Thu, Oct 09, 2008 at 09:01:57AM +0100, Tristan Colgate wrote:
<br>> My take on this....
<br>>
<br>> Whilst I think I'm generally in favour of copyright assignment and
<br>> CLAs (it just makes things clearer, and prevents the kind of issue
<br>> around relicensing of legacy code that we face). But it is rather too
<br>> late, and I suspect, rather too much pain, to implement it now.
<br>> A CLA would also provide an additional barrier to entry for many
<br>> potential contributors and I don't think that is wise at this time.
<br><br>I agree. It seems like the only reason to require a CLA would be to
<br>allow relicensing in the future, and I don't think this is enough of an
<br>issue to justify the pain.
<br><br>> As for the licensing issue, we could add an exemption to allow
<br>> linking to the public interfaces from non-GPL/OSS code, but I'm not
<br>> sure that is really needed. I don't think something linking to Aqsis
<br>> via the RI interface could be considered a derivative work of Aqsis,
<br>> any more than an application passing the Aqsis binary a lump of RIB
<br>> could.
<br><br>Again I agree. The RI interface isn't even our work!
<br><br>> LGPL might make things a bit clearer, but I am not sure that
<br>> the additional level of clarity is so great as to warrant the effort.
<br><br>Given what I said in the previous mail, I believe that the LGPL doesn't
<br>offer much on the legal side of things. It does try to make the linking
<br>issue clearer in a wishy-washy way, but we can do that just as easily by
<br>simply stating so in our documentation or FAQ.
<br><br>~Chris.
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19895890&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19894626Re: Contributor License Agreements2008-10-09T01:01:57Z2008-10-09T01:01:57ZTristan ColgateMy take on this....
<br><br> Whilst I think I'm generally in favour of copyright assignment and
<br>CLAs (it just makes things clearer, and prevents the kind of issue
<br>around relicensing of legacy code that we face). But it is rather too
<br>late, and I suspect, rather too much pain, to implement it now.
<br>A CLA would also provide an additional barrier to entry for many
<br>potential contributors and I don't think that is wise at this time.
<br>It's different if you are GCC and have hundreds of regular commiters
<br>and an active, visible mailing lists for submission of patches.
<br><br> As for the licensing issue, we could add an exemption to allow
<br>linking to the public interfaces from non-GPL/OSS code, but I'm not
<br>sure that is really needed. I don't think something linking to Aqsis
<br>via the RI interface could be considered a derivative work of Aqsis,
<br>any more than an application passing the Aqsis binary a lump of RIB
<br>could. LGPL might make things a bit clearer, but I am not sure that
<br>the additional level of clarity is so great as to warrant the effort.
<br><br> It is all going to boil down to the practicality of contacting
<br>everyone with a copyright claim to Aqsis code (surely that is only the
<br>people that have explicitly laid claim to it in source files?). We
<br>either do it once and try to persuade them to submit a patch to
<br>reassign the copyright, which they might be unhappy to do. Or we
<br>mail the same group of people requesting a license change. We would
<br>also need clear direction of what the legal standpoint is if those
<br>people do not respond to mails in a timely fashion.
<br><br> Just for the record:
<br> I'm happy to reassign copyright for whatever of my code might be
<br>left in Aqsis, and to sign a CLA for any future contributions.
<br><br>On Thu, Oct 09, 2008 at 05:07:01PM +1000, Chris Foster wrote:
<div class='shrinkable-quote'><br>> On Wed, Oct 08, 2008 at 08:52:07AM +0100, Paul Gregory wrote:
<br>> > All,
<br>> >
<br>> > After last weeks meeting I've been looking into the issue of copyright
<br>> > assignment and contributor license agreements (CLA). The reason this issue
<br>> > was raised was that some files in a branch are explicitly marked as
<br>> > copyright the author, and concerns were raised about this practice,
<br>> > specifically should the need arise to relicense at any time.
<br>> >
<br>> > I've spent some time looking into this matter, and found a variety of
<br>> > opinions, but this discussion on the OSGeo IRC channel during a meeting
<br>> > about just this issue seems to be the most informative. I certainly believe
<br>> > that Eric S. Raymond ("esr" in the logs) is far more knowledgeable in this
<br>> > than I. I would like everyone interested to read this discussion in
<br>> > preparation for this weeks meeting (20081012) during which we will discuss
<br>> > the issues and form a final decision on the policy.
<br>> >
<br>> > <a href="http://logs.qgis.org/osgeo/%23osgeo.2006-03-20.log" target="_top" rel="nofollow">http://logs.qgis.org/osgeo/%23osgeo.2006-03-20.log</a><br>>
<br>> I've read over these logs, but didn't find them incredibly definitive.
<br>> A bit of background - OSGeo is an foundation for geospatial software;
<br>> they're an umbrella for several semi-independent open source projects.
<br>> These logs contain a discussion about the benefits and drawbacks of
<br>> requiring contributor license agreements.
<br>>
<br>> The discussion about CLAs on the qgis logs centres around two issues:
<br>> (1) Protection of the project (or contributors?) from patent lawsuits
<br>> etc. by agressive third parties
<br>> (2) Giving projects a limited ability to relicense code at a later time.
<br>>
<br>> ESR argued fairly convincingly that CLAs are useless as legal protection
<br>> (and actually conterproductive)... this wasn't a concern of mine
<br>> however, I'm more concerned about point (2).
<br>>
<br>> As Paul noted, I brought up the ability to relicense at the last
<br>> meeting; on this point the discussion linked above seemed much less
<br>> definitive IMHO. The OSGeo guys eventually decided to create a CLA
<br>> which could be optionally adopted by the individual projects as they saw
<br>> fit. Here's the relevant link:
<br>>
<br>> <a href="http://wiki.osgeo.org/wiki/Contributor_Agreement" target="_top" rel="nofollow">http://wiki.osgeo.org/wiki/Contributor_Agreement</a><br>>
<br>> ... reading that legalese certianly leaves a bad taste in my mouth.
<br>>
<br>>
<br>> My main concern regards linking and this is why I brought up the
<br>> licensing issues in the first place: I don't think it's reasonable that
<br>> commercial projects which simply *link* to Aqsis libraries (at least the
<br>> ones which I write!) should have to also be released under
<br>> GPL-compatible licenses. To require such a thing seems contradictory
<br>> given the nature of our primary interface - the Renderman Interface.
<br>> The renderman interface is a commercial interface itself, but is made
<br>> available *freely* to anyone wishing to implement it.
<br>>
<br>> Lawrence Rosen has written an excellent book on open source licensing,
<br>> available here:
<br>> <a href="http://rosenlaw.com/oslbook.htm" target="_top" rel="nofollow">http://rosenlaw.com/oslbook.htm</a><br>>
<br>> The chapter on the GPL has an interesting discussion about linking and
<br>> the GPL. It seems that the requirement that all code linked with Aqsis
<br>> be released under the GPL depends on the definition of "derivative
<br>> work", which is legally shaky. Ultimately it suggests that license
<br>> requirements for programs which link to GPL'd code are up to the
<br>> copyright holders (us).
<br>>
<br>> The book also has an interesting analysis of the LGPL which is what I
<br>> had in mind when I mentioned relicensing to begin with. As I understand
<br>> it, the intent of the LGPL is to specifically allow programs to link
<br>> with LGPL'd libraries, without imposing any license requirements on
<br>> those programs. However, Rosen calls the relevant sections of the LGPL
<br>> "an impenetrable maze of technological babble", and I can see what he's
<br>> getting at; they're very vague! At the end of the section "The LGPL
<br>> alternative" in chapter 6, Rosen concludes that
<br>>
<br>> The LGPL, therefore, is an anomaly - a hybrid license intended to
<br>> address a complex issue about program linking and derivative works. It
<br>> doesn't solve that problem, but merely directs us back to the main
<br>> event, the GPL license itself.
<br>>
<br>> Given the analysis in the book by Rosen, I'm inclined to be less worried
<br>> about the linking issue, and hence the multiple licensor issue.
<br>> Nevertheless it seems messy to have code listed as copyright of various
<br>> licensors, especially since files may be modified by many developers
<br>> other than the original one over the lifetime of the project.
<br>>
<br>> Any contributor automatically retains copyright over their own work by
<br>> default. For attribution, I think that simply putting them on the
<br>> authors list for a file should suffice.
<br>>
<br>>
<br>> I'd like to note that according to the LGPL, it's perfectly
<br>> permissable to relicense under the GPL at any time. This means that we
<br>> could choose to make future versions of libri2rib available under the
<br>> GPL. IMHO it would be simpler and cleaner to have all of Aqsis
<br>> available under the same license.
<br>>
<br>>
<br>> Issues for discussion
<br>> =====================
<br>>
<br>> * An official stance on linking proprietry programs with our codebase.
<br>> * Should we allow different licensors in different files of the codebase?
<br>> * Status of libri2rib regarding LGPL vs GPL licensing.
<br>> * Pros and cons of CLAs.
<br>> * Relicensing.
<br>>
<br>>
<br>> Ugh... this legal stuff is rather mind-numbing.
<br>> ~Chris.
<br>>
<br>> -------------------------------------------------------------------------
<br>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>> Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>> Grand prize is a trip for two to an Open Source event anywhere in the world
<br>> <a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>> _______________________________________________
<br>> Aqsis-development mailing list
<br>> <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19894626&i=0" target="_top" rel="nofollow">Aqsis-development@...</a>
<br>> <a href="https://lists.sourceforge.net/lists/listinfo/Aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/Aqsis-development</a></div><br>--
<br>Tristan Colgate
<br>e-mail: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19894626&i=1" target="_top" rel="nofollow">tristan@...</a>
<br>---------
<br> "You can get all of your daily vitamins from
<br>42 pints of Guinness and a glass of milk"
<br><br>-------------------------------------------------------------------------
<br>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
<br>Build the coolest Linux based applications with Moblin SDK & win great prizes
<br>Grand prize is a trip for two to an Open Source event anywhere in the world
<br><a href="http://moblin-contest.org/redirect.php?banner_id=100&url=/" target="_top" rel="nofollow">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>_______________________________________________
<br>Aqsis-development mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19894626&i=2" target="_top" rel="nofollow">Aqsis-development@...</a>
<br><a href="https://lists.sourceforge.net/lists/listinfo/aqsis-development" target="_top" rel="nofollow">https://lists.sourceforge.net/lists/listinfo/aqsis-development</a><br><p>From forum: <a href="http://www.nabble.com/aqsis-development-f3702.html" embed="fixTarget[3702]" target="_top" >aqsis-development</a></p>tag:www.nabble.com,2006:post-19893590Re: Contributor License Agreements2008-10-09T00:07:01Z2008-10-09T00:07:01ZChris FosterOn Wed, Oct 08, 2008 at 08:52:07AM +0100, Paul Gregory wrote:
<div class='shrinkable-quote'><br>> All,
<br>>
<br>> After last weeks meeting I've been looking into the issue of copyright
<br>> assignment and contributor license agreements (CLA). The reason this issue
<br>> was raised was that some files in a branch are explicitly marked as
<br>> copyright the author, and concerns were raised about this practice,
<br>> specifically should the need arise to relicense at any time.
<br>>
<br>> I've spent some time looking into this matter, and found a variety of
<br>> opinions, but this discussion on the OSGeo IRC channel during a meeting
<br>> about just this issue seems to be the most informative. I certainly believe
<br>> that Eric S. Raymond ("esr" in the logs) is far more knowledgeable in this
<br>> than I. I would like everyone interested to read this discussion in
<br>> preparation for this weeks meeting (20081012) during which we will discuss
<br>> the issues and form a final decision on the policy.
<br>>
<br>> <a href="http://logs.qgis.org/osgeo/%23osgeo.2006-03-20.log" target="_top" rel="nofollow">http://logs.qgis.org/osgeo/%23osgeo.2006-03-20.log</a></div><