On Wednesday, 27 March 2013 at 15:29:19 UTC, deadalnix wrote:
On Sunday, 24 March 2013 at 02:37:52 UTC, Moritz Maxeiner wrote:
On Sunday, 24 March 2013 at 01:35:28 UTC, Chris Cain wrote:
On Saturday, 23 March 2013 at 21:19:14 UTC, Moritz Maxeiner
wrote:
TLDR: Your example should now work, provided you fix what I
previously mentioned. You can also look at
sample/fibonacci.d which I used instead of your fac to
confirm that you gist now works.
- Moritz
Awesome. Indeed, it now fully works (and JIT does work after
all! Thanks for showing me how to use that). Thanks for the
more interesting example in the README, it's extremely
helpful. And also thank you for taking some time to help with
the issues I was having.
No problem, writing that fibonacci example forced me to read
up Stuff about LLVM I need to know anyway (for making the D
API)^^
Just one thing I forgot to mention: When you're using
llvm.util.memory.toCString you'll need to take care of the
allocated memory yourself, or you'll get memory leaks. The
example is a special case as all the c strings need to be kept
aroound until program termination, anyway (since LLVM's global
context exists until then and all the c strings used by LLVM
internally), but that's not the case with all LLVM C functions
with c string args.
Question : why did you reorganize the modules ? They don't
match LLVM's .h filenames.
Is that intended , if yes, why ?
Yes it is intended to be that way. Regarding the reasons for that
decision:
Short answer:
Because in the case of the LLVM C API it makes things a lot
easier and simpler to maintain, as well as trivial to add new
parts for new LLVM versions.
Long answer:
1) The LLVM C API has headers which have very few lines of actual
code (e.g. Linker.h which only contains one enum and one
functions), making those into D modules seems wasteful.
2) Over versions of the LLVM C API headers appear and dissappear
(e.g. Linker.h exists since 3.2, EnhancedDissassembly.h has been
removed in trunk 3.3) and having them all around as D modules
makes maintenence a lot more complicated.
3) Having all functions in a single compile time enum makes the
runtime loading process a lot easier as you can generate all
three steps ( 1. function pointer alias for every C function 2.
function pointer variable for every function pointer alias 3.
loading of the shared lib symbol into the function pointer for
every function pointer) with but a few lines of codes, instead of
having to write the names of all C functions three times. And
since you can encode more information in that enum (an
associative array in this case) adding more function is trivial:
Simply add the function to the array in this manner: "NAME" :
["SIGNATURE", "+", "VERSION"] and that's it (and if the function
has been removed in said VERSION, change "+" into "-"). Since the
MixinMap template (a CTFE version of the map function designed to
get an array as its list and create D code for each of the items
of said array based on a delegate function f) is used for the
three steps described above no further code is needed.
TLDR: Supporting different versions of the LLVM C API takes
considerably less effort this way and if there is a disadvantage
to this approach big enough to outweigh that I can't see it.
