On 7/29/2018 9:53 PM, Manu wrote:
On Sun, 29 Jul 2018 at 20:25, Walter Bright via Digitalmars-d
wrote:
On 7/29/2018 7:50 PM, Nicholas Wilson wrote:
No it doesn't.
I meant that you can today "reopen" namespace scopes by placing them in separate
modules.
That's not the same th
On 7/29/2018 7:50 PM, Nicholas Wilson wrote:
No it doesn't.
I meant that you can today "reopen" namespace scopes by placing them in separate
modules.
You can (today) also "reopen" namespace scopes by placing them in separate mixin
templates, or struct declarations. I posted examples.
On 7/29/2018 1:52 PM, Manu wrote:
On Sun, 29 Jul 2018 at 05:10, kinke via Digitalmars-d
wrote:
[...]
so that a straight C++ namespace => D module hierarchy mapping
would probably be required in the general case:
```
// cppns/package.d
module cppns;
extern(C++, "cppns") { void foo(); }
//
On 7/29/2018 2:44 PM, Seb wrote:
FYI: this doesn't error as of now,
Right, but also you cannot specify which will be called.
On 7/29/2018 1:45 PM, Manu wrote:
There's no way you'll get a bug report from someone complaining they
can't multiply define symbols in the same scope. That's common sense.
But then you cannot interface with this C++ code:
namespace ab { void foo(); }
namespace cd { void foo(); }
Why
On 7/29/2018 1:52 PM, Manu wrote:
On Sun, 29 Jul 2018 at 05:10, kinke via Digitalmars-d
wrote:
[...]
so that a straight C++ namespace => D module hierarchy mapping
would probably be required in the general case:
```
// cppns/package.d
module cppns;
extern(C++, "cppns") { void foo(); }
//
The name can be "transferred" into the global namespace using an alias.
This boilerplate can all be put inside of a string mixin.
On 7/29/2018 1:15 AM, Manu wrote:
All we're asking for is that C++ namespaces do **nothing** except affect the
mangling.
If I do that, the next bug report will be:
extern (C++, "ab") { void foo(); }
extern (C++, "cd") { void foo(); } // Error, foo() is already declared
foo(); // which
On 7/28/2018 9:23 PM, Manu wrote:
Don't troll me on this one, this is a very sensitive topic!
I could have a legit mental breakdown ;)
Here's another method:
--
extern (C++, ns) { int foo() { return 1; } }
mixin template X()
{
extern (C++, ns) { int bar() { return 2; } }
}
mixin X!()
On 7/28/2018 11:06 PM, Nicholas Wilson wrote:
Then again I don't see any (non philosophical/compiler front end internal) issue
why you can't reopen a namespace. D is supposed to be pragmatic, after all.
Consider if a template reopens a namespace and throws a few more overloads in
it. Then,
On 7/28/2018 11:18 AM, Manu wrote:
Make a PR that implements namespace as a string... I will use that fork of D
forever.
1. Look how it is mangled on the C++ side. (Use "grep" on the object file.)
2. Use:
pragma(mangle, "the mangled name")
On 7/28/2018 7:09 AM, Laeeth Isharc wrote:
Opportunities are
abundant where people aren't looking because they don't want to.
My father told me I wasn't at all afraid of hard work. I could lie down right
next to it and go to sleep.
On 7/25/2018 4:27 PM, Laeeth Isharc wrote:
I think it's more interesting to be the change you
wish to see in the world.
Haha, the whole point of me starting D. I was tired of trying to convince
entrenched interests (and I wasn't very good at that).
On 7/27/2018 4:15 PM, Laeeth Isharc wrote:
Can you think of a pragmatic solution to Atila's problem?
One way is for the C++ => D translator to gather all the members of a namespace
before trying to emit them. Since D does not impose an order on declarations
(unlike C++) it is not constrained
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D
compiler how to mangle symbols.
Namespaces have semantic implications, too, such as overload resolutions. A
namespace introduces a new scope, not just a mangling.
> But why does this not compile?
>
On 7/25/2018 3:46 PM, Ecstatic Coder wrote:
C++ string constants are stupid pointers, no size etc. Indeed one big C++ silly
thing that Walter fixed perfectly. He is the only language designed who found
and applied the perfect solution for strings, arrays and slices. Big respect to
him...
Not
On 7/25/2018 2:08 AM, Jim Balter wrote:
It ought to be obvious that "just use better tools" is far cheaper and more
effective, but I think one of the problems is something that I also see in
politics quite a bit: a lot of people are more interested in feeling superior or
punishing people for
On 7/24/2018 4:53 AM, Ecstatic Coder wrote:
str = str1 + " " + str2;
But you have to be careful how it is written:
str = "hello" + "world";
str = "hello" + "world" + str1;
don't work, etc.
On 7/23/2018 5:39 AM, Joakim wrote:
In my experience, people never learn, even from the blatantly obvious,
_particularly_ when they're invested in the outdated. What inevitably happens is
the new tech gets good enough to put them out of business, then they finally
pick it up or retire. Until
On 7/23/2018 4:51 AM, Jim Balter wrote:
The responses are not encouraging, but I suppose they're useful for sociologists
studying fallacious thinking.
A big motivation for starting D was not having to convince the C/C++ community
of such things. I'd rather write code than argue.
On 7/21/2018 11:53 PM, Walter Bright wrote:
My article C's Biggest Mistake on front page of https://news.ycombinator.com !
Direct link:
https://news.ycombinator.com/item?id=17585357
My article C's Biggest Mistake on front page of https://news.ycombinator.com !
On 7/15/2018 2:46 PM, tcb wrote:
Thank you both, that clarifies a lot!
You can set the start address with the DMC C compiler using a #pragma:
https://www.digitalmars.com/ctg/pragmas.html#startaddress
but currently that isn't directly settable with the DMD compiler.
You can see how it is
On 7/15/2018 1:29 PM, tcb wrote:
I've been trying to compile a trivial program (extern C int main() {return 0;})
without linking parts of the C runtime with no success.
Declaring a C function called "main" causes the C runtime library to be pulled
in. After all, main() is not the program
On 7/12/2018 2:22 PM, Luís Marques wrote:
On Thursday, 12 July 2018 at 21:16:02 UTC, Walter Bright wrote:
as Python's BDFL.
Don't get any ideas!
I have no plans to resign until they carry me out in a box.
as Python's BDFL.
https://mail.python.org/pipermail/python-committers/2018-July/005664.html
On 7/11/2018 4:56 PM, John Carter wrote:
I disagree with Bjarne Stroustrup on many things but in this article he is
absolutely spot on. https://www.artima.com/intv/goldilocks3.html
It's a great article, and a quick read.
On 7/11/2018 11:27 AM, Brad Roberts wrote:
When you're afraid of your software and afraid to make changes to it, you make
bad choices. Embrace every strategy you can find to help you find problems as
quickly as possible.
It's good to hear my opinions on the subject backed by major
On 7/11/2018 6:54 PM, Brad Roberts wrote:
Anyway, this is one of the areas where people clearly have different
philosophies and changing minds is unlikely to happen.
True, but that doesn't mean each philosophy is equally valid. Some ideas are
better than others :-)
BTW, the "fail fast with
On 7/10/2018 12:21 PM, Timon Gehr wrote:
Which threads are those?
Here's one:
https://digitalmars.com/d/archives/digitalmars/D/Program_logic_bugs_vs_input_environmental_errors_244143.html
Have fun, it may take upwards of a week to read that one!
On 7/10/2018 8:39 AM, H. S. Teoh wrote:
The saving grace to real mode DOS was that rebooting was so fast.
I beg to differ. Boot time has been about the same for the last 40 years :-)
On 7/10/2018 12:21 PM, Timon Gehr wrote:
On 03.07.2018 06:54, Walter Bright wrote:
(I'm referring to the repeated and endless threads here where people argue
that yes, they can recover from programming bugs!)
Which threads are those?
I'd have to google for them. Maybe try searching
On 7/9/2018 6:50 PM, John Carter wrote:
Nothing creates flaky and unreliable systems more than allowing them to wobble
on past the first point where you already know that things are wrong.
Things got so bad with real mode DOS development that I rebooted the system
every time my program
On 7/5/2018 3:26 PM, H. S. Teoh wrote:
people keep tripping over the terminology
Some people do. However, the long threads of debate on this topic was with
people who were clear on what the terminology meant.
On 7/4/2018 10:22 AM, H. S. Teoh wrote:
Actually, what will make dmd produce better code IMO is: (1) a more
aggressive metric for the inliner (currently it gives up too easily, at
the slightest increase in code complexity), and (2) implement loop
unrolling.
It's already doing some loop
On 7/3/2018 4:03 PM, H. S. Teoh wrote:
Hopefully this eventually translates to actual improvements to the
optimizer?
That's the plan. D code is a lot more malleable than C++.
A small, but important milestone has been achieved!
Many thanks for the help from Sebastian Wilzbach and Rainer Schuetze.
On 7/2/2018 7:53 PM, John Carter wrote:
Step 2 is to (gradually) migrate std:: standard library precondition
violations in particular from exceptions (or error codes) to contracts. The
programming world now broadly recognizes that programming bugs (e.g.,
out-of-bounds access, null dereference,
Please post bug reports (including documentation problems) on bugzilla!
On 6/30/2018 3:04 PM, Jonathan M Davis wrote:
>> Just quote the bit you are responding to, and then only enough to cue
>> the reader to just what you are responding to.
Quoting at least _part_ of the message is highly desirable for those using
the mailing list, even it's very abbreviated.
What
When replying to message in the forum, please don't quote the entire message and
then add a little bit to the end. News readers are quite capable of displaying
the context to the reader. Just quote the bit you are responding to, and then
only enough to cue the reader to just what you are
On 6/29/2018 2:34 AM, Mike Franklin wrote:
I doubt there'd be any problem have DConf anywhere in the world as long is it is
properly funded. Who in Asia would be willing to sponsor it?
Mike is right on both counts.
On 6/29/2018 1:43 AM, Ecstatic Coder wrote:
Game development is a very special use case, but personally I don't think that
many of those who use C++ for close-to-the-metal development should be that much
interested in switching to D, because most of its standard libraries depend on
the
On 6/22/2018 3:03 PM, Adam D. Ruppe wrote:
On Friday, 22 June 2018 at 21:37:07 UTC, Walter Bright wrote:
I decided to accept the Mission Impossible of figuring out why it was inferred
as @system.
This would be trivial if the compiler had decent error messages.
https://issues.dlang.org
In trying to get Phobos to compile with dip1000, I was faced with the following
innocuous looking line:
assert(equal(achr, arr), text(a.byCodepoint));
https://github.com/dlang/phobos/blob/master/std/uni.d#L3763
and the compiler complained that `text(a.byCodepoint)` was a system call. I
On 6/18/2018 11:42 PM, aliak wrote:
Is the extern(C++) on semanticTraits remnants from converting dmd to d?
No, it's to be callable from the 3 non-D back ends.
On 6/18/2018 3:54 AM, Timon Gehr wrote:
The code you linked to does it. :)
I know. But it shouldn't. Do as I say, not as I do :-)
On 6/15/2018 11:08 PM, DigitalDesigns wrote:
When an identifier starts with __, allMembers does not return it. This is very
bad behavior! It can silently create huge problems if the programmer is not
aware of the bug.
It's not a bug, it's quite deliberate:
On 6/14/2018 12:30 PM, Jordan Wilson wrote:
I remember reading your answer on how you generate income. You said you bought
high and sold low. I suffered several losses before I realised your particular
sense of humor.
My superpower is control over the stock market. Immediately after I buy a
On 6/14/2018 4:19 AM, jmh530 wrote:
I found myself getting in trouble when I was texting and being sarcastic. I
always add the little winky face now. People don't get mad anymore, but instead
just say I'm not funny. Good trade-off.
My sense of humor tends to the droll side, and people who
On 6/14/2018 2:53 AM, Unsafe wrote:
"D only has advantages" ??
What is the point of such a post?
Read the parent post.
To me, it just comes across as being DPRK like propaganda.
Evidently my brand of humor got lost in translation. I grovel and beg for
forgiveness, and will appropriately
https://news.ycombinator.com/item?id=17306761
On 6/12/2018 7:31 PM, makedgreatagain wrote:
Thanks for all you help, the betteC is really useful and handy.
That's great to hear!
On 6/12/2018 5:13 AM, makedgreatagain wrote:
extern(C) int main(string[] args){
Need to declare main() like those C people do:
extern (C) int main(int argc, char** argv){
On 6/12/2018 3:35 AM, biocyberman wrote:
On Tuesday, 12 June 2018 at 08:42:51 UTC, Walter Bright wrote:
Direct link:
https://news.ycombinator.com/item?id=17284350\
I tried compiling 'make' for fun, but failed. Is the source on github outdated?
You can see the errors here: https://github.com
Direct link:
https://news.ycombinator.com/item?id=17284350\
On 6/11/2018 7:50 PM, Mike Parker wrote:
Woohoo! I'm extremely pleased to announce the first Seoul D Meetup!
Wish I could be there!
https://github.com/dlang/druntime/pull/2213
On 6/11/2018 11:17 AM, Guillaume Piolat wrote:
I don't know if someone really wrote this code, or if it was all from
intrinsics.
memcpy is so critical to success it is likely written by Intel itself to ensure
every drop of perf is wrung out of the CPU.
I was Intel CEO I'd direct the CPU
On 6/11/2018 7:21 AM, Mike Parker wrote:
Walter's latest post on -betterC is now on the blog. Here, he shows step-by-step
an example of using -betterC to convert a real-world program, one small enough
to describe in a blog post, from C to D.
The blog:
On 6/11/2018 6:00 AM, Steven Schveighoffer wrote:
No, __doPostblit is necessary -- you are making a copy.
example:
File[] fs = new File[5];
fs[0] = ...; // initialize fs
auto fs2 = fs;
fs.length = 100;
At this point, fs points at a separate block from fs2. If you did not do
postblit on
On 6/11/2018 1:12 AM, Mike Franklin wrote:
On Monday, 11 June 2018 at 08:00:10 UTC, Walter Bright wrote:
Making it a template is not really necessary. The compiler knows if there is
the possibility of it throwing based on the type, it doesn't need to infer it.
There are other reasons to make
On 6/10/2018 8:34 PM, Basile B. wrote:
- default win32 OMF:
https://github.com/DigitalMars/dmc/blob/master/src/core/MEMCCPY.C
I think you mean:
https://github.com/DigitalMars/dmc/blob/master/src/CORE32/MEMCPY.ASM
On 6/10/2018 8:43 PM, Mike Franklin wrote:
That only addresses the @safe attribute, and that code is much too complex for
anyone to audit it and certify it as safe.
Exceptions are also not all handled, so there is no way it can pass as nothrow.
The runtime call needs to be replaced with a
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!
On 6/10/2018 7:49 PM, Mike Franklin wrote:
On Sunday, 10 June 2018 at 15:12:27 UTC, Kagamin wrote:
If the compiler can't get it right then who can?
The compiler implementation is faulty. It rewrites the expressions to an
`extern(C)` runtime implementation that is not @safe, nothrow, or pure:
On 6/10/2018 4:39 PM, David Nadlinger wrote:
That's not entirely true. Intel started optimising some of the REP string
instructions again on Ivy Bridge and above. There is a CPUID bit to indicate
that (ERMS?); I'm sure the Optimization Manual has further details. From what I
remember, `rep
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.
followed by the ASM implementation.
The CPU makers abandoned optimizing the REP
On 6/10/2018 6:45 AM, Mike Franklin wrote:
void memcpyD()
{
dst = src.dup;
}
Note that .dup is doing a GC memory allocation.
On 6/10/2018 5:49 AM, Mike Franklin wrote:
[...]
One source of entropy in the results is src and dst being global variables.
Global variables in D are in TLS, and TLS access can be complex (many
instructions) and is influenced by the -fPIC switch. Worse, global variable
access is not
On 6/9/2018 1:03 AM, Nick Sabalausky (Abscissa) wrote:
Maybe naive, maybe not, but my policy is that: Any hour of any day an employer
claims ***ANY*** influence over, must be paid for ($$$) by said employer when
attempting to make ANY claim on that hour of my life. Period.
If that's the deal
On 6/8/2018 10:04 PM, Mike Franklin wrote:
On Saturday, 9 June 2018 at 05:00:29 UTC, Walter Bright wrote:
My goal in the short term is that Phobos is going to compile successfully with
dip1000 the way it is now. It has already been deferred and deferred and
deferred.
I understand
On 6/6/2018 2:17 AM, Russel Winder wrote:
It is worth noting that any employer who understands software
development and is involved in software development will write into the
contract of employment that all software created by an employee at any
time is the property of the employer. However,
On 6/8/2018 8:12 PM, Mike Franklin wrote:
Simple! And when v2.{whatever} comes around, we're all set with a better D.
My goal in the short term is that Phobos is going to compile successfully with
dip1000 the way it is now. It has already been deferred and deferred and deferred.
On 6/8/2018 7:17 PM, Adam D. Ruppe wrote:
On Saturday, 9 June 2018 at 02:13:00 UTC, Walter Bright wrote:
But it was never enforced, meaning that suddenly enforcing it is just going to
break code left and right.
It isn't going to break anything. It is going to *correctly diagnose already
On 6/8/2018 6:02 PM, Mike Franklin wrote:
Should it be deprecated (not necessarily removed) to guide users towards a more
consistent and idiomatic usage of the language? Also, if there are fewer usages,
it will make it much easier to redefine `in` to something useful in the future.
'in' is
On 6/8/2018 5:54 PM, Kapps wrote:
Personally I think the fear of Microsoft ruining GitHub is completely unfounded.
My concern has nothing to do with Microsoft. It's about not totally relying on
any third party not under our control.
On 6/8/2018 3:02 PM, Brad Roberts wrote:
Essentially (if not actually) everything on github is available through their
api's. No need for scraping or other heroics to gather it.
That's good to know! The situation I was concerned with is it going dark all of
a sudden.
BTW, if someone wants
On 6/7/2018 10:01 PM, H. S. Teoh wrote:
And that is why it's a bad thing to build a walled garden around a code
repo, esp. when the underlying VCS is well capable of distributed
development. If only there has been a standard protocol for
communicating such associated content, such as PR
On 6/7/2018 10:17 AM, H. S. Teoh wrote:
Exactly!!! Git was built precisely for decentralized, distributed
development. Anyone should be (and is, if they bothered to put just a
tiny amount of effort into it) able to set up a git server and send the
URL to prospective collaborators. Anyone is
On 6/7/2018 4:00 PM, Nick Sabalausky (Abscissa) wrote:
Yea, it certainly does have that going for it. And I have no real big objections
to bugzilla. It would be nice, though, if it were better (and more cleanly)
integrated with GitHub/GitLab/BitBucket/etc., and if its data were all
On 6/6/2018 10:28 PM, Nick Sabalausky (Abscissa) wrote:
Keep in mind, if we had been commoditizing and decentralizing repository
hosting, issue tracking, PRs, user accounts, etc. right from the start like we
should've been, then this MS buyout of GitHub would've been entirely irrelevant
to
On 6/3/2018 8:51 PM, Anton Fediushin wrote:
This is still just a rumour, we'll know the truth on Monday (which is today).
We'll stay on Github as long as it continues to serve our interests, which it
has done very well, and I have no reason to believe will change.
We have a number of ties
On 6/3/2018 3:03 PM, Huuskes wrote:
I meant more in the AMA-ready-to-answer any questions sense, haha. You don't see
that often where the creator of pops up in threads. It's
nice to see, partially how I ended up here! ^^
Back in the Symantec days, I would regularly do tech support myself on
On 6/3/2018 1:48 PM, Huuskes wrote:
On Sunday, 3 June 2018 at 20:37:14 UTC, Walter Bright wrote:
https://news.ycombinator.com
You always seem so on top of this :) On HN they seem more positive towards D
than on Reddit.
I noticed it 6 hours after it was posted.
https://news.ycombinator.com
On 6/1/2018 12:30 AM, Mike Franklin wrote:
I already have a pending PR at https://github.com/dlang/dmd/pull/8310 which I
can modify to fix for both __LINE__ and __FILE_ if I can get clarification on
how it *should* work.
I followed up there. Thanks for taking care of this!
On 5/30/2018 1:27 AM, FeepingCreature wrote:
There's a very common idiom where in order to report line numbers of an error or
a log line at the callsite of a function, you pass __FILE__ and __LINE__ as
default parameters:
void foo(string file = __FILE__, size_t line = __LINE__);
What's wrong
On 5/30/2018 2:45 PM, John Colvin wrote:
https://run.dlang.io/is/oMe7KQ
Less elegant, but solves the problem of accidental argument adding (CallerFile
acts as a barrier). Unfortunately, while it works in theory, in practice the
compiler crashes LOL
Please post bug reports when you find
On 5/28/2018 6:54 PM, 12345swordy wrote:
No doubt that all this complexity is partially due to having a religious like
zeal when it comes to preserving backwards compatibility.
I mean create a new official file extension, so that it can make much needed
breaking changes on it.
For all the
A cautionary tale we should all keep in mind.
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf
https://www.reddit.com/r/programming/comments/8mq10v/bjarne_stroustroup_remeber_the_vasa_critique_of/
https://news.ycombinator.com/item?id=17172057
On 5/26/2018 4:12 AM, Rubn wrote:
What about self moderation? If I make an unprofessional comment and want to
delete it? Will this be allowed now? I guess it's more of a feature request.
People have from time to time asked me to delete one of their comments, which I
have done if I could.
From time to time, the issue comes up.
The standard here is professional demeanor. For what professional demeanor is,
see:
https://www.amazon.com/Etiquette-Society-Business-Politics-Home/dp/1497339979
Unprofessional demeanor will get removed at the forum staff's sole discretion on
a case by
On 5/25/2018 1:27 AM, Dukc wrote:
So, ~ may be a bit confusing for newcomers, but there is a solid reason why it's
used instead of +, and it's because they have a fundamentally different meaning.
Good work, whoever chose that meaning!
This ambiguity bug with + has been causing well-known
On 5/23/2018 10:48 AM, Manu wrote:
Sadly, neither of these are correct.
The type is a class (has vtable, etc), so it is declared in D as a
class... It is also a class in C++, so it must mangle like a class.
It's also the case that it's passed by pointer, in C++ and in D. It's
a class that
On 5/21/2018 10:50 PM, Nicholas Wilson wrote:
As Ali said Walter will be giving his talk again (some conference in Poland
(Krakow?, code eu? can't remember the name).
It was at Code Europe 2018 in Krakow on May 8. They said it would take a month
for them to upload the videos on youtube. I'll
On 5/22/2018 6:27 AM, Steven Schveighoffer wrote:
There's no need for the private struct.
That is correct. But pragmatically, I wanted the public interface to be very
small and easily inspected. The struct is very large with many dependencies and
hard to inspect to see what is public and
Back on the front page with an apparent followup:
Consider using Digital Mars C compiler (virtualbox.org)
33 points by yuhong 3 hours ago | flag | hide | past | web | favorite | 14
comments
https://news.ycombinator.com/news
On 5/22/2018 9:38 PM, Dmitry Olshansky wrote:
On Wednesday, 23 May 2018 at 01:18:43 UTC, Walter Bright wrote:
Yay! Any thoughts about opening runtime library?
Yes, I just didn't get around to it yet. I didn't think anyone was interested
:-)
https://news.ycombinator.com/news
And it’s
On 5/21/2018 2:41 PM, Steven Schveighoffer wrote:
On 5/21/18 5:23 PM, Walter Bright wrote:
In C, the way to do PIMPL is to write just a struct declaration:
=== s.h ===
struct S;
=== s.c ===
#include "s.h"
struct S { ... };
=== t.c ===
#include "s.h"
701 - 800 of 15506 matches
Mail list logo
