Also replace links to wiki.gdcproject.org with wiki.dlang.org.
Ah, wait, D doesn't support source in non-unicode encoding. Try
to place the text in a separate file and import it.
AFAIK, gcc has an option to specify source encoding, maybe gdc
supports it too?
On Friday, 31 January 2014 at 14:16:48 UTC, Mike wrote:
On Friday, 31 January 2014 at 07:52:16 UTC, Iain Buclaw wrote:
Let me know if you need anything else.
Iain.
What are these?
1) http://gdcwin.sourceforge.net/
2) http://gdcmac.sourceforge.net/
3) http://gdcgnu.sourceforge.net/
Are they
C first sign-extends then converts to unsigned. It's just weird
it treats pointer as signed. Was there an option for it?
Reduce it.
Also this getexecname function is a good candidate for
std.process.
On Wednesday, 10 July 2013 at 15:25:02 UTC, Johannes Pfau wrote:
Getting the real application path is not simple and not
portable, but
if you really want to do that:
http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-executable-in-c
http://stackoverflow.com/questions/1023
oops, stdout.
int zero=setvbuf(stdout,null,_IONBF,0);
assert(zero==0);
or
stdio.setvbuf(0,_IONBF);
You can also try to call setvbuf on stdio with _IONBF mode to set
it to non-buffering mode.
On Friday, 29 March 2013 at 13:24:42 UTC, Iain Buclaw wrote:
https://github.com/D-Programming-Language/dmd/pull/1809
lol, put imports after test3.
core.memory.GC.addrOf(dg.ptr);
Are you trying to get stack top?
void test(scope void delegate() dg)
{
int[2] top;
void* p=top.ptr;
assert(p < dg.ptr);
assert(dg.ptr !is null);
//also check that ptr is not in heap
assert(gc_addrOf(dg.ptr) is null);
}
On Friday, 6 April 2012 at 13:00:34 UTC, Joseph Rushton Wakeling
wrote:
Yes, but -- if I understand correctly -- the Waf binary is
provided as an integral part of the source distribution. It's
not just another program that sits elsewhere on your computer
and can be installed independently.
I
Newsgroup link should be http://forum.dlang.org/group/D.gnu
On Monday, 27 February 2012 at 11:10:03 UTC, Kagamin wrote:
Should be a problem, I believe.
I mean, should not be a problem.
On Sunday, 26 February 2012 at 20:54:27 UTC, Johannes Pfau wrote:
The files in libc/glibc/core/stdc would be in the core.stdc
package
(not glib.core.stdc), so we just have to compile the correct
subdirectory into druntime.
The structure seems good, but I still suggest to go through
deimos pro
On Sunday, 26 February 2012 at 13:06:58 UTC, Johannes Pfau wrote:
still have to make sure core.* works.
That's an issue. Given the c libraries incompatibilities, what
functionality the core.stdc should provide? What to do with
functions like backtrace?
deimos
|-glibc
|---stdio.d
|---math.d
|---sys
|-posix
|-bionic
|---stdio.d
|---math.d
|---sys
|-posix
|-dietlibc
|---stdio.d
|---math.d
|---sys
|-posix
Maybe better replicate c library structure?
-x option and extension autodetect if .d doesn't conflict with
dependencies files
On Sunday, 15 January 2012 at 22:34:28 UTC, Iain Buclaw wrote:
* GDC's default calling convention has now been switched back
to that of the default for the target platform. The D_InlineAsm
family of version identifiers are now turned off by default as
we no longer pretend to follow DMD's callin
On Monday, 16 January 2012 at 14:42:08 UTC, Artur Skawina wrote:
As you still cannot easily call D code from C, without the
equivalent of
"extern(D)", why not default to a more sane calling
conventions, such as
regparm on 32-bit x86?
The requirement for this kind of compatibility was simply a
Iain Buclaw Wrote:
> Anyway, yes I believe this would be the expected behaviour. GDC has a slightly
> different strategy than DMD to ensure symbols that are supposed to be only
> linked
> once are done so correctly.
Haha, just by making sure they're always linked? :)
What is this strategy? I me
---
struct BL{int OAT=42;}
BL[1024][64][4] bloat;
void foo()
{
bloat[0][0][0].OAT=1;
}
void goo(){}
---
I compile this file and archive it to a library and then link to another file.
If goo is used, bloat also gets into executable, which is not true for dmd.
Is this expected behavior or
Daniel Green Wrote:
> The Windows driver module, possibly others I'm just familiar with that
> one, may be a good way to think of the problem. Essentially one has
> layers that would give access to an increasing subset of D until you
> reach the full capabilities offered.
>
> bare-metal : D s
25 matches
Mail list logo
