On Monday, 10 April 2017 at 23:27:35 UTC, Walter Bright wrote:
The next problem is that dmd occasionally changes the interface
to the D runtime. […] I also do not know how the gdc/lds
druntime
interfaces differ.
Just to make this very clear to everybody reading this thread:
It's not even
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
Recompiling the dependency-chain of a software from source when
compiling a package using the "right" compiler and statically
adding the code is forbidden by distro policy.
Yet, from what I could find after a brief search, the
On Monday, 10 April 2017 at 17:27:28 UTC, Matthias Klumpp wrote:
That's why I have been writing a lot of Makefiles and Meson
build definitions lately.
It seems like doing so without having a closer look at the
realities of D software (no stable ABI, etc.) might not have been
the best use of
On Monday, 10 April 2017 at 17:50:08 UTC, Matthias Klumpp wrote:
I am reading release notes, so we rebuilt dependencies of LDC -
(I assume you mean reverse dependencies.)
[…] But since no bugs were reported, I assume no issues are
present :-)
So do we need to put a reminder about the ABI
On Monday, 10 April 2017 at 20:43:06 UTC, Iain Buclaw wrote:
Master sports Phobos 2.071. Someone will have to see whether
latter versions can be built using it.
… and some weird Frankensteinian mix of several frontend
versions, I take it, maybe enough to build Phobos, but not
necessarily
On Sunday, 9 April 2017 at 14:47:39 UTC, Jonathan Marler wrote:
My guess is that making Socket a class prevents socket handle
leaks because you can clean up the handle in the destructor
when the memory gets freed if no one closes it. Is this the
reason it is a class and are there any other
On Friday, 7 April 2017 at 22:57:39 UTC, Walter Bright wrote:
Thanks for pointing that out, I didn't know that. I just
assumed LDC would have gone with a clang-style inline assembler
(does clang even have inline asm?).
LDC supports both DMD-style asm {} blocks as well as LLVM's
native inline
On Friday, 7 April 2017 at 21:49:22 UTC, Walter Bright wrote:
Note that this also resolves the long-standing legal issue with
D's inline assembler being backend licensed, and so not
portable to gdc/ldc.
Just to clarify for people not usually frequenting these circles:
LDC does support
On Friday, 7 April 2017 at 17:06:31 UTC, Russel Winder wrote:
If anyone has any useful intelligence as to what happening and
how I
can workaround it, I'd be a grateful bunny.
You might want to check with LDC from Git master first to see
whether it is in fact a 2.073-related problem. — David
On Wednesday, 5 April 2017 at 16:33:42 UTC, Guillaume Piolat
wrote:
This means TLS is here but uninitialized and eg. core.cpuid has
to be duplicated.
Fragmentation ensues.
You can still lazily initialise TLS data, though. — David
On Wednesday, 5 April 2017 at 14:35:18 UTC, Guillaume Piolat
wrote:
But those of us with the runtime disabled don't have TLS.
This is only true on DMD/OS X x86, where TLS is emulated in
druntime. On other platforms, TLS is implemented by the linker
and/or C runtime, so it works without
On Monday, 3 April 2017 at 21:00:53 UTC, Walter Bright wrote:
The idea of this proposal is to make a nogc program much more
achievable. Currently, in order to not link with the GC, you
can't use exceptions (or at least not in a memory safe manner).
A solution without memory safety is not
On Sunday, 2 April 2017 at 10:55:22 UTC, Johan Engelen wrote:
a ~ "abc" "def";
If the order is important, make it `a ~ ("abc" ~ "def")` instead.
I'd argue that with concatenation usually being left-associative,
clearly stating the intention to evaluate the side first would be
a good idea
On Saturday, 18 March 2017 at 00:34:57 UTC, XavierAP wrote:
Is this a known issue with D on GitHub? Should I report it I
guess?
How smart is GH that it doesn't look at the file extension?
What happened?
The extension .d can legitimately refer to makefiles as well
(specifically, to dependency
On Wednesday, 15 March 2017 at 09:19:17 UTC, Jack Applegame wrote:
I think that fixing such bugs is quite general interest. I'm
not asking to do enhancement required solely to me. I'm asking
to fix a bug, very bad bug.
The reason why your post is not appropriate here is in the name
of the
On Wednesday, 15 March 2017 at 07:37:53 UTC, Jack Applegame wrote:
Dear developers. I need help fixing issue #17257
(https://issues.dlang.org/show_bug.cgi?id=17257) and related
bug
(https://forum.dlang.org/post/zpxzbctiijfhjujsz...@forum.dlang.org).
This is a forum for announcements of
On Monday, 6 March 2017 at 02:20:02 UTC, Deech wrote:
[…] add pattern matching to the language as a macro.
D doesn't have macros per se. However, template metaprogramming
and mixins can replace them in many cases.
Which particular form of pattern matching do you have in mind?
You won't get
On Sunday, 5 March 2017 at 15:30:29 UTC, Andrei Alexandrescu
wrote:
Another good thing pointed by the article would be to use the
Mersenne twister for unpredictableSeed, which would make it
difficult to infer the sequence from a few samples. Please
share if that would be a good thing to do.
On Friday, 3 March 2017 at 18:11:29 UTC, deadalnix wrote:
https://issues.dlang.org/show_bug.cgi?id=17236
Coming to you on ubuntu soon.
I'm pretty sure that would still work with LDC. So not exactly
"nothing". ;)
– David
On Monday, 27 February 2017 at 17:13:24 UTC, Seb wrote:
A solution for the moment is to point people at the ddoc
version, e.g.
https://dlang.org/phobos/std_algorithm_comparison.html#.among
Sure, linking only that would definitely work. — David
On Monday, 27 February 2017 at 15:41:18 UTC, Seb wrote:
Is it redditable?
Yes, finally :)
Can we fix the fact that the docs are duplicated for template
functions before any big announcements? See e.g.
https://dlang.org/library-prerelease/std/algorithm/comparison/among.html from above. This
On Wednesday, 22 February 2017 at 08:20:41 UTC, Jonathan M Davis
wrote:
Well, the OP's code wrapped the Thread object in another class
and joined the thread in its finalizer, so you would think that
the Thread would be joined before its finalizer was called, but
thinking further on it, IIRC,
On Wednesday, 22 February 2017 at 07:14:27 UTC, Jonathan M Davis
wrote:
In this particular case, the program would probably exit if you
did
void main()
{
{
auto a = new A;
}
import core.memory;
GC.collect();
}
I very much doubt so. A Thread object isn't just a handle
On Thursday, 9 February 2017 at 17:16:35 UTC, Joseph Rushton
Wakeling wrote:
This package should be possible to install on Ubuntu 16.04 or
later, or Ubuntu 14.04, as well as any other distro making
available a recent version of snapd (2.21 or later):
https://snapcraft.io/docs/core/install
Hi all,
This year's FOSDEM is taking place Saturday–Sunday in Brussels
(registration-less open source software event).
Any D heads in the area? Kai Nacke is going to give a talk on PGO
in LDC in the LLVM dev room [1], and I'll also be around.
— David
[1]
On Thursday, 2 February 2017 at 16:08:37 UTC, Profile Anaysis
wrote:
Should be something like […]
Thanks for the suggestion. However, please use
https://issues.dlang.org for bug reports and enhancement
requests. They will just get lost here on the NG.
— David
On Thursday, 2 February 2017 at 09:28:15 UTC, Walter Bright wrote:
I seem to recall Valgrind wasn't on OSX, either, at one point.
Maybe that has since been corrected.
It nominally works on 10.10, if I recall correctly, but not to
the same standard as on Linux.
For C/C++, a combination of
Hi all,
Version 1.1.0 of LDC, the LLVM-based D compiler, has finally been
released:
https://github.com/ldc-developers/ldc/releases/tag/v1.1.0
Please head over to the digitalmars.D.ldc forums for more details
and discussions:
http://forum.dlang.org/post/etynfqwjosdvuuukl...@forum.dlang.org
On Wednesday, 25 January 2017 at 22:59:55 UTC, Jonathan M Davis
wrote:
Yes, but my point is that you're normally only going to use
.ptr to pass something to a C function, and even if you're
doing more with it in D, odds are, you're going to be doing
pointer arithmetic.
Wrong again. If this
On Wednesday, 25 January 2017 at 22:54:32 UTC, Adam D. Ruppe
wrote:
On Wednesday, 25 January 2017 at 22:46:10 UTC, David Nadlinger
wrote:
This is because every pointer in SafeD is dereferencable.
But null pointers are allowed in SafeD and arr.ptr is either
arr[0] or null
This is a
On Wednesday, 25 January 2017 at 18:12:18 UTC, Jonathan M Davis
wrote:
Fine, but in the vast majority of cases, you're calling .ptr,
because you're going to be passing the pointer to C code, in
which case, doing [0] buys you very little, since the C
code is inevitably going to be reading more
On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis
wrote:
It seems _slightly_ better from a safety perspective but only
slightly.
Wrong – one is correct, the other is not. This is because every
pointer in SafeD is dereferencable. Pointer arithmetic is not
allowed in SafeD, so your
On Monday, 23 January 2017 at 19:56:33 UTC, Johan Engelen wrote:
Great! :-)
Keep me in the loop when preparing your slides! ;-)
Glad to help out in any way as well. I might also make it to
FOSDEM myself this year, but that's not quite sure yet.
— David
On Monday, 23 January 2017 at 17:42:00 UTC, Stefan Koch wrote:
interpret3.d passes!!!
The only remaining issues that cause miscompiled code are
UTF(8/16/32) encoding and decoding issues.
Is that without bailing out?
— David
On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:
I'd say start with DMD, as it comes practically free of
dependencies […]
The same applies to LDC. If you want, you can use the
self-contained binary releases, which just require the system
linker to be present, like DMD does.
On Friday, 14 October 2016 at 13:07:10 UTC, Johan Engelen wrote:
On Friday, 14 October 2016 at 12:55:17 UTC, Guillaume Piolat
wrote:
- this pointer is aligned to N bytes
- this pointer doesn't alias with this pointer
Do you mean these as "just a hint, should not generate invalid
code if not
On Tuesday, 11 October 2016 at 15:08:34 UTC, Andrei Alexandrescu
wrote:
Looked at this, still seems to generate a jump forward with ldc.
ldc.intrinsics.llvm_expect might help to influence basic block
layout.
— David
On Monday, 3 October 2016 at 02:47:09 UTC, Manu wrote:
On 3 October 2016 at 02:37, Timon Gehr via Digitalmars-d
This is a known issue:
https://issues.dlang.org/show_bug.cgi?id=3720
(What I do is: typeof((this).f) is int delegate(), but
auto x =
does not compile as the 'this' reference is
On Sunday, 2 October 2016 at 22:25:14 UTC, Nordlöw wrote:
Where is it?
https://github.com/CyberShadow/digger
— David
On Friday, 30 September 2016 at 14:02:36 UTC, Manu wrote:
Perfect! How can we protect against this going stale?
Don't; just use `ldc2 -help`. This is the perfect example of a
problem that doesn't need a solution. Downloading and extracting
the binary package (or installing the distro
On Thursday, 29 September 2016 at 13:58:44 UTC, Eugene Wissner
wrote:
Any chance to get this one working:
import std.typecons;
enum Stuff
{
asdf,
}
void main()
{
BitFlags!Stuff a;
mixin(__traits(fullyQualifiedName, typeof(a)) ~ " c;");
}
This wouldn't be a correct
On Thursday, 29 September 2016 at 01:33:00 UTC, Joel wrote:
Oops, I got confused and installed with homebrew. I was going
to try DVM.
Jacob is also the author of DVM, so he might be a bit biased. ;)
I've had good experiences using Homebrew, although you sometimes
have to wait a day or three
On Tuesday, 27 September 2016 at 10:46:23 UTC, Johan Engelen
wrote:
On Monday, 26 September 2016 at 23:32:05 UTC, Walter Bright
wrote:
Linking C libraries and object code into D programs has always
worked easily in D. The other way around, not so well.
[snip]
How much of an issue is this
On Wednesday, 14 September 2016 at 22:48:29 UTC, Pierre Krafft
wrote:
I've had to use fullyQualifiedName in some string mixins.
Unless there is more to the example than what meets the eye, "had
to" isn't quite true, and even with the `import moduleName!…`
hack, your code is still
On Wednesday, 14 September 2016 at 12:13:58 UTC, Seb wrote:
You should try -static in ldc, it's works like a dream for me :)
Yep, LDC supports fully static linking on Linux (and is currently
the only compiler to do so).
— David
On Sunday, 11 September 2016 at 11:33:14 UTC, Dicebot wrote:
On Sunday, 11 September 2016 at 08:37:56 UTC, deadalnix wrote:
On Sunday, 11 September 2016 at 06:09:01 UTC, Dicebot wrote:
Presence of compile-time valid T.init for any type T is
absolutely critical for generic programming and must
On Saturday, 3 September 2016 at 12:22:25 UTC, thedeemon wrote:
On Friday, 2 September 2016 at 14:55:26 UTC, jmh530 wrote:
Anyway, with @safe unions, my thinking is that it would mean
that the garbage collector can be made precise in @safe code
in a way that it can't in @system code (assuming
On Saturday, 3 September 2016 at 22:39:22 UTC, Walter Bright
wrote:
Because it's useless to anyone but the compiler devs, and it
adds cruft to the compiler. And even worse than useless, it
confuses the user into thinking it is a meaningful message.
This is short-sighted, for the reason I
On Sunday, 4 September 2016 at 17:37:28 UTC, David Nadlinger
wrote:
In this case, it's seems to be a race condition between Travis
trying to check out the branch to test, and GitHub actually
serving it up (or you removing it again).
Oh, wait, this is on a branch in the main dlang repo, as
On Sunday, 4 September 2016 at 14:46:56 UTC, Andrei Alexandrescu
wrote:
Can we do the same? How can we make sure that a Travis failure
always is legit and needs action?
In this case, it's seems to be a race condition between Travis
trying to check out the branch to test, and GitHub actually
On Sunday, 4 September 2016 at 12:37:47 UTC, David Nadlinger
wrote:
Do we, though? It's easy to state a general claim like this,
but I find it hard to actually justify.
(And to pre-empt the collective freak-out, note that this
statement is coming from somebody who has done quite a bit of
On Sunday, 4 September 2016 at 12:33:07 UTC, Andrei Alexandrescu
wrote:
Thanks for answering. Yes, we really need introspection of
private members. One way or another we need to support that.
Do we, though? It's easy to state a general claim like this, but
I find it hard to actually justify.
On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote:
Based on that experience I have now implemented another pseudo
function called __ctfeTicksMs.
[…]
Please tell me what you think.
Please don't. This makes CTFE indeterministic.
To write performance tests, just measure compilation
On Saturday, 3 September 2016 at 14:40:37 UTC, Martin Nowak wrote:
Yes, it does help. As private prevents usage outside of a
module it allows to do some optimizations that required whole
program analysis otherwise, e.g. variables and functions can
get internal linkage, thus reducing
On Friday, 2 September 2016 at 22:12:20 UTC, Walter Bright wrote:
Compiling with -v will usually show how far the compiler got.
It's curious that this topic should come up now – just a couple
of days ago, I thought about adding better user reporting for LDC
ICEs.
What I was planning to do
On Friday, 2 September 2016 at 12:15:25 UTC, Manu wrote:
D doesn't seem to have this, and that is proving to be quite
problematic. What's the work around?
Somehow pass in the required information along with the symbol,
for example as a member function/alias or an UDA. It's hard to
get more
On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:
On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
std.traits wrappers should use __traits to build *safe* things
(declaring that @trusted in the end).
This has nothing to do with memory safety.
Actually it does, albeit
On Thursday, 1 September 2016 at 21:48:41 UTC, Rory McGuire wrote:
I was hoping that the error was coming from the CTFE engine as
it ran the code, but it comes up before ctfe execution I guess.
As a general comment, there is no such thing as a CTFE phase. It
is performed in-line with other
On Thursday, 1 September 2016 at 21:01:46 UTC, Rory McGuire wrote:
I'm actually asking why we can't catch the ctfe error.
You can, by using __traits(compiles, …).
Surely the ctfe engine could be changed to catch unsupported
code errors. (Not invalid, just unsupported at CT).
It already
On Thursday, 1 September 2016 at 19:38:13 UTC, Stefan Koch wrote:
I have something that will help with that a little bit.
https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln
when you apply this patch __ctfeWriteln() will output every
compiletime avilable string to the console.
More
On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
So why can't we even catch the Error during CTFE, that would at
least help somewhat.
You are mixing up runtime exceptions ("throw …") with compiler
errors (missing a semicolon). dm.D.learn should be able to help
clear that
On Thursday, 1 September 2016 at 16:43:53 UTC, Rory McGuire wrote:
is that in one of the "semantic" passes the compiler has?
For reference, I've laid out the reasons why this proposal
couldn't work to Stefan here:
https://github.com/dlang/dmd/pull/6098#issuecomment-243375543
The real
On Wednesday, 31 August 2016 at 12:45:14 UTC, Ethan Watson wrote:
But in this case, because instantiation happens within the
scope of the binderoo.typedescriptor module instead of within
the scope of the module the template is invoking from, it just
can't see my new CTypeNameOverride
On Monday, 29 August 2016 at 10:20:56 UTC, rikki cattermole wrote:
By the looks you're not running the tests more then once.
Druntime initialization could be effecting this.
Please execute each test (without memory allocation) 1
times atleast and then report back what they are.
D program
On Sunday, 28 August 2016 at 21:52:48 UTC, Illuminati wrote:
Also D doesn't seem to have a volitile keyword anymore which is
required to prevent the compiler from prematurely optimizing
critical code.
It isn't. In fact, using volatile to achieve thread
synchronisation (seeing as this is what
On Saturday, 27 August 2016 at 17:47:33 UTC, Dicebot wrote:
But actual value of that Regex struct is perfectly known during
compile time. Thus it is possible and fine to use it as
initializer. You can use any struct or class as initializer if
it can be computed during compile-time.
Yes,
On Thursday, 25 August 2016 at 20:31:59 UTC, John Burton wrote:
I'll try to get a self contained report tomorrow.
Please do – the -deps switch is certainly not the most
well-tested part of LDC. It mostly inherits this part of the code
from DMD, but there might be a subtle, unintentional
On Sunday, 21 August 2016 at 14:57:15 UTC, Seb wrote:
An alternative would be to compile your application locally,
then copy it over to your container. I don't know how similar
CoreOs to a typical Linux distribution is, but if it comes with
the typical shared libraries (libm.so, libc.so,
On Sunday, 21 August 2016 at 11:38:09 UTC, Suliman wrote:
I would like to create small VPS instance with Linux distrib on
VPS. Can I use CoreOS as image? Would it possible to install
dlang there?
For LDC, you can just download the latest release from
On Friday, 19 August 2016 at 15:47:00 UTC, ag0aep6g wrote:
https://dlang.org/spec/property.html#stringof
Someone should edit that, if fullyQualifiedName is no good
either.
Indeed. I'm sure the change was well-intentioned, but symbol
visibility/import concerns and Voldemort types should make
On Friday, 19 August 2016 at 15:15:55 UTC, ag0aep6g wrote:
I think that qualifies as a bug, because fullyQualifiedName is
supposed to be usable in code generation.
This is a misconception. Neither .stringof nor fullyQualifiedName
should *ever* be used in code generation. There is a myriad of
On Saturday, 6 August 2016 at 21:56:06 UTC, Walter Bright wrote:
Let me rephrase the question - how does fusing them alter the
result?
There is just one rounding operation instead of two.
Of course, if floating point values are strictly defined as
having only a minimum precision, then
On Saturday, 6 August 2016 at 09:35:32 UTC, Walter Bright wrote:
The LDC fastmath bothers me a lot. It throws away proper NaN
and infinity handling, and throws away precision by allowing
reciprocal and algebraic transformations.
This is true – and precisely the reason why it is actually
On Saturday, 6 August 2016 at 12:48:26 UTC, Iain Buclaw wrote:
There are compiler switches for that. Maybe there should be
one pragma to tweak these compiler switches on a per-function
basis, rather than separately named pragmas.
This might be a solution for inherently compiler-specific
On Saturday, 6 August 2016 at 10:02:25 UTC, Iain Buclaw wrote:
No pragmas tied to a specific architecture should be allowed in
the language spec, please.
I wholeheartedly agree. However, it's not like FP optimisation
pragmas would be specific to any particular architecture. They
just
On Saturday, 23 July 2016 at 14:24:08 UTC, Matthias Klumpp wrote:
4) Resolving weird LDC bugs like this one:
https://github.com/ldc-developers/ldc/issues/1618 - might
actually be an LLVM issue, but I don't know enough to pin down
the issue.
Turns out that this is not actually a LDC/LLVM bug,
Hi Jay,
On Sunday, 26 June 2016 at 16:40:08 UTC, Jay Norwood wrote:
After watching Andre's sentinel thing, I'm playing with strlen
on char strings with 4 terminating 0s instead of a single one.
Seems to work and is 4x faster compared to the runtime version.
Please keep general discussions
On Friday, 24 June 2016 at 00:26:52 UTC, John Colvin wrote:
My biggest bugbear is actually the opposite of what you are
point out here: people doing careful benchmarking and
asm-inspection of small code-fragments in isolation when in
reality it is always going to be inlined and optimised in
On Thursday, 23 June 2016 at 23:34:54 UTC, David Nadlinger wrote:
I get the following results:
(This is of course not intended to be a comprehensive analysis.
For example, the codegen for the two functions is actually
identical on GDC and LDC, the relative differences are due to
measurement
On Thursday, 23 June 2016 at 22:08:20 UTC, Seb wrote:
[1] https://github.com/wilzbach/perf-d/blob/master/test_pow.d
[2] https://github.com/wilzbach/perf-d/blob/master/test_powi.d
This is a bad way to benchmark. You are essentially testing the
compiler's ability to propagate your constants
On Thursday, 23 June 2016 at 08:14:42 UTC, Mike Parker wrote:
* extern(C) functions should, at a minimum, be declared as
@nogc and nothrow for client code using those attributes.
Be careful, though, if the C library supports user-specified
callbacks to be set for some functionality – unless
On Thursday, 23 June 2016 at 17:24:34 UTC, Andrei Alexandrescu
wrote:
On my Ubuntu, /usr/bin/ld -> x86_64-linux-gnu-ld. What does
that mean? -- Andrei
`ld --version` should clear that up. ;)
— David
On Thursday, 23 June 2016 at 12:57:47 UTC, Steven Schveighoffer
wrote:
[…] I believe Weka.io does not [use Phobos] either.
Weka actually uses Phobos quite liberally – `fgrep -rI "import
std." weka` yields several thousand results (I'm sure Liran will
be happy to share more details). It's
On Tuesday, 21 June 2016 at 21:44:59 UTC, Dicebot wrote:
Would you mind making a point release with it if fix is
confirmed?
That's Kai's territory, but I'm sure he'll agree that this a
sensible thing to do.
— David
On Wednesday, 22 June 2016 at 08:04:34 UTC, Nordlöw wrote:
Is there now algorithm (similar to `canFind`) that can search
for a `T` in a `T[]`? Existing `canFind` only supports
sub-sequence needles.
What about
http://dlang.org/phobos/std_algorithm_searching.html#.canFind.canFind.2?
— David
On Tuesday, 21 June 2016 at 16:26:14 UTC, Satoshi wrote:
On Monday, 20 June 2016 at 11:28:58 UTC, Antonio Corbi wrote:
Hi folks!
I'm using ldc version:
LDC - the LLVM D compiler (1.0.0):
based on DMD v2.070.2 and LLVM 3.8.0
built with DMD64 D Compiler v2.071.0
Default target:
On Tuesday, 21 June 2016 at 16:12:13 UTC, Steven Schveighoffer
wrote:
On 6/21/16 11:43 AM, Dicebot wrote:
On Tuesday, 21 June 2016 at 12:18:37 UTC, Steven Schveighoffer
wrote:
On 6/21/16 6:14 AM, Dicebot wrote:
httpthub.com/dlang/druntime/blob/master/src/core/thread.d#L1611
I suspected
On Monday, 20 June 2016 at 08:10:19 UTC, Dicebot wrote:
How about defining semantics like "try inlining if possible,
fallback to always emitting symbol to object file otherwise"?
That would also allow compatible implementation in dmd.
This would get rid of the undefined symbols, but there is
Hi Antonio,
On Monday, 20 June 2016 at 11:28:58 UTC, Antonio Corbi wrote:
./ldcfail
Fatal Error while loading '/usr/lib/libphobos2-ldc.so.70':
The module 'std.regex.internal.parser' is already
defined in './ldcfail'.
[…]
Is this a bug in ldc or is it somehow related to my code?
On Monday, 20 June 2016 at 00:34:18 UTC, Joerg Joergonson wrote:
Can I just force the cast in some way if I know good an well it
works for ever? Or do I have to write extra code to get around
axiom: "We did this to save you trouble because we know better
than you what you are doing. Go forth
On Monday, 20 June 2016 at 00:01:58 UTC, Joerg Joergonson wrote:
class a { }
class b : a { }
class A(T : a)
{
T x;
}
void main(string[] argv)
{
auto y = new A!a();
auto z = new A!b();
y.x = new a();
z.x = new b();
auto p1 = cast(A!a)y;
On Sunday, 19 June 2016 at 21:06:43 UTC, Joerg Joergonson wrote:
A!b is derived from A!a if b is derived from a, is it not? If
not, then I am wrong, if so then D casting has a bug.
You are wrong.
The array example given by Adam is actually a neat illustration
of precisely your question if
On Sunday, 19 June 2016 at 21:13:00 UTC, Johan Engelen wrote:
On Sunday, 19 June 2016 at 21:11:59 UTC, Johan Engelen wrote:
(I think we can pretty much inline anything the user throws at
us)
(as long as it is not a naked asm function)
Another example is `alloca`, which you might not want to
On Sunday, 19 June 2016 at 20:20:38 UTC, David Nadlinger wrote:
Such a separate driver could then also be used as part of the
regular distribution to improve the performance on
memory-constrained all-at-once builds, by freeing all the
frontend/LLVM memory (i.e., terminating the process) before
On Sunday, 19 June 2016 at 18:23:06 UTC, Jakob Bornecrantz wrote:
That will be annoying, the LDC that works with SPIR-V wont be
able to produce MSVC compatible exes. Lets hope they mainline
it soon.
One possible solution for this would be a thin driver executable
that parses just enough of
On Sunday, 19 June 2016 at 14:05:22 UTC, mogu wrote:
It's awful that I compile a little 64bit program(or -m32mscoff)
in windows must have visual studio which has tremendous size
installed even though I only need a linker. It's weird that a
compiler compiles to binary targets needs another
On Friday, 17 June 2016 at 11:10:12 UTC, Gary Willoughby wrote:
Thanks, I forgot to mention I'm also doing lots of other stuff
in the constructor to private fields too.
struct Foo(T)
{
private int _bar;
private void* _baz;
this(int bar = 8)
{
this._bar = bar;
On Sunday, 12 June 2016 at 21:49:21 UTC, Vladimir Panteleev wrote:
On Sunday, 12 June 2016 at 19:12:37 UTC, Meta wrote:
I wanted to use OpenSSL from D but I noticed that the Deimos
bindings are for version 1.0.0e, which according to
OpenSSL.org is an out of date version. Are there any bindings
On Friday, 10 June 2016 at 14:37:23 UTC, Markus Pursche wrote:
If this is the case we would want to use Orbis.
As Seb also pointed out on GitHub, I've seen LLVM use "PS4"
internally, and it always seemed rather natural to me. On the
other hand, with Orbis I would have had no idea what the
On Friday, 10 June 2016 at 22:38:29 UTC, Dechcaudron wrote:
Error: basic type expected, not mixin
Why should it be like that? I believe the compiler should not
impose restrictions on what mixins can or cannot do :/
This might be a gratuitous grammar restriction. There are a few
of those
101 - 200 of 646 matches
Mail list logo
