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 i
On Tue, 26 Aug 2014 23:16:14 -0700
Ali Çehreli via Digitalmars-d-announce
wrote:
> * Formatted element output with %( and %)
by the way, i never knows about this feature. maybe i should RTFM
someday...
signature.asc
Description: PGP signature
On Tue, 26 Aug 2014 23:16:14 -0700
Ali Çehreli via Digitalmars-d-announce
wrote:
> * The 'User Defined Attributes (UDA)' chapter
great!
> * static this, static ~this, shared static this, and shared static
> ~this
and this too.
signature.asc
Description: PGP signature
I made some additions and corrections. The following are the major ones:
* The 'User Defined Attributes (UDA)' chapter
* @nogc
* foreach_reverse
* Formatted element output with %( and %)
* static this, static ~this, shared static this, and shared static ~this
As a reminder, the book is avail
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.
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 artific
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 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
Phobos
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 comm
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 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: redu
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 artifici
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 st
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 coul
On Wednesday, 20 August 2014 at 04:48:02 UTC, Kai Nacke wrote:
I managed to get mentioned in LLVM Weekly again.
(http://llvmweekly.org/issue/33)
LLVM weekly is a newsletter with high attention in the LLVM
world.
Regards,
Kai
Cool!
"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
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 libr
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: t
"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 8/26/14, 9:46 AM, Dicebot wrote:
...and it has just been merged! ^_^
Thanks Walter!
Congratulations for a job well done. -- Andrei
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 bet
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 a
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 8/26/2014 8:30 AM, Mike wrote:
If core.stdcpp is intended to be the language bindings to libstdc++, I don't
think it should belong it D's language implementation, druntime, any more the
language bindings to Cairo or GTK should.
The same goes for core.stdc and core.sys.linux and friends, as th
On Tue, 26 Aug 2014 16:46:19 +
Dicebot via Digitalmars-d-announce
wrote:
> ..and it has just been merged! ^_^
WOW! that's great!
> Thanks Walter!
second that!
signature.asc
Description: PGP signature
..and it has just been merged! ^_^
Thanks Walter!
On Wednesday, 20 August 2014 at 04:48:02 UTC, Kai Nacke wrote:
On Friday, 15 August 2014 at 15:04:44 UTC, Kai Nacke wrote:
Hi everyone,
LDC 0.14.0, the LLVM-based D compiler, is available for
download!
This release is based on the 2.065.0 frontend and standard
library and supports LLVM 3.1-3.
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 not
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 to
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 d
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 Thursday, 7 August 2014 at 23:36:59 UTC, Brian Schott wrote:
dscanner: https://github.com/Hackerpilot/Dscanner
Thanks for dscanner - a really helpful tool.
BTW
Your build.bat as of 2014-08-25 didn't work for me - it produced
wrong paths, e.g. (shortened):
dmd src\astprinter.d src\ctags.d
On Saturday, 23 August 2014 at 13:19:18 UTC, dlangophile wrote:
On Thursday, 14 August 2014 at 07:51:11 UTC, Alex wrote:
On Thursday, 14 August 2014 at 07:07:59 UTC, Alex wrote:
Invoking stuff is easy. I'd rather reimplement the
communication to the dcd server instead to not get such a
bottlen
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.
C++ interoperability is very important for D's future. -- Andrei
On Friday, 22 August 2014 at 21:41:13 UTC, Andrew Edwards wrote:
On 8/23/14, 3:33 AM, Andrei Alexandrescu wrote:
On 8/22/14, 10:05 AM, John Colvin wrote:
As I'm sure has been mentioned elsewhere, the website changes
should be
part of the release process, not an afterthought.
Agreed. Who woul
"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 de
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 you
"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 availa
"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++
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
un
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 scop
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 purpos
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 purpo
I've created a set of Zeus Python scripts to allow
the Dscanner to be run from inside Zeus.
The Dscanner will need to be downloaded and built
form here:
https://github.com/Hackerpilot/Dscanner
The Zeus scripts can be found here:
http://www.zeusedit.com/zforum/viewtopic.php?t=7196
Note: I'm th
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 them
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 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 Tue, 26 Aug 2014 07:00:26 +
Ola Fosheim Gr via Digitalmars-d-announce
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 shouldn't need to have
> > to see
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, a
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 "gener
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 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 shouldn't need to have
to see that ugliness, though.
Sounds easier to write your own ::std:: on the c++ side...
52 matches
Mail list logo