On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote:
On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote:
On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright
wrote:
I'm judging by both the responses in this thread
On Saturday, 30 August 2014 at 08:39:12 UTC, eles wrote:
On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote:
On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote:
On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright
On 2014-08-29 23:00, simendsjo wrote:
It's still available at dsource: http://www.dsource.org/projects/ares
I don't think he's referring to Ares, he's referring to some other D
runtime.
--
/Jacob Carlborg
On Friday, 29 August 2014 at 16:37:12 UTC, Sean Kelly wrote:
On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
I'm asking this community to consider setting a new precedent
for druntime: reduce the scope to just the language
On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
I'm asking this community to consider setting a new precedent
for druntime: reduce the scope to just the language
implementation, encapsulate and isolate the platform specific
On Wednesday, 27 August 2014 at 21:38:04 UTC, deadalnix wrote:
The problem is that you don't always want to bring libc and
libstdc++ with you with every single project you write.
Thus it shouldn't be in the runtime (except the very bit you
can't get rid of). It can still be core.stdc .
To
On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote:
eles wrote in message
news:rixtiaiokrukvqjsf...@forum.dlang.org...
One such platform exists and is the embedded system, others
are the linux kernel and the like, and even others are writing
D compiler back-ends and, yes,
On 8/27/2014 2:38 PM, deadalnix wrote:
The problem is that you don't always want to bring libc and libstdc++ with you
with every single project you write.
Remember that a library is not simply inserted bodily into the executable. A
library is searched for modules that define unresolved
On 8/29/14, 10:02 AM, Sean Kelly wrote:
Don't get me wrong, I hate having to maintain the modules in
core.stdc and core.sys. It's the worst job ever.
It's also one of those jobs silently appreciated by many. -- Andrei
On 08/29/2014 07:07 PM, Sean Kelly wrote:
On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote:
eles wrote in message news:rixtiaiokrukvqjsf...@forum.dlang.org...
One such platform exists and is the embedded system, others are the
linux kernel and the like, and even others are
On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote:
On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright
wrote:
The irony is D1 has std.c, and for D2 it was migrated to
core.stdc.
...and design takes the backseat to
On 8/26/2014 5:32 PM, Mike wrote:
We currently have std.c and core.stdc. I believe core.stdc should be
migrated to std.c, not the other way around. And before we make the same
mistake with core.stdcpp, we should set a new precedent with std.cpp instead.
The irony is D1 has std.c, and for D2
eles wrote in message news:ybcxmuwwpsiyupwer...@forum.dlang.org...
The question of dupplication may be addressed now better, since the newly
fixed bug about hierarchical packaging.
I don't see how.
_only that_ should be the runtime. And the sole part that one needs to
port in order to
On Wednesday, 27 August 2014 at 07:52:18 UTC, Daniel Murphy wrote:
eles wrote in message
news:ybcxmuwwpsiyupwer...@forum.dlang.org...
Requiring full c/OS bindings in druntime is so useful, and it
costs us so little.
But the request is simply to split the current druntime in a
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote:
On 8/26/2014 5:32 PM, Mike wrote:
Moving it back in an endless search for taxonomical perfection
Well, keeping things in limbo for such many years (@property,
anyone?) is not going to help neither.
I agree it is a fine
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote:
On 8/26/2014 5:32 PM, Mike wrote:
We currently have std.c and core.stdc. I believe core.stdc
should be
migrated to std.c, not the other way around. And before we
make the same
mistake with core.stdcpp, we should set a new
On Wednesday, 27 August 2014 at 02:17:39 UTC, Dicebot wrote:
On Wednesday, 27 August 2014 at 01:57:38 UTC, Mike wrote:
What do you think about following compromise:
1) C bindings are defined in spec to be optional
2) They are still kept in druntime repo but declared an
implementation detail
eles wrote in message news:rixtiaiokrukvqjsf...@forum.dlang.org...
But the request is simply to split the current druntime in a
language-runtime and a phobos-runtime. The namespace and so on might even
remain the same and the existing code would run unmodified. What is really
important is
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote:
On 8/26/2014 5:32 PM, Mike wrote:
We currently have std.c and core.stdc. I believe core.stdc
should be
migrated to std.c, not the other way around. And before we
make the same
mistake with core.stdcpp, we should set a new
On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote:
Mike wrote in message
news:sdrjfagsayomsngme...@forum.dlang.org...
line between the language and the platform. Make it a more of
a language, and less of a framework.
On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
Apparently, all things have this tendency to get bloated. One
of the main reasons for C's still unbelievable success is its
slimness.
Yeah, I think C's success is directly linked to having a clear
use scenario and avoiding being a
On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:
The C standard library and C++ standard library are not part of
D-the-language. D would even be better served by putting these
features in phobos as std.stdc and std.stdcpp. This would make
them just as conveniently available to users,
On Tue, 26 Aug 2014 07:00:26 +
Ola Fosheim Gr via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote:
The implementation of it, however, is going to be ugly and very
specific to each C++ compiler. The user
On Tuesday, 26 August 2014 at 08:25:58 UTC, Jonathan M Davis via
Digitalmars-d-announce wrote:
Quite possibly, but then it wouldn't integrate with existing
C++ libraries
built with the system's C++ compiler, which would be the point.
I know, but the vendor provided C++ libraries could trigger
On Tuesday, 26 August 2014 at 08:15:07 UTC, Marc Schütz wrote:
On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote:
The C standard library and C++ standard library are not part
of D-the-language. D would even be better served by putting
these features in phobos as std.stdc and std.stdcpp.
On Tuesday, 26 August 2014 at 06:35:18 UTC, Walter Bright wrote:
On 8/25/2014 11:12 PM, Mike wrote:
The C standard library and C++ standard library are not part
of D-the-language.
D would even be better served by putting these features in
phobos as std.stdc
and std.stdcpp. This would make
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
Yeah, I think C's success is directly linked to having a clear
use scenario and avoiding being a general purpose language
What? C is THE quintessential general
On Tuesday, 26 August 2014 at 10:44:03 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
Yeah, I think C's success is directly linked to having a clear
use scenario and avoiding being a general
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote:
convenient inlining and operator overloading. So people use it
For me, what it would be really nice to have in C from C++ would
be templates.
And from D, that
On Tuesday, 26 August 2014 at 10:57:10 UTC, eles wrote:
For me, what it would be really nice to have in C from C++
would be templates.
And from D, that scope().
When I think about it, I think one of the reasons for going from
C to C++ in visualization/games was that 3D operations in C are
Ola Fosheim Grøstad wrote in message
news:pbfaphgiugafrhach...@forum.dlang.org...
I know, but the vendor provided C++ libraries could trigger compiler-magic
in the optimizer, so it might not be enough to look at the source code in
the general case…
I would be very surprised to find a C++
Mike wrote in message news:zjscnxerhbxnopvay...@forum.dlang.org...
The C standard library and C++ standard library are not part of
D-the-language. D would even be better served by putting these features
in phobos as std.stdc and std.stdcpp. This would make them just as
conveniently
On Tuesday, 26 August 2014 at 12:23:18 UTC, Daniel Murphy wrote:
I would be very surprised to find a C++ compiler that does this
over public function boundaries, as it would prevent mixing
optimized and unoptimized code.
Probably, at least without whole-program optimization turned on.
But
Ola Fosheim Grøstad wrote in message
news:mclztlymyjydwhcxs...@forum.dlang.org...
Probably, at least without whole-program optimization turned on.
Linking with D is not a concern for whole-program-optimized C++ programs.
But you still have to track compiler version changelogs and then deal
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu
wrote:
On 8/26/14, 3:06 AM, Mike wrote:
D has a lot of potential beyond it's current use. Please take
this
opportunity to reflect on what's been done, take a look ahead,
and see
if we can set a better precedent for the future.
On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu
wrote:
On 8/26/14, 3:06 AM, Mike wrote:
The same goes for core.stdc and core.sys.linux and friends, as
these are not part of D's language implementation.
Am I correct to
On Tuesday, 26 August 2014 at 12:54:49 UTC, Daniel Murphy wrote:
I really don't see a practical problem with having them in
druntime, only a philosophical one.
It give the impression that D requires the C standard library,
the C++ standard library, and an full-featured desktop OS in
order
On Tuesday, 26 August 2014 at 15:44:31 UTC, eles wrote:
On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei
Alexandrescu wrote:
On 8/26/14, 3:06 AM, Mike wrote:
The same goes for core.stdc and core.sys.linux and friends, as
these are
On Tuesday, 26 August 2014 at 18:13:01 UTC, eles wrote:
On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:
On 8/26/2014 8:30 AM, Mike wrote:
wow. I remember the hot debate about the name o the standard
library back then.
well, namesace name
On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:
On 8/26/2014 8:30 AM, Mike wrote:
Regardless of where stdcpp goes, one issue is that the stuff in
it goes into the namespace std, which conflicts with Phobos'
std higher level package name.
wow. I remember the hot debate
On 8/26/14, 8:30 AM, Mike wrote:
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote:
On 8/26/14, 3:06 AM, Mike wrote:
D has a lot of potential beyond it's current use. Please take this
opportunity to reflect on what's been done, take a look ahead, and see
if we can set a
Mike wrote in message news:bkkdiikafdsraqssj...@forum.dlang.org...
I really don't see a practical problem with having them in druntime,
only a philosophical one.
It give the impression that D requires the C standard library, the C++
standard library, and an full-featured desktop OS in
On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote:
On 8/26/2014 8:30 AM, Mike wrote:
There's never going to be a clear distinction between druntime
and phobos. The original reason for the split anyway was
druntime would be a
Well, in C there is and I like that distinction:
On Tuesday, 26 August 2014 at 18:33:07 UTC, Daniel Murphy wrote:
Mike wrote in message
news:bkkdiikafdsraqssj...@forum.dlang.org...
I really don't see a practical problem with having them in
druntime, only a philosophical one.
It give the impression that D requires the C standard
eles wrote in message news:qrfucjdbmydvoqgey...@forum.dlang.org...
While this might be acceptable, there is one more question: what use to
have the druntime separated from phobos, in this case?
Apart from the fact that it's too late to change of course.
For me the druntime shall include
On Tuesday, 26 August 2014 at 19:22:22 UTC, Daniel Murphy wrote:
eles wrote in message
news:qrfucjdbmydvoqgey...@forum.dlang.org...
Apart from the fact that it's too late to change of course.
Well, that separation is just a detail of the implementation, not
of the specification. You could
On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu
wrote:
I don't understand the objection. Are you arguing that we
shouldn't make core.stdc and core.stdcpp available, and instead
let anyone who wants to use libc and libc++ write their own
declarations?
No. We currently have
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
I'm asking this community to consider setting a new precedent
for druntime: reduce the scope to just the language
implementation, encapsulate and isolate the platform specific
logic (e.g. the ports - see 11666), and deport the
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
I believe druntime's scope should be reduced to simply
implementing the language, not creating an OS or library API.
That's what phobos and DUB are for.
I'm asking this community to consider setting a new precedent
for druntime:
On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu
wrote:
On 8/26/14, 3:06 AM, Mike wrote:
D has a lot of potential beyond it's current use. Please take
this
opportunity to reflect on what's been done, take a look ahead,
and see
if we can set a better precedent for the future.
On Wednesday, 27 August 2014 at 01:05:19 UTC, Dicebot wrote:
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
I believe druntime's scope should be reduced to simply
implementing the language, not creating an OS or library API.
That's what phobos and DUB are for.
I'm asking this
On Wednesday, 27 August 2014 at 01:57:38 UTC, Mike wrote:
What do you think about following compromise:
1) C bindings are defined in spec to be optional
2) They are still kept in druntime repo but declared an
implementation detail
3) C bindings are defined to be mandatory in Phobos - if
On Wednesday, 27 August 2014 at 01:21:59 UTC, deadalnix wrote:
I think this cannot be understated. People have existing
codebase
that they aren't going to rewrite from scratch.
PS: This is the reason why SDC unwind C++'s exception properly
(but you obviously can't catch them).
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
I'm asking this community to consider setting a new precedent
for druntime: reduce the scope to just the language
implementation, encapsulate and isolate the platform specific
logic (e.g. the ports - see 11666), and deport the
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu
wrote:
No. We currently have std.c and core.stdc.
Let's not even say this is confusing.
55 matches
Mail list logo
