Re: Evaluation order of index expressions
On 25 May 2015 01:10, Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote: On 05/25/2015 12:36 AM, Iain Buclaw via Digitalmars-d wrote: This comes up once in a while. We should stick with left to right through and through. It's a simple matter of getting somebody on the compiler team to find the time for it. -- Andrei I find it is not as clear cut as that. In gdc, there is a compiler flag that tells the optimizer to honour left to right evaluation, and because of both what you say and the agreement of others, it seems natural to have this turned on by default. However, this has an interesting side effect with operations with side effects. Ie: foo += bar() could either produce expected or surprising results. Hint, the LTR order - foo = foo + bar() - gives the most surprise in my experience from users. I think I still don't get it. What is the surprise? That bar() is evaluated before the value is written to foo? That foo is cached before bar() is evaluated. The context here involves concurrency where bar() calls yield and makes changes to foo before returning to assign the updated results.
Re: Checking template parameter types of class
On 05/24/2015 09:14 PM, tcak wrote: Line 243: auto fileResourceList = new shared FileResourceList( 2 ); main.d(243): Error: class main.FileResourceList(T) if (is(T : FileResource)) is used as a type struct and class templates do not have automatic type deduction; function templates do. The solution is to provide a convenience function template alongside the struct or class. auto fileResourceList = new shared FileResourceList!FileResource( 2 ); Then it works. The error message is not indicating directly this, though logically it is still correct. 'if (is(T : FileResource))' part means if T can implicitly be converted to FileResource. You still provide T so that it gets checked. Ali
Re: Uphill
On Mon, 25 May 2015 00:24:26 +0200, Iain Buclaw via Digitalmars-d wrote: I find the situation being like at university looking for grants or funding, and constantly being told. #39;Oh yes, it is important what you are doing, and you must keep doing it as it is pivotal for future success. But no, we won#39;t help you.#39; that's 'cause GCC is untameable beast for average Joe like me, for example. ;-) signature.asc Description: PGP signature
Re: Evaluation order of index expressions
On Monday, 25 May 2015 at 07:33:49 UTC, ketmar wrote: On Sun, 24 May 2015 19:30:52 +, kinke wrote: So for the 2nd assignment's left-hand-side, the index is evaluated before evaluating the container! Please don't tell me that's by design. : it is. at least this is what i was told when i faced the similar issue. WONTIFX, STFU. To be fair, the example that the OP gave is almost the same thing as foo(++i, ++i); whereas what you came up with had a lot more layers to it, with whole chains of function calls affecting each other. With the kind of example you came up with, even with defining the evaluation as strictly left-to-right, you would _still_ run into screwy problems with stuff easily being mutated in a different order than you expected. Defining the order of evaluation as being strictly left-to-right will avoid some of the common bugs cause by folks foolishly doing something like foo(++i, ++i); but the reality of the matter is, if you start doing stuff like mutating the arguments inside of the function inside of the function when the same arguments are being passed to other functions in the same expression, you _will_ have weird and unexpected stuff happening. It might be completely well-defined and consistent, but it may not be what you expect, and even if it is, a slight change to the code could change the order. So, the kind of stuff that you're complaining about not being able to do really shouldn't be done regardless of how well-defined the order of evaluation is. It's just begging for trouble. - Jonathan M Davis
Re: Checking template parameter types of class
On Monday, 25 May 2015 at 04:15:00 UTC, tcak wrote: main.d(243): Error: class main.FileResourceList(T) if (is(T : FileResource)) is used as a type The error message is not indicating directly this, though logically it is still correct. Compiler means template is used as a type which is an error since templates are not types. I guess adding the word template to that message would make it more clear.
Re: Idiomatic way to call base method in generic code
On Sun, 24 May 2015 23:32:50 +, ZombineDev wrote:
I know I can call a base implementation of a method like in 3), but I
need to do it generically like in 2). Does anybody now how I can achieve
this?
i don't know why you want that, but something like this may do:
auto callBaseMethod(string MTN, C, Args...) (inout C self, Args args) {
alias FSC = BaseClassesTuple!(C)[0];
return mixin(`self.`~FSC.stringof~`.`~MTN~(args));
}
writeln(d.callBaseMethod!toString);
Additionally is there a way to make 1) work without using string mixins?
no. and again, why do you want that? why do you people are so afraid of
string mixins? ;-)
signature.asc
Description: PGP signature
Re: Evaluation order of index expressions
On Sun, 24 May 2015 19:30:52 +, kinke wrote: So for the 2nd assignment's left-hand-side, the index is evaluated before evaluating the container! Please don't tell me that's by design. : it is. at least this is what i was told when i faced the similar issue. WONTIFX, STFU. signature.asc Description: PGP signature
[Issue 14469] file.readText on Win64 doesn't work for files 4GB.
https://issues.dlang.org/show_bug.cgi?id=14469 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/95fd043dc6d0c945c171f8874761e1399a11252c Fix Issue 14469 - read 4GB file on Windows x64. https://github.com/D-Programming-Language/phobos/commit/75f068773ccc0750c2cf865fe2f621a9947723f3 Merge pull request #3218 from artemalive/issue_14469 Fix Issue 14469 - read 4GB file on Windows x64. --
[Issue 14469] file.readText on Win64 doesn't work for files 4GB.
https://issues.dlang.org/show_bug.cgi?id=14469 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Idiomatic way to call base method in generic code
On Monday, 25 May 2015 at 07:57:49 UTC, ketmar wrote:
i don't know why you want that, but something like this may do:
auto callBaseMethod(string MTN, C, Args...) (inout C self, Args
args) {
alias FSC = BaseClassesTuple!(C)[0];
return mixin(`self.`~FSC.stringof~`.`~MTN~(args));
}
writeln(d.callBaseMethod!toString);
Thanks!
[1]:
https://github.com/ZombineDev/Chess2RT/blob/c36ba3e73744cf3912c25abccedbbd742f7f5be3/source/util/prettyprint.d#L7
[2]:
https://github.com/ZombineDev/Chess2RT/blob/master/source/util/prettyprint.d#L14
I initially had [1] a string mixin which goes through all the
members of a class and prints them and also prints its base
class' members, but then it seemed that it would be more cleaner
if I could use a function template [2] (which also improved my
debug experience) so I started exploring alias, but they turned
out to be less powerful then I thought:
alias can't refer to a nested member:
-
struct Point2
{
float x;
float y;
}
struct Line2
{
Point2 start;
Point2 end;
mixin Access;
// alias x1 = this.start.x; - this doesn't work :(
alias x1 = get!start.x;
alias y1 = get!start.y;
alias x2 = get!end.x;
alias y2 = get!end.y;
}
// I need to use a mixin to flatten the access :(
private mixin template Access()
{
ref auto get(string accessPattern)() inout
{
return mixin(accessPattern);
}
}
-
So I wondered if I'm missing something and decided to ask here.
no. and again, why do you want that? why do you people are so
afraid of
string mixins? ;-)
Well I'm not afraid of string mixins, but the `alias` keyword
seemed to possess some mysterious power (I was also under the
influence of this [3] blog post) which I wanted to explore. Also
they're a bit more elegant.
[3]:
http://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/
Re: indie game contests
Awww Danni, you've forsaken me! :P On 25 May 2015 at 03:47, Vlad Levenfeld via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 23 May 2015 at 05:17:13 UTC, Danni Coy wrote: Got very close to a year or so ago. Probably something I would be much more capable of doing now. The only downside is that I enjoy doing asset creation more. That's perfect, actually. Shoot me an email, we can all assemble a D team and make something awesome.
Re: Evaluation order of index expressions
On Monday, 25 May 2015 at 08:00:15 UTC, Jonathan M Davis wrote: it is, a slight change to the code could change the order. So, the kind of stuff that you're complaining about not being able to do really shouldn't be done regardless of how well-defined the order of evaluation is. It's just begging for trouble. The the compiler should complain about it...
Re: Uphill
On Sunday, 24 May 2015 at 16:03:30 UTC, Andrei Alexandrescu wrote: On 5/24/15 1:20 AM, weaselcat wrote: IMO I think the worst thing C++ has done is blatantly ignore features that have been 'killer' in D(see: the reaction to the static_if proposal) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4461.html -- Andrei Quote: always going to establish a new scope. This alone will make it much less powerful that D's static if.
Re: Uphill
On Sunday, 24 May 2015 at 19:06:28 UTC, weaselcat wrote: Furthermore, I strongly dislike that Rust has made it completely impossible to opt out of bounds checking without annotating your code with unsafe. But this is exactly the situation in D, isn't it? As soon as you use `arr.ptr[i]`, you're no longer @safe. Or do you mean that there's no command-line switch equivalent to -noboundscheck?
Regex-Fu
I'm a bit at a loss here. I cannot get the longest possible
match. I tried several versions with eager operators and stuff,
but D's regex engine(s) always seem to return the shortest match.
Is there something embarrassingly simple I'm missing?
void main()
{
import std.regex : regex, matchFirst;
import std.stdio : writeln;
auto word = blablahula;
auto m = matchFirst(word, regex(^([a-z]+)(hula|ula)$));
writeln(m); // prints [blablahula, blablah, ula]
}
I want it to return hula not ula.
Re: Regex-Fu
I cannot get the longest possible it match longest for first group ([a-z]+) try ^([a-z]+?)(hula|ula)$
Re: Regex-Fu
On Monday, 25 May 2015 at 11:20:46 UTC, novice2 wrote: I cannot get the longest possible it match longest for first group ([a-z]+) try ^([a-z]+?)(hula|ula)$ Namespace, novice2: Ah, I see. The problem was with the first group that was too greedy, not with the second. I was focusing on the latter. Thanks, this works now!
Re: Request for Features/Ideas: A std.archive package
On Monday, 25 May 2015 at 03:33:37 UTC, Rikki Cattermole wrote: Anyway, take a look at e.g. IWritableCapsuleArchive. There is a LOT more whitespace needed to be added in that file. Could you elaborate? Functions/etc in the interfaces are grouped by purpose (opIndexAssign/opSliceAssign are grouped because they're related operators; fileName and lastModifed because they're both bits of metadata; put and save because they're both range interface functions).
Autotester FreeBSD: Cycle detected between modules with ctors/dtors
The autotester complains about cycles between module ctors on FreeBSD 32/64 for this PR: https://github.com/D-Programming-Language/phobos/pull/3233 The modules are std.digest.hmac (added in the PR), and std.digest.digest. However, neither of them even has a module ctor or dtor. I remember vaguely that there were some problems with cycle detection. Is this an instance of it? What can be done about it?
Re: Regex-Fu
On Monday, 25 May 2015 at 11:11:50 UTC, Chris wrote:
I'm a bit at a loss here. I cannot get the longest possible
match. I tried several versions with eager operators and stuff,
but D's regex engine(s) always seem to return the shortest
match. Is there something embarrassingly simple I'm missing?
void main()
{
import std.regex : regex, matchFirst;
import std.stdio : writeln;
auto word = blablahula;
auto m = matchFirst(word, regex(^([a-z]+)(hula|ula)$));
writeln(m); // prints [blablahula, blablah, ula]
}
I want it to return hula not ula.
Make the + operator less greedy:
matchFirst(word, regex(^([a-z]+?)(hula|ula)$));
[Issue 14554] [REG2.066] dmd generate wrong error message for multiple template with same name
https://issues.dlang.org/show_bug.cgi?id=14554 --- Comment #2 from Daniel Kozak kozz...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4681 --
DMD Symbol Reference Analysis Pass
Does DMD currently do any analysis of references to a symbol in a
given scope? If not where could this information be extracted (in
which visitor/callback) and in what structure should it, if so,
be stored?
Reason: After having read about Rust's data-flow (and in turn
escape) analysis I'm very curious about how difficult it would be
to add more clever type inference of, for instance, mutability,
based on this analysis.
Two cases come to my mind:
A: Non-Templated Function: must be @safe (or perhaps @trusted)
pure and parameter must qualified as const (or in).
B: Templated Function: Usage of parameter in body must be
non-mutating; meaning no lhs of assignment op (=, +=, ...), and
calls to functions that take parameter as argument must be
transitively fulfill A and B.
I'm guessing
Scope::insert(Dsymbol*s)
{
if (VarDeclaration *vd = s-isVarDeclaration())
{
// ..
is of interest. Is there another member function called everytime
a Dsymbol is referenced?
I'm guessing MODFlags plays a role here aswell.
I'm asking again because of the work recently done in DIP-25,
that may be related to this problem.
Re: Request for Features/Ideas: A std.archive package
On 25/05/2015 10:48 p.m., Liam McSherry wrote:
On Monday, 25 May 2015 at 03:33:37 UTC, Rikki Cattermole wrote:
Anyway, take a look at e.g. IWritableCapsuleArchive.
There is a LOT more whitespace needed to be added in that file.
Could you elaborate?
Functions/etc in the interfaces are grouped by purpose
(opIndexAssign/opSliceAssign are grouped because they're related
operators; fileName and lastModifed because they're both bits of
metadata; put and save because they're both range interface functions).
Basically there is no lines between one function declaration and another.
E.g.
/// description here
/// and here
/// one more
void func() { ... }
/// description here
/// and here
/// and yes one more
void func2() { ... }
Re: Idiomatic way to call base method in generic code
On Monday, 25 May 2015 at 09:24:58 UTC, ZombineDev wrote:
On Monday, 25 May 2015 at 07:57:49 UTC, ketmar wrote:
i don't know why you want that, but something like this may do:
auto callBaseMethod(string MTN, C, Args...) (inout C self,
Args args) {
alias FSC = BaseClassesTuple!(C)[0];
return mixin(`self.`~FSC.stringof~`.`~MTN~(args));
}
writeln(d.callBaseMethod!toString);
Thanks!
[1]:
https://github.com/ZombineDev/Chess2RT/blob/c36ba3e73744cf3912c25abccedbbd742f7f5be3/source/util/prettyprint.d#L7
[2]:
https://github.com/ZombineDev/Chess2RT/blob/master/source/util/prettyprint.d#L14
I initially had [1] a string mixin which goes through all the
members of a class and prints them and also prints its base
class' members, but then it seemed that it would be more
cleaner if I could use a function template [2] (which also
improved my debug experience) so I started exploring alias, but
they turned out to be less powerful then I thought:
alias can't refer to a nested member:
-
struct Point2
{
float x;
float y;
}
struct Line2
{
Point2 start;
Point2 end;
mixin Access;
// alias x1 = this.start.x; - this doesn't work :(
alias x1 = get!start.x;
alias y1 = get!start.y;
alias x2 = get!end.x;
alias y2 = get!end.y;
}
// I need to use a mixin to flatten the access :(
private mixin template Access()
{
ref auto get(string accessPattern)() inout
{
return mixin(accessPattern);
}
}
-
So I wondered if I'm missing something and decided to ask here.
no. and again, why do you want that? why do you people are so
afraid of
string mixins? ;-)
Well I'm not afraid of string mixins, but the `alias` keyword
seemed to possess some mysterious power (I was also under the
influence of this [3] blog post) which I wanted to explore.
Also they're a bit more elegant.
[3]:
http://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/
You might be interested in this thread:
http://forum.dlang.org/thread/mi3pip$22va$1...@digitalmars.com
Re: Evaluation order of index expressions
On Monday, 25 May 2015 at 08:00:15 UTC, Jonathan M Davis wrote: It might be completely well-defined and consistent, but it may not be what you expect, and even if it is, a slight change to the code could change the order. If the behavior isn't what I expect (and I don't think that's often case for left-to-right order), then the language should force me to express the intention differently. If it's not well-defined, I may not be aware of such issues until I use a different compiler. Allowing implementation-dependent evaluation order is just begging for additional bugs and portability issues. Another example: b = 0; ((++b *= 5) *= 2) += ++b * (b -= 6); DMD yields b=60, LDC the intuitively correct b=65. If it's well defined, one may argue about the form of such a statement, but it's not silly code with different results depending on the used D compiler anymore. +1 for Timon's PR being merged asap.
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #15 from Sobirari Muhomori dfj1es...@sneakemail.com --- BTW, Windows 8 has GetSystemTimePreciseAsFileTime function for time reading with better precision. --
Re: Request for Features/Ideas: A std.archive package
On Monday, 25 May 2015 at 11:50:25 UTC, Rikki Cattermole wrote: Basically there is no lines between one function declaration and another. I've added some extra white-space.
Re: Expanding asm.dlang.org
On Monday, 25 May 2015 at 14:54:59 UTC, Mike wrote: On Monday, 25 May 2015 at 14:41:51 UTC, Mike wrote: I can add any cross compilers hosted on gdcproject.org. What do you need from me? Or did you mean any compiler from the finite list here: http://forum.dlang.org/post/satkcwpjqogloqlrj...@forum.dlang.org? Cut and pasted the wrong link. Did you mean any compiler from the finite list here: http://gdcproject.org/downloads?
Re: Uphill
On 25 May 2015 09:45, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Mon, 25 May 2015 00:24:26 +0200, Iain Buclaw via Digitalmars-d wrote: I find the situation being like at university looking for grants or funding, and constantly being told. #39;Oh yes, it is important what you are doing, and you must keep doing it as it is pivotal for future success. But no, we won#39;t help you.#39; that's 'cause GCC is untameable beast for average Joe like me, for example. ;-) Both have equal complexity, so that is no excuse. DMD just operates at a lower level, on a smaller scale, and forces you to think about the effect on generated object code.
Re: This Week in D: ... not much, actually
Or a long review for more content.
[dconf] Share a ride SLC-hotel?
I'm arriving in SLC on Tue at 11:39 pm. Anyone up for sharing a ride? I'm thinking http://www.expressshuttleutah.com/. -- Andrei
Re: Uphill
On 5/25/15 3:51 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Sunday, 24 May 2015 at 16:03:30 UTC, Andrei Alexandrescu wrote: On 5/24/15 1:20 AM, weaselcat wrote: IMO I think the worst thing C++ has done is blatantly ignore features that have been 'killer' in D(see: the reaction to the static_if proposal) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4461.html -- Andrei Quote: always going to establish a new scope. This alone will make it much less powerful that D's static if. I know. Politics does have a cost. -- Andrei
Re: Evaluation order of index expressions
On 5/24/15 11:13 PM, Iain Buclaw via Digitalmars-d wrote: The context here involves concurrency where bar() calls yield and makes changes to foo before returning to assign the updated results. We're not addressing that. += is not supposed to do concurrency magic. -- Andrei
Re: Replacing nested loops foreach using map/each/etc
On Monday, 25 May 2015 at 15:46:54 UTC, Dennis Ritchie wrote:
On Monday, 25 May 2015 at 15:06:45 UTC, Alex Parrill wrote:
Hint: Use `cartesianProduct` [1] with three iota ranges to
replace the foreachs, and `filter` to replace the if
[1]
http://dlang.org/phobos/std_algorithm_setops.html#.cartesianProduct
Thank you. Is it possible to replace the loop `foreach`
function `each` or `chunkBy` with the auxiliary functions?
import std.stdio, std.algorithm, std.range;
void main() {
const x = 12, y = 65, z = 50, s = 1435;
auto a = iota(0, x + 1);
foreach (idx; cartesianProduct(a, a, a).filter!(i = i[0] *
(y + 3 * z) + i[1] * (y + 2 * z) + i[2] * (y + z) == s)) {
writeln(idx[0] + idx[1] + idx[2]);
writeln(idx[0] * 3 + idx[1] * 2 + idx[2]);
writeln(idx[0] * 3 + idx[1] * 2 + idx[2]);
writeln(idx[0], idx[1], idx[2]);
}
}
-
http://rextester.com/HZP96719
import std.algorithm;
import std.range;
import std.stdio;
void main()
{
const x = 12, y = 65, z = 50, s = 1435;
auto a = iota(0, x + 1);
cartesianProduct(a, a, a)
.filter!(i = i[0] * (y + 3 * z)
+ i[1] * (y + 2 * z)
+ i[2] * (y + z)
== s)
.each!((idx)
{
writeln(idx[0] + idx[1] + idx[2]);
writeln(idx[0] * 3 + idx[1] * 2 + idx[2]);
writeln(idx[0] * 3 + idx[1] * 2 + idx[2]);
writeln(idx[0], idx[1], idx[2]);
});
}
Re: Evaluation order of index expressions
On 5/25/15 1:00 AM, Jonathan M Davis wrote: foo(++i, ++i); More complete example: table[++i] = objTable[++i].funcTable[++i](++i, ++i); should be well defined and evaluate left to right. Andrei
Expanding asm.dlang.org
We currently have 4 different online compiler/disassembers all forked from the same GCC Explorer, and all apparently hosted by different individuals. http://asm.dlang.org (DMD) http://d.godbolt.org/ (GDC) http://explore.dgnu.org/ (GDC) http://ldc.acomirei.ru/ (LDC) Judging by the announcement for asm.dlang.org (http://forum.dlang.org/post/satkcwpjqogloqlrj...@forum.dlang.org) the plan was to expand it. Are the 3 primary compilers already installed on the asm.dlang.org host machine? If so, do we just need to update the configuration files? If not, what do you need to add a new compiler? * I would like to add a GDC ARM Thumb cross compiler and/or an LDC compiler with an ARM Thumb backend. What do you need from me to do that? Thanks, Mike
Replacing nested loops foreach using map/each/etc
Hi,
Is it possible to write such a construction that could push
immediately to a conditional statement without using nested
loops? Ie organize search directly in the iterator if provided by
a map / each / iota and other support functions.
Ie I want to write this code shorter :)
import std.stdio;
void main() {
const x = 12, y = 65, z = 50, s = 1435;
foreach (i; 0 .. x + 1)
foreach (j; 0 .. x + 1)
foreach (k; 0 .. x + 1)
if (i * (y + 3 * z) + j * (y + 2 * z) + k * (y +
z) == s) {
writeln(i + j + k);
writeln(i * 3 + j * 2 + k);
writeln(i * 3 + j * 2 + k);
writeln(i, j, k);
}
}
-
http://rextester.com/SJTU87854
Re: Expanding asm.dlang.org
On 25 May 2015 16:30, Mike via Digitalmars-d digitalmars-d@puremagic.com wrote: We currently have 4 different online compiler/disassembers all forked from the same GCC Explorer, and all apparently hosted by different individuals. http://asm.dlang.org (DMD) http://d.godbolt.org/ (GDC) http://explore.dgnu.org/ (GDC) http://ldc.acomirei.ru/ (LDC) Judging by the announcement for asm.dlang.org ( http://forum.dlang.org/post/satkcwpjqogloqlrj...@forum.dlang.org) the plan was to expand it. Are the 3 primary compilers already installed on the asm.dlang.org host machine? If so, do we just need to update the configuration files? If not, what do you need to add a new compiler? * I would like to add a GDC ARM Thumb cross compiler and/or an LDC compiler with an ARM Thumb backend. What do you need from me to do that? I can add any cross compilers hosted on gdcproject.org. You'd need to go through Godbolt to get it on his host. asm.dlang.org is a no go because it has been tailored for dmd only.
Re: Expanding asm.dlang.org
On 25 May 2015 at 18:45, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 5/25/15 7:36 AM, Iain Buclaw via Digitalmars-d wrote: I can add any cross compilers hosted on gdcproject.org http://gdcproject.org. You'd need to go through Godbolt to get it on his host. asm.dlang.org http://asm.dlang.org is a no go because it has been tailored for dmd only. The right answer is to tailor asm.dlang.org for everything. -- Andrei That would involve making DMD comply with GDC and LDC on matters of emission. :-)
Re: Expanding asm.dlang.org
On 25 May 2015 at 17:02, Iain Buclaw ibuc...@gdcproject.org wrote: On 25 May 2015 16:55, Mike via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 25 May 2015 at 14:41:51 UTC, Mike wrote: I can add any cross compilers hosted on gdcproject.org. What do you need from me? Or did you mean any compiler from the finite list here: http://forum.dlang.org/post/satkcwpjqogloqlrj...@forum.dlang.org? The finite list here: http://gdcproject.org/downloads Currently only arm eabi and hard float. I've updated explore.dgnu.org with gdc-4.9, along with ARM and ARMHF variants. ARM supports -mthumb code generation. http://goo.gl/NmdnU1 Iain
Re: D needs...
On Monday, 18 May 2015 at 21:51:49 UTC, Namespace wrote: Knee-jerk response: if no return attribute on a function it should be safe to bind rvalues to ref parameters. Of course that's impractical as a default so explicit auto ref would be needed. -- Andrei Would it be to hasty if someone would start implementing auto ref for non-templates right now? Or should a more experienced user do that? Just in case I can contribute somehow. I took the liberty to begin with an implementation. Thanks to Kenjiis work, it was not too difficult, I had to adjust only the changes on the new code base: https://github.com/Dgame/dmd/tree/auto-ref-for-non-templates Maybe this could be reviewed as soon as 'return ref' is fully implemented.
Re: Request for Features/Ideas: A std.archive package
On 26/05/2015 1:39 a.m., Liam McSherry wrote: On Monday, 25 May 2015 at 11:50:25 UTC, Rikki Cattermole wrote: Basically there is no lines between one function declaration and another. I've added some extra white-space. Awesome thanks, it'll make it a little easier to get it through review. There is still a few things left to fix, but no issue for now.
Re: Autotester FreeBSD: Cycle detected between modules with ctors/dtors
On 5/25/15 6:18 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: The autotester complains about cycles between module ctors on FreeBSD 32/64 for this PR: https://github.com/D-Programming-Language/phobos/pull/3233 The modules are std.digest.hmac (added in the PR), and std.digest.digest. However, neither of them even has a module ctor or dtor. I remember vaguely that there were some problems with cycle detection. Is this an instance of it? What can be done about it? I added my comments, I think I know the issue. -Steve
Re: Replacing nested loops foreach using map/each/etc
On Monday, 25 May 2015 at 15:06:45 UTC, Alex Parrill wrote:
Hint: Use `cartesianProduct` [1] with three iota ranges to
replace the foreachs, and `filter` to replace the if
[1]
http://dlang.org/phobos/std_algorithm_setops.html#.cartesianProduct
Thank you. Is it possible to replace the loop `foreach` function
`each` or `chunkBy` with the auxiliary functions?
import std.stdio, std.algorithm, std.range;
void main() {
const x = 12, y = 65, z = 50, s = 1435;
auto a = iota(0, x + 1);
foreach (idx; cartesianProduct(a, a, a).filter!(i = i[0] *
(y + 3 * z) + i[1] * (y + 2 * z) + i[2] * (y + z) == s)) {
writeln(idx[0] + idx[1] + idx[2]);
writeln(idx[0] * 3 + idx[1] * 2 + idx[2]);
writeln(idx[0] * 3 + idx[1] * 2 + idx[2]);
writeln(idx[0], idx[1], idx[2]);
}
}
-
http://rextester.com/HZP96719
Re: Evaluation order of index expressions
On Monday, 25 May 2015 at 12:38:29 UTC, kinke wrote:
On Monday, 25 May 2015 at 08:00:15 UTC, Jonathan M Davis wrote:
It might be completely well-defined and consistent, but it may
not be what you expect, and even if it is, a slight change to
the code could change the order.
If the behavior isn't what I expect (and I don't think that's
often case for left-to-right order), then the language should
force me to express the intention differently. If it's not
well-defined, I may not be aware of such issues until I use a
different compiler.
It seems like you still don't understand. Yes, defining the order
of evaluation within an expression as being left-to-right makes
it easier to deal with what is directly inside the expression,
and the compiler could be make to do that (and from the sounds of
it likely will). It could also be made to not be fixed about the
order of evaluation but give an error when it detects that the
order of evaluation matters, so that expressions like
foo(++i, ++i);
give an error. But even so, the compiler _cannot_ be made to
catch all such problems for you, because all it takes is starting
to bury the problem within other function calls within the
expression, and while the order of evaluation in such cases may
very well be defined, whether it's going to do what you expect is
a completely different matter. For instance, what if you had
int bar()
{
return ++i;
}
foo(bar(), bar());
Now, because ++i is inside a call to another function, the
compiler can no longer see that the arguments that you're using
depend on one another. The results _are_ well-defined, but
whether it's what you expect is another matter. With one extra
layer like this, you'll probably see it, and it'll be doing what
you want, but what if you have an expression like
auto f = foo(bar() + baz(bop(), beep() + boop()));
and 4 levels down into the call stack bar() and beep() both
mutate a static or global variable - or some other shared
resource. Then the result of this expression ends up depending on
an order of evaluation issue that you can't see without really
digging into the code, and the compiler sure isn't going to see
for you. You might see that swapping the arguments around in the
expression results in a different result when you think that it
shouldn't, but just as likely, you wouldn't catch that, and a
small change to the code later could change the results
unexpectedly, which you might or might not notice.
Now, that sort of thing is all the more reason to avoid using
static or global variables, and it's the sort of thing that I
would hope good code would avoid. But defining the order of
evaluation as left-to-right, doesn't make those problems go away.
At best, it makes them consistent, and that may be worth it, but
it's not a silver bullet. And it takes optimization opportunities
away from the compiler, since in many cases, it can reorder how
the expression is evaluated to make better use of the registers
and whatnot. So, forcing the order of evaluation is not without
its cons, even if it did solve all order of evaluation issues,
and it really doesn't - especially when that often depends on
what you expect.
Ketmar had a screwy example with arrays a while back that he was
complaining bitterly about not working due to order of evaluation
issues, but IIRC he had recursive function calls which affected
each other and was having all kinds of problems just because he
insisted on doing multiple things in an expression rather than
splitting them out. And the results he was getting were
completely consistent; they just weren't what he wanted. The
order of evaluation mattered too much in the expressions that he
was writing.
Ultimately, if you want to reduce the risk of bugs, you really
should be writing expressions where the order of evaluation
doesn't matter, or where it only matters based on operator
precedence directly within the expression so that it really
doesn't matter what other code is doing. And forcing
left-to-right evaluation doesn't change that. All it really does
is make what what's happening consistent. It doesn't mean that
relying on it is a good idea or that it's going to fix anything
but the some of the most basic order of evaluation issues.
Personally, I don't think that it's worth the cost in lost
optimizations, but even if it is, my point here is really that at
best it only fixes part of the problem.
- Jonathan M Davis
Re: Expanding asm.dlang.org
On 25 May 2015 at 17:06, Mike via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 25 May 2015 at 15:03:06 UTC, Iain Buclaw wrote: On 25 May 2015 16:55, Mike via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 25 May 2015 at 14:41:51 UTC, Mike wrote: I can add any cross compilers hosted on gdcproject.org. What do you need from me? Or did you mean any compiler from the finite list here: http://forum.dlang.org/post/satkcwpjqogloqlrj...@forum.dlang.org? The finite list here: http://gdcproject.org/downloads Currently only arm eabi and hard float. Ok, then what is needed from me to get my cross-compiler on that list? Only requirement is that it is a Linux x86 cross (not 64bit), and for it to be uploaded somewhere for me to retrieve for inspection.
Re: Uphill
On Mon, 25 May 2015 16:59:48 +0200, Iain Buclaw via Digitalmars-d wrote: On 25 May 2015 09:45, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Mon, 25 May 2015 00:24:26 +0200, Iain Buclaw via Digitalmars-d wrote: I find the situation being like at university looking for grants or funding, and constantly being told. #39;Oh yes, it is important what you are doing, and you must keep doing it as it is pivotal for future success. But no, we won#39;t help you.#39; that's 'cause GCC is untameable beast for average Joe like me, for example. ;-) Both have equal complexity, so that is no excuse. DMD just operates at a lower level, on a smaller scale, and forces you to think about the effect on generated object code. i'm afraid that they doesn't have equal complexity. i can read DMD code (ok, even backend, it's hard, but doable), but i cannot read GCC backend code in the same amount of time. and there are alot more things i have to know to understand GDC. i made some trivial fixes in DMD backend, yet i don't even know where to start to understand at least *something* in GCC. signature.asc Description: PGP signature
[Issue 14617] PTHREAD_MUTEX_INITIALIZER does not work on OSX
https://issues.dlang.org/show_bug.cgi?id=14617 --- Comment #8 from Andrei Alexandrescu and...@erdani.com --- I now understand. Let's leave types.d be code-free for now (in fact it could be renamed to types.di) and only fix PTHREAD_MUTEX_INITIALIZER at least for now. --
Re: Uphill
On 25 May 2015 at 18:14, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Mon, 25 May 2015 16:59:48 +0200, Iain Buclaw via Digitalmars-d wrote: On 25 May 2015 09:45, ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Mon, 25 May 2015 00:24:26 +0200, Iain Buclaw via Digitalmars-d wrote: I find the situation being like at university looking for grants or funding, and constantly being told. #39;Oh yes, it is important what you are doing, and you must keep doing it as it is pivotal for future success. But no, we won#39;t help you.#39; that's 'cause GCC is untameable beast for average Joe like me, for example. ;-) Both have equal complexity, so that is no excuse. DMD just operates at a lower level, on a smaller scale, and forces you to think about the effect on generated object code. i'm afraid that they doesn't have equal complexity. i can read DMD code (ok, even backend, it's hard, but doable), but i cannot read GCC backend code in the same amount of time. and there are alot more things i have to know to understand GDC. i made some trivial fixes in DMD backend, yet i don't even know where to start to understand at least *something* in GCC. Yes, they do. The key difference is that GCC doesn't require you to delve into it's backend, as a language implementer, you only need to think of how the code should be represented in it's tree language (ie: http://icps.u-strasbg.fr/~pop/gcc-ast.html) - Because of this, I never need to look at assembly dumps to understand what is going on, only tree dumps, which are handily outputted in a C-style format with -fdump-tree-original=stdout.
Re: Expanding asm.dlang.org
I can add any cross compilers hosted on gdcproject.org. What do you need from me?
Re: Expanding asm.dlang.org
On Monday, 25 May 2015 at 14:41:51 UTC, Mike wrote: I can add any cross compilers hosted on gdcproject.org. What do you need from me? Or did you mean any compiler from the finite list here: http://forum.dlang.org/post/satkcwpjqogloqlrj...@forum.dlang.org?
Re: shared libs for OSX
I've been reading through the Mach-O docs[1], and it seems that dynamic libs are treated the same as static libs in that exported symbols can only be defined once, even across dynamically loaded libraries. This is why calling rt_init from my dylib ended up calling the one that was already defined in the application image. I was able to call the rt_init from the dylib by specifically requesting it through dlsym, but then, all the global variables it used(_isRuntimeInitialized, etc) still ended up resolving to the ones in the application image. At this point, my impression is that it would be very impractical, if not impossible to have separate druntimes for each shared library. Even when you do link separate runtimes, dyld still treats all the exported symbols as shared. @Martin So correct me if I'm wrong, but it seems the _only_ choice is a shared druntime for osx. Could you elaborate a bit on how you've managed to do this for linux? [1] https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachOTopics/0-Introduction/introduction.html Thanks, Bit
Re: Replacing nested loops foreach using map/each/etc
On Monday, 25 May 2015 at 14:25:52 UTC, Dennis Ritchie wrote:
Hi,
Is it possible to write such a construction that could push
immediately to a conditional statement without using nested
loops? Ie organize search directly in the iterator if provided
by a map / each / iota and other support functions.
Ie I want to write this code shorter :)
import std.stdio;
void main() {
const x = 12, y = 65, z = 50, s = 1435;
foreach (i; 0 .. x + 1)
foreach (j; 0 .. x + 1)
foreach (k; 0 .. x + 1)
if (i * (y + 3 * z) + j * (y + 2 * z) + k * (y
+ z) == s) {
writeln(i + j + k);
writeln(i * 3 + j * 2 + k);
writeln(i * 3 + j * 2 + k);
writeln(i, j, k);
}
}
-
http://rextester.com/SJTU87854
Hint: Use `cartesianProduct` [1] with three iota ranges to
replace the foreachs, and `filter` to replace the if
[1]
http://dlang.org/phobos/std_algorithm_setops.html#.cartesianProduct
Re: Expanding asm.dlang.org
On Monday, 25 May 2015 at 15:03:06 UTC, Iain Buclaw wrote: On 25 May 2015 16:55, Mike via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 25 May 2015 at 14:41:51 UTC, Mike wrote: I can add any cross compilers hosted on gdcproject.org. What do you need from me? Or did you mean any compiler from the finite list here: http://forum.dlang.org/post/satkcwpjqogloqlrj...@forum.dlang.org? The finite list here: http://gdcproject.org/downloads Currently only arm eabi and hard float. Ok, then what is needed from me to get my cross-compiler on that list?
Re: Replacing nested loops foreach using map/each/etc
On Monday, 25 May 2015 at 16:41:35 UTC, Meta wrote:
import std.algorithm;
import std.range;
import std.stdio;
void main()
{
const x = 12, y = 65, z = 50, s = 1435;
auto a = iota(0, x + 1);
cartesianProduct(a, a, a)
.filter!(i = i[0] * (y + 3 * z)
+ i[1] * (y + 2 * z)
+ i[2] * (y + z)
== s)
.each!((idx)
{
writeln(idx[0] + idx[1] + idx[2]);
writeln(idx[0] * 3 + idx[1] * 2 + idx[2]);
writeln(idx[0] * 3 + idx[1] * 2 + idx[2]);
writeln(idx[0], idx[1], idx[2]);
});
}
Thanks. I do not even know what `each` support braces.
Re: Evaluation order of index expressions
Am Mon, 25 May 2015 09:40:34 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 5/24/15 11:13 PM, Iain Buclaw via Digitalmars-d wrote:
The context here involves concurrency where bar() calls yield and
makes changes to foo before returning to assign the updated results.
We're not addressing that. += is not supposed to do concurrency
magic. -- Andrei
It's not += doing the magic, it's bar(). And it's not limited to
concurrency, it happens with every side effect:
import std.stdio;
void main()
{
int a = 0;
int bar()
{
a++;
return a;
}
a += bar(); // = a = a + bar()
writeln(a);
}
DMD: 2
GDC: 1
which one is correct?
Re: Expanding asm.dlang.org
On 25 May 2015 16:55, Mike via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 25 May 2015 at 14:41:51 UTC, Mike wrote: I can add any cross compilers hosted on gdcproject.org. What do you need from me? Or did you mean any compiler from the finite list here: http://forum.dlang.org/post/satkcwpjqogloqlrj...@forum.dlang.org? The finite list here: http://gdcproject.org/downloads Currently only arm eabi and hard float.
Re: Expanding asm.dlang.org
On 5/25/15 7:36 AM, Iain Buclaw via Digitalmars-d wrote: I can add any cross compilers hosted on gdcproject.org http://gdcproject.org. You'd need to go through Godbolt to get it on his host. asm.dlang.org http://asm.dlang.org is a no go because it has been tailored for dmd only. The right answer is to tailor asm.dlang.org for everything. -- Andrei
Re: How to append range to array?
On Saturday, 23 May 2015 at 07:03:35 UTC, Vladimir Panteleev
wrote:
int[] arr = [1, 2, 3];
auto r = iota(4, 10);
// ???
assert(equal(arr, iota(1, 10)));
Hopefully in one GC allocation (assuming we know the range's
length).
I tried std.range.primitives.put but its behavior seems a
little mysterious:
This compiles but asserts at runtime:
int[] arr = [1, 2, 3];
arr.put(iota(4, 10));
And this is even weirder, can you guess what it will print?
int[] arr = [1, 2, 3];
arr.put(4);
writeln(arr);
int[] arr = [1,2,3];
auto r = iota(4, 10);
auto app = arr.refAppender;
app.put(r);
assert(equal(arr, iota(1, 10)));
which of course you wrap with something like
auto append(T, R)(ref T arr, R r)
if(is(T : Q[], Q) isInputRange!r);
{
auto app = arr.refAppender;
app.put(r);
return arr;
}
to get
int[] arr = [1,2,3];
auto r = iota(4, 10);
arr.append(r);
assert(equal(arr, iota(1, 10)));
Walter has mentioned that he was interested in adding more
range-awareness to the language, so who knows, maybe this sort of
thing will get sugar at some point.
Re: Replacing nested loops foreach using map/each/etc
On Monday, 25 May 2015 at 17:05:35 UTC, Dennis Ritchie wrote:
On Monday, 25 May 2015 at 16:41:35 UTC, Meta wrote:
import std.algorithm;
import std.range;
import std.stdio;
void main()
{
const x = 12, y = 65, z = 50, s = 1435;
auto a = iota(0, x + 1);
cartesianProduct(a, a, a)
.filter!(i = i[0] * (y + 3 * z)
+ i[1] * (y + 2 * z)
+ i[2] * (y + z)
== s)
.each!((idx)
{
writeln(idx[0] + idx[1] + idx[2]);
writeln(idx[0] * 3 + idx[1] * 2 + idx[2]);
writeln(idx[0] * 3 + idx[1] * 2 + idx[2]);
writeln(idx[0], idx[1], idx[2]);
});
}
Thanks. I do not even know what `each` support braces.
`each` doesn't support braces. There are 4 ways to write a
function/delegate literal in D (with a few minor variations):
Short form:
function(int i) = i;
(int i) = i
(i) = i
i = i
Long form:
function(int i) { return i; }
(int i) { return i; }
(i) { return i; }
{ return 0; }
http://dlang.org/expression.html#FunctionLiteral
function
Re: Evaluation order of index expressions
On Monday, 25 May 2015 at 17:21:05 UTC, Johannes Pfau wrote:
import std.stdio;
void main()
{
int a = 0;
int bar()
{
a++;
return a;
}
a += bar(); // = a = a + bar()
writeln(a);
}
DMD: 2
GDC: 1
which one is correct?
So what about my previous example?
int b = 0;
((++b *= 5) *= 2) += ++b * (b -= 6);
DMD 2.067.1: 60, latest LDC: 65, GDC: ?
This divergence probably doesn't have anything to do with the
evaluation order, which seems to be identical (LTR), but rather
how the lhs expression is treated (a double-nature as nested
lvalue to be assigned to and rvalue result of a binAssign
expression). For more context, see
https://github.com/ldc-developers/ldc/pull/873.
Re: Replacing nested loops foreach using map/each/etc
On Monday, 25 May 2015 at 19:16:04 UTC, anonymous wrote:
On Monday, 25 May 2015 at 17:52:09 UTC, Dennis Ritchie wrote:
But why is the solution breaks down when `s = 1` ? :)
import std.stdio, std.algorithm, std.range;
int c;
const x = 12, y = 65, z = 50, s = 10;
Which is it, now? 4 or 5 zeros?
No difference!
void solve(Range)(Range r) {
cartesianProduct(r, r, r).filter!(i = i[0] * (y + 3 * z) +
i[1] * (y + 2 * z) + i[2] * (y + z) == s).each!dout;
}
void main() {
auto a = iota(0, x + 1).array;
solve(a);
writefln(`%s total`, c);
}
void dout(Tuple)(Tuple idx) {
++c;
}
-
http://rextester.com/XGDL26042
What do you mean it breaks down? Your original code doesn't
print anything for s = 10_000 or s = 100_000, either.
Excuse me, this is my blemish! I forgot that the constant `x`
depends on `s`. Everything works correctly:
import std.stdio, std.algorithm, std.range;
void solve(Range)(Range r) {
cartesianProduct(r, r, r).filter!(i = i[0] * (y + 3 * z) +
i[1] * (y + 2 * z) + i[2] * (y + z) == s).each!dout;
}
const y = 65, z = 50, s = 10;
const x = s / (y + z);
void main() {
auto a = iota(0, x + 1);
solve(a);
}
auto dout(Tuple)(Tuple idx) {
writefln(`%s apples`, idx[0] + idx[1] + idx[2]);
writefln(`%s gingerbread`, idx[0] * 3 + idx[1] * 2 + idx[2]);
writefln(`%s pharynx tea`, idx[0] * 3 + idx[1] * 2 + idx[2]);
writefln(Sour: %s; semi-acid: %s; sweet: %s.\n, idx[0],
idx[1], idx[2]);
}
-
http://rextester.com/MMCI9993
Re: [dconf] Share a ride SLC-hotel?
On 5/25/15 12:39 PM, Andrei Alexandrescu wrote: I'm arriving in SLC on Tue at 11:39 pm. Anyone up for sharing a ride? I'm thinking http://www.expressshuttleutah.com/. -- Andrei Just make sure you call, because they told me after hours (which I think was after midnight) requires an additional fee. I am arriving at 10 pm today, so no issue for me, but you are close. -Steve
Re: [dconf] Share a ride SLC-hotel?
On 5/25/2015 9:39 AM, Andrei Alexandrescu wrote: I'm arriving in SLC on Tue at 11:39 pm. Anyone up for sharing a ride? I'm thinking http://www.expressshuttleutah.com/. -- Andrei Chuck says the shuttle is $38 one way and $68 round trip.
Re: Evaluation order of index expressions
Andrei Alexandrescu wrote in message news:mjvlv5$vch$1...@digitalmars.com... which one is correct? GDC. -- Andrei I don't think it matters too much if we pick strict LTR, or keep dmd's existing exception for assign expressions. IIRC Walter is in favour of keeping the exception[1]. Could you and Walter please come to an agreement and confirm here? It should be fairly straightforward to get this fixed once it's clear which way it should go. [1] https://github.com/D-Programming-Language/dmd/pull/4035#issuecomment-58861231
Re: Evaluation order of index expressions
On 25 May 2015 21:00, Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote: Andrei Alexandrescu wrote in message news:mjvlv5$vch$1...@digitalmars.com. .. which one is correct? GDC. -- Andrei I don't think it matters too much if we pick strict LTR, or keep dmd's existing exception for assign expressions. IIRC Walter is in favour of keeping the exception[1]. Could you and Walter please come to an agreement and confirm here? It should be fairly straightforward to get this fixed once it's clear which way it should go. [1] https://github.com/D-Programming-Language/dmd/pull/4035#issuecomment-58861231 Yeah, but his reasoning only applies to x86. This makes it void in my books.
Re: Evaluation order of index expressions
On 25 May 2015 at 21:02, kinke via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 25 May 2015 at 17:21:05 UTC, Johannes Pfau wrote:
import std.stdio;
void main()
{
int a = 0;
int bar()
{
a++;
return a;
}
a += bar(); // = a = a + bar()
writeln(a);
}
DMD: 2
GDC: 1
which one is correct?
So what about my previous example?
int b = 0;
((++b *= 5) *= 2) += ++b * (b -= 6);
DMD 2.067.1: 60, latest LDC: 65, GDC: ?
If the litmus test is What does GDC do?, then LDC is doing it the correct
way. :-)
Re: std.multidimarray
On Monday, 25 May 2015 at 18:33:57 UTC, Dennis Ritchie wrote:
Yes, that's what I mean. Some common questions about working
with multidimensional arrays need to be addressed. For example,
the cycle `foreach` multiple iterators, etc.
Cycle was tough. I was using T[2] to track slice boundaries but
had to retrofit the library with an Interval!(L,R) type to admit
the possibility of unbounded dimensions. This has resulted in a
fairly easy implementation for cycle, though.
https://github.com/evenex/autodata/blob/master/source/spaces/cyclic.d
Foreach is something I am still considering. It is
straightforward to define a range adaptor that traverses a
multidimensional array lexicographically, but another interesting
possibility is to define traversable multidim arrays recursively,
eg:
2d array = {1d row, 2d remainder}
This is cool, as it may enable us to write generic traversals for
n-dim arrays and trees alike... However I have been struggling to
find a way to make such a thing work with foreach cleanly.
Re: Replacing nested loops foreach using map/each/etc
On Monday, 25 May 2015 at 17:52:09 UTC, Dennis Ritchie wrote:
But why is the solution breaks down when `s = 1` ? :)
import std.stdio, std.algorithm, std.range;
int c;
const x = 12, y = 65, z = 50, s = 10;
Which is it, now? 4 or 5 zeros?
void solve(Range)(Range r) {
cartesianProduct(r, r, r).filter!(i = i[0] * (y + 3 * z) +
i[1] * (y + 2 * z) + i[2] * (y + z) == s).each!dout;
}
void main() {
auto a = iota(0, x + 1).array;
solve(a);
writefln(`%s total`, c);
}
void dout(Tuple)(Tuple idx) {
++c;
}
-
http://rextester.com/XGDL26042
What do you mean it breaks down? Your original code doesn't
print anything for s = 10_000 or s = 100_000, either.
Re: Evaluation order of index expressions
On 05/25/2015 09:14 PM, Iain Buclaw via Digitalmars-d wrote: So what about my previous example? int b = 0; ((++b *= 5) *= 2) += ++b * (b -= 6); DMD 2.067.1: 60, latest LDC: 65, GDC: ? If the litmus test is What does GDC do?, then LDC is doing it the correct way. :-) Even if it isn't. ;)
Re: Evaluation order of index expressions
On 5/25/15 10:21 AM, Johannes Pfau wrote:
Am Mon, 25 May 2015 09:40:34 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 5/24/15 11:13 PM, Iain Buclaw via Digitalmars-d wrote:
The context here involves concurrency where bar() calls yield and
makes changes to foo before returning to assign the updated results.
We're not addressing that. += is not supposed to do concurrency
magic. -- Andrei
It's not += doing the magic, it's bar(). And it's not limited to
concurrency, it happens with every side effect:
import std.stdio;
void main()
{
int a = 0;
int bar()
{
a++;
return a;
}
a += bar(); // = a = a + bar()
writeln(a);
}
DMD: 2
GDC: 1
which one is correct?
GDC. -- Andrei
Re: shared libs for OSX
On 2015-05-25 16:33, bitwise wrote: I've been reading through the Mach-O docs[1], and it seems that dynamic libs are treated the same as static libs in that exported symbols can only be defined once, even across dynamically loaded libraries. This is why calling rt_init from my dylib ended up calling the one that was already defined in the application image. I was able to call the rt_init from the dylib by specifically requesting it through dlsym, but then, all the global variables it used(_isRuntimeInitialized, etc) still ended up resolving to the ones in the application image. At this point, my impression is that it would be very impractical, if not impossible to have separate druntimes for each shared library. Even when you do link separate runtimes, dyld still treats all the exported symbols as shared. @Martin So correct me if I'm wrong, but it seems the _only_ choice is a shared druntime for osx. Could you elaborate a bit on how you've managed to do this for linux? If I recall correctly, this is how it works: On Linux the compiler will generate a function which is placed in a special section in the binary, same as annotating a C function with __attribute__((constructor)). This function calls a function in the druntime. This will give similar properties as _dyld_register_func_for_add_image on OS X but without the issues with registered callbacks Each image then becomes responsible to initialize itself. The image updates the shared data structure containing the necessary data (TLS, exception handling tables, ...). As you noticed yourself, all global symbols are shared across all images. -- /Jacob Carlborg
Re: Evaluation order of index expressions
On 05/25/2015 09:14 PM, Iain Buclaw via Digitalmars-d wrote: If the litmus test is What does GDC do?, then LDC is doing it the correct way. :-) Perfect. :) On Monday, 25 May 2015 at 19:17:48 UTC, Timon Gehr wrote: Even if it isn't. ;) It is - on its merge-2.067 branch. ;)
Re: Evaluation order of index expressions
On 25 May 2015 21:35, Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote: On 05/25/2015 09:28 PM, kinke wrote: On 05/25/2015 09:14 PM, Iain Buclaw via Digitalmars-d wrote: If the litmus test is What does GDC do?, then LDC is doing it the correct way. :-) Perfect. :) On Monday, 25 May 2015 at 19:17:48 UTC, Timon Gehr wrote: Even if it isn't. ;) It is - on its merge-2.067 branch. ;) LDC is doing it the correct way even if What does GDC do? is not the litmus test. I am not a fan of this dictatorship. I vote for democracy, if two compilers do 'X', then the odd one out is wrong. ;-)
Re: Evaluation order of index expressions
Timon Gehr wrote in message news:mjvtqm$17d8$1...@digitalmars.com... A related issue is that the rewrites documented at http://dlang.org/operatoroverloading.html don't all preserve the order of subexpressions. However, ideally, the order of evaluation would be preserved. As operator overloading is defined in terms of lowering to function calls, I think it's reasonable to decide the order of evaluation after the lowering. This will still be consistent across compilers and platforms. Preserving the original order would require added complexity that I don't think is warranted.
Re: Replacing nested loops foreach using map/each/etc
On Monday, 25 May 2015 at 17:19:27 UTC, Meta wrote:
`each` doesn't support braces. There are 4 ways to write a
function/delegate literal in D (with a few minor variations):
Short form:
function(int i) = i;
(int i) = i
(i) = i
i = i
Long form:
function(int i) { return i; }
(int i) { return i; }
(i) { return i; }
{ return 0; }
http://dlang.org/expression.html#FunctionLiteral
function
Thanks.
But why is the solution breaks down when `s = 1` ? :)
import std.stdio, std.algorithm, std.range;
int c;
const x = 12, y = 65, z = 50, s = 10;
void solve(Range)(Range r) {
cartesianProduct(r, r, r).filter!(i = i[0] * (y + 3 * z) + i[1]
* (y + 2 * z) + i[2] * (y + z) == s).each!dout;
}
void main() {
auto a = iota(0, x + 1).array;
solve(a);
writefln(`%s total`, c);
}
void dout(Tuple)(Tuple idx) {
++c;
}
-
http://rextester.com/XGDL26042
Re: std.multidimarray
On Monday, 25 May 2015 at 18:11:32 UTC, Vlad Levenfeld wrote: The matrix implementation is really just a placeholder, when I have more time I would like to fill it out with compile-time swappable backend implementations using the same matrix frontend (eg forwarding arithmetic operations to gsl routines). So yes, the matrix example is very raw (I assume by damp you meant siroi). The other structures are much more fleshed out and provide much better examples of what I'm going for (ie any of the reimplemented Phobos adaptors: cycle, stride, etc). Yes crude meaning raw. The library itself is meant to generate consistent, safe interfaces for all manner of multidimensional structures (or, at least those that resemble cartesian products of half open intervals). I can drop in a naive backend later this week as a concrete demonstration. Its unlikely, even in complete form, that this would be suitable for inclusion in Phobos (it adds a lot of nonstandard idioms), but many of the design issues surrounding multidimensional structures with not-necessarily-integral indices have been carefully addressed; their solutions may prove useful in the effort to build a standard library package. Yes, that's what I mean. Some common questions about working with multidimensional arrays need to be addressed. For example, the cycle `foreach` multiple iterators, etc.
[Issue 14617] PTHREAD_MUTEX_INITIALIZER does not work on OSX
https://issues.dlang.org/show_bug.cgi?id=14617 --- Comment #9 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/ab78a534dc017efecbe86f79f5d4559b85ef8619 fix issue 14617 - Define correct values for PTHREAD_MUTEX_INITIALIZER and PTHREAD_ONCE_INIT. https://github.com/D-Programming-Language/druntime/commit/19f3f0db648b6361248e2c53e00fcb3794c2521b Merge pull request #1285 from schveiguy/pthreadmutexosx Fix issue 14617 - PTHREAD_MUTEX_INITIALIZER does not work on OSX --
Re: Evaluation order of index expressions
On 05/25/2015 09:28 PM, kinke wrote: On 05/25/2015 09:14 PM, Iain Buclaw via Digitalmars-d wrote: If the litmus test is What does GDC do?, then LDC is doing it the correct way. :-) Perfect. :) On Monday, 25 May 2015 at 19:17:48 UTC, Timon Gehr wrote: Even if it isn't. ;) It is - on its merge-2.067 branch. ;) LDC is doing it the correct way even if What does GDC do? is not the litmus test.
Re: Evaluation order of index expressions
Timon Gehr wrote in message news:mjvvq2$19hd$1...@digitalmars.com... As operator overloading is defined in terms of lowering to function calls, I think it's reasonable to decide the order of evaluation after the lowering. This will still be consistent across compilers and platforms. But almost entirely arbitrary. Yes. I don't think this is particularly important, as depending on evaluation order is highly discouraged. Preserving the original order would require added complexity that I don't think is warranted. The compiler would just need to introduce some temporary variables for the two lowerings. Why wouldn't this be warranted to make overloaded operators consistent with built-in ones? If anything, I think it is desirable to have opBinary(B) on type A and opBinaryRight(A) on type B interchangeable. What complexity are you worried about? Introducing temporary variables is added complexity. It affects all sorts of other parts of the compiler.
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Sobirari Muhomori from comment #15) BTW, Windows 8 has GetSystemTimePreciseAsFileTime function for time reading with better precision. If there's a way to utilize this and still be binary compatible with Win XP, that might be possible. But we can't require Windows 8 for D. And actually, this has been pulled, so I think we can close this. --
Re: deserialization: creating a class instance without calling constructor
On Thursday, 21 May 2015 at 19:06:35 UTC, Jacob Carlborg wrote:
On 2015-05-21 11:06, Timothee Cour via Digitalmars-d-learn
wrote:
Can I create an instance of A without calling a constructor?
(see below)
Use case: for generic deserialiaztion, when the
deserialization library
encounters a class without default constructor for example (it
knows
what the fields should be set to, but doesn't know how to
construct the
object).
class A{
int x=2;
this(int x){
this.x=x;
}
}
This came up here:
https://github.com/msgpack/msgpack-d/issues/54#issuecomment-104136148
I provide some hacky solution for that in that thread but I
suspect it's
not safe and something is missing.
Here's how I do it in my serialization library Orange [1]
[1]
https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L166
Thanks!
Re: shared libs for OSX
On Monday, 25 May 2015 at 14:33:43 UTC, bitwise wrote: At this point, my impression is that it would be very impractical, if not impossible to have separate druntimes for each shared library. Even when you do link separate runtimes, dyld still treats all the exported symbols as shared. Yes, you can't mix them with a D executable.
Re: std.multidimarray
On Monday, 25 May 2015 at 19:14:05 UTC, Vlad Levenfeld wrote:
Cycle was tough. I was using T[2] to track slice boundaries but
had to retrofit the library with an Interval!(L,R) type to
admit the possibility of unbounded dimensions. This has
resulted in a fairly easy implementation for cycle, though.
https://github.com/evenex/autodata/blob/master/source/spaces/cyclic.d
Yes, it would be great to learn how to create recursive iterators
for each subarray.
Foreach is something I am still considering. It is
straightforward to define a range adaptor that traverses a
multidimensional array lexicographically, but another
interesting possibility is to define traversable multidim
arrays recursively, eg:
2d array = {1d row, 2d remainder}
This is cool, as it may enable us to write generic traversals
for n-dim arrays and trees alike... However I have been
struggling to find a way to make such a thing work with foreach
cleanly.
That recursive n-dimensional array, but I think that recursion
will not be effective.
http://forum.dlang.org/thread/ulhtlyxxclihaseef...@forum.dlang.org#post-mihl6m:241che:241:40digitalmars.com
Re: std.multidimarray
On Monday, 25 May 2015 at 19:14:05 UTC, Vlad Levenfeld wrote: https://github.com/evenex/autodata/blob/master/source/spaces/cyclic.d And I think that the symbol `ℕ` in your code you need to replace some words.
[Issue 7454] Add file and line numbers to Linux stack traces using addr2line
https://issues.dlang.org/show_bug.cgi?id=7454 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #3 from Martin Nowak c...@dawg.eu --- See also issue 11870. We should implement support for decoding DWARF info in druntime itself. --
Re: shared libs for OSX
On Monday, 25 May 2015 at 19:40:52 UTC, bitwise wrote: 1) _dyld_register_func_for_add_image should be taken care of with the above two fixes You still cannot unregister the callback, so it can't be used for dynamically loading druntime. Last time we talked about this problem, we found some undocumented function that could be deregistered. 2) __attribute__((constructor/destructor)) can be added to druntime when building for osx like in the file dylib_fixes.c [1] For linux we let the compiler emit comdat constructors into every D object, so you'll end up with exactly a single function for any binary containing D code. I don't think you need ctors/dtors on OSX if you already have the dylib callback. 3) copy paste rt_init/rt_term, rename them to dylib_init/dylib_term and remove everything except whats needed to initialize a shared lib's image. Not sure what you want to copy, but for sure you need to extend sections_osx to handle multiple dylibs. It should be very similar to _d_dso_registry for ELF, except that you iterate over the sections of a dylib image to get EH tables and ModuleInfo.
Re: indie game contests
@Manu - if by that you mean do game jams without you - that horse has already bolted the stable :p I would be happy to a try the October Game Jam again this year and I thoroughly recommend the global (much more laid back). extrawurst - danni@gmail.com On Mon, May 25, 2015 at 8:06 PM, Manu via Digitalmars-d digitalmars-d@puremagic.com wrote: Awww Danni, you've forsaken me! :P On 25 May 2015 at 03:47, Vlad Levenfeld via Digitalmars-d digitalmars-d@puremagic.com wrote: On Saturday, 23 May 2015 at 05:17:13 UTC, Danni Coy wrote: Got very close to a year or so ago. Probably something I would be much more capable of doing now. The only downside is that I enjoy doing asset creation more. That's perfect, actually. Shoot me an email, we can all assemble a D team and make something awesome.
Re: Evaluation order of index expressions
On 05/25/2015 07:21 PM, Johannes Pfau wrote:
Am Mon, 25 May 2015 09:40:34 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 5/24/15 11:13 PM, Iain Buclaw via Digitalmars-d wrote:
The context here involves concurrency where bar() calls yield and
makes changes to foo before returning to assign the updated results.
We're not addressing that. += is not supposed to do concurrency
magic. -- Andrei
It's not += doing the magic, it's bar(). And it's not limited to
concurrency, it happens with every side effect:
import std.stdio;
void main()
{
int a = 0;
int bar()
{
a++;
return a;
}
a += bar(); // = a = a + bar()
writeln(a);
}
DMD: 2
GDC: 1
which one is correct?
With left-to-right evaluation, 1 is correct. Java and C# also give 1.
Re: std.multidimarray
On Sunday, 24 May 2015 at 22:42:12 UTC, Dennis Ritchie wrote: On Sunday, 24 May 2015 at 20:45:56 UTC, Laeeth Isharc wrote: You might take a look at Vlad Levenfeld's work too, although I think he would say that it is still at an early stage (if I understand correctly - looks very interesting to me, although I have not yet properly had time to explore it in depth) https://github.com/evenex/autodata Yes, at the moment it looks all pretty damp, but very interesting. For example, this really is not enough: https://github.com/evenex/autodata/blob/master/source/spaces/matrix.d#L53-L68 The fact that no library will not arrange me. I need the tools to work with multidimensional arrays, which will necessarily be built into Phobos! The matrix implementation is really just a placeholder, when I have more time I would like to fill it out with compile-time swappable backend implementations using the same matrix frontend (eg forwarding arithmetic operations to gsl routines). So yes, the matrix example is very raw (I assume by damp you meant siroi). The other structures are much more fleshed out and provide much better examples of what I'm going for (ie any of the reimplemented Phobos adaptors: cycle, stride, etc). The library itself is meant to generate consistent, safe interfaces for all manner of multidimensional structures (or, at least those that resemble cartesian products of half open intervals). I can drop in a naive backend later this week as a concrete demonstration. Its unlikely, even in complete form, that this would be suitable for inclusion in Phobos (it adds a lot of nonstandard idioms), but many of the design issues surrounding multidimensional structures with not-necessarily-integral indices have been carefully addressed; their solutions may prove useful in the effort to build a standard library package.
Re: shared libs for OSX
On Mon, 25 May 2015 14:39:37 -0400, Jacob Carlborg d...@me.com wrote: On 2015-05-25 16:33, bitwise wrote: I've been reading through the Mach-O docs[1], and it seems that dynamic libs are treated the same as static libs in that exported symbols can only be defined once, even across dynamically loaded libraries. This is why calling rt_init from my dylib ended up calling the one that was already defined in the application image. I was able to call the rt_init from the dylib by specifically requesting it through dlsym, but then, all the global variables it used(_isRuntimeInitialized, etc) still ended up resolving to the ones in the application image. At this point, my impression is that it would be very impractical, if not impossible to have separate druntimes for each shared library. Even when you do link separate runtimes, dyld still treats all the exported symbols as shared. @Martin So correct me if I'm wrong, but it seems the _only_ choice is a shared druntime for osx. Could you elaborate a bit on how you've managed to do this for linux? If I recall correctly, this is how it works: On Linux the compiler will generate a function which is placed in a special section in the binary, same as annotating a C function with __attribute__((constructor)). This function calls a function in the druntime. This will give similar properties as _dyld_register_func_for_add_image on OS X but without the issues with registered callbacks Each image then becomes responsible to initialize itself. The image updates the shared data structure containing the necessary data (TLS, exception handling tables, ...). As you noticed yourself, all global symbols are shared across all images. So then I think I have a full solution: 1) _dyld_register_func_for_add_image should be taken care of with the above two fixes 2) __attribute__((constructor/destructor)) can be added to druntime when building for osx like in the file dylib_fixes.c [1] 3) copy paste rt_init/rt_term, rename them to dylib_init/dylib_term and remove everything except whats needed to initialize a shared lib's image. Does this make sense? Thanks, Bit [1] https://github.com/D-Programming-Language/druntime/blob/61ba4b8d3c0052065c17ffc8eef4f11496f3db3e/src/rt/dylib_fixes.c
Re: Evaluation order of index expressions
On 05/24/2015 09:30 PM, kinke wrote:
code
import core.stdc.stdio;
static int[] _array = [ 0, 1, 2, 3 ];
int[] array() @property { printf(array()\n); return _array; }
int start() @property { printf(start()\n); return 0; }
int end() @property { printf(end()\n); return 1; }
void main()
{
array[start..end] = 666;
printf(---\n);
array[start] = end;
}
/code
stdout
array()
start()
end()
---
start()
array()
end()
/stdout
So for the 2nd assignment's left-hand-side, the index is evaluated
before evaluating the container! Please don't tell me that's by design. :
[origin: https://github.com/D-Programming-Language/phobos/pull/3311]
A related issue is that the rewrites documented at
http://dlang.org/operatoroverloading.html don't all preserve the order
of subexpressions. However, ideally, the order of evaluation would be
preserved.
Re: D for Android
On Monday, 18 May 2015 at 15:47:07 UTC, Joakim wrote: Sure, have fun with your new devices. :) Hopefully, I'll get Android/ARM working before then, but I don't and won't have any AArch64 devices to test. Not that it matters, as 64-bit ARM has even less share than x86 right now. Earlier this week, I stumbled across a way to get TLS working with ldc for Android/ARM, similar to the approach used for Android/x86 so far. Exception-handling on ARM for ldc is currently unfinished (https://github.com/ldc-developers/ldc/issues/489), so if I disable a handful of tests related to that, I get 36 of 42 druntime modules' unit tests and around 31 of 70 phobos modules' unit tests to pass. All tests were run from the command line on my Android tablet. It appears there are issues related to unicode and the GC causing many of the remaining failures.
Re: Evaluation order of index expressions
On 05/25/2015 10:02 PM, Daniel Murphy wrote: Timon Gehr wrote in message news:mjvtqm$17d8$1...@digitalmars.com... A related issue is that the rewrites documented at http://dlang.org/operatoroverloading.html don't all preserve the order of subexpressions. However, ideally, the order of evaluation would be preserved. As operator overloading is defined in terms of lowering to function calls, I think it's reasonable to decide the order of evaluation after the lowering. This will still be consistent across compilers and platforms. But almost entirely arbitrary. Preserving the original order would require added complexity that I don't think is warranted. The compiler would just need to introduce some temporary variables for the two lowerings. Why wouldn't this be warranted to make overloaded operators consistent with built-in ones? If anything, I think it is desirable to have opBinary(B) on type A and opBinaryRight(A) on type B interchangeable. What complexity are you worried about?
Re: Evaluation order of index expressions
On 5/25/15 11:58 AM, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:mjvlv5$vch$1...@digitalmars.com... which one is correct? GDC. -- Andrei I don't think it matters too much if we pick strict LTR, or keep dmd's existing exception for assign expressions. IIRC Walter is in favour of keeping the exception[1]. Could you and Walter please come to an agreement and confirm here? It should be fairly straightforward to get this fixed once it's clear which way it should go. [1] https://github.com/D-Programming-Language/dmd/pull/4035#issuecomment-58861231 I'm fine with RTL for assignment expressions, and LTR everywhere else. Daniel, if you could work this out at front end level so it goes the same way for all backends, that would be fantastic. -- Andrei
Re: Evaluation order of index expressions
On 05/26/2015 01:45 AM, Andrei Alexandrescu wrote: On 5/25/15 11:58 AM, Daniel Murphy wrote: Andrei Alexandrescu wrote in message news:mjvlv5$vch$1...@digitalmars.com... which one is correct? GDC. -- Andrei I don't think it matters too much if we pick strict LTR, or keep dmd's existing exception for assign expressions. IIRC Walter is in favour of keeping the exception[1]. Could you and Walter please come to an agreement and confirm here? It should be fairly straightforward to get this fixed once it's clear which way it should go. [1] https://github.com/D-Programming-Language/dmd/pull/4035#issuecomment-58861231 I'm fine with RTL for assignment expressions, and LTR everywhere else. Daniel, if you could work this out at front end level so it goes the same way for all backends, that would be fantastic. -- Andrei Why? Strictly left-to-right is the simplest thing.
Re: Status of Deimos bindings
On Monday, 25 May 2015 at 21:43:18 UTC, rsw0x wrote: On Monday, 25 May 2015 at 21:33:15 UTC, FreeSlave wrote: What's the current status of Deimos? I don't think that this kind of bindings is useless, since not everyone always wants dynamic bindings. E.g. for the sake of simplicity or static linking. Actually Walter even fixes issues in these bindings time by time, so I guess the idea is still alive. But I see some problems now: 1. Some of Deimos bindings are not made into the dub packages. Also not all of those which have dub.json (or package.json) are presented in dub registry. 2. No consistency on names. There're repos named with lib prefix and without it either. 3. I could not find information on how to propose new binding to Deimos. Currently we have some bindings in dub registry which are not in D-Programming-Deimos. Would be better to keep these things in the same place. One can filter dub registry by choosing the Development library - D language bindings - Deimos header-only binding, but some bindings (for example, flac) are not assigned to this section, so you will not see them. Thoughts? I like how nim approaches this by making important C bindings such as SDL, Lua, etc first class members of the language. I believe that they ship directly with the nim implementation as ported headers barely take up any space. These are libraries that pretty much any language is expected to support. Bye. +1 Anything without much cost one can do to make it easy for people to get started with D will pay off, because small frictions in life cumulatively have large consequences. (Not cost-free given maintenance and desire to sync them with dmd releases, but if the bindings are clearly identified as not part of core D then it's better to make it easy than force people to hunt them down).
Re: Evaluation order of index expressions
On 05/25/2015 10:30 PM, Daniel Murphy wrote: Timon Gehr wrote in message news:mjvvq2$19hd$1...@digitalmars.com... As operator overloading is defined in terms of lowering to function calls, I think it's reasonable to decide the order of evaluation after the lowering. This will still be consistent across compilers and platforms. But almost entirely arbitrary. Yes. I don't think this is particularly important, Those small ugly corners of the language do add up, and they do cause real problems. For issues like this one, which are not considered important enough, I think it is fine to fix the spec and let the compiler catch up later (with a warning in the spec). I'm not saying this is urgent, just that it is obvious how it ought to be. as depending on evaluation order is highly discouraged. ... Doesn't mean it won't happen. Having different evaluation order for expressions that look identical is just asking for really funny problems in generic code, of the sort that will summon more threads like this one. Preserving the original order would require added complexity that I don't think is warranted. The compiler would just need to introduce some temporary variables for the two lowerings. Why wouldn't this be warranted to make overloaded operators consistent with built-in ones? If anything, I think it is desirable to have opBinary(B) on type A and opBinaryRight(A) on type B interchangeable. What complexity are you worried about? Introducing temporary variables is added complexity. It affects all sorts of other parts of the compiler. This ought to be a matter of changing a few lines in one place. Took me a couple of minutes to implement for opBinaryRight: -r=New!CallExp(opoverloadR,[e1]); -r.loc=loc; +auto tmpe=New!TmpVarExp(e1); +tmpe.loc=loc; +tmpe.semantic(sc); +version(assert) assert(!!tmpe.sym); +auto c=New!CallExp(opoverloadR,[tmpe.sym]); +r=New!(BinaryExp!(Tok!,))(tmpe,c); +r.loc=c.loc=loc; What makes this different for DMD?
Re: DIP66 1.2 (Multiple) alias this. Continuation of work.
On Tuesday, 31 March 2015 at 20:01:14 UTC, Andrei Alexandrescu
wrote:
On 3/31/15 7:28 AM, IgorStepanov wrote:
On Monday, 30 March 2015 at 18:33:17 UTC, Andrei Alexandrescu
wrote:
On 3/30/15 8:04 AM, Steven Schveighoffer wrote:
On 3/29/15 1:34 PM, IgorStepanov wrote:
1. We should reject types which use opDispatch and alias
this at the
same time.
Why? Alias this has no filter. opDispatch can use template
constraints.
It makes perfect sense to prefer opDispatch, unless it
doesn't have a
valid match, and then use alias this instead.
For example, if I wanted to wrap a type so I can instrument
calls to
'foo', I could do something like this:
struct FooWrapper(T)
{
T t;
alias t this;
auto opDispatch(string s, A...)(A args) if(s == foo) {
writeln(calling foo); return t.foo(args); }
}
Why is this a bad use case?
The idea is to start restrictive and define interaction
meaningfully
later based on compelling use cases. -- Andrei
Andrei, do you approve those changes? Can we move to work on
my github PR?
I made a few editorial passes, no major changes. I think
there's still a fly in the ointment. The resolution algorithm
goes:
1. If xyz is a symbol (member, method, enum etc) defined inside
typeof(obj) then lookup is done.
2. Otherwise, if xyz is a symbol introduced in the base class
(where applicable), then lookup is done.
3. Otherwise, if opDispatch!xyz exists, then lookup is done.
4. Otherwise, alias this is attempted transitively, and if xyz
is found, then lookup is done.
5. Otherwise an UFCS rewrite is effected.
This puts opDispatch in between inheritance and subtyping,
which I think we discussed is inappropriate - alias this should
be effectively subtyping.
If we're really convinced alias this means multiple subtyping,
the inherited type should not have a special role. However, it
simplifies a lot of things to give one particular subtype a leg
up on all others. So I think this would work:
1. If xyz is a symbol (member, method, enum etc) defined inside
typeof(obj) then lookup is done.
2. Otherwise, if xyz is a symbol introduced in the base class
(where applicable), then lookup is done.
3. Otherwise, if xyz is found at least via either an
opDispatch!xyz or alias this conversion, then lookup is done.
4. Otherwise an UFCS rewrite is effected.
Then you explain that if you find more than one possibility via
opDispatch and alias this, that's an ambiguity error.
I noticed you do mention in the Limitations section that
opDispatch and alias this cannot be simultaneously present, but
that kind of contradicts your resolution algorithm.
Andrei
Ok, I've applied your changes to the DIP page, and I'm starting
to rework my github PR. Sorry for the slow work (I'm very busy
last time). However I still working. Stay on line=)
Re: std.multidimarray
On Monday, 25 May 2015 at 20:52:33 UTC, Dennis Ritchie wrote: On Monday, 25 May 2015 at 19:14:05 UTC, Vlad Levenfeld wrote: https://github.com/evenex/autodata/blob/master/source/spaces/cyclic.d And I think that the symbol `ℕ` in your code you need to replace some words. Ok, done.
