[Issue 16692] New debug experience: possible to execute pure functions during expression evaluation?
https://issues.dlang.org/show_bug.cgi?id=16692 --- Comment #10 from Manu --- Okay, that's awesome! Seems to work well. So for const pure properties (or methods that look like properties) where it's safe to call them without mutating, is it possible to automatically populate the struct/class with phony members for the property getters? Ideally they would have a different little icon than data members (like C# does with its properties). --
[Issue 18639] VisualD - First 5 minutes - Improve list of project wizards, propritise MSBuild projects
https://issues.dlang.org/show_bug.cgi?id=18639 Manu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Manu --- Situation is much better! --
[Issue 18846] VisualD - show vtable in debugger
https://issues.dlang.org/show_bug.cgi?id=18846 Manu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Manu --- Seems to be working well! --
Re: Phobos, minimal runtime, -betterC compatibility documentation
On Wednesday, 6 June 2018 at 01:34:13 UTC, Arun Chandrasekaran wrote: I'm more interested in no/minimal runtime[1] than -betterC for my use cases. I think it will be good to have the document mention if the function is supported without the druntime and/or with -betterC. This documentation can be the module level or function level. Is this possible and/or is it worth it? I understand that using druntime function with -betterC will make the compiler throw error. But it will be good to know it up front via doc if a function uses druntime or not. [1] https://dlang.org/changelog/2.079.0.html#minimal_runtime What we actually need is to have the runtime itself to be well-documented. In doing so, one would be able to see which features are implemented in the runtime and which features aren't, so what is and isn't supported in a "minimal runtime" would be self-evident. In lew of that, however, I'll refer you to documentation "object", "core", and "rt" here: https://dlang.org/phobos/index.html. Another good resource is https://wiki.dlang.org/Runtime_Hooks; it's outdated, but still relevant. Please also understand that one of the primary use cases for the "minimal runtime" changes in 2.079 is to allow users to port the runtime to a new platform incrementally in a pay-as-you-go fashion. For that, you'll need to learn the details of the runtime anyway. Prior to the changes in 2.079, you had to implement a large part of the runtime just to get a build, and most of that code would have never even been called from your program. It was ridiculous and a major barrier to entry. With 2.079, you can now implement just what you need incrementally, and that will make it much easier to learn the runtime. What I'm trying to say, is the "minimal runtime" approach to using D is for those who wish to become runtime hackers, and are willing to study and experiment in order to learn how to take control of the runtime for themselves. The reason the phrase "minimal runtime" is often used over "no runtime" is because it is up to you to decide which features of D to implement or not implement. That being said, understand that -betterC does not link in the runtime, so anything not supported by -betterC will also not be supported by a bare runtime. Therefore the documenation at https://dlang.org/spec/betterc.html is still relevant to the "minimal runtime" approach.There are differences. For example, I think -betterC forwards asserts to the C library, while a bare runtime would not. But, the differences are few. You're also welcome to ask questions. I'm the one primarily responsible for those "minimal runtime" changes, and I'd be happy to help you if I can. Mike P.S. You're probably not going to have much success using Phobos in a "minimal runtime" scenario. I'm exploring a way to get around that at https://github.com/JinShil/utiliD.
Re: Hunt framework 1.0.0 released
On Tuesday, 5 June 2018 at 13:54:25 UTC, Steven Schveighoffer wrote: On 6/5/18 3:25 AM, Brian wrote: source code in github https://github.com/huntlabs/hunt/ documents in wiki https://github.com/huntlabs/hunt/wiki/ hunt framework website http://www.huntframework.com/ Is there a way to view your website in English? I found a popup on the bottom that has "English" as a selection, but it doesn't do anything. -Steve We're going to rebuild site with hunt 1.0, use English as the default language.
Phobos, minimal runtime, -betterC compatibility documentation
I'm more interested in no/minimal runtime[1] than -betterC for my use cases. I think it will be good to have the document mention if the function is supported without the druntime and/or with -betterC. This documentation can be the module level or function level. Is this possible and/or is it worth it? I understand that using druntime function with -betterC will make the compiler throw error. But it will be good to know it up front via doc if a function uses druntime or not. [1] https://dlang.org/changelog/2.079.0.html#minimal_runtime
[Issue 18949] New: Array literals don't work with betterc
https://issues.dlang.org/show_bug.cgi?id=18949
Issue ID: 18949
Summary: Array literals don't work with betterc
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: johnnymar...@gmail.com
--- bug.d
void takeArray(const(int)[] array)
{
}
void bar()
{
takeArray([1, 2, 3]);
}
> dmd -c -betterc bug.d
bug.d(6): Error: `TypeInfo` cannot be used with -betterC
It looks like passing an array literal to a function parameter creates a
dependency on `TypeInfo`. It think this has to do with how D is handling the
array literal. It might be trying to allocate it using the GC which is causing
it to depend on GC. You can make the example work if you change bar to the
following:
void bar()
{
static arr = [1, 2, 3];
takeArray(arr);
}
However, I think both versions should work. Otherwise, a better error message
should be in order, i.e.
bug.d(6): dynamic array literals are not supported in betterC. you can fix
this by assigning the array to a static variable instead.
--
Re: stride in slices
On 05.06.2018 21:05, DigitalDesigns wrote: On Tuesday, 5 June 2018 at 18:46:41 UTC, Timon Gehr wrote: On 05.06.2018 18:50, DigitalDesigns wrote: With a for loop, it is pretty much a wrapper on internal cpu logic so it will be near as fast as possible. This is not even close to being true for modern CPUs. There are a lot of architectural and micro-architectural details that affect performance but are not visible or accessible in your for loop. If you care about performance, you will need to test anyway, as even rather sophisticated models of CPU performance don't get everything right. Those optimizations are not part of the instruction set so are irrelevant. They will occur with ranges too. ... I was responding to claims that for loops are basically a wrapper on internal CPU logic and nearly as fast as possible. Both of those claims were wrong. For loops HAVE a direct cpu semantic! Do you doubt this? ... You'd have to define what that means. (E.g., Google currently shows no hits for "direct CPU semantics".) Cpu's do not have range semantics. Ranges are layers on top of compiler semantics... you act like they are equivalent, they are not! I don't understand why you bring this up nor what you think it means. The compiler takes a program and produces some machine code that has the right behavior. Performance is usually not formally specified. In terms of resulting behavior, code with explicit for loops and range-based code may have identical semantics. Which one executes faster depends on internal details of the compiler and the target architecture, and it may change over time, e.g. between compiler releases. All range semantics must go through the library code then to the compiler then to cpu. For loops of all major systems languages go almost directly to cpu instructions. for(int i = 0; i < N; i++) translates in to either increment and loop or jump instructions. ... Sure, or whatever else the compiler decides to do. It might even be translated into a memcpy call. Even if you want to restrict yourself to use only for loops, my point stands. Write maintainable code by default and let the compiler do what it does. Then optimize further in those cases where the resulting code is actually too slow. Test for performance regressions. There is absolutely no reason why any decent compiler would not use what the cpu has to offer. For loops are language semantics, Ranges are library semantics. Not really. Also, irrelevant. To pretend they are equivalent is wrong and no amount of justifying will make them the same. Again, I don't think this point is part of this discussion. I actually do not know even any commercial viable cpu exists without loop semantics. What does it mean for a CPU to have "loop semantics"? CPUs typically have an instruction pointer register and possibly some built-in instructions to manipulate said instruction pointer. x86 has some built-in loop instructions, but I think they are just there for legacy support and not actually something you want to use in performant code. I also no of no commercially viable compiler that does not wrap those instructions in a for loop(or while, or whatever) like syntax that almost maps directly to the cpu instructions. ... The compiler takes your for loop and generates some machine code. I don't think there is a "commercially viable" compiler that does not sometimes do things that are not direct. And even then, there is no very simple mapping from CPU instructions to observed performance, so the entire point is a bit moot. Also, it is often not necessary to be "as fast as possible". It is usually more helpful to figure out where the bottleneck is for your code and concentrate optimization effort there, which you can do more effectively if you can save time and effort for the remaining parts of your program by writing simple and obviously correct range-based code, which often will be fast as well. It's also often not necessary to be "as slow as possible". This seems to be quoting an imaginary person. My point is that to get even faster code, you need to spend effort and often get lower maintainability. This is not always a good trade-off, in particular if the optimization does not improve performance a lot and/or the code in question is not executed very often. I'm not asking for about generalities but specifics. It's great to make generalizations about how things should be but I would like to know how they are. That's a bit unspecific. Maybe in theory ranges could be more optimal than other semantics but theory never equals practice. I don't know who this is addressed to. My point was entirely practical.
Re: GitHub could be acquired by Microsoft
On Tuesday, 5 June 2018 at 17:12:00 UTC, Apocalypto wrote: On Tuesday, 5 June 2018 at 16:12:25 UTC, RalphBa wrote: Did you ever have the need to write something efficient? .NET is a sandbox for children and UX people. Oh yeah, toy applications for children like StackOverflow, Siemens NX, Solidworks, most of the Azure platform, MSSQL and Visual Studio just to name a few. Even a toy compiler like Roslyn. Don't be surprised if github will run someday on top of the .net platform. Welcome to the children playground! This take on Microsoft is really ridiculous. I hope it's all just for fun. I've been using Linux 100% for years and it's really ridiculous seeing comments about Microsoft being some evil company. Beating competition with alternative product is everywhere...Google took over from Yahoo, Github from Rosetta and Co, Facebook from others,...its all competition in business. These people who complain don't usually contribute a penny to Open source. Frankly, Microsoft has done great things for the world with software. Making computers accessible to everyone... They recently came out with VS Code which is better than any existing open source alternative...even though it uses same technology as atom and bracket text editor. Really, Microsoft write high quality software... proprietary or open source. They contribute to Linux and other tools. There's the major contributor to open source. Github is a for-profit company so of course i would expect to make profit too if I bought it. Your employer doesn't pay you with leaves. That money comes from commercialization. Developers must eat. I think some only look at what happened during Steve Balmer's time as ceo. It was "HIS" strategy to pick on Linux. In fact, he pick on Apple too and several other competing products. Its all marketing and competition and its pretty much everywhere. Monopoly and patent registration is everywhere. I'm not saying its a good thing or bad,...Its not just Microsoft. If you're don't trust Microsoft, you shouldn't trust any commercial company. Microsoft has changed business model too by embracing open source. In fact, their the real believers in open source now compared to those who don't think theirs money in open source.
Re: D on top of Hacker News!
On Tuesday, 5 June 2018 at 21:53:51 UTC, I love Ice Cream wrote: On Tuesday, 5 June 2018 at 20:15:07 UTC, Jonathan M Davis wrote: On Tuesday, June 05, 2018 15:09:56 Dejan Lekic via Digitalmars-d wrote: On Sunday, 3 June 2018 at 17:40:46 UTC, I love Ice Cream wrote: >> Is D really a top 20 language? I don't remember seeing it >> anywhere close to the top 20. >> >> https://www.tiobe.com/tiobe-index/ has them in 31 > > Top comment is kind of depressing. The right place to look is https://www.tiobe.com/tiobe-index/d/ I agree with other comments regarding TIOBE - they are constantly changing how they do statistics so they are not relevant source at all. Just look where Kotlin is there and that should pretty much tell you everything. I know at least 10 large companies that are moving from Java/Scala to Kotlin, yet Kotlin is at the bottom 50 table... Ridiculous... The TIOBE has never been a measurement of how much any given language is used. At best, it's been a measurement of which languages folks have been searching for. That can tell you something, but you have to understand what it's measuring to have any clue what it does tell you. And of course, because of how difficult it is to measure search results for a particular language, they keep changing their criteria. The result is that while the tiobe index may be interesting, it must be taken with a very large grain of salt - and that's without getting into any discussions of how valid it is or isn't to use search results from google to do the measuring. - Jonathan M Davis And all of the other metrics done by other groups that was provided that paints a similar picture? http://githut.info/ http://pypl.github.io/PYPL.html http://sogrady-media.redmonk.com/sogrady/files/2018/03/lang.rank_.118.png https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages https://insights.stackoverflow.com/survey/2016 I'm not really intending to crap on anyone here. It's just the dismissal of a collection of data all pointing towards one particular conclusion is a bit strange. It seems like the interest in D is going down not up. I mean it could have a renaissance, but I'd imagine some work would have to be put into that to make it happen. The first link shows D having more repos. The third doesn't show changes in language popularity over time. I can't find any info about D usage over time in the other three links. The Stack Overflow survey isn't going to be informative anyway because most activity for D occurs here, not on SO, so it wouldn't be representative.
Re: stride in slices
On Tuesday, 5 June 2018 at 22:28:44 UTC, DigitalDesigns wrote: On Tuesday, 5 June 2018 at 21:35:03 UTC, Steven Schveighoffer wrote: [...] [...] Does ranges not evaluate lazily on some cases. So it'll avoid unnecessary work...and be much faster and efficient. If I'm correct. [...]
Re: stride in slices
On Tuesday, 5 June 2018 at 21:35:03 UTC, Steven Schveighoffer wrote: On 6/5/18 5:22 PM, DigitalDesigns wrote: On Tuesday, 5 June 2018 at 20:07:06 UTC, Ethan wrote: In conclusion. The semantics you talk about are literally some of the most basic instructions in computing; and that escaping the confines of a for loop for a foreach loop can let the compiler generate more efficient code than 50-year-old compsci concepts can. Ok asshat! You still don't get it! I didn't say ranges would not compile down to the same thing! Do you have trouble understanding the English language? Nope, he doesn't. Look at what you said: "Maybe in theory ranges could be more optimal than other semantics but theory never equals practice. " And now you have been shown (multiple times) that in practice ranges in fact outperform for loops. Including the assembly to prove it (which helps with this comment: "Having some "proof" that they are working well would ease my mind.") No, you have shown a few fucking cases, why are you guys attacking me for being dense? You can't prove that ranges are more optimal than direct semantics! Do it! I'd like to see you try! So tone down the attitude, you got what you *clearly* asked for but seem reluctant to acknowledge. Ranges are good, for loops are good too, but not as. So maybe you should just use ranges and use the correct optimization flags and call it a day? Or else use for loops and accept that even though they may not run as quickly, they are "safer" to use since some malicious coder could come along and add in sleeps inside the std.algorithm functions. -Steve What it seems is that a few of you are upset because I didn't bow down to your precious range semantics and ask for clarification. At first I was jumped on then someone did some tests and found out that it wasn't so rosy like everyone thought. Of course, the work around is to force optimizations that fix the problem when the problem doesn't exist in for loops. Then you come along and tell me that specific cases prove the general case... that is real dense. You know, it takes two to have an attitude! I asked for information regarding stride. I got the range version, it turned out to be slower in some corner case for some bizarre reason. I was then told it required optimizations(why? That is fishy why the corner cause would be 200% slower for a weird edge case) and then I was told that ranges are always faster(which is what you just said because you act like one example proves everything). Every step of the way I am told "don't worry". You've already stepped in the shit once and you expect me to believe everything you say? Why is it so hard to have a test suite that checks the performance of range constructs instead of just getting me to believe you? Huh? Do you really think I'm suppose to believe every thing any asshat says on the net just because they want me to? Back up your beliefs, that simple. Provide timings for all the range functions in various combinations and give me a worse case scenario compared to their equivalent hand-coded versions. Once you do that then I will be able to make an informed decision rather than doing what you really want, which is except your world as authority regardless of the real truth.
Re: stride in slices
On Tuesday, 5 June 2018 at 22:20:08 UTC, DigitalDesigns wrote: It doesn't matter! The issue that I said was not that ranges were slower but that ranges exist on an abstract on top of language semantics! that means that they can never be faster than the language itself! Anything that a range does can never be faster than doing it by hand. This is the best part. Ranges *ARE* a language semantic. https://tour.dlang.org/tour/en/basics/ranges
Re: stride in slices
On Tuesday, 5 June 2018 at 19:18:15 UTC, Adam D. Ruppe wrote: On Tuesday, 5 June 2018 at 19:05:27 UTC, DigitalDesigns wrote: For loops HAVE a direct cpu semantic! Do you doubt this? What are they? And for bonus points, are they actually used by compilers? Then the final question: is the generated code any different than inlined ranges? It doesn't matter! The issue that I said was not that ranges were slower but that ranges exist on an abstract on top of language semantics! that means that they can never be faster than the language itself! Anything that a range does can never be faster than doing it by hand. This is not a hard concept to understand. I know everyone wants to defend their precious ranges but what happens is irrelevant in some particular case. Ranges could be 100x faster in some specific case but it doesn't change the fact that they are an abstraction on top of the language, not in the language. I've already pointed out, and made it clear, I will do it one last time: There is no guarantee(doesn't have to be 100% by the rule of god) by the compiler that a ranges performance will even come close to hand written code or that it won't all of a sudden change when someone decides to "optimize" it and actually makes it worse! These problems are far less likely to occur in a well established language semantic. I can't believe people are really defending library solutions as not having these issues, but I guess that is the nature of most humans.
Re: Confusion/trying to understand CTFE keywords
On Tuesday, June 05, 2018 22:08:32 Stefan Koch via Digitalmars-d-learn wrote: > On Tuesday, 5 June 2018 at 18:00:05 UTC, Steven Schveighoffer > > wrote: > > No, it's definitely a bug. main is not being evaluated at > > compile time. The real result of this function should be a > > compile-time error -- __ctfe is a *runtime* value that is > > always defined based on whether you are __ctfe or not. > > Therefore, n must be a runtime value, and not usable as a > > static array dimension. > > > > If the posted code is valid, then this should be valid as well: > > > > static if(__ctfe) > > > >immutable n = 1; > > > > else > > > >immutable n = 2; > > > > But it's not. > > > > -Steve > > I see what you mean. > I fear fixing this bug will not be easy without breaking arguably > valid uses. Any such case should work by either using an enum instead or using an enum to have the value during CTFE and then initialize a const or immutable variable with it. We'd likely need to deprecate the old behavior rather than simply fixing it in order to avoid breaking code, but the result would ultimately be cleaner, and it should be easy for any affected code to be updated. As is standsw the fact that immutable i = foo(); int[i] arr; works and uses CTFE whereas immutable i = foo(); doesn't do any CTFE just increases the confusion of how CTFE works. The fact that __ctfe then affects things further just makes matters worse. CTFE really should only kick in when it has to kick in. That way, it's clean and understandable as to when it kicks in and when it doesn't, and anyone who wants to initialize a local variable with CTFE can always just use an intermediary enum. We have too much confusion over when CTFE kicks in even without this quirk with immutable. - Jonathan M Davis
Re: Confusion/trying to understand CTFE keywords
On Tuesday, 5 June 2018 at 18:00:05 UTC, Steven Schveighoffer wrote: No, it's definitely a bug. main is not being evaluated at compile time. The real result of this function should be a compile-time error -- __ctfe is a *runtime* value that is always defined based on whether you are __ctfe or not. Therefore, n must be a runtime value, and not usable as a static array dimension. If the posted code is valid, then this should be valid as well: static if(__ctfe) immutable n = 1; else immutable n = 2; But it's not. -Steve I see what you mean. I fear fixing this bug will not be easy without breaking arguably valid uses.
Re: stride in slices
On Tuesday, 5 June 2018 at 21:54:20 UTC, DigitalDesigns wrote: You are an idiot! Take it to reddit. Back your arguments up with actual knowledge and intelligence, not unfounded agression.
Re: stride in slices
On Tuesday, 5 June 2018 at 21:52:03 UTC, Ethan wrote: On Tuesday, 5 June 2018 at 21:22:27 UTC, DigitalDesigns wrote: Ok asshat! Take it to reddit. Back your arguments up with actual knowledge and intelligence, not unfounded agression. You are an idiot! You obviously do not understand basic logic. Unfounded aggression? Yep, way to see how you didn't start it! Must be nice being the bully!
Re: stride in slices
On Tuesday, 5 June 2018 at 21:22:27 UTC, DigitalDesigns wrote: Ok asshat! Take it to reddit. Back your arguments up with actual knowledge and intelligence, not unfounded agression.
Re: D on top of Hacker News!
On Tuesday, 5 June 2018 at 20:15:07 UTC, Jonathan M Davis wrote: On Tuesday, June 05, 2018 15:09:56 Dejan Lekic via Digitalmars-d wrote: On Sunday, 3 June 2018 at 17:40:46 UTC, I love Ice Cream wrote: >> Is D really a top 20 language? I don't remember seeing it >> anywhere close to the top 20. >> >> https://www.tiobe.com/tiobe-index/ has them in 31 > > Top comment is kind of depressing. The right place to look is https://www.tiobe.com/tiobe-index/d/ I agree with other comments regarding TIOBE - they are constantly changing how they do statistics so they are not relevant source at all. Just look where Kotlin is there and that should pretty much tell you everything. I know at least 10 large companies that are moving from Java/Scala to Kotlin, yet Kotlin is at the bottom 50 table... Ridiculous... The TIOBE has never been a measurement of how much any given language is used. At best, it's been a measurement of which languages folks have been searching for. That can tell you something, but you have to understand what it's measuring to have any clue what it does tell you. And of course, because of how difficult it is to measure search results for a particular language, they keep changing their criteria. The result is that while the tiobe index may be interesting, it must be taken with a very large grain of salt - and that's without getting into any discussions of how valid it is or isn't to use search results from google to do the measuring. - Jonathan M Davis And all of the other metrics done by other groups that was provided that paints a similar picture? http://githut.info/ http://pypl.github.io/PYPL.html http://sogrady-media.redmonk.com/sogrady/files/2018/03/lang.rank_.118.png https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages https://insights.stackoverflow.com/survey/2016 I'm not really intending to crap on anyone here. It's just the dismissal of a collection of data all pointing towards one particular conclusion is a bit strange. It seems like the interest in D is going down not up. I mean it could have a renaissance, but I'd imagine some work would have to be put into that to make it happen.
Re: stride in slices
On 6/5/18 5:22 PM, DigitalDesigns wrote: On Tuesday, 5 June 2018 at 20:07:06 UTC, Ethan wrote: In conclusion. The semantics you talk about are literally some of the most basic instructions in computing; and that escaping the confines of a for loop for a foreach loop can let the compiler generate more efficient code than 50-year-old compsci concepts can. Ok asshat! You still don't get it! I didn't say ranges would not compile down to the same thing! Do you have trouble understanding the English language? Nope, he doesn't. Look at what you said: "Maybe in theory ranges could be more optimal than other semantics but theory never equals practice. " And now you have been shown (multiple times) that in practice ranges in fact outperform for loops. Including the assembly to prove it (which helps with this comment: "Having some "proof" that they are working well would ease my mind.") So tone down the attitude, you got what you *clearly* asked for but seem reluctant to acknowledge. Ranges are good, for loops are good too, but not as. So maybe you should just use ranges and use the correct optimization flags and call it a day? Or else use for loops and accept that even though they may not run as quickly, they are "safer" to use since some malicious coder could come along and add in sleeps inside the std.algorithm functions. -Steve
Re: stride in slices
On Tuesday, 5 June 2018 at 20:07:06 UTC, Ethan wrote: On Tuesday, 5 June 2018 at 19:05:27 UTC, DigitalDesigns wrote: For loops HAVE a direct cpu semantic! Do you doubt this? ... Right. If you're gonna keep running your mouth off. How about looking at some disassembly then. for(auto i=0; iUsing ldc -O4 -release for x86_64 processors, the initialiser translates to: mov byte ptr [rbp + rcx], 0 The comparison translates to: cmp r13, rcx ja .LBB0_2 And the increment and store translates to: mov byte ptr [rbp + rcx], 0 movsxd rcx, eax add eax, 3 So. It uses three of the most basic instructions you can think of: mov, cmp, j, add. Now, what might you ask are the instructions that a range compiles down to when everything is properly inlined? The initialisation, since it's a function, pulls from the stack. mov rax, qword ptr [rsp + 16] movsxd rcx, dword ptr [rsp + 32] But the comparison looks virtually identical. cmp rax, rcx jb .LBB2_4 But how does it do the add? With some register magic. movsxd rcx, edx lea edx, [rcx + r9] Now, what that looks like it's doing to me is combing the pointer load and index increment in to two those two instructions. One instruction less than the flat for loop. In conclusion. The semantics you talk about are literally some of the most basic instructions in computing; and that escaping the confines of a for loop for a foreach loop can let the compiler generate more efficient code than 50-year-old compsci concepts can. Ok asshat! You still don't get it! I didn't say ranges would not compile down to the same thing! Do you have trouble understanding the English language? You don't seem to get the concept where ranges are library solutions and someone can some along at any time and modify some code and WHAM! They no longer compile down to your efficient precious instructions. That is far more unlikely to occur with language semantics. Why is that so difficult for you to understand you sure do you have an attitude for someone that has difficulty with English.
Re: pure functions cannot be removed, actually: pure vs. total
On 6/5/18 5:03 PM, FeepingCreature wrote:
On Tuesday, 5 June 2018 at 17:47:15 UTC, Steven Schveighoffer wrote:
Another observation: under the "infinite loops are important
observable behavior" world-view, pure functions cannot be lazily
evaluated either:
pure int foo() { /*infinite loop */}
void main(string[] args)
{
auto a = foo;
writeln("hi");
if(args[1] == "printa")
writeln(a);
}
With some optimizers, this can be rewritten:
writeln("hi");
if(args[1] == "printa")
writeln(foo);
Which if foo is a *normally returning* function and not an infinite
loop one, then this can save cycles in certain cases.
But under your world-view, the optimization is invalid, because foo
might have an infinite loop, and then the observable behavior changes
(instead of printing nothing and infinite looping, "hi" is printed,
and infinite loops).
That's correct, this optimization is invalid. The only optimization that
can arise from foo being pure is *subsequent* calls to foo being removed.
I think Haskell would disagree with you:
https://wiki.haskell.org/Lazy_evaluation
On Tuesday, 5 June 2018 at 17:47:15 UTC, Steven Schveighoffer wrote:
I'll repeat what I said in the PR where you made this similar comment,
I don't think it is important to ensure a pure function that never
returns is always called. Can you explain the benefit of such a thing?
We've all heard of optimizers that reduce "code that does nothing"
down to just a return statement, foiling people who are expecting
benchmarks to run properly, why is this any different?
Frankly speaking, we should not implement optimizations merely on the
basis that we cannot immediately think of a case where they fail. For
instance, a practical function that loops forever would be a find() call
on an infinite range, such as a range returned by .repeat or .generate.
But a call to find doesn't "do nothing". It takes a range and returns a
range.
We are specifically talking about strong-pure functions that return
void, or even strong pure functions whose return value is ignored.
And yes, we can actually prove that calls to pure functions do nothing
based on the rules of pure functions, which is why the optimization is
easy to prove correct. It's one of the reasons pure optimizations are
much easier to reason about.
However, if we have a wrinkle of "we have to make sure infinite loops
execute their thing", then many pure optimizations get thrown out the
window.
-Steve
Re: pure functions cannot be removed, actually: pure vs. total
On Tuesday, 5 June 2018 at 17:47:15 UTC, Steven Schveighoffer
wrote:
Another observation: under the "infinite loops are important
observable behavior" world-view, pure functions cannot be
lazily evaluated either:
pure int foo() { /*infinite loop */}
void main(string[] args)
{
auto a = foo;
writeln("hi");
if(args[1] == "printa")
writeln(a);
}
With some optimizers, this can be rewritten:
writeln("hi");
if(args[1] == "printa")
writeln(foo);
Which if foo is a *normally returning* function and not an
infinite loop one, then this can save cycles in certain cases.
But under your world-view, the optimization is invalid, because
foo might have an infinite loop, and then the observable
behavior changes (instead of printing nothing and infinite
looping, "hi" is printed, and infinite loops).
That's correct, this optimization is invalid. The only
optimization that can arise from foo being pure is *subsequent*
calls to foo being removed.
-Steve
On Tuesday, 5 June 2018 at 17:47:15 UTC, Steven Schveighoffer
wrote:
I'll repeat what I said in the PR where you made this similar
comment, I don't think it is important to ensure a pure
function that never returns is always called. Can you explain
the benefit of such a thing?
We've all heard of optimizers that reduce "code that does
nothing" down to just a return statement, foiling people who
are expecting benchmarks to run properly, why is this any
different?
Frankly speaking, we should not implement optimizations merely on
the basis that we cannot immediately think of a case where they
fail. For instance, a practical function that loops forever would
be a find() call on an infinite range, such as a range returned
by .repeat or .generate.
Re: Mixin templates are a pain at best, useless at worst for any non-trivial use case
On Tuesday, 5 June 2018 at 12:08:58 UTC, Simen Kjærås wrote: There's a reason for those rules in the language, namely function hijacking. This is an issue we take very seriously, and workarounds exists. So serious that there is no meaningful error message? These issues can be ameliorated as in your other post here, by wrapping the template mixin statement as well. This leads to a host of other problems - how do you specify arguments to the mixin template? How do you deal with aliased mixin templates? These issues may possibly be fixed, but it's gonna get ugly. I've posted on these newsgroups literally within the last three weeks about dealing with multiple different argument types (parsing template parameters) and aliases (__traits( identifier, Symbol ) does not match Symbol.stringof if it is an alias). As such, that's purely within the realms of "solvable by the programmer with new idioms" as I see it. This thing I'm posting about is solvable by giving up and generating a string to treat as code. ie the nuclear option when everything else in the language is unsuitable. This issue shows up every now and then, so we know it's a real issue, and the workarounds are clunky. At the same time, the current behavior is there for a reason, and is very unlikely to change. https://dlang.org/spec/template-mixin.html 1. A TemplateMixin takes an arbitrary set of declarations from the body of a TemplateDeclaration and inserts them into the current context. Everything you've talked about here directly conflicts with point number 1 of the mixin template spec. Point 3 of the spec makes a note of the implementation not actually doing the direct copy/paste that it mentions and instead embeds it in to a nested scope and imports it after the fact. Yet there appears to be quite a number of "except for this" clauses that aren't made clear. Clearly something has gone wrong somewhere along the way. So by that token: How many real world dollars have been wasted on function hijacking? Is this something a corporate client has been adamant about? Bringing up the #define macro analogy again, these are clearly similar problems that can happen in C/C++. So is it more of an ideological stand than a real-world one?
Re: D on top of Hacker News!
On Tuesday, June 05, 2018 15:09:56 Dejan Lekic via Digitalmars-d wrote: > On Sunday, 3 June 2018 at 17:40:46 UTC, I love Ice Cream wrote: > >> Is D really a top 20 language? I don't remember seeing it > >> anywhere close to the top 20. > >> > >> https://www.tiobe.com/tiobe-index/ has them in 31 > > > > Top comment is kind of depressing. > > The right place to look is https://www.tiobe.com/tiobe-index/d/ > > I agree with other comments regarding TIOBE - they are constantly > changing how they do statistics so they are not relevant source > at all. Just look where Kotlin is there and that should pretty > much tell you everything. I know at least 10 large companies that > are moving from Java/Scala to Kotlin, yet Kotlin is at the bottom > 50 table... Ridiculous... The TIOBE has never been a measurement of how much any given language is used. At best, it's been a measurement of which languages folks have been searching for. That can tell you something, but you have to understand what it's measuring to have any clue what it does tell you. And of course, because of how difficult it is to measure search results for a particular language, they keep changing their criteria. The result is that while the tiobe index may be interesting, it must be taken with a very large grain of salt - and that's without getting into any discussions of how valid it is or isn't to use search results from google to do the measuring. - Jonathan M Davis
Re: stride in slices
On Tuesday, 5 June 2018 at 19:05:27 UTC, DigitalDesigns wrote: For loops HAVE a direct cpu semantic! Do you doubt this? ... Right. If you're gonna keep running your mouth off. How about looking at some disassembly then. for(auto i=0; iUsing ldc -O4 -release for x86_64 processors, the initialiser translates to: mov byte ptr [rbp + rcx], 0 The comparison translates to: cmp r13, rcx ja .LBB0_2 And the increment and store translates to: mov byte ptr [rbp + rcx], 0 movsxd rcx, eax add eax, 3 So. It uses three of the most basic instructions you can think of: mov, cmp, j, add. Now, what might you ask are the instructions that a range compiles down to when everything is properly inlined? The initialisation, since it's a function, pulls from the stack. mov rax, qword ptr [rsp + 16] movsxd rcx, dword ptr [rsp + 32] But the comparison looks virtually identical. cmp rax, rcx jb .LBB2_4 But how does it do the add? With some register magic. movsxd rcx, edx lea edx, [rcx + r9] Now, what that looks like it's doing to me is combing the pointer load and index increment in to two those two instructions. One instruction less than the flat for loop. In conclusion. The semantics you talk about are literally some of the most basic instructions in computing; and that escaping the confines of a for loop for a foreach loop can let the compiler generate more efficient code than 50-year-old compsci concepts can.
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 ag0aep6g changed: What|Removed |Added CC||ag0ae...@gmail.com --
Re: SecureD moving to GitLab
On Tuesday, June 05, 2018 19:15:12 biocyberman via Digitalmars-d-announce wrote: > On Tuesday, 5 June 2018 at 11:09:31 UTC, Jonathan M Davis wrote: > > [...] > > Very informative. I don't live in the US, but this gives me a > feeling of how tough life can be over there for everyone, except > lawyers. Fortunately, it's not usually a problem, but it's something that any programmer who writes code in their free time has to be aware of. In most cases, if you have a reasonable employer, you can do whatever programming you want in your free time so long as it's not related to what you work on at work. But it is occasionally a problem. - Jonathan M Davis
Re: stride in slices
On 6/5/18 3:05 PM, DigitalDesigns wrote: It's also often not necessary to be "as slow as possible". I'm not asking for about generalities but specifics. It's great to make generalizations about how things should be but I would like to know how they are. Maybe in theory ranges could be more optimal than other semantics but theory never equals practice. Again, I want to stress, ranges are not "as slow as possible", and it's clear from the numbers posted here that they are faster than for loops in practice, at least for this example. -Steve
Re: stride in slices
On Tuesday, 5 June 2018 at 19:05:27 UTC, DigitalDesigns wrote: For loops HAVE a direct cpu semantic! Do you doubt this? What are they? And for bonus points, are they actually used by compilers? Then the final question: is the generated code any different than inlined ranges?
Re: SecureD moving to GitLab
On Tuesday, 5 June 2018 at 11:09:31 UTC, Jonathan M Davis wrote: [...] Very informative. I don't live in the US, but this gives me a feeling of how tough life can be over there for everyone, except lawyers.
Re: stride in slices
On Tuesday, 5 June 2018 at 18:46:41 UTC, Timon Gehr wrote: On 05.06.2018 18:50, DigitalDesigns wrote: With a for loop, it is pretty much a wrapper on internal cpu logic so it will be near as fast as possible. This is not even close to being true for modern CPUs. There are a lot of architectural and micro-architectural details that affect performance but are not visible or accessible in your for loop. If you care about performance, you will need to test anyway, as even rather sophisticated models of CPU performance don't get everything right. Those optimizations are not part of the instruction set so are irrelevant. They will occur with ranges too. For loops HAVE a direct cpu semantic! Do you doubt this? Cpu's do not have range semantics. Ranges are layers on top of compiler semantics... you act like they are equivalent, they are not! All range semantics must go through the library code then to the compiler then to cpu. For loops of all major systems languages go almost directly to cpu instructions. for(int i = 0; i < N; i++) translates in to either increment and loop or jump instructions. There is absolutely no reason why any decent compiler would not use what the cpu has to offer. For loops are language semantics, Ranges are library semantics. To pretend they are equivalent is wrong and no amount of justifying will make them the same. I actually do not know even any commercial viable cpu exists without loop semantics. I also no of no commercially viable compiler that does not wrap those instructions in a for loop(or while, or whatever) like syntax that almost maps directly to the cpu instructions. Also, it is often not necessary to be "as fast as possible". It is usually more helpful to figure out where the bottleneck is for your code and concentrate optimization effort there, which you can do more effectively if you can save time and effort for the remaining parts of your program by writing simple and obviously correct range-based code, which often will be fast as well. It's also often not necessary to be "as slow as possible". I'm not asking for about generalities but specifics. It's great to make generalizations about how things should be but I would like to know how they are. Maybe in theory ranges could be more optimal than other semantics but theory never equals practice.
Re: stride in slices
On 05.06.2018 18:50, DigitalDesigns wrote: With a for loop, it is pretty much a wrapper on internal cpu logic so it will be near as fast as possible. This is not even close to being true for modern CPUs. There are a lot of architectural and micro-architectural details that affect performance but are not visible or accessible in your for loop. If you care about performance, you will need to test anyway, as even rather sophisticated models of CPU performance don't get everything right. Also, it is often not necessary to be "as fast as possible". It is usually more helpful to figure out where the bottleneck is for your code and concentrate optimization effort there, which you can do more effectively if you can save time and effort for the remaining parts of your program by writing simple and obviously correct range-based code, which often will be fast as well.
[Issue 18470] std.algorithm.splitter has frame access problems for custom preds
https://issues.dlang.org/show_bug.cgi?id=18470 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18470] std.algorithm.splitter has frame access problems for custom preds
https://issues.dlang.org/show_bug.cgi?id=18470 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/b5162ecc014a33b5866f2de62b5af012cf425c1d fix issue 18470 - std.algorithm.splitter has frame access problems for custom preds https://github.com/dlang/phobos/commit/a6bf2b6c4793f6af9f6aa148f6bf603b702fb942 Merge pull request #6522 from BBasile/issue-18470 fix issue 18470 - std.algorithm.splitter has frame access problems for custom preds merged-on-behalf-of: Jack Stouffer --
Re: Orange serializer/deserializer
I'm also having some issue now when I changed a type from using a class to using it's base interface Unhandled exception: orange.serialization.SerializationException.SerializationException The object of the static type "const(ItemInterface)" have a different runtime type (Item) and therefore needs to either register its type or register a serializer for its type "Item". at ..\..\..\orange\serialization\SerializationException.d(25) Item inherits from ItemInterface. I was storing a list of Items and changed it to store ItemInterface Item[] -> ItemInterface[] and this is when the error happened. Of course, I'd expect the interface not being serializable(although, maybe @properties should be?) it would be nice if it would store the actual type in it's place(an Item). Else, this prevents me from using interfaces.
Re: Confusion/trying to understand CTFE keywords
On 6/5/18 12:10 PM, Stefan Koch wrote: This is not bug just not very intuitive. Since you are declaring a static array the value of n needs to known at compiletime. so it'll try to evaluate n at an compile-time context in which n is 1. however when code-generation for the function is done __ctfe will be false. Causing the n variable to be initialized to 2. Therefore n will not be equal to a.length. No, it's definitely a bug. main is not being evaluated at compile time. The real result of this function should be a compile-time error -- __ctfe is a *runtime* value that is always defined based on whether you are __ctfe or not. Therefore, n must be a runtime value, and not usable as a static array dimension. If the posted code is valid, then this should be valid as well: static if(__ctfe) immutable n = 1; else immutable n = 2; But it's not. -Steve
Re: stride in slices
On 6/5/18 12:50 PM, DigitalDesigns wrote: I suppose in the long run ranges do have the potential to out perform since they do abstract but there is no guarantee they will even come close. Having some "proof" that they are working well would ease my mind. As this thread shows, ranges have some major issues. Just to point it out again, Ethan's numbers: 17 ms, 891 μs, and 6 hnsecs // for loop 15 ms, 694 μs, and 1 hnsec // fill 15 ms, 570 μs, and 9 hnsecs // each I think ranges are doing just fine. You just need the cross-module inlining turned on. Imagine having some code on your machine that is very performant but on another machine in a slightly different circumstances it runs poorly. Now, say it is the stride issue... One normally would not think of that being an issue so one will look in other areas and could waste times. At least with direct loops you pretty much get what you see. It is very easy for ranges to be slow but more difficult for them to be fast. The same can be said even with direct loops. There are no guarantees of course that one type of programming style is going to outperform another on all platforms and all compilers. My experience is that things that seem like they should be slower can sometimes be faster, and vice versa. It depends on so many factors, and the best thing to do is test and observe in each situation. -Steve
Re: pure functions cannot be removed, actually: pure vs. total
On 6/5/18 10:48 AM, FeepingCreature wrote:
I'm just posting to clear up the misunderstanding that a call to a pure
function can be removed. Actually, even calls to strongly pure functions
cannot always be removed. This is because there is one thing that a pure
function can do that will change program behavior if it is removed, even
if it does not change any global state whatsoever: it can simply never
return.
void foo() pure { while (true) { } }
By the way, this led to an amusing Phobos bug involving a pure function
(not) returning a struct with an enum member:
https://github.com/dlang/dmd/pull/8013#pullrequestreview-110250441 and
assert(false.repeat.any == true); :)
When a strongly pure function is called multiple times with the same
parameter, all but the first call can be removed; this is because if it
was going to not return, it would already have inf-looped the first
time. pure lets you go from n to 1, but not from 1 to 0.
A pure function that returns a value for every possible parameter is
called a total function. Unfortunately, there is no way to enforce
totality in the compiler, due to the halting problem.
I'll repeat what I said in the PR where you made this similar comment, I
don't think it is important to ensure a pure function that never returns
is always called. Can you explain the benefit of such a thing?
We've all heard of optimizers that reduce "code that does nothing" down
to just a return statement, foiling people who are expecting benchmarks
to run properly, why is this any different?
I'm asking because it seems like we give up a really easy optimization
for pure functions for the sake of pure infinite loop programs, which I
suppose have some value, but not much value. Getting around the infinite
loop elision would be pretty simple, just return an int.
On the flip side, if the compiler can figure out via introspection that
some template function is strong pure and returns void, therefore it
doesn't need to call it, that's a much bigger win than preserving the
possible infinite loopiness that likely is a bug anyway.
Another observation: under the "infinite loops are important observable
behavior" world-view, pure functions cannot be lazily evaluated either:
pure int foo() { /*infinite loop */}
void main(string[] args)
{
auto a = foo;
writeln("hi");
if(args[1] == "printa")
writeln(a);
}
With some optimizers, this can be rewritten:
writeln("hi");
if(args[1] == "printa")
writeln(foo);
Which if foo is a *normally returning* function and not an infinite loop
one, then this can save cycles in certain cases.
But under your world-view, the optimization is invalid, because foo
might have an infinite loop, and then the observable behavior changes
(instead of printing nothing and infinite looping, "hi" is printed, and
infinite loops).
-Steve
Re: Orange serializer/deserializer
On Saturday, 2 June 2018 at 20:11:17 UTC, Jacob Carlborg wrote: On 2018-06-02 03:30, IntegratedDimensions wrote: How can I modify the pre serialization and post serialization values? I need to transform some variables that are stored but I would like to do this easily "inline"(would be cool to be able to provide a delegate to do the transformations at the site of definition of the fields). Use the "onSerializing" and "onSerialized" UDAs on a method. "onSerializing" will be called before serializing and "onSerialized" after serializing. Have a look at the unit tests [1]. Also, how does orange handle properties? Seems it just deals with fields and ignores all functions(does not use getter and setter of properties). This is valid, of course, just want to make sure. I still need to be able to transform values pre and post though. That is correct, it only (de)serializes fields. If you want to (de)serialize proprieties, implement the "toData" and "fromData". See the example in the wiki [2]. Note, by implementing these methods none of the standard serialization will occur. If you want to serialize the fields as well, you need to do that as well when implementing "toData" and "fromData". It's also possible to implement these "methods" in a non-intrusive way, i.e. for customizing serialization of third party type [3]. [1] https://github.com/jacob-carlborg/orange/blob/master/tests/Events.d#L39-L54 [2] https://github.com/jacob-carlborg/orange/wiki/Custom-Serialization [3] https://github.com/jacob-carlborg/orange/blob/master/tests/NonIntrusive.d Thanks. I'm having problems preventing void* pointers from not being serialized ..\..\..\orange\serialization\Serializer.d(975): Error: expression `*value` is `void` and has no value ..\..\..\orange\serialization\Serializer.d(1491): Error: new can only create structs, dynamic arrays or class objects, not `void`'s and all I've added to my class is @nonSerialized void* ptr; It seems that the (de)serializer should just ignore all void's no matter what. They can't be serialized to any meaningful thing. Maybe spit a warning out if the uda is not added. Usually pointer values are not meant to be serialized anyways.
Re: Simple tutorials for complex subjects
On Tuesday, 5 June 2018 at 13:33:18 UTC, Kagamin wrote: Why message detection is in receiver instead of infrastructure? Because recursion. One of the messages I've written is a wrapper message for a multi-packet split message, and calls receive with the reconstructed byte buffer. Fairly elegant way to not special-case the thing that much. And why not gather message types from receiver's interface with DbI (like WCF does)? There already is design by introspection. But I don't parse a type, I parse an entire module. The switch statement is being built through the results of an introspective pass. This is quite deliberate. I'm writing a large-scale maintainable codebase. Having everything in one file is a sure way to reduce maintainability and thus productivity of the programmers maintaining it. Getting D to favour lots of smaller files means getting creative. I *could* put all the messages in an interface and inherit from it... but that's a fairly old-school way of thinking. I don't need a giant virtual function table to enforce implementing message types when I can use outside-the-box introspective tricks and compile down to nothing. There's also a design advantage to going message-first here. I'm forcing the maintainers to think of the data before they get to implementation. The existence of a struct already explicitly creates one piece of data - the message ID. Anything else you put in there is up to you. And being structs, means that you don't constantly have to maintain function signatures each time you want to add a value to a message for example.
Re: GitHub could be acquired by Microsoft
On Tuesday, 5 June 2018 at 16:12:25 UTC, RalphBa wrote: Did you ever have the need to write something efficient? .NET is a sandbox for children and UX people. Oh yeah, toy applications for children like StackOverflow, Siemens NX, Solidworks, most of the Azure platform, MSSQL and Visual Studio just to name a few. Even a toy compiler like Roslyn. Don't be surprised if github will run someday on top of the .net platform. Welcome to the children playground!
Re: SecureD moving to GitLab
On Tue, Jun 05, 2018 at 06:55:42AM +, Joakim via Digitalmars-d-announce wrote: > On Tuesday, 5 June 2018 at 06:45:48 UTC, Adam Wilson wrote: > > Hello Fellow D'ers, > > > > As some of you know I work for Microsoft. And as a result of the > > recent acquisition of GitHub by Microsoft, I have decided, out of an > > abundance of caution, to move all of my projects that currently > > reside on GitHub to GitLab. > > > > [...] > > This reads like a joke, why would it matter if you contributed to open > source projects on an open platform that your employer runs? Remember this phrase: conflict of interest. It can land you in serious legal trouble when it involves your employer. T -- If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology.
Re: pure functions cannot be removed, actually: pure vs. total
On Tuesday, 5 June 2018 at 14:48:23 UTC, FeepingCreature wrote: I'm just posting to clear up the misunderstanding that a call to a pure function can be removed. Actually, even calls to strongly pure functions cannot always be removed. This is because there is one thing that a pure function can do that will change program behavior if it is removed, even if it does not change any global state whatsoever: it can simply never return. [...] In that instance you can have false negatives. catgorizing total functions an non total. But no false positives afaics.
Re: stride in slices
On Tuesday, 5 June 2018 at 13:05:56 UTC, Steven Schveighoffer wrote: On 6/4/18 5:52 PM, DigitalDesigns wrote: On Monday, 4 June 2018 at 17:40:57 UTC, Dennis wrote: On Monday, 4 June 2018 at 15:43:20 UTC, Steven Schveighoffer wrote: Note, it's not going to necessarily be as efficient, but it's likely to be close. -Steve I've compared the range versions with a for-loop. For integers and longs or high stride amounts the time is roughly equal, but for bytes with low stride amounts it can be up to twice as slow. https://run.dlang.io/is/BoTflQ 50 Mb array, type = byte, stride = 3, compiler = LDC -O4 -release For-loop 18 ms Fill(0) 33 ms each! 33 ms With stride = 13: For-loop 7.3 ms Fill(0) 7.5 ms each! 7.8 ms This is why I wanted to make sure! I would be using it for a stride of 2 and it seems it might have doubled the cost for no other reason than using ranged. Ranges are great but one can't reason about what is happening in then as easy as a direct loop so I wanted to be sure. Thanks for running the test! See later postings from Ethan and others. It's a matter of optimization being able to see the "whole thing". This is why for loops are sometimes better. It's not inherent with ranges, but if you use the right optimization flags, it's done as fast as if you hand-wrote it. What I've found with D (and especially LDC) is that when you give the compiler everything to work with, it can do some seemingly magic things. -Steve It would be nice if testing could be done. Maybe even profiling in unit tests to make sure ranges are within some margin of error(10%). One of the main reasons I don't use ranges is I simply don't have faith they will be as fast as direct encoding. While they might offer a slightly easier syntax I don't know what is going on under the hood so I can't reason about it(unless I look up the source). With a for loop, it is pretty much a wrapper on internal cpu logic so it will be near as fast as possible. I suppose in the long run ranges do have the potential to out perform since they do abstract but there is no guarantee they will even come close. Having some "proof" that they are working well would ease my mind. As this thread shows, ranges have some major issues. Imagine having some code on your machine that is very performant but on another machine in a slightly different circumstances it runs poorly. Now, say it is the stride issue... One normally would not think of that being an issue so one will look in other areas and could waste times. At least with direct loops you pretty much get what you see. It is very easy for ranges to be slow but more difficult for them to be fast.
Re: GitHub could be acquired by Microsoft
On Tuesday, 5 June 2018 at 16:12:25 UTC, RalphBa wrote: Of course it had to be losing money..how else would they have convinced everyone it need to be aquired? That's long term Now which company has done more for software development, besides Microsoft? GNU... oh sorry, you are speaking about companies... Sun... ok, open and free software isn't really compatible with making money. Best argument why to leave GitHub if you do such kind of software. Mostly closed source proprietary, sure, but still...(and that's changed a lot now!) Well, changed... you really belive them? And mind, open source doesn't imply open and free software, only vice versa. How young are you to not knowing M$ better? I'm sure MS Linux will come out soon .. someone has to compete with Ubuntu. Still M$, still noone essential who will use it... and if only to make a point. And sure, MS stopped a lot of other developers/apps from competing ...but hey, that's business...what else can we expect (from any for-profit, shareholder company). Up there... I wrote something of incompatible, so no not expecting anything else. Thats exactly the point. C# - Windows Forms - Database integration - anyone? I still program with them ;-) If I tried doing any one of my 'windows forms apps' on any open source solution/platform, the productivity loss alone would be immense. Did you ever have the need to write something efficient? .NET is a sandbox for children and UX people. And yes I know what I'm speaking about... not only up to 4.0 what by the way should lack support and security fixes in the meantime, but as XP user you are common to. I hate cloud! Dump the tablet and mobile, and bring back the pc ( running Windows XP 64 bit, or course - where admin means admin!). Let me try to correct you, you hate centralised clouds. There is another concept of cloud even it isn't that far yet. But I'm pretty sure it will once solve the dilamma that stuff can be infiltrated/bought in one big chunk. Or the one that it has to be financed by one Organisation. BR Ralph Nothing wrong with the cloud. The past few companies Ive worked for (small) have used AWS and Azure. Not managing servers and services make it easy for small companies. For instance we use Beanstalk, ECS, Cloudfront, RDS, ElasticCache, Lambda, SQS, and SNS at my current job. With only 5 employees this would be a pain to deal with on own and the cost is about 1000/month for us. Sure we could have our own servers in a datacenter but then that just brings even more headache and the cost would be more than AWS. I agree that large companies serving vast amounts of the internet is not a good thing but the times we live in.
Re: Mixin templates are a pain at best, useless at worst for any non-trivial use case
On Tuesday, 5 June 2018 at 11:35:10 UTC, Ethan wrote: On Tuesday, 5 June 2018 at 10:11:49 UTC, Ethan wrote: And, honestly, with this method, I am already seeing the workaround. Because I've had to do it a ton of times already with other templates. Run a search for 'mixin( "import' in Binderoo to see how many times I've had to get around the changes to template visibility rules. Rather than do that though, now I'll have to iterate over every member of a stored mixin and alias them in to the surrounding object. I've had to go nuclear, in fact, to get this working. And resort to string mixins. https://run.dlang.io/is/O5PDaK So it works. But it doesn't Just Work(TM). avoid unrolling for-each mate. you do that by enclosing the Tuple Argument in [Args].
Re: GitHub could be acquired by Microsoft
Of course it had to be losing money..how else would they have convinced everyone it need to be aquired? That's long term Now which company has done more for software development, besides Microsoft? GNU... oh sorry, you are speaking about companies... Sun... ok, open and free software isn't really compatible with making money. Best argument why to leave GitHub if you do such kind of software. Mostly closed source proprietary, sure, but still...(and that's changed a lot now!) Well, changed... you really belive them? And mind, open source doesn't imply open and free software, only vice versa. How young are you to not knowing M$ better? I'm sure MS Linux will come out soon .. someone has to compete with Ubuntu. Still M$, still noone essential who will use it... and if only to make a point. And sure, MS stopped a lot of other developers/apps from competing ...but hey, that's business...what else can we expect (from any for-profit, shareholder company). Up there... I wrote something of incompatible, so no not expecting anything else. Thats exactly the point. C# - Windows Forms - Database integration - anyone? I still program with them ;-) If I tried doing any one of my 'windows forms apps' on any open source solution/platform, the productivity loss alone would be immense. Did you ever have the need to write something efficient? .NET is a sandbox for children and UX people. And yes I know what I'm speaking about... not only up to 4.0 what by the way should lack support and security fixes in the meantime, but as XP user you are common to. I hate cloud! Dump the tablet and mobile, and bring back the pc ( running Windows XP 64 bit, or course - where admin means admin!). Let me try to correct you, you hate centralised clouds. There is another concept of cloud even it isn't that far yet. But I'm pretty sure it will once solve the dilamma that stuff can be infiltrated/bought in one big chunk. Or the one that it has to be financed by one Organisation. BR Ralph
Re: Confusion/trying to understand CTFE keywords
On Tuesday, 5 June 2018 at 13:27:35 UTC, Steven Schveighoffer
wrote:
On 6/5/18 6:40 AM, Simen Kjærås wrote:
On Tuesday, 5 June 2018 at 09:36:22 UTC, Gopan wrote:
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}
That's gotta be a bug - that should give a 'variable n cannot
be read at compile time' error. The fact that n is immutable
shouldn't be enough to use it at compile time. Filed as
https://issues.dlang.org/show_bug.cgi?id=18945.
Indeed it is a bug. Interesting to see what the compiler sees
as its AST:
import object;
void main()
{
immutable immutable(int) n = __ctfe ? 1 : 2;
int[1] a = 0;
assert(1LU == cast(ulong)n);
return 0;
}
This is what -vcg-ast spits out.
Note the int[1].
-Steve
This is not bug just not very intuitive.
Since you are declaring a static array the value of n needs to
known at compiletime.
so it'll try to evaluate n at an compile-time context in which n
is 1.
however when code-generation for the function is done __ctfe will
be false.
Causing the n variable to be initialized to 2.
Therefore n will not be equal to a.length.
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 --- Comment #9 from David Bennett --- (In reply to David Bennett from comment #8) > (In reply to David Bennett from comment #7) > > Then there are immutable struct members used at compile time, they might not > > be easy to convert to an enum. > > https://run.dlang.io/is/cfGfxw > > I've never seen it used like that... but it does work currently. > > Actually, I reduced that last case a bit to much that it would work fine > even with this change... Here is the case I was thinking of: https://run.dlang.io/is/zZWdIQ Only works currently with static immutable, so not sure if it could be a problem as I think this change would only effect immutable (without static). sorry for the noise. --
Re: determining if array element is null
On Tuesday, 5 June 2018 at 14:52:28 UTC, Timoses wrote: Does `int[4] nums = void` work? Work for what? If you avoid initialization, then the variable(s) are not initialized. https://dlang.org/spec/declaration.html#void_init However, an int is not nullable and always contains a value.
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 --- Comment #8 from David Bennett --- (In reply to David Bennett from comment #7) > Then there are immutable struct members used at compile time, they might not > be easy to convert to an enum. > https://run.dlang.io/is/cfGfxw > I've never seen it used like that... but it does work currently. Actually, I reduced that last case a bit to much that it would work fine even with this change... --
[Issue 18948] std.uni.toLower and std.uni.toUpper should work with random access ranges
https://issues.dlang.org/show_bug.cgi?id=18948 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18948] std.uni.toLower and std.uni.toUpper should work with random access ranges
https://issues.dlang.org/show_bug.cgi?id=18948 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/fa5830c32ee08c34bdfc10bfb62dd7cb5ee87ba3 Fix Issue 18948 - toLower and toUpper should work with random access ranges https://github.com/dlang/phobos/commit/cc58e8a7bf3dec7004cdd9511df927ba38cdeb3c Merge pull request #6545 from JackStouffer/toCase-random-access Issue 18948 - std.uni.toLower and std.uni.toUpper should work with random access ranges merged-on-behalf-of: Jack Stouffer --
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 --- Comment #7 from David Bennett --- (In reply to Jonathan M Davis from comment #6) > > Just use an enum if you want the value to be known and used at compile time, > and use an immutable variable if you want it to be known and used at > runtime. Don't try to have a variable with different values at compile time > and runtime. And if for some reason, you want the value calculated at > compile time but to still have a variable, then use an enum to initialize > the immutable variable. That's what you have to do with mutable variables > already. So the deprecation message shouldn't have a concrete example to opt-in to keep the current functionality. Just something like "Deprecation: Using an immutable variable at compile time will be removed in a future version. Try changing `n` in `int[n] a;` to use an enum variable.". And assume D users will know that they will need to implement the enum separately from the immutable if they want to keep the status quo? Then there are immutable struct members used at compile time, they might not be easy to convert to an enum. https://run.dlang.io/is/cfGfxw I've never seen it used like that... but it does work currently. --
Re: D on top of Hacker News!
On Sunday, 3 June 2018 at 17:40:46 UTC, I love Ice Cream wrote: Is D really a top 20 language? I don't remember seeing it anywhere close to the top 20. https://www.tiobe.com/tiobe-index/ has them in 31 Top comment is kind of depressing. The right place to look is https://www.tiobe.com/tiobe-index/d/ I agree with other comments regarding TIOBE - they are constantly changing how they do statistics so they are not relevant source at all. Just look where Kotlin is there and that should pretty much tell you everything. I know at least 10 large companies that are moving from Java/Scala to Kotlin, yet Kotlin is at the bottom 50 table... Ridiculous...
Re: determining if array element is null
On Saturday, 2 June 2018 at 18:10:38 UTC, eastanon wrote:
Does D array implementation support an array of null values?
int a[4] = null;
But I ran into a type error while checking if a[i] is null
foreach(i; 0..3){
if(i == null){
writeln("it is null");
}
}
}
How do you set fixed size array of null values and check if
they are null?
Does `int[4] nums = void` work?
pure functions cannot be removed, actually: pure vs. total
I'm just posting to clear up the misunderstanding that a call to
a pure function can be removed. Actually, even calls to strongly
pure functions cannot always be removed. This is because there is
one thing that a pure function can do that will change program
behavior if it is removed, even if it does not change any global
state whatsoever: it can simply never return.
void foo() pure { while (true) { } }
By the way, this led to an amusing Phobos bug involving a pure
function (not) returning a struct with an enum member:
https://github.com/dlang/dmd/pull/8013#pullrequestreview-110250441 and assert(false.repeat.any == true); :)
When a strongly pure function is called multiple times with the
same parameter, all but the first call can be removed; this is
because if it was going to not return, it would already have
inf-looped the first time. pure lets you go from n to 1, but not
from 1 to 0.
A pure function that returns a value for every possible parameter
is called a total function. Unfortunately, there is no way to
enforce totality in the compiler, due to the halting problem.
Re: Mixin templates are a pain at best, useless at worst for any non-trivial use case
On Tuesday, 5 June 2018 at 10:11:49 UTC, Ethan wrote: As soon as you have an overload of a function declared in the base object you're mixing in to, any other overload mixed in will not resolve correctly. Great. Yes, it is great, since this lets you selectively override behavior from a generic mixin template for a specific use. I like this. But we might be able to change the rule so, for functions, it follows the overload rules with arguments instead of just going by name. That would let you add functions... but that's inconsistent with how D does child class inheritance too (you need to alias in overloads there as well), for better or for worse. Perhaps adding something like `alias * = Base.*;` as a feature would be good. I kinda hate that. But the idea there would be to just add all of Base's things to the overload set. OK that basically sucks especially when there's multiple bases. but it would be fairly consistent.
Re: stride in slices
On 06/04/2018 07:08 PM, Ethan wrote: On Monday, 4 June 2018 at 18:11:47 UTC, Steven Schveighoffer wrote: BTW, do you have cross-module inlining on? Just to drive this point home. https://run.dlang.io/is/nrdzb0 Manually implemented stride and fill with everything forced inline. Otherwise, the original code is unchanged. 17 ms, 891 μs, and 6 hnsecs 15 ms, 694 μs, and 1 hnsec 15 ms, 570 μs, and 9 hnsecs My new stride outperformed std.range stride, and the manual for-loop. And, because the third test uses the new stride, it also benefited. But interestingly runs every so slightly faster... BTW I've had this thought for a long time to implement stride with a compile-time step... never got around to implementing it. It would easily generalize the existing code without too much work. Essentially the step would be a template parameter; if that is 0, then use a run-time stride. Most of the code works unchanged.
Re: Driving Continuous Improvement in D
05.06.2018 17:00, Steven Schveighoffer пишет: To clarify a bit, complicated or controversial changes that are likely to be delayed or stalled, should be split from simple doc changes if it turns out it's not going to be pulled anytime soon. But normally, adding fixes for docs I would think is fine. -Steve Adding fixes for docs is fine for me too. I just don't like mixing unrelated changes in a commit. But nevertheless I did it. The world isn't ideal)
Re: SecureD moving to GitLab
On Tuesday, 5 June 2018 at 06:55:42 UTC, Joakim wrote: On Tuesday, 5 June 2018 at 06:45:48 UTC, Adam Wilson wrote: Hello Fellow D'ers, As some of you know I work for Microsoft. And as a result of the recent acquisition of GitHub by Microsoft, I have decided, out of an abundance of caution, to move all of my projects that currently reside on GitHub to GitLab. [...] This reads like a joke, why would it matter if you contributed to open source projects on an open platform that your employer runs? I think it's the case of possible "use of company assets for non work related purposes", even if Github still remains open for everyone.
Re: Driving Continuous Improvement in D
On 6/5/18 9:58 AM, Steven Schveighoffer wrote: On 6/5/18 3:20 AM, drug wrote: 04.06.2018 21:08, Steven Schveighoffer пишет: On 6/4/18 1:51 PM, Joakim wrote: On Monday, 4 June 2018 at 15:52:24 UTC, Steven Schveighoffer wrote: On 6/2/18 3:23 AM, Mike Parker wrote: [...] I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function." [...] I think he was talking about _unrelated_ doc changes. Well, how unrelated? If, for instance, you are changing the docs to accommodate the new code, and notice a typo, I would be fine with fixing that, and have even ASKED for that. I guess I need a bigger clarification, as the way it reads is that we require people split their doc changes from their code changes, and that simply hasn't been the case. But what if your commit with this typo would be reverted? Then you lost your typo fix too. Then you fix the typo again? Reverts don't happen enough to justify this concern. To clarify a bit, complicated or controversial changes that are likely to be delayed or stalled, should be split from simple doc changes if it turns out it's not going to be pulled anytime soon. But normally, adding fixes for docs I would think is fine. -Steve
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945 --- Comment #6 from Jonathan M Davis --- (In reply to David Bennett from comment #4) > I'm not sure what workaround we would recommend in the deprecation messaged > as the current functionality is actually hard to replicate. Just use an enum if you want the value to be known and used at compile time, and use an immutable variable if you want it to be known and used at runtime. Don't try to have a variable with different values at compile time and runtime. And if for some reason, you want the value calculated at compile time but to still have a variable, then use an enum to initialize the immutable variable. That's what you have to do with mutable variables already. --
Re: Driving Continuous Improvement in D
On 6/5/18 3:20 AM, drug wrote: 04.06.2018 21:08, Steven Schveighoffer пишет: On 6/4/18 1:51 PM, Joakim wrote: On Monday, 4 June 2018 at 15:52:24 UTC, Steven Schveighoffer wrote: On 6/2/18 3:23 AM, Mike Parker wrote: [...] I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function." [...] I think he was talking about _unrelated_ doc changes. Well, how unrelated? If, for instance, you are changing the docs to accommodate the new code, and notice a typo, I would be fine with fixing that, and have even ASKED for that. I guess I need a bigger clarification, as the way it reads is that we require people split their doc changes from their code changes, and that simply hasn't been the case. But what if your commit with this typo would be reverted? Then you lost your typo fix too. Then you fix the typo again? Reverts don't happen enough to justify this concern. -Steve
Re: Hunt framework 1.0.0 released
On Tue, Jun 5, 2018 at 3:54 PM, Steven Schveighoffer via Digitalmars-d-announce wrote: > On 6/5/18 3:25 AM, Brian wrote: > > source code in github https://github.com/huntlabs/hunt/ >> documents in wiki https://github.com/huntlabs/hunt/wiki/ >> hunt framework website http://www.huntframework.com/ >> > > Is there a way to view your website in English? I found a popup on the > bottom that has "English" as a selection, but it doesn't do anything. > > -Steve > https://translate.googleusercontent.com/translate_c?depth=1=cs=translate.google.com=zh-CN=nmt4=en=http://www.huntframework.com/=17259,152,15700022,15700124,15700149,15700168,15700173,15700186,15700191,15700201=ALkJrhiSdndhn6w5ujhGrkPtuxcHYpZFfA
Re: Hunt framework 1.0.0 released
On 6/5/18 3:25 AM, Brian wrote: source code in github https://github.com/huntlabs/hunt/ documents in wiki https://github.com/huntlabs/hunt/wiki/ hunt framework website http://www.huntframework.com/ Is there a way to view your website in English? I found a popup on the bottom that has "English" as a selection, but it doesn't do anything. -Steve
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
anonymous4 changed:
What|Removed |Added
Hardware|x86 |All
OS|Windows |All
--- Comment #5 from anonymous4 ---
---
int f(in int a) pure
{
return a;
}
void g()
{
immutable int a=0;
static assert(f(a)==0);
}
---
This works.
---
int f(in ref int a) pure
{
return a;
}
void g()
{
immutable int a=0;
static assert(f(a)==0);
}
---
This doesn't.
--
Re: Simple tutorials for complex subjects
On Sunday, 3 June 2018 at 16:25:29 UTC, Ethan wrote:
Step seven: In your receive function that takes a byte stream,
put in a switch statement that looks a little bit like the
following:
switch( msg.GetID )
{
static foreach( Message; ServerMessages )
{
case ObjectIDOf!Message:
Message deserialised = msg.FromBinary!Message;
this.receive( deserialised );
}
default:
break;
}
Why message detection is in receiver instead of infrastructure?
And why not gather message types from receiver's interface with
DbI (like WCF does)?
Re: Confusion/trying to understand CTFE keywords
On 6/5/18 6:40 AM, Simen Kjærås wrote:
On Tuesday, 5 June 2018 at 09:36:22 UTC, Gopan wrote:
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}
That's gotta be a bug - that should give a 'variable n cannot be read at
compile time' error. The fact that n is immutable shouldn't be enough to
use it at compile time. Filed as
https://issues.dlang.org/show_bug.cgi?id=18945.
Indeed it is a bug. Interesting to see what the compiler sees as its AST:
import object;
void main()
{
immutable immutable(int) n = __ctfe ? 1 : 2;
int[1] a = 0;
assert(1LU == cast(ulong)n);
return 0;
}
This is what -vcg-ast spits out.
Note the int[1].
-Steve
[Issue 18948] New: std.uni.toLower and std.uni.toUpper should work with random access ranges
https://issues.dlang.org/show_bug.cgi?id=18948 Issue ID: 18948 Summary: std.uni.toLower and std.uni.toUpper should work with random access ranges Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: j...@jackstouffer.com --
[Issue 18947] New: No way to get list of overloads from template mixins
https://issues.dlang.org/show_bug.cgi?id=18947
Issue ID: 18947
Summary: No way to get list of overloads from template mixins
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
mixin template foo(T) {
void fun(T) {}
}
struct S {
mixin foo!int;
mixin foo!string;
}
unittest {
static assert(__traits(compiles, __traits(getMember, S, "fun")));
static assert(__traits(getOverloads, S, "fun").length == 0);
S s;
s.fun(3);
}
Somehow the call to s.fun compiles, but trying to get the list of overloads
fails.
--
Re: stride in slices
On 6/4/18 5:52 PM, DigitalDesigns wrote: On Monday, 4 June 2018 at 17:40:57 UTC, Dennis wrote: On Monday, 4 June 2018 at 15:43:20 UTC, Steven Schveighoffer wrote: Note, it's not going to necessarily be as efficient, but it's likely to be close. -Steve I've compared the range versions with a for-loop. For integers and longs or high stride amounts the time is roughly equal, but for bytes with low stride amounts it can be up to twice as slow. https://run.dlang.io/is/BoTflQ 50 Mb array, type = byte, stride = 3, compiler = LDC -O4 -release For-loop 18 ms Fill(0) 33 ms each! 33 ms With stride = 13: For-loop 7.3 ms Fill(0) 7.5 ms each! 7.8 ms This is why I wanted to make sure! I would be using it for a stride of 2 and it seems it might have doubled the cost for no other reason than using ranged. Ranges are great but one can't reason about what is happening in then as easy as a direct loop so I wanted to be sure. Thanks for running the test! See later postings from Ethan and others. It's a matter of optimization being able to see the "whole thing". This is why for loops are sometimes better. It's not inherent with ranges, but if you use the right optimization flags, it's done as fast as if you hand-wrote it. What I've found with D (and especially LDC) is that when you give the compiler everything to work with, it can do some seemingly magic things. -Steve
Re: Hunt framework 1.0.0 released
On Tuesday, 5 June 2018 at 07:25:33 UTC, Brian wrote: We are pleased to announce an official version of hunt 1.0 , This is an important milestone release! [...] /usr/bin/ld: cannot find -lmysqlclient collect2: error: ld returned 1 exit status Error: linker exited with status 1
[Issue 18946] assert message can throw hijacking the assert failure.
https://issues.dlang.org/show_bug.cgi?id=18946 Shachar Shemesh changed: What|Removed |Added CC||shac...@weka.io --
Re: Can anyone explain this?
On Tuesday, 5 June 2018 at 09:58:43 UTC, Nicholas Wilson wrote: prints Exception https://issues.dlang.org/show_bug.cgi?id=18946
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
David Bennett changed:
What|Removed |Added
CC||davidbenn...@bravevision.co
||m
--- Comment #4 from David Bennett ---
I'm not sure what workaround we would recommend in the deprecation messaged as
the current functionality is actually hard to replicate... as enum and static
would give a different runtime result (actually an error in this case as __ctfe
is not known at statictime... only ctfetime and runtime)
The best I could do on short notice was:
unittest {
immutable n = __ctfe ? 1 : 2;
enum l = {return __ctfe ? 1 : 2;}();
int[l] a;
assert(a.length == n);
}
--
[Issue 18946] New: assert message can throw hijacking the assert failure.
https://issues.dlang.org/show_bug.cgi?id=18946
Issue ID: 18946
Summary: assert message can throw hijacking the assert failure.
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: iamthewilsona...@hotmail.com
from https://forum.dlang.org/thread/pf5gm7$14gb$1...@digitalmars.com
import std.stdio;
import core.exception;
// mess with the compiler's reasoning about the truthiness
// of the assert, otherwise the trailing catches are removed
// as dead code, triggering the implicit one around Dmain
bool returnsFalse() { return false;}
void main() {
try {
static string throwingFunc() {
throw new Exception("An exception");
}
assert(returnsFalse(), throwingFunc());
} catch(Exception ex) {
writeln("Exception");
} catch(AssertError ex) {
writeln("Assert");
}
}
prints
Exception
the compiler should be at least warn that the message expression is not
nothrow. but we should probably deprecate it.
--
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
--- Comment #3 from Jonathan M Davis ---
This probably does need to be removed via deprecation rather than simply making
it an error, but allowing it is exactly the sort of thing that increases the
confusion about how CTFE works and when it's used. Currently,
immutable i = foo();
doesn't do CTFE. But
immutable i = foo();
int[i] arr;
does, and that muddies the waters considerably. We already have problems due to
folks getting really confused about why stuff like
auto foo(int i)
{
return bar!i();
}
isn't legal, and allowing a runtime variable to be used just because it's
immutable makes that worse - even more so when you consider that
auto foo(immutable int i)
{
return bar!i();
}
won't work, and neither will
auto foo(immutable int i = 42)
{
return bar!i();
}
And allowing
immutable i = foo();
int[i] arr;
to work doesn't even buy us anything. You could simply use enum instead of
immutable, and it works perfectly fine.
My guess is that the current behavior was added because of an enhancement
request, and the person who implemented it didn't think of all of the
consequences that result from that decision (including the issue with __ctfe).
But I definitely think that we'd be better off if you _had_ to use an enum in
this case and that the fact that a variable was const or immutable would have
zero effect on CTFE.
--
Re: Mixin templates are a pain at best, useless at worst for any non-trivial use case
On Tuesday, 5 June 2018 at 10:11:49 UTC, Ethan wrote:
Exhibit A: https://run.dlang.io/is/a85Lbq
I submitted a bug with the above code, and it was "helpfully"
shut down with a link to the documentation and workaround.
Congratulations. That's not the use case here, and to be quite
honest this is one of those examples where a #define macro
would "just work". And I'm firmly of the view that *ANY*
example of that should be dealt with at a language level in
order to completely remove the argument of needing a
preprocessor.
There's a reason for those rules in the language, namely function
hijacking. This is an issue we take very seriously, and
workarounds exists.
As you point out, the suggested workaround is aliasing each
function in the mixin (you also say you don't want workarounds -
bear with me, I'm building to a point). This can to some extent
be encapsulated in a string mixin that's used alongside any
template mixin:
string introduceSymbols(alias F)()
{
enum id = __traits(identifier, F);
return "static foreach (fn; __traits(allMembers, "~id~")) {"~
"mixin(`alias `~fn~` = "~id~".`~fn~`;`);"~
"}";
}
mixin foo!() foo_;
mixin(introduceSymbols!foo_);
This introduces complexity in that each mixin must be given a
unique name at instantiation, another line must be included with
every mixin, and the name must be repeated in the second line.
This situation is less than optimal, and the compiler gives no
help if you've forgotten a introduceSymbols line, or passed it
the wrong name.
These issues can be ameliorated as in your other post here, by
wrapping the template mixin statement as well. This leads to a
host of other problems - how do you specify arguments to the
mixin template? How do you deal with aliased mixin templates?
These issues may possibly be fixed, but it's gonna get ugly.
Can we perhaps do better? Could we somehow say at the
instantiation point 'please introduce all symbols in this mixin
into the instantiation scope even if there are hijackings.'?
Something like `mixin scope foo!();`? That seems possible to me.
If we write a DIP for it, I've a good feeling about getting that
into the language.
This issue shows up every now and then, so we know it's a real
issue, and the workarounds are clunky. At the same time, the
current behavior is there for a reason, and is very unlikely to
change.
--
Simen
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
--- Comment #2 from David Bennett ---
Disclaimer: Just a D user, I hold no decision making power or insight into the
history here.
const and immutable are runtime lvalues that have a known way to get "a" value
at compiletime. As you have noticed the runtime and compiletime values could be
different. Here is another example to show the same effect.
---
unittest {
immutable n = __ctfe ? 1 : 2;
enum j = n;
assert(n == j);
}
---
If you wanted to opt-in to making sure you could only use n at runtime you
could make it a `static immutable` but this has the effect of running the
assignment expression at compiletime.
I believe the current functionality is being used in various projects so I dont
see this being changed without at least a deprecation process. For example,
I've seen sending const variables as template parameters more than a few times.
As for my personal opinion on this issue, I believe using const and immutable
at compiletime is useful, it's just that the values could be different that's
confusing.
So I believe the current reasoning goes like this:
immutable values are theoretically known at compile time so why not use
them.
It's not always possible to ctfe so runtime immutable is assigned at
runtime.
But the runtime value is not known at compiletime, so when it's used we do
the ctfe then and error if it cant.
--
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 20:00:45 UTC, Maksim Fomin wrote: Just as rough estimate: to support $7.5 bl valuation Microsoft must turn -$30 ml. net loss company into business generating around $750 ml. for many years. There is no way to get these money from the market. Alternatively, the project can have payoff if something is broken and Microsoft cash flows increase by $750 ml. This is more likely... MS aims for cloud market, and github is a strategic asset there, as long as it helps the cloud business, it doesn't matter that github in isolation is not profitable. After MS takes over webdev and monopolizes the cloud market they can pull effective management again, but it will be a long way to go, but webdev being webdev can make it a little shorter. They were already kicked out of mobile market, it was reasonably unexpected, but it doesn't look like they plan to fall for it again.
Re: Mixin templates are a pain at best, useless at worst for any non-trivial use case
On Tuesday, 5 June 2018 at 10:11:49 UTC, Ethan wrote: And, honestly, with this method, I am already seeing the workaround. Because I've had to do it a ton of times already with other templates. Run a search for 'mixin( "import' in Binderoo to see how many times I've had to get around the changes to template visibility rules. Rather than do that though, now I'll have to iterate over every member of a stored mixin and alias them in to the surrounding object. I've had to go nuclear, in fact, to get this working. And resort to string mixins. https://run.dlang.io/is/O5PDaK So it works. But it doesn't Just Work(TM).
[Issue 18945] immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
Jonathan M Davis changed:
What|Removed |Added
CC||issues.dl...@jmdavisprog.co
||m
--- Comment #1 from Jonathan M Davis ---
Yeah. And bizarrely, this code actually results in an error about not being
able to call stuff during CTFE:
int foo()
{
import std.datetime;
return cast(int)Clock.currTime().stdTime;
}
void main()
{
immutable i = foo();
int[i] arr;
}
Getting rid of the declaration for arr fixes the problem. So, clearly, the
compiler is currently deciding whether it should do CTFE on an immutable, local
variable based on whether it's then used in a context where its value must be
known at compile time instead of forcing enum to be used instead. It also seems
to do the same with const.
The fact that the static array's size can use a local variable is completely
inconsistent with how CTFE normally works and makes the whole situation that
much more confusing. CTFE should only be kicking in based on whether the value
is actually needed at compile time and not based on whether the variable that
it's assigned to is then used at compile time.
--
Re: Confusion/trying to understand CTFE keywords
On Tuesday, June 05, 2018 11:18:05 Gopan via Digitalmars-d-learn wrote:
> On Tuesday, 5 June 2018 at 10:40:20 UTC, Simen Kjærås wrote:
> > On Tuesday, 5 June 2018 at 09:36:22 UTC, Gopan wrote:
> >> void main()
> >> {
> >>
> >> immutable n = __ctfe ? 1 : 2;
> >> int[n] a;
> >> assert(a.length == n); // fails, wat
> >>
> >> }
> >
> > That's gotta be a bug - that should give a 'variable n cannot
> > be read at compile time' error. The fact that n is immutable
> > shouldn't be enough to use it at compile time. Filed as
> > https://issues.dlang.org/show_bug.cgi?id=18945.
> >
> > --
> >
> > Simen
>
> Not only immutable. The behavior is same if you declare n as
> 'const int' also.
It's a bug either way. I suspect that someone made it work as an enhancement
request at some point on the theory that the variable was guaranteed to
always be the same, and they didn't take __ctfe into account. Regardless,
initializing a non-static, local variable shouldn't be triggering CTFE.
- Jonathan M Davis
Re: Confusion/trying to understand CTFE keywords
On Tuesday, 5 June 2018 at 10:40:20 UTC, Simen Kjærås wrote:
On Tuesday, 5 June 2018 at 09:36:22 UTC, Gopan wrote:
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}
That's gotta be a bug - that should give a 'variable n cannot
be read at compile time' error. The fact that n is immutable
shouldn't be enough to use it at compile time. Filed as
https://issues.dlang.org/show_bug.cgi?id=18945.
--
Simen
Not only immutable. The behavior is same if you declare n as
'const int' also.
Re: GitHub could be acquired by Microsoft
On Tuesday, 5 June 2018 at 03:53:31 UTC, Adam Wilson wrote: GitHub has not been profitable for years and is thought to have had cash reserves for only one or two more months of operations. Losing GitHub entirely overnight would have been an unmitigated disaster for the entire Open-Source community. Of course it had to be losing money..how else would they have convinced everyone it need to be aquired? That's long term business strategy at work ;-) And there are fates worse than death. Imagine for a second GitHub at Google or ... *shudder* Oracle. Whatever your opinions about Microsoft, you cannot possible imagine that either of those outcomes would have been qualitatively better. In that sense Microsoft was the best of the bad options GitHub. 'best of the bad options'? Now which company has done more for software development, besides Microsoft? Mostly closed source proprietary, sure, but still...(and that's changed a lot now!) I'm sure MS Linux will come out soon .. someone has to compete with Ubuntu. And sure, MS stopped a lot of other developers/apps from competing ...but hey, that's business...what else can we expect (from any for-profit, shareholder company). C# - Windows Forms - Database integration - anyone? I still program with them ;-) If I tried doing any one of my 'windows forms apps' on any open source solution/platform, the productivity loss alone would be immense. I also remember when I was programming DOS gui apps back in the early nineties - using Visual Basic 1.0 for DOS - it was just amazing how easy it was (even though it never caught on, cause Windows was about to become the next big thing.) Try doing those apps in Borland Cjeessseses...! MS have done more for software developers, than anyone, in my opinion. Now I'm not a fan of the MS cloud push at all, but for high productivity development tools and sophisticated applications, MS were always hard to beat. That is, until Windows 8 came out.. then it all went backwards...now its all that html javascript crap! or stupid useless apps on the ms apps store - or that god awful monstrosity that VS studio has become!! (I'm still on VS2010, using C# 4.0 and Windows Forms...and I'm not moving!) No doubt Github will just be integrated into their overall crappy vision of their cloud future... I hate cloud! Dump the tablet and mobile, and bring back the pc ( running Windows XP 64 bit, or course - where admin means admin!).
Re: SecureD moving to GitLab
On Tuesday, June 05, 2018 10:34:54 ExportThis via Digitalmars-d-announce wrote: > On Tuesday, 5 June 2018 at 06:55:42 UTC, Joakim wrote: > > This reads like a joke, why would it matter if you contributed > > to open source projects on an open platform that your employer > > runs? > > If you read between the lines, you can 'kinda' get the message. > > A Microsoft employee. > A Microsoft platform. > Encryption. > U.S Export Controls. > > How they all come together is anyones guess though ;-) > > That's why we have lawyers. Given that he works on SecureD, that could be part of it, but I don't think that exporting encryption is the problem that it once was in the US, and I'd think that the issue was more likely related to what Microsoft can claim to own. In general in the US, if your employer can claim that what you're doing in your free time is related to what you do for work, then they can claim that they own it. And if you're in a state with fewer employee protections, they can even claim to own everything you do in your free time regardless of whether it really has anything to do with any company intellectual property (e.g. a coworker at a previous company told me of a coworker who had gone to work at Bloomberg in NY after the division he was in was laid off, but he quit Bloomberg soon therefafter, because Bloomberg was going to claim to own everything he did in his free time - and he was a Linux kernel developer, so that would have caused serious problems for him). What paperwork you signed for your employer can also affect this. So, the exact situation you're in can vary wildly depending on where you live, who you work for, what exactly you do at work, and what exactly you do in your free time. If you want to sort out exactly what situation you're in, you do potentially need to see a lawyer about it. That whole set of issues may or may not be why Adam is moving his stuff to gitlab, but it does mean that you have to tread carefully when doing anything that relates at all to your employer or what you do for work. So, I can easily see it as a good idea to avoid doing anything in your free time with a site that is owned or operated by your employer. It may or may not actually be necessary, but playing it safe can avoid legal problems down the road, and typically, employees are going to have a _very_ hard time winning against employers in court, even if the employee is clearly in the right, simply because the legal fees stand a good chance of destroying the employee financially, whereas the employer can typically afford it. You simply don't want to be in a situation where your employer ever might try and do anything to you with the legal system - and of course, you don't want to be in a position where your employer fires you. So, an abundance of caution is sometimes warranted even if it arguably shouldn't need to be. - Jonathan M Davis
Re: Mixin templates are a pain at best, useless at worst for any non-trivial use case
On Tuesday, 5 June 2018 at 10:11:49 UTC, Ethan wrote: Exhibit A: https://run.dlang.io/is/a85Lbq [..snip..] I submitted a bug with the above code, and it was "helpfully" shut down with a link to the documentation and workaround. This looks like the bug report you are referring to: https://issues.dlang.org/show_bug.cgi?id=18944 I understand that the specification defines the current behavior and provides a workaround, but what's the justification for that behavior? Is it hygiene? I've been interested in improving mixins for reasons discussed in the interpolated strings PR (https://github.com/dlang/dmd/pull/7988) and this discussion about library-implemented properties (https://forum.dlang.org/post/mqveusvzkmkshrzws...@forum.dlang.org). Perhaps there's an opportunity here for a language improvement that would help all of these use cases. Mike
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 19:06:52 UTC, Maksim Fomin wrote: My second reaction after reading news (after shock) was to visit D forum. Same here! I was off for a few days and found out today on GitHub [1], and then I remembered the thread header talking about GitLab. I'm skeptical to say the least. I still remember how difficult it was to use Skype after it had been bought by MS. I dunno what's behind it. Polishing up their image, trying to get the copyright for all the code on GitHub, killing off OSS, or all of the above ;) MS have certainly missed a lot of stuff over the last couple of years, stuff that came out of or was based on the OSS community. Search engines, the success of Java, Android and the mobile phone market in general, social media etc. People will create and move to new platforms, simply because they don't like the thought of MS hosting their code (same goes for Google or Oracle). They will move to platforms made by their fellow programmers. Now, this will take some time and GitHub will do business as usual for at least a year. But the rot will set in sooner or later, I think. [1] e.g. https://blog.github.com/2018-06-04-github-microsoft/
Re: Confusion/trying to understand CTFE keywords
On Tuesday, 5 June 2018 at 09:36:22 UTC, Gopan wrote:
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}
That's gotta be a bug - that should give a 'variable n cannot be
read at compile time' error. The fact that n is immutable
shouldn't be enough to use it at compile time. Filed as
https://issues.dlang.org/show_bug.cgi?id=18945.
--
Simen
[Issue 18945] New: immutable variable is used as if it's an enum
https://issues.dlang.org/show_bug.cgi?id=18945
Issue ID: 18945
Summary: immutable variable is used as if it's an enum
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: CTFE
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
unittest {
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n);
}
The above assert fails - the value of n is calculated using CTFE for the length
of a, and is thus set to 1. Then, at runtime, the value of n is set to 2, and
the assert fails.
It seems to me the issue is that the variable n is being used as a compile-time
constant. The expected behavior is an error message along the lines of
'variable n cannot be read at compile time'.
--
Re: SecureD moving to GitLab
On Tuesday, 5 June 2018 at 06:55:42 UTC, Joakim wrote: This reads like a joke, why would it matter if you contributed to open source projects on an open platform that your employer runs? If you read between the lines, you can 'kinda' get the message. A Microsoft employee. A Microsoft platform. Encryption. U.S Export Controls. How they all come together is anyones guess though ;-) That's why we have lawyers.
[Issue 6447] iota(BigInt) too
https://issues.dlang.org/show_bug.cgi?id=6447
Russel Winder changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME |---
--- Comment #17 from Russel Winder ---
Using LDC on Debian Sid, the code:
import std.bigint: BigInt;
import std.range: iota;
void main() {
auto x = iota(BigInt(10));
}
compiles and executes fine, but the code:
void main() {
import std.bigint: BigInt;
import std.range: iota;
iota(BigInt(1), BigInt(100), BigInt(5));
iota(BigInt(1), BigInt(100), 5);
}
results in:
test_b.d(4): Error: template std.range.iota cannot deduce function from
argument types !()(BigInt, BigInt, BigInt), candidates are:
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5371):
std.range.iota(B, E, S)(B begin, E end, S step) if ((isIntegral!(CommonType!(B,
E)) || isPointer!(CommonType!(B, E))) && isIntegral!S)
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5481):
std.range.iota(B, E)(B begin, E end) if (isFloatingPoint!(CommonType!(B, E)))
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5488):
std.range.iota(B, E)(B begin, E end) if (isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E)))
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5558):
std.range.iota(E)(E end) if (is(typeof(iota(E(0), end
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5567):
std.range.iota(B, E, S)(B begin, E end, S step) if
(isFloatingPoint!(CommonType!(B, E, S)))
test_b.d(4):... (1 more, -v to show) ...
test_b.d(5): Error: template std.range.iota cannot deduce function from
argument types !()(BigInt, BigInt, int), candidates are:
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5371):
std.range.iota(B, E, S)(B begin, E end, S step) if ((isIntegral!(CommonType!(B,
E)) || isPointer!(CommonType!(B, E))) && isIntegral!S)
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5481):
std.range.iota(B, E)(B begin, E end) if (isFloatingPoint!(CommonType!(B, E)))
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5488):
std.range.iota(B, E)(B begin, E end) if (isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E)))
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5558):
std.range.iota(E)(E end) if (is(typeof(iota(E(0), end
/usr/lib/ldc/x86_64-linux-gnu/include/d/std/range/package.d(5567):
std.range.iota(B, E, S)(B begin, E end, S step) if
(isFloatingPoint!(CommonType!(B, E, S)))
test_b.d(5):... (1 more, -v to show) ...
Using dmd from d-apt the first code works fine and the second code results in:
test_b.d(4): Error: template `std.range.iota` cannot deduce function from
argument types `!()(BigInt, BigInt, BigInt)`, candidates are:
/usr/include/dmd/phobos/std/range/package.d(5890):`std.range.iota(B, E,
S)(B begin, E end, S step) if ((isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E))) && isIntegral!S)`
/usr/include/dmd/phobos/std/range/package.d(6000):`std.range.iota(B,
E)(B begin, E end) if (isFloatingPoint!(CommonType!(B, E)))`
/usr/include/dmd/phobos/std/range/package.d(6007):`std.range.iota(B,
E)(B begin, E end) if (isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E)))`
/usr/include/dmd/phobos/std/range/package.d(6077):`std.range.iota(E)(E
end) if (is(typeof(iota(E(0), end`
/usr/include/dmd/phobos/std/range/package.d(6086):`std.range.iota(B, E,
S)(B begin, E end, S step) if (isFloatingPoint!(CommonType!(B, E, S)))`
test_b.d(4):... (1 more, -v to show) ...
test_b.d(5): Error: template `std.range.iota` cannot deduce function from
argument types `!()(BigInt, BigInt, int)`, candidates are:
/usr/include/dmd/phobos/std/range/package.d(5890):`std.range.iota(B, E,
S)(B begin, E end, S step) if ((isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E))) && isIntegral!S)`
/usr/include/dmd/phobos/std/range/package.d(6000):`std.range.iota(B,
E)(B begin, E end) if (isFloatingPoint!(CommonType!(B, E)))`
/usr/include/dmd/phobos/std/range/package.d(6007):`std.range.iota(B,
E)(B begin, E end) if (isIntegral!(CommonType!(B, E)) ||
isPointer!(CommonType!(B, E)))`
/usr/include/dmd/phobos/std/range/package.d(6077):`std.range.iota(E)(E
end) if (is(typeof(iota(E(0), end`
/usr/include/dmd/phobos/std/range/package.d(6086):`std.range.iota(B, E,
S)(B begin, E end, S step) if (isFloatingPoint!(CommonType!(B, E, S)))`
test_b.d(5):... (1 more, -v to show) ...
So I think this problem is not fixed.
--
Mixin templates are a pain at best, useless at worst for any non-trivial use case
I've come across this before with Binderoo, but now I've got really simple use cases. Rather than having one unmaintainable mess of a file that handles everything (for a really egregious example, see std.datetime.systime which has the distinction of both its source code and documentation being unreadable), I decided to do something similar to C#'s partial classes and use mixin templates declared in other modules to complete the implementation. This is all well and good until you get to dealing with function overloads. Exhibit A: https://run.dlang.io/is/a85Lbq As soon as you have an overload of a function declared in the base object you're mixing in to, any other overload mixed in will not resolve correctly. Great. The core use case I derived this from is client/server message handling, and I plan on reusing mixins across client/server types since message handling will also require variables added in to the object to do so. Simple example: Handling Ping and Pong will require the Ping sender to start a timer and resolve it on receiving Pong. The partial class model is perfect for this, and mixins are the closest we have to this. I submitted a bug with the above code, and it was "helpfully" shut down with a link to the documentation and workaround. Congratulations. That's not the use case here, and to be quite honest this is one of those examples where a #define macro would "just work". And I'm firmly of the view that *ANY* example of that should be dealt with at a language level in order to completely remove the argument of needing a preprocessor. Exhibit B: https://run.dlang.io/is/s2BJUO This one fired as soon as Binderoo tried to do its thing: Doing an allMembers pass of the object will list your entirely-mixed-in overload as a member, but attempting to get that member will resolve the symbol to void. Great. So functions that otherwise completely resolve as a member of a class actually don't resolve as a member of a class? Huh? I don't even. To see where I'm going with this, exhibit C: https://run.dlang.io/is/KWN9yA Rather than mixin things one by one and manually handle errors and language shortcomings, I'm using helpers to wholesale add functionality to my object. And, honestly, with this method, I am already seeing the workaround. Because I've had to do it a ton of times already with other templates. Run a search for 'mixin( "import' in Binderoo to see how many times I've had to get around the changes to template visibility rules. Rather than do that though, now I'll have to iterate over every member of a stored mixin and alias them in to the surrounding object. Sigh. I know that simply posting this will result in a thread of people offering workarounds. I don't need or want them. Why? Because the next person that tries to do this will have the same problems. And rather than the "correct" way to do this be voodoo knowledge found by a Google search if you're lucky, I would far prefer this thread become a discussion on how to improve mixins so that a DIP can be written and resolved. So that the next person can express language as simply as possible and have it all Just Work(TM).
Re: Can anyone explain this?
On Tuesday, 5 June 2018 at 09:03:03 UTC, Simen Kjærås wrote:
On Tuesday, 5 June 2018 at 08:26:22 UTC, Nicholas Wilson wrote:
writeln("Assert"); // this is not caught because the thrown
throwable is not an exception
Now that's plain false - If you replace the call to
throwingFunc() with a string literal, you'll see it's properly
caught. Also, the catch clause explicitly specifies
AssertError, which as the name implies, is an Error, not an
Exception.
Whoops I meant _is_.
However, if we add catch (Throwable ex) to the list of catch
statements, that *does* catch a regular object.Exception.
Moving the catch (Exception) statement down the list does
nothing. Adding another layer of try-catch also catches it
(even with just catch (Exception ex)):
That does seem odd but is consistent with the implicit "try"
surrounding Dmain inserted by the runtime.
import std.stdio;
import core.exception;
unittest {
scope(failure) {
writeln("Not gonna happen");
}
try {
try {
static string throwingFunc() {
throw new Exception("An exception");
}
assert(0==1, throwingFunc());
} catch(AssertError ex) {
writeln("Assert");
} catch(Exception ex) {
writeln("Exception A");
}
} catch(Exception ex) {
writeln("Exception B");
}
}
So I'm stumped. It seems the exception handling is simply not
setup correctly. This could be because of UB I guess, but I'd
hope the AssertError would be thrown first in such a case.
The assert error will never be thrown because one of the
parameters to the __assert_fail throws. Its like as if you had
written.
if (0==1)
{
string tmp = throwingFunc(); // throws
__assert_fail(tmp,__LINE__,...); // dead code.
}
Actually it may be the compiler doing something funky with
assert(0, msg); being special (assert(0,...) since the spec says
for assert any compile time expression == 0 has the effect of
assert(0). i.e. assert(0==1); is the same as assert(0);).
Proof
import std.stdio;
import core.exception;
bool foo() { return false;} // mess with the compiler's reasoning
about the truthiness of the assert
void main() {
scope(failure) {
writeln("Not gonna happen");
}
try {
static string throwingFunc() {
throw new Exception("An exception");
}
assert(foo(), throwingFunc());
} catch(Exception ex) {
writeln("Exception");
} catch(AssertError ex) {
writeln("Assert");
}
}
prints
Exception
[Issue 18936] Internal error: dmd/backend/cgxmm.c 684
https://issues.dlang.org/show_bug.cgi?id=18936 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/d2884aa5a06f59ec6f4c4ae48ef864037c4d238f fix Issue 18936 - Internal error: dmd/backend/cgxmm.c 684 https://github.com/dlang/dmd/commit/6a210604e16ad1fc64406abec99c5d1b74072b9b Merge pull request #8326 from WalterBright/cgxmm684 fix Issue 18936 - Internal error: dmd/backend/cgxmm.c 684 merged-on-behalf-of: Walter Bright --
[Issue 18936] Internal error: dmd/backend/cgxmm.c 684
https://issues.dlang.org/show_bug.cgi?id=18936 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Confusion/trying to understand CTFE keywords
On Sunday, 3 June 2018 at 21:32:06 UTC, gdelazzari wrote:
Couldn't a keyword like "ctfe" (just making it up right now)
exist? So that, when seeing something like
ctfe myNumber = 5;
ctfe if (myNumber + 2 == 7)
{
// ...
}
one could immediately understand that the code is
executed/evaluated at compile time. True, after someone knows
that "static" and "enum" mean (in the above example) that some
compile-time things are happening, it's fine. I just find it a
bit confusing not having a dedicated keyword but re-using
existing ones that also serve other purposes...
Hi gdelazzari,
While seeing your post, I just recollected my post 4 years ago.
https://forum.dlang.org/post/wbfnvwulchrpnrxov...@forum.dlang.org
I recommend you to go through it. Let me put here my thoughts
again.
void main()
{
immutable n = __ctfe ? 1 : 2;
int[n] a;
assert(a.length == n); // fails, wat
}
Here, the declaration int[n] a forces n to be calculated during
compile time. During compile time, __ctfe is true (I dont know
if it a variable or macro, etc). Hence the value of n during
compile time is 1. So, size of the array a is 1. Anyway, n is
calculated during runtime too. At runtime, __ctfe is false. n
becomes 2. Finally, at runtime a.length is 1 and n is 2.
This shocked me. ie While reading a huge code, you need to check
how you got the value of n, which I personally dont want to.
While this scared me away, I thought about it. What is the
underlying problem? My immediate answer is that the same
variable getting computed during both compile time and runtime
caused this issue. Why should a variable get a new value at
runtime if it has already got a value during compile time, for
the same statement?
May be I am less imaginative. I still wish some could enlighten
me to accept this behavior if everybody else thinks it is right.
Regards,
Gopan
