dcv
dcv copied to clipboard
libmir
betterC mir-cv
@ljubobratovicrelja what do you think about to create a new repo for new code? This will allow us to do development and review faster.
Good idea! Regarding that, can I ask of you this one thing - could you lay out (in readme of this new repo, or anywhere convenient) rules that have to be obeyed in order to library stays betterC compliant? So we have, sort of like the guide to follow, when porting existing functions from present dcv to the new one.
Another thing - I suppose in order to be linkable from other languages, the whole library has to be built with these rules, right? In case we'd like to have high level (D) layer that has less restrictions, and for e.g. uses the GC, I suppose we'd have to separate this layer as another library, which would be a wrapper to low-level (betterC) library, correct? It would be awesome If you could explain those architectural requirements also.
Even better: it would be awesome if we could automatically enforce that the low-level part is betterC with Travis or CircleCi!
https://github.com/libmir/mir-algorithm/wiki/BetterC-for-Mir https://github.com/libmir/mir-cv
Another thing - I suppose in order to be linkable from other languages, the whole library has to be built with these rules, right? In case we'd like to have high level (D) layer that has less restrictions, and for e.g. uses the GC, I suppose we'd have to separate this layer as another library, which would be a wrapper to low-level (betterC) library, correct? It would be awesome If you could explain those architectural requirements also.
A generic betterC library can contain GC code, but it should be restricted small API subset. For example, only slice uses GC in mir-algorithm.
Even better: it would be awesome if we could automatically enforce that the low-level part is betterC with Travis or CircleCi!
This can be done for precompiled library.
https://github.com/libmir/mir-algorithm/wiki/BetterC-for-Mir
Thanks!