April 11, 2018
On Wednesday, 11 April 2018 at 12:22:56 UTC, bachmeier wrote:
> It also wouldn't work with GDC. Given that GDC has been added to GCC, it would be a bad idea to tell people they need to use LDC to work with C code.

Currently porting a project to linux, stuff is so severely outdated, pretty much no dependency was satisfied  by the distro, in wich case for D it would be better to install ldc just to not touch gdc :)
Granted, it's only a problem for active projects, but what projects are inactive?
April 11, 2018
On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote:
> It's one thing for someone who is familiar with D to weigh the options and decide that being tied to ldc is okay. It's quite another to tell someone who isn't familiar with D that in order to use D, they have to use a feature which only works with a specific compiler that is not the reference compiler and which will likely never work with the reference compiler.

I'd say, you can focus on negative aspects if the auditory will analyze them, but it's a bad strategy if you only want to overcome prejudice.
April 12, 2018
On Wednesday, 11 April 2018 at 18:36:56 UTC, Walter Bright wrote:
> On 4/11/2018 3:25 AM, Atila Neves wrote:
>> I did the best I could having seen some macros. It's likely there are cases I've missed, or that maybe the translation in the link above doesn't work even for what it's supposed to be doing (I have no confidence about catching all the C casts for instance).
>> 
>> If there are other cases, I'll fix them as they're encountered. It's possible some of them can't be fixed and the user will have to work around them. Right now I have a feeling it will probably be ok. Time will tell (assuming I have users!).
>
>
> That's right. There is no general solution. One can only look for common patterns and do those. For example,
>
>   #define X 15
>
> is a common pattern and can be reliably rewritten as:
>
>   enum X = 15;

If I understand it correctly, dpp doesn't do that.

Instead, it runs the pre-processor on the source code, just like in C, so

// test.dpp
#define X 15
int foo() { return X; }

becomes

// test.d
int foo() { return 15; }

The upside of this approach: all macros just work, unless they use C (not C pre-processor, C proper) features that dpp can't handle. `sizeof(...)` is a special case that is handled in dpp.cursor.macro.translateToD and more could be added.

The downside: macros can't be directly used outside .dpp files.
April 12, 2018
On Thursday, 12 April 2018 at 11:43:51 UTC, John Colvin wrote:
> On Wednesday, 11 April 2018 at 18:36:56 UTC, Walter Bright wrote:
>> On 4/11/2018 3:25 AM, Atila Neves wrote:
>>> [...]
>>
>>
>> That's right. There is no general solution. One can only look for common patterns and do those. For example,
>>
>>   #define X 15
>>
>> is a common pattern and can be reliably rewritten as:
>>
>>   enum X = 15;
>
> If I understand it correctly, dpp doesn't do that.
>
> Instead, it runs the pre-processor on the source code, just like in C, so
>
> // test.dpp
> #define X 15
> int foo() { return X; }
>
> becomes
>
> // test.d
> int foo() { return 15; }
>
> The upside of this approach: all macros just work, unless they use C (not C pre-processor, C proper) features that dpp can't handle. `sizeof(...)` is a special case that is handled in dpp.cursor.macro.translateToD and more could be added.
>
> The downside: macros can't be directly used outside .dpp files.

Yes, I assumed it actually "expands" the macros, whereas it actually runs
the preprocessor on dpp files: https://github.com/atilaneves/dpp/issues/30

I can see it perfectly matches the Atila's usecase, and I'm curious
what are the other usecases for dpp?
April 13, 2018
Am Wed, 11 Apr 2018 16:44:32 +0300 schrieb drug:

> 11.04.2018 16:26, Uknown пишет:
>> On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote:
>>> 11.04.2018 15:22, bachmeier пишет:
>>>> On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote: ... Given that GDC has been added to GCC...
>>> Is it true? I don't see anything like that here https://gcc.gnu.org/gcc-8/changes.html
>> 
>> Here's relevant news from Phoronix:
>> 
>> https://www.phoronix.com/scan.php?page=news_item&px=D-Frontend-For-GCC
>> 
>> Here's the relevant announcement: https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
> I've read it. Unfortunately it doesn't answer my question. I've heard there were some problems.

IIRC copyright stuff once again stalled further discussion and the relevant GCC guys are not responding: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg186124.html


-- 
Johannes
April 13, 2018
On Wednesday, 11 April 2018 at 14:26:04 UTC, Jacob Carlborg wrote:
> On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
>> Here's my blog post about my project that allows directly #including C headers in D*
>
> BTW, you can steal the config script [1] from DStep to help detect locations of LLVM/libclang. It also supports static linking. Supports manually specifying the path to LLVM if needed.
>
> [1] https://github.com/jacob-carlborg/dstep/blob/master/configure.d
>
> --
> /Jacob Carlborg

Thanks!
April 13, 2018
On Wednesday, 11 April 2018 at 14:33:26 UTC, Jacob Carlborg wrote:
> On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
>> Here's my blog post about my project that allows directly #including C headers in D*
>
> I don't know the exact details of your project but can't you just:
>
> 1. Copy the includes
> 2. Paste them into a C file
> 3. Run DStep on the C file
> 4. Replace the includes in the first file with the result from DStep
>
> This would require changing DStep to always return `false` here [1]. Or perhaps run the preprocessor to expand the includes and then run DStep.
>
> [1] https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L326
>
> --
> /Jacob Carlborg

That wouldn't have the same semantics as I want.

I tried using dstep as a library. It didn't work.


April 13, 2018
On Wednesday, 11 April 2018 at 14:57:51 UTC, rumbu wrote:
> On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
>>[...]
> Cannot manage to build it on Windows:
>
> D:\git\dpp>dub build
> WARNING: A deprecated branch based version specification is used for the dependency libclang. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead.
> Performing "debug" build using dmd for x86.
> libclang ~master: target for configuration "library" is up to date.
> dpp 0.0.1+commit.41.g60f98e4: building configuration "executable"...
> Linking...
> OPTLINK (R) for Win32  Release 8.00.17
> Copyright (C) Digital Mars 1989-2013  All rights reserved.
> http://www.digitalmars.com/ctg/optlink.html
> OPTLINK : Warning 183: Extension not .RES : clang.lib
> C:\Users\[]\AppData\Roaming\dub\packages\libclang-master\libclang\.dub\build\library-debug-windows-x86-dmd_2079-78261F5A299D700FEEC2C0E7B51191C1\libclang.lib(1) : Error 52: .DEF Syntax Error
>
> [...]

I'll have to take a look at Jacob's configure.d to find out where libclang is installed on Windows.

It'll fail even if it builds though, since there won't be a `cpp.exe` on Windows for it to call. I don't even know what the equivalent would be with Visual Studio.
April 13, 2018
On 2018-04-13 12:33, Atila Neves wrote:

> I'll have to take a look at Jacob's configure.d to find out where libclang is installed on Windows.

Unfortunately the configuration script is only for Posix.

-- 
/Jacob Carlborg
April 14, 2018
On Friday, 13 April 2018 at 10:31:43 UTC, Atila Neves wrote:
> On Wednesday, 11 April 2018 at 14:33:26 UTC, Jacob Carlborg wrote:
>> On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote:
>>> Here's my blog post about my project that allows directly #including C headers in D*
>>
>> I don't know the exact details of your project but can't you just:
>>
>> 1. Copy the includes
>> 2. Paste them into a C file
>> 3. Run DStep on the C file
>> 4. Replace the includes in the first file with the result from DStep
>>
>> This would require changing DStep to always return `false` here [1]. Or perhaps run the preprocessor to expand the includes and then run DStep.
>>
>> [1] https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L326
>>
>> --
>> /Jacob Carlborg
>
> That wouldn't have the same semantics as I want.
>
> I tried using dstep as a library. It didn't work.

You also mentioned this in the reddit thread, though I'm still curious to understand what's difference in the semantics between the approach you have taken and the approach Jacob proposed.