On Monday, 15 July 2019 at 20:57:59 UTC, Johannes Pfau wrote:
I don't see how "should be made public" can be interpreted as
"should be installed", especially considering that templates
need source code installed (core.internal), but that's
completely orthogonal to what functions should be
On Monday, 15 July 2019 at 20:27:16 UTC, Johannes Pfau wrote:
I guess this should be documented somewhere then.
See druntime/CONTRIBUTING.md:
```
In general, only modules in the 'core' package should be
made public. The single exception is the 'object' module
which is not in any package.
The
On Monday, 15 July 2019 at 19:41:11 UTC, Johannes Pfau wrote:
And duplicating extern(C) declarations, syncing them manually,
... is a safety liability and maintainance nightmare (see my
other post). So in no way should we start to add more such
functions interfacing rt to core.internal.
On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote:
I'm sorry it broke digger, but digger is not how we typically
build DMD, druntime, and Phobos.
It also breaks the LDC build system. Just shipping rt.* too by
itself would be simple, but as the frontend takes various
libraries when
On Monday, 15 July 2019 at 19:52:57 UTC, David Nadlinger wrote:
On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
My understanding is the `rt` is the language implementation
and `core` is the low level library for users.
This understanding would be mistaken. We haven't been
On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote:
My understanding is the `rt` is the language implementation
and `core` is the low level library for users.
This understanding would be mistaken. We haven't been shipping
`rt` on the import path for a long time. `core.internal`
On Monday, 27 August 2018 at 20:47:08 UTC, Stefam Koch wrote:
generating it is not the problem but linking it on windows
currently requires the MS linker.
Is that true, though? DMD ships with LLD these days. — David
On Saturday, 25 August 2018 at 22:53:44 UTC, Walter Bright wrote:
On 8/25/2018 2:46 PM, David Nadlinger wrote:
At least for the transition period, I'd have attributes only
apply to the user-specified code and infer them for the actual
full constructor. (We can still print a deprecation warning
On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:
If I fix the bug, I break existing code, and apparently a
substantial amount of existing code. What's your advice on how
to proceed with this?
At least for the transition period, I'd have attributes only
apply to the
On Friday, 24 August 2018 at 03:53:38 UTC, David Nadlinger wrote:
[…]
All this is not to say that nothrow constructors aren't a good
idea, though.
This was meant to say nothrow DEstructors, as hopefully obvious
from context. —David
On Thursday, 23 August 2018 at 23:06:00 UTC, Ethan wrote:
Is that actually true, or would handling exceptions within the
constructor allow one to initialise the object to an invalid
state and thus still follow RAII paradigms correctly?
If you end up needing to check for that uninitialised
On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright wrote:
D deals with it via "chained exceptions", which is terrifyingly
difficult to understand. If you believe it is understandable,
just try to understand the various devious test cases in the
test suite.
I don't think that
On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh
wrote:
On 23/08/18 18:35, Joakim wrote:
[…]
How much time or money exactly has Weka spent on getting this
issue and other "critical" bugs fixed?
Weka is paying prominent D developers as contractors. We've had
David
On Thursday, 23 August 2018 at 21:31:41 UTC, Walter Bright wrote:
My personal opinion is that constructors that throw are an
execrable programming practice, and I've wanted to ban them.
(Andrei, while sympathetic to the idea, felt that too many
people relied on it.) I won't allow throwing
On Saturday, 18 August 2018 at 07:50:04 UTC, Dukc wrote:
On Thursday, 16 August 2018 at 14:11:20 UTC, Andrei
Alexandrescu wrote:
we're working on a HOPL submission.
What's HOPL?
https://hopl4.sigplan.org, presumably. —David
On Tuesday, 31 July 2018 at 18:21:15 UTC, Walter Bright wrote:
What I'm doing is preparing a submission to HOPL on the origins
of D. There's an emphasis on accuracy, references, correct
dates, correct attributions, and correct credit to the right
people.
I'd put together a timeline for my
On Monday, 18 June 2018 at 10:19:57 UTC, Nicholas Wilson wrote:
You should get in contact with Manu Evans, he's working on this
as well IIRC.
Might be a lonely conversation – this is a spam-bot repost of one
of Manu's messages. ;)
—David
On Sunday, 17 June 2018 at 17:00:00 UTC, David Nadlinger wrote:
core.simd.loadUnaligned instead
Ah, well… https://issues.dlang.org/show_bug.cgi?id=19001
— David
On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
https://github.com/JinShil/memcpyD
[…]
Feedback, advise, and pull requests to improve the
implementation are most welcome.
The memcpyD implementation is buggy; it assumes that all
arguments are aligned to their size. This
On Monday, 11 June 2018 at 03:34:59 UTC, Basile B. wrote:
- default linux:
https://github.com/gcc-mirror/gcc/blob/master/libgcc/memcpy.c
To see what is executed when you call memcpy() on a regular
GNU/Linux distro, you'd want to have a look at glibc instead. For
example, the AVX2 and AVX512
On Monday, 11 June 2018 at 08:02:42 UTC, Walter Bright wrote:
On 6/10/2018 9:44 PM, Patrick Schluter wrote:
See what Agner Fog has to say about it:
Thanks. Agner Fog gets the last word on this topic!
Well, Agner is rarely wrong indeed, but there is a limit to how
much material a single
On Sunday, 10 June 2018 at 22:23:08 UTC, Walter Bright wrote:
On 6/10/2018 11:16 AM, David Nadlinger wrote:
Because of the large amounts of noise, the only conclusion one
can draw from this is that memcpyD is the slowest,
Probably because it does a memory allocation.
Of course
On Sunday, 10 June 2018 at 12:49:31 UTC, Mike Franklin wrote:
I'm not experienced with this kind of programming, so I'm
doubting these results. Have I done something wrong? Am I
overlooking something?
You've just discovered the fact that one can rarely be careful
enough with what is
On Sunday, 27 May 2018 at 06:00:30 UTC, IntegratedDimensions
wrote:
[…] This is a potential suggestion for including such a feature
in the D language to provide sightly more consistency.
Solving this in the general case requires explicitly allowing,
specifying, and tracking covariance and
On Wednesday, 16 May 2018 at 14:48:54 UTC, Ethan Watson wrote:
And even better - LDC doesn't support core.simd and has its own
intrinsics that don't match the SSE/AVX intrinsics API
published by Intel.
To provide some context here: LDC only supports the types from
core.simd, but not the
On Saturday, 19 May 2018 at 01:15:10 UTC, RhyS wrote:
More then worth the effort because its used a lot when
discussions are ongoing regarding languages like Go, C, ... Its
one of the best form of free advertisement.
D used to be there, but at some point was at the maintainer's
whim for no
On Wednesday, 9 May 2018 at 04:17:17 UTC, Shachar Shemesh wrote:
On 09/05/18 01:09, David Nadlinger wrote:
The algorithm isn't wait-free (haven't thought too carefully
about this, though)
This mirrors a discussion I had with Maor (who originally wrote
it). Let's see if I bring you around
On Monday, 14 May 2018 at 18:31:13 UTC, Jacob Carlborg wrote:
Out of curiosity, how come the Objective-C integration seem to
always lack behind when LDC merges a new DMD release with some
new Objective-C integration? Is it less prioritized, not so
much knowledge in this area, something else?
On Monday, 14 May 2018 at 11:53:44 UTC, Nick Treleaven wrote:
On Monday, 14 May 2018 at 01:20:38 UTC, Jonathan M Davis wrote:
Yeah. It's been discussed that it should be illegal to declare
a struct or class member named init, but that change has yet
to happen.
On Sunday, 13 May 2018 at 13:37:06 UTC, A. Nicholi wrote:
I am trying to build LDC’s druntime by itself (without phobos)
[…] Make says: “No rule to make target '../dmd/src/osmodel.mak'”
LDC uses its own CMake-based build system for druntime/Phobos,
see runtime/CMakeLists.txt I'm the main
On Thursday, 10 May 2018 at 09:11:20 UTC, Walter Bright wrote:
This isn't the only time videos of my talks (and others) have
been lost due to technical problems or simple screwups. I'm
tired of this happening.
One hopes that the contract with the respective company providing
A/V services
On Wednesday, 9 May 2018 at 00:20:39 UTC, Andy Smith wrote:
What's MPSP? :-)
Whoops, MPMC, of course. ;) And that wasn't even the only typo; I
should know better than to post while distracted…
So if any D codebase has got bragging rights on the term
'industry-grade' I think this has to be
On Tuesday, 8 May 2018 at 17:20:33 UTC, Dmitry Olshansky wrote:
On Tuesday, 8 May 2018 at 04:00:03 UTC, manumaster wrote:
Is there some implement like this in D ?
https://github.com/pramalhe/ConcurrencyFreaks/blob/master/papers/multilist-2017.pdf
Look for Mecca by Wekka.io team. It has
On Tuesday, 10 April 2018 at 20:32:05 UTC, Seb wrote:
On Tuesday, 10 April 2018 at 16:51:57 UTC, Atila Neves wrote:
If you get to the point where you can #include , it
will be doubly impressive!
Not *if*, *when*. ;)
Atila
FYI people have been fighting with this for a long time:
On Saturday, 7 April 2018 at 09:07:48 UTC, sdvcn wrote:
true?stt="AA":stt="BB";-///Out:BB
writeln(stt);
As I just pointed out in Ali's bug report [1], this is correct, as
true ? stt = "AA" : stt = "BB"
means
(true ? (stt = "AA") : stt) = "BB",
in
On Saturday, 7 April 2018 at 21:22:07 UTC, kdevel wrote:
Can the ternary conditional even be used to assign objects of
the wrong type?
[…]
Congratulations, I'm pretty sure you found an actual bug, even
though it doesn't have anything to do with the conditional
operator per se:
On Tuesday, 20 March 2018 at 10:37:55 UTC, zunkree wrote:
On Sunday, 18 March 2018 at 14:36:04 UTC, Jacob Carlborg wrote:
FYI, -static is not support on macOS.
So, how to build static binary for macOS?
Static binaries aren't really supported by Apple (anymore).
What do you need it for?
—
On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:
Are there ways to reduce this to below 0.1s, or should I just
leave idiomatic D and make a betterC program?
The best solution would be to profile the startup process and
file a bug accordingly. ;)
— David
On Sunday, 18 March 2018 at 14:15:37 UTC, Stefan Koch wrote:
On Sunday, 18 March 2018 at 12:59:06 UTC, tipdbmp wrote:
I can't read assembly but it seems to me that it doesn't:
https://godbolt.org/g/PCsnPT
I think C++'s sort can take a "function object" that can get
inlined.
Correct it does
On Friday, 16 March 2018 at 07:57:04 UTC, John Chapman wrote:
I need to write to a range created with outputRangeObject, then
read from it. Is there a way to convert it to an input range?
Could you illustrate your problem a bit further?
In the literal sense, converting from an output to an
On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote:
You have to remember that the really big first client of
betterC(++) was DMD, porting DMD from C++ was a big
undertaking. Right now both DMD and LDC use a form of betterC,
so it is critical to have it finalized.
This is entirely wrong.
On Thursday, 1 March 2018 at 14:54:41 UTC, Shachar Shemesh wrote:
I.e. - is it well defined to copy between overlapping slices?
No: https://dlang.org/spec/arrays.html#overlapping-copying
—David
On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote:
David (aka klickverbot) is a longtime D contributor […]
… who is slightly surprised at the amount of media interest this
has attracted. ;)
— David
On Monday, 12 February 2018 at 22:35:23 UTC, Walter Bright wrote:
I take it dstep spawns the clang compiler?
It embeds the Clang frontend, which is designed to be usable as a
library.
— David
On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris wrote:
Oh, and look what I just found:
https://github.com/rust-lang/rust/issues/26179
Oh, look:
https://github.com/ldc-developers/druntime/blob/7b77937c70b4aba720e98727dcaad3323c29bd8d/src/ldc/intrinsics.di#L579-L587
— David
On Thursday, 1 February 2018 at 11:42:32 UTC, Russel Winder wrote:
The problem is actually a thread blocked in an inotify blocking
read. As both Steven and yourself have pointed out I am going
to have to use a timeout to check the state of the application.
There are better solutions
On Thursday, 4 January 2018 at 13:03:21 UTC, Mike Parker wrote:
https://dlang.org/blog/2018/01/04/dmd-2-078-0-has-been-released/
In normal D code, struct destructors are executed when an
instance goes out of scope. This is handled by DRuntime, […]
This is slightly inaccurate. Regular stack
On Tuesday, 2 January 2018 at 11:42:49 UTC, John Chapman wrote:
Because an alias of a type is just another name for the same
thing you can't test if they're different. I wondered if there
was a way to get the aliased name, perhaps via traits?
(.stringof returns the original type.)
There is
On Saturday, 30 December 2017 at 13:48:16 UTC, ChangLong wrote:
After fiber yield, the spoke guard is not able to execute,
unless I throw a exception in Fiber. I am look if there is
some hack method to make the fiber Interrupted at any time with
scope(exit) code executed.
There isn't. In
On Monday, 25 December 2017 at 20:39:52 UTC, Mengu wrote:
is partially applying templates possible?
Check out std.meta.Apply{Left, Right}.
— David
On Saturday, 23 December 2017 at 12:23:33 UTC, Johan Engelen
wrote:
Fine grained PGO profiling:
-fprofile-instr-generate
http://johanengelen.github.io/ldc/2016/07/15/Profile-Guided-Optimization-with-LDC.html
Function entry/exit profiling:
-finstrument-functions
On Thursday, 21 December 2017 at 18:40:54 UTC, Andrei
Alexandrescu wrote:
I heard ldc already uses its embedded variant for linking
programs (on Widows? Posix? 32bit? 64bit?)
Internal linking is currently enabled by a separate command-line
flag; we still use the system linker by default (just
On Thursday, 21 December 2017 at 12:43:51 UTC, Jacob Carlborg
wrote:
On 2017-12-20 11:31, Benjamin Thaut wrote:
Would this work in all cases? Do tls variables work across
Linux shared libraries?
As far as I know it works on Linux and FreeBSD, but it doesn't
work on macOS. I don't know about
On Sunday, 17 December 2017 at 12:45:58 UTC, Yuxuan Shui wrote:
Although this might also be a bug on musl side: it tries to
call init functions even when RTLD_NOLOAD is passed to dlopen.
Ah, interesting. Might be worth reporting as a bug indeed;
without looking too hard, I didn't see anything
On Thursday, 14 December 2017 at 19:47:53 UTC, Jack Stouffer
wrote:
Clang has __int128. Is there anyway to use this with D with LDC?
There has been some work on this a while ago, by Kai, but it
hasn't been merged yet:
https://github.com/ldc-developers/ldc/pull/1355
— David
On Wednesday, 13 December 2017 at 01:14:26 UTC, Seb wrote:
Also the storage on the machine is limited and we can't drop an
unlimited amount of Docker images there.
Shouldn't the overhead from that be fairly manageable? After all,
the last layer would only be as large as a single DMD/LDC
On Sunday, 10 December 2017 at 21:00:08 UTC, Timothee Cour wrote:
ldc has better support
Just to be clear, LDC doesn't aim at incrementally "better
support", but support, full stop.
Granted, it has probably seen less real-world use than shared
library support on Linux so there might be
On Saturday, 9 December 2017 at 06:46:27 UTC, Arun Chandrasekaran
wrote:
Thanks. Just curious why reference can't be obtained here.
Saves nasty null checks in most places.
D simply doesn't have a (C++-style) concept of references as part
of the type. Arguments can be passed by reference -
On Saturday, 9 December 2017 at 00:32:36 UTC, Timothee Cour wrote:
They are on LDC; would be interesting to see whether the
problem occurs there as well (I'm having issues with my Mac
right now, so can't check myself until later).
just updated bug report: same issue with ldc!
Only if not
On Friday, 8 December 2017 at 18:59:00 UTC, Manu wrote:
Nicholas wants a *compile* error, not a link error.
I don't think this is necessarily implied from the original post.
Certainly, a linker error would just work fine for the original
use case (avoiding unsupported codegen on compute
On Friday, 8 December 2017 at 16:17:14 UTC, Jacob Carlborg wrote:
Well, shared libraries are not officially support on macOS.
They are on LDC; would be interesting to see whether the problem
occurs there as well (I'm having issues with my Mac right now, so
can't check myself until later).
On Saturday, 2 December 2017 at 15:47:23 UTC, Jacob Carlborg
wrote:
On 2017-12-02 13:41, kinke wrote:
Nope, unfortunately still waiting for one of my compadres to
create and upload the OSX package.
Have you thought of automatically build and upload packages
using Travis CI?
That would be
On Friday, 17 November 2017 at 02:01:41 UTC, solidstate1991 wrote:
It's filled with Assembly code, and otherwise not very
readable. Would need a lot of work, I don't think it would
worth it. Let's hope that MS will allow us to distribute a
linker alongside DMD.
The more promising avenue
On Friday, 3 November 2017 at 23:50:33 UTC, Nicholas Wilson wrote:
Does `-link-internally` mean that you don't require command
line tool/dev installation for OS X and Windows? That would be
awesome for getting workshops for non-programmers (the
biologists at my Uni) to work.
You still need
On Wednesday, 1 November 2017 at 17:24:32 UTC, Igor Shirkalin
wrote:
Does new "-betterC" mean we may use parallelism with using
separate linker?
`-betterC` does not add any emulation of missing platform
features — on the contrary, it *removes* language runtime
functionality! Thus, if TLS
On Wednesday, 1 November 2017 at 17:30:05 UTC, Iain Buclaw wrote:
GDC supports the same or maybe more platforms than LDC. :-)
Or quite possibly fewer, depending on what one understands
"platform" and "support" to mean. ;)
What is the state of GDC on Android/ARM – has anyone been using
it
On Wednesday, 21 June 2017 at 16:10:41 UTC, Dan Walmsley wrote:
My idea is to build the whole thing, see what the code size and
performance is, and then one by one reduce things down as
needed.
Starting from nothing so far has been a bit of a none starter!
This way, you'll end up having to
On Monday, 19 June 2017 at 14:08:56 UTC, Patric Dexheimer wrote:
Fresh install of GDC. (tried with 32x ad 32_64x)
Where did you get the GDC executable from? The GDC project
doesn't currently offer any official builds that target Windows;
the 6.3.0 builds from https://gdcproject.org/downloads
On Wednesday, 21 June 2017 at 06:58:43 UTC, Jacob Carlborg wrote:
Musl (or similar) should be available as an alternative. That
will make it easier to cross-compile as well.
This is not relevant for cross-compilation, as long as you have
the libraries available. You can actually link a D
On Wednesday, 21 June 2017 at 14:53:04 UTC, Dan Walmsley wrote:
when trying to compile I'm getting lots of errors like this one:
C:\dev\repos\druntime\src\gc\impl\manual\gc.d(28): Error:
module config is in file 'gc\config.d' which cannot be read
import path[0] =
On Tuesday, 20 June 2017 at 17:52:59 UTC, Dan Walmsley wrote:
I need to know, how does the run time know which area of ram to
use for heap?
It uses C's malloc/calloc().
— David
On Tuesday, 20 June 2017 at 18:51:17 UTC, Moritz Maxeiner wrote:
On Tuesday, 20 June 2017 at 12:09:06 UTC, Jacob Carlborg wrote:
LLD, the LLVM linker [1]. As far as I understand it, it also
support cross-platform linking. Using LDC, musl and LLD you
have a fully working cross-compiler tool
On Tuesday, 20 June 2017 at 19:01:06 UTC, Stefan Koch wrote:
On Tuesday, 20 June 2017 at 18:58:36 UTC, David Nadlinger wrote:
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
Hit me with brittle numeric code please!
[…]
Unfortunately this also broke the phobos unitttests since now
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
Hit me with brittle numeric code please!
[…]
Unfortunately this also broke the phobos unitttests since now
more of is attempted to be evaluated.
Just making sure that the Phobos unit tests pass at compile time
(with 64 bit reals,
On Wednesday, 14 June 2017 at 19:55:49 UTC, Yawniek wrote:
Msgpack rpc with vibe.d works. We used it.
Its extremely fast, youll never get that speed with thrift.
I don't think Thrift is fundamentally much different in
performance than MessagePack, see e.g.
On Wednesday, 14 June 2017 at 12:48:14 UTC, Russel Winder wrote:
On Wed, 2017-06-14 at 10:40 +, gzp via Digitalmars-d wrote:
[…]
cas
in all api I've seen on a failed swap, the current value is
retrieved
(in c/c++ there are intrinsic for them)
This appears to be in core.atomic.
There is
Hi,
On Tuesday, 13 June 2017 at 06:12:46 UTC, gzp wrote:
the docs are quite minimal
That's true. In fact, this applies not only to atomic intrinsics,
but all of `shared`. We need to sit down and properly specify
things at some point. Andrei has been trying to get an initiative
going to do
On Sunday, 4 June 2017 at 10:39:09 UTC, rikki cattermole wrote:
Should be a way, since you can pass arg directly via ldc to ld.
But I would expect it to have done it by default anyway.
It is indeed done by default on Windows and Linux. If you dump
the object code before it gets to the linker,
On Saturday, 3 June 2017 at 23:13:09 UTC, Nicholas Wilson wrote:
Good idea, name of global needs to be known in advance though.
Why, and how would that be a non-trivial problem?
— David
On Friday, 2 June 2017 at 21:56:47 UTC, Robert burner Schadek
wrote:
If that works out, the next step is properly to integrate that
in the phobos/druntime/dmd CI. Which properly means putting the
benchmark library through the experimental integration process,
and finding a place for the
On Saturday, 3 June 2017 at 14:12:03 UTC, Russel Winder wrote:
I have no idea what drugs the person who chose that last one to
be correct semantics was on at the time, but it was some
seriously bad stuff.
Of all people, I certainly didn't expect you to stray so far from
the tone appropriate
On Saturday, 3 June 2017 at 14:19:00 UTC, Jacob Carlborg wrote:
Perhaps using the variadic template with a constraint on one
element trick will work. Ugly, but I think that will work.
We could also finally fix the frontend to get around this. At
DConf 2015, Walter officially agreed that this
On Saturday, 3 June 2017 at 13:17:46 UTC, Russel Winder wrote:
Is this a problem in D or a problem in DStep?
It's a limitation of DStep – for that use case, it would need to
transform one of the macro arguments into a template argument
rather than a runtime function parameter.
If you need
On Saturday, 3 June 2017 at 12:13:41 UTC, Nicholas Wilson wrote:
Alas no. __attribute__((target(...)) works because it targeting
different targets of the _same_ backend, this targets different
backends.
But surely you could just take the buffer with the object code
emitted by the compute
On Tuesday, 23 May 2017 at 19:47:49 UTC, Andrei Alexandrescu
wrote:
A big one will be making the GC lazily initialize itself.
How detailed are your plans for this? The interaction between GC
and shared library loading is a bit non-trivial to get right.
— David
On Sunday, 14 May 2017 at 15:30:19 UTC, Walter Bright wrote:
On 5/14/2017 3:39 AM, Tomer Filiba wrote:
Of course it only applies to runtime division -- the compiler
can do the same if
the divisor is known in compile time.
I hate to say this, but modern compilers already do this for
On Thursday, 11 May 2017 at 21:37:45 UTC, Iain Buclaw wrote:
This is not a problem that needs to be solved for GDC.
It's not a problem that needs to be solved *in* GDC, but it has
to be tackled *for* (packaging) GDC, as you need to have a
bootstrap compiler available. Hence, building a
On Thursday, 11 May 2017 at 21:14:16 UTC, Iain Buclaw wrote:
Oh, do you have to do the multi-stage build yourself? I don't.
So you intend to keep a copy of the (old) bootstrap compiler
sources in-tree for all future D-based GDC versions (if/when you
start requiring D)? We could do that just
On Thursday, 11 May 2017 at 20:54:45 UTC, Iain Buclaw wrote:
My rebuttal still stands. Switching build from C++ to D should
be a one line change, if it isn't then you have a problems with
your build process.
How does snap requiring more than a one-line change for a
multi-stage build imply
On Thursday, 11 May 2017 at 17:56:00 UTC, Iain Buclaw wrote:
I can only infer that you are saying that using a D project
means it's more difficult to get working with snap. To which I
will insert an obligatory "Woah!", and "I expect you to know
better" rebuttal.
...
Woah, I expect you to
On Wednesday, 10 May 2017 at 19:46:01 UTC, Joseph Rushton
Wakeling wrote:
Ironically, given that I'd always been worried this would be
the most finnicky compiler snap to create, it's actually the
simplest package definition out of all the Big 3 ;-)
Without even having seen your snap file, I
On Saturday, 6 May 2017 at 23:53:45 UTC, Ethan Watson wrote:
This is quite feasible in Europe, since everything is quite
close together. I'm keen. Atila is keen. Anyone else think this
is a great idea?
I'd definitely be interested as well. —David
On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote:
static Phobos2 : 806968 bytes
dynamic Phobos2 : 18552 bytes
That's about 770 KiB to share or 97.7% of its total size!
Awesome!
By the way, using LDC: 402736 bytes for the static build (Linux
x86_64). ;)
— David
On Saturday, 22 April 2017 at 10:12:04 UTC, Arek wrote:
And no output for ARM64. :/
LDC has beta-quality support for AArch64. --David
On Tuesday, 11 April 2017 at 09:30:28 UTC, Jacob Carlborg wrote:
And no official support on macOS.
LDC officially supports shared libraries on macOS. -David
On Tuesday, 11 April 2017 at 18:13:11 UTC, Russel Winder wrote:
I have only the data that compiling and linking a GtkD
application against a shared library is a lot shorter than
against a static library.
Sure, but that might be easily fixed, and if you really want to
use shared libraries,
On Tuesday, 11 April 2017 at 12:03:27 UTC, Matthias Klumpp wrote:
On Monday, 10 April 2017 at 22:15:53 UTC, David Nadlinger wrote:
So do we need to put a reminder about the ABI being unstable
into set of every release notes to make sure we won't get
angry bug reports once users actually build
On Monday, 10 April 2017 at 22:36:39 UTC, Iain Buclaw wrote:
All the regression fixes and none of the bugs!
That's an interesting approach (spoken with British language
sensibilities).
Is anybody using GDC on a big "modern" D2 codebase
(metaprogramming-heavy, …) right now? From my
On Tuesday, 11 April 2017 at 14:49:03 UTC, Russel Winder wrote:
Having played a bit with GtkD, you always want this as a shared
library for development.
Why would a shared library be preferable to a static library for
that (which might still be re-used between different projects,
etc.)?
—
On Tuesday, 11 April 2017 at 12:38:01 UTC, Matthias Klumpp wrote:
If you could change the SOVERSION with every one of these
changes, or simply just tie it to the respective Phobos
release, distributions would automatically do the right thing
and compile all D code using Phobos against the new
1 - 100 of 2050 matches
Mail list logo
