Administrator
|
I made a detailed overhaul of GlueGen's Struct Code Generator.
(Next desired step: Adding callback-generator C -> Java for C-function callbacks) Documentation: - New document covering GlueGen in general <https://jogamp.org/cgit/gluegen.git/about/doc/GlueGen_Mapping.md> - Specifically Struct Mapping (what has changes) <https://jogamp.org/cgit/gluegen.git/about/doc/GlueGen_Mapping.md#struct-mapping> - Actual JavaEmitter commit with details <https://jogamp.org/cgit/gluegen.git/commit/?id=8b127c4c1dd26fcb1756805ddb83729203161f78> - All git changes visible as usual here <https://jogamp.org/cgit/gluegen.git/log/> The JOAL, JOGL and JOCL changes were minimal: <https://jogamp.org/cgit/joal.git/log/> <https://jogamp.org/cgit/jogl.git/log/> <https://jogamp.org/cgit/jocl.git/log/> Further I updated - GlueGen git about <https://jogamp.org/cgit/gluegen.git/about/> - GlueGen web <https://jogamp.org/gluegen/www/> Please discuss ... below the copy & paste of the main git commit message of JavaEmitter commit with details <https://jogamp.org/cgit/gluegen.git/commit/?id=8b127c4c1dd26fcb1756805ddb83729203161f78>
|
Administrator
|
I like to add and was allowed to mention, that this feature work has been funded by Ankama. Marking this the 2nd round after the MacOS and HiDPI revision as of late. Thank you!
(We had one more last Dec/Jan for MacOS aarch64, but got no allowance to mention 'em) If more small to medium sized companies using our work would join in the funding rounds, we surely would not have any issues .. |
Administrator
|
In reply to this post by Sven Gothel
Discussion-1: In cases where the memory is being replaced and the complete 'array' not being written due to 'destPos + length < elemCount', shouldn't the old content be copied into the new memory area?
See example below. I would say yes ... +++ Discussion-2: In 'const type*' cases where the memory is always being replaced even at 'destPos + length < elemCount', the elemCount can shrink. This is different than for 'type*' cases, where the setter never shrinks the elemCount. Shall both variants behave the same, i.e. the 'const type*' case not shrink? See example below. I would say yes ... Additionally, perhaps shall the setter contain a flag allowing the elemCount to be shrinked? This also would help aligning the setter for both cases. +++ See setter code for a 'const int32_t*', always replacing whole memory. - Note: If destPos > 0, the new memory only has zero'ed bytes - Note: elemCount shrinks if destPos + length < oldElemCount, contrary to non-const setter below See setter code for a 'int32_t*', only replacing whole memory if 'destPos + length > elemCount'. - Note: If destPos > 0 and destPos + length > elemCount, the new memory only has zero'ed bytes - Note: elemCount never shrinks if destPos + length < oldElemCount, contrary to const setter above - Note: To shrink the array, one would need to call 'releaseVariaInt32PointerVariaLen()'
|
Administrator
|
If my answer would be taken, we would have:
- Copy old -> new non-covered data when allocating new memory - Adding a 'allowShrink' to the setter ??? |
Administrator
|
Could name it 'boolean subset', i.e. if true, the set*(..) is meant to only set a subset of the 'array', hence no shrink will occur. Otherwise, if false, the call is meant to set the whole 'array' and may shrink it. So if 'subset == true', the 'array' should also not grow - this in contrast to a flag named 'allowShrink'. Which variant tasted better? I like to avoid generating another function like setSub*(..) of course. |
Administrator
|
OK, the setter will be revised:
A) int32_t val[10] -> setter for a subset change only, as-is with args[src, srcPos, destPos, length] - no new memory - no special action to be performed B) int32_t* val -> setter with toggle 'subset' with args[subset, src, srcPos, destPos, length], - may replace memory where it also may copy 'destPos' gap from old -> new C) const int32_t* val -> setter to replace referenced memory only args[src, srcPos, length] - always replaces memory, no copy of a gap (no destPos) Hence: - case (A) stays as is - case (B) will be revised and argument 'boolean subset' added - case (C) will be revised (simplified) and argument 'destPos' removed Acceptable? Will do a code of this, also adding a generated API doc header for the setter and getter. |
Administrator
|
Completed mentioned setter refinement
- Signature Table https://jogamp.org/gluegen/doc/GlueGen_Mapping.html#struct-java-signature-table - Signature Examples https://jogamp.org/gluegen/doc/GlueGen_Mapping.html#struct-java-signature-examples See last git logs: GlueGen Struct [9] - [13] - https://jogamp.org/cgit/gluegen.git/log/ |
Administrator
|
Working pointer-pointer and function-pointer within structs:
https://jogamp.org/gluegen/doc/GlueGen_Mapping.html#struct-pointer-pointer-support .. and the git logs of course. https://jogamp.org/cgit/gluegen.git/log/ I pushed most logic down to Type* and Element/PointerBuffer, so the delta within JavaEmitter is almost neutral. Left todo: Complete the Java Callback support |
Administrator
|
This work was joined by Mathieu Féry (Ankama), providing ideas, patches and use-cases.
I was also able to merge his GlueGen patch series, enhancing usability. |
Free forum by Nabble | Edit this page |