https://issues.dlang.org/show_bug.cgi?id=2
Lance Bachmeier changed:
What|Removed |Added
CC||la...@lancebachmeier.com
--- Comment #3
https://issues.dlang.org/show_bug.cgi?id=2
--- Comment #2 from Atila Neves ---
I see. The -P flag doesn't show up in the man page.
--
https://issues.dlang.org/show_bug.cgi?id=2
Dennis changed:
What|Removed |Added
CC||dkor...@live.nl
Hardware|x86_64
https://issues.dlang.org/show_bug.cgi?id=2
Atila Neves changed:
What|Removed |Added
Keywords||ImportC
--
https://issues.dlang.org/show_bug.cgi?id=2
Issue ID: 2
Summary: ImportC: no way to specify where header files "live"
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severi
https://issues.dlang.org/show_bug.cgi?id=6019
--- Comment #13 from Walter Bright ---
(In reply to Andrej Mitrovic from comment #1)
> http://d-programming-language.org/dll.html
Now https://wiki.dlang.org/Win32_DLLs_in_D
--
https://issues.dlang.org/show_bug.cgi?id=23547
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #4
https://issues.dlang.org/show_bug.cgi?id=23547
--- Comment #3 from Iain Buclaw ---
*** Issue 23548 has been marked as a duplicate of this issue. ***
--
https://issues.dlang.org/show_bug.cgi?id=23547
Iain Buclaw changed:
What|Removed |Added
Summary|[REG master] C header files |[REG 2.101-master] C header
https://issues.dlang.org/show_bug.cgi?id=6019
Iain Buclaw changed:
What|Removed |Added
Priority|P2 |P3
--
https://issues.dlang.org/show_bug.cgi?id=18589
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P4
--
https://issues.dlang.org/show_bug.cgi?id=18363
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P4
--
https://issues.dlang.org/show_bug.cgi?id=23547
Iain Buclaw changed:
What|Removed |Added
Summary|[REG master] C header files |[REG master] C header files
https://issues.dlang.org/show_bug.cgi?id=23547
Iain Buclaw changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=23547
Iain Buclaw changed:
What|Removed |Added
Keywords||ImportC, rejects-valid,
|
https://issues.dlang.org/show_bug.cgi?id=23547
--- Comment #2 from Iain Buclaw ---
https://github.com/dlang/dmd/pull/14636
--
https://issues.dlang.org/show_bug.cgi?id=23547
Iain Buclaw changed:
What|Removed |Added
CC||ibuc...@gdcproject.org
--- Comment #1 from
https://issues.dlang.org/show_bug.cgi?id=23547
Issue ID: 23547
Summary: [REG master] C header files have precedent over D
modules
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
https://issues.dlang.org/show_bug.cgi?id=6019
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=6019
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=6019
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=6019
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
https://issues.dlang.org/show_bug.cgi?id=6019
Richard Cattermole changed:
What|Removed |Added
Keywords|bootcamp|
CC|
https://issues.dlang.org/show_bug.cgi?id=9285
Seb changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Tuesday, 18 February 2020 at 09:20:08 UTC, Andre Pany wrote:
Hi Petar,
Hi Andre, I'm happy to help :)
thank you very much for the explanation and the code sample.
Filling the az_span anonymous member was the tricky part,
I thought it would be not possible to do so, but you showed me
the
On Tuesday, 18 February 2020 at 08:32:47 UTC, Petar Kirov
[ZombineDev] wrote:
On Tuesday, 18 February 2020 at 05:41:38 UTC, Andre Pany wrote:
Hi,
I try to get wrap the "Azure SDK for C" using DPP and have
following issue.
Functions, which are actually implemented in C header files
On Tuesday, 18 February 2020 at 05:41:38 UTC, Andre Pany wrote:
Hi,
I try to get wrap the "Azure SDK for C" using DPP and have
following issue.
Functions, which are actually implemented in C header files
will cause
linker errors:
https://github.com/Azure/azure-sdk-for-c/blob/maste
Hi,
I try to get wrap the "Azure SDK for C" using DPP and have
following issue.
Functions, which are actually implemented in C header files will
cause
linker errors:
https://github.com/Azure/azure-sdk-for-c/blob/master/sdk/core/core/inc/az_span.h#L91
Example:
AZ_NODISCARD AZ_INLI
Am Tue, 30 Jul 2019 15:19:44 +1200 schrieb rikki cattermole:
> On 30/07/2019 4:11 AM, Eduard Staniloiu wrote:
>> Cheers, everybody
>>
>> I'm working on this as part of my GSoC project [0].
>>
>> I'm working on building gdc with the auto-generated `frontend.h` [1],
>> but I'm having some issues
On 30/07/2019 4:11 AM, Eduard Staniloiu wrote:
Cheers, everybody
I'm working on this as part of my GSoC project [0].
I'm working on building gdc with the auto-generated `frontend.h` [1],
but I'm having some issues
There are functions in dmd that don't have an `extern (C)` or `extern
(C++)`
Cheers, everybody
I'm working on this as part of my GSoC project [0].
I'm working on building gdc with the auto-generated `frontend.h`
[1], but I'm having some issues
There are functions in dmd that don't have an `extern (C)` or
`extern (C++)` but they are used by gdc (are exposed in `.h`
On Sunday, 13 January 2019 at 22:40:57 UTC, Alec Stewart wrote:
Example without code; for some reason a macro is defined for
the stdlib functions `malloc`, `realloc`, and `free`. Maybe
it's just because I don't have any pro experience with C or
C++, but that seems a bit excessive. Or I
On Sunday, 13 January 2019 at 23:23:50 UTC, Alex wrote:
These three are members of the standard library in D.
https://dlang.org/phobos/core_memory.html
Ah, yea that's way easier.
At first, I would suggest to try out some automatic converters,
which are written by the community:
On Sunday, 13 January 2019 at 22:40:57 UTC, Alec Stewart wrote:
Example without code; for some reason a macro is defined for
the stdlib functions `malloc`, `realloc`, and `free`. Maybe
it's just because I don't have any pro experience with C or
C++, but that seems a bit excessive. Or I could
Hello all!
So while I have a decent grasp on D, I've been having trouble
figuring out specific projects that I could do in D, so I thought
I'd maybe find a little C or C++ library I could transfer over to
D. I decided to make my life easier and look for something that's
just a single header
https://issues.dlang.org/show_bug.cgi?id=18589
Issue ID: 18589
Summary: Windows header files: bcrypt and ncrypt
Product: D
Version: D2
Hardware: All
OS: Windows
Status: NEW
Severity: enhancement
https://issues.dlang.org/show_bug.cgi?id=18363
Issue ID: 18363
Summary: we should autogenerate duplicate “.h” header files in
dmd to keep them in sync
Product: D
Version: D2
Hardware: x86
OS: All
https://issues.dlang.org/show_bug.cgi?id=6019
Andrei Alexandrescu changed:
What|Removed |Added
Keywords||bootcamp
On 28/08/2016 6:34 AM, cy wrote:
I made a module that looped for a while in compile time (since you can't
sleep during compile time), to see if I could pre-compile the module,
and thus save time compiling the main application. It didn't work at
first, because any file that depended on the module
I made a module that looped for a while in compile time (since
you can't sleep during compile time), to see if I could
pre-compile the module, and thus save time compiling the main
application. It didn't work at first, because any file that
depended on the module would import it, and importing
On Wednesday, 6 January 2016 at 13:36:03 UTC, data pulverizer
wrote:
I have been converting C numeric libraries and depositing them
here: https://github.com/dataPulverizer. So far I have glpk and
nlopt converted on a like for like c function basics. I am now
stuck on the gsl library, primarily
I have been converting C numeric libraries and depositing them
here: https://github.com/dataPulverizer. So far I have glpk and
nlopt converted on a like for like c function basics. I am now
stuck on the gsl library, primarily because of the preprocessor c
code which I am very new to. The
On Wednesday, 6 January 2016 at 13:59:44 UTC, John Colvin wrote:
#define INLINE_FUN extern inline // used in gsl_pow_int.h:
INLINE_FUN double gsl_pow_2(const double x) { return x*x; }
Could I just ignore the INLINE_FUN and use alias for function
pointer declaration? For example ...
alias
https://issues.dlang.org/show_bug.cgi?id=3306
Andrei Alexandrescu and...@erdani.com changed:
What|Removed |Added
Version|2.032 |D2
--
Am Sun, 10 May 2015 10:37:13 -0400
schrieb bitwise bitwise@gmail.com:
I'm not sure I understand what you're trying to say.
Bit
I'm trying to hijack your thread and communicate that .di
files are important for D since they allow the compiler to
stop recursively importing modules at
On Monday, 11 May 2015 at 12:46:59 UTC, Marco Leise wrote:
Am Sun, 10 May 2015 10:37:13 -0400
schrieb bitwise bitwise@gmail.com:
I'm not sure I understand what you're trying to say.
Bit
I'm trying to hijack your thread and communicate that .di
files are important for D since they
Am Mon, 11 May 2015 12:50:48 +
schrieb weaselcat weasel...@gmail.com:
On Monday, 11 May 2015 at 12:46:59 UTC, Marco Leise wrote:
Am Sun, 10 May 2015 10:37:13 -0400
schrieb bitwise bitwise@gmail.com:
I'm not sure I understand what you're trying to say.
Bit
I'm trying
for it being this way?
Wouldn't it be much more useful if directories were preserved?
Bit
I agree, D modules are hierarchical and sometimes share the
same base name. Header files are very important to short
circuit the transitive import chain. We've already seen it in
Phobos. Many modules ends up
On Sunday, 10 May 2015 at 01:00:31 UTC, bitwise wrote:
Is there really no way to preserve the directory structure when
creating .di files?
Bit
Why hello, Bitwise! I believe the '-op' flag is what you're
looking for!
Bitwiser
On Sun, 10 May 2015 04:20:45 -0400, Marco Leise marco.le...@gmx.de wrote:
I agree, D modules are hierarchical and sometimes share the
same base name. Header files are very important to short
circuit the transitive import chain. We've already seen it in
Phobos. Many modules ends up pulling
On 05/10/2015 09:11 AM, bitwise wrote:
On Sunday, 10 May 2015 at 01:00:31 UTC, bitwise wrote:
Is there really no way to preserve the directory structure when
creating .di files?
Bit
Why hello, Bitwise! I believe the '-op' flag is what you're looking for!
Bitwiser
Wow! Walter has
On Sat, 09 May 2015 21:09:33 -0400, Ali Çehreli acehr...@yahoo.com wrote:
On 05/09/2015 07:01 AM, bitwise wrote:
./main.d
./pack/foo.d
./pack/sub/bar.d
dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H
This dumps all the *.di files into the output directory ignoring the
directory structure.
On 05/09/2015 07:01 AM, bitwise wrote:
./main.d
./pack/foo.d
./pack/sub/bar.d
dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H
This dumps all the *.di files into the output directory ignoring the
directory structure.
Is there some rational for it being this way?
Wouldn't it be much more useful
On 05/09/2015 06:18 PM, bitwise wrote:
I'm not sure I understand what you mean, but my point is, that as is,
this feature of DMD is broken.
Arguably broken but compared to other tools it behaves in the same way.
If people are successfully using dmd -H right now, they must not be
using
On Sat, 09 May 2015 21:31:20 -0400, Ali Çehreli acehr...@yahoo.com wrote:
On 05/09/2015 06:18 PM, bitwise wrote:
I'm not sure I understand what you mean, but my point is, that as is,
this feature of DMD is broken.
Arguably broken but compared to other tools it behaves in the same way.
On Sat, 09 May 2015 10:01:25 -0400, bitwise bitwise@gmail.com wrote:
./main.d
./pack/foo.d
./pack/sub/bar.d
dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H
This dumps all the *.di files into the output directory ignoring the
directory structure.
Is there some rational for it being
./main.d
./pack/foo.d
./pack/sub/bar.d
dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H
This dumps all the *.di files into the output directory ignoring the
directory structure.
Is there some rational for it being this way?
Wouldn't it be much more useful if directories were preserved?
https://issues.dlang.org/show_bug.cgi?id=9285
Issue 9285 depends on issue 11620, which changed state.
Issue 11620 Summary: dmd json output should output enum values
https://issues.dlang.org/show_bug.cgi?id=11620
What|Removed |Added
https://issues.dlang.org/show_bug.cgi?id=9285
--- Comment #14 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
https://issues.dlang.org/show_bug.cgi?id=11620 is now fixed, are there any
other fixes needed for this tool?
--
\package.d
source\wba\wbWrapper.d source\wba\webbrowser.d
source\wba\webBrowserForm.d -IC:\D\dmd2\src\druntime\import
-IC:\D\dmd2\src\phobos -IC:\D\lib\WindowsAPI -lib -odobj\Header
-ofJ:\Workspace\Libraries\WebBrowserApplication\bin\Header\wba.lib -H
3 issues:
1) While using the header files
\wba.lib
-H
3 issues:
1) While using the header files in another project, the
package.di file does not work as expected. I cannot use
statement: import wba;
main.d(3): Error: module wba is in file 'wba.d' which cannot be
read
It only works if I rename package.di to package.d
2) property
On Saturday, 5 April 2014 at 10:00:13 UTC, Andre wrote:
2) property methods doesn't work with header files.
For this coding:
@property docHostUIHandler()
{
return this._docHostUIHandler;
}
This di coding was created:
@property docHostUIHandler
Am 05.04.2014 12:49, schrieb evilrat:
i have little info about this, but let me clear something for you.
- interface generation is outdated/broken
- .di files should be avoided now, this is why import looking for .d
only, but idk why.
- to avoid @property issue you can try adding export
On Saturday, 5 April 2014 at 10:55:19 UTC, evilrat wrote:
// recommended, manual type
@property HostUIHandlerType()
{
return this._docHostUIHandler;
}
oops. this of course should be like normal function.
https://d.puremagic.com/issues/show_bug.cgi?id=9285
--- Comment #13 from Adam D. Ruppe destructiona...@gmail.com 2014-02-10
20:55:50 PST ---
I haven't linked this in here yet so here it is:
https://github.com/D-Programming-Language/tools/pull/39
Should be good enough to start using, then we
On Friday, 13 December 2013 at 01:20:41 UTC, Mike Parker wrote:
On 12/13/2013 7:52 AM, Gary Willoughby wrote:
I have a lot of opaque types in C headers i'm porting to D.
What is the
best way to handle these? Would you just use void pointers?
In the below example Tcl_AsyncHandler_ is not
I have a lot of opaque types in C headers i'm porting to D. What
is the best way to handle these? Would you just use void pointers?
In the below example Tcl_AsyncHandler_ is not defined anywhere.
C:
typedef struct Tcl_AsyncHandler_ *Tcl_AsyncHandler;
D:
alias void* Tcl_AsyncHandler;
On 12/13/2013 7:52 AM, Gary Willoughby wrote:
I have a lot of opaque types in C headers i'm porting to D. What is the
best way to handle these? Would you just use void pointers?
In the below example Tcl_AsyncHandler_ is not defined anywhere.
C:
typedef struct Tcl_AsyncHandler_
https://d.puremagic.com/issues/show_bug.cgi?id=9285
Martin Nowak c...@dawg.eu changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment
https://d.puremagic.com/issues/show_bug.cgi?id=9285
--- Comment #10 from Adam D. Ruppe destructiona...@gmail.com 2013-11-27
11:43:21 PST ---
Are there any more substantial comments on the code I wrote in January? I just
tried to use it again, and there's some small updates needed. dmd's json
https://d.puremagic.com/issues/show_bug.cgi?id=9285
--- Comment #11 from Adam D. Ruppe destructiona...@gmail.com 2013-11-27
19:51:37 PST ---
I cleaned up and updated my old code so it works with new dmd again:
http://arsdnet.net/dcode/dtoh.zip
There's still some fixmes in there i can fix,
http://d.puremagic.com/issues/show_bug.cgi?id=6019
--- Comment #9 from Martin Nowak c...@dawg.eu 2013-10-02 04:42:10 PDT ---
*** Issue 9220 has been marked as a duplicate of this issue. ***
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving
http://d.puremagic.com/issues/show_bug.cgi?id=6019
--- Comment #11 from Martin Nowak c...@dawg.eu 2013-10-02 08:51:30 PDT ---
(In reply to comment #10)
How about this? Using weak undefined symbols to link against the imported
ModuleInfo would result in null pointers during runtime.
That
On 2013-07-18 00:59, H. S. Teoh wrote:
IOW either you don't do it at all, or you have to go all the way and
implement a fully-functional C frontend?
If so, libclang is starting to sound rather attractive...
That's what I'm telling
Hmm. We *could* pre-preprocess the code to do this
On 2013-07-18 00:36, Walter Bright wrote:
You could, but then you are left with failing to recognize:
#define FOO 3
and converting it to:
enum FOO = 3;
And things like:
#if linux
short a;
#elif _WIN32 || _WIN64
int a;
#endif
Should preferably be converted to:
version (linux)
On 2013-07-17 21:40, Walter Bright wrote:
Yes, but the front end itself must be complete. Otherwise,
it's not really practical when you're dealing with things like the
preprocessor - because a non-compliant front end won't even know it has
gone off the rails.
There are other issues when
On Wednesday, 17 July 2013 at 15:34:54 UTC, Jacob Carlborg wrote:
On 2013-07-17 13:24, Paulo Pinto wrote:
Thus we are back to the compiler as library discussion.
Yes, but for the C family of languages we already have a
compiler as library, that is Clang.
Agreed.
I also confess that my
On Wednesday, 17 July 2013 at 05:12:00 UTC, Timothee Cour wrote:
what's a non-full C front end? If it's not a real C front end
it's gonna
break with certain macros etc. Not good.
Macro are processed before parsing? No need for a full C frontend
to handle macros.
I see no point in
Possibly instead of 'include' would be better use 'include_C' as
opposed to C++ or any other language.
On Tue, Jul 16, 2013 at 11:01 PM, deadalnix deadal...@gmail.com wrote:
On Wednesday, 17 July 2013 at 05:12:00 UTC, Timothee Cour wrote:
what's a non-full C front end? If it's not a real C front end it's gonna
break with certain macros etc. Not good.
Macro are processed before parsing? No
On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote:
Made a proof of concept to automatically parse, translate and
import C header files in D using DStep. DMD is linked against
DStep and does not start new process to make the translation.
I added a new pragma, include, that handles
On 7/16/2013 10:04 PM, deadalnix wrote:
On Wednesday, 17 July 2013 at 04:14:56 UTC, Walter Bright wrote:
On 7/16/2013 8:49 PM, Timothee Cour wrote:
So how about a library solution instead, which doesn't require compiler change:
While semantically a great idea, technically I don't think CTFE
On 2013-07-17 08:29, angel wrote:
Possibly instead of 'include' would be better use 'include_C' as opposed
to C++ or any other language.
Or there could be an optional argument indicating the language.
pragma(include, foo.h, C);
--
/Jacob Carlborg
On 2013-07-17 07:04, deadalnix wrote:
This is the right path. We don't need the full front end, do we ?
Oh, yes we do. You will always run into corner cases your tool cannot
handle until you have a complete front end. I tried that first, before I
used libclang.
--
/Jacob Carlborg
On 2013-07-16 17:05, Dicebot wrote:
While this a relatively common request, I don't think such stuff belongs
to compiler. It creates extra mandatory dependencies while providing
little advantage over doing this as part of a build system.
I started to think a bit about this. One might need to
On 2013-07-17 10:14, Walter Bright wrote:
Yeah, you do need the full front end. It's pretty amazing how the
simplest of .h files seem determined to exercise every last, dark corner
of the language.
If the converter doesn't accept the full language, you're just going to
get a dump truck
On Wednesday, 17 July 2013 at 09:27:53 UTC, Jacob Carlborg wrote:
On 2013-07-17 10:14, Walter Bright wrote:
Yeah, you do need the full front end. It's pretty amazing how
the
simplest of .h files seem determined to exercise every last,
dark corner
of the language.
If the converter doesn't
On 2013-07-17 13:24, Paulo Pinto wrote:
Thus we are back to the compiler as library discussion.
Yes, but for the C family of languages we already have a compiler as
library, that is Clang.
--
/Jacob Carlborg
On Wednesday, 17 July 2013 at 07:17:07 UTC, Timothee Cour wrote:
you'd still need to parse C files recursively (textual
inclusion...),
handle different C function calling conventions, different C
standards,
you'd need a way to forward to dmd different C compiler options
(include
paths to
On Wednesday, 17 July 2013 at 09:27:53 UTC, Jacob Carlborg wrote:
On 2013-07-17 10:14, Walter Bright wrote:
Yeah, you do need the full front end. It's pretty amazing how
the
simplest of .h files seem determined to exercise every last,
dark corner
of the language.
If the converter doesn't
On 7/17/2013 2:27 AM, Jacob Carlborg wrote:
On 2013-07-17 10:14, Walter Bright wrote:
Yeah, you do need the full front end. It's pretty amazing how the
simplest of .h files seem determined to exercise every last, dark corner
of the language.
If the converter doesn't accept the full language,
On 7/17/2013 9:48 AM, deadalnix wrote:
My understanding is that we only want to convert declaration to D. Can you give
me an example of such corner case that would require the full frontend ?
One example:
On Wed, Jul 17, 2013 at 12:46:54PM -0700, Walter Bright wrote:
On 7/17/2013 9:48 AM, deadalnix wrote:
My understanding is that we only want to convert declaration to D.
Can you give me an example of such corner case that would require the
full frontend ?
One example:
On 7/17/2013 3:20 PM, H. S. Teoh wrote:
Though about trigraphs... I've to admit I've never actually seen *real*
C code that uses trigraphs, but yeah, needing to account for them can
significantly complicate your code.
Building a correct C front end is a known technology, doing a half-baked job
On Wed, Jul 17, 2013 at 03:36:15PM -0700, Walter Bright wrote:
On 7/17/2013 3:20 PM, H. S. Teoh wrote:
Though about trigraphs... I've to admit I've never actually seen
*real* C code that uses trigraphs, but yeah, needing to account for
them can significantly complicate your code.
Building a
On Wednesday, 17 July 2013 at 19:46:54 UTC, Walter Bright wrote:
On 7/17/2013 9:48 AM, deadalnix wrote:
My understanding is that we only want to convert declaration
to D. Can you give
me an example of such corner case that would require the full
frontend ?
One example:
On 7/17/2013 5:31 PM, deadalnix wrote:
On Wednesday, 17 July 2013 at 19:46:54 UTC, Walter Bright wrote:
On 7/17/2013 9:48 AM, deadalnix wrote:
My understanding is that we only want to convert declaration to D. Can you give
me an example of such corner case that would require the full frontend
Made a proof of concept to automatically parse, translate and import C
header files in D using DStep. DMD is linked against DStep and does not
start new process to make the translation.
I added a new pragma, include, that handles everything. Use like this:
// foo.h
void foo ();
// main.d
On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote:
Made a proof of concept to automatically parse, translate and
import C header files in D using DStep. DMD is linked against
DStep and does not start new process to make the translation.
awesome! :-)
On Tuesday, 16 July 2013 at 14:15:55 UTC, Jacob Carlborg wrote:
Made a proof of concept to automatically parse, translate and
import C header files in D using DStep. DMD is linked against
DStep and does not start new process to make the translation.
While this a relatively common request, I
1 - 100 of 243 matches
Mail list logo