Re: Just found this debugger...
On Wednesday, 3 October 2018 at 23:51:38 UTC, tide wrote: On Wednesday, 3 October 2018 at 13:20:03 UTC, JN wrote: On Wednesday, 3 October 2018 at 03:25:04 UTC, solidstate1991 wrote: Then I had a thought: Is there anything usable on the market besides these? It may not be enough for your needs, but VSCode C++ debugger somewhat works for D. I can't set breakpoints, but stepping through code works and watches also work for most simple types. Enable the setting in your user/workspace: // Allow setting breakpoints in any file. "debug.allowBreakpointsEverywhere": true, I'll give it a try. Stuff like that should be added to Debuggers wiki I guess. Right now it's full of some outdated out-of-IDE debuggers that barely anyone uses nowadays.
Re: Deep nesting vs early returns
On Tuesday, 2 October 2018 at 18:14:55 UTC, Andrei Alexandrescu
wrote:
Kate Gregory makes a good argument on something I've often
commented in code reviews: https://youtu.be/n0Ak6xtVXno?t=2682
Thank you Andrei for mentioning this. I always had this question
of which one to choose - early return or nesting.
But the idea of 'early return' leads to multiple return
statements too (for separate return conditions), right?
Certain people recommend that there be only one return statement
(usually at the end) from a function. The said advantage is
that, in a maintenance code, if you later want to do something
before returning, you can add it just above the return statement.
I have seen people enclosing the function logic inside a
while(1) merely to stick on to single return at the end.
while(1)
{
...
break; //otherwise return would come here.
...
break;
}
return ...;
I (no expert) still don't have clear idea about the multiple
return statements scattered inside a function. So, I return
where ever I want to return. And, I use your C++ ScopeGuard to
do that extra thing that is supposed to be done before returning
( from your article
http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/184403758 )
Any advices?
Re: DIP 1014
On Wed, Oct 3, 2018 at 11:00 PM Timothee Cour via Digitalmars-d wrote: > > @Manu, @Jonathan M Davis > > > GNU's std::string implementation stores an interior pointer! >_< > > it's not just GNU's std::string ; it can crop up in other places, see > https://github.com/Syniurge/Calypso/issues/70 in opencv (cv:: MatStep) Sure. Certainly, it shows up in C++ fairly often... but I'm working on the STL containers, and I didn't think there were any implementations that did that (because inefficient use of space), but turns out the GNU implementation bent me over, at least as far as I've encountered yet. It's kinda got me stuck.
Re: DIP 1014
@Manu, @Jonathan M Davis > GNU's std::string implementation stores an interior pointer! >_< it's not just GNU's std::string ; it can crop up in other places, see https://github.com/Syniurge/Calypso/issues/70 in opencv (cv:: MatStep) On Wed, Oct 3, 2018 at 8:10 PM Shachar Shemesh via Digitalmars-d wrote: > > On 03/10/18 23:25, Stanislav Blinov wrote: > > It *is* true when the type doesn't have a destructor. Extending that to > > a move hook, it will also be true because destruction will be elided. > > I know what you're talking about, that happens for types that have > > destructors. > > No, destructors have nothing to do with it, as well they shouldn't. The > whole point of D moving structs around is that no destruction is needed. > It took me a while to figure out why your program does appear to work. > At first I thought it was because of inlining, but that was wrong. > > The reason your test case works (sometimes, if you don't breath on it > too heavily) is because the object is actually moved twice. Once when > returning from the function into the variable, and another when copied > into opAssign's argument. This results in it returning to its original > address. > > If you do *anything* to that program, and that includes even changing > its compilation flags (try enabling inlining), it will stop working. > > You should have known that when you found out it doesn't work on ldc: > ldc and dmd use the same front-end. If you think something works > fundamentally different between the two, you are probably wrong. > > To verify my guess is right, I tried the following change: add to > createCounter and createCounterNoNRV in your original program (no > destructors) the following two lines: >int a; >write(a); > > You have added another local variable to the functions, but otherwise > changed absolutely nothing. You will notice your program now has an offset. > > Shachar
Re: DIP 1014
On 03/10/18 23:25, Stanislav Blinov wrote: It *is* true when the type doesn't have a destructor. Extending that to a move hook, it will also be true because destruction will be elided. I know what you're talking about, that happens for types that have destructors. No, destructors have nothing to do with it, as well they shouldn't. The whole point of D moving structs around is that no destruction is needed. It took me a while to figure out why your program does appear to work. At first I thought it was because of inlining, but that was wrong. The reason your test case works (sometimes, if you don't breath on it too heavily) is because the object is actually moved twice. Once when returning from the function into the variable, and another when copied into opAssign's argument. This results in it returning to its original address. If you do *anything* to that program, and that includes even changing its compilation flags (try enabling inlining), it will stop working. You should have known that when you found out it doesn't work on ldc: ldc and dmd use the same front-end. If you think something works fundamentally different between the two, you are probably wrong. To verify my guess is right, I tried the following change: add to createCounter and createCounterNoNRV in your original program (no destructors) the following two lines: int a; write(a); You have added another local variable to the functions, but otherwise changed absolutely nothing. You will notice your program now has an offset. Shachar
Re: `shared`...
On 10/3/2018 1:33 AM, Atila Neves wrote: I'm confused. Given how the lifetimes of aggregates are defined in DIP1000, and also given that I tried to escape members of a struct when I wrote fearless and the compiler didn't let me, I'm trying to understand in what situation scope doesn't apply transitively. for 'scope T**' the scope applies to the T**, but not to the T*.
Re: Just found this debugger...
On Wednesday, 3 October 2018 at 13:20:03 UTC, JN wrote: On Wednesday, 3 October 2018 at 03:25:04 UTC, solidstate1991 wrote: Then I had a thought: Is there anything usable on the market besides these? It may not be enough for your needs, but VSCode C++ debugger somewhat works for D. I can't set breakpoints, but stepping through code works and watches also work for most simple types. Enable the setting in your user/workspace: // Allow setting breakpoints in any file. "debug.allowBreakpointsEverywhere": true,
Re: Move semantics, D vs. C++, ABI details
On Wednesday, 3 October 2018 at 20:57:39 UTC, kinke wrote: For DIP 1014, we (at least LDC) would most likely need to adopt the C++ ABI in this regard, i.e., always pass non-PODs by reference Which would also help with C++ interop of course - while LDC's extern(C++) ABI was fixed wrt. passing all non-PODs by reference, the different destruction rules are still an issue (no destruction when calling a C++ function from D, and double destruction when calling an extern(C++) D function from C++).
Move semantics, D vs. C++, ABI details
This is an attempt to clarify some of the recent confusion wrt.
DIP 1014, Walter's statement that DMD wouldn't move structs etc.
My understanding of the terminology:
* D moving: copy bits to another memory location, skipping
postblit for the
moved-to object & skipping destruction of the moved-from object
* C++ moving: moved-to object constructed via special constructor
hijacking
the moved-from object's data and resetting the moved-from
object for safe
destruction (no double-free etc.)
More interesting are the following low-level ABI differences. No
guarantees for completeness/absolute correctness from my side
(but I've worked on LDC's ABI implementations).
C++11:
1) Non-POD by-value arguments are passed by reference,
low-level-wise,
and never on the stack or in registers.
2) The argument/parameter is allocated on the caller's stack and
destructed
by the caller after the call.
struct S
{
S(int) {} // ctor
S(const S&) {} // copy ctor
S(S&&) {} // move ctor
~S() {}// dtor
};
void foo(S);
void bar()
{
// 1) passing an rvalue
foo(S(123));
/* =>
* S tmp(123); // construct temporary
* foo(&tmp); // pass the temporary directly by ref, no move
ctor involved
* tmp.~S(); // destruct it after the call
*/
// 2) passing an lvalue
S lval(456);
foo(lval);
/* =>
* S tmp(lval); // construct temporary via copy ctor
* foo(&tmp); // pass the temporary directly by ref
* tmp.~S();// destruct it after the call
*/
// 3) using std::move
foo(std::move(lval));
/* =>
* S tmp(std::move(lval)); // construct temporary via move
ctor (possibly mutating lval)
* foo(&tmp); // pass the temporary by ref
* tmp.~S(); // destruct it after the call
*/
}
D:
1) Non-POD by-value arguments are passed by value, i.e., on the
stack
[or in registers].
2) The callee destructs the parameter; the caller doesn't perform
any
cleanup/destruction after the call.
struct S
{
this(int) {} // ctor
this(this) {} // postblit
~this() {}// dtor
}
void foo(S);
void bar()
{
// 1) passing an rvalue
foo(S(123));
/* =>
* S tmp = S(123); // construct temporary
* foo(tmp); // pass the temporary by value, i.e., move
* // to foo params stack (copy bits, no
postblit call)
* // foo() will destruct its param (moved-to object)
* // destruction of tmp is skipped (no need to reset to
S.init)
*/
// 2) passing an lvalue
S lval = S(456);
foo(lval);
/* =>
* S tmp = lval; // construct temporary by bitcopy + postblit
call
* foo(tmp); // pass the temporary by value, see rvalue
case
* // foo() will destruct its param & tmp's dtor is disabled
(in the AST)
*/
}
D's rvalue case (explicit temporary + move to params stack) is
how LDC handles it to satisfy LLVM IR (before optimization);
other compilers might emplace the argument directly in the
parameters stack.
For DIP 1014, we (at least LDC) would most likely need to adopt
the C++ ABI in this regard, i.e., always pass non-PODs by
reference - AFAIK, the LLVM IR doesn't provide the means to get
the final address of the (moved-to) parameter in the callee's
parameter stack, inside the caller's scope (required for the
proposed postmove call), with whatever that entails (don't
disable dtor for lvalue copies in AST, destruct the temporaries
after the call in a finally block if the callee potentially
throws etc.).
Re: DIP 1014
On Wednesday, 3 October 2018 at 18:58:37 UTC, Shachar Shemesh wrote: On 03/10/18 20:43, Stanislav Blinov wrote: On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh wrote: I.e. - I am asserting if a move was not caught. The program fails to run on either ldc or dmd. To me, this makes perfect sense as for the way D is built. In essence, opAssign isn't guaranteed to run. Feel free to build a struct where that assert passes to convince me. That's a slightly different issue here. Well, I view this issue as a deal breaker. If you need to move the object *in order* to pass it to your move hook, then anything that requires knowing the address of the old instance will, by definition, not work. I feel like we're still not on the same page here. this(typeof(this)) doesn't work like a move hook in D right now. I'm *suggesting* making that be a move ctor, instead of opPostMove from your DIP (see below). Look at the output. The operator is being run, it can't *not* run, Sure it can. Just look at the example I posted on the other thread (https://forum.dlang.org/post/pp2v16$1014$1...@digitalmars.com). The hook you mention is downright @disabled there. In fact, had that not been the case, this DIP would never have happened. Yup, we're definitely not on the same page :) That's not what I'm talking about at all. Here is the flaw in your logic: void opAssign(Tracker rhs) rhs is passed by value. This means that already at the point opAssign is called, rhs *already* has a different address than the one it was passed in with. Currently that is only true if you define a destructor. No, that's not true. Try printing the instance's address in the constructor and again in your operator. It *is* true when the type doesn't have a destructor. Extending that to a move hook, it will also be true because destruction will be elided. I know what you're talking about, that happens for types that have destructors. In the presence of a move hook, 'rhs' would first have to pass through that hook, which will not take destructors into account at all. I'm sorry, I'm not following. What is the difference between what you're proposing and opPostMove as defined? 1. with this(typeof(this)) the type of argument would never change. With opPostMove, it may. Remember that 'is(Tracker == const(Tracker))' is false. 2. you won't have to always move all the bits unconditionally. 3. symmetry with this(this) This is the run I got: $ ./movetest2 Address of temporary is 'b382e390', counter points to 'b382e390' ... which is '0' bytes from the address of temporary. ...I'm not sure what I should have seen, or what I should have concluded from it. This is your original program, unmodified. This illustrates the intended behavior of a move hook if it existed in the language. The 'rhs' that was passed to the call was constructed at that same address (&rhs.counter == &rhs.localCounter). I.e. this is how I'm suggesting a this(typeof(this)) *could* work. this(typeof(this)), of course, would need to be special in the ABI, but again, that's one special function instead of two. No. My proposal requires one amendment to argument passing in the ABI, but no special cases at all. Changes to the ABI are not the same as changes to the run time library. How so? Or, more to the point, what's argument passing OR runtime have to do with this? Let's take a step back for a moment and look at what should actually be happening for this hook to work (which you briefly mention in the DIP): 1. The compiler constructs the value. In your case, it constructs two: It does not. It copies the bits from one to the other. Poor choice of words on my part. It *creates* two. Whereas with this(typeof(this)) no implicit copying of bits is required, a-la a C++ move constructor. The programmer is free to choose the bits they need, or do a blit-and-patch if so desired. Except that unlike a C++ move constructor, no state bookkeeping would be necessary (same is true with your DIP as is). the original and the new one. In my case, it constructs the original and then passes it over to the move ctor (one blit potentially avoided). 2. It calls the hook (move ctor). I'm not sure I follow you on that one. What did you mean? In your case, that would be when it calls __move_post_blt. 3. In your case, it calls the opPostMove. In all cases, you need to call the hook, whatever it is, for those structs that have it, and do some default handling for those that don't. Correct, which would just be whatever the compilers already do. 4. In any case, it *doesn't* destruct the original. Ever. The alternative would be to force the programmer to put the original back into valid state, and suddenly we're back to C++ with all it's pleasantries. That last part is quite different from the current model, in which the compiler always destructs function arguments. That's why my example fails when a de
Re: DIP 1014
On Wednesday, 3 October 2018 at 18:38:50 UTC, Manu wrote: On Wed, Oct 3, 2018 at 7:00 AM Stanislav Blinov via Digitalmars-d wrote: Any function in D that has a signature of the form ReturnType foo(Type x); in C++ would have an equivalent signature of ReturnType foo(Type&& x); // NOT ReturnType foo(Type x); What are you talking about? Equivalent C++ is: ReturnType foo(Type x); C++ has rvalue references, move semantics are explicit. D doesn't have any of that. Perhaps I wasn't quite clear in that above statement though. Given some type Bar, compare these two calls in C++ in D, and tell me, which signature in C++ should correspond to D? I'm not talking about ABI, I'm talking about semantics. foo(std::move(bar)); // C++ foo(move(bar)); // D remembering that D's move() doesn't call postblit. void foo(Bar bar) wouldn't satisfy that last bit, would it? Yes, the semantics are different, as in D the move occurs before the call. But in D right now you *must* assume that the argument may have been moved, with all the consequences the language currently entails (and some of which the DIP attempts to resolve), whereas in C++ you can be explicit about it via overloading for rvalue references. It's impossible to perform copy elision when passing an lvalue by-value *to* a function, but that's a case where you depend on move semantics. Of course it's impossible. I'm not sure I understand your point here. Also, within the function that receives an argument by value, you depend on move to construct something with that argument. Type&& passes a reference, which means you can perform the move direct from source to destination, without a stop at the middle man. Yup, no argument there.
Re: Please don't do a DConf 2018, consider alternatives
On Wednesday, 3 October 2018 at 18:46:02 UTC, Joakim wrote: Except that you can also view the videos at home, then discuss them later at a conference, which is the actual suggestion here. Maybe that would work better with a smaller group? I imagine some people are too busy to do that beforehand. Another thing that might work would be to have everybody read through the presentations beforehand and then just have questions. That doesn't work so well when there are live code examples though.
Re: DIP 1014
On 03/10/18 20:43, Stanislav Blinov wrote: On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh wrote: I.e. - I am asserting if a move was not caught. The program fails to run on either ldc or dmd. To me, this makes perfect sense as for the way D is built. In essence, opAssign isn't guaranteed to run. Feel free to build a struct where that assert passes to convince me. That's a slightly different issue here. Well, I view this issue as a deal breaker. If you need to move the object *in order* to pass it to your move hook, then anything that requires knowing the address of the old instance will, by definition, not work. Look at the output. The operator is being run, it can't *not* run, Sure it can. Just look at the example I posted on the other thread (https://forum.dlang.org/post/pp2v16$1014$1...@digitalmars.com). The hook you mention is downright @disabled there. In fact, had that not been the case, this DIP would never have happened. Here is the flaw in your logic: void opAssign(Tracker rhs) rhs is passed by value. This means that already at the point opAssign is called, rhs *already* has a different address than the one it was passed in with. Currently that is only true if you define a destructor. No, that's not true. Try printing the instance's address in the constructor and again in your operator. In the presence of a move hook, 'rhs' would first have to pass through that hook, which will not take destructors into account at all. I'm sorry, I'm not following. What is the difference between what you're proposing and opPostMove as defined? Consider your own DIP: what you're suggesting is the ability to take the address of the original when a move is taking place. My example shows that in the simplest case even today, address of the original is already the address of the argument. This is the run I got: $ ./movetest2 Address of temporary is 'b382e390', counter points to 'b382e390' ... which is '0' bytes from the address of temporary. Address of temporary is 'b382e390', counter points to '8eb82b60' ... which is '-966984906800' bytes from the address of temporary. Address of temporary is 'b382e390', counter points to 'b382e390' ... which is '0' bytes from the address of temporary. Address of temporary is 'b382e390', counter points to '8eb82b60' ... which is '-966984906800' bytes from the address of temporary. I'm not sure what I should have seen, or what I should have concluded from it. This is your original program, unmodified. The changes are literally the same as the ones you're proposing: "When moving a struct's instance, the compiler MUST call __move_post_blt giving it both new and old instances' addresses." That is the same that would have to happen with this(typeof(this) rhs), where &this is the address of new instance, and &rhs is the address of old instance, but there's no need for opPostMove then. I guess what I should've said from the start is that the semantics you're proposing fit nicely within one special function, instead of two. Except, like I said, it's not working for me, and I find it hard to understand how it *can* work (inlining notwithstanding), which is why I did not propose it. this(typeof(this)), of course, would need to be special in the ABI, but again, that's one special function instead of two. No. My proposal requires one amendment to argument passing in the ABI, but no special cases at all. Changes to the ABI are not the same as changes to the run time library. Let's take a step back for a moment and look at what should actually be happening for this hook to work (which you briefly mention in the DIP): 1. The compiler constructs the value. In your case, it constructs two: It does not. It copies the bits from one to the other. This also means that a struct where some of its members have a hook is copied wholesale and patched, which is typically faster than copying in parts. the original and the new one. In my case, it constructs the original and then passes it over to the move ctor (one blit potentially avoided). 2. It calls the hook (move ctor). I'm not sure I follow you on that one. What did you mean? 3. In your case, it calls the opPostMove. In all cases, you need to call the hook, whatever it is, for those structs that have it, and do some default handling for those that don't. 4. In any case, it *doesn't* destruct the original. Ever. The alternative would be to force the programmer to put the original back into valid state, and suddenly we're back to C++ with all it's pleasantries. That last part is quite different from the current model, in which the compiler always destructs function arguments. That's why my example fails when a destructor is present. Like I said above, I don't think that's correct. The other thing to note (again something that you mention but don't expand on), and that's nodding back to my comment about making move() and empl
Re: Please don't do a DConf 2018, consider alternatives
On Wednesday, 3 October 2018 at 17:51:00 UTC, Russel Winder wrote: On Wed, 2018-10-03 at 17:26 +, Joakim via Digitalmars-d wrote: […] At least look at the first two bullet points in my post responding to Adam, because you're missing the entire point of my suggestions, which is that certain things like talks are better suited to online whereas conferences are more suited for in-person interaction. In your opinion. In my opinion, online material is a waste of time, I never watch YouTube videos, for me it is a waste of my time. But that is the point, different people have a different view. This doesn't mean I am right or wrong, it means different people have different ways of dealing with material. I like a live presentation that I can then ignore *or* take up with a gusto with the presenter, or other people, after the session. Conferences allow this. Presentations are an introduction to interaction with others. For me. Others prefer to consume videos and have no interactions about the material. Personal differences. Except that you can also view the videos at home, then discuss them later at a conference, which is the actual suggestion here. Since there is a population of people who like online stuff, then online stuff there must be. As there are people who like a live presentation and post session discussion, this must also happen. The two are not in conflict. They are in conflict because the cost of doing it live is much, much higher. DConf organizers' goal should be to enable the widest reach at the lowest cost, not catering to off-the-wall requests from a select few like yourself. I don't doubt that some are like you and prefer viewing live, but given how conferences keep dying off and online tech talks are booming, you're in an extreme minority that prefers that high-cost live version. That means the market inevitably stops catering to you, which is why the talk-driven conference format is dying off.
Re: DIP 1014
On Wed, Oct 3, 2018 at 7:00 AM Stanislav Blinov via Digitalmars-d
wrote:
>
> Shachar, as I don't see a better place of discussing that DIP at
> the moment, I'll pour some observations and thoughts in here if
> you don't mind, will add some comments on GitHub later.
> As I see it right now, it's a case of over-engineering of a quite
> simple concept.
>
> 1. A new function, called __move_post_blt, will be added to
> DRuntime.
>
> That's unnecessary, if not downright harmful for the language. We
> should strive to remove things from DRuntime, not add to it. The
> core language should deal with type memory, not a .so or dll. And
> it's extraneous, because...
>
> 2 and 3. onPostMove and __move_post_blt:
>
> They're unnecessary as well. All that's required is to allow a
> by-value constructor, e.g:
>
> struct S {
> this(S rhs);
> }
>
> Any function in D that has a signature of the form
>
> ReturnType foo(Type x);
>
> in C++ would have an equivalent signature of
>
> ReturnType foo(Type&& x); // NOT ReturnType foo(Type x);
What are you talking about? Equivalent C++ is:
ReturnType foo(Type x);
It's impossible to perform copy elision when passing an lvalue
by-value *to* a function, but that's a case where you depend on move
semantics.
Also, within the function that receives an argument by value, you
depend on move to construct something with that argument.
Type&& passes a reference, which means you can perform the move direct
from source to destination, without a stop at the middle man.
This all has nothing to do with Walter's surprising claim that "as the
DMD compiler doesn't actually move structs"... I'm still trying to
understand this statement.
Re: DIP 1014
On Wednesday, 3 October 2018 at 08:21:38 UTC, Manu wrote: Okay, so copy elision is working... but moves otherwise are not? That's still not what we've been peddling all these years. A whole lot of design surface area is dedicated to implicit move semantics... and they don't work? What does it do? postblit unnecessarily? No. The problem is that the language is under-specified. It is built on the *assumption* that no one ever should create self-referencing data. But it does not enforce that. Which eventually leads to someone trying to make such data and then run into a wall, or worse, a heisenbug. Thing is, there isn't anything wrong with self-referencing data per se. It's that the language plumbing should either disallow it wholesale (i.e. Rust) or allow a graceful way of handling it. Neither is present in D. The latter could be added though, that's what the DIP is about.
Re: Please don't do a DConf 2018, consider alternatives
On Wed, 2018-10-03 at 17:26 +, Joakim via Digitalmars-d wrote: […] > At least look at the first two bullet points in my post > responding to Adam, because you're missing the entire point of my > suggestions, which is that certain things like talks are better > suited to online whereas conferences are more suited for > in-person interaction. In your opinion. In my opinion, online material is a waste of time, I never watch YouTube videos, for me it is a waste of my time. But that is the point, different people have a different view. This doesn't mean I am right or wrong, it means different people have different ways of dealing with material. I like a live presentation that I can then ignore *or* take up with a gusto with the presenter, or other people, after the session. Conferences allow this. Presentations are an introduction to interaction with others. For me. Others prefer to consume videos and have no interactions about the material. Personal differences. Since there is a population of people who like online stuff, then online stuff there must be. As there are people who like a live presentation and post session discussion, this must also happen. The two are not in conflict. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: DIP 1014
On Wednesday, 3 October 2018 at 17:43:08 UTC, Stanislav Blinov wrote: But IMHO, it's something that should be fixed by not making these facilities built into the language. s/not//
Re: DIP 1014
On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh
wrote:
On 03/10/18 17:29, Stanislav Blinov wrote:
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
Now I see why sometimes your posts are greeted with hostility.
Yes. I am actually sorry about that. I was responding to your
assumption that I'm wrong. Had your post been phrased as "why
didn't you", instead of "you're wrong wrong wrong" I wouldn't
have responded that way.
Like I said, I am sorry.
I am sorry as well since I wasn't clear in my initial post.
> Allow me to further illustrate with something that can be
written in D > today:
I am not sure what you were trying to demonstrate, so instead I
wanted to see if you succeeded. I added the following to your
Tracker struct:
~this() {
writefln("%s destructed", &this);
assert(counter is null || counter is &localCounter);
}
I.e. - I am asserting if a move was not caught. The program
fails to run on either ldc or dmd. To me, this makes perfect
sense as for the way D is built. In essence, opAssign isn't
guaranteed to run. Feel free to build a struct where that
assert passes to convince me.
That's a slightly different issue here.
Look at the output. The operator is being run, it can't *not*
run, unlike postblit (ironically, right now it doesn't run on
fixed-size arrays though). In fact, as soon as you define a
destructor, the compiler will generate a by-value opAssign if you
haven't defined one.
That's a separate problem. Currently, presence of a destructor
makes the compilers generate different code, because it cannot
elide destruction of arguments, because explicit move semantics
do not exist in the language. That's why I haven't included a
destructor in the example to begin with.
Here is the flaw in your logic:
void opAssign(Tracker rhs)
rhs is passed by value. This means that already at the point
opAssign is called, rhs *already* has a different address than
the one it was passed in with.
Currently that is only true if you define a destructor. That
would not be true, however, if a move hook in any form existed in
the language. That was my point.
I only used opAssign as something resembling the supposed new
behavior, not as a "look, it already works". In the presence of a
move hook, 'rhs' would first have to pass through that hook,
which will not take destructors into account at all.
Consider your own DIP: what you're suggesting is the ability to
take the address of the original when a move is taking place. My
example shows that in the simplest case even today, address of
the original is already the address of the argument. Except it
cannot be enforced in any way right now. A move hook will have to
enforce that, as it will have to be called for every move.
I did not follow your logic on why this isn't so, but I don't
see how you can make it not so without changing the ABI quite
drastically.
The changes are literally the same as the ones you're proposing:
"When moving a struct's instance, the compiler MUST call
__move_post_blt giving it both new and old instances' addresses."
That is the same that would have to happen with this(typeof(this)
rhs), where &this is the address of new instance, and &rhs is the
address of old instance, but there's no need for opPostMove then.
I guess what I should've said from the start is that the
semantics you're proposing fit nicely within one special
function, instead of two.
this(typeof(this)), of course, would need to be special in the
ABI, but again, that's one special function instead of two.
Let's take a step back for a moment and look at what should
actually be happening for this hook to work (which you briefly
mention in the DIP):
1. The compiler constructs the value. In your case, it constructs
two: the original and the new one. In my case, it constructs the
original and then passes it over to the move ctor (one blit
potentially avoided).
2. It calls the hook (move ctor).
3. In your case, it calls the opPostMove.
4. In any case, it *doesn't* destruct the original. Ever. The
alternative would be to force the programmer to put the original
back into valid state, and suddenly we're back to C++ with all
it's pleasantries.
That last part is quite different from the current model, in
which the compiler always destructs function arguments. That's
why my example fails when a destructor is present.
The other thing to note (again something that you mention but
don't expand on), and that's nodding back to my comment about
making move() and emplace() intrinsics, is that creating such a
hook *will* invalidate current behavior of move(). Which is
perhaps more easily fixed with your implementation, actually,
*except* for the part about eliding destruction. Unions are
unreliable for that unless we also change the spec that talks
about them.
But IMHO, it's something that should be fixed by not making these
facilities built into the
Re: DIP 1014
On 03/10/18 12:48, Corel wrote:
The fact that in D the structures to date are not moved, is known for
years ... take advantage of this fact, and move on.
I have no idea where you got this fact:
import std.stdio;
struct MoveTest {
static uint counter=1;
uint id;
@disable this(this);
@disable this(MoveTest);
this(uint dummy) {
id = counter++;
writefln("Constructed %s id %s", &this, id);
}
~this() {
writefln("Id %s destroyed at %s", id, &this);
}
}
MoveTest func1() {
return MoveTest(3);
}
void func2(MoveTest m) {
}
int main() {
func2(func1());
return 0;
}
$ rdmd movetest.d
Constructed 7FFDC7A663E0 id 1
Id 1 destroyed at 7FFDC7A66400
Our instance was constructed at one address, but destroyed at another.
In other words, it was moved.
Can we, please, put that myth to rest?
Shachar
Re: Warn on unused imports?
On Wednesday, 3 October 2018 at 14:27:42 UTC, Dejan Lekic wrote: IDK, I prefer things done in the UNIX way - do one thing and do it right. Compiler should do what its name says - COMPILE, while some other tool should be made for these kind of code checks. The code will compile no matter whether there are some unused imports or not, right? Sure, the Unix way is a nice philosophy, but let's face the facts: - Because of (amongst others) CTFE and mixin, D is an incredibly complicated language to reason about (unlike Java or C#) - There is only one D front-end, and it will likely stay that way for a while - Any static analysis tool that doesn't only work with a subset of the language must basically re-implement a complete compiler front-end or leverage dmd Also dmd is currently not following the Unix way by a long shot. You could have separate programs for the optimizer and assembler, like some compilers have. Every stage of compilation could be a separate program, and that would even be beneficial to static analysis tools, but that has other problems too (like changes in the API, worse performance because of text input and output). Currently we have a package that does everything that requires intricate knowledge of the D language: compiling, documentation generation, profiling, and warning about things like dead code. Also unit-testing is part of the language and the standard library is huge. Warning about unused imports seems like a useful addition to me.
Re: Please don't do a DConf 2018, consider alternatives
On Wednesday, 3 October 2018 at 17:13:51 UTC, Dejan Lekic wrote: On Wednesday, 3 October 2018 at 16:21:45 UTC, Joakim wrote: Like most of the responses in this thread, I have no idea why you're stumping for in-person interaction, when all my suggestions were geared around having _more in-person interaction_. If you're still not sure what I mean, read this long post I wrote fisking Adam's similar post: https://forum.dlang.org/post/eoygemytghynpogvl...@forum.dlang.org Perhaps you did not get my point? No, I got it, you didn't get mine. - I have nothing against core D team having web-conferences as much as they please. It is up to them (and they may already have them?) how they want to communicate. What I argued about was that, just because some antisocial geek argues that conferences are "dead" because we have web-conferencing and similar means of communication does not mean we all share that opinion... Everyone can record a "talk" with slides and put it on some video streaming site like Vimeo or YouTube, but I personally see that as ANOTHER way to reach the community, certainly NOT an alternative to a well-organised conference! Do not get me wrong, I have nothing against the proposal - I think D community can have both good, annual conference, AND what web-conferencing between core D devs, and people who would record talks in their rooms or offices and make them public... While my OP did mention some of those things, it only did so as a way to have _more in-person interaction_ at the two DConf alternative formats I suggested, neither of which was primarily about any of the stuff you mention. At least look at the first two bullet points in my post responding to Adam, because you're missing the entire point of my suggestions, which is that certain things like talks are better suited to online whereas conferences are more suited for in-person interaction.
Re: DIP 1014
On Wed, Oct 3, 2018 at 2:50 AM Corel via Digitalmars-d wrote: > > On Wednesday, 3 October 2018 at 08:21:38 UTC, Manu wrote: > > On Tue, Oct 2, 2018 at 6:15 PM Walter Bright via Digitalmars-d > > wrote: > >> > >> On 10/2/2018 4:30 PM, Adam D. Ruppe wrote: > >> > On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis > >> > wrote: > >> >> Yeah. IIRC, it was supposed to be _guaranteed_ that the > >> >> compiler moved structs in a number of situations - e.g. > >> >> when the return value was an rvalue. Something like > >> > > >> > Eh, I don't think that moves it, but rather just constructs > >> > it in-place for the next call. > >> > >> The technical term for that is "copy elision". > > > > Okay, so copy elision is working... but moves otherwise are > > not? That's still not what we've been peddling all these years. > > A whole lot of design surface area is dedicated to implicit > > move semantics... and they don't work? What does it do? > > postblit unnecessarily? > > The impression is that you are complaining about the continuous > lack of "things" based on an incomplete knowledge of how D works > in detail ... tragically you invoke low-level features, and you > do not know the question. > > The fact that in D the structures to date are not moved, is known > for years ... take advantage of this fact, and move on. > > Work on an implementation that works, AFTER profile it, and > possibly complain about performance. O_o .. this is one of the stranger replies I've ever gotten here.
Re: Please don't do a DConf 2018, consider alternatives
On Wednesday, 3 October 2018 at 16:21:45 UTC, Joakim wrote: Like most of the responses in this thread, I have no idea why you're stumping for in-person interaction, when all my suggestions were geared around having _more in-person interaction_. If you're still not sure what I mean, read this long post I wrote fisking Adam's similar post: https://forum.dlang.org/post/eoygemytghynpogvl...@forum.dlang.org Perhaps you did not get my point? - I have nothing against core D team having web-conferences as much as they please. It is up to them (and they may already have them?) how they want to communicate. What I argued about was that, just because some antisocial geek argues that conferences are "dead" because we have web-conferencing and similar means of communication does not mean we all share that opinion... Everyone can record a "talk" with slides and put it on some video streaming site like Vimeo or YouTube, but I personally see that as ANOTHER way to reach the community, certainly NOT an alternative to a well-organised conference! Do not get me wrong, I have nothing against the proposal - I think D community can have both good, annual conference, AND what web-conferencing between core D devs, and people who would record talks in their rooms or offices and make them public...
Re: Please don't do a DConf 2018, consider alternatives
On Wednesday, 3 October 2018 at 11:48:06 UTC, Dejan Lekic wrote: On Tuesday, 2 October 2018 at 06:26:30 UTC, Joakim wrote: I'm sure some thought and planning is now going into the next DConf, so I'd like to make sure people are aware that the conference format that DConf uses is dying off, as explained here: https://marco.org/2018/01/17/end-of-conference-era It is a matter of personal preference, and a view of a modern-day geek, in my humble opinion... I _highly disagree_. People go to conferences for different reasons. You know, even though we "computer people" tend to be branded as antisocial, there are still many of us who prefer to see someone in person, talk to him/her, meet new people, speak to them too, build the network, exchange phone numbers, etc... As usual with conferences not all people are happy - you will ALWAYS have people who prefer more technical stuff, and people who prefer more business side - people who try to promote their products and services. - Conferences are brilliant places for them. Another group of people interested in conferences and meetups are recruiters. My company found few new colleagues this way... Yet another group are people who also want to see the town where the conference is held - it is a form of tourism if you like. Yes, you can have all that interaction with some internet-conferencing software, but not at the level when people interact with each other directly! Like most of the responses in this thread, I have no idea why you're stumping for in-person interaction, when all my suggestions were geared around having _more in-person interaction_. If you're still not sure what I mean, read this long post I wrote fisking Adam's similar post: https://forum.dlang.org/post/eoygemytghynpogvl...@forum.dlang.org
Re: Please don't do a DConf 2018, consider alternatives
On Wednesday, 3 October 2018 at 01:28:37 UTC, Adam Wilson wrote: On 10/2/18 4:34 AM, Joakim wrote: On Tuesday, 2 October 2018 at 09:39:14 UTC, Adam Wilson wrote: On 10/1/18 11:26 PM, Joakim wrote: [snip] I disagree. It is not clear what you disagree with, since almost nothing you say has any bearing on my original post. To summarize, I suggest changing the currently talk-driven DConf format to either 1. a more decentralized collection of meetups all over the world, where most of the talks are pre-recorded, and the focus is more on introducing new users to the language or 2. at least ditching most of the talks at a DConf still held at a central location, maybe keeping only a couple panel discussions that benefit from an audience to ask questions, and spending most of the time like the hackathon at the last DConf, ie actually meeting in person. This point has a subtle flaw. Many of the talks raise points of discussion that would otherwise go without discussion, and potentially unnoticed, if it were not for the person bringing it up. The talks routinely serve as a launchpad for the nightly dinner sessions. Benjamin Thauts 2016 talk about shared libraries is one such example. Indeed every single year has brought at least one (but usually more) talk that opened up some new line of investigation for the dinner discussions. I thought it was pretty obvious from my original post, since I volunteered to help with the pre-recorded talks, but the idea is to have pre-recorded talks no matter whether DConf is held in a central location or not. Since both of these alternatives I suggest are much more about in-person interaction, which is what you defend, and the only big change I propose is ditching the passive in-person talks, which you do not write a single word in your long post defending, I'm scratching my head about what you got out of my original post. There is much more to the conference than just a 4-day meetup with talks. The idea that it's just the core 8-15 people with a bunch of hangers-on is patently false. It's not about the conversations I have with the "core" people. It's Schveighoffer, or Atila, or Jonathan, or any of a long list of people who are interested enough in coming. Remember these people self-selected to invest non-trivial treasure to be there, they are ALL worthy of conversing with. Since both my mooted alternatives give _much more_ opportunity for such interaction, I'm again scratching my head at your reaction. This is untrue. See responses further down. It is true. You merely prefer certain interaction for yourself to the overall interaction of the community. Is it a "mini-vaction"? Yea, sure, for my wife. For her it's a four day shopping spree in Europe. For me it's four days of wall-to-wall action that leaves me drop-dead exhausted at the end of the day. So it's the talks that provide this or the in-person interaction? If the latter, why are you arguing against my pushing for more of it and ditching the in-person talks? It's everything. The talks, the coding, the talking, the drinking. All of it has some social component I find valuable. Please try to stay on the subject. Nobody's talking about getting rid of coding/talking/drinking, in fact, the idea is to have _more_ time for those, by ditching the in-person talks. So the relevant info here would be what you find "social" about passively watching a talk in person with 100 other people in the same room, which as usual, you don't provide. Every time I see somebody predicting the end of "X" I roll my eyes. I have a vivid memory of the rise of Skype and videoconferencing in the early 2000's giving way to breathless media reports about how said tools would kill the airlines because people could just meet online for a trivial fraction of the price. People make stupid predictions all the time. Ignoring all such "end of" predictions because many predict badly would be like ignoring all new programming languages because 99% are bad. That means you'd never look at D. And yes, some came true: almost nobody programs minicomputers or buys standalone mp3 players like the iPod anymore, compared to how many used to at their peak. Sure, but the predictions about videoconferencing have yet to come true. As told but the data itself. The travel industry is setting new records yearly in spite of videoconferencing. That's not conjecture or opinion, go look for yourself. As I have previously suggested, the stock prices and order-books of Airbus and Boeing are are record highs. Airplanes are more packed than ever (called load-factor). For example, Delta's system-wide load-factor was 85.6% last year. Which means that 85.6% of all available seats for the entire year were occupied. (Source: https://www.statista.com/statistics/221085/passenger-load-factor-of-delta-air-lines/). Airlines are delivering entire planes for business travelers. All of th
Re: DIP 1014
On 03/10/18 18:33, Shachar Shemesh wrote:
~this() {
writefln("%s destructed", &this);
assert(counter is null || counter is &localCounter);
}
You might also want to add @disable this(this); and remove the dead code
(i.e. - the case where the pointer is global) to reduce noise. I
verified that neither one changes anything in the outcome.
Shachar
Re: DIP 1014
On 03/10/18 17:29, Stanislav Blinov wrote:
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
Now I see why sometimes your posts are greeted with hostility.
Yes. I am actually sorry about that. I was responding to your assumption
that I'm wrong. Had your post been phrased as "why didn't you", instead
of "you're wrong wrong wrong" I wouldn't have responded that way.
Like I said, I am sorry.
> Allow me to further illustrate with something that can be written in
D > today:
I am not sure what you were trying to demonstrate, so instead I wanted
to see if you succeeded. I added the following to your Tracker struct:
~this() {
writefln("%s destructed", &this);
assert(counter is null || counter is &localCounter);
}
I.e. - I am asserting if a move was not caught. The program fails to run
on either ldc or dmd. To me, this makes perfect sense as for the way D
is built. In essence, opAssign isn't guaranteed to run. Feel free to
build a struct where that assert passes to convince me.
Here is the flaw in your logic:
void opAssign(Tracker rhs)
rhs is passed by value. This means that already at the point opAssign is
called, rhs *already* has a different address than the one it was passed
in with. I did not follow your logic on why this isn't so, but I don't
see how you can make it not so without changing the ABI quite drastically.
Shachar
Re: DIP 1014
On Wednesday, 3 October 2018 at 14:07:58 UTC, Shachar Shemesh
wrote:
If you read the DIP, you will notice that the *address* in
which the old instance resides is quite important...
Allow me to further illustrate with something that can be written
in D today:
import std.stdio;
struct Tracker {
static int globalCounter;
int localCounter;
int* counter;
this (bool local) {
if (local) counter = &localCounter;
else counter = &globalCounter;
}
// this should be this(Tracker rhs)
void opAssign(Tracker rhs) {
// note: taking address of local parameter
// note: LDC will already 'optimize' the move which in
the absence
// of any move hooks will mess up the address; try with
DMD
printf("Address of temporary is '%x', counter points to
'%x'\n", &rhs, rhs.counter);
auto d = cast(void*) rhs.counter - cast(void*) &rhs;
printf("... which is '%ld' bytes from the address of
temporary.\n", d);
localCounter = rhs.localCounter;
counter = rhs.counter;
if (counter is &rhs.localCounter)
counter = &localCounter;
}
}
auto createCounter(bool local = true) {
Tracker result = Tracker(local);
return result;
}
auto createCounterNoNRV(bool local = true) {
return Tracker(local);
}
void main() {
Tracker stale1, stale2;
stale1 = createCounter();
stale2 = createCounter(false);
Tracker stale3, stale4;
stale3 = createCounterNoNRV();
stale4 = createCounterNoNRV(false);
}
If you run the above with DMD, you'll see what I mean about
obviating the address. If we get this(typeof(this)) (that is
*always* called on move) into the language, the behavior would be
set in stone regardless of compiler.
Re: Warn on unused imports?
On Thursday, 27 September 2018 at 18:35:58 UTC, Nick Sabalausky (Abscissa) wrote: On 09/26/2018 04:37 AM, Dejan Lekic wrote: On Tuesday, 25 September 2018 at 13:03:30 UTC, FeepingCreature wrote: I'm playing with a branch of DMD that would warn on unused imports: I humbly believe this does not belong to the compiler. These sort of things belong to a static code analyser TOOL. Think of checkstyle/findbugs in Java, or flake8/pep8 in Python world. It amounts to the same thing. What you're talking about ultimately boils down to nothing more than the trivial distinction between: toolx ... toola --do-x ... And if you still prefer the former, that can be trivially created via shell alias or a one-liner script. OTOH, If you're talking about whether action X should be taken by default, than that's an entirely orthogonal matter to whether or not it can be included in the compiler. IDK, I prefer things done in the UNIX way - do one thing and do it right. Compiler should do what its name says - COMPILE, while some other tool should be made for these kind of code checks. The code will compile no matter whether there are some unused imports or not, right?
Re: DIP 1014
On Wednesday, 3 October 2018 at 14:07:58 UTC, Shachar Shemesh
wrote:
On 03/10/18 16:56, Stanislav Blinov wrote:
struct S {
this(S rhs);
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
Now I see why sometimes your posts are greeted with hostility.
And this simply and utterly doesn't work.
If you read the DIP, you will notice that the *address* in
which the old instance resides is quite important for
performing the actual move. This is not available with the
interface you're suggesting, mainly because by the time you
have rhs, it has already moved.
In other words, for the interface above to work, the type must
already be movable, which kinda contradict what we're trying to
achieve here.
In the presence of such a constructor, the compiler will have to
call it every time it moves the value, same as what you're
proposing for __move_post_blt. This obviates the need of an
address: address of the argument will always already be
sufficient, even though it's not ref, as the chain of calls for
this(S) will inevitably start with the address of something
constructed in place.
in C++ would have an equivalent signature of
ReturnType foo(Type&& x); // NOT ReturnType foo(Type x);
No, it is not. You see, in C++, x is an "rvalue *reference*". x
has not moved by this point in the run, it has simply had its
address passed to foo.
You've misunderstood me. Yes, in C++ there's an obvious
difference between pass-by-value and pass-by-rvalue-reference,
and it is always user's responsibility to write a move ctor. Not
so in D. In D, you can always assume that anything passed by
value *is* an rvalue reference, precisely because of D's take on
move semantics. I.e. any argument passed by value can assumed to
be moved or constructed in place (that's the main difference from
C++, where it must be explicitly specified).
Re: DIP 1014
On 03/10/18 16:56, Stanislav Blinov wrote:
struct S {
this(S rhs);
OMG, that's so simple!!! Why didn't I think of it?
Oh wait, I did.
And this simply and utterly doesn't work.
If you read the DIP, you will notice that the *address* in which the old
instance resides is quite important for performing the actual move. This
is not available with the interface you're suggesting, mainly because by
the time you have rhs, it has already moved.
In other words, for the interface above to work, the type must already
be movable, which kinda contradict what we're trying to achieve here.
in C++ would have an equivalent signature of
ReturnType foo(Type&& x); // NOT ReturnType foo(Type x);
No, it is not. You see, in C++, x is an "rvalue *reference*". x has not
moved by this point in the run, it has simply had its address passed to
foo. Please see
https://stackoverflow.com/questions/28483250/rvalue-reference-is-treated-as-an-lvalue
Shachar
Re: DIP 1014
On Wednesday, 3 October 2018 at 13:56:29 UTC, Stanislav Blinov
wrote:
Aendment, this should of course be:
this(Tracker oldLocation) {
localCounter = oldLocation.locaclCounter;
counter = oldLocation.counter;
if( counter is &oldLocation.localCounter )
counter = &localCounter;
}
Re: DIP 1014
Shachar, as I don't see a better place of discussing that DIP at
the moment, I'll pour some observations and thoughts in here if
you don't mind, will add some comments on GitHub later.
As I see it right now, it's a case of over-engineering of a quite
simple concept.
1. A new function, called __move_post_blt, will be added to
DRuntime.
That's unnecessary, if not downright harmful for the language. We
should strive to remove things from DRuntime, not add to it. The
core language should deal with type memory, not a .so or dll. And
it's extraneous, because...
2 and 3. onPostMove and __move_post_blt:
They're unnecessary as well. All that's required is to allow a
by-value constructor, e.g:
struct S {
this(S rhs);
}
Any function in D that has a signature of the form
ReturnType foo(Type x);
in C++ would have an equivalent signature of
ReturnType foo(Type&& x); // NOT ReturnType foo(Type x);
because passing by value in D always implies a possible move. The
'x' in such functions can be safely cannibalized without any
repercussions, as it is either a temporary on the call site, or,
which is especially pertaining to the original bugzilla
discussion, constructed in place via copy elision.
Thus in effect this(S) would be an equivalent of C++'s move
constructor. We already have a de-facto move-assignment in the
form of opAssign(S), this(S) would be a natural extension to that.
Note, per above, that it is NOT a copy constructor, although user
code may want to create a copy *before* calling it, to create the
temporary.
Such approach reduces added complexity. The only potential
problem with it would be a need to "special-case" initialization
from .init, although at the moment, I think even that may be
unnecessary: this is a hook after all.
Your example from the DIP would become:
struct Tracker {
static uint globalCounter;
uint localCounter;
uint* counter;
@disable this(this);
this(bool local) {
localCounter = 0;
if( local )
counter = &localCounter;
else
counter = &globalCounter;
}
this(Tracker oldLocation) {
if( counter is &oldLocation.localCounter )
counter = &localCounter;
}
void increment() {
(*counter)++;
}
}
Usage:
auto old = Tracker(true);
// ...
auto new = move(old); // calls Tracker.this(Tracker);
...this avoids any need to inject special postblits into user
code.
As I see it, in addition to the above, what would be really
desirable is for move() and emplace() family of calls to become
compiler intrinsics instead of library constructs. Those at the
moment are complete poison: being templates they infect user code
with dependencies on libc (moveEmplace calls memset and memcpy of
all things) and unnecessary calls to DRuntime (typeid), and they
of course blow up the amount of generated code in the form of
template instantiations. That's despite the fact that the
compiler possesses ALL the necessary knowledge at the time of
those calls.
Re: Just found this debugger...
On Wednesday, 3 October 2018 at 03:25:04 UTC, solidstate1991 wrote: Then I had a thought: Is there anything usable on the market besides these? It may not be enough for your needs, but VSCode C++ debugger somewhat works for D. I can't set breakpoints, but stepping through code works and watches also work for most simple types.
Re: Just found this debugger...
On Wednesday, 3 October 2018 at 03:25:04 UTC, solidstate1991 wrote: https://x64dbg.com/#start I've tried it. It's not very good for source-level debugging. Seems to be primarily aimed at reverse-engineering / debugging programs you don't have the source for.
Re: Just found this debugger...
On Wednesday, 3 October 2018 at 03:25:04 UTC, solidstate1991 wrote: and I don't want to go back to VisualD after VSCode for either a usable mago or VS native debug. Visual Studio makes a decent stand-alone source-level debugger. Just select the .exe file, and right-click it in the project/solution pane to start a debugging session. (Of course, you need to build with -m32mscoff or -m64 as well as -g). VisualD isn't even needed, though VS by itself won't understand D types like arrays/strings.
Re: Please don't do a DConf 2018, consider alternatives
On Tuesday, 2 October 2018 at 06:26:30 UTC, Joakim wrote: I'm sure some thought and planning is now going into the next DConf, so I'd like to make sure people are aware that the conference format that DConf uses is dying off, as explained here: https://marco.org/2018/01/17/end-of-conference-era It is a matter of personal preference, and a view of a modern-day geek, in my humble opinion... I _highly disagree_. People go to conferences for different reasons. You know, even though we "computer people" tend to be branded as antisocial, there are still many of us who prefer to see someone in person, talk to him/her, meet new people, speak to them too, build the network, exchange phone numbers, etc... As usual with conferences not all people are happy - you will ALWAYS have people who prefer more technical stuff, and people who prefer more business side - people who try to promote their products and services. - Conferences are brilliant places for them. Another group of people interested in conferences and meetups are recruiters. My company found few new colleagues this way... Yet another group are people who also want to see the town where the conference is held - it is a form of tourism if you like. Yes, you can have all that interaction with some internet-conferencing software, but not at the level when people interact with each other directly!
Re: DIP 1014
On 03/10/18 04:10, Walter Bright wrote:
On 10/2/2018 4:30 PM, Adam D. Ruppe wrote:
On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis wrote:
Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler
moved structs in a number of situations - e.g. when the return value
was an rvalue. Something like
Eh, I don't think that moves it, but rather just constructs it
in-place for the next call.
The technical term for that is "copy elision".
I'm not sure I follow.
First of all, you cannot elide the copy if there is more than one
potential local variable you are returning, ala:
A someFunc() {
A a, b;
manipulate(a); manipulate(b);
if( someRandomCondition )
return a;
return b;
}
What happens then?
What happens if A has @disable this(this)?
What happens if we explicitly call std.algorithm.move?
Shachar
Re: DIP 1014
On Wednesday, 3 October 2018 at 08:21:38 UTC, Manu wrote: On Tue, Oct 2, 2018 at 6:15 PM Walter Bright via Digitalmars-d wrote: On 10/2/2018 4:30 PM, Adam D. Ruppe wrote: > On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis > wrote: >> Yeah. IIRC, it was supposed to be _guaranteed_ that the >> compiler moved structs in a number of situations - e.g. >> when the return value was an rvalue. Something like > > Eh, I don't think that moves it, but rather just constructs > it in-place for the next call. The technical term for that is "copy elision". Okay, so copy elision is working... but moves otherwise are not? That's still not what we've been peddling all these years. A whole lot of design surface area is dedicated to implicit move semantics... and they don't work? What does it do? postblit unnecessarily? The impression is that you are complaining about the continuous lack of "things" based on an incomplete knowledge of how D works in detail ... tragically you invoke low-level features, and you do not know the question. The fact that in D the structures to date are not moved, is known for years ... take advantage of this fact, and move on. Work on an implementation that works, AFTER profile it, and possibly complain about performance.
Re: Please don't do a DConf 2018, consider alternatives
On Tuesday, 2 October 2018 at 16:10:20 UTC, Johannes Loher wrote: On Tuesday, 2 October 2018 at 15:42:20 UTC, Joakim wrote: On Tuesday, 2 October 2018 at 15:03:45 UTC, Adam D. Ruppe wrote: That is what Joakim is talking about - changing the main event to be more like the after-hours stuff everyone loves so much, to actually use all the time to maximize the potential of in-person time. I'm talking about growing two different qualities much more, with my two suggested alternatives to the DConf format. 1. Ditch the talks, focus on in-person interaction. That's why I suggest having almost no talks, whether at a central DConf or not. You clearly agree with this. 2. Decentralize the DConf location, casting a much wider net over many more cities. Walter and Adam could rent a room and setup a Seattle DConf location, Andrei and Steven in Boston, Ali and Shammah in the bay area, and so on (only illustrative, I'm not imposing this on any of these people). Some of the money that went to renting out a large conference room in Munich can instead be spent on these much smaller rooms in each city. Charge some minimal fee for entrance in some locations, if that means they can spend time with W&A and to cover costs. I wouldn't charge anything more than $2 in my city for my event, as event organizers here have found that that's low enough to keep anyone who's really interested while discouraging fake RSVPs, ie those who have no intent of ever showing up but strangely sign up anyway (I know an organizer who says he had 150 people RSVP for a Meetup here and only 15 showed up). By keeping travel and ticket costs much lower, you invite much more participation. Obviously my second alternative to DConf listed above wouldn't be decentralized at all, only enabling in-person interaction at a still-central DConf. Mix and match as you see fit. I totally agree with you on your first point, i.e. making DConf more interactive. I have had very good experiences with formats like open space or barcamp. However, these formats only work if people are actually willing to participate and bring in their own ideas. Not having anything prepared can in rare cases lead to the situation where there is a lack of things to talk about (I doubt this would be the case for the D community, but it is something to keep in mind). As long as you plan ahead and compile an online list of stuff to work on or discuss in the weeks preceding, I don't see this being a problem. However, I must say I disagree with your second point, i.e. decentralising DConf. As many people here have already mentioned, DConf is about talking to people. And to me it is especially important to talk to lots of different people whom I otherwise don’t get the chance to talk to in person. By decentralising the conference, we would limit the number of different people you can get in touch with directly by a huge amount. I doubt that, it would just be different people you're talking to. There are probably three types of current and potential D users worth talking about. There's the core team, power users, and everybody else, ie casual or prospective users. A central DConf caters to the first two, almost nobody from the largest camp, ie casual/prospective users, is flying out or paying $400 to attend. A decentralized DConf tries to get much more casual/prospective users and power users who couldn't justify traveling so far before, but it has two potential costs: 1. The core team may be spread out and not mostly gathered in one spot anymore. That is why I have suggested having them meet separately from DConf or at one of the DConf locations earlier in this thread. 2. A power user who might have paid to travel to Berlin before doesn't get access to the entire core team at once, someone like you I'm guessing. I think there's some value there, but I suspect it's much less than the value gained from a decentralized DConf. Just to use myself as an example, last Docnf I was able to talk to Andrei, Walter, Mike, Ali, Jonathan, Kai and lots of others and exchange ideas with them. This would not have been possible with a decentralised event (except for the off chance that all those people by chance attend the same local „meetup“). Yes, but what did the D ecosystem concretely get out of it? Is it worth not having the hundreds of people who might have met them at decentralized DConf locations at Boston/SV/Seattle/Berlin not meeting them last year? That's the kind of tough-minded calculation that needs to be made. On the other hand, I have to admit that decentralising the event would open it up for a much bigger audience, which definitely is a good idea. However, I would much prefer to have something like a main DConf and if there are enough interested people in an area who will not go to the main event, they can host their own mini conference and watch streams, make their own small workshops etc. This is w
Re: `shared`...
On Tuesday, 2 October 2018 at 21:35:40 UTC, Walter Bright wrote: On 10/2/2018 1:49 PM, Manu wrote: So... `scope` says "I won't escape this, but I may escape anything this points to"? That's right. http://dconf.org/2017/talks/bright.html I'm confused. Given how the lifetimes of aggregates are defined in DIP1000, and also given that I tried to escape members of a struct when I wrote fearless and the compiler didn't let me, I'm trying to understand in what situation scope doesn't apply transitively.
Re: DIP 1014
On Tue, Oct 2, 2018 at 6:15 PM Walter Bright via Digitalmars-d wrote: > > On 10/2/2018 4:30 PM, Adam D. Ruppe wrote: > > On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis wrote: > >> Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler moved > >> structs > >> in a number of situations - e.g. when the return value was an rvalue. > >> Something like > > > > Eh, I don't think that moves it, but rather just constructs it in-place for > > the > > next call. > > The technical term for that is "copy elision". Okay, so copy elision is working... but moves otherwise are not? That's still not what we've been peddling all these years. A whole lot of design surface area is dedicated to implicit move semantics... and they don't work? What does it do? postblit unnecessarily?
Re: DConf and outreach, e.g. ACCU [was Please don't do a DConf 2018, consider alternatives]
On Wednesday, 3 October 2018 at 07:33:44 UTC, Russel Winder wrote: I have been muttering about this a while. :-) I know, but this conference was sorta last minute realisation that it would be very beneficial to attend and I've been rather busy with it. Being at another conference clearly makes things a bit more difficult, but having registered, logged in to the Web application, a submission just requires a title, blurb and presenter bio. This might hopefully be feasible for you, albeit less than ideal. Good, although I can't guarantee that the blurb will match the final presentation because I'm sure a lot will happen in the mean time, but oh well.
Re: DConf and outreach, e.g. ACCU [was Please don't do a DConf 2018, consider alternatives]
On Wed, 2018-10-03 at 07:03 +, Nicholas Wilson via Digitalmars-d wrote: > On Wednesday, 3 October 2018 at 06:40:28 UTC, Russel Winder wrote: > > How about DConf continues, as it should, and people submit > > sessions to > > ACCU as part of the outreach programme. The call for sessions > > opens at > > the end of this week and lasts three weeks. > > Ow, that does not give me a lot of time, as I'm going to the US > for a conference in the mean time. I have been muttering about this a while. :-) Being at another conference clearly makes things a bit more difficult, but having registered, logged in to the Web application, a submission just requires a title, blurb and presenter bio. This might hopefully be feasible for you, albeit less than ideal. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Please don't do a DConf 2018, consider alternatives
On Tue, 2018-10-02 at 15:03 +, Adam D. Ruppe via Digitalmars-d wrote: > On Tuesday, 2 October 2018 at 14:49:31 UTC, bachmeier wrote: > > I believe it would be a mistake to drop DConf. > > What about we design a DConf that focuses on interactive > collaboration instead of sitting passively in a room watching > someone talk over a slideshow? I will be heading off the the annual GStreamer conference later this month – it's in Edinburgh, so, currently at least, in the UK. Two days of traditional conference with lightning talks, and two days of "hackfest". A very interesting format. I'll let you know if it works after. Python conferences always have at least one sprints day after a conference. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Yet another binding generator (WIP)
On Tuesday, 2 October 2018 at 01:25:10 UTC, evilrat wrote: On Monday, 1 October 2018 at 15:35:30 UTC, Stefan Koch wrote: On Monday, 1 October 2018 at 13:51:10 UTC, evilrat wrote: Hi, Early access program is now live! Limited offer! Preorder until 12.31.2017 BC and you will receive* unique pet - "Cute Space Hamster"! !! *(Limited quantity in stock) [...] Recently there is also "dpp" showed up, it also seems to do same C API approach as dstep, probably has little-to-none C++ support, might be wrong though. Oh wait, no Windows? nice... But if you only ever do linux stuff and C only then it probably even better choice. Somebody managed to get dpp compiling on Windows. It's not going to be a lot of work to get it done, it's just not a priority of mine. C++ support is getting there. On Monday I wrote the line `#include `. It didn't work, but the fact that I even attempted is major progress. C++ is *massive*. And `` #includes `` which uses pretty much every advanced template feature ever.
Re: DConf and outreach, e.g. ACCU [was Please don't do a DConf 2018, consider alternatives]
On Wednesday, 3 October 2018 at 06:40:28 UTC, Russel Winder wrote: How about DConf continues, as it should, and people submit sessions to ACCU as part of the outreach programme. The call for sessions opens at the end of this week and lasts three weeks. Ow, that does not give me a lot of time, as I'm going to the US for a conference in the mean time.
