On Monday, 1 October 2018 at 02:29:40 UTC, Manu wrote:
I feel like I don't understand the design...
mutable -> shared should work the same as mutable -> const...
because
surely that's safe?
Nope. Consider.
struct A {
A* a;
}
void foo(shared A* a) {
a.a = new shared(A))();
}
Now
On Wednesday, 11 April 2018 at 12:41:24 UTC, Vladimir Panteleev
wrote:
On Wednesday, 11 April 2018 at 12:04:24 UTC, deadalnix wrote:
This used to be an option:
dchar val = ...;
char[4] buf;
toUTF8(buf, val);
Now I'm getting an error.
This std.utf.toUTF8 overload was deprecated in 2.074.0
This used to be an option:
dchar val = ...;
char[4] buf;
toUTF8(buf, val);
Now I'm getting an error. Looking at the doc, it seems that there
are only option returning a string, which I assume is allocated
on the GC. Has the function moved somewhere else ? If not, what's
going on ?
On Wednesday, 28 February 2018 at 14:05:19 UTC, Jonathan M Davis
wrote:
I expect that pretty much anything you propose that requires
code flow analysis is DOA. Walter is almost always against
features that require it, because it's so hard to get right,
and the places that D does use it tend to
On Thursday, 22 February 2018 at 19:26:54 UTC, Andrei
Alexandrescu wrote:
After coding https://github.com/dlang/phobos/pull/6192 with
AliasSeq, the experience has been quite pleasurable. However,
in places the AliasSeq tends to expand too eagerly, leading to
a need to "keep it together" e.g.
On Thursday, 18 January 2018 at 09:02:38 UTC, Walter Bright wrote:
I don't remember how long, but it took me a fair while to do
the divide:
https://github.com/dlang/druntime/blob/master/src/rt/llmath.d
It could be upscaled by rote to 128 bits, but even that would
take me much longer than
On Thursday, 18 January 2018 at 03:19:57 UTC, deadalnix wrote:
On Sunday, 14 January 2018 at 23:03:27 UTC, Andrei Alexandrescu
wrote:
Thanks for these thoughts!
* (u)cent support
* fixes for the shared qualifier
* ownership mechanism
These took less than 1h to add support for? That would be
On Sunday, 14 January 2018 at 23:03:27 UTC, Andrei Alexandrescu
wrote:
Thanks for these thoughts!
* (u)cent support
* fixes for the shared qualifier
* ownership mechanism
These took less than 1h to add support for? That would be
awesome... but realistically only the (u)cent sounds like that
On Saturday, 30 December 2017 at 16:59:41 UTC, aberba wrote:
In this video[1] from 2016, developer talks about C++ memory
safety features, meta-programming, maturity and few others as
main reasons they choose it for developing their blockchain
software (the way I got it from a quick view).
On Monday, 7 August 2017 at 23:45:13 UTC, Joakim wrote:
On Wednesday, 2 August 2017 at 16:21:41 UTC, jmh530 wrote:
I was surprised to see a familiar name here:
https://www.bloomberg.com/view/articles/2017-08-02/bitcoin-s-split-is-good-for-progress
Here's an interview with Amaury about the
On Wednesday, 2 August 2017 at 19:00:05 UTC, Ali Çehreli wrote:
On 08/02/2017 09:21 AM, jmh530 wrote:
I was surprised to see a familiar name here:
https://www.bloomberg.com/view/articles/2017-08-02/bitcoin-s-split-is-good-for-progress
"They -- led by former Facebook developer Amaury Sechet
On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
See -
https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce
A long read. Someone has stolen $31M of Ether.
To give an idea of how bad it is:
On Monday, 31 July 2017 at 07:17:33 UTC, Guillaume Chatelet wrote:
Some people here might find this interesting:
https://github.com/xoreaxeaxeax/sandsifter
White paper here:
https://github.com/xoreaxeaxeax/sandsifter/blob/master/references/domas_breaking_the_x86_isa_wp.pdf
This man is a
On Saturday, 1 July 2017 at 21:47:20 UTC, Andrei Alexandrescu
wrote:
Walter looked at http://erdani.com/conversions.svg and said
actually "const inout" and "const inout shared" should not
exist as distinct qualifier groups, leading to the simplified
qualifier hierarcy in
On Tuesday, 27 June 2017 at 19:43:03 UTC, Vladimir Panteleev
wrote:
On Tuesday, 27 June 2017 at 19:39:25 UTC, deadalnix wrote:
Please, please, please, just do the same as clang.
I don't think clang has this feature, so doing the same as
clang would be a regression. We're in uncharted waters!
On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev
wrote:
As has been announced, DMD now has colorized syntax
highlighting in error messages:
http://forum.dlang.org/post/of9oao$230j$1...@digitalmars.com
With 2.075's release near, now would be a good time to decide
on a nice color
On Monday, 12 June 2017 at 15:41:03 UTC, Era Scarecrow wrote:
On Monday, 12 June 2017 at 13:41:36 UTC, deadalnix wrote:
You misunderstood. We need cent/ucent supported by the
compiler to get to larger integral types efficiently. There
are no ways around it. There are a ton of operations such
On Sunday, 11 June 2017 at 18:01:41 UTC, Era Scarecrow wrote:
On Sunday, 11 June 2017 at 08:52:37 UTC, deadalnix wrote:
I ended up doing my own. There are just no way to do it well
without cent/ucent . Weka is running into the same problem for
error correction.
And what timing, I just
On Saturday, 10 June 2017 at 20:19:22 UTC, Era Scarecrow wrote:
On Saturday, 10 June 2017 at 19:40:47 UTC, Andrei Alexandrescu
wrote:
On 6/10/17 3:28 PM, Era Scarecrow wrote:
Got a possible one. My implementation is heavy on assembly
language to take advantage of x86 features
That's cool
On Sunday, 21 May 2017 at 00:33:30 UTC, Vittorio Romeo wrote:
Hello everyone, I recently started learning D (I come from a
Modern C++ background) and I was curious about closures that
require GC allocation. I wrote this simple example:
auto bar(T)(T x) @nogc
{
return x(10);
On Thursday, 11 May 2017 at 12:26:11 UTC, Steven Schveighoffer
wrote:
if(arr) -> same as if(arr.ptr)
Nope. It is:
if(arr) -> same as if(((cast(size_t) arr.ptr) | arr.length) != 0)
Should we conclude from the fact that absolutely nobody gets it
right in this very forum that nobody will get
On Thursday, 11 May 2017 at 12:21:46 UTC, Steven Schveighoffer
wrote:
I can't imagine anyone attempted to force this to break without
a loud backlash. I think if(ptr) is mostly universally
understood to mean the pointer is not null.
-Steve
It is not a problem for pointer because for pointer
On Thursday, 11 May 2017 at 21:20:35 UTC, Jack Stouffer wrote:
On Tuesday, 9 May 2017 at 14:13:31 UTC, Walter Bright wrote:
2. it may not be available on your platform
I just had to use valgrind for the first time in years at work
(mostly Python code there) and I realized that there's no
On Wednesday, 10 May 2017 at 17:51:38 UTC, H. S. Teoh wrote:
Haha, I guess I'm not as good of a C coder as I'd like to think
I am. :-D
That comment puts you ahead of the pack already :)
On Wednesday, 10 May 2017 at 19:06:40 UTC, Ali Çehreli wrote:
Bummer for H. S. Teoh I guess... :/
Although I prefer explicit over implicit in most cases, I've
never graduated from if(p) and still using it happily. :)
Ali
All bool conversions in D are value based, not identity based.
Not
On Monday, 8 May 2017 at 08:25:24 UTC, Andrej Mitrovic wrote:
Thoughts?
It seems like the most sensible path forward. Mike ?
On Saturday, 6 May 2017 at 17:59:38 UTC, thedeemon wrote:
On Saturday, 6 May 2017 at 06:26:29 UTC, Joakim wrote:
Walter: I believe memory safety will kill C.
And then null safety will kill D. ;)
I actually think this is more likely than memory safety killing
C. Just because both are very
On Tuesday, 2 May 2017 at 11:13:35 UTC, Andrej Mitrovic wrote:
On Tuesday, 2 May 2017 at 09:03:27 UTC, deadalnix wrote:
100% in favor of the constructor behavior change in case no
constructor is in the derived class.
I think we could even split this up into two separate
proposals, because
On Monday, 1 May 2017 at 14:55:28 UTC, Mike Parker wrote:
DIP 1004 is titled "Inherited Constructors.
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1004.md
All review-related feedback on and discussion of the DIP should
occur in this thread. Due to DConf taking place during the
review
On Sunday, 23 April 2017 at 19:25:09 UTC, Andrej Mitrovic wrote:
With this syntax, the import is executed only if the declared
name (process) is actually looked up.
I don't believe the workaround with the `from` template fixes
this.
Not sure what DMD does, but SDC sure would do it only if
On Saturday, 22 April 2017 at 11:54:08 UTC, Mike Parker wrote:
Destroy!
I'm not per se against going there but there are 2 points that
needs to be considered. The first one is the "self important
lookup" which obviate the need for this DIP to some extent.
Second, if we are going to
On Sunday, 23 April 2017 at 12:34:34 UTC, Andrej Mitrovic wrote:
On Sunday, 23 April 2017 at 12:03:47 UTC, Andrei Alexandrescu
wrote:
Mostly out of a sense of conformity. We asked Michael to give
no special treatment of DIPs originating from us, and this one
was open, so he put it up for
On Tuesday, 11 April 2017 at 17:43:20 UTC, Walter Bright wrote:
On the other hand, overly principled languages tend to not be
as successful, because what people need to do with programs is
often dirty.
Monads, and "functional reactive programming", are obtuse
things that come about when a
On Monday, 10 April 2017 at 21:44:32 UTC, Jonathan Marler wrote:
"throw" operator (throw a Throwable object)
"new" operator (create a GC object)
"throw new" operator (create and throw a reference-counted
Throwable object)
There is no need for this, the compiler already understands
On Sunday, 9 April 2017 at 20:14:24 UTC, Walter Bright wrote:
For another, a general mechanism for safe refcounting of
classes has eluded us.
The only thing you need to get backed into the language is to
make sure things do not escape in uncontrolled manner. Everything
else is library.
You
On Sunday, 9 April 2017 at 13:16:45 UTC, irritate wrote:
The problems is with the so called "proposals". Second class
ideas nowhere near implementation. There is a better discussion
in this forum, every other week. Deadalinx should get a better
image of the quality of his own work and stop
On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:
https://github.com/dlang/dmd/pull/6680
Yes, this is for real! Symantec has given their permission to
relicense it. Thank you, Symantec!
<3
On Thursday, 6 April 2017 at 16:56:10 UTC, Olivier FAURE wrote:
I'm not saying you're wrong, but there's a different between
saying "You should flesh out your idea" and "We're not going to
respond formally before you submit a DIP".
Yes that's essentially my problem here.
On Thursday, 6 April 2017 at 22:11:55 UTC, Walter Bright wrote:
On 4/6/2017 2:18 PM, H. S. Teoh via Digitalmars-d wrote:
You were asking for a link to deadalnix's original discussion,
and
that's the link I found (somebody else also posted a link to
the same
discussion).
Only deadalnix can
On Wednesday, 5 April 2017 at 14:01:24 UTC, Guillaume Piolat
wrote:
Do we have a missed opportunity with shared?
Yes we do.
The #1 problem is that it lack a bridge to and from the "normal"
thread local world. there is literally no way to use shared in a
correct way, you always need to
On Wednesday, 5 April 2017 at 23:49:00 UTC, Walter Bright wrote:
Your original proposal listed 3 different kinds of catch, now
it seems different. It's clear to me that this is more of an
idea than a proposal - a lot more work needs to go into it.
It is no different. These aren't special
On Thursday, 6 April 2017 at 03:52:39 UTC, Andrei Alexandrescu
wrote:
Thank you. If history is any indication, there is little to
show after years of being around the community. The pattern
seems to be a frustration that other people don't work on your
ideas, which you can't convince yourself
On Wednesday, 5 April 2017 at 09:51:16 UTC, Walter Bright wrote:
Much of Phobos has been redone to not assume/require the GC. A
glaring exception (!) is when Exceptions are thrown, which is
why we're looking for a solution.
Make the exception owned, and let the caller decide.
On Wednesday, 5 April 2017 at 12:14:38 UTC, Andrei Alexandrescu
wrote:
As a matter of procedure no, a forum post will not be followed
by a formal response. The DIP process ensures a formal response.
[...]
I encourage anyone interested in pursuing this idea to work on
a DIP.
Thanks,
Andrei
On Wednesday, 5 April 2017 at 09:48:47 UTC, Walter Bright wrote:
try { ... }
catch (owned Exception e) { ... }
catch (scope Exception e) { ... }
catch (Exception e) { ... }
It not look enticing.
You can do that, but that's 100% equivalent to:
try { ... }
catch (scope
On Tuesday, 4 April 2017 at 09:45:14 UTC, Walter Bright wrote:
1. we already have some of the benefits of the proposal because
D has transitive immutability
This works hand in hand with D type qualifier system.
2. I'm looking for a solution where exceptions don't rely on
the GC to the
On Monday, 3 April 2017 at 22:20:23 UTC, Walter Bright wrote:
You're right that this proposal does not address how memory is
allocated for anything indirectly referenced by the exception
object. That is an independent issue, and is not peculiar to
exception objects.
There is no issue
On Monday, 3 April 2017 at 08:22:41 UTC, Matthias Bentrup wrote:
How would you deal with the Exception payload, e.g. the message
string ?
Yes current proposal are unable to handle properly multiple
levels of indirections.
On Saturday, 1 April 2017 at 22:08:27 UTC, Walter Bright wrote:
On 4/1/2017 7:54 AM, deadalnix wrote:
It doesn't need any kind of throw new scope Exception, and was
proposed,
literally, years ago during discussion around DIP25 and alike.
A link to that proposal would be appreciated.
The
On Sunday, 2 April 2017 at 18:41:45 UTC, Adam D. Ruppe wrote:
On Sunday, 2 April 2017 at 18:16:43 UTC, Johannes Pfau wrote:
I do not want GC _allocation_ for embedded systems (don't even
want to link in the GC or GC stub code) ;-)
Then don't use operator `new`... you're probably using some
On Saturday, 1 April 2017 at 13:34:58 UTC, Andrei Alexandrescu
wrote:
Walter and I discussed the following promising setup:
Use "throw new scope Exception" from @nogc code. That will
cause the exception to be allocated in a special stack-like
region.
If the catching code uses "catch (scope
On Thursday, 30 March 2017 at 20:29:26 UTC, Dukc wrote:
On Thursday, 30 March 2017 at 17:22:20 UTC, Stefan Koch wrote:
SDC has the goal to be more principled.
And Not to be Mr. fast and loose, right ?
If a file parses it'd better be syntactically correct!
All of it.
Just an idea, but could
On Wednesday, 29 March 2017 at 19:32:50 UTC, Vladimir Panteleev
wrote:
Sorry, is this not already the case?
$ dmd test.d
$ cat test.d
void main()
{
import std.stdio;
writeln("Hello, world!");
}
unittest
{
foo bar {} baz more-syntax!errors)blah
}
$ dmd test.d
$ ./test
On Wednesday, 29 March 2017 at 11:22:59 UTC, rikki cattermole
wrote:
Which is basically what you said.
It isn't. version needs to be parsed and thus, grammatically
valid.
I was wondering. When uniitests aren't going to run, it may be
desirable to skip parsing altogether, just lexing and counting
braces until the matching closing brace is found.
Obviously, this means that no error will be found in unittests
blocks. That can contain pretty much anything that
On Tuesday, 28 March 2017 at 13:18:57 UTC, kinke wrote:
You don't seem to get my point, I don't know why it's
apparently that hard.
It's hard because you assume I did not understood you point and
you keep repeating the same thing. I understand you point and
showed you why it isn't a mangling
On Tuesday, 28 March 2017 at 08:30:43 UTC, kinke wrote:
What I don't get is why it's considered important to have a
matching C++ mangling for templates across D and C++ - what
for? I only care about mangling wrt.
If you still think this is a mangling problem, please reread my
first response
On Sunday, 26 March 2017 at 22:56:59 UTC, Jerry wrote:
On Sunday, 26 March 2017 at 22:29:56 UTC, deadalnix wrote:
It is clear that you won't be able to express 100% of C++ in
D, that would require to important all the weird parts of C++
into D, but if we are doing so, why use D in the first
On Sunday, 26 March 2017 at 17:41:57 UTC, Benjamin Thaut wrote:
On Sunday, 26 March 2017 at 14:30:00 UTC, deadalnix wrote:
It's consistent. D's const is transitive, and D doesn't allow
you to specify const on the indirection of a reference type.
So there is no problem on the C++ mangling
On Sunday, 26 March 2017 at 10:43:11 UTC, Benjamin Thaut wrote:
As you see from the above example D mangles the getClassConst
as a "Class const * const" instead of a "Class const *"
("YAQEBV" vs "YAPEBV"). Is this expected behavior?
It's consistent. D's const is transitive, and D doesn't
On Friday, 24 March 2017 at 09:27:54 UTC, Vladimir Panteleev
wrote:
Yep, because of the misuse-worst-case arguments. Simple
solutions that guard against such mistakes are welcome. E.g. we
could allow squashing if all commits' commit messages except
the first one's start with "[SQUASH] " or
On Wednesday, 22 March 2017 at 09:02:24 UTC, Vladimir Panteleev
wrote:
On Tuesday, 21 March 2017 at 18:07:57 UTC, deadalnix wrote:
Large companies such as Google or Facebook
A blind appeal to authority is fallacious, but it's still
worthwhile to see what others are doing. I think it's
On Tuesday, 21 March 2017 at 12:49:22 UTC, Vladimir Panteleev
wrote:
there are ample proof that is increase the quality of the code
review,
OK, where is the proof?
Large companies such as Google or Facebook measure these things.
You have presented 0 arguments so far, and dismissed both
On Tuesday, 21 March 2017 at 12:45:45 UTC, Vladimir Panteleev
wrote:
On Tuesday, 21 March 2017 at 11:59:42 UTC, deadalnix wrote:
It's not good either. Why would I want to look at a DAG when
the serie of event is strictly linear to begin with ?
Not sure what you mean here. The way it's
On Tuesday, 21 March 2017 at 01:39:39 UTC, Vladimir Panteleev
wrote:
On Monday, 20 March 2017 at 12:25:22 UTC, deadalnix wrote:
Because a picture is clearer than a thousand words:
What this tells me is that the default way git-log presents
history is not very useful. Consider this
On Monday, 20 March 2017 at 05:10:04 UTC, Martin Nowak wrote:
On Wednesday, 15 March 2017 at 13:14:31 UTC, deadalnix wrote:
This is making the history very spaghettified. Is that
possible to have the bot rebase/squash commits and then
pushing ?
I don't really agree with the argument. A merge
On Wednesday, 15 March 2017 at 13:14:31 UTC, deadalnix wrote:
This is making the history very spaghettified. Is that possible
to have the bot rebase/squash commits and then pushing ?
Arf I fat fingered the title, i meant the dlang bot.
This is making the history very spaghettified. Is that possible
to have the bot rebase/squash commits and then pushing ?
On Thursday, 9 March 2017 at 15:42:22 UTC, qznc wrote:
I'm curious. Where does it make sense for opEquals to be
non-pure? Likewise opCmp, etc.
When the object need some kind of normalization to be comparable
and you don't want to do the normalization every single time.
On Wednesday, 8 March 2017 at 20:00:54 UTC, aberba wrote:
I don't really have much experience with large code base, so
spare me.
From a technical and experience point of view (those with
experience in large D code-base), how is only D's GC & optional
MMM a significant production-use blocker?
On Tuesday, 7 March 2017 at 19:07:29 UTC, Jack Stouffer wrote:
I've seen this mentioned serval times now by people coming from
Rust.
Rust users: Is the PC/politicking really that pervasive in
their community?
https://www.youtube.com/watch?v=dIageYT0Vgg
Lot of good stuff in there, but, if
On Tuesday, 7 March 2017 at 16:18:15 UTC, Wyatt wrote:
On Tuesday, 7 March 2017 at 03:04:05 UTC, Joakim wrote:
https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hello-d/
I like the bit in the comments where he says this:
"It doesn’t have to be idiomatic to work just fine, which is
On Tuesday, 7 March 2017 at 01:27:56 UTC, Andrei Alexandrescu
wrote:
The question is what to do to minimize breakage yet "break the
bad code". The most backward-compatible solution is to define
opCmp automatically to do a field-by-field lexicographical
comparison. The most radical solution is
On Friday, 3 March 2017 at 18:47:53 UTC, H. S. Teoh wrote:
Actually, I just tested on a freshly-cloned copy of
dmd/druntime/phobos, it seems that building on Debian does
work. Digging into the git log, it appears that commit 78cd023
*should* have added -fPIC to the makefiles.
So how come
https://issues.dlang.org/show_bug.cgi?id=17236
Coming to you on ubuntu soon.
On Wednesday, 1 March 2017 at 06:44:34 UTC, Cecil Ward wrote:
const uint power2 = 512; // say, some 1 << n anyway
const uint prime = 509; // some prime just below the power,
some prime > power2/2
static assert( power2 - 1 - prime < prime );
x = x & ( power2 - 1 );
x = ( x
On Tuesday, 28 February 2017 at 17:57:14 UTC, Andrei Alexandrescu
wrote:
This is of possible interest:
https://probablydance.com/2017/02/26/i-wrote-the-fastest-hashtable/ -- Andrei
But let’s say you know that your hash function returns numbers
that are well distributed and that you’re rarely
On Saturday, 4 February 2017 at 23:54:12 UTC, David Gileadi wrote:
That's obviously a self important lookup.
This. So much this.
I'm afraid you are the only one who appreciate my humor :)
On Monday, 6 February 2017 at 11:02:31 UTC, Walter Bright wrote:
https://www.reddit.com/r/programming/comments/5sda9s/what_rust_can_do_that_other_languages_cant_in_six/
https://news.ycombinator.com/item?id=13576976
(On ycombinator, don't click on the link above, click on
On Friday, 3 February 2017 at 23:33:58 UTC, Walter Bright wrote:
I agree, it's pretty dazz! We need to give this technique a
memorable name (not an acronym). I thought "Voldemort Types"
turned out rather well, whereas CTFE is klunky, UFCS is even
worse. The absolute worst is C++ SFINAE.
Any
On Wednesday, 1 February 2017 at 03:43:10 UTC, David Nadlinger
wrote:
Hi all,
Version 1.1.0 of LDC, the LLVM-based D compiler, has finally
been released:
https://github.com/ldc-developers/ldc/releases/tag/v1.1.0
Please head over to the digitalmars.D.ldc forums for more
details and
On Tuesday, 31 January 2017 at 23:42:43 UTC, Walter Bright wrote:
On 1/31/2017 11:32 AM, Nordlöw wrote:
On Tuesday, 31 January 2017 at 19:26:51 UTC, Walter Bright
wrote:
This "as if" thing enables the designer of a function API to
set the desired
relationships even if the implementation is
On Saturday, 28 January 2017 at 21:46:17 UTC, Walter Bright wrote:
Same problem, same solution, same fallout.
What problem?
Ask Andrei, he asked for inout's deprecation. I'm not going to
run after you two like you are toddlers. Having to make the same
case again and again for literally
On Monday, 30 January 2017 at 01:34:52 UTC, ilya-stromberg wrote:
Walter created an entire language and a community around it.
Can you, please, share with us how your accomplishments give
any importance to whatever your disagreement is with him? All
that is visible, here is you protest
On Monday, 30 January 2017 at 01:15:52 UTC, Dicebot wrote:
On 01/30/2017 12:38 AM, Walter Bright wrote:
...
Please, don't waste your time. You mentioned being curious
about what is wrong with that PR - I have explained. Let's just
stop here before you write another 20 posts presuming that I
On Saturday, 28 January 2017 at 03:40:43 UTC, Walter Bright wrote:
On 1/27/2017 4:43 PM, deadalnix wrote:
I mostly went silent on this because I this point, I have no
idea how to reach
to you and Andrei. This is bad because of all the same reasons
inout is bad,
plus some other on its own, and
On Friday, 27 January 2017 at 19:12:37 UTC, Walter Bright wrote:
Yes, I'm 100% responsible for 'return scope' and pushing it
harder than most people probably would like. Maybe I'm alone,
but I strongly believe it is critical to D's future.
You sound like this guy:
On Friday, 27 January 2017 at 19:09:30 UTC, Walter Bright wrote:
On 1/26/2017 5:42 AM, Dicebot wrote:
https://issues.dlang.org/show_bug.cgi?id=17123
Can I have my "I told you so" badge please?
Yes, you may. But nobody promised there would be no regressions
- just that we'll fix them. I'll
On Wednesday, 25 January 2017 at 12:36:02 UTC, Stefan Koch wrote:
newCTFE is green now on all platforms!
<3
On Sunday, 22 January 2017 at 17:55:03 UTC, Martin Nowak wrote:
Glad to announce D 2.073.0.
This release comes with a few phobos additions, new -mcpu=avx
and -mscrt switch, and several bugfixes.
http://dlang.org/download.html
http://dlang.org/changelog/2.073.0.html
-Martin
<3
On Sunday, 22 January 2017 at 05:02:43 UTC, Araq wrote:
It's an O(1) that requires a hash table lookup in general
because allocations can exceed the chunk size and so you cannot
just mask the pointer and look at the chunk header because it
might not be a chunk header at all. Know any
On Saturday, 14 January 2017 at 04:37:01 UTC, Chris Wright wrote:
Unfortunately, given an interior pointer, you can't identify
the base of its heap object in constant time.
1. Split the heap in chunk of size n being a power of 2, say 4M.
Align them 4M.
2. Find the chunk an alloc is part of in
On Wednesday, 11 January 2017 at 00:33:41 UTC, Martin Nowak wrote:
But it is not clear if anyone cares at this stage.
are rather frustrating to read.
Alright, sentence like this come from extreme frustration at
things being almost constantly broken. For instance:
Alright some feedback.
It is rather disappointing that Warn and Abort only write to
stderr. Being able to specify the sink would be great. i may want
to log the issue or something.
There is option to throw on error.
Checked!(Checked!(int, ProperCompare), WithNaN) is rather
inelegent. Why
Is the doc available somewhere in a readable form ?
On Wednesday, 4 January 2017 at 15:56:13 UTC, Timon Gehr wrote:
I don't fully agree. Nested imports, the way they have been
implemented, pose a new symbol hijacking hazard.
I'd argue this was an existing bug in import handling. This is
why I like to have very orthogonal definitions.
It
On Wednesday, 4 January 2017 at 16:03:29 UTC, Stefan Koch wrote:
On Wednesday, 4 January 2017 at 15:56:13 UTC, Timon Gehr wrote:
[1] Both static if and static foreach (once it lands) need the
same kind of scoping rules.
Please do contact me if you are working on static foreach,
there are
On Tuesday, 3 January 2017 at 00:16:52 UTC, Martin Nowak wrote:
On Monday, 2 January 2017 at 18:18:33 UTC, deadalnix wrote:
Plus the fix was actually released yesterday, so it's not like
I'm lagging by much. The internal meddling nonsense that's
going on is none of any user business.
Bug
There are quite a few fallacies in there.
On Monday, 2 January 2017 at 21:23:19 UTC, Andrei Alexandrescu
wrote:
Regarding the ongoing doubts about the advantages of inline
imports: they are first and foremost a completion of the nested
import feature. As such, most, if not all, arguments
On Monday, 2 January 2017 at 13:52:29 UTC, Martin Nowak wrote:
On Monday, 2 January 2017 at 13:51:15 UTC, Martin Nowak wrote:
On Sunday, 1 January 2017 at 23:55:37 UTC, deadalnix wrote:
But it is not clear if anyone cares at this stage...
It's fairly embarrassing to read so much uninformed
1 - 100 of 1851 matches
Mail list logo
