Re: D easily overlooked?
On Thursday, 20 July 2017 at 16:15:43 UTC, porter wrote: On Thursday, 20 July 2017 at 15:40:04 UTC, Wulfklaue wrote: the problems are greater than thought http://forum.dlang.org/thread/bqlfknpsdetzoxuxr...@forum.dlang.org
Re: Floating point operator <> and friends
On 7/22/2017 6:03 PM, Ali Çehreli wrote: Are the following floating operators gone? !> !< !>= !<= <> !<> <>= !<>= They still appear at least on the following pages: http://dlang.org/spec/lex.html#tokens https://wiki.dlang.org/Operator_precedence Thanks to Andrew Edwards's warning and unless someone objects, I'm removing them from the book... Ali Yes, they're gone. They were a failure.
Floating point operator <> and friends
Are the following floating operators gone? !> !< !>= !<= <> !<> <>= !<>= They still appear at least on the following pages: http://dlang.org/spec/lex.html#tokens https://wiki.dlang.org/Operator_precedence Thanks to Andrew Edwards's warning and unless someone objects, I'm removing them from the book... Ali
Re: Problem with integral promotions
On 7/22/2017 1:07 PM, Vladimir Panteleev wrote: Git blames you: https://github.com/dlang/dlang.org/commit/4cd3f38bbabdde30b280738dab4f4184c06f05f9 Ah, thanks for finding this. It was in response to: https://issues.dlang.org/show_bug.cgi?id=5132 i.e. it was documenting existing behavior.
Re: Problem with integral promotions
Jerry wrote: What code would break? Are there any examples of D code that would break as a result of the change? basically, any template that has small integral type T and does unary +/-/~ on it. and there *is* such code in phobos, and it's not explicitly tested for different integral sizes. when i added a warning, i had to fix phobos in several places, but i'm pretty sure that there are ALOT more.
Re: Problem with integral promotions
On Saturday, 22 July 2017 at 10:51:05 UTC, ketmar wrote: Walter Bright wrote: 2. Codify existing practice, since it has been that way forever. Not matching C has caused problems, see 16997 and 17637. It may cause more serious silent problems for people converting C code to D code. i'd say "codify, and add warning". since i patched the warning into the compiler, i have no more problems with the current rules: compiler tells me about possible incompatibilities with C, and i can either add `()` to silent the warning, or explicitly cast to the type i want. i think most other people will prefer to get warning instead of code breakage too. at least i hope so. ;-) Good luck adding a warning into DMD. After years there still isn't a warning for unsigned/signed comparisons. What code would break? Are there any examples of D code that would break as a result of the change?
Re: Problem with integral promotions
On Saturday, 22 July 2017 at 10:44:04 UTC, Walter Bright wrote: Note that the spec says: "Note: unlike in C and C++, the usual integral promotions are not performed prior to the complement operation." http://dlang.org/spec/expression.html#complement_expressions Where did that come from? Git blames you: https://github.com/dlang/dlang.org/commit/4cd3f38bbabdde30b280738dab4f4184c06f05f9
Re: New Garbage Collector?
On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote: In the forum, I saw a thread about someone working on a new GC. Just wanted to know if there's any updates on that. And what issues is it going to fix.. Personally, I would be greatly delighted if it acknowledges the Stop-The-World problem[1]. Going around it is shown not to be impossible[2]. I do understand it's not trivial task but how is the community/core devs supporting this? [1] https://dlang.org/spec/garbage.html [2] https://hub.docker.com/r/nimlang/nim/ I'm working on new GC. First iteration aims to be faster at allocation and at collection without changing the fundamental mark-sweep strategy. Second stage is getting concurrent collection. It wouldn't be a real-time miracle, but a pause time in the range of 10-20ms is possible.
Re: Problem with integral promotions
On Saturday, 22 July 2017 at 10:51:05 UTC, ketmar wrote: Walter Bright wrote: 2. Codify existing practice, since it has been that way forever. Not matching C has caused problems, see 16997 and 17637. It may cause more serious silent problems for people converting C code to D code. i'd say "codify, and add warning". I'd vote for the ketmar solution if workable. Another argument for this is that C code that has already been converted to D, and is currently silently broken, would benefit from a new warning as a way of gathering attention. However matching C promotion might make this code work too but silently.
Re: Problem with integral promotions
This affects: ~ubyte: all values -ubyte: all values -byte: -128 (0x80) ~ushort: all values -ushort: all values -short: -32768 (0x8000)
Re: newCTFE Status July 2017
On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys,
Due to improved ABI handling a subset of slices of complex
structs work now :)
The following code will correctly compile with newCTFE.
struct NA
{
string name;
uint age;
}
NA[] make5(string name)
{
NA[] result;
foreach(i; 1 .. 6)
{
string nameN = name ~ [cast(immutable char)('0' + (i %
10))];
result ~= [NA(nameN , i-1)];
}
return result;
}
static assert (make5("Tony") == [NA("Tony1", 0u), NA("Tony2",
1u), NA("Tony3", 2u), NA("Tony4", 3u), NA("Tony5", 4u)]);
As soon as the foreach-loop is iterated more then 1000 times you
will see a 7-10x speed improvement :)
Re: D easily overlooked?
On Saturday, 22 July 2017 at 14:20:24 UTC, Russel Winder wrote: On Sat, 2017-07-22 at 13:27 +, aedt via Digitalmars-d wrote: […] D without the GC isn't at all interesting, might as well use Go in that case. So D only gets traction if it keeps a GC. Go people are also trying to make their GC pretty fast afaik https://news.ycombinator.com/item?id=12821586
Re: New Garbage Collector?
On Saturday, 22 July 2017 at 16:35:03 UTC, Igor Shirkalin wrote: On Saturday, 22 July 2017 at 10:17:49 UTC, Temtaime wrote: On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote: In the forum, I saw a thread about someone working on a new GC. Just wanted to know if there's any updates on that. And what issues is it going to fix.. Personally, I would be greatly delighted if it acknowledges the Stop-The-World problem[1]. Going around it is shown not to be impossible[2]. I do understand it's not trivial task but how is the community/core devs supporting this? [1] https://dlang.org/spec/garbage.html [2] https://hub.docker.com/r/nimlang/nim/ The new precise GC will be never added to druntime. It is dead, man. Are you real developer of new GC? He's not he's just a naysayer :)
Re: New Garbage Collector?
On Saturday, 22 July 2017 at 10:17:49 UTC, Temtaime wrote: On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote: In the forum, I saw a thread about someone working on a new GC. Just wanted to know if there's any updates on that. And what issues is it going to fix.. Personally, I would be greatly delighted if it acknowledges the Stop-The-World problem[1]. Going around it is shown not to be impossible[2]. I do understand it's not trivial task but how is the community/core devs supporting this? [1] https://dlang.org/spec/garbage.html [2] https://hub.docker.com/r/nimlang/nim/ The new precise GC will be never added to druntime. It is dead, man. Are you real developer of new GC?
Re: D easily overlooked?
On 22.07.2017 16:20, Russel Winder via Digitalmars-d wrote: D without the GC isn't at all interesting, might as well use Go in that case. Uh, no.
Re: D easily overlooked?
On Saturday, 22 July 2017 at 15:13:12 UTC, Ali wrote: On Saturday, 22 July 2017 at 14:39:17 UTC, Moritz Maxeiner wrote: On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote: Unless some miracle happens and makes the GC better by preventing stop-the-world I have yet to see a (working, correct) non-STW GC that doesn't make other trade offs not acceptable for D (extra thread(s), memory barriers for all writes, etc.). There's room for improvement of the current GC, but I sincerely doubt we will see one that's not STW. or gets rid of the GC And remove one of the primary reasons why one doesn't have to prototype in some script language (e.g. python)? No thanks. Ocaml comes to mind, it is being used bu jane street for high frequency trading and they dont complain I think the key point it, is that if stw fast enough, it is good enough for most uses I think a very fast GC should be next on the list for D Ocaml's GC is stop-the-world for both its minor and major heap [1], so if someone wants to write another GC implementation for D, that's a good place to draw inspiration from, yes. [1] https://realworldocaml.org/v1/en/html/understanding-the-garbage-collector.html
Re: D easily overlooked?
On Saturday, 22 July 2017 at 14:39:17 UTC, Moritz Maxeiner wrote: On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote: Unless some miracle happens and makes the GC better by preventing stop-the-world I have yet to see a (working, correct) non-STW GC that doesn't make other trade offs not acceptable for D (extra thread(s), memory barriers for all writes, etc.). There's room for improvement of the current GC, but I sincerely doubt we will see one that's not STW. or gets rid of the GC And remove one of the primary reasons why one doesn't have to prototype in some script language (e.g. python)? No thanks. Ocaml comes to mind, it is being used bu jane street for high frequency trading and they dont complain I think the key point it, is that if stw fast enough, it is good enough for most uses I think a very fast GC should be next on the list for D
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
On Friday, 21 July 2017 at 19:36:08 UTC, H. S. Teoh wrote: However, I think the presentation of the DIP needs some work. For example, the rationales and lines of reasoning that eventually led to the currently proposed syntax, both from the original draft of this DIP and from the ensuing discussion in the previous review thread, ought to be included (of course, in summarized form -- no need to repeat the back-and-forth of the original discussions, but just the eventual line of thought). If possible, some of the discarded alternatives could be mentioned along with the reasons why they were eventually decided against. The first draft of the current proposal actually started with this approach: https://github.com/dlang/DIPs/commit/677c4e2bd5ff9b4bcbca35a28831560d5ce06f8c Hopefully this will help: https://github.com/dlang/DIPs/pull/88
Re: D easily overlooked?
On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote: Unless some miracle happens and makes the GC better by preventing stop-the-world I have yet to see a (working, correct) non-STW GC that doesn't make other trade offs not acceptable for D (extra thread(s), memory barriers for all writes, etc.). There's room for improvement of the current GC, but I sincerely doubt we will see one that's not STW. or gets rid of the GC And remove one of the primary reasons why one doesn't have to prototype in some script language (e.g. python)? No thanks.
Re: The X Macro using D
On Saturday, 22 July 2017 at 11:50:40 UTC, Stefan Koch wrote: tuple map and array are all pretty expensive. please profile. Well a bit more compile time isn't the end of the world, and by far not the only metric (e.g. readability and maintainability also rank high). You're slightly obsessed with the template compile-time topic ;). BTW, the term expensive is fairly subjective easily misunderstood. Sth. more specific would reduce the chance for confusion, e.g. "tuple map and array require longer to compile"
Re: D easily overlooked?
On Sat, 2017-07-22 at 13:27 +, aedt via Digitalmars-d wrote: > […] > Unless some miracle happens and makes the GC better by preventing > stop-the-world, or gets rid of the GC, D will not get any more > attention. D without the GC isn't at all interesting, might as well use Go in that case. So D only gets traction if it keeps a GC. Except for the "actually on the metal" people who can prove they cannot survive if there is a GC, and D does that already – but without the standard library. -- Russel. = Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder signature.asc Description: This is a digitally signed message part
Re: D easily overlooked?
On Friday, 14 July 2017 at 08:57:17 UTC, Wulfklaue wrote: https://blog.sourced.tech/post/language_migrations/ A recent article where github programming languages popularity and migration got analysed was very interesting but it showed one noticeable thing: [...] Unless some miracle happens and makes the GC better by preventing stop-the-world, or gets rid of the GC, D will not get any more attention.
Re: newCTFE Status July 2017
On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys,
Another work-filled two day went by.
And here is the fruit of the labor:
int[2][3] split(int[6] a)
{
int[2][3] result;
foreach (i; 0 .. typeof(result[0]).length)
{
foreach (j; 0 .. result.length)
{
auto idx = i*result.length + j;
result[j][i] = a[idx];
}
}
return result;
}
static assert(split([1,2,3,4,5,6]) == [[1, 4], [2, 5], [3, 6]]);
The above code does now work at ctfe.
Meaning we are well on our way of supporting multidimensional
arrays.
Multidimensional Slices however are a little tricker.
Re: The X Macro using D
On Friday, 21 July 2017 at 20:44:13 UTC, Enamex wrote: On Thursday, 20 July 2017 at 22:02:32 UTC, Walter Bright wrote: [...] How about this (if I'm not mistaken, this's only one template instantiation per tuple-type&extracted-index): [...] tuple map and array are all pretty expensive. please profile.
Re: Problem with integral promotions
Walter Bright wrote: 2. Codify existing practice, since it has been that way forever. Not matching C has caused problems, see 16997 and 17637. It may cause more serious silent problems for people converting C code to D code. i'd say "codify, and add warning". since i patched the warning into the compiler, i have no more problems with the current rules: compiler tells me about possible incompatibilities with C, and i can either add `()` to silent the warning, or explicitly cast to the type i want. i think most other people will prefer to get warning instead of code breakage too. at least i hope so. ;-)
Problem with integral promotions
They are supposed to match C. But they don't for unary operators + - ~, and as far as I can tell never did. https://issues.dlang.org/show_bug.cgi?id=16997 https://issues.dlang.org/show_bug.cgi?id=17637 Note that the spec says: "Note: unlike in C and C++, the usual integral promotions are not performed prior to the complement operation." http://dlang.org/spec/expression.html#complement_expressions Where did that come from? And the spec says nothing about unary - or unary +. http://dlang.org/spec/expression.html#unary-expression It's been like this at least since D1, both the code and the Spec. So, we have a choice: 1. Fix it so it matches C, as has been generally promised. Fixing it will break existing code such as: https://github.com/dlang/phobos/pull/5646 but worse, it may silently break code. I don't know of a reasonable way to detect this. 2. Codify existing practice, since it has been that way forever. Not matching C has caused problems, see 16997 and 17637. It may cause more serious silent problems for people converting C code to D code.
Re: New Garbage Collector?
On Saturday, 22 July 2017 at 10:17:49 UTC, Temtaime wrote: The new precise GC will be never added to druntime. It is dead, man. Why?
Re: New Garbage Collector?
On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote: In the forum, I saw a thread about someone working on a new GC. Just wanted to know if there's any updates on that. And what issues is it going to fix.. Personally, I would be greatly delighted if it acknowledges the Stop-The-World problem[1]. Going around it is shown not to be impossible[2]. I do understand it's not trivial task but how is the community/core devs supporting this? [1] https://dlang.org/spec/garbage.html [2] https://hub.docker.com/r/nimlang/nim/ The new precise GC will be never added to druntime. It is dead, man.
Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins
On Saturday, 22 July 2017 at 03:05:55 UTC, aberba wrote:
How about this in current syntax? (that's what I do)
int func(int a)
in
{
assert(a >= 0);
}
out(result)
{
assert(result >= 2);
}
body
{
return 2 * a;
}
I can only restate my opinion against the above as "too verbose"
for the common use case of simple conditions such as null
pointer, range empty, etc. Until in contracts are injected at the
call site, the above is essentially equivalent to this less
verbose version:
---
int func(int a)
{
assert (a >= 0); // > should be used here, though
int result;
scope (success) assert (result >= 2);
return result = 2*a;
}
---
an improvement could be:
int func(int a)
in assert(a >= 0);
out(result) assert(result >= 2);
body
{
return 2 * a;
}
just like an in-line if-else statement
Summary of issues with that (that you can also find in the Round
1 discussion):
- Free semicolons within the function signature are inconsistent
with the rest of D
- The `body` keyword is redundant here; imho it should also have
been removed (deprecation first) from the current contract syntax
instead of being replaced by `do`, because it's inconsistent with
the rest of D to require a keyword to delimit the *end* of an
optional element, but since those (shell) contracts are extremely
verbose, anyway, it doesn't matter much
- There already is the verbose syntax to specify contracts as
"shells" that are to be explicitly filled with whatever checks
one needs (assert, enforce, etc.), i.e. requiring the user to
couple a contract with its implementation; the new syntax allows
the user to specify contracts as what they originally are (in the
DbC context): abstract promises between caller and callee with
the user not needing to worry about the implementation.
- Imho the reason why current contract syntax is used only by few
people is its verbosity; the more succinct the new syntax, the
higher chance I think it has of yielding more widespread use
