On Monday, 13 January 2014 at 05:25:31 UTC, evilrat wrote:
after about half year i tried it again on OS X, and Mono-D is
quite good for writing the code, but... the debug!!11
can we haz some GDB or LLDB(or both :)) support please? it
shouldn't be that hard porting linux code to OS X. it may
On Monday, 13 January 2014 at 11:03:45 UTC, Alexander Bothe wrote:
On Monday, 13 January 2014 at 05:25:31 UTC, evilrat wrote:
after about half year i tried it again on OS X, and Mono-D is
quite good for writing the code, but... the debug!!11
can we haz some GDB or LLDB(or both :)) support
On 2014-01-13 12:03, Alexander Bothe wrote:
I've got no OSX but erm, what tool is required to have lldb information
generated? ldc2?
On the other side, which tool is then required to get gdb debug info?
With DMD I get the line numbers in a backtrace, both in gdb and lldb. I
compiled with -g.
To everyone: please consider replying in linked discussion thread
if you don't feel like you are going to vote for any reason. So
far activity is rather low and I think I will need some feedback
to determine if it is because of low demand or for some other
reasons.
On Monday, 13 January 2014 at 11:49:57 UTC, evilrat wrote:
On Monday, 13 January 2014 at 11:03:45 UTC, Alexander Bothe
wrote:
On Monday, 13 January 2014 at 05:25:31 UTC, evilrat wrote:
after about half year i tried it again on OS X, and Mono-D is
quite good for writing the code, but... the
On Monday, 13 January 2014 at 05:25:31 UTC, evilrat wrote:
p.s. also, why at first launch it can't just fetch default
phobos
location for DMD? it's quite annoying adding this paths in
settings and it may revolve unaware users from using it(like it
was for me about year ago).
Okay, implemented
On Friday, 10 January 2014 at 17:33:31 UTC, Steve Teale wrote:
I have done more work on the web page to cut out fluff, and to
cover all the composition elements.
There is also a beginning for the description of the user
interfaces.
I lied unwittingly on the web page. I do have the source
On Monday, 13 January 2014 at 17:36:22 UTC, Robert M. Münch wrote:
On 2014-01-13 13:50:09 +, Dicebot said:
To everyone: please consider replying in linked discussion
thread if you don't feel like you are going to vote for any
reason.
Don't understand what you mean... How about
On 2014-01-13 13:50:09 +, Dicebot said:
To everyone: please consider replying in linked discussion thread if
you don't feel like you are going to vote for any reason.
Don't understand what you mean... How about explaining how to vote if
it's not here, or there, ... keep things simple
On Monday, 13 January 2014 at 14:50:05 UTC, Alexander Bothe wrote:
So according to Jacob's comment it's actually possible to get
gdb on OSX - but probably just with a wrong build
configuration, i.e. the mi2 interface for gdb is not available
- or is it? Just try executing gdb --interpreter=mi2
On Tuesday, 14 January 2014 at 04:10:03 UTC, evilrat wrote:
On Monday, 13 January 2014 at 14:50:05 UTC, Alexander Bothe
wrote:
So according to Jacob's comment it's actually possible to get
gdb on OSX - but probably just with a wrong build
configuration, i.e. the mi2 interface for gdb is not
On Tuesday, 14 January 2014 at 04:15:50 UTC, evilrat wrote:
ApplicationName='gdb', CommandLine=-quiet -fullname -i=mi2',
CurrentDirectory=, NativeError= Cannot find the specified file
Okay, I think I'm gonna make a separate option panel then for
setting up the path to gdb.
On Tuesday, 14 January 2014 at 05:04:42 UTC, Alexander Bothe
wrote:
On Tuesday, 14 January 2014 at 04:15:50 UTC, evilrat wrote:
ApplicationName='gdb', CommandLine=-quiet -fullname -i=mi2',
CurrentDirectory=, NativeError= Cannot find the specified file
Okay, I think I'm gonna make a separate
On 13 January 2014 05:01, Manu turkey...@gmail.com wrote:
On 11 January 2014 23:04, Iain Buclaw ibuc...@gdcproject.org wrote:
On 11 January 2014 00:24, Manu turkey...@gmail.com wrote:
On 11 January 2014 06:59, Iain Buclaw ibuc...@gdcproject.org wrote:
On 10 January 2014 20:54, John Colvin
On Saturday, 11 January 2014 at 05:45:41 UTC, H. S. Teoh wrote:
It's not just about custom error messages; it's about picking
up a
particular template signature even when you don't have an
implementation
for it, because logically speaking, your set of overloads
*should* pick
up all such
On Saturday, 11 January 2014 at 20:38:32 UTC, Jacob Carlborg
wrote:
On 2014-01-10 23:16, Joseph Rushton Wakeling wrote:
Yes, but there's a difference between restrictive and
intrusive.
Using GDC doesn't intrude into anything -- the standard
libraries are
still Boost-licensed and simply
On 13 January 2014 08:07, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
On Saturday, 11 January 2014 at 20:38:32 UTC, Jacob Carlborg wrote:
On 2014-01-10 23:16, Joseph Rushton Wakeling wrote:
Yes, but there's a difference between restrictive and intrusive.
Using GDC doesn't
Johannes Pfau wrote:
Am Thu, 09 Jan 2014 19:07:17 +0100
schrieb Piotr Szturmaj bncr...@jadamspam.pl:
Hello,
Answers for GDC:
I'm developing embedded system product on ARM9/Linux platform and I
wish I could use D and vibe.d for this task.
ARMv5 or ARMv4? I tested ARMv5 and that should
On 13/01/14 09:13, Iain Buclaw wrote:
Yah, but s/constraints/freedoms/. :-)
Quite. :-)
On 13 January 2014 09:05, Piotr Szturmaj bncr...@jadamspam.pl wrote:
Johannes Pfau wrote:
Am Thu, 09 Jan 2014 19:07:17 +0100
schrieb Piotr Szturmaj bncr...@jadamspam.pl:
Hello,
Answers for GDC:
I'm developing embedded system product on ARM9/Linux platform and I
wish I could use D and
On Sunday, 12 January 2014 at 10:40:50 UTC, Benjamin Thaut wrote:
Am 12.01.2014 11:27, schrieb Rainer Schuetze:
I think a moving collector is currently not feasible without
restricting
the language a lot, probably similar to safe D and more. I'm
not sure we
want that in general.
Could
On 13/01/14 02:07 , Manu wrote:
What doesn't come across in my posts is that the D experience today is
_so much_ better than it was while I was doing the Remedy work. It's
come a long way in terms of quality in the last 1-2 years, and generally
gets better every day.
I often remark to myself
On Sunday, 12 January 2014 at 00:19:02 UTC, Andrei Alexandrescu
wrote:
https://www.bountysource.com/trackers/383571-d-programming-language
I just checked a few and some are strange.
For example, Issue 1824 - Object not const correct is actually
a meta-issue. The current strategy to fix this,
On 2014-01-13 09:07, Joseph Rushton Wakeling wrote:
Right, but they are not merely using -- they are redistributing (and
distributing derivative works). The GPL places certain constraints
here, I think we can all agree, but it can hardly be described as
intrusive; there's no obligation to base
On 2014-01-13 09:11, Iain Buclaw wrote:
Yes, however Walter has *ehem* ties with Microsoft, so he may have
access to information the Free Software community don't. ;)
It doesn't hurt to ask ;)
--
/Jacob Carlborg
On 2014-01-13 10:20, Rainer Schuetze wrote:
Maybe I'm too pessimistic ;-) I guess moving in general could be ok, I
was thinking about segregating heaps by type (shared/immutable/mutable)
and moving data between them adds restrictions. I'd like to be proven
wrong.
Some thoughts regarding a
On 13 January 2014 20:03, Guido Kollerie gu...@kollerie.com wrote:
On 13/01/14 02:07 , Manu wrote:
What doesn't come across in my posts is that the D experience today is
_so much_ better than it was while I was doing the Remedy work. It's
come a long way in terms of quality in the last 1-2
Iain Buclaw wrote:
QEMU testing is quirky. If your lucky and get it working, don't make
any system changes. :o)
What do you mean exactly?
Saying that, ARM is the only emulation that I've gotten working where
I've actually built GDC ontop of.
For anyone interested:
Here are prebuilt
On Sat, 11 Jan 2014 10:04:44 -, Kagamin s...@here.lot wrote:
On Friday, 10 January 2014 at 00:37:07 UTC, Adam D. Ruppe wrote:
I know there's other win32 bindings we can download, but for just the
common types, I like to use the built in aliases, and TCHAR, TSTR,
etc., are common in
On Fri, 10 Jan 2014 19:47:07 -, H. S. Teoh hst...@quickfur.ath.cx
wrote:
On Sat, Jan 11, 2014 at 02:14:41AM +1000, Manu wrote:
[...]
One more, again here to reduce spam...
2 overloads exist:
void func(const(char)* str);
void func(const(char)[] str);
Called with literal string:
On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:
On 12 January 2014 00:35, Kai Nacke k...@redstar.de wrote:
On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:
This might have been brought up before but I couldn't find
any thread
about this. As things has progressed I wonder
On Sunday, 12 January 2014 at 19:29:08 UTC, sunspyre wrote:
The very reliance of the garbage collector, regardless of how
far between the stop-the-world sweeps are, is a showstopper for
many people. They hear GC and think Java pauses. Being able to
honestly claim well it runs concurrently in a
On Monday, 13 January 2014 at 10:59:44 UTC, Jacob Carlborg wrote:
Could we have a segregated heap for C pointers? Would that
help? Basically having a special function allocating everything
that should interface with C.
Is it possible to declare whether the C-function retains a
pointer to the
I add that it may be helpful for us if you could relay the
information on twitter/reddit :)
Thank you.
On 13 January 2014 21:40, Kai Nacke k...@redstar.de wrote:
On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:
On 12 January 2014 00:35, Kai Nacke k...@redstar.de wrote:
On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:
This might have been brought up before but I couldn't
On Fri, 10 Jan 2014 16:30:12 -, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 1/10/14 6:07 AM, Regan Heath wrote:
On Fri, 10 Jan 2014 08:16:53 -, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 1/9/14 11:56 PM, Jacob Carlborg wrote:
On 2014-01-10 02:34,
On Monday, 13 January 2014 at 12:47:09 UTC, Manu wrote:
Oooohh yeah, this is exciting! :D
How about Win32? That's really important too, particularly
since DMD
doesn't support Win32 :/
You mean the 32 bit MSVC toolchain? SEH support is unlikely to
happen until that Borland patent expires.
On Monday, 13 January 2014 at 12:47:09 UTC, Manu wrote:
On 13 January 2014 21:40, Kai Nacke k...@redstar.de wrote:
On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:
On 12 January 2014 00:35, Kai Nacke k...@redstar.de wrote:
On Friday, 10 January 2014 at 20:51:19 UTC, Dwhatever wrote:
On Monday, 13 January 2014 at 12:59:53 UTC, John Colvin wrote:
On Monday, 13 January 2014 at 12:47:09 UTC, Manu wrote:
On 13 January 2014 21:40, Kai Nacke k...@redstar.de wrote:
On Monday, 13 January 2014 at 05:04:46 UTC, Manu wrote:
On 12 January 2014 00:35, Kai Nacke k...@redstar.de
On Monday, 13 January 2014 at 08:07:42 UTC, Joseph Rushton
Wakeling wrote:
Right, but they are not merely using -- they are redistributing
(and distributing derivative works). The GPL places certain
constraints here, I think we can all agree, but it can hardly
be described as intrusive;
On 2014-01-13 13:53, Regan Heath wrote:
Sure. But, lets take an example: std.algorithm.canFind is more or less
what you might call std.string.contains (which does not exist - instead
we'd use indexOf != -1.. I think).
I think contains is a way better name. That's what most other
languages
On Friday, 10 January 2014 at 14:02:13 UTC, Regan Heath wrote:
IIRC wchar_t is actually UCS-2 (called Multibyte by devenv and
various functions) which is a sub-set of UTF-16. So, calling a
windows W function with wchar[] could also break.. just in far
fewer cases than char[] with A
On Sunday, 12 January 2014 at 00:19:02 UTC, Andrei Alexandrescu
wrote:
I've placed on behalf of Facebook a few more bounties on
D-related issues.
There are interesting research done on such topics:
http://freakonomics.com/2013/06/05/is-paying-for-blood-a-good-idea-after-all/1
In Freakonomics,
On Mon, 13 Jan 2014 13:37:54 -, Olivier Pisano
olivier.pis...@laposte.net wrote:
On Friday, 10 January 2014 at 14:02:13 UTC, Regan Heath wrote:
IIRC wchar_t is actually UCS-2 (called Multibyte by devenv and various
functions) which is a sub-set of UTF-16. So, calling a windows W
On 1/13/14 2:22 AM, qznc wrote:
On Sunday, 12 January 2014 at 00:19:02 UTC, Andrei Alexandrescu wrote:
https://www.bountysource.com/trackers/383571-d-programming-language
I just checked a few and some are strange.
For example, Issue 1824 - Object not const correct is actually a
meta-issue.
On 1/13/14 7:50 AM, bearophile wrote:
On Sunday, 12 January 2014 at 00:19:02 UTC, Andrei Alexandrescu wrote:
I've placed on behalf of Facebook a few more bounties on D-related
issues.
There are interesting research done on such topics:
On Sunday, 12 January 2014 at 12:48:05 UTC, Tobias Pankrath wrote:
On Saturday, 11 January 2014 at 21:42:46 UTC, Dmitry Olshansky
wrote:
12-Jan-2014 01:22, monarch_dodra пишет:
And it's indeed quite high, the amount of bad sheep that
gets longer/shorter across the whole Unicode is around 5-10
On Monday, 13 January 2014 at 17:45:26 UTC, Dmitry Olshansky
wrote:
How would it be expensive? I don't see a need to do anything to
pin a memory block, at the time of scanning there will be a
potential pointer to it (in the stack space of C function or
registers).
How do you know that it is
13-Jan-2014 13:20, Rainer Schuetze пишет:
On Sunday, 12 January 2014 at 10:40:50 UTC, Benjamin Thaut wrote:
Am 12.01.2014 11:27, schrieb Rainer Schuetze:
I think a moving collector is currently not feasible without restricting
the language a lot, probably similar to safe D and more. I'm not
13-Jan-2014 21:49, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com пишет:
On Monday, 13 January 2014 at 17:45:26 UTC, Dmitry Olshansky wrote:
How would it be expensive? I don't see a need to do anything to pin
a memory block, at the time of scanning there will be a potential
pointer to
07-Nov-2013 17:45, Dicebot пишет:
Time to move forward with some more reviews :)
Our current victim is std.signal by Robert Klotzner which is supposed to
deprecate and supersede existing (and broken) std.signals
[snip]
If there are any frequent Phobos contributors / core developers
please
On Monday, 13 January 2014 at 09:20:16 UTC, Rainer Schuetze wrote:
Maybe I'm too pessimistic ;-) I guess moving in general could
be ok, I was thinking about segregating heaps by type
(shared/immutable/mutable) and moving data between them adds
restrictions. I'd like to be proven wrong.
I
On Monday, 13 January 2014 at 17:56:12 UTC, Dmitry Olshansky
wrote:
Precisely. Since C space has no type information you have to
conservatively assume that everything can be a pointer.
I think we are misunderstanding each other? I don't think a Boehm
style GC can do compaction, since you
…and scanning of C data segments is insufficient anyway, since
protected drivers can retain pointers that are out of reach...
On 1/12/2014 2:40 AM, Benjamin Thaut wrote:
Am 12.01.2014 11:27, schrieb Rainer Schuetze:
I think a moving collector is currently not feasible without restricting
the language a lot, probably similar to safe D and more. I'm not sure we
want that in general.
Could you give an example which
On 1/13/14 12:44 PM, Walter Bright wrote:
On 1/12/2014 2:40 AM, Benjamin Thaut wrote:
Am 12.01.2014 11:27, schrieb Rainer Schuetze:
I think a moving collector is currently not feasible without restricting
the language a lot, probably similar to safe D and more. I'm not sure we
want that in
13-Jan-2014 22:44, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com пишет:
On Monday, 13 January 2014 at 17:56:12 UTC, Dmitry Olshansky wrote:
Precisely. Since C space has no type information you have to
conservatively assume that everything can be a pointer.
I think we are
13-Jan-2014 22:56, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com пишет:
…and scanning of C data segments is insufficient anyway, since protected
drivers can retain pointers that are out of reach...
A stack is a stack is a stack.
Not that D haven't had problem with hidden pointers
On 1/13/2014 12:57 PM, Brad Roberts wrote:
The key advantage that moving gives to a GC is to allow it to have a block of
memory that it can do allocations out of by simply bumping the pointer. When
that region is full, a minor collection kicks in, moving anything still alive
out to a different
On Monday, 13 January 2014 at 18:16:33 UTC, Dmitry Olshansky
wrote:
2. When I needed something remotely like that I'll do just fine
with array of delegates.
It's not so good to have array of delegates because you will have
a memory leaks. Delegate has permanent pointer to the object, so
GC
On Monday, 13 January 2014 at 21:08:50 UTC, Dmitry Olshansky
wrote:
So what? It can't move it and as such there is nothing special
about it, it doesn't _cost_ anything to pin object.
Well, the advantage of compaction is that you (in theory) can
relocate objects so that you:
1. get temporal
On 01/13/2014 10:08 PM, Dmitry Olshansky wrote:
13-Jan-2014 22:44, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com пишет:
On Monday, 13 January 2014 at 17:56:12 UTC, Dmitry Olshansky wrote:
Precisely. Since C space has no type information you have to
conservatively assume that
Am 13.01.2014 18:45, schrieb Dmitry Olshansky:
13-Jan-2014 13:20, Rainer Schuetze пишет:
Maybe I'm too pessimistic ;-) I guess moving in general could be ok, I
was thinking about segregating heaps by type (shared/immutable/mutable)
and moving data between them adds restrictions. I'd like to be
Am 13.01.2014 21:44, schrieb Walter Bright:
A moving GC is already supported by D's semantics.
Unions are dealt with by 'pinning' those objects, i.e. simply don't move
them. I know this can work because I implemented a mostly copying
generational collector years ago for Java. (After I
On 01/13/2014 10:11 PM, Walter Bright wrote:
Not to say there aren't other ways of doing things, but with random
objects
becoming pinnable puts a big damper on things unless you can identify
all the
objects that might be pinned and isolate them. But I doubt that's really
knowable up front.
Am 13.01.2014 22:31, schrieb Timon Gehr:
On 01/13/2014 10:11 PM, Walter Bright wrote:
Not to say there aren't other ways of doing things, but with random
objects
becoming pinnable puts a big damper on things unless you can identify
all the
objects that might be pinned and isolate them. But I
In theory you could use a region allocator for a pure function
and copy its result out.
This wouldn't be worth it in the general case but imagine worker
threads in a task pool. Pure functions executing message
in/message(s) out that did not significantly contribute to the
stop the world GC
On 01/11/14 03:30, Rainer Schuetze wrote:
On 10.01.2014 22:42, Andrei Alexandrescu wrote:
[snip]
std.emplace will continue to work as a way to build an object at a
specified address. I suspect that allocating and manipulating objects on
the GC heap in particular may have certain
On 1/13/2014 1:28 PM, Benjamin Thaut wrote:
Am 13.01.2014 21:44, schrieb Walter Bright:
A moving GC is already supported by D's semantics.
Unions are dealt with by 'pinning' those objects, i.e. simply don't move
them. I know this can work because I implemented a mostly copying
generational
Benjamin Thaut:
I would prefer a option where the user can specifiy a function
to scan classes / structs that contain unions percisely instead
of pinning it.
In generall I would want a option to specify a manual scanning
function for any block of GC managed memory, D is a systems
programming
On 01/13/2014 11:05 PM, Paulo Pinto wrote:
Am 13.01.2014 22:31, schrieb Timon Gehr:
On 01/13/2014 10:11 PM, Walter Bright wrote:
Not to say there aren't other ways of doing things, but with random
objects
becoming pinnable puts a big damper on things unless you can identify
all the
objects
Hi
I'm a new contributor to this site - I'm trying D out, and liking
it a lot. Though I'm new to D, my background is in computer
graphics, so I'm excited to see graphics capabilities being
discussed, and I thought I'd add my two-penneth.
Firstly, there seems to be disagreement on exactly
On Mon, 13 Jan 2014 15:46:42 -0800, Matt Taylor taylor...@gmail.com
wrote:
Hi
I'm a new contributor to this site - I'm trying D out, and liking it a
lot. Though I'm new to D, my background is in computer graphics, so I'm
excited to see graphics capabilities being discussed, and I thought
Hello! I didn't really know if I should post here or not but I
decided I should try. I recently started reading up on the IRC
protocol and thought I would try to mess with it a bit and see if
I could implement a server with a few features, just for fun. I'm
already having trouble...
(I'm
Perhaps this was in the wrong section, sorry about that.
On Tuesday, 14 January 2014 at 03:42:29 UTC, APott wrote:
byte[] buffer;
client.receive(buffer);
These lines are wrong: receive needs a pre-allocated buffer with
a certain size and it tries to fill it. Also generally ubyte is
better for this than byte.
ubyte[1024] buffer;
auto got=
Wow, that's actually incredibly embarrassing... I can't believe I
didn't notice this, I knew I was missing something simple.
Thanks for the help Adam!
On 2014-01-12 21:13, Jesse Phillips wrote:
The main issue is that arr.length is size_t, I thought that that it
would be wise not to go against the grain, but I had to back out some of
those changes, since in reality it seems that gtk seems to expect
count/length in int (I've squashed the
On 2014-01-13 10:58, Jacob Carlborg wrote:
I'm using this philosophy when I'm porting SWT to D. In prioritizing order:
1. The public API needs to be the same on all platforms and preferably
as the Java API.
2. The types and signatures should match the native ones. That means, if
the native
Hi yes I think noticed in another thread that you were wrapping
Qt with dynamic loading of the qt libs, interesting idea - does
your code allow subclassing of the Qt classes and overriding
the virtual methods? I'm taking a much more traditional
approach, but there is method in my madness :-)
On 2014-01-12 19:47, Gary Willoughby wrote:
When using Win32/x86 in a version block, does that relate to the
compiler or OS?
for example:
version(Win32)
{
// 32bit Windows or 32bit Compiler?
}
Microsoft 32-bit Windows systems
version(X86)
{
// 32bit OS or 32bit Compiler?
}
On Sun, 2014-01-12 at 19:11 +, Adam D. Ruppe wrote:
[…]
enum version = import(VERSION);
// use it now like any other string in D
Calling a string an enum seemed discordant, and version is sort of a
reserved word (at least as far as Emacs D-Mode colorizing is concerned)
so in the end I
On Sunday, 12 January 2014 at 20:16:15 UTC, Nordlöw wrote:
Is there a trait to check whether a type has value or reference
semantics?
I need this in a template struct that adaptively (using static
if) represent histogram bins as either a dense static array or
a sparse associative array.
On Sunday, 12 January 2014 at 20:16:15 UTC, Nordlöw wrote:
Is there a trait to check whether a type has value or reference
semantics?
I need this in a template struct that adaptively (using static
if) represent histogram bins as either a dense static array or
a sparse associative array.
On Monday, 13 January 2014 at 11:39:02 UTC, Russel Winder wrote:
Calling a string an enum seemed discordant
Slightly off-topic but I should mention that in D enums are not
just enumerations but any compile-time constants and used
idiomatically that way.
On Monday, 13 January 2014 at 11:39:02 UTC, Russel Winder wrote:
immutable auto versionNumber = strip(import(VERSION));
The auto doesn't do anything in this case, as immutable is a
storage class and hence implies auto. It might be better to write:
static immutable versionNumber = ...
On Sunday, 12 January 2014 at 20:16:15 UTC, Nordlöw wrote:
Is there a trait to check whether a type has value or reference
semantics?
I need this in a template struct that adaptively (using static
if) represent histogram bins as either a dense static array or
a sparse associative array.
Hi There,
I am playing around CTFE, and I get different compile time
behavior with the reference compiler (both 64-bit Linux):
DMD64 D Compiler v2.064
and the LLVM compiler:
LDC - the LLVM D compiler (37ee99): based on DMD v2.063.2
and
LLVM 3.3
The code snippet at the bottom of
If you just want to check if specifically it's a structure, you could
always check `__traits(compiles, T()) if(typeof(T()) == T)` beware
however that this will evaluate to true if T is a class with a static
opCall who's return type is T.
On 1/13/14, Tobias Pankrath tob...@pankrath.net wrote:
On
On Monday, 13 January 2014 at 13:41:30 UTC, Orvid King wrote:
If you just want to check if specifically it's a structure, you
could
always check `__traits(compiles, T()) if(typeof(T()) == T)`
beware
however that this will evaluate to true if T is a class with a
static
opCall who's return
On Monday, 13 January 2014 at 13:37:05 UTC, Ben Cumming wrote:
Hi There,
I am playing around CTFE, and I get different compile time
behavior with the reference compiler (both 64-bit Linux):
DMD64 D Compiler v2.064
and the LLVM compiler:
LDC - the LLVM D compiler (37ee99): based on
On Monday, 13 January 2014 at 13:41:30 UTC, Orvid King wrote:
If you just want to check if specifically it's a structure, you
could
always check `__traits(compiles, T()) if(typeof(T()) == T)`
beware
however that this will evaluate to true if T is a class with a
static
opCall who's return
On Monday, 13 January 2014 at 13:46:26 UTC, Dicebot wrote:
This is the answer. Current LDC is still based on 2.063.2
version of frontend. There have been several tweaks in
`std.conv` to make `to` more pure-friendly between those two
releases.
Thanks! I will recompile the latest version of
On Monday, 13 January 2014 at 14:18:49 UTC, Ben Cumming wrote:
On Monday, 13 January 2014 at 13:46:26 UTC, Dicebot wrote:
This is the answer. Current LDC is still based on 2.063.2
version of frontend. There have been several tweaks in
`std.conv` to make `to` more pure-friendly between those
On 1/13/14, anonymous anonym...@example.com wrote:
On Monday, 13 January 2014 at 13:41:30 UTC, Orvid King wrote:
If you just want to check if specifically it's a structure, you
could
always check `__traits(compiles, T()) if(typeof(T()) == T)`
beware
however that this will evaluate to true
On Sunday, 12 January 2014 at 18:36:19 UTC, Russel Winder wrote:
With C++ and Python, it is idiomatic to put the application
version
number in a separate file that can then be processed by the
build
system. For C++ a config file is constructed defining a macro
that is
then used in the rest of
Maxim Fomin:
as well as more sophisticated nonsense. Issue is filed is
bugzilla, so it will be fixed sooner or latter, current policy
is to ignore it.
See also:
https://d.puremagic.com/issues/show_bug.cgi?id=3934
Bye,
bearophile
On Monday, 13 January 2014 at 14:32:03 UTC, Dicebot wrote:
I don't think 2.064 LDC has been released yet
So I see, thanks.
On Monday, 13 January 2014 at 15:12:21 UTC, Ben Cumming wrote:
On Monday, 13 January 2014 at 14:32:03 UTC, Dicebot wrote:
I don't think 2.064 LDC has been released yet
So I see, thanks.
The merge-2.064 branch in Git is stable enough already for most
purposes, so if you don't mind building
On Thursday, 2 January 2014 at 20:38:10 UTC, Jeroen Bollen wrote:
Is it good to re-seed a generator for every coordinate, will
this be performance intensive? Is there maybe way to easily
implement Generator.at(uint x) in D?
1 - 100 of 173 matches
Mail list logo
