On Tuesday, 2 April 2013 at 11:16:27 UTC, deadalnix wrote:
On Friday, 29 March 2013 at 12:07:11 UTC, Moritz Maxeiner wrote:
Now regarding the fact that you say that solution will have
the negative side-effect of making compile time and resource
"explode": I have tested llvm-d on some of my old machines
(inluding a first-gen intel atom underclocked to about 800
Mhz) and llvm-d compilation was never noticable slow, or used
considerable memory. But to either prove or contradict whether
this is a noticable side-effect of that solution we'd need
hard benchmarks.
DMD uses an huge amount of resource for CTFE, and leak a LOT of
memory. That is already known. Obviously, compiling this lib by
itself isn't going to trigger such issue.
I've not seen any mention about that under the "Documentation"
category and I've only found posts about that after explicitly
searching for that problem right now. I'm sorry for not knowing
about that, but if that is such a critical problem, it may be
sensible to document it in an article, e.g. "Compile time
function evaluation", under dlang.org's "Documentation" category
- I expected dmd to not use more memory for CTFE operations than
D would for runtime operations.
Regardless of that, the llvm-d's D API will need to include all
of the C API bindings anyway (however they may be done) and
llvm-d's internal C bindings exist primarily for the use of the D
API. If you only want the C bindings anyway, consider using
deimos-llvm. I've forked it and am going to update it to 3.2 and
3.3svn: https://github.com/Calrama/deimos-llvm
Another reason why the C bindings' enums and the D bindings'
enums will stay seperated is for compatibility with
deimos-llvm, which will be usable as a replacement for the
internal C bindings for people who e.g. want a c header -> d
module translation.
You thrown away that with your module refactoring, so it is
kind of pointless to raise that point now.
This is the important part of that sentence:
which will be usable as a replacement for the internal C
bindings
I don't use C header -> D module in llvm-d's internal C bindings,
llvm-d's D API, however, can use either llvm-d's internal C
bindings or (soon) deimos-llvm. I do not consider it pointless to
raise the point that if you (the user, not you specifically) want
to have a C header -> D module translation you can use
deimos-llvm together with llvm-d's D API without llvm'd internal
C bindings, that's all.
