On Thursday, 9 May 2013 at 10:15:42 UTC, Iain Buclaw wrote:
I'll will very likely keep a branch with the C++ implemented
front end for
these purposes. But ideally we should get porting as soon as
possible ahead
of this move so that there are already D compilers available
for said
targets.
On Saturday, 11 May 2013 at 15:09:24 UTC, Iain Buclaw wrote:
Actually, the more I sit down and think about it, the more I
question
whether or not it is a good idea for the D D front end to have
a dependency
on phobos. Maybe I should stop thinking in general. :)
Regards
Let me restate the
Am Sat, 11 May 2013 23:51:36 +0100
schrieb Iain Buclaw ibuc...@ubuntu.com:
I am more concerned from GDC's perspective of things. Especially
when it comes to building from hosts that may have phobos disabled
(this is a configure switch).
Indeed. Right now we can compile and run GDC on
On 5/11/2013 10:25 PM, Daniel Murphy wrote:
My thought was that you ensure (for the foreseeable future) that all D
versions of the compiler compile with the most recent C++ version of the
compiler.
That would likely mean the the D compiler sources must be compilable with 2.063.
On 2013-05-12 05:50, Jonathan M Davis wrote:
That helps considerably, though if the compiler is old enough, that won't work
for Linux due to glibc changes and whatnot.
My experience is the other way around. Binaries built on newer version
of Linux doesn't work on older. But binaries built on
On 12 May 2013 10:39, Jacob Carlborg d...@me.com wrote:
On 2013-05-12 05:50, Jonathan M Davis wrote:
That helps considerably, though if the compiler is old enough, that won't
work
for Linux due to glibc changes and whatnot.
My experience is the other way around. Binaries built on newer
On Sunday, 12 May 2013 at 09:48:58 UTC, Iain Buclaw wrote:
Depends... statically linked binaries will probably always work
on the
latest version, dynamic link and then you've got yourself a
'this
libstdc++v5 doesn't exist anymore' problem.
I am picturing a Linux workstation with the Post-It
On 12 May 2013 11:08, w0rp devw...@gmail.com wrote:
On Sunday, 12 May 2013 at 09:48:58 UTC, Iain Buclaw wrote:
Depends... statically linked binaries will probably always work on the
latest version, dynamic link and then you've got yourself a 'this
libstdc++v5 doesn't exist anymore' problem.
On Sunday, 12 May 2013 at 09:48:58 UTC, Iain Buclaw wrote:
On 12 May 2013 10:39, Jacob Carlborg d...@me.com wrote:
On 2013-05-12 05:50, Jonathan M Davis wrote:
That helps considerably, though if the compiler is old
enough, that won't
work
for Linux due to glibc changes and whatnot.
My
On 12 May 2013 11:39, John Colvin john.loughran.col...@gmail.com wrote:
On Sunday, 12 May 2013 at 09:48:58 UTC, Iain Buclaw wrote:
On 12 May 2013 10:39, Jacob Carlborg d...@me.com wrote:
On 2013-05-12 05:50, Jonathan M Davis wrote:
That helps considerably, though if the compiler is old
Walter Bright newshou...@digitalmars.com wrote in message
news:kmnk08$3qr$1...@digitalmars.com...
On 5/11/2013 10:25 PM, Daniel Murphy wrote:
My thought was that you ensure (for the foreseeable future) that all D
versions of the compiler compile with the most recent C++ version of the
On May 5, 2013 2:36 PM, Iain Buclaw ibuc...@gdcproject.org wrote:
Daniel and/or David,
We should list down in writing the issues preventing DMD, GDC, and LDC
having a shared code base. From what David has shown me, LDC will need the
most work for this, but I'll list down what I can remember.
Iain Buclaw ibuc...@ubuntu.com wrote in message
news:mailman.1201.1368284962.4724.digitalmar...@puremagic.com...
Actually, the more I sit down and think about it, the more I question
whether or not it is a good idea for the D D front end to have a
dependency
on phobos. Maybe I should stop
On Saturday, 11 May 2013 at 15:16:29 UTC, Daniel Murphy wrote:
Iain Buclaw ibuc...@ubuntu.com wrote in message
news:mailman.1201.1368284962.4724.digitalmar...@puremagic.com...
Actually, the more I sit down and think about it, the more I
question
whether or not it is a good idea for the D D
On Saturday, 11 May 2013 at 15:51:26 UTC, David Nadlinger wrote:
On Saturday, 11 May 2013 at 15:16:29 UTC, Daniel Murphy wrote:
Iain Buclaw ibuc...@ubuntu.com wrote in message
news:mailman.1201.1368284962.4724.digitalmar...@puremagic.com...
Actually, the more I sit down and think about it,
On Saturday, 11 May 2013 at 16:08:02 UTC, deadalnix wrote:
On Saturday, 11 May 2013 at 15:51:26 UTC, David Nadlinger wrote:
If we keep a must compile with several past versions policy
anyway, what would make Phobos special?
David
It prevent the use of newer feature of D in phobos.
?!
It
On Saturday, 11 May 2013 at 16:15:13 UTC, David Nadlinger wrote:
On Saturday, 11 May 2013 at 16:08:02 UTC, deadalnix wrote:
On Saturday, 11 May 2013 at 15:51:26 UTC, David Nadlinger
wrote:
If we keep a must compile with several past versions policy
anyway, what would make Phobos special?
On Saturday, 11 May 2013 at 16:27:37 UTC, deadalnix wrote:
On Saturday, 11 May 2013 at 16:15:13 UTC, David Nadlinger wrote:
On Saturday, 11 May 2013 at 16:08:02 UTC, deadalnix wrote:
On Saturday, 11 May 2013 at 15:51:26 UTC, David Nadlinger
wrote:
If we keep a must compile with several past
David Nadlinger s...@klickverbot.at wrote in message
news:llovknbpvcnksinsn...@forum.dlang.org...
On Saturday, 11 May 2013 at 15:16:29 UTC, Daniel Murphy wrote:
Iain Buclaw ibuc...@ubuntu.com wrote in message
news:mailman.1201.1368284962.4724.digitalmar...@puremagic.com...
Actually, the more
On Saturday, 11 May 2013 at 17:10:51 UTC, Daniel Murphy wrote:
If you decide that all later versions of the compiler must
compile with all
earlier versions of phobos, then those phobos modules are
unable to change.
In (the rare) case of breaking changes, we could always work
around them in
David Nadlinger s...@klickverbot.at wrote in message
news:mwkwqttkbdpmzvyvi...@forum.dlang.org...
On Saturday, 11 May 2013 at 17:10:51 UTC, Daniel Murphy wrote:
If you decide that all later versions of the compiler must compile with
all
earlier versions of phobos, then those phobos modules
On Saturday, 11 May 2013 at 17:23:53 UTC, Daniel Murphy wrote:
That... doesn't sound very nice to me. How much of phobos are
we
realistically going to need?
All of it? Well, not quite, but large parts at least.
If we are going to stick to the C subset of the language, there
is little point
On 5/11/13 1:10 PM, Daniel Murphy wrote:
Yes it's possible, but it seems like a really bad idea because:
- Phobos is huge
- Changes in phobos now have the potential to break the compiler
The flipside is:
- Phobos offers many amenities and opportunities for reuse
- Breakages in Phobos will be
On Saturday, 11 May 2013 at 17:36:18 UTC, Andrei Alexandrescu
wrote:
- Breakages in Phobos will be experienced early on a large
system using them
I've talked about this with Simon Peyton-Jones who was
unequivocal to assert that writing the Haskell compiler in
Haskell has had enormous
On Saturday, 11 May 2013 at 17:48:27 UTC, David Nadlinger wrote:
[…] the whole DDDMD effort […]
Whoops, must be a Freudian slip, revealing how much I'd like to
see the D compiler being written in idiomatic D. ;)
David
David Nadlinger s...@klickverbot.at wrote in message
news:bwkwvbjdykrnsdezp...@forum.dlang.org...
On Saturday, 11 May 2013 at 17:23:53 UTC, Daniel Murphy wrote:
That... doesn't sound very nice to me. How much of phobos are we
realistically going to need?
All of it? Well, not quite, but
David Nadlinger s...@klickverbot.at wrote in message
news:wynfxitcgpiggwemr...@forum.dlang.org...
On Saturday, 11 May 2013 at 17:36:18 UTC, Andrei Alexandrescu wrote:
- Breakages in Phobos will be experienced early on a large system using
them
I've talked about this with Simon Peyton-Jones
On 5/11/13 2:15 PM, Daniel Murphy wrote:
David Nadlingers...@klickverbot.at wrote in message
news:wynfxitcgpiggwemr...@forum.dlang.org...
On Saturday, 11 May 2013 at 17:36:18 UTC, Andrei Alexandrescu wrote:
- Breakages in Phobos will be experienced early on a large system using
them
I've
On Saturday, 11 May 2013 at 17:36:18 UTC, Andrei Alexandrescu
wrote:
On 5/11/13 1:10 PM, Daniel Murphy wrote:
Yes it's possible, but it seems like a really bad idea because:
- Phobos is huge
- Changes in phobos now have the potential to break the
compiler
The flipside is:
- Phobos offers
On Saturday, 11 May 2013 at 18:15:22 UTC, Daniel Murphy wrote:
If we use them in the compiler, we effectively freeze them. We
can't use
the new modules, because the old toolchains don't have them.
Fair enough, but in such a case we could always add the parts of
them we really need to the
11-May-2013 22:15, Daniel Murphy пишет:
If we aren't confident that we can write and maintain a large real-world
application in D just yet, we must pull the emergency brakes on the whole
DDDMD effort, right now.
David
I'm confident in D, just not in phobos. Even if phobos didn't exist, we'd
On Saturday, May 11, 2013 20:40:46 deadalnix wrote:
Except that now, it is a pain to migrate old haskell stuff to
newer haskelle stuff if you missed several compile release.
You ends up building recursively from the native version to the
version you want.
Yeah. And I'm stuck with the
On Saturday, 11 May 2013 at 21:09:57 UTC, Jonathan M Davis wrote:
On Saturday, May 11, 2013 20:40:46 deadalnix wrote:
Except that now, it is a pain to migrate old haskell stuff to
newer haskelle stuff if you missed several compile release.
You ends up building recursively from the native
Am 11.05.2013 23:43, schrieb John Colvin:
On Saturday, 11 May 2013 at 21:09:57 UTC, Jonathan M Davis wrote:
On Saturday, May 11, 2013 20:40:46 deadalnix wrote:
Except that now, it is a pain to migrate old haskell stuff to
newer haskelle stuff if you missed several compile release.
You ends up
On May 11, 2013 6:35 PM, David Nadlinger s...@klickverbot.at wrote:
On Saturday, 11 May 2013 at 17:23:53 UTC, Daniel Murphy wrote:
That... doesn't sound very nice to me. How much of phobos are we
realistically going to need?
All of it? Well, not quite, but large parts at least.
If we
On Saturday, May 11, 2013 23:43:19 John Colvin wrote:
Can't this be eased with readily available binaries and cross
compilation?
E.g. We drop the C++ version in 2.7. You want DMD version 2.8.2.
The minimum needed to compile 2.8.2 is 2.7.5:
You can download a binary of 2.7.5 for any common
On 5/11/2013 2:09 PM, Jonathan M Davis wrote:
I have to be able
to build old haskell code without updating it,
I guess this is the crux of the matter. Why can't you update the source?
On Saturday, May 11, 2013 17:51:24 Walter Bright wrote:
On 5/11/2013 2:09 PM, Jonathan M Davis wrote:
I have to be able
to build old haskell code without updating it,
I guess this is the crux of the matter. Why can't you update the source?
Well, in this particular case, it has to do with
On 5/11/2013 6:09 PM, Jonathan M Davis wrote:
So, we might be better of restricting how much the compiler depends on - or we
may decide that the workaround is to simply build the last C++ version of the
compiler and then move forward from there. But I think that the issue should
at least be
On Saturday, May 11, 2013 18:18:27 Walter Bright wrote:
On 5/11/2013 6:09 PM, Jonathan M Davis wrote:
So, we might be better of restricting how much the compiler depends on -
or we may decide that the workaround is to simply build the last C++
version of the compiler and then move forward
On 5/11/2013 7:30 PM, Jonathan M Davis wrote:
But in theory, the way to solve the problem of your program not compiling with
the new compiler is to compile with the compiler it was developed with in the
first place, and then if you want to upgrade your code, you upgrade your code
and use it with
On Saturday, May 11, 2013 19:56:00 Walter Bright wrote:
At least for dmd, we keep all the old binaries up and downloadable for that
reason.
That helps considerably, though if the compiler is old enough, that won't work
for Linux due to glibc changes and whatnot. I expect that my particular
Jonathan M Davis jmdavisp...@gmx.com wrote in message
news:mailman.1222.1368325870.4724.digitalmar...@puremagic.com...
The big problem is when you need to compile
the compiler. You have a circular dependency due to the compiler depending
on
itself, and have to break it somehow. As long as
Do you plan to support a build path that has no circular dependendencies?
This would be a very strong nice to have for porting D to new architectures.
So it should be possible to build a subset of D (stage 1) with gcc without
relying on a D compiler and than using the stage 1 binary to build a
On 9 May 2013 10:11, Thomas Koch tho...@koch.ro wrote:
Do you plan to support a build path that has no circular dependendencies?
This would be a very strong nice to have for porting D to new
architectures.
So it should be possible to build a subset of D (stage 1) with gcc without
relying on
On Thursday, 9 May 2013 at 09:11:05 UTC, Thomas Koch wrote:
There are languages in Debian that rely on themselves to be
build and it's a
headache to support those languages on all architectures.
Wouldn't the normal workflow for porting to a new platform be
to start out with a cross-compiler
On 9 May 2013 12:50, David Nadlinger s...@klickverbot.at wrote:
On Thursday, 9 May 2013 at 09:11:05 UTC, Thomas Koch wrote:
There are languages in Debian that rely on themselves to be build and
it's a
headache to support those languages on all architectures.
Wouldn't the normal workflow
On 9 May 2013 13:06, Iain Buclaw ibuc...@ubuntu.com wrote:
On 9 May 2013 12:50, David Nadlinger s...@klickverbot.at wrote:
On Thursday, 9 May 2013 at 09:11:05 UTC, Thomas Koch wrote:
There are languages in Debian that rely on themselves to be build and
it's a
headache to support those
Daniel Murphy yebbl...@nospamgmail.com wrote in message
news:km7lir$48g$1...@digitalmars.com...
Walter Bright newshou...@digitalmars.com wrote in message
news:km7fml$2rka$1...@digitalmars.com...
When devising solutions, I want to prefer solutions that do not rely on
#ifdef/#endif. I've
Walter Bright newshou...@digitalmars.com wrote in message
news:km7fml$2rka$1...@digitalmars.com...
When devising solutions, I want to prefer solutions that do not rely on
#ifdef/#endif. I've tried to scrub those out of the dmd front end source
code.
I completely agree. But - refactoring
On 6 May 2013 08:19, Daniel Murphy yebbl...@nospamgmail.com wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:km7fml$2rka$1...@digitalmars.com...
When devising solutions, I want to prefer solutions that do not rely on
#ifdef/#endif. I've tried to scrub those out of the
On 6 May 2013 05:16, Daniel Murphy yebbl...@nospamgmail.com wrote:
Iain Buclaw ibuc...@gdcproject.org wrote in message
news:qtcogcbrhfzjvuoay...@forum.dlang.org...
Daniel and/or David,
We should list down in writing the issues preventing DMD, GDC, and LDC
having a shared code base.
Daniel and/or David,
We should list down in writing the issues preventing DMD, GDC,
and LDC having a shared code base. From what David has shown me,
LDC will need the most work for this, but I'll list down what I
can remember.
1. Support extern(C++) classes so can have a split C++/D
On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
15. Deal with all C++ - D conversion
15. Deal with all C++ - D conversion issues (see all DDMD marked
pull requests).
16. Testing the C++ - D front end conversion on Linux. Daniel
you can send me the sources to test that if
On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
13. LDC makes some more arbitrary changes to which the reason
for the change has been forgotten. Get on it David! :o)
This applies only to a small part of the changes. The larger
share of them will actually need adaption of the
On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
12. LDC adds extra reserved version identifiers that are not
allowed to be declared in D code. This could and probably
should be merged into D front end. Don't think it would be wise
to let back end's have the ability to add their own.
On May 5, 2013 3:30 PM, David Nadlinger s...@klickverbot.at wrote:
On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
13. LDC makes some more arbitrary changes to which the reason for the
change has been forgotten. Get on it David! :o)
This applies only to a small part of the
On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
1. Support extern(C++) classes so can have a split C++/D
implementation of eg: Expression and others.
I don't know if this will be in the videos, so I'll ask here. I
thought extern(C++) only supported interfaces because everything
On May 5, 2013 5:20 PM, lt;luismarq...@gmail.comgt;quot;@puremagic.com
quot;\quot;Luísquot;.Marquesquot; wrote:
On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
1. Support extern(C++) classes so can have a split C++/D implementation
of eg: Expression and others.
I don't know if
On 5/5/2013 9:17 AM, Luís Marques luismarq...@gmail.com wrote:
On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
1. Support extern(C++) classes so can have a split C++/D implementation of eg:
Expression and others.
I don't know if this will be in the videos, so I'll ask here. I
On Sunday, 5 May 2013 at 20:33:15 UTC, Walter Bright wrote:
extern(C++) interfaces are ABI compatible with C++ com
classes - i.e. single inheritance, no constructors or
destructors.
That I know, thanks, I just understood that point one meant some
additional extern(C++) support:
1. Support
Iain Buclaw ibuc...@gdcproject.org wrote in message
news:qtcogcbrhfzjvuoay...@forum.dlang.org...
Daniel and/or David,
We should list down in writing the issues preventing DMD, GDC, and LDC
having a shared code base. From what David has shown me, LDC will need
the most work for this, but
I'm expecting lots of positive comments when I get off my flight in 14
hours.
Daniel Murphy yebbl...@nospamgmail.com wrote in message
news:km7aqo$2kv4$1...@digitalmars.com...
Iain Buclaw ibuc...@gdcproject.org wrote in message
news:qtcogcbrhfzjvuoay...@forum.dlang.org...
Daniel and/or
When devising solutions, I want to prefer solutions that do not rely on
#ifdef/#endif. I've tried to scrub those out of the dmd front end source code.
64 matches
Mail list logo
