"Lubomir Bourdev" <lbourdev@adobe.com> wrote in message news:B55F4112A7B48C44AF51E442990015C0016B74D0@namail1.corp.adobe.com...
Andy Little wrote:
- What is your evaluation of the design?
I believe that the various Concepts namely treating a data sequence as a view on a matrix or grid, iterating a matrix or Grid , and Color have not been adequately thought about in their own right.
We have discussed our disagreements on separating out Color and Grid in separate lengthy emails. To summarize my points:
For Color: Though the idea is appealing, you cannot deal with color in an abstract way; in a color library you must account for how color is represented in memory. There are a large number of representations out there (order of channels, channel depth, subbyte representation, etc.) Where do all these representations come from? Almost exclusively they come from the way colors in _images_ are represented. So all these memory representations are specific to images and therefore logically they must be supported inside an image library. This explains why color is inside every image library I have looked at.
I think I have covered this in other posts.
For Grid: Again, what concrete example can you give me that requires GIL-s generalization of a Grid and cannot be represented as an image. Your example of a DisplayMatrix for text characters quickly falls apart. If you need a generic grid navigation, why not use a library whose goal is more aligned to grids and navigation, such as boost::MultiArray?
The Concept of grid navigation is interesting and I like the locator in GIL. Boost.MultiArray is a model of a grid sure. The example that interests me is the mandelbrot example. The mandelbrot function itself is a poor demo because generating points is nearly random, but here there is no actual grid in required to be in memory, but there is still the concept of a grid.. All that is required is the clipping region (You could have a grid in memory to cache the results of previous views if the user is moving about, but it is not required). The locator ( I would call it cursor) maybe provides the ability to iterate over a non-existent grid, which appeals to me. dereferencing the cursor where some elements are functions and others are data elements and things could get interesting. An obvious application for a bitmap is where many pixels are the same colour. One could also provide a function which allows the cursor to navigate the grid maybe following an edge ( a significant difference between two neigbouring elements maybe) and recording its path for example.
- What is your evaluation of the implementation?
I didnt look in detail. It appeared that some typedefs were only there to meet GIL Concept requirements and appeared to be unused. This is an indication that the implementation probably has unneccessary dependencies.
There are typedefs that are required by N-dimensional concepts, for example get an iterator over the N-th dimension of a locator/view/image. These are important so that current 2D models can be used in future generic N-dimensional algorithms.
- What is your evaluation of the documentation?
Links to the Concepts don't work (they point to local files on my system).
Yes, after you brought it up, I discovered that the PDF files have dead links. In the future we will remove the links when generating the PDFs. The HTML links should be working properly.
The use of ConceptC++ style concepts is problematic. My suggestion is that if one wishes to use this style in the Docs then you should also follow through and actually put the Concepts into code and compile them on ConceptGCC. You could then verify that the documentation is correct. I suspect that the current GIL docs would require a lot of work to pass that test. In fact I would make that a requirement for any Docs that wish to use the ConceptGCC format. This would be an interesting discipline and I suspect would result in design changes to the library itself.
Compiling GIL on ConceptGCC is a great idea and we will do so. Where can we get ConceptGCC from? Had you looked in the code though, you would have discovered that GIL concepts have associated Concept classes, and yes, GIL compiles successfully with boost::concept_check enabled. While this is probably not as strict as ConceptGCC, it suggests that large changes to the library are unlikely.
ConceptC++ is a different animal. My limited experience with it so far has been to throw away most ideas regarding templates. Porting a libary to ConceptC++ will be AFAICS, a major project.
There is a format (official or unofficial) for library reviews, which has not been followed. The code is designed to be copied into the reviewers boost distribution for evaluation.
Given that some other libraries have used external links as well, my understanding is that the vault is for convenience to developers that don't have an easy way to distribute their library. I believe our web page has an easy way to get to the code and documentation and may be more convenient to navigate than a directory of files.
The installations section of the tutorial doesnt cover quite what you are meant to do to install the library.
The tutorial refers you to GIL's web page which contains detailed installation instructions.
Suggestions for a first example. Load an image, provide some means or suggestions so that you can view the image. Show code for a transform
of
the image. View the result. Proceed like that.
Have you looked at slide 88 of the video presentation? It is doing exactly this. It shows GIL code to the left and the result to the right. Having a GUI to display an image in a platform independent way is beyond the scope of the library, as we have discussed in an earlier thread. You can just save the image and use your favorite image viewer.
As regards the way the review material is packaged for potential reviewers, I think you could revisit it ;-) regards Andy Little