Re: Here's looking at you, kid
On 2015-11-23 05:16, bachmeier wrote: Okay. I'll do it tomorrow. The sidebar will be Download Getting Started Official Tutorial Wiki Change Log I think there should be a "Contribute" menu item at the top level. Is it necessary to have "Change Log" at the top level? Is that perhaps better located in the download section? -- /Jacob Carlborg
Re: Persistent list
On Monday, 23 November 2015 at 04:40:08 UTC, Dicebot wrote: Not entirely. If there are any one can have a look how compiler organizes rc management internally there and what are current D limitations of doing so in a library. But I don't know any either and suspect it isn't coincidental. They exist: 1. reactive programming language that don't do allocation 2. languages that forbid circular references 3. languages that allow memory leaks in the case of circular references In addition you have runtimes that use region allocators. However, keep in mind that mark-sweep was invented for Lisp.
Re: Short-circuit evaluation in D
On Saturday, 21 November 2015 at 13:48:06 UTC, Shriramana Sharma wrote: Hello. From http://dlang.org/expression.html#OrOrExpression and the subsequent AndAndExpression section it is clear to me that D does indeed employ short-circuit evaluation true to being part of the C family. But I am disappointed to note that D is not mentioned at https://en.wikipedia.org/wiki/Short-circuit_evaluation. I would edit it myself but the table also mentions eager operators and I'm not sure whether D has any such operators i.e. whether & and | are supposed to be eager in D as they are said to be (as per the table) in C++. So I request someone more knowledgeable about D than me to do the edit and respond here too. Thanks. && and || short circuit. &, | and ^ do not short circuit.
Example: wc
I was looking under "Books & Articles" and one of the submenu items is titled "Example: wc". So I thought it must be a heck of an example, but upon clicking, I saw a program with a bunch of nested foreach statements and no explanations. Why is this on the front page sidebar at all? It certainly doesn't belong under "Books & Articles" because it's just code. Is this something we can move to the wiki? I will make the change, but I'm hoping somebody will say something if it belongs there.
Re: Referencer
On Friday, 20 November 2015 at 19:53:23 UTC, HaraldZealot wrote: On Friday, 20 November 2015 at 18:48:51 UTC, Alex Parrill wrote: On Friday, 20 November 2015 at 18:23:57 UTC, HaraldZealot wrote: You say ranges are pass-by-value, but that's not entirely true. Ranges themselves can be classes, or be made references via std.range.refRange. Range elements can be made lvalues by using ref functions [1]. Possible refRange is what I was looking for. Thanks. Unfortunately current RefRange and refRange implementation doesn't work with out-range :( Ridiculous, because reference semantic for out-range even is more important. So I'm found myself at fork point which from my next work for community is better: * add support for out range in `RefRange` * or implement further my universal referencer?
Re: Referencer
On Monday, 23 November 2015 at 11:31:32 UTC, HaraldZealot wrote: On Friday, 20 November 2015 at 19:53:23 UTC, HaraldZealot wrote: On Friday, 20 November 2015 at 18:48:51 UTC, Alex Parrill wrote: On Friday, 20 November 2015 at 18:23:57 UTC, HaraldZealot wrote: You say ranges are pass-by-value, but that's not entirely true. Ranges themselves can be classes, or be made references via std.range.refRange. Range elements can be made lvalues by using ref functions [1]. Possible refRange is what I was looking for. Thanks. Unfortunately current RefRange and refRange implementation doesn't work with out-range :( Ridiculous, because reference semantic for out-range even is more important. So I'm found myself at fork point which from my next work for community is better: * add support for out range in `RefRange` * or implement further my universal referencer? RefRange is not intended to work with output ranges, and output ranges are very different beasts from input ranges, so any kind of reference type wrapper for output ranges should be a separate construct. That being said, I'd be inclined to argue that anything taking an output range should always take it by ref, precisely because copying an output range almost never results in the correct semantics. So, we should probably make it a general policy that anything accepting an output range should accept it by ref. Now, if you need to work around the fact that a function doesn't take its arguments by ref, you could probably just pass a pointer to your output range rather than passing it by value. The syntax of calling a function on a pointer is the same as calling it on the object directly, so it should just work. And if it doesn't for some reason, then given the fact that the only function that output ranges recognize is put, creating a reference type wrapper would be pretty trivial; you only have one function to worry about. Certainly, I would think that your Referencer type is going in the wrong direction, because it's declaring a bunch of functions that have nothing to do with output ranges. - Jonathan M Davis
Re: Example: wc
On Monday, 23 November 2015 at 11:10:29 UTC, bachmeier wrote: I was looking under "Books & Articles" and one of the submenu items is titled "Example: wc". So I thought it must be a heck of an example, but upon clicking, I saw a program with a bunch of nested foreach statements and no explanations. Why is this on the front page sidebar at all? It certainly doesn't belong under "Books & Articles" because it's just code. Is this something we can move to the wiki? I will make the change, but I'm hoping somebody will say something if it belongs there. It used to be the code example displayed on the start page, if I remember correctly. Shouldn't it be put there (with some text that explains what's going on), if not already done so? Looks like it was temporarily "parked" under "Books & Articles" and forgotten.
Re: DConf keynote speaker ideas
On Sunday, 22 November 2015 at 15:23:18 UTC, Andrei Alexandrescu wrote: On 11/22/2015 06:38 AM, Mathias Lang via Digitalmars-d wrote: Over the proposed speakers so far, Carmack would be my favorite. I've asked him a few days ago, he declined. -- Andrei +1 for Tim Sweeney (if Carmack is not available). AFAIK he even was somehow involved with D waaay back around 2000. ... after googling: not sure about involved, but he did post to the forum: https://www.google.sk/search?sclient=psy-ab&gbv=2&biw=1678&bih=985&noj=1&tbs=cdr%3A1%2Ccd_min%3A01.01.1999%2Ccd_max%3A01.01.2002&q=tim+sweeney+digital+mars&oq=tim+sweeney+digital+mars&gs_l=serp.3...55655.57773.1.57878.13.8.0.0.0.0.0.0..0.00...1c.1.64.serp..13.0.0.sPMPPuI2DqA https://www.google.sk/search?sclient=psy-ab&gbv=2&biw=1678&bih=985&noj=1&tbs=cdr%3A1%2Ccd_min%3A01.01.1999%2Ccd_max%3A01.01.2002&q=tim+sweeney+d+lang&oq=tim+sweeney+d+lang&gs_l=serp.3...78672.79872.2.80041.7.6.0.0.0.0.0.0..0.00...1c.1.64.serp..20.0.0.NXIxL1ISmy0
Re: Example: wc
On Monday, 23 November 2015 at 12:19:08 UTC, Chris wrote: On Monday, 23 November 2015 at 11:10:29 UTC, bachmeier wrote: I was looking under "Books & Articles" and one of the submenu items is titled "Example: wc". So I thought it must be a heck of an example, but upon clicking, I saw a program with a bunch of nested foreach statements and no explanations. Why is this on the front page sidebar at all? It certainly doesn't belong under "Books & Articles" because it's just code. Is this something we can move to the wiki? I will make the change, but I'm hoping somebody will say something if it belongs there. It used to be the code example displayed on the start page, if I remember correctly. Shouldn't it be put there (with some text that explains what's going on), if not already done so? Looks like it was temporarily "parked" under "Books & Articles" and forgotten. Okay. Do you know how to add it as a code example? It doesn't make a good first impression.
Re: Here's looking at you, kid
On Monday, 23 November 2015 at 08:09:12 UTC, Jacob Carlborg wrote: On 2015-11-23 05:16, bachmeier wrote: Okay. I'll do it tomorrow. The sidebar will be Download Getting Started Official Tutorial Wiki Change Log I think there should be a "Contribute" menu item at the top level. I agree, but I do prefer "Get Involved" rather than "Contribute". Is it necessary to have "Change Log" at the top level? Is that perhaps better located in the download section? I had the same thought but didn't want to push for so many changes here. This conversation shouldn't be buried inside a thread on a different topic. Ultimately, Andrei and Walter are the ones that decide what goes on the front page, but others will have an opinion.
Re: Here's looking at you, kid
On Monday, 23 November 2015 at 08:09:12 UTC, Jacob Carlborg wrote: Is it necessary to have "Change Log" at the top level? Is that perhaps better located in the download section? Actually, I just checked, and it's already in the download section. The top-level menu item could be deleted.
Re: Example: wc
On Monday, 23 November 2015 at 12:44:55 UTC, bachmeier wrote: On Monday, 23 November 2015 at 12:19:08 UTC, Chris wrote: On Monday, 23 November 2015 at 11:10:29 UTC, bachmeier wrote: I was looking under "Books & Articles" and one of the submenu items is titled "Example: wc". So I thought it must be a heck of an example, but upon clicking, I saw a program with a bunch of nested foreach statements and no explanations. Why is this on the front page sidebar at all? It certainly doesn't belong under "Books & Articles" because it's just code. Is this something we can move to the wiki? I will make the change, but I'm hoping somebody will say something if it belongs there. It used to be the code example displayed on the start page, if I remember correctly. Shouldn't it be put there (with some text that explains what's going on), if not already done so? Looks like it was temporarily "parked" under "Books & Articles" and forgotten. Okay. Do you know how to add it as a code example? It doesn't make a good first impression. The code doesn't look up to date and maybe it's been replaced with a more up to date example (i.e. with range chaining). It uses ulong instead of size_t. I dunno, maybe it should be dropped completely.
Re: Example: wc
On Monday, 23 November 2015 at 14:10:35 UTC, Chris wrote: The code doesn't look up to date and maybe it's been replaced with a more up to date example (i.e. with range chaining). It uses ulong instead of size_t. I dunno, maybe it should be dropped completely. ulong is appropriate here; the maximum word count should not be dependent on the system's memory limits, since it's streaming from an (arbitrary large) file.
Re: Referencer
On Monday, 23 November 2015 at 12:09:13 UTC, Jonathan M Davis wrote: On Monday, 23 November 2015 at 11:31:32 UTC, HaraldZealot wrote: RefRange is not intended to work with output ranges, and output ranges are very different beasts from input ranges, so any kind of reference type wrapper for output ranges should be a separate construct. That being said, I'd be inclined to argue that anything taking an output range should always take it by ref, precisely because copying an output range almost never results in the correct semantics. So, we should probably make it a general policy that anything accepting an output range should accept it by ref. So, you see that to open a PR about changes _by value_ to _by ref_ semantic for all functions operate with out range (especially for copy) is better way? But this breaks existing API... Certainly, I would think that your Referencer type is going in the wrong direction, because it's declaring a bunch of functions that have nothing to do with output ranges. I see my referencer as universal wrapper to any value-like stuff (e.g. structs or even simple POD variable), not only for out ranges (or input ranges). But possibly it is to general (and so not perfect) solution.
Re: Here's looking at you, kid
Am 20.11.2015 um 15:26 schrieb crimaniak: On Friday, 20 November 2015 at 13:57:16 UTC, David DeWitt wrote: The "New Library Reference Preview" under Resources is much cleaner and has comments. I personally prefer the look of that resource. It isn's updated and is on 2.067.1. Don't works for me now, problem with http://dlang.org/library/symbols.js both Chromium and Firefox. I have to wait for timeout for every page - symbols.js end is not detected by browser so he is waiting for next chunk until timeout. But yes, it's better. I couldn't reproduce this with either Chrome/Firefox/Opera on Windows/Linux/Mac and I don't really have an idea what might be wrong, since symbols.js is just an ordinary file like everything else. Could this be something local getting in the way, such as a proxy server, a script blocker or similar?
Re: Referencer
On Monday, 23 November 2015 at 14:25:19 UTC, HaraldZealot wrote: On Monday, 23 November 2015 at 12:09:13 UTC, Jonathan M Davis wrote: On Monday, 23 November 2015 at 11:31:32 UTC, HaraldZealot wrote: RefRange is not intended to work with output ranges, and output ranges are very different beasts from input ranges, so any kind of reference type wrapper for output ranges should be a separate construct. That being said, I'd be inclined to argue that anything taking an output range should always take it by ref, precisely because copying an output range almost never results in the correct semantics. So, we should probably make it a general policy that anything accepting an output range should accept it by ref. So, you see that to open a PR about changes _by value_ to _by ref_ semantic for all functions operate with out range (especially for copy) is better way? But this breaks existing API... That would require a larger discussion. It's come up before, but I don't recall if anything was ever decided. Output ranges pretty much have to be reference types or be passed by ref to work properly though. Pseudo-reference types might work under some circumstances (e.g. dynamic arrays), but outright value types won't. So, we almost have to make it so that they're passed by ref in order for them to work. But output ranges probably are long past due for a more in-depth discussion of their problems and how we should address them (e.g. how is code supposed to deal with the possibility of the output range being full) - though at this point, we're mostly trying to move to using lazy input ranges in most cases, since they're more flexible, and that will limit the scope of output ranges and make their deficiencies less of an issue (though we really should fix them). In any case, no, you probably shouldn't just start creating PRs which put ref on various output range parameters in Phobos. Certainly, I would think that your Referencer type is going in the wrong direction, because it's declaring a bunch of functions that have nothing to do with output ranges. I see my referencer as universal wrapper to any value-like stuff (e.g. structs or even simple POD variable), not only for out ranges (or input ranges). But possibly it is to general (and so not perfect) solution. Well, if all you want is to get a reference type out of a value type, then putting it on the heap and using a pointer to it would be a solution. Using RefCounted would be another, and I would think that it would be similar to what you're trying to do, since what you're trying to do sounds like it would be something like a RefCounted that doesn't actually involve reference counting. - Jonathan M Davis
Re: Referencer
On Monday, 23 November 2015 at 15:35:32 UTC, Jonathan M Davis wrote: Well, if all you want is to get a reference type out of a value type, then putting it on the heap and using a pointer to it would be a solution. Using RefCounted would be another, and I would think that it would be similar to what you're trying to do, since what you're trying to do sounds like it would be something like a RefCounted that doesn't actually involve reference counting. Hmm, interesting. I'm looking deeper to `RefCounted`
Re: Here's looking at you, kid
On Monday, 23 November 2015 at 02:24:31 UTC, Andrei Alexandrescu wrote: If so, then the wiki should also be promoted to top level. Good idea. Please do it! -- Andrei https://github.com/D-Programming-Language/dlang.org/pull/1156
Re: Example: wc
On Monday, 23 November 2015 at 14:10:35 UTC, Chris wrote: The code doesn't look up to date and maybe it's been replaced with a more up to date example (i.e. with range chaining). It uses ulong instead of size_t. I dunno, maybe it should be dropped completely. https://github.com/D-Programming-Language/dlang.org/pull/1157
Dwarf Exception Handling question
I'm struggling to understand dwarf EH, and figure it's a good idea to try and
make it binary compatible with what gdc does, or at least not gratuitously
different. If I use gdc to compile this:
void foo1() {
abc();
try {
def();
}
catch(DD t) {
ghi(t);
}
catch(CC t) {
ghi(t);
}
catch {
mno();
}
jkl();
}
the code generated looks like this:
_D3eh54foo1FZv:
pushRBP
mov RBP,RSP
sub RSP,010h
call abc
call def
L12:call jkl
jmp short L86
cmp RDX,2
je L59
cmp RDX,3
je L7F
cmp RDX,1
je L33
mov RDI,RAX
call_Unwind_Resume
L33:sub RAX,8
mov RAX,[RAX]
mov ESI,offset _D3eh52DD7__ClassZ
mov RDI,RAX
call_d_dynamic_cast
mov -8[RBP],RAX
mov RAX,-8[RBP]
mov RDI,RAX
call ghi
jmp short L12
L59:sub RAX,8
mov RAX,[RAX]
mov ESI,offset _D3eh52CC7__ClassZ
mov RDI,RAX
call_d_dynamic_cast
mov -010h[RBP],RAX
mov RAX,-010h[RBP]
mov RDI,RAX
call ghi
jmp short L12
L7F:call mno
jmp short L12
L86:leave
ret
The calls to _d_dynamic cast appear to be redundant - shouldn't the value in RDX
be sufficient? And why is there a 'default' call to _Unwind_Resume if RDX isn't
an expected value? Shouldn't the personality routine simply not jump to the
landing pad if none of the catch types are satisfied?
Re: Dwarf Exception Handling question
On 23 November 2015 at 18:31, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> I'm struggling to understand dwarf EH, and figure it's a good idea to try
> and make it binary compatible with what gdc does, or at least not
> gratuitously different. If I use gdc to compile this:
>
> void foo1() {
> abc();
> try {
> def();
> }
> catch(DD t) {
> ghi(t);
> }
> catch(CC t) {
> ghi(t);
> }
> catch {
> mno();
> }
> jkl();
> }
>
> the code generated looks like this:
>
> _D3eh54foo1FZv:
> pushRBP
> mov RBP,RSP
> sub RSP,010h
> call abc
> call def
> L12:call jkl
> jmp short L86
> cmp RDX,2
> je L59
> cmp RDX,3
> je L7F
> cmp RDX,1
> je L33
> mov RDI,RAX
> call_Unwind_Resume
> L33:sub RAX,8
> mov RAX,[RAX]
> mov ESI,offset _D3eh52DD7__ClassZ
> mov RDI,RAX
> call_d_dynamic_cast
> mov -8[RBP],RAX
> mov RAX,-8[RBP]
> mov RDI,RAX
> call ghi
> jmp short L12
> L59:sub RAX,8
> mov RAX,[RAX]
> mov ESI,offset _D3eh52CC7__ClassZ
> mov RDI,RAX
> call_d_dynamic_cast
> mov -010h[RBP],RAX
> mov RAX,-010h[RBP]
> mov RDI,RAX
> call ghi
> jmp short L12
> L7F:call mno
> jmp short L12
> L86:leave
> ret
>
> The calls to _d_dynamic cast appear to be redundant - shouldn't the value
> in RDX be sufficient? And why is there a 'default' call to _Unwind_Resume
> if RDX isn't an expected value? Shouldn't the personality routine simply
> not jump to the landing pad if none of the catch types are satisfied?
>
Yes, the _d_dynamic_cast is redundant. This happened because the EH
pointer was treated as an Object, then upcasted to the catch type via the
normal convert() routines. This is what caused the unnecessary call to
_d_dynamic_cast.
This switch statement is generated by GCC itself, and it tries to be
accommodating for all supported languages. I imagine that the default case
is there to support `catch(...)` in C++ code, however D has no notion of
this construct, so what is instead generated is _Unwind_Resume to tell
unwind to keep looking up the call chain.
In other words, the default case should never really happen in D code
except in the event of a logic bug in the unwind EH personality function
(or possibly corruption). If you feel it more appropriate, I don't see the
harm in replacing it with whatever HLT or abort instruction you like. :-)
Re: Dwarf Exception Handling question
On 11/23/2015 10:07 AM, Iain Buclaw via Digitalmars-d wrote: Yes, the _d_dynamic_cast is redundant. This happened because the EH pointer was treated as an Object, then upcasted to the catch type via the normal convert() routines. This is what caused the unnecessary call to _d_dynamic_cast. This switch statement is generated by GCC itself, and it tries to be accommodating for all supported languages. I imagine that the default case is there to support `catch(...)` in C++ code, however D has no notion of this construct, so what is instead generated is _Unwind_Resume to tell unwind to keep looking up the call chain. In other words, the default case should never really happen in D code except in the event of a logic bug in the unwind EH personality function (or possibly corruption). If you feel it more appropriate, I don't see the harm in replacing it with whatever HLT or abort instruction you like. :-) Thanks, this helps a lot, and makes me a lot more comfortable with the notion that I understand what is going on. I won't generate the cast, then, and I'll use a HLT for the default. BTW, are you working on supporting catching std::exception ? My eevil plan is to get D exceptions working completely before trying to support std::exception.
Re: Dwarf Exception Handling question
On 23 November 2015 at 19:18, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 11/23/2015 10:07 AM, Iain Buclaw via Digitalmars-d wrote: > >> Yes, the _d_dynamic_cast is redundant. This happened because the EH >> pointer was >> treated as an Object, then upcasted to the catch type via the normal >> convert() >> routines. This is what caused the unnecessary call to _d_dynamic_cast. >> >> This switch statement is generated by GCC itself, and it tries to be >> accommodating for all supported languages. I imagine that the default >> case is >> there to support `catch(...)` in C++ code, however D has no notion of this >> construct, so what is instead generated is _Unwind_Resume to tell unwind >> to keep >> looking up the call chain. >> >> In other words, the default case should never really happen in D code >> except in >> the event of a logic bug in the unwind EH personality function (or >> possibly >> corruption). If you feel it more appropriate, I don't see the harm in >> replacing >> it with whatever HLT or abort instruction you like. :-) >> > > Thanks, this helps a lot, and makes me a lot more comfortable with the > notion that I understand what is going on. I won't generate the cast, then, > and I'll use a HLT for the default. > > BTW, are you working on supporting catching std::exception ? > > My eevil plan is to get D exceptions working completely before trying to > support std::exception. > Actively? No. First comes 2.067, which will have to be updated *as is* without the visitor conversions. I will need to adjust *my* personality function to be more graceful for handling foreign exceptions. After that, I can look into C++ typeinfo mangling. It's just normal C++ mangling with a _ZT prefix, no? :-) Also, I notice that you are using an older version of GDC. That version you're using doesn't support exception chaining. To get that working I had to invent a callback __gdc_begin_catch() which cleans up the chained exceptions list.
Re: Dwarf Exception Handling question
On Monday, 23 November 2015 at 17:31:51 UTC, Walter Bright wrote: The calls to _d_dynamic cast appear to be redundant - shouldn't the value in RDX be sufficient? This is indeed the case, but of course you need to know in which order the compiler backend wrote the type info entries to the tables. Maybe at the time there didn't exist an intrinsic for that in GDC or something like that. This is how the function looks in LDC (on OS X, but the libunwind "client"-side code is very similar): --- 00010a40 <__D5test24foo1FZv>: 10a40: 53 push rbx 10a41: e8 ca fe ff ff call 10910 <__D4test3abcFZv> 10a46: e8 d5 fe ff ff call 10920 <__D4test3defFZv> 10a4b: 5b poprbx 10a4c: e9 ef fe ff ff jmp10940 <__D4test3jklFZv> 10a51: 48 89 c3movrbx,rax 10a54: 83 fa 03cmpedx,0x3 10a57: 74 05 je 10a5e <__D5test24foo1FZv+0x1e> 10a59: 83 fa 02cmpedx,0x2 10a5c: 75 0f jne10a6d <__D5test24foo1FZv+0x2d> 10a5e: e8 5d ff 00 00 call 1000109c0 <__d_eh_enter_catch> 10a63: 48 8b 3bmovrdi,QWORD PTR [rbx] 10a66: e8 c5 fe ff ff call 10930 <__D4test3ghiFC4test2CCZv> 10a6b: eb de jmp10a4b <__D5test24foo1FZv+0xb> 10a6d: 83 fa 01cmpedx,0x1 10a70: 75 10 jne10a82 <__D5test24foo1FZv+0x42> 10a72: e8 49 ff 00 00 call 1000109c0 <__d_eh_enter_catch> 10a77: e8 d4 fe ff ff call 10950 <__D4test3mnoFZv> 10a7c: 5b poprbx 10a7d: e9 be fe ff ff jmp10940 <__D4test3jklFZv> 10a82: 48 89 dfmovrdi,rbx 10a85: e8 16 ff 00 00 call 1000109a0 <__d_eh_resume_unwind> --- And why is there a 'default' call to _Unwind_Resume if RDX isn't an expected value? Shouldn't the personality routine simply not jump to the landing pad if none of the catch types are satisfied? The reason LDC emits the __d_eh_resume_unwind call all the time is because it is needed as soon as there is a cleanup involved anyway, and so far I was just too lazy to optimize the extra branch away in the special case that there are no cleanups. — David
Re: Dwarf Exception Handling question
On 23 November 2015 at 19:32, David Nadlinger via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Monday, 23 November 2015 at 17:31:51 UTC, Walter Bright wrote: > >> And why is there a 'default' call to _Unwind_Resume if RDX isn't an >> expected value? Shouldn't the personality routine simply not jump to the >> landing pad if none of the catch types are satisfied? >> > > The reason LDC emits the __d_eh_resume_unwind call all the time is because > it is needed as soon as there is a cleanup involved anyway, and so far I > was just too lazy to optimize the extra branch away in the special case > that there are no cleanups. > > We seem to be doing very similar things here.
Re: Here's looking at you, kid
>>> I'm not always politically correct >> >> Most of the time, "politically correct" means being respectful to >> others, except the speaker intends to indicate that that is a bad >> thing. > > Political correctness tries to censor the free expression of thoughts > and has nothing to do with being respectful or not. Being politically > correct means to censor one's own thoughts out of fear of being told > off. This is your line of objection when I asked you to be respectful toward people who might want to learn D. Normal people are polite and respectful out of common human decency. Does this sometimes mean not uttering everything that passes through your head? Of course. But the motivation comes from wanting to work well with others and even from caring about other people. Not fear of being told off. Does this not work for you?
Re: Here's looking at you, kid
On Monday, 23 November 2015 at 20:21:37 UTC, Chris Wright wrote: This is your line of objection when I asked you to be respectful toward people who might want to learn D. Normal people are polite and respectful out of common human decency. Does this sometimes mean not uttering everything that passes through your head? Of course. But the motivation comes from wanting to work well with others and even from caring about other people. Not fear of being told off. Does this not work for you? Chiming in unasked and unwanted from the side here: I personally believe it's better to actually say the things you think straight up instead of trying to sugarcoat things so people are less offended. I've been reading this forum for a while now, and there's often people arguing and accusing each other, even about trivial things, but from what I've seen these types of discussions have brought up and subsequently improved on real problems not too rarely. Plus, anyone getting offended by people ranting on the internet is doing something wrong imho.
Re: Dwarf Exception Handling question
On 11/23/2015 10:31 AM, Iain Buclaw via Digitalmars-d wrote: I will need to adjust *my* personality function to be more graceful for handling foreign exceptions. After that, I can look into C++ typeinfo mangling. It's just normal C++ mangling with a _ZT prefix, no? :-) I think so, but I haven't looked. Also, I notice that you are using an older version of GDC. It's the one I installed recently on Ubuntu with: sudo apt-get install gdc That version you're using doesn't support exception chaining. To get that working I had to invent a callback __gdc_begin_catch() which cleans up the chained exceptions list. Could you please invent it as Boost licensed code, so I can simply incorporate it?
Re: Dwarf Exception Handling question
On 11/23/2015 10:32 AM, David Nadlinger wrote:
This is how the function looks in LDC (on OS X, but the libunwind "client"-side
code is very similar):
---
00010a40 <__D5test24foo1FZv>:
10a40: 53 push rbx
10a41: e8 ca fe ff ff call 10910 <__D4test3abcFZv>
10a46: e8 d5 fe ff ff call 10920 <__D4test3defFZv>
10a4b: 5b poprbx
10a4c: e9 ef fe ff ff jmp10940 <__D4test3jklFZv>
10a51: 48 89 c3movrbx,rax
10a54: 83 fa 03cmpedx,0x3
10a57: 74 05 je 10a5e
<__D5test24foo1FZv+0x1e>
10a59: 83 fa 02cmpedx,0x2
10a5c: 75 0f jne10a6d
<__D5test24foo1FZv+0x2d>
10a5e: e8 5d ff 00 00 call 1000109c0 <__d_eh_enter_catch>
10a63: 48 8b 3bmovrdi,QWORD PTR [rbx]
10a66: e8 c5 fe ff ff call 10930
<__D4test3ghiFC4test2CCZv>
10a6b: eb de jmp10a4b
<__D5test24foo1FZv+0xb>
10a6d: 83 fa 01cmpedx,0x1
10a70: 75 10 jne10a82
<__D5test24foo1FZv+0x42>
10a72: e8 49 ff 00 00 call 1000109c0 <__d_eh_enter_catch>
10a77: e8 d4 fe ff ff call 10950 <__D4test3mnoFZv>
10a7c: 5b poprbx
10a7d: e9 be fe ff ff jmp10940 <__D4test3jklFZv>
10a82: 48 89 dfmovrdi,rbx
10a85: e8 16 ff 00 00 call 1000109a0 <__d_eh_resume_unwind>
---
The code looks quite good. I've been trying to adjust things, however, so there
are no pushes and pops in the code, trying to preallocate everything needed in
the function prolog.
And why is there a 'default' call to _Unwind_Resume if RDX isn't an expected
value? Shouldn't the personality routine simply not jump to the landing pad if
none of the catch types are satisfied?
The reason LDC emits the __d_eh_resume_unwind call all the time is because it is
needed as soon as there is a cleanup involved anyway, and so far I was just too
lazy to optimize the extra branch away in the special case that there are no
cleanups.
dmd rewrites try-catch-finally into try-{try-catch}-finally, which makes it
easier to generate code, because fewer special cases and fewer bugs. I've become
a big fan of that technique :-)
Re: Here's looking at you, kid
On Monday, 23 November 2015 at 20:21:37 UTC, Chris Wright wrote: I'm not always politically correct Most of the time, "politically correct" means being respectful to others, except the speaker intends to indicate that that is a bad thing. Political correctness tries to censor the free expression of thoughts and has nothing to do with being respectful or not. Being politically correct means to censor one's own thoughts out of fear of being told off. This is your line of objection when I asked you to be respectful toward people who might want to learn D. Have I ever been disrespectful toward people who want to learn D? Have I ever told people not to learn D? Where did you get that idea? Seriously, where? I merely objected to comparing (domain specific) scripting languages like JS and PHP to D and I gave my reasons for it in one of my posts. I strongly warn against drawing conclusions from JS's and PHP's success story for D and how to market it. D will never gain traction in the same way and for the same reasons JS and PHP gained traction in the late 90ies. Please try to think about the points I made instead of feeling offended, because you may happen to use PHP or JS or both (or know someone who does). Normal people are polite and respectful out of common human decency. Does this sometimes mean not uttering everything that passes through your head? Of course. But the motivation comes from wanting to work well with others and even from caring about other people. Not fear of being told off. Only, I wasn't talking about people. What does bashing a language have to do with lack of respect? Bashing languages is normal in the programming world and it does not equal bashing the _users_ of the language in question, which I fear you believe. I too have to use JS, out of necessity, and PHP for that matter. Using mediocre, messy or unspectacular languages doesn't mean you're an idiot. Does this not work for you? Oh please. Do you want to shame me? Really? Will not work. Seriously.
Re: Dwarf Exception Handling question
On Monday, 23 November 2015 at 21:05:29 UTC, Walter Bright wrote:
dmd rewrites try-catch-finally into try-{try-catch}-finally,
which makes it easier to generate code, because fewer special
cases and fewer bugs. I've become a big fan of that technique
:-)
Wouldn't that makes unwinding slower because one need to go
through several landing pads ?
Re: Dwarf Exception Handling question
On 11/23/2015 1:32 PM, deadalnix wrote:
On Monday, 23 November 2015 at 21:05:29 UTC, Walter Bright wrote:
dmd rewrites try-catch-finally into try-{try-catch}-finally, which makes it
easier to generate code, because fewer special cases and fewer bugs. I've
become a big fan of that technique :-)
Wouldn't that makes unwinding slower because one need to go through several
landing pads ?
Yes. But if you're choked by unwinding speed, you're doing it wrong.
Re: Here's looking at you, kid
On Monday, 23 November 2015 at 20:21:37 UTC, Chris Wright wrote: I'm not always politically correct Most of the time, "politically correct" means being respectful to others, except the speaker intends to indicate that that is a bad thing. Political correctness tries to censor the free expression of thoughts and has nothing to do with being respectful or not. Being politically correct means to censor one's own thoughts out of fear of being told off. This is your line of objection when I asked you to be respectful toward people who might want to learn D. Normal people are polite and respectful out of common human decency. Does this sometimes mean not uttering everything that passes through your head? Of course. But the motivation comes from wanting to work well with others and even from caring about other people. Not fear of being told off. Does this not work for you? Do not watch this, if you identify with any of the following languages: C, C++, Perl, Java, Scala, JavaScript, Go, Rust, bash, Python (2 and 3), Ruby, PHP, Mathematica, C#, Prolog, Lisp http://bjorn.tipling.com/if-programming-languages-were-weapons Else, you can just have a laugh.
Re: range.save
On Thursday, 19 November 2015 at 21:30:23 UTC, Freddy wrote: ... Another problem I noticed with ranges is that all functionality is unionized. Ranges are expected to be able to popFront,Index,popBack, randomly possibly forcing ranges to carry unneeded buffers if indexing or popBack in never used. On possible solution is to have .retroRange and .indexRange On forward/input ranges.
Re: Dwarf Exception Handling question
On Monday, 23 November 2015 at 21:05:29 UTC, Walter Bright wrote:
The code looks quite good. I've been trying to adjust things,
however, so there are no pushes and pops in the code, trying to
preallocate everything needed in the function prolog.
Wouldn't you still need to restore the stack before leaving the
function (tail call in this case)?
For a single register, push/pop is probably still cheaper than
setting up RBP and having the extra mov/sub.
dmd rewrites try-catch-finally into try-{try-catch}-finally,
which makes it easier to generate code, because fewer special
cases and fewer bugs. I've become a big fan of that technique
Except that we actually need to flatten all the nesting into a
single landing pad anyway. How would you do this in DMD? I didn't
realize you could even have multiple EH table entries attached to
a single code location.
— David
Re: range.save
On 11/23/15 7:10 PM, Freddy wrote: On Thursday, 19 November 2015 at 21:30:23 UTC, Freddy wrote: ... Another problem I noticed with ranges is that all functionality is unionized. Ranges are expected to be able to popFront,Index,popBack, randomly possibly forcing ranges to carry unneeded buffers if indexing or popBack in never used. surely you mean opIndex? Note that ranges are required to implement front, popFront, and empty. That's it, then it is a range. Even save isn't required unless you want it to be a forward range. But yes, a fundamental requirement is to be able to get the front element repeatedly. This necessitates a buffer or "saving of state". -Steve
Re: range.save
On Tuesday, 24 November 2015 at 01:03:36 UTC, Steven Schveighoffer wrote: But yes, a fundamental requirement is to be able to get the front element repeatedly. This necessitates a buffer or "saving of state". Either that or the same operation/calculation is done every time you call front, and it results in the same value (e.g. the result of map calls its predicate every time that you cal front on it). In any case, regardless of how it's done, front needs to always return the same value until popFront is called, and how that's done can vary. - Jonathan M Davis
Re: Dwarf Exception Handling question
On 11/23/2015 4:36 PM, David Nadlinger wrote:
On Monday, 23 November 2015 at 21:05:29 UTC, Walter Bright wrote:
The code looks quite good. I've been trying to adjust things, however, so
there are no pushes and pops in the code, trying to preallocate everything
needed in the function prolog.
Wouldn't you still need to restore the stack before leaving the function (tail
call in this case)?
Yes.
dmd rewrites try-catch-finally into try-{try-catch}-finally, which makes it
easier to generate code, because fewer special cases and fewer bugs. I've
become a big fan of that technique
Except that we actually need to flatten all the nesting into a single landing
pad anyway.
I don't know why that would be true. gdc generates multiple landing pads.
How would you do this in DMD? I didn't realize you could even have
multiple EH table entries attached to a single code location.
You can't. The most deeply nested one gets the table entry.
Re: range.save
On Tuesday, 24 November 2015 at 01:03:36 UTC, Steven Schveighoffer wrote: surely you mean opIndex? Note that ranges are required to implement front, popFront, and empty. That's it, then it is a range. Even save isn't required unless you want it to be a forward range. I meant .indexableRange, random access may require extra buffers or stack space that take space even when random access isn't used, and I'm asking for optional members(.retroRange, .indexableRange) But yes, a fundamental requirement is to be able to get the front element repeatedly. This necessitates a buffer or "saving of state". Not quite what I was thinking. I was saying that ranges that implement back,popBack may need to implement a backwards buffer along a forward buffer even if the backwards buffer is never used.
Re: range.save
On 11/23/15 8:38 PM, Freddy wrote: Not quite what I was thinking. I was saying that ranges that implement back,popBack may need to implement a backwards buffer along a forward buffer even if the backwards buffer is never used. Maybe you are saying that if you want to implement indexing, you must also implement back and popBack? Note that if you don't implement something, it just doesn't get qualified as that type of range, so it's definitely possible to have indexing, but not back and popBack (although if range[$-1] is possible, then wouldn't that easily qualify as back?). So I don't really understand still. I think your issue may be better described with an example. -Steve
Re: Dwarf Exception Handling question
On Monday, 23 November 2015 at 21:38:39 UTC, Walter Bright wrote:
On 11/23/2015 1:32 PM, deadalnix wrote:
On Monday, 23 November 2015 at 21:05:29 UTC, Walter Bright
wrote:
dmd rewrites try-catch-finally into try-{try-catch}-finally,
which makes it
easier to generate code, because fewer special cases and
fewer bugs. I've
become a big fan of that technique :-)
Wouldn't that makes unwinding slower because one need to go
through several
landing pads ?
Yes. But if you're choked by unwinding speed, you're doing it
wrong.
I don't think this is a good reason for making it twice as slow :)
Re: foreach and element type inference
On Friday, 20 November 2015 at 19:37:09 UTC, Nicolas F. wrote: " Allowing "auto" here, as somebody pointed out, would lead to two styles which may be confusing as one might mistake "foreach (e" to be different from "foreach (auto e", and even worse, might be led to believe that "e" was declared earlier in the former case. " So, doesn't that logically suggest that auto e should be kept and e should disregarded or given the error you suggested? foreach(e; x) looks like e is an unqualified type. foreach(auto e; x) looks like e has type "auto", which makes sense. I think most C programmers looking at D without any previous D experiences would think using auto made more sense. Else, why not allow stuff like e = 1; instead of auto e = 1; ?
Re: foreach and element type inference
On 11/24/2015 05:58 AM, Jonny wrote: Else, why not allow stuff like e = 1; instead of auto e = 1; Because the first notation already has a different meaning.
Re: Scott Meyers wants to bring default zero-initialization to C++, mentions TDPL for precedent
On Wednesday, 18 November 2015 at 15:12:27 UTC, Joakim wrote: He advocates for a tool like gofix, to automatically convert such features to be deprecated: http://scottmeyers.blogspot.com/2015/11/breaking-all-eggs-in-c.html Good to see C++ finally trying to deprecate more, long overdue. Also found this comment from Scott when reading the comments just now: "If C++ were to adopt zero-initialization by default, I'd expect a provision for opting out in every context where the current language doesn't require initialization (e.g., arrays, heap objects without constructors, etc.). What the opt-out syntax would be for the various contexts, I don't know, though the first place I'd look would be D to see what it does." Good to see D influencing C++ development. I thought this anonymous comment about his pacemaker example was funny: "I surely hope you are talking about the programmer device for pacemakers and not the actual pacemaker inside someone's body. I worked for Intermedics until we got bought by Guidant on Monday and shut down on Tuesday. We had a project at that time that was being written in C++ and it was likely the compiler did not even have a standard year attached. I was never comfortable with that project given the really ugly tendencies of both compilers and software engineers to do awful things in code. The ugly things in compilers was behind the push for standards in both C and C++! The actual pacemaker likely has so little memory and power that it would be very strange to be written even in C (but more likely after 16 years of improved technology). It is more likely that the pacemaker code is still being written in assembler and the whole program is likely less that a few thousand lines. I am confused by your assertions. It would be *very* unlikely once a device is released to production that the compiler would be changed to a newer version. Medical device software that is done properly must undergo massive amounts of verification and validation before it is released. Changing the compiler would require that the compiler itself be exhaustively validated against the old compiler and then the verification and validation of the device would be required to be repeated. That whole process would likely cost hundreds of thousands of dollars (perhaps even a million) in engineer/clinician time to verify that the device is still safe and effective. It is very likely that all properly managed medical device companies continue to use the initially validated compiler for a *very* long time. As an example, when I worked in arthroscopy, we used the same C compiler for our micro-controllers for 6 years before we even entertained updating to the very latest. And arthroscopy is not nearly as mission critical as pacemakers. If the company you did contract work for was not that diligent, I would sure like to know who it is so I can tell my Dad to decline to use that manufacturer's pacemakers."
Re: Dwarf Exception Handling question
On 2015-11-23 19:18, Walter Bright wrote: My eevil plan is to get D exceptions working completely before trying to support std::exception. Is the idea to replace the existing exception handling mechanism for D code that don't interact with C++ as well? -- /Jacob Carlborg
