On Tuesday, 11 April 2017 at 12:36:41 UTC, Russel Winder wrote:
Most programming languages are going this route, used
programming language tools and libraries are decreasingly
packaged by the OS.
Exactly the reason why we banned Go quite recently.
Just far too expensive, especially w/
On Tuesday, 11 April 2017 at 12:56:59 UTC, Jonathan M Davis wrote:
But if we just use dub - which _is_ the official packaging and
build tool - then we avoid these issues. Ideally, the compiler
and dub would be part of the distro, but libraries don't need
to be.
But that would defeat a
On Tuesday, 11 April 2017 at 00:47:34 UTC, Jonathan M Davis wrote:
Hi folks,
Also, what are we even looking to distribute in debian? I would
have thought that the normal thing to do would be to build with
dub, in which case, having the compiler and dub be debian
packages makes sense but not
Am Wed, 03 May 2017 01:02:38 +
schrieb Moritz Maxeiner :
> On Tuesday, 2 May 2017 at 23:27:28 UTC, Marco Leise wrote:
> > Am Tue, 02 May 2017 20:53:50 +
> > schrieb Moritz Maxeiner :
> >
> >> On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise
On Tuesday, 2 May 2017 at 23:27:28 UTC, Marco Leise wrote:
Am Tue, 02 May 2017 20:53:50 +
schrieb Moritz Maxeiner :
On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote:
>
> I see what you're doing there, but your last point is
> wishful thinking. Dynamically
Am Tue, 02 May 2017 20:53:50 +
schrieb Moritz Maxeiner :
> On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote:
> >
> > I see what you're doing there, but your last point is wishful
> > thinking. Dynamically linked binaries can share megabytes of
> > code. Even
On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote:
I see what you're doing there, but your last point is wishful
thinking. Dynamically linked binaries can share megabytes of
code. Even Phobos - although heavily templated - has proven to
be very amenable to sharing. For example, a
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
Am Tue, 11 Apr 2017 15:03:36 +
schrieb qznc :
> On Tuesday, 11 April 2017 at 12:56:59 UTC, Jonathan M Davis wrote:
> > But if we just use dub - which _is_ the official packaging and
> > build tool - then we avoid these issues. Ideally, the compiler
> > and dub would be part of
Am Tue, 11 Apr 2017 07:40:12 -0700
schrieb Jonathan M Davis via Digitalmars-d
:
> It could always just be distributed as a static library. There arguably
> isn't much point in distributing it as a shared library anyway -
> particularly when it's not ABI compatible
Am Wed, 12 Apr 2017 07:42:42 +
schrieb Martin Nowak :
> Our point releases might also contain small ABI
> incompatibilities, so they aren't really eligible as patch
> version.
I've actually been hit by this in one point release on Gentoo,
where I used dynamic linking for
On 11 April 2017 at 23:02, Johannes Pfau via Digitalmars-d
wrote:
> Am Tue, 11 Apr 2017 14:21:57 +
> schrieb Matthias Klumpp :
>
>> can be used by Automake
>> (native),
>
> Do you maintain D support for automake? I wrote some basic D support
> for
Am Wed, 12 Apr 2017 07:42:42 +
schrieb Martin Nowak :
> On Monday, 10 April 2017 at 16:12:35 UTC, Iain Buclaw wrote:
> > Last time someone else looked, it seemed like LDC and DMD make
> > use of SOVERSION, but do so in an incorrect manner.
>
> You know what exactly is the
On Monday, 10 April 2017 at 16:12:35 UTC, Iain Buclaw wrote:
Last time someone else looked, it seemed like LDC and DMD make
use of SOVERSION, but do so in an incorrect manner.
You know what exactly is the problem? Any suggestion what to use
instead?
It's currently using libphobos2.so.0.74,
On Tuesday, 11 April 2017 at 21:08:05 UTC, Johannes Pfau wrote:
I'd think of .d files as a superset of .di files.
Note that there is zero difference between them. The compiler
treats both *exactly* the same way (it just considers the
extensions to be aliases of each other).
It is just a
Am Tue, 11 Apr 2017 07:44:45 -0700
schrieb Jonathan M Davis via Digitalmars-d
:
> On Tuesday, April 11, 2017 14:33:01 Matthias Klumpp via Digitalmars-d
> wrote:
> > On Tuesday, 11 April 2017 at 14:26:37 UTC, rikki cattermole wrote:
> > > [...]
> > > The problem with
Am Tue, 11 Apr 2017 14:21:57 +
schrieb Matthias Klumpp :
> can be used by Automake
> (native),
Do you maintain D support for automake? I wrote some basic D support
for autoconf and libtool
(https://github.com/D-Programming-GDC/GDC/tree/master/libphobos/m4) but
no automake
On 11 April 2017 at 20:13, David Nadlinger via Digitalmars-d
wrote:
> 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).
>
On Tuesday, 11 April 2017 at 18:14:40 UTC, David Nadlinger wrote:
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
On 2017-04-11 19:34, Walter Bright wrote:
Looks like it solves it by adding another layer of indirection:
"the performance overhead of the extra ivar offset variable is small."
Yes, there are always tradeoffs. But as you've said, exceptions are
already slow ;)
--
/Jacob Carlborg
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 Tue, 2017-04-11 at 17:02 +, David Nadlinger via Digitalmars-d
wrote:
> 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
On 11 April 2017 at 14:11, Matthias Klumpp via Digitalmars-d
wrote:
> On Monday, 10 April 2017 at 22:36:39 UTC, Iain Buclaw wrote:
>>
>> On 10 April 2017 at 23:52, David Nadlinger via Digitalmars-d
>> wrote:
>>>
>>> On Monday, 10 April
On 4/11/2017 6:46 AM, Jacob Carlborg wrote:
http://www.sealiesoftware.com/blog/archive/2009/01/27/objc_explain_Non-fragile_ivars.html
Looks like it solves it by adding another layer of indirection:
"the performance overhead of the extra ivar offset variable is small."
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 11 April 2017 at 17:48, Matthias Klumpp via Digitalmars-d
wrote:
> On Tuesday, 11 April 2017 at 15:31:46 UTC, David Nadlinger wrote:
>>
>> On Tuesday, 11 April 2017 at 12:38:01 UTC, Matthias Klumpp wrote:
>>>
>>> If you could change the SOVERSION with every one of
On Tuesday, 11 April 2017 at 15:31:46 UTC, David Nadlinger wrote:
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
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
On Tuesday, 11 April 2017 at 14:43:15 UTC, Russel Winder wrote:
On Tue, 2017-04-11 at 14:21 +, Matthias Klumpp via
Digitalmars-d wrote:
[…]
At time I am playing around with the idea of using
pkg-config[1]
files to enlist the sources a D library consists of.
By doing that, we would have
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.
Yeah, GtkD is pretty massive and takes quite a large amount of
time to compile... Redoing that for each software depending on it
is
On Tuesday, 11 April 2017 at 12:56:59 UTC, Jonathan M Davis wrote:
But if we just use dub - which _is_ the official packaging and
build tool - then we avoid these issues. Ideally, the compiler
and dub would be part of the distro, but libraries don't need
to be. And it sounds like that's
On Tue, 2017-04-11 at 07:40 -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Tuesday, April 11, 2017 14:21:57 Matthias Klumpp via Digitalmars-d
> wrote:
> > This will *not* solve the issues with Phobos breakage though, as
> > Phobos is a shared library.
>
> It could always just be
On Tuesday, April 11, 2017 14:33:01 Matthias Klumpp via Digitalmars-d wrote:
> On Tuesday, 11 April 2017 at 14:26:37 UTC, rikki cattermole wrote:
> > [...]
> > The problem with /usr/include/d is that is where .di files
> > would be located not .d. This would also match up with the
> > c/c++ usage
On 11/04/2017 3:33 PM, Matthias Klumpp wrote:
On Tuesday, 11 April 2017 at 14:26:37 UTC, rikki cattermole wrote:
[...]
The problem with /usr/include/d is that is where .di files would be
located not .d. This would also match up with the c/c++ usage of it.
When I asked about this a while back,
On Tue, 2017-04-11 at 14:21 +, Matthias Klumpp via Digitalmars-d
wrote:
>
[…]
> At time I am playing around with the idea of using pkg-config[1]
> files to enlist the sources a D library consists of.
> By doing that, we would have a very build-system agnostic way of
> doing storing that
On Tuesday, April 11, 2017 14:21:57 Matthias Klumpp via Digitalmars-d wrote:
> This will *not* solve the issues with Phobos breakage though, as
> Phobos is a shared library.
It could always just be distributed as a static library. There arguably
isn't much point in distributing it as a shared
On Tuesday, 11 April 2017 at 14:26:37 UTC, rikki cattermole wrote:
[...]
The problem with /usr/include/d is that is where .di files
would be located not .d. This would also match up with the
c/c++ usage of it.
When I asked about this a while back, I was told to just install
the sources into
On 11/04/2017 3:21 PM, Matthias Klumpp wrote:
On Tuesday, 11 April 2017 at 14:04:44 UTC, rikki cattermole wrote:
[...]
/usr/share/source/D/package-name-version
Add a search path like that to Dub and create source only library
packages and that is pretty much all the distribution we need for
On Tuesday, 11 April 2017 at 14:04:44 UTC, rikki cattermole wrote:
[...]
/usr/share/source/D/package-name-version
Add a search path like that to Dub and create source only
library packages and that is pretty much all the distribution
we need for libraries I reckon.
It's more likely that the
On 11/04/2017 3:01 PM, Jacob Carlborg wrote:
On 2017-04-11 14:56, Jonathan M Davis via Digitalmars-d wrote:
That's basically what's required with D. It is not ABI compatible across
releases, and while ABI compatibility might be nice, it really isn't
reasonable with D - especially with how
On 2017-04-11 14:56, Jonathan M Davis via Digitalmars-d wrote:
That's basically what's required with D. It is not ABI compatible across
releases, and while ABI compatibility might be nice, it really isn't
reasonable with D - especially with how attributes work and how template
heavy D code is.
On Tuesday, 11 April 2017 at 13:43:38 UTC, Jacob Carlborg wrote:
On 2017-04-11 02:47, Jonathan M Davis via Digitalmars-d wrote:
Honestly, I don't see how it really makes much sense to use
shared libraries
with D except in cases where you have no choice. The lack of
ABI
compatibility makes
On 2017-04-11 02:20, Walter Bright wrote:
On 4/10/2017 4:43 PM, David Nadlinger wrote:
[1] In fact, it looks like – for example with DMD moving to
libunwind-based EH
as well – the issue is slowly resolving itself anyway and at some
point we'll
merely have to sit down for a week and iron out the
On 2017-04-11 02:47, Jonathan M Davis via Digitalmars-d wrote:
Honestly, I don't see how it really makes much sense to use shared libraries
with D except in cases where you have no choice. The lack of ABI
compatibility makes them almost useless.
Also, what are we even looking to distribute in
On Tuesday, 11 April 2017 at 12:47:13 UTC, Russel Winder wrote:
So why bother, no Rust people will use it, they just use Cargo
and it gets stuff for them. Why bother packaging anything when
people will not use it? All you need to have a working Rust
system on Debian is curl and bash.
Users
On Tuesday, April 11, 2017 12:25:09 Matthias Klumpp via Digitalmars-d wrote:
> Haskell and OCaml permanently rebuild the whole stack on every
> new compiler release, which is why they have permanent transition
> trackers[1], so they basically continuously rebuild. I want to
> avoid this at all
On Tue, 2017-04-11 at 12:48 +, Matthias Klumpp via Digitalmars-d
wrote:
[…]
> That's false. Debian is leading the effort on reproducible builds
> that many other projects (including Fedora) have joined, and a
> large chunk of packages is already reproducible[1].
> It's actually quite the
On Tuesday, April 11, 2017 12:40:34 Matthias Klumpp via Digitalmars-d wrote:
> On Tuesday, 11 April 2017 at 00:47:34 UTC, Jonathan M Davis wrote:
> > On Monday, April 10, 2017 23:08:17 David Nadlinger via [...]
> > Also, what are we even looking to distribute in debian? I would
> > have thought
On Tuesday, 11 April 2017 at 12:42:13 UTC, Russel Winder wrote:
On Tue, 2017-04-11 at 12:03 +, Matthias Klumpp via
Digitalmars-d wrote:
[…]
Nah, there are several options here, one would simply be to
tell
people not to use the distro packages with anything but the
default D compiler
On Tue, 2017-04-11 at 12:38 +, Gerald via Digitalmars-d wrote:
> Looking into Rust and Cargo Debian packaging, it looks like they
> are looking to go with source packages to work around the ABI
> issue:
>
> "Because Rust doesn't have a stable shared-library ABI, and we
> don't want to
On Tuesday, 11 April 2017 at 00:47:34 UTC, Jonathan M Davis wrote:
On Monday, April 10, 2017 23:08:17 David Nadlinger via [...]
Also, what are we even looking to distribute in debian? I would
have thought that the normal thing to do would be to build with
dub, in which case, having the
On Tue, 2017-04-11 at 12:03 +, Matthias Klumpp via Digitalmars-d
wrote:
>
[…]
> Nah, there are several options here, one would simply be to tell
> people not to use the distro packages with anything but the
> default D compiler used in the respective Debian release.
> Go apparently tells
Looking into Rust and Cargo Debian packaging, it looks like they
are looking to go with source packages to work around the ABI
issue:
"Because Rust doesn't have a stable shared-library ABI, and we
don't want to rebuild every Rust library package for every
architecture every time we upload a
On Monday, 10 April 2017 at 23:43:04 UTC, David Nadlinger wrote:
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
On Tue, 2017-04-11 at 11:55 +, Matthias Klumpp via Digitalmars-d
wrote:
>
[…]
> That's the problem I would like to see addressed (but given
> Walter's comment, it won't be feasible to resolve it in the near
> future).
> We could simply do away with "don't use distro packages for your
> D
On Monday, 10 April 2017 at 23:33:17 UTC, Walter Bright wrote:
On 4/10/2017 6:08 AM, Matthias Klumpp wrote:
I also want to stress that having a single C++ library like
Boost compiled into
stuff and rolling dependency transitions when its API/ABI
changes with a major
release is less of a
On Monday, 10 April 2017 at 23:27:35 UTC, Walter Bright wrote:
On 4/10/2017 5:59 AM, Matthias Klumpp wrote:
You need to see here that D is not the center of the world and
we will need to
make it work nicely with the rest of the system. The technical
policies work for
everything else, so there
On Monday, 10 April 2017 at 23:08:17 UTC, David Nadlinger wrote:
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
On Tuesday, 11 April 2017 at 12:11:10 UTC, Matthias Klumpp wrote:
On Monday, 10 April 2017 at 22:36:39 UTC, Iain Buclaw wrote:
All the regression fixes and none of the bugs!
The current situation is that it should be link-compatible
with current upstream/stable. Enough so that when someone
On Monday, 10 April 2017 at 22:36:39 UTC, Iain Buclaw wrote:
On 10 April 2017 at 23:52, David Nadlinger via Digitalmars-d
wrote:
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
On Monday, 10 April 2017 at 22:26:46 UTC, Joseph Rushton Wakeling
wrote:
On Monday, 10 April 2017 at 13:20:00 UTC, Matthias Klumpp wrote:
This has worked nicely for every language. If you don't have
templates in your API or don't change the templates between
releases, you can survive with one
On Monday, 10 April 2017 at 22:15:53 UTC, David Nadlinger wrote:
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
On Monday, 10 April 2017 at 20:11:28 UTC, Wyatt wrote:
On Monday, 10 April 2017 at 18:46:31 UTC, H. S. Teoh wrote:
Hmm. I guess there's no easy way to make dmd/ldc emit
dependencies with modified SONAMEs? So yeah, you're right,
every software that depends on said libraries would have to
I apologize in advance for the large amount of mail that will
likely follow, but I want to address all comments.
On Monday, 10 April 2017 at 18:46:31 UTC, H. S. Teoh wrote:
[...]
One issue, though: if we standardize on compiling Debian
packages with ldc, then what do we do with libraries that
On Monday, April 10, 2017 23:08:17 David Nadlinger via Digitalmars-d wrote:
> IIRC OCaml is also very much a statically linked affair. And how
> does Debian distribute Go binaries? Is there any issue with those
> being linked statically? If not, let's just distribute D
> libraries as source and
On 4/10/2017 4:43 PM, David Nadlinger wrote:
[1] In fact, it looks like – for example with DMD moving to libunwind-based EH
as well – the issue is slowly resolving itself anyway and at some point we'll
merely have to sit down for a week and iron out the last few kinks.
dmd is not moving to a
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 11 April 2017 at 01:33, Walter Bright via Digitalmars-d
wrote:
> On 4/10/2017 6:08 AM, Matthias Klumpp wrote:
>>
>> I also want to stress that having a single C++ library like Boost compiled
>> into
>> stuff and rolling dependency transitions when its API/ABI
On 11 April 2017 at 01:27, Walter Bright via Digitalmars-d
wrote:
>
> The next problem is that dmd occasionally changes the interface to the D
> runtime. Or more accurately, with about every release. This has not been an
> issue historically for us, as the two have
On 4/10/2017 6:08 AM, Matthias Klumpp wrote:
I also want to stress that having a single C++ library like Boost compiled into
stuff and rolling dependency transitions when its API/ABI changes with a major
release is less of a problem than having the entire language give zero stability
and
On 4/10/2017 1:43 PM, Iain Buclaw via Digitalmars-d wrote:
This is an unfortunate distribution problem, things would be different
if GCC were more like a library. It's not like anyone is helping me
with the push. I am ultimately the one who is doing the tens of
thousands of lines of code
On 4/10/2017 5:59 AM, Matthias Klumpp wrote:
You need to see here that D is not the center of the world and we will need to
make it work nicely with the rest of the system. The technical policies work for
everything else, so there is nothing that really justifies an exception for D
here (if 10%
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 10 April 2017 at 23:52, David Nadlinger via Digitalmars-d
wrote:
> 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
On Monday, 10 April 2017 at 13:20:00 UTC, Matthias Klumpp wrote:
This has worked nicely for every language. If you don't have
templates in your API or don't change the templates between
releases, you can survive with one library for a long time.
But the vast majority of D libraries _do_ have
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 10 April 2017 at 19:50, Matthias Klumpp via Digitalmars-d
wrote:
> On Monday, 10 April 2017 at 16:58:05 UTC, Johan Engelen wrote:
>>
>> On Monday, 10 April 2017 at 13:20:00 UTC, Matthias Klumpp wrote:
>>>
>>>
>>> Btw, at time we are just ignore the ABI issues, and
On 10 April 2017 at 19:48, Matthias Klumpp via Digitalmars-d
wrote:
> On Monday, 10 April 2017 at 16:12:35 UTC, Iain Buclaw wrote:
>>
>> [...]
>> Everyone should follow GDC's ABI, rather than trying to mimic DMD calling
>> convention. ;-)
>
>
> GDC is working very
On Monday, 10 April 2017 at 18:46:31 UTC, H. S. Teoh wrote:
Hmm. I guess there's no easy way to make dmd/ldc emit
dependencies with modified SONAMEs? So yeah, you're right,
every software that depends on said libraries would have to
explicitly depend on a different SONAME depending on what
On 4/10/2017 8:11 AM, Jack Stouffer wrote:
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
3) Will DMD support more architectures in the near future? How should the
architecture issue be handled?
This can be definitively answered as "no",
On Mon, Apr 10, 2017 at 06:12:26PM +, Matthias Klumpp via Digitalmars-d
wrote:
> On Monday, 10 April 2017 at 17:29:04 UTC, H. S. Teoh wrote:
> > On Mon, Apr 10, 2017 at 11:40:12AM +, Matthias Klumpp via
> > Digitalmars-d wrote: [...]
> > > [...]
> > > If we do that, we will run into the D
On Monday, 10 April 2017 at 17:29:04 UTC, H. S. Teoh wrote:
On Mon, Apr 10, 2017 at 11:40:12AM +, Matthias Klumpp via
Digitalmars-d wrote: [...]
[...]
If we do that, we will run into the D ABI trap: Libraries
compiled with compiler X can not be used from software
compiled with D compiler
On Monday, 10 April 2017 at 16:58:05 UTC, Johan Engelen wrote:
On Monday, 10 April 2017 at 13:20:00 UTC, Matthias Klumpp wrote:
Btw, at time we are just ignore the ABI issues, and
surprisingly nothing broke yet, indicating that ABI breakage
isn't very common or not affecting commonly used
On Monday, 10 April 2017 at 16:12:35 UTC, Iain Buclaw wrote:
[...]
Everyone should follow GDC's ABI, rather than trying to mimic
DMD calling convention. ;-)
GDC is working very well, and using it would actually be the
natural choice for us as GCC is the default compiler.
However, there are
On Monday, 10 April 2017 at 14:33:34 UTC, qznc wrote:
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
1) Is there some perspective on D getting a defined ABI that
works with all major D compilers?
2) What would the D community recommend on how to deal with
the ABI issues
On Mon, Apr 10, 2017 at 11:40:12AM +, Matthias Klumpp via Digitalmars-d
wrote:
[...]
> Naturally, when the reference compiler is available in Debian, we
> would compile everything with that, as it is the development focus and
> the thing many people test with.
>
> We do, however, have quite a
On Monday, 10 April 2017 at 14:21:43 UTC, Gerald wrote:
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
There are a two issues though that we will be facing in Debian
soon, and I would like to get some opinion and maybe
perspective on from the D community on them.
First I
On Monday, 10 April 2017 at 15:11:01 UTC, Jack Stouffer wrote:
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
3) Will DMD support more architectures in the near future?
How should the architecture issue be handled?
This can be definitively answered as "no",
On Monday, 10 April 2017 at 13:20:00 UTC, Matthias Klumpp wrote:
Btw, at time we are just ignore the ABI issues, and
surprisingly nothing broke yet, indicating that ABI breakage
isn't very common or not affecting commonly used interfaces
much.
One big ABI change was in 2.071:
On 10 April 2017 at 15:20, Matthias Klumpp via Digitalmars-d
wrote:
> On Monday, 10 April 2017 at 13:07:22 UTC, Vladimir Panteleev wrote:
>>
>> On Monday, 10 April 2017 at 12:59:37 UTC, Matthias Klumpp wrote:
Who came up with those policies and decided that
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
3) Will DMD support more architectures in the near future?
How should the architecture issue be handled?
This can be definitively answered as "no",
https://issues.dlang.org/show_bug.cgi?id=15108
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
1) Is there some perspective on D getting a defined ABI that
works with all major D compilers?
2) What would the D community recommend on how to deal with
the ABI issues currently? A Linux distribution is a bunch of
tightly
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
There are a two issues though that we will be facing in Debian
soon, and I would like to get some opinion and maybe
perspective on from the D community on them.
First I would like to say thank you for all the work you did in
On Monday, 10 April 2017 at 12:59:58 UTC, qznc wrote:
[...]
How do Debian and C++ go along? There is no ABI compatibility
between GCC and Clang afaik.
Clang offers compatibility for most basic features. There are
some ABI compatibility issues though and you find them reported
in the
On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
Hi there!
[...]
If we do that, we will run into the D ABI trap: Libraries
compiled with compiler X can not be used from software compiled
with D compiler Y. There is actually no ABI stability guarantee
even between DMD releases.
On Monday, 10 April 2017 at 13:07:22 UTC, Vladimir Panteleev
wrote:
On Monday, 10 April 2017 at 12:59:37 UTC, Matthias Klumpp wrote:
Who came up with those policies and decided that they apply
to D? Because I really don't think they should.
[...]
You need to see here that D is not the center
1 - 100 of 106 matches
Mail list logo