GtkD Binaries
Does anyone know where i could find the DLLs not included in the gtk+ runtime installer for GtkD, as I don't have the necessary environment to build the gtk+ runtime. I have already located a copy of "libgtksourceview-3.0-1.dll" (Found it on the pbone rpm archive). I still need to find "libvte-2.91.dll" and a bunch of others.
Re: D Github contributors - enable 2 factor authentification
Currently 11/35 have enabled 2FA
Re: Why D is not popular enough?
On Thursday, 11 August 2016 at 20:16:04 UTC, bachmeier wrote: On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote: the arrogance by which D was initially and repeatedly compared against C/C++ has been totally out of place since the C++ is a very good language and the effort made to denigrate it with specious and ridiculously false arguments about it vis-a-vis D as a programming language has almost irreparably hurt D as a serious programming language irrespective of its actual abilities or weaknesses. You are not going to appeal to the really intelligent programmers out there if you are not honest and rigorous in discussion of your own programming language in relation to others. All that you end up doing is to alienate anyone with real programming intelligence by the tactics that D has taken over the years with such comparisons. I never understood how people can get their feelings hurt when criticising the language they program in. Either the criticised point is true and one accepts it or not, in that case a factual refutation can be done. Feeling offended is ridiculous. 4) As a C++ programmer largely interested in C++ template programming, C++ concepts etc., and potential compile-time/run-time introspection, I have never found a compelling reason to use D rather than C++. This is a good example of why C++ programmers will never move to D. They are quite happy with the language. They want a better C++, and that's C++14, C++17, etc., not D. Yeah, it's also known as Stockholm Syndrome :-)
Re: Why D is not popular enough?
On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote: 4) As a C++ programmer largely interested in C++ template programming, C++ concepts etc., and potential compile-time/run-time introspection, I have never found a compelling reason to use D rather than C++. I do recognize that C++'s template syntax is difficult and abstruse but I do not and have never seen where D improves upon these matters in any serious and rigorous way. This may be because the documentation about these areas in D is either very light or almost completely lacking. Even in Mr. Alexandrescu's book the discussion of these areas was very light in my estimation. So whatever D has to offer in these areas, if there are really impovements, is either lacking in the D documentation or does not really exist for me. From the best of my knowledge you cannot do these things in in C++: https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through-CTFE https://p0nce.github.io/d-idioms/#Enumerate-fields-with-__traits(allMembers)-and-static-foreach https://p0nce.github.io/d-idioms/#Embed-a-dynamic-library-in-an-executable https://p0nce.github.io/d-idioms/#Recursive-Sum-Type-with-matching https://p0nce.github.io/d-idioms/#String-interpolation-as-a-library https://p0nce.github.io/d-idioms/#Using-std.typecons.Flag-like-a-pro https://p0nce.github.io/d-idioms/#Voldemort-types Another expose of what you can achieve with these feature is the "D Cookbook" book. - Chapter 6 Forwarding methods with opDispatch - Chapter 8 Getting a list of child classes - Chapter 8 Determining if a module is available - Chapter 8 Using user defined attributes - Chapter 9 Creating user-defined literals - Chapter 9 Generating data structure from text diagrams Finally what we label "DbI" is quite the game changer: https://p0nce.github.io/d-idioms/#Design-by-Introspection
Re: DIP1000: Scoped Pointers (Discussion)
On Thursday, 11 August 2016 at 22:00:06 UTC, Walter Bright wrote:
On 8/11/2016 4:46 AM, Robert burner Schadek wrote:
Can I do this:
```
struct Foo { int a; }
auto rcs = RefCountedSlice!Foo(); // assume rcs.length > 0
scope Foo zero = rcs[0];
zero.a = 1337;
assert(rcs[0].a == 1337);
```
No, because the lifetime of zero exceeds the lifetime of rcs[0].
Hm, that is really bad IMO. The shown use case is properly the
most common use case. Is there no way to make it transitive so
the lifetime of rcs[0] is the lifetime of rcs.
To be blunt, this is a real show-stopper for me.
Re: DIP1000: Scoped Pointers (Discussion)
On Friday, 12 August 2016 at 09:42:35 UTC, Robert burner Schadek
wrote:
On Thursday, 11 August 2016 at 22:00:06 UTC, Walter Bright
wrote:
On 8/11/2016 4:46 AM, Robert burner Schadek wrote:
Can I do this:
```
struct Foo { int a; }
auto rcs = RefCountedSlice!Foo(); // assume rcs.length > 0
scope Foo zero = rcs[0];
zero.a = 1337;
assert(rcs[0].a == 1337);
```
No, because the lifetime of zero exceeds the lifetime of
rcs[0].
Hm, that is really bad IMO. The shown use case is properly the
most common use case. Is there no way to make it transitive so
the lifetime of rcs[0] is the lifetime of rcs.
To be blunt, this is a real show-stopper for me.
No, the DIP doesn't handle several levels of indirection.
Re: DIP1000: Scoped Pointers (Discussion)
On Thursday, 11 August 2016 at 21:57:06 UTC, Walter Bright wrote: With conditionals, the scope of it is the narrowest scope of each of its leaves. (cond ? a : c) = &b; // not ok, accepted even though a outlives b I had overlooked the lvalue case, but you're right. The rules for it are inevitable. I raised that in November 2014 already. To be honest I'm to a point were I'm starting withdrawing from these conversation because I have no idea how to reach to you guys. I could write on toilet paper before using it to the same effect.
Re: DIP1000: Scoped Pointers (Discussion)
No, the DIP doesn't handle several levels of indirection.
What about:
struct Bar { int a; int b }
auto rcs = RefCountedTree!(string,Bar)();
fcs["bar"].a = 1337; // log n
fcs["bar"].b = 1338; // log n
? I need to pay log n twice to assign two members
Re: DIP1000: Scoped Pointers (Discussion)
On 8/12/2016 3:12 AM, deadalnix wrote: I raised that in November 2014 already. I remember the discussion. To be honest I'm to a point were I'm starting withdrawing from these conversation because I have no idea how to reach to you guys. I could write on toilet paper before using it to the same effect. I believe I understood your point. I just didn't agree that was the best way forward for D. I didn't expect you'd changed your mind, either :-)
Re: DIP1000: Scoped Pointers (Discussion)
On 8/12/2016 2:42 AM, Robert burner Schadek wrote: Hm, that is really bad IMO. The shown use case is properly the most common use case. Is there no way to make it transitive so the lifetime of rcs[0] is the lifetime of rcs. rcs[0].a = 1337; assert(rcs[0].a == 1337); It shouldn't be a big problem if the containers are shallow - the optimizer can remove the redundant computations. To be blunt, this is a real show-stopper for me. Generally, it will require a more thorough use of encapsulation of containers and operations on them, if one is to use malloc/free or ref counting safely.
Re: DIP1000: Scoped Pointers (Discussion)
On Friday, 12 August 2016 at 10:24:22 UTC, Robert burner Schadek
wrote:
No, the DIP doesn't handle several levels of indirection.
What about:
struct Bar { int a; int b }
auto rcs = RefCountedTree!(string,Bar)();
fcs["bar"].a = 1337; // log n
fcs["bar"].b = 1338; // log n
? I need to pay log n twice to assign two members
What you are proposing is having the returned value survive not
till the end of the expression, but longer. The question is how
long. If, instead of a tree, you use an hashmap, then the
reference to rcs["bar"] may die long before rcs itself (because
of a rehash).
So for this to work the compiler should consider the references
returned by the functions to be valid until a mutable operation
is applied to the container, i think.
Re: DIP1000: Scoped Pointers (Discussion)
On 8/12/2016 3:24 AM, Robert burner Schadek wrote: ? I need to pay log n twice to assign two members In order to return a pointer that lasts longer than an expression, make it a ref counted entity as well.
Re: Why D is not popular enough?
On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote: I am a C++ expert who has looked at D in the past. Perhaps my reasons for not programming in D may be taken as some of the reasons why D "is not popular enough". My opinions are not meant to start a flame war, even if some of my insights may be harsh to those who do use D. They will hopefully give some idea of why and where D went wrong in trying to appeal to the general intelligent programmer as a programming language. 1) Until very recently the documentation for D has been very substandard. I do notice better documentation both on the web site now and a few more books on D as a programming language. For a very long time after D was created, even after version 2 was created, there was essentially no decent documentation at all. If you are trying to promote the use of a computer language to the general public you must create first-rate documentation and explanation of your computer language from the very beginning. Without this first-rate documentation your programming language, no matter how good it might be, is just a toy to those who want to play around with it and try it out. This is the case that D promoted for a very long time, so the expectation that D was going to become popular to the programming public with such poor documentation was just foolish. C took off as a programming language for the general programming when Kernigan and Ritchie wrote their classic book and C++ took off as a programming language for the general public when Stroustrop and subsequently Lippman wrote their classuc books. While I think that Alexandrescu's book is decent it is not written at the level of these others. I never got that point, really. When I started to program in D around 2010, documentation for D was almost non existent, but I quickly learned how to use it by just, well, using it. Programming languages have a lot of things in common, once you know one (or two) others are not so hard to learn/understand/use. If you come from a C++ background, understanding D should be a piece of cake. 2) While I greatly respect the programming abilities of Mr. Bright and Mr. Alexandrescu and their hard work in creating and improving D, having followed both from the C++ world, the arrogance by which D was initially and repeatedly compared against C/C++ has been totally out of place since the beginning. C++ is a very good language and the effort made to denigrate it with specious and ridiculously false arguments about it vis-a-vis D as a programming language has almost irreparably hurt D as a serious programming language irrespective of its actual abilities or weaknesses. You are not going to appeal to the really intelligent programmers out there if you are not honest and rigorous in discussion of your own programming language in relation to others. All that you end up doing is to alienate anyone with real programming intelligence by the tactics that D has taken over the years with such comparisons. Cf. Patrick's comment. Let me add this: by constantly mentioning `intelligent programmers` you insinuate that people who use D are idiots who religiously worship the language. Anything but. The thing is that in D things are moving (and people in the community perceive it as something positive), which brings me to your next point. 3) D has suffered greatly because it has had too many moving targets as if constant change to something slightly better is going to endear programmers to using a computer language. Programmers need stability. The needed to know that if they are using a programming language they are getting a particular standard at a particular time with particular libraries that work. They also need backward compatibility when things change. D appears to have presented an almost constantly moving target to this programmer, where adding/changing some feature is much more important than fixing problems and providing stability. True. I admit that I "fear" every new release in the sense that something will break and I'll have to fix it. More often than not, however, the fixes are trivial, and if they make sense and improve the language, I'm willing to pay the price. But your argument shows the fix D developers are in: to provide a better language without changing it (paradox). The trivial truth is that you can only improve a language by changing it and you need a community that is willing to go along with the changes. For this reason D hasn't taken off, because most people are not willing to risk (or cannot afford) frequent changes. Personally, I don't know which is worse, frequent (educated) changes or years of suboptimal coding until changes are made at long last (cf. Java). Mind you, well established languages like Java and C++ are now adopting things that have been around in D (and other languages) for a while, because those concepts have proven to be useful. This said, D
Re: DIP1000: Scoped Pointers (Discussion)
On Thursday, 11 August 2016 at 21:57:06 UTC, Walter Bright wrote: On 8/11/2016 6:36 AM, Marc Schütz wrote: 4) The DIP doesn't address mutable aliasing at all. As a consequence, the example `RefCountedSlice` is unsafe: auto arr = RefCountedSlice!int(10); auto ptr = &arr[5]; arr = RefCountedSlice!int(42); *ptr = 1;// use after free The idea is to have containers return references by 'return ref' or 'return scope' so the internal references can't escape the expression they're used in. So &arr[5] would be an error. The bug can still occur when passing arr and arr[5] both by reference to a function, but that case can (in future) be solved by making RefCountedSlice an @rc object*. * https://wiki.dlang.org/DIP77
Re: Why D is not popular enough?
On 8/12/16 4:59 AM, Patrick Schluter wrote: On Thursday, 11 August 2016 at 20:16:04 UTC, bachmeier wrote: On Thursday, 11 August 2016 at 15:41:42 UTC, Edward Diener wrote: the arrogance by which D was initially and repeatedly compared against C/C++ has been totally out of place since the C++ is a very good language and the effort made to denigrate it with specious and ridiculously false arguments about it vis-a-vis D as a programming language has almost irreparably hurt D as a serious programming language irrespective of its actual abilities or weaknesses. You are not going to appeal to the really intelligent programmers out there if you are not honest and rigorous in discussion of your own programming language in relation to others. All that you end up doing is to alienate anyone with real programming intelligence by the tactics that D has taken over the years with such comparisons. I never understood how people can get their feelings hurt when criticising the language they program in. Either the criticised point is true and one accepts it or not, in that case a factual refutation can be done. Feeling offended is ridiculous. I recall I had a similar reaction as Edward back in the day. No hurt feelings or anything, but the arguments made were so specious I'd roll my eyes whenever I saw them in the C++ forums. -- Andrei
Re: DIP1000: Scoped Pointers (Discussion)
On 8/12/16 6:12 AM, deadalnix wrote: To be honest I'm to a point were I'm starting withdrawing from these conversation because I have no idea how to reach to you guys. You committed to author a proposal a few months back. Did you make progress on that? -- Andrei
Re: DIP1000: Scoped Pointers (Discussion)
On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu wrote: On 8/12/16 6:12 AM, deadalnix wrote: To be honest I'm to a point were I'm starting withdrawing from these conversation because I have no idea how to reach to you guys. You committed to author a proposal a few months back. Did you make progress on that? -- Andrei Are you referring to this one? https://github.com/dlang/DIPs/pull/16
[OT] Re: DIP1000: Scoped Pointers (Discussion)
On 8/12/16 8:28 AM, Seb wrote: On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu wrote: On 8/12/16 6:12 AM, deadalnix wrote: To be honest I'm to a point were I'm starting withdrawing from these conversation because I have no idea how to reach to you guys. You committed to author a proposal a few months back. Did you make progress on that? -- Andrei Are you referring to this one? https://github.com/dlang/DIPs/pull/16 One of our clocks is skewed, which is it? -- Andrei
Re: DIP1000: Scoped Pointers (Discussion)
On 8/12/16 8:28 AM, Seb wrote: On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu wrote: On 8/12/16 6:12 AM, deadalnix wrote: To be honest I'm to a point were I'm starting withdrawing from these conversation because I have no idea how to reach to you guys. You committed to author a proposal a few months back. Did you make progress on that? -- Andrei Are you referring to this one? https://github.com/dlang/DIPs/pull/16 That was related to safety and lifetimes. I've created the study group specifically to encourage positive contribution from talented folks instead of negative reaction. Sadly it hasn't bore fruit yet. It is surprising deadalnix still frames the discussion as him proposing things and not being heard; my perception is he consistently refuses to contribute literally anything in spite of my desperate attempts to get him to work on something - anything -, and instead chooses to wait on the sidelines and criticize destructively any attempt to make progress. -- Andrei
Re: [OT] Re: DIP1000: Scoped Pointers (Discussion)
On Friday, 12 August 2016 at 12:41:07 UTC, Andrei Alexandrescu wrote: On 8/12/16 8:28 AM, Seb wrote: On Friday, 12 August 2016 at 12:29:21 UTC, Andrei Alexandrescu wrote: On 8/12/16 6:12 AM, deadalnix wrote: To be honest I'm to a point were I'm starting withdrawing from these conversation because I have no idea how to reach to you guys. You committed to author a proposal a few months back. Did you make progress on that? -- Andrei Are you referring to this one? https://github.com/dlang/DIPs/pull/16 One of our clocks is skewed, which is it? -- Andrei Wait - you are not "from the future"? :O http://i.imgur.com/9pvCtXR.png (I just checked my phone and it seems to be in sync)
Re: DIP1000: Scoped Pointers (Discussion)
On Thursday, 11 August 2016 at 08:53:22 UTC, John Colvin wrote:
On Thursday, 11 August 2016 at 08:45:38 UTC, Walter Bright
wrote:
On 8/11/2016 1:29 AM, John Colvin wrote:
Can someone talk me through the lifetime algebra for the
following?
void foo()
{
int a;
int** c;
void bar()
{
int* b = &a; <= ok, b has a smaller lifetime than a
c = &b;<= error, c has a larger lifetime than b
}
bar();
*c; //undefined behaviour
}
but according to this rule:
"For an unrestricted pointer, visibility is dictated by the
usual lexical scope rules. Lifetime, however is dictated by the
lifetime of the data to which the pointer points to."
b should have the same lifetime as a, no?
ping on this? I want to understand what's going on here and be
another set of eyes checking for mistakes, but I'm stuck on this
bit of the spec.
Re: DIP1000: Scoped Pointers (Discussion)
On Thursday, 11 August 2016 at 21:57:06 UTC, Walter Bright wrote:
auto arr = RefCountedSlice!int(10);
auto ptr = &arr[5];
arr = RefCountedSlice!int(42);
*ptr = 1;// use after free
The idea is to have containers return references by 'return
ref' or 'return scope' so the internal references can't escape
the expression they're used in.
What expressions are allowed? Will this work?
auto arr = RefCountedSlice!int(10);
void f(scope ref int n)
{
arr = RefCountedSlice!int(42);
n = 1; // use after free
}
f(arr[5]);
Re: GtkD Binaries
On 08/12/2016 09:03 AM, Sean Campbell wrote: Does anyone know where i could find the DLLs not included in the gtk+ runtime installer for GtkD, as I don't have the necessary environment to build the gtk+ runtime. I have already located a copy of "libgtksourceview-3.0-1.dll" (Found it on the pbone rpm archive). I still need to find "libvte-2.91.dll" and a bunch of others. The Binaries in the gtk+ installer used by GtkD are coming from MSYS2. So if your missing anything you could check there, although they don't have binaries for Vte. GtkSourceview should have been included in the installer. -- Mike Wey
Re: DIP1000: Scoped Pointers (Discussion)
On Fri, 12 Aug 2016 10:24:22 +, Robert burner Schadek wrote:
>> No, the DIP doesn't handle several levels of indirection.
>
> What about:
>
> struct Bar { int a; int b }
> auto rcs = RefCountedTree!(string,Bar)();
>
> fcs["bar"].a = 1337; // log n
> fcs["bar"].b = 1338; // log n
>
> ? I need to pay log n twice to assign two members
In the worst case, you can change the API so you can write:
rcs.update("bar", (x) { x.a = 1337; x.b = 1338; });
Re: Why D is not popular enough?
On Fri, 12 Aug 2016 08:59:14 +, Patrick Schluter wrote: > I never understood how people can get their feelings hurt when > criticising the language they program in. > > Yeah, it's also known as Stockholm Syndrome :-) Because you specifically are criticizing the person directly, not the language they use, now.
Re: Why D is not popular enough?
On Friday, 12 August 2016 at 09:38:13 UTC, Guillaume Piolat wrote: From the best of my knowledge you cannot do these things in in C++: The most important thing is what you can't do in D: read a Scott Meyers book.
Re: Why D is not popular enough?
On 8/12/16 10:19 AM, bachmeier wrote: On Friday, 12 August 2016 at 09:38:13 UTC, Guillaume Piolat wrote: From the best of my knowledge you cannot do these things in in C++: The most important thing is what you can't do in D: read a Scott Meyers book. That's the last thing D needs. -Steve
Re: Why D is not popular enough?
On Fri, 12 Aug 2016 09:38:13 +, Guillaume Piolat wrote: > From the best of my knowledge you cannot do these things in in > C++: > > https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time- through-CTFE You can use an external tool at build time to do this, but it's awkward. (DMD, when it was C++-based, used that technique to generate a few things.) > https://p0nce.github.io/d-idioms/#Embed-a-dynamic-library-in-an- executable You need a resources script for it with MSVC++. If you're building an ELF executable, you can use `objcopy(1)` to convert a data file into an object file containing static data. Which is, I feel, the story of life using D vs C++. You can get it done in C++, but it might take some external tools, it's going to be awkward, and it's going to be different on every platform.
Re: DIP1000: Scoped Pointers (Discussion)
On Friday, 12 August 2016 at 14:02:50 UTC, Chris Wright wrote:
In the worst case, you can change the API so you can write:
rcs.update("bar", (x) { x.a = 1337; x.b = 1338; });
yes, but that will not catch on. And I think (x) must be (scope
ref x)
Re: Why D is not popular enough?
On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote: I cannot say the same thing about the things in C++ I miss when I write D. Be constructive and enumerate them.
Re: Why D is not popular enough?
On 11/08/16 18:41, Edward Diener wrote: 2) While I greatly respect the programming abilities of Mr. Bright and Mr. Alexandrescu and their hard work in creating and improving D, having followed both from the C++ world, the arrogance by which D was initially and repeatedly compared against C/C++ has been totally out of place since the beginning. C++ is a very good language and the effort made to denigrate it with specious and ridiculously false arguments about it vis-a-vis D as a programming language has almost irreparably hurt D as a serious programming language irrespective of its actual abilities or weaknesses. You are not going to appeal to the really intelligent programmers out there if you are not honest and rigorous in discussion of your own programming language in relation to others. All that you end up doing is to alienate anyone with real programming intelligence by the tactics that D has taken over the years with such comparisons. To me, this is not so much the question of alienating C++ programmers, as it is that this arrogance is actively hindering D from becoming better. Any time I raise an issue I have with D, the discussion with both AA and WB seems more like an argument designed to prove to me that I am wrong than like a discussion aimed to make D better. Once they decide that something is best a certain way, it is very very difficult to make them see the downsides of that decision, much less act on it. And, to me, this is an actual threat to D's future as a wide spread programming language. This attitude, if unchanged, will doom D to become a niche language, only suited for those who do not need it for anything that WB and AA have not thought of. 4) As a C++ programmer largely interested in C++ template programming, C++ concepts etc., and potential compile-time/run-time introspection, I have never found a compelling reason to use D rather than C++. I do recognize that C++'s template syntax is difficult and abstruse but I do not and have never seen where D improves upon these matters in any serious and rigorous way. This may be because the documentation about these areas in D is either very light or almost completely lacking. Even in Mr. Alexandrescu's book the discussion of these areas was very light in my estimation. So whatever D has to offer in these areas, if there are really impovements, is either lacking in the D documentation or does not really exist for me. Here I'm not sure I follow you. I love C++, but its compile time execution is just horrible. Yes, if you are fluent with functional programming you will probably get by sufficiently, but since C++ isn't itself a functional language, this means doing C++ meta-programming requires a different programming paradigm than programming C++. It is a very very very high barrier to pass. Personally, I'm not a fan of doing too much during compile time. I think it introduces a level of complexity into your program, where the program as seen by the CPU is considerably different than the one you see in your source editor, that is hard to track and debug. As such, the weakness of C++'s meta programming has not been a major setback for me. If you do like compile time programming, however, I don't see how you can claim that C++'s is good enough, when compared to D's. Shachar
Re: D Github contributors - enable 2 factor authentification
On Friday, 12 August 2016 at 08:10:15 UTC, Walter Bright wrote: Currently 11/35 have enabled 2FA Have you 5 hidden members ?
Re: Why D is not popular enough?
On 12/08/16 12:38, Guillaume Piolat wrote: From the best of my knowledge you cannot do these things in in C++: https://p0nce.github.io/d-idioms/#Precomputed-tables-at-compile-time-through-CTFE I maintain an open source program called fakeroot-ng. It is written in C++. Just today, while doing some cleanups, I ran across this point when trying to convert a table to const. So, yes, having a CTFE to compute the table would have been great, and had fakeroot-ng been written in D, I would have. Then again, the ultimate cost of not doing this is so low, that I didn't really feel cheated out of it. That table was not expensive to compute, and its constantness wasn't crucial enough even for me to put a wrapper pointer and only access it through it. Had that not been the case, and had that table been more expensive to computer, I'd probably compute at compile time with an external tool. The point is that while I missed have D's CTFE to compute that table, I didn't miss it much, and I don't miss D features often. Sadly, I cannot say the same thing about the things in C++ I miss when I write D. They are both everyday and, to me, without reasonable substitutes. Shachar
Re: D Github contributors - enable 2 factor authentification
On 8/12/16 10:53 AM, mùsdl wrote: On Friday, 12 August 2016 at 08:10:15 UTC, Walter Bright wrote: Currently 11/35 have enabled 2FA Have you 5 hidden members ? Members have the option of publicly exposing their membership. -Steve
Re: Why D is not popular enough?
On Friday, 12 August 2016 at 12:27:50 UTC, Andrei Alexandrescu wrote: I recall I had a similar reaction as Edward back in the day. No hurt feelings or anything, but the arguments made were so specious I'd roll my eyes whenever I saw them in the C++ forums. -- Andrei I already roll my eyes at these threads and I've only been using D for like a year or two. I'm amazed you still have eyes at this point.
Re: Why D is not popular enough?
On Friday, 12 August 2016 at 14:24:06 UTC, Steven Schveighoffer wrote: On 8/12/16 10:19 AM, bachmeier wrote: On Friday, 12 August 2016 at 09:38:13 UTC, Guillaume Piolat wrote: From the best of my knowledge you cannot do these things in in C++: The most important thing is what you can't do in D: read a Scott Meyers book. That's the last thing D needs. -Steve Though people could enjoy an article explaining how shared works :)
Re: Why D is not popular enough?
On 8/12/16 11:28 AM, Kagamin wrote: Though people could enjoy an article explaining how shared works :) First you have to find someone who knows how it works :) All kidding aside, shared is pretty broken currently. If you want to know how it was *supposed* to work, you can read TDPL, though I'm not sure that's still valid. -Steve
Re: Why D is not popular enough?
On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote: So, yes, having a CTFE to compute the table would have been great, and had fakeroot-ng been written in D, I would have. Then again, the ultimate cost of not doing this is so low, that I didn't really feel cheated out of it. I was just giving examples of things that aren't possible in C++, or are possible but less easy, require external programs, require incredible macros... If it's not easy it's as if it doesn't exist.
Re: DIP1000: Scoped Pointers (Discussion)
On Fri, Aug 12, 2016 at 01:27:08PM +, Kagamin via Digitalmars-d wrote:
> On Thursday, 11 August 2016 at 21:57:06 UTC, Walter Bright wrote:
> > > auto arr = RefCountedSlice!int(10);
> > > auto ptr = &arr[5];
> > > arr = RefCountedSlice!int(42);
> > > *ptr = 1;// use after free
> >
> > The idea is to have containers return references by 'return ref' or
> > 'return scope' so the internal references can't escape the
> > expression they're used in.
>
> What expressions are allowed? Will this work?
>
> auto arr = RefCountedSlice!int(10);
> void f(scope ref int n)
> {
> arr = RefCountedSlice!int(42);
> n = 1; // use after free
> }
> f(arr[5]);
Nice one!
But I believe the current rules ought to catch this case as well,
because if RefCountedSlice!int(42) returns by scope, then assigning it
to arr would be illegal (lifetime of arr is longer than lifetime of the
new slice).
T
--
"No, John. I want formats that are actually useful, rather than over-featured
megaliths that address all questions by piling on ridiculous internal links in
forms which are hideously over-complex." -- Simon St. Laurent on xml-dev
Re: Why D is not popular enough?
On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote:
That table was not expensive to compute, and its constantness
wasn't crucial enough even for me to put a wrapper pointer and
only access it through it. Had that not been the case, and had
that table been more expensive to computer, I'd probably
compute at compile time with an external tool.
Shachar
And you are forgetting about composability. If I can compute a
table at compile-time this means I can go higher on the
abstraction ladder.
void interpFast(string expr)(float x)
{
// here a look-up computed at compile-time
static immutable table = makeTable!exp(0, 100, 0.1f);
int ipart = cast(int)x;
int fpart = x - ipart;
return linInterp(table[ipart], table[ipart+1], fpart);
}
void main()
{
// automatically tabulated
float x = interpFast!"pow(cos(x) + 4, x)"(0.5f);
}
Not only is this impossible in C++, but being cumbersome it means
that people won't do it and loose optimization opportunities.
Re: Why D is not popular enough?
On Friday, 12 August 2016 at 12:27:50 UTC, Andrei Alexandrescu wrote: I recall I had a similar reaction as Edward back in the day. No hurt feelings or anything, but the arguments made were so specious I'd roll my eyes whenever I saw them in the C++ forums. -- Andrei So what changed? What gave you the initial kick to start moving from sideline scoffer to benevolent diarch? -Wyatt
Re: Why D is not popular enough?
On Friday, 12 August 2016 at 15:43:54 UTC, Steven Schveighoffer wrote: All kidding aside, shared is pretty broken currently. If you want to know how it was *supposed* to work, you can read TDPL, though I'm not sure that's still valid. Ah, was it Andrei, who tried to sell the idea that shared is a silver bullet for concurrency problems? That can explain why we have two different views on shared. Looks like a repetition of the story with autodecoding (with similar rationale).
Re: Why D is not popular enough?
On Friday, August 12, 2016 16:38:23 Kagamin via Digitalmars-d wrote: > On Friday, 12 August 2016 at 15:43:54 UTC, Steven Schveighoffer > > wrote: > > All kidding aside, shared is pretty broken currently. If you > > want to know how it was *supposed* to work, you can read TDPL, > > though I'm not sure that's still valid. > > Ah, was it Andrei, who tried to sell the idea that shared is a > silver bullet for concurrency problems? That can explain why we > have two different views on shared. Looks like a repetition of > the story with autodecoding (with similar rationale). Honestly, I don't think that shared is broken. It's just that once you've locked the appropriate mutex, you have to cast a way shared and make sure that no thread-local references to that data are still around when you release the lock. shared is doing its job of indicating when a variable isn't thread-local as well as preventing a number of incorrect operations on data that's shared across threads without being protected by a lock. What we're missing is a way safely have shared cast away for us so that we don't have to do the work of verifying that we're not screwing it up. synchronized classes as described in TDPL partially solve the problem in that they provide a safe, automatic way to remove one layer of shared - but it's only one layer, and it's never been implemented. It's the equivalent of having a set of operations that we'd like to be @safe but are stuck as @system, and we're forced to use @trusted to deal with it. But folks get annoyed with shared, because they have to cast it away at the appropriate time. They just want it to magically work in a safe manner, and we simply haven't figured out how to do that. Instead, we have a way to segregate shared stuff and thus minimize how much code has to deal with the problems that come with sharing data across threads but which requires that you handle it carefully rather than having a way to just handle it safely, automatically. shared isn't perfect, but having thread-local by default is dowright fantastic, and when you have to deal with shared, you mostly doing the same sorts of things that you're supposed to be doing in C++. It's just that you have to cast away shared to operate on the object while the mutex is locked. IMHO, the biggest problem with shared is that the related types in druntime (like the mutexes and condition variables) aren't marked with it properly rather than shared itself being fundamentally flawed. - Jonathan M Davis
Re: Why D is not popular enough?
On 08/12/2016 12:31 PM, Wyatt wrote: On Friday, 12 August 2016 at 12:27:50 UTC, Andrei Alexandrescu wrote: I recall I had a similar reaction as Edward back in the day. No hurt feelings or anything, but the arguments made were so specious I'd roll my eyes whenever I saw them in the C++ forums. -- Andrei So what changed? What gave you the initial kick to start moving from sideline scoffer to benevolent diarch? Walter and I talked and he said he'd be interested in working together on the kind of things I was interested in: generic programming, static introspection, and such. -- Andrei
Re: Why D is not popular enough?
On 08/12/2016 10:51 AM, Shachar Shemesh wrote: To me, this is not so much the question of alienating C++ programmers, as it is that this arrogance is actively hindering D from becoming better. I agree it would behoove us to be more humble. -- Andrei
Re: Why D is not popular enough?
On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote: Honestly, I don't think that shared is broken. Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!) The thing that is NOT broken is unshared. There's literally not much you can do with shared, and what you can do isn't consistent or useful. It needs lots of attention. -Steve
Does not work on fresh dmd: make -j16 -f posix.mak AUTO_BOOTSTRAP=1
Anyone knows about this? I'm investigating it, any help would be appreciated. Thanks! -- Andrei
Re: Why D is not popular enough?
On 08/12/2016 01:21 PM, Steven Schveighoffer wrote: On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote: Honestly, I don't think that shared is broken. Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!) How is this broken and how should it behave? -- Andrei
Re: Why D is not popular enough?
On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 08/12/2016 01:21 PM, Steven Schveighoffer wrote: > > On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote: > > > > > > Honestly, I don't think that shared is broken. > > > > Yes. It is broken. > > > > shared int x; > > ++x; // error, must use atomicOp. > > x = x + 1; // OK(!) > > How is this broken and how should it behave? -- Andrei ?! Isn't it obvious that assigning to a shared int must require atomicOp or a cast? `x = x + 1;` clearly has a race condition otherwise. T -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen
Re: Does not work on fresh dmd: make -j16 -f posix.mak AUTO_BOOTSTRAP=1
On Friday, 12 August 2016 at 18:02:30 UTC, Andrei Alexandrescu wrote: Anyone knows about this? I'm investigating it, any help would be appreciated. Thanks! -- Andrei Yep, it's known. You need to move the comment of the version a line above: https://github.com/dlang/dmd/pull/6022#issuecomment-238328228 Idk why it hasn't been fixed yet, but this PR should do? (I don't use a Mac) https://github.com/dlang/dmd/pull/6051
Re: Does not work on fresh dmd: make -j16 -f posix.mak AUTO_BOOTSTRAP=1
On 08/12/2016 02:13 PM, Seb wrote: On Friday, 12 August 2016 at 18:02:30 UTC, Andrei Alexandrescu wrote: Anyone knows about this? I'm investigating it, any help would be appreciated. Thanks! -- Andrei Yep, it's known. You need to move the comment of the version a line above: https://github.com/dlang/dmd/pull/6022#issuecomment-238328228 Idk why it hasn't been fixed yet, but this PR should do? (I don't use a Mac) https://github.com/dlang/dmd/pull/6051 https://github.com/dlang/dmd/pull/6052 also fixes a typo, could you please pull it and close the other :o). -- Andrei
Re: Why D is not popular enough?
On 08/12/2016 02:01 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: On 08/12/2016 01:21 PM, Steven Schveighoffer wrote: On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote: Honestly, I don't think that shared is broken. Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!) How is this broken and how should it behave? -- Andrei ?! Isn't it obvious that assigning to a shared int must require atomicOp or a cast? `x = x + 1;` clearly has a race condition otherwise. It is not to me, and it does not seem like a low-level race condition to me (whereas ++x is). Currently the compiler must ensure that an atomic read and an atomic write are generated for x. Other than that, it is the responsibility of the user. The use of "shared" does not automatically relieve the user from certain responsibilities. I agree that it would be nice to have stronger protection against higher-level bugs, but those are outside the charter of "shared". Consider: x = *p + 1; How would the compiler reject the right uses but not the case when p == &x? Andrei
Re: Why D is not popular enough?
On Friday, August 12, 2016 13:21:10 Steven Schveighoffer via Digitalmars-d wrote: > On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote: > > Honestly, I don't think that shared is broken. > > Yes. It is broken. > > shared int x; > ++x; // error, must use atomicOp. > x = x + 1; // OK(!) > > The thing that is NOT broken is unshared. > > There's literally not much you can do with shared, and what you can do > isn't consistent or useful. > > It needs lots of attention. It does not surprise me in the least if there are bugs related to shared in the compiler, and we definitely don't deal with it properly in druntime with regards to stuff like Mutex and Condition. But I don't agree with the idea that shared is fundamentally broken. - Jonathan M Davis
Re: Why D is not popular enough?
On Fri, Aug 12, 2016 at 02:21:04PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 08/12/2016 02:01 PM, H. S. Teoh via Digitalmars-d wrote: > > On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via > > Digitalmars-d wrote: > > > On 08/12/2016 01:21 PM, Steven Schveighoffer wrote: > > > > On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote: > > > > > > > > > > Honestly, I don't think that shared is broken. > > > > > > > > Yes. It is broken. > > > > > > > > shared int x; > > > > ++x; // error, must use atomicOp. > > > > x = x + 1; // OK(!) > > > > > > How is this broken and how should it behave? -- Andrei > > > > ?! > > > > Isn't it obvious that assigning to a shared int must require > > atomicOp or a cast? `x = x + 1;` clearly has a race condition > > otherwise. > > It is not to me, and it does not seem like a low-level race condition > to me (whereas ++x is). The problem is that the line between "low-level" and "high-level" is unclear and arbitrary. Doesn't ++x lower to x = x + 1 on some CPUs anyway (or vice versa, if the optimizer decides to translate it the other way)? Why should the user have to worry about such details? Wouldn't that make shared kinda useless to begin with? > Currently the compiler must ensure that an atomic read and an atomic > write are generated for x. Other than that, it is the responsibility > of the user. The use of "shared" does not automatically relieve the > user from certain responsibilities. > > I agree that it would be nice to have stronger protection against > higher-level bugs, but those are outside the charter of "shared". > Consider: > > x = *p + 1; > > How would the compiler reject the right uses but not the case when p > == &x? [...] The compiler should reject it (without the appropriate casts) if p has a shared type, and the aliasing situation with x is unknown / unclear. The programmer ought to explicitly state the assumption that x isn't aliased by p by specifying a cast (or equivalent), rather than be able to write such code, possibly not being aware of the implications, and have it compile without any warning. T -- If lightning were to ever strike an orchestra, it'd always hit the conductor first.
Phobos unittests either spuriously fail or spuriously pass
I was surprised to see this in phobos master: make -f posix.mak unittest This passes. So do these: make -f posix.mak BUILD=debug unittest make -f posix.mak BUILD=release unittest Now, this also passes: make -f posix.mak BUILD=debug std/algorithm/sorting.test But this fails in std/algorithm/sorting.d line 2266! make -f posix.mak BUILD=release std/algorithm/sorting.test I'll investigate this. Any insight is welcome! Thanks, Andrei
Re: Phobos unittests either spuriously fail or spuriously pass
On Friday, 12 August 2016 at 18:45:54 UTC, Andrei Alexandrescu wrote: I was surprised to see this in phobos master: make -f posix.mak unittest This passes. So do these: make -f posix.mak BUILD=debug unittest make -f posix.mak BUILD=release unittest Now, this also passes: make -f posix.mak BUILD=debug std/algorithm/sorting.test But this fails in std/algorithm/sorting.d line 2266! make -f posix.mak BUILD=release std/algorithm/sorting.test I'll investigate this. Any insight is welcome! Thanks, Andrei That is known as well ;-) std.algorithm.sorting fails in the individual test due to entropy behaving weird in std.math: A couple of pointers: - https://github.com/dlang/phobos/pull/4587 (recognizes this problem and ignores std.algorithm.sorting from Travis) - https://github.com/dlang/phobos/pull/4719 (switches back to just run test_runner)
Re: Phobos unittests either spuriously fail or spuriously pass
On Friday, 12 August 2016 at 18:57:37 UTC, Seb wrote: On Friday, 12 August 2016 at 18:45:54 UTC, Andrei Alexandrescu wrote: I was surprised to see this in phobos master: make -f posix.mak unittest This passes. So do these: make -f posix.mak BUILD=debug unittest make -f posix.mak BUILD=release unittest Now, this also passes: make -f posix.mak BUILD=debug std/algorithm/sorting.test But this fails in std/algorithm/sorting.d line 2266! make -f posix.mak BUILD=release std/algorithm/sorting.test I'll investigate this. Any insight is welcome! Thanks, Andrei That is known as well ;-) std.algorithm.sorting fails in the individual test due to entropy behaving weird in std.math: A couple of pointers: - https://github.com/dlang/phobos/pull/4587 (recognizes this problem and ignores std.algorithm.sorting from Travis) - https://github.com/dlang/phobos/pull/4719 (switches back to just run test_runner) I answered to quickly: 1) entropy is in std.numeric, not std.math 2) the issue has been reported a month ago - https://issues.dlang.org/show_bug.cgi?id=16227 3) #4587 just found a workaround of 16227 for std.numeric, not for its caller
Re: Why D is not popular enough?
On 8/12/2016 7:41 AM, Shachar Shemesh wrote: That table was not expensive to compute, and its constantness wasn't crucial enough even for me to put a wrapper pointer and only access it through it. Had that not been the case, and had that table been more expensive to computer, I'd probably compute at compile time with an external tool. What I do (and is done in building DMD) is write a program (optabgen.c) to generate the tables and write a C++ source file, then compile the generated file into DMD.
[OT] The coolest (literally) desktop machine I've ever had
I was using a large Lenovo Y70-70 laptop as a pseudo-desktop machine and additional monitor. It's quite powerful, but its fans would run at all times. Getting really tired of that, I googled for the better part of an afternoon for "fanless desktop" and it turns out it's much harder to find one than I'd initially thought. (Slow fanless machines are easy to find, but I was looking for one as powerful as any desktop.) At about the time I was ready to give up I found an obscure site of an Israeli company that claimed to make a real i7 fanless machine. It was releases very recently, too, so I'm thinking it might be of interest to some others. So I got it from Amazon: https://www.amazon.com/dp/B01CP4S15E. I fitted it with 8 GB RAM and 512 GB SSD. It's more expensive than a traditional desktop of the same configuration, but as soon as you turn it on, you know where that extra money went. (Speaking of money, ironically, the extra expenditure has had an unexpected return: I occasionally daytrade, and when I do I need CNBC on. That made the laptop's fans make even more noise than usual, so I was avoiding it. Nowadays I can keep CNBC on no problem, which allowed me to handily cover the extra expense.) I've put Linux Mint on it (which is what they recommend) and it works swimmingly. The handling of multiple desktops is just awesome. The one thing I don't like about the machine is it always powers the discrete graphics card, which I don't use. Their engineers (who've been very active to respond to my emailed questions) said a future BIOS upgrade will allow powering off the card. Thought this might help others looking for a fanless dekstop. Andrei
Re: Why D is not popular enough?
On 12/08/16 22:07, Walter Bright wrote: On 8/12/2016 7:41 AM, Shachar Shemesh wrote: That table was not expensive to compute, and its constantness wasn't crucial enough even for me to put a wrapper pointer and only access it through it. Had that not been the case, and had that table been more expensive to computer, I'd probably compute at compile time with an external tool. What I do (and is done in building DMD) is write a program (optabgen.c) to generate the tables and write a C++ source file, then compile the generated file into DMD. Yes, I'm sorry. I meant to say "build time" instead of "compile time". That is precisely what I meant. Shachar
Re: Why D is not popular enough?
On 12/08/16 17:50, mùsdl wrote: On Friday, 12 August 2016 at 14:41:14 UTC, Shachar Shemesh wrote: I cannot say the same thing about the things in C++ I miss when I write D. Be constructive and enumerate them. I'll give some highlights, but those are, mostly, things that I've already listed in this forum and in my lightening talk. - No RAII support, despite the fact everybody here seems to think that D supports RAII. - Recursive const makes many cases where I can use const in C++ (and enjoy the protection it provides) simply mutable in D. - This one I have not complained about yet. Operator overloads stepping on each other's toes. In my case, I have a container (with opIndex that accepts a custom type and opOpAssign!"~") and I place in it a struct with some operator overloads as well (have not reduced the cause yet, hence no previous complaint about this one). So, when I write Container[IndexType] ~= Type; And the compiler assumes that means: Container.opIndexOpAssign!"~"(IndexType, Type); but since nothing like that is defined, the code doesn't compile. I ended up writing (actual code from the Weka code base): blockIds[diskIdx].opOpAssign!"~"(makeBlockId(stripeIdx+i, placement.to!SlotIdx(diskIdx))); Took me almost ten minutes and consulting someone else to find this solution. - GC. GC. GC. Some more GC. - Integral type operations promotion and the constant need for casts. - No warning for signed/unsigned comparisons. An unfailing source for bugs. - No ref type. These are just off the top of my head. There are more. Like I said, my frustrations with D are daily. Shachar
Re: DIP1000: Scoped Pointers (Discussion)
On 10.08.2016 22:36, Dicebot wrote: http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org The first DIP has just landed into the new queue. It is a proposal from language authors and thus it bypasses usual nitpicking process and proceeds straight to requesting community (your!) feedback. Essentially, it is an attempt to solve reference lifetime problem by extending implementation of `scope` keyword. Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md This proposes to add a kind of information the type system is supposed to track (lifetimes), which cannot be communicated losslessly across function and aggregate boundaries. Hence it won't work well in its current form.
Re: Why D is not popular enough?
On 08/12/2016 08:04 PM, Andrei Alexandrescu wrote:
On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
[...]
shared int x;
++x; // error, must use atomicOp.
x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
I may be responsible for some confusion here, including my own.
Disclaimer: I'm far from being an expert on thread-safety. I may have
misunderstandings about fundamentals.
Recently, I made a thread titled "implicit conversions to/from shared":
http://forum.dlang.org/post/nlth0p$1l7g$1...@digitalmars.com
Before starting that thread, and before messing with atomicOp, I had
assumed that D enforces atomic reads/writes on shared types. Then I
noticed that I can read/write shared types that are too large for atomic
ops.
Example:
alias T = ubyte[1000];
enum T a = 1;
enum T b = 2;
shared T x = a;
import core.thread: Thread;
void write()
{
bool flip = false;
foreach (i; 0 .. 1_000_000)
{
if (flip) x = a; else x = b; // non-atomic write
flip = !flip;
}
}
void main()
{
auto t = new Thread(&write);
t.start();
foreach (i; 0 .. 1_000_000)
{
T r = x; // non-atomic read
assert(r == a || r == b); // fails
}
t.join();
}
I tested a bunch of stuff, and I remember having a test case that failed
with a primitive type like int, but I can't find or recreate it now, and
a little googling suggests that reading/writing should be atomic for
primitive types (on X86 with various restrictions). So I probably just
had an error in that test.
But the above test case stands, and it also fails with -m32 and ulong:
alias T = ulong;
enum T a = 0x01_01_01_01__01_01_01_01;
enum T b = 0x02_02_02_02__02_02_02_02;
/* rest as above */
So, `shared int x; x = x + 1;` is ok, as far as I see now. But with
other types, unsafe reads/writes are generated.
Re: DIP1000: Scoped Pointers (Discussion)
On 11.08.2016 12:13, Walter Bright wrote:
On 8/11/2016 3:00 AM, deadalnix wrote:
This DIP is flawed because it only handle on
indirection level and break down for anything more than this.
It actually does two levels - the address of the pointer variable
('ref') and the contents of the pointer variable ('scope'). But you are
essentially correct. This is not a general annotation system for any
pointer in a non-trivial graph of pointers. There is no notion of
'borrowing'.
The question, however, is whether such a system is needed. The intent
with this DIP is for people constructing such graphs to make them safe
by using reference counted containers for the nodes rather than networks
of annotated raw pointers.
This scheme is good enough to prevent the escape of addresses on the
stack, and for containers to prevent the escape of pointers to their
contents.
Assuming all the soundness issues are fixed, I think the general scheme
it is not expressive enough. E.g. it does not allow lazy range
algorithms from std.algorithm and std.range to be used on a slice of
stack-allocated data. The selling points of a language are not real
selling points if they are mutually exclusive.
Reddit: bot disabled - please post manually
Just a short annoucement for the people who lost track r/d_language due to the bot: As an attempt to increase activity in this subreddit we want to try it without the bot for a while. Please announce relevant stuff from the forum (or blog or elsewhere) here manually from now on! In short idea is that bot kills active discussions as it creates ghost threads that are seldom commented on or watched. For a longer explanation see either [2, 3] or below: In fact it would be great to see the forum use reddit more actively for heated discussions as everyone can judge the value of a comment/thread and off-topic threads (or threads with low-values) get down-voted very quickly. It might also help to avoid such 50 pages threads (like auto-decoding) as the most-important thread stays on top and newcomers to the discussion don't have to read everything to get the gist and reduce the constant noise of off-topic comments or personal attacks on the NG. Another advantage is that discussions are sorted after their current important and not after the latest post. Of course there are some disadvantages too (e.g. 1) not all D members might like reddit, 2) it puts reddit "out-of-sync", 3) one can't repost outdated topics, and 4) we have to trust reddit that they accidentally delete our discussions), but I believe 1) isn't a big concern as we usually have active discussions on the reddit thread of announcements and this just about disabling the bot, 2) (out-of-sync) the NG is an essential part of the D language and as thus many people check it daily. Yes disabling the bot might put the people on reddit "out-of-sync" with the main NG, but I argue that they check the NG anyways and don't post here, because they know it's a dead copy - not the original thread. 3) (no ghost posts) is a good thing as it requires the reposter to think about reviving a thread from the dead & summarizing the gist, 4) (data security) reddit is a lot more unlikely to crash their servers. After all it's a company with full-time developers working on it - no offence to all the great people keeping the NG and it's forum interface up & running. [1] https://www.reddit.com/r/d_language/ [2] https://www.reddit.com/r/d_language/comments/4wr8v2/meta_bot_disabled_please_post_manually/ [3] https://www.reddit.com/r/d_language/comments/4vel7m/can_we_kill_the_dlang_bot_and_its_ghost_threads/
Re: Why D is not popular enough?
On 8/12/2016 12:14 PM, Shachar Shemesh wrote: On 12/08/16 22:07, Walter Bright wrote: On 8/12/2016 7:41 AM, Shachar Shemesh wrote: That table was not expensive to compute, and its constantness wasn't crucial enough even for me to put a wrapper pointer and only access it through it. Had that not been the case, and had that table been more expensive to computer, I'd probably compute at compile time with an external tool. What I do (and is done in building DMD) is write a program (optabgen.c) to generate the tables and write a C++ source file, then compile the generated file into DMD. Yes, I'm sorry. I meant to say "build time" instead of "compile time". That is precisely what I meant. I'm surprised that I've never seen anyone else use such a technique. It's so unusual I've seen it be unrepresentable in some 'make' replacements. I suppose it's like unittest and ddoc. Sure, you can do it with some contortions and/or some external tooling, but having it conveniently built in to the language changes everything.
Re: Why D is not popular enough?
On 8/12/2016 12:29 PM, Shachar Shemesh wrote: - No RAII support, despite the fact everybody here seems to think that D supports RAII. Please explain. - Recursive const makes many cases where I can use const in C++ (and enjoy the protection it provides) simply mutable in D. Right, in C++ you can have a const pointer to mutable. On the other hand, in C++ you cannot have 'const T' apply to what is accessible through T. - This one I have not complained about yet. Operator overloads stepping on each other's toes. In my case, I have a container (with opIndex that accepts a custom type and opOpAssign!"~") and I place in it a struct with some operator overloads as well (have not reduced the cause yet, hence no previous complaint about this one). So, when I write Container[IndexType] ~= Type; And the compiler assumes that means: Container.opIndexOpAssign!"~"(IndexType, Type); but since nothing like that is defined, the code doesn't compile. I ended up writing (actual code from the Weka code base): blockIds[diskIdx].opOpAssign!"~"(makeBlockId(stripeIdx+i, placement.to!SlotIdx(diskIdx))); Took me almost ten minutes and consulting someone else to find this solution. - GC. GC. GC. Some more GC. - Integral type operations promotion and the constant need for casts. I don't understand this. Integral type promotions are the same as in C++. The casts are needed for integral type demotions (i.e. narrowing conversions). Having implicit narrowing conversions in C++ is a significant source of bugs, as the most significant bits are silently discarded. - No warning for signed/unsigned comparisons. An unfailing source for bugs. Understood, but to be pedantic, such warnings are extensions to C++ compilers, not part of the language. - No ref type. D has the ref storage class. What difference are you seeing?
Re: Why D is not popular enough?
On 12/08/16 22:55, Walter Bright wrote: > > I'm surprised that I've never seen anyone else use such a technique. > It's so unusual I've seen it be unrepresentable in some 'make' > replacements. > > I suppose it's like unittest and ddoc. Sure, you can do it with some > contortions and/or some external tooling, but having it conveniently > built in to the language changes everything. > Actually, even with it being easilly accessible in the compiler, there are sometimes reasons to still do it with an external tool. My next task at work requires precomputing a table. This might prove to be a quite intensive task, and the result will change quite rarely. Under those circumstances, I believe I will not wish to compute it each time the system is compiled, but to compute it when it changes and use a cached version. This means I still need a build rule for it, which means that if the build system does not support it, sucks to be me. Shachar
Re: Why D is not popular enough?
On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote: - Recursive const makes many cases where I can use const in C++ (and enjoy the protection it provides) simply mutable in D. FWIW HeadConst can be easily done in a library and will hopefully soon be in Phobos. https://github.com/dlang/phobos/pull/3862 Note that the reverse of having a easy to use recursive const in library code of C++ is not true.
Re: DIP1000: Scoped Pointers (Discussion)
On 8/12/2016 12:45 PM, Timon Gehr wrote: Assuming all the soundness issues are fixed, I think the general scheme it is not expressive enough. Possibly true, but general expressivity comes at a large cost in complexity and difficulty for users. E.g. it does not allow lazy range algorithms from std.algorithm and std.range to be used on a slice of stack-allocated data. If that does turn out to be a problem, lazy algorithms can detect it (because they won't compile) and use an eager version for such cases.
Re: DIP1000: Scoped Pointers (Discussion)
On 8/11/2016 1:53 AM, John Colvin wrote:
On Thursday, 11 August 2016 at 08:45:38 UTC, Walter Bright wrote:
On 8/11/2016 1:29 AM, John Colvin wrote:
Can someone talk me through the lifetime algebra for the following?
void foo()
{
int a;
int** c;
void bar()
{
int* b = &a; <= ok, b has a smaller lifetime than a
c = &b;<= error, c has a larger lifetime than b
}
bar();
*c; //undefined behaviour
}
but according to this rule:
"For an unrestricted pointer, visibility is dictated by the usual lexical scope
rules. Lifetime, however is dictated by the lifetime of the data to which the
pointer points to."
b should have the same lifetime as a, no?
When b is assigned the address of a, then the contents of b, as accessible
through b, have the lifetime of b.
Re: Why D is not popular enough?
On 8/12/2016 11:34 AM, Jonathan M Davis via Digitalmars-d wrote: It does not surprise me in the least if there are bugs related to shared in the compiler, and we definitely don't deal with it properly in druntime with regards to stuff like Mutex and Condition. But I don't agree with the idea that shared is fundamentally broken. I'd put it more as being largely unimplemented. However, it still works as separating by type data that is shared vs data that is local, and that is still immensely valuable. Also, one thing at a time. Scope has been largely unimplemented forever, and this DIP intends to fix that.
Why was that min() call in sort?
I might be missing something, could y'all take a look? https://github.com/dlang/phobos/pull/4725. Thx! -- Andrei
Re: DIP1000: Scoped Pointers (Discussion)
On 8/12/2016 12:34 PM, Timon Gehr wrote: This proposes to add a kind of information the type system is supposed to track (lifetimes), which cannot be communicated losslessly across function and aggregate boundaries. Hence it won't work well in its current form. I believe it does track across function boundaries, because function parameters can be annotated. Aggregate boundaries, no, because annotating fields with 'scope' is not allowed, like 'ref' fields are not allowed.
Re: DIP1000: Scoped Pointers (Discussion)
On 08/12/2016 03:34 PM, Timon Gehr wrote: On 10.08.2016 22:36, Dicebot wrote: http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org The first DIP has just landed into the new queue. It is a proposal from language authors and thus it bypasses usual nitpicking process and proceeds straight to requesting community (your!) feedback. Essentially, it is an attempt to solve reference lifetime problem by extending implementation of `scope` keyword. Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md This proposes to add a kind of information the type system is supposed to track (lifetimes), which cannot be communicated losslessly across function and aggregate boundaries. Hence it won't work well in its current form. Could it work in a restricted manner, yet permissive enough to be useful? -- Andrei
Re: [OT] The coolest (literally) desktop machine I've ever had
On Friday, 12 August 2016 at 19:13:12 UTC, Andrei Alexandrescu wrote: Thought this might help others looking for a fanless dekstop. I built fanless desktops that I use for HTPC. I find it's much easier to just find a fanless heat sink and choose the parts for the rest of the machine based on that.
Re: DIP1000: Scoped Pointers (Discussion)
On 12.08.2016 22:22, Andrei Alexandrescu wrote: On 08/12/2016 03:34 PM, Timon Gehr wrote: On 10.08.2016 22:36, Dicebot wrote: http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org The first DIP has just landed into the new queue. It is a proposal from language authors and thus it bypasses usual nitpicking process and proceeds straight to requesting community (your!) feedback. Essentially, it is an attempt to solve reference lifetime problem by extending implementation of `scope` keyword. Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md This proposes to add a kind of information the type system is supposed to track (lifetimes), which cannot be communicated losslessly across function and aggregate boundaries. Hence it won't work well in its current form. Could it work in a restricted manner, yet permissive enough to be useful? -- Andrei The issue is that there is information that the type system tracks that cannot be passed around effectively at the type system level. This generally leads to a painful "fighting-the-compiler" experience when trying to use the feature in a not-completely-trivial capacity (c.f. inout, it is also a case of this). I think users of the language generally expect features to compose. So even if it is useful for the handful of special cases it was designed for, there will be a lot of complaints.
Re: DIP1000: Scoped Pointers (Discussion)
On 12.08.2016 22:22, Walter Bright wrote: On 8/12/2016 12:34 PM, Timon Gehr wrote: This proposes to add a kind of information the type system is supposed to track (lifetimes), which cannot be communicated losslessly across function and aggregate boundaries. Hence it won't work well in its current form. I believe it does track across function boundaries, because function parameters can be annotated. ... Yes, to some extent, but what the type system knows and makes use of at the call site is more informative than what can be tracked around function boundaries. The effect is that there are pieces of code that cannot be abstracted into their own functions, which creates friction. Aggregate boundaries, no, because annotating fields with 'scope' is not allowed, like 'ref' fields are not allowed. This rules out structs that wrap data and adapt it in some interesting way, a very common idiom in (generic) D code.
Re: Why D is not popular enough?
On 08/12/2016 02:29 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Aug 12, 2016 at 02:21:04PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
On 08/12/2016 02:01 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
Honestly, I don't think that shared is broken.
Yes. It is broken.
shared int x;
++x; // error, must use atomicOp.
x = x + 1; // OK(!)
How is this broken and how should it behave? -- Andrei
?!
Isn't it obvious that assigning to a shared int must require
atomicOp or a cast? `x = x + 1;` clearly has a race condition
otherwise.
It is not to me, and it does not seem like a low-level race condition
to me (whereas ++x is).
The problem is that the line between "low-level" and "high-level" is
unclear and arbitrary.
I'd need to think a bit before agreeing or disagreeing, but it's a
plausible take. In this case fortunately, the matters can be distinguished.
Doesn't ++x lower to x = x + 1 on some CPUs
anyway (or vice versa, if the optimizer decides to translate it the
other way)?
This doesn't matter. The question is what is explicit and what is
implicit in the computation.
++expr
is a RMW ("read-modify-write") expression, equivalent to:
((ref x) => { return x = cast(typeof(x)) (x + 1); })(expr)
In contrast,
expr1 = expr2 + 1
is an expression consisting of distinct read and write, both under the
control of the code written by the programmer. As I explained,
distinguishing in the general case when expr1 and expr2 refer to the
same memory location is not doable statically. So it stands to reason
that the compiler generates the code for one read and one write because
that is literally what it has been asked to do.
It may actually be the case that one wants to do x = x + 1 and exercise
a benign high-level race.
Why should the user have to worry about such details?
What details are you referring to, and how would compiler technology
help with those?
Wouldn't that make shared kinda useless to begin with?
It doesn't seem that way.
Currently the compiler must ensure that an atomic read and an atomic
write are generated for x. Other than that, it is the responsibility
of the user. The use of "shared" does not automatically relieve the
user from certain responsibilities.
I agree that it would be nice to have stronger protection against
higher-level bugs, but those are outside the charter of "shared".
Consider:
x = *p + 1;
How would the compiler reject the right uses but not the case when p
== &x?
[...]
The compiler should reject it (without the appropriate casts) if p has a
shared type, and the aliasing situation with x is unknown / unclear.
I think you are not right here.
Andrei
Re: Why D is not popular enough?
On 08/12/2016 03:55 PM, Walter Bright wrote: On 8/12/2016 12:14 PM, Shachar Shemesh wrote: On 12/08/16 22:07, Walter Bright wrote: On 8/12/2016 7:41 AM, Shachar Shemesh wrote: That table was not expensive to compute, and its constantness wasn't crucial enough even for me to put a wrapper pointer and only access it through it. Had that not been the case, and had that table been more expensive to computer, I'd probably compute at compile time with an external tool. What I do (and is done in building DMD) is write a program (optabgen.c) to generate the tables and write a C++ source file, then compile the generated file into DMD. Yes, I'm sorry. I meant to say "build time" instead of "compile time". That is precisely what I meant. I'm surprised that I've never seen anyone else use such a technique. It's a matter of frequenting the appropriate circles. The technique is in wide use. Andrei
Re: Why D is not popular enough?
On 08/12/2016 04:06 PM, Shachar Shemesh wrote:
On 12/08/16 22:55, Walter Bright wrote:
I'm surprised that I've never seen anyone else use such a technique.
It's so unusual I've seen it be unrepresentable in some 'make'
replacements.
I suppose it's like unittest and ddoc. Sure, you can do it with some
contortions and/or some external tooling, but having it conveniently
built in to the language changes everything.
Actually, even with it being easilly accessible in the compiler, there
are sometimes reasons to still do it with an external tool.
My next task at work requires precomputing a table. This might prove to
be a quite intensive task, and the result will change quite rarely.
Under those circumstances, I believe I will not wish to compute it each
time the system is compiled, but to compute it when it changes and use a
cached version.
I wonder if you can arrange things such that a compile-time table is
computed only upon a change in the source file. I mean:
// table.di
extern double[] table;
// table.d
double[] table = makeComplicatedTable();
double[1024] makeComplicatedTable() {
... compile-time computation ...
}
People use the interface file table.di. The complicated computation goes
in table.o which is generated only when table.d is changed.
Andrei
Re: DIP1000: Scoped Pointers (Discussion)
On 08/12/2016 04:58 PM, Timon Gehr wrote: On 12.08.2016 22:22, Andrei Alexandrescu wrote: On 08/12/2016 03:34 PM, Timon Gehr wrote: On 10.08.2016 22:36, Dicebot wrote: http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org The first DIP has just landed into the new queue. It is a proposal from language authors and thus it bypasses usual nitpicking process and proceeds straight to requesting community (your!) feedback. Essentially, it is an attempt to solve reference lifetime problem by extending implementation of `scope` keyword. Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md This proposes to add a kind of information the type system is supposed to track (lifetimes), which cannot be communicated losslessly across function and aggregate boundaries. Hence it won't work well in its current form. Could it work in a restricted manner, yet permissive enough to be useful? -- Andrei The issue is that there is information that the type system tracks that cannot be passed around effectively at the type system level. This generally leads to a painful "fighting-the-compiler" experience when trying to use the feature in a not-completely-trivial capacity (c.f. inout, it is also a case of this). I think users of the language generally expect features to compose. So even if it is useful for the handful of special cases it was designed for, there will be a lot of complaints. Can you please give examples of cases that are (a) unlikely to be supported with reasonable effort, and (b) likely to cause problems in usability? Thanks! -- Andrei
Re: Why D is not popular enough?
On 08/12/2016 09:41 PM, ag0aep6g wrote:
So, `shared int x; x = x + 1;` is ok, as far as I see now. But with
other types, unsafe reads/writes are generated.
Missing alignment can also throw the compiler off:
alias T = int;
enum T a = 0x01_01_01_01;
enum T b = 0x02_02_02_02;
struct S
{
byte[13] padding;
align(1) T x = a;
}
shared S s;
import core.thread: Thread;
void write()
{
bool flip = false;
foreach (i; 0 .. 1_000_000)
{
if (flip) s.x = a; else s.x = b;
flip = !flip;
}
}
void main()
{
auto t = new Thread(&write);
t.start();
foreach (i; 0 .. 1_000_000)
{
T r = s.x;
assert(r == a || r == b); // fails
}
t.join();
}
Re: Why D is not popular enough?
On 8/12/16 2:04 PM, Andrei Alexandrescu wrote: On 08/12/2016 01:21 PM, Steven Schveighoffer wrote: On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote: Honestly, I don't think that shared is broken. Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!) How is this broken and how should it behave? -- Andrei It's broken because it's inconsistent. If the compiler is going to complain about races in one case, but not in other equivalent cases, then the feature is useless. If all I have to do to avoid compiler complaints is rewrite my expression in an equivalent way, then what is the point of the complaint? At that point, it's just a style guide. What should it do? If I knew that, then I'd have proposed a DIP by now. It's not an easy problem to solve. I don't think you can "solve" races because the compiler can't see all interactions with data. At first glance, it seems that shared data shouldn't be usable without some kind of explicit usage syntax. x = x + 1 is too innocuous looking. It's not going to "solve" the issue, but it makes the code easier to pick out. -Steve
Re: Why D is not popular enough?
On 8/12/16 6:58 PM, Steven Schveighoffer wrote: On 8/12/16 2:04 PM, Andrei Alexandrescu wrote: On 08/12/2016 01:21 PM, Steven Schveighoffer wrote: On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote: Honestly, I don't think that shared is broken. Yes. It is broken. shared int x; ++x; // error, must use atomicOp. x = x + 1; // OK(!) How is this broken and how should it behave? -- Andrei It's broken because it's inconsistent. If the compiler is going to complain about races in one case, but not in other equivalent cases, then the feature is useless. But ++expr and expr1 = expr1 + expr2 are fundamentally different. If all I have to do to avoid compiler complaints is rewrite my expression in an equivalent way, then what is the point of the complaint? At that point, it's just a style guide. A bunch of rewrites to seemingly identical behavior to avoid type errors are de rigoeur in so many situations. This is no different. What should it do? If I knew that, then I'd have proposed a DIP by now. It's not an easy problem to solve. I don't think you can "solve" races because the compiler can't see all interactions with data. ++expr contains a low-level race that is worth removing. Extending that to a variety of sub-patterns of expr1 = expr2 + expr3 seems a terrible idea to me. At first glance, it seems that shared data shouldn't be usable without some kind of explicit usage syntax. x = x + 1 is too innocuous looking. It's not going to "solve" the issue, but it makes the code easier to pick out. We discussed this at a point (some 10 years ago). It was: atomicReadRef(x) = atomicRead(x) + 1; But it's painfully obvious that yes the intent is to read the address and read the thing... so why need these anyway? So we left things as they are. I agree shared needs work, but this is not it. We're wasting our time here. Andrei
Re: DIP1000: Scoped Pointers (Discussion)
On 8/12/2016 2:03 PM, Timon Gehr wrote:
On 12.08.2016 22:22, Walter Bright wrote:
I believe it does track across function boundaries, because function
parameters can be annotated.
Yes, to some extent, but what the type system knows and makes use of at the call
site is more informative than what can be tracked around function boundaries.
The effect is that there are pieces of code that cannot be abstracted into their
own functions, which creates friction.
I don't understand your comment.
Aggregate boundaries, no, because annotating fields with 'scope' is not
allowed, like 'ref' fields are not allowed.
This rules out structs that wrap data and adapt it in some interesting way, a
very common idiom in (generic) D code.
Consider:
struct S { int* a, b; }
int x;
S s;
s.a = &x;
should be semantically equivalent, as far as scope rules go, to:
int x;
int* a;
a = &x;
(Note that 'scope' is inferred here.)
What would not work is:
int x;
S* ps = new S;
ps.a = &x;
Re: [OT] The coolest (literally) desktop machine I've ever had
On Friday, 12 August 2016 at 19:13:12 UTC, Andrei Alexandrescu wrote: At about the time I was ready to give up I found an obscure site of an Israeli company that claimed to make a real i7 fanless machine. It was releases very recently, too, so I'm thinking it might be of interest to some others. Compulab is pretty well-known among hardware enthusiasts, as they're pretty much the only company putting out ARM desktops: http://www.phoronix.com/scan.php?page=article&item=compulab_utilite&num=1 They seem to have focused more on the fanless x86 nettops these days.
