On Thursday, 28 March 2013 at 05:04:42 UTC, deadalnix wrote:
>
> Ok, that sound reasonable.
>
> Second question, why do you do stuff like :
>
> enum Foo {
>    FooA,
>    FooB,
>    FooC,
> }
>
> when you would do
>
> enum Foo {
>     A,
>     B,
>     C,
> }
>
> ?

I don't, I do:

alias uint Foo;
enum : Foo
{
  FooA,
  FooB,
  FooC
}

which is a direct translation of the C enums. It gives the enum items no named scope, only creates an (alias) type for them. See
https://github.com/Calrama/llvm-d/blob/master/llvm/c/constants.d
and
https://github.com/Calrama/llvm-d/blob/master/llvm/c/types.d

>
> D enums introduce a scope, when C's don't. So C need to prefix enums entries manually, when in D it isn't required. The C to D translation goes as follow : FooA => Foo.A instead of Foo.FooA .

That is not the D equivalence of the C code. That is how D improves upon C enums. The equivalence and thus the translation is to not use a named scope as seen above.

>
> If the goal isn't to follow LLVM's source as closely as possible, I think this is the way to go.

It does follow the LLVM C API source code as closely as possible. It just uses a module structure different from LLVM's C API header structure for the reasons stated above, which does not change how to use the C API (As you should do "import llvm.c.all" either way). This is also not a new approach, Derelict (one of the major providers for D bindings to C libraries other than deimos) has been doing it for a long time.

On Thursday, 28 March 2013 at 09:23:27 UTC, Moritz Maxeiner wrote:
> I don't, I do:
>
> alias uint Foo;
> enum : Foo
> {
>   FooA,
>   FooB,
>   FooC
> }
>
> which is a direct translation of the C enums. It gives the enum items no named scope, only creates an (alias) type for them. See
> https://github.com/Calrama/llvm-d/blob/master/llvm/c/constants.d
> and
> https://github.com/Calrama/llvm-d/blob/master/llvm/c/types.d
>

Ho sorry, I missed that. That is still inferior as it doesn't introduce its own type now.

>>
>> D enums introduce a scope, when C's don't. So C need to prefix enums entries manually, when in D it isn't required. The C to D translation goes as follow : FooA => Foo.A instead of Foo.FooA .
>
> That is not the D equivalence of the C code. That is how D improves upon C enums. The equivalence and thus the translation is to not use a named scope as seen above.
>

This is why I used the word translation. A good translation doesn't repeat stupidly, but uses idoms of the target language.

>>
>> If the goal isn't to follow LLVM's source as closely as possible, I think this is the way to go.
>
> It does follow the LLVM C API source code as closely as possible. It just uses a module structure different from LLVM's C API header structure for the reasons stated above, which does not change how to use the C API (As you should do "import llvm.c.all" either way). This is also not a new approach, Derelict (one of the major providers for D bindings to C libraries other than deimos) has been doing it for a long time.

It doesn't follow as closely as possible as the way code is structured is part of the code. I also don't see the consistency between that choice and the enum one.

On Thursday, 28 March 2013 at 17:30:24 UTC, deadalnix wrote:
> On Thursday, 28 March 2013 at 09:23:27 UTC, Moritz Maxeiner wrote:
>> I don't, I do:
>>
>> alias uint Foo;
>> enum : Foo
>> {
>>  FooA,
>>  FooB,
>>  FooC
>> }
>>
>> which is a direct translation of the C enums. It gives the enum items no named scope, only creates an (alias) type for them. See
>> https://github.com/Calrama/llvm-d/blob/master/llvm/c/constants.d
>> and
>> https://github.com/Calrama/llvm-d/blob/master/llvm/c/types.d
>>
>
> Ho sorry, I missed that. That is still inferior as it doesn't introduce its own type now.

No problem, if you mean a strict/strong type, iirc (correct me if I'm wrong, though) that is the case for C enums as well. I can change the alias to typedef, though, if it is really that important.

>
>>>
>>> D enums introduce a scope, when C's don't. So C need to prefix enums entries manually, when in D it isn't required. The C to D translation goes as follow : FooA => Foo.A instead of Foo.FooA .
>>
>> That is not the D equivalence of the C code. That is how D improves upon C enums. The equivalence and thus the translation is to not use a named scope as seen above.
>>
>
> This is why I used the word translation. A good translation doesn't repeat stupidly, but uses idoms of the target language.

Generally I would agree, but I'm translating the declarations of an interface here, not porting the implementation. And as such the content of the D interface imho should match the content of the C interface, meaning a literal translation, even if that makes it stupid from the D perspective. The *only* exception to that is the file structure as C headers are different things than D modules and there's no 100% match in D for C headers. D interface files (.di) would probably be technically the closest thing.

>
>>>
>>> If the goal isn't to follow LLVM's source as closely as possible, I think this is the way to go.
>>
>> It does follow the LLVM C API source code as closely as possible. It just uses a module structure different from LLVM's C API header structure for the reasons stated above, which does not change how to use the C API (As you should do "import llvm.c.all" either way). This is also not a new approach, Derelict (one of the major providers for D bindings to C libraries other than deimos) has been doing it for a long time.
>
> It doesn't follow as closely as possible as the way code is structured is part of the code.

The way the code (in C) is structured is preserved in the D modules by grouping and documentation tags. The C header file structure itself is lost, yes, but not the logical structure it represent. As such I don't see any vital information being lost compared to translating the C headers as D modules.

> I also don't see the consistency between that choice and the enum one.

It is only consistent under the directive "Follow the original C API code as closely as possible while minimizing the amount of work needed to maintain the result", not in a general sense, but consider this:

Your enum choice would create a break in the documentation, as the enum items would not match what is written in the LLVM doxygen documentation anymore (which means I would have to provide documentation for that difference); that also holds true for the file structure, of course, but since you'll get the entire C API with one import anyway ("import llvm.c.all") there's no additional documentation needed there (it is covered by the already existing examples).

If you want proper D enums (with names), though, they'll be present in the D API - mapping to the C bindings' enum's items.

On Thursday, 28 March 2013 at 19:09:47 UTC, Moritz Maxeiner wrote:
> No problem, if you mean a strict/strong type, iirc (correct me if I'm wrong, though) that is the case for C enums as well. I can change the alias to typedef, though, if it is really that important.
>

Typedef is depreacted. The D way is enum TypeName : superType { members }

> Generally I would agree, but I'm translating the declarations of an interface here, not porting the implementation. And as such the content of the D interface imho should match the content of the C interface, meaning a literal translation, even if that makes it stupid from the D perspective. The *only* exception to that is the file structure as C headers are different things than D modules and there's no 100% match in D for C headers. D interface files (.di) would probably be technically the closest thing.
>

Changing the module structure change the interface. Including all isn't a solution to that problem, as this kind of thing will make compile time and resource explode, especially since many things here are built out of mixins.

> Your enum choice would create a break in the documentation, as the enum items would not match what is written in the LLVM doxygen documentation anymore (which means I would have to provide documentation for that difference); that also holds true for the file structure, of course, but since you'll get the entire C API with one import anyway ("import llvm.c.all") there's no additional documentation needed there (it is covered by the already existing examples).
>

It wont break LLVM's documentation. See for instance : http://llvm.org/docs/doxygen/html/group__LLVMCCoreType.html

LLVMGetTypeKind is clearly documented as returning a LLVMTypeKind, not an int.

> If you want proper D enums (with names), though, they'll be present in the D API - mapping to the C bindings' enum's items.

Code duplication is rarely a good idea. Especially since your goal mentioned above is to reduce maintenance costs.

On Friday, 29 March 2013 at 03:47:47 UTC, deadalnix wrote:
> On Thursday, 28 March 2013 at 19:09:47 UTC, Moritz Maxeiner wrote:
>Including all isn't a solution to that problem, as this kind of thing
> will make compile time and resource explode, especially since many things here are built out of mixins.

The problem you describe is that you consider not representing C headers as D modules a change in the interface, correct (I disagree, but that's another matter)? If noone interfaces with the structure at all, e.g. by importing an all module, what you feel is a problem won't bother anyone, as noone interacts with the structure anymore; thus it is a solution to that problem.

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.

>> Your enum choice would create a break in the documentation, as the enum items would not match what is written in the LLVM doxygen documentation anymore (which means I would have to provide documentation for that difference); that also holds true for the file structure, of course, but since you'll get the entire C API with one import anyway ("import llvm.c.all") there's no additional documentation needed there (it is covered by the already existing examples).
>>
>
> It wont break LLVM's documentation. See for instance : http://llvm.org/docs/doxygen/html/group__LLVMCCoreType.html
>
> LLVMGetTypeKind is clearly documented as returning a LLVMTypeKind, not an int.

I did not talk about functions using the enums at that point, but about the enum definition (the enums' items):

>> as the enum items would not match what is written in the LLVM doxygen documentation anymore

See here under "Enumerations":
http://llvm.org/docs/doxygen/html/group__LLVMCCoreTypes.html

The enums documentation would not match the enums anymore, as the items' names would be different (even if it is just missing the part about their enum's name).

>
>> If you want proper D enums (with names), though, they'll be present in the D API - mapping to the C bindings' enum's items.
>
> Code duplication is rarely a good idea. Especially since your goal mentioned above is to reduce maintenance costs.

The enums in the C bindings exist in a global context, while the enums in the D API are often bound to specific classes (as the original C++ enums are, to which the C API enums partially map). An alias to the C bindings' enums would not suffixe as then the global C bindings' enums' items could still be used as arguments. And again, my goal was/is to

>> "Follow the original C API code as closely as possible while minimizing the amount of work needed to maintain the result"

Not to simply cut down on maintenence costs. Also the maintenence cost for that is virtually nonexistent in constrast to the header/module issue.

This goal is also followed for the D API reconstruction of the C++ class hierarchy, so the enums that are bound to classes in the C++ API should be bound to the classes in the D API, unless their names already imply where they belong - as is the case with TypeID. Literal it should e.g. become in D: "Type.TypeID.Void" but here TypeID implies Type so I made it "TypeID.Void".

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.

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.

> See here under "Enumerations":
> http://llvm.org/docs/doxygen/html/group__LLVMCCoreTypes.html
>
> The enums documentation would not match the enums anymore, as the items' names would be different (even if it is just missing the part about their enum's name).
>

It would simply transform LLVMXXXYYY into LLVMXXX.YYY, which is simply a workaround C limitations in the first place.

> 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.

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.

On Tuesday, 2 April 2013 at 15:30:53 UTC, Moritz Maxeiner wrote:
> 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.
>

I'd prefers see the problem fixed than documented. Anyway it is real, and should be considered now.

> 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
>

I don't think all modules need to, but you know better than me.

> 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.

The thing is that any automated tool will suffer from the translated module name as it cannot transform #include directives.

On Thursday, 4 April 2013 at 18:31:59 UTC, deadalnix wrote:
> On Tuesday, 2 April 2013 at 15:30:53 UTC, Moritz Maxeiner wrote:
>> 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.
>>
>
> I'd prefers see the problem fixed than documented. Anyway it is real, and should be considered now.

For the internal C bindings I'll stick with the CTFE (although I'll try to minimize/optimize its use). For the deimos-llvm pull request I used CTFE as well, but Jens already said that he thinks it's more natural to use multiple branches for supporting different LLVM versions (See here: https://github.com/jkm/deimos-llvm/pull/2) and llvm-d now supports using deimos-llvm as a replacement for its internal C bindings, so if the CTFE is a serious problem for someone, using deimos-llvm once he has integrated the split the CTFE into the branches would be the best option, I think.

>
>> 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
>>
>
> I don't think all modules need to, but you know better than me.

At present not yet, but since all LLVM C API functions wrap around LLVM's C++ class functions (except a few globals, which wrap around C++ globals) afaik to mimic as much of the LLVM hierarchy as possible, all these wrapper functions will be needed. I'll only be able to tell for sure once I'm finished, though and judging be the amount of work left that's going to take a while.

>
>> 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.
>
> The thing is that any automated tool will suffer from the translated module name as it cannot transform #include directives.

I'm not quite sure where you'd use an automated tool here that needs to be aware of any translation from C to D but if you do why not change the tool to make it aware of the constant/type/functions approach - It's not something I invented or actually new, see Derelict for example...

In any case, if you really need that, go with the deimos-llvm bindings. All you have to do is use "-version=DEIMOS_LLVM" and the internal C bindings won't even be imported by the D API and subsequently don't have to be compiled.