Re: This thread on Hacker News terrifies me
On 09/01/2018 09:15 AM, Jonathan M Davis wrote: I don't know if any DVD players have ever used Java, but all Blu-ray players do require it, because unfortunately, the Blu-ray spec allows for the menus to be done via Java (presumably so that they can be fancier than what was possible on DVDs). DVDs (PUOs)...BluRays (Java)...Web... All evidence that the more technical power you give content creators, the bigger the design abominations they'll subject the world to ;) [1] I actually once came across a professionally-produced, major-studio BluRay where pressing Pause didn't pause the video, but actually made it deliberately switch over to and play a *different* video instead. This is why a good system is one that automatically does the right thing by default, and makes you work to do the wrong thing...if it's even important enough to have the escape hatch. [1] That, of course, is not an "us-vs-them" statement: Programmers are by definition content creators, too!
Re: This thread on Hacker News terrifies me
On 09/02/2018 12:53 AM, Jonathan M Davis wrote: Ouch. Seriously, seriously ouch. Heh, yea, well...that particular one was state party school, so, what y'gonna do? *shrug* Smug as I may have been at the at the time, it wasn't until later I realized the REAL smart ones were the ones out partying, not the grads or the nerds like me. Ah, young hubris ;) (Oh, the computer art students, BTW, were actually really fun to hang out with! I think they probably managed to hit the best balance of work & play.)
DIP25/DIP1000: My thoughts round 2
Round 2 because I had this whole thing typed up, and then my
power went out on me right before I posted. I was much happier
with how that one was worded too.
Basically I'd like to go over at length one of the issues I see
with these DIPs (though I think it applies more to DIP1000),
namely return parameters and what we could do to make them
stronger. I will say I do not have the chops to go implement
these ideas myself, even if I had approval and support. This is
more to get my thoughts out there and see what other people think
about them (frankly I'd be putting this in Study if it wasn't a
ghost town over there).
First I'm going to reiterate over DIP25 as I understand it for
background, stealing some examples from the DIP page. Let's
starting with the following.
ref int id(ref int x) {
return x; // pass-through function that does nothing
}
ref int fun() {
int x;
return id(x); // escape the address of local variable
}
The id() function just takes and returns a variable by ref, which
is perfectly legal. However it is open to abuse. As you see in
fun(), id() is used to escape a reference to a local variable,
which is obviously not desired behavior. The issue is how do we
tell fun(), from id()'s signature alone, "id() will return a
reference to whatever you pass it, one way or another. Make sure
you don't give id()'s return value to something that'll outlive
the argument you pass to id()" (though we need to say this in
more concise terms obviously). DIP25 solves this pretty nicely
with return parameters
// now this function is banned, since it has a ref parameter and
returns by ref
ref int wrongId(ref int x) {
return x; // ERROR! Cannot return a ref, please use "return
ref"
}
// this is fine however
ref int id(return ref int x) {
return x;
}
ref int fun() {
int x;
static int y;
return id(x); // no, wait, since we're returning to a scope
that'll outlive x, this errors at compile-time. Thanks return ref
return id(y); // fine, sure, y lives forever
}
fun() now knows the return value of id() cannot outlive the
argument it passes to id(). This allows us to disallow certain
undesired behavior at compile-time, which is great.
With that in mind, let's move on to DIP1000. Namely, I'm looking
at this issue Walter filed.
https://issues.dlang.org/show_bug.cgi?id=19097
I'll try to detail it here (and steal more examples, thanks Mike
:*) ). It has to do with the same principles I outlined above for
DIP25, only this time we're using pointers rather than refs.
First example, which works as expected
int* frank(return scope int* p) { return p; } // basically id()
void main()
{
// lifetimes end in reverse order from which they are declared
int* p; // `p`'s lifetime is longer than `i`'s
int i; // `i`'s lifetime is longer than `q`'s
int* q; // `q`'s lifetime is the shortest
q = frank(); // ok because `i`'s lifetime is longer than
`q`'s
p = frank(); // error because `i`'s lifetime is shorter
than `p`'s
}
frank() marks its parameter as return, to signal to main() that
wherever main() puts frank()'s return value, it can't outlive
what main() passed as an argument to frank(). All fine and dandy.
Second example (I'd pay closer attention to betty()'s definition
here)
void betty(ref scope int* r, return scope int* p)
{
r = p; // (1) Error: scope variable `p` assigned to `r` with
longer lifetime
}
void main()
{
int* p;
int i;
int* q;
betty(q, ); // (2) ok
betty(p, ); // (3) should be error
}
Hang on, why can't I compile betty(), when it's doing the same
thing as frank(), only putting the return value in the first
parameter rather than returning it? No reason, I absolutely
should be able to compile and use betty(). So the question
becomes, how can betty() tell main(), that what main() passes as
the first argument to betty() can't outlive what's passed as the
second argument? Marking the second parameter return does not
work here, as that only ties its lifetime to the return value. It
can't be used on arbitrary parameters. How to resolve this?
Walter's solution is as follows. If a function is void, and its
first parameter is ref, apply the "return" annotation to the
first parameter rather than the return value of the function.
Using these conditions, betty() now compiles, and main() errors
at (3) as expected. However I find this solution too restrictive.
While it fits many functions within Phobos, we are tying users to
this special case and forcing them to unnecessarily refactor
their code around it. What if I don't want it to be void and want
the function to return something as well? What if I want to
return via the second parameter? This just seems to be setting up
another trap for users to fall into.
I talked about this in the "Is @safe still a work-in-progress?"
thread, but I'll repeat it here again. There is a cleaner way to
do this. I'll
Re: This thread on Hacker News terrifies me
On 09/01/2018 02:15 AM, Ola Fosheim Grøstad wrote: The root cause of bad software is that many programmers don't even have an education in CS or software engineering, or didn't do a good job while getting it! Meh, no. The root cause trifecta is: A. People not caring enough about their own craft to actually TRY to learn how to do it right. B. HR people who know nothing about the domain they're hiring for. C. Overall societal reliance on schooling systems that: - Know little about teaching and learning, - Even less about software development, - And can't even decide whether their priorities should be "pure theory *without* sufficient practical" or "catering to the above-mentioned HR folk's swing-and-miss, armchair-expert attempts at defining criteria for identifying good programmers" (Hint: The answer is "neither").
DCD 0.9.11 & D-Scanner 0.5.10
Both compatible with syntax changes coming with 2.082. https://github.com/dlang-community/DCD/releases/tag/v0.9.11 https://github.com/dlang-community/D-Scanner/releases/tag/v0.5.10
Re: This thread on Hacker News terrifies me
On Saturday, September 1, 2018 10:44:57 PM MDT Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > On 09/01/2018 01:51 AM, rikki cattermole wrote: > > But in saying that, we had third year students starting out not > > understanding how cli arguments work so... > > How I wish that sort of thing surprised me ;) > > As part of the generation that grew up with BASIC on 80's home > computers, part of my spare time in high school involved some PalmOS > development (man I miss PalmOS). Wasn't exactly anything special - you > pony up a little $ for Watcom (or was it Borland?), open the IDE, follow > the docs, do everything you normally do. Read a book. Yawn. After that, > in college, had a job working on Palm and WAP websites (anyone remember > those? Bonus points if you remember the Palm version - without WiFi or > telephony it was an interesting semi-mobile experience). > > Imagine my shock another year after that when I saw the college I was > attending bragging how their computer science *graduate* students...with > the help and guidance of a professor...had gotten a hello world "running > on an actual Palm Pilot!" Wow! Can your grad students also tie their own > shoes and wipe their own noses with nothing more than their own wits and > somebody else to help them do it??? Because, gee golly, that would be > one swell accomplishment! Wow! Hold your hat, Mr. Dean, because Ivy > League, here you come!! Ouch. Seriously, seriously ouch. - Jonathan M Davis
Re: This thread on Hacker News terrifies me
On 09/01/2018 01:51 AM, rikki cattermole wrote: But in saying that, we had third year students starting out not understanding how cli arguments work so... How I wish that sort of thing surprised me ;) As part of the generation that grew up with BASIC on 80's home computers, part of my spare time in high school involved some PalmOS development (man I miss PalmOS). Wasn't exactly anything special - you pony up a little $ for Watcom (or was it Borland?), open the IDE, follow the docs, do everything you normally do. Read a book. Yawn. After that, in college, had a job working on Palm and WAP websites (anyone remember those? Bonus points if you remember the Palm version - without WiFi or telephony it was an interesting semi-mobile experience). Imagine my shock another year after that when I saw the college I was attending bragging how their computer science *graduate* students...with the help and guidance of a professor...had gotten a hello world "running on an actual Palm Pilot!" Wow! Can your grad students also tie their own shoes and wipe their own noses with nothing more than their own wits and somebody else to help them do it??? Because, gee golly, that would be one swell accomplishment! Wow! Hold your hat, Mr. Dean, because Ivy League, here you come!!
[Issue 19211] New: [REG 2.072] cant get the type of a non-const delegate in a const function
https://issues.dlang.org/show_bug.cgi?id=19211
Issue ID: 19211
Summary: [REG 2.072] cant get the type of a non-const delegate
in a const function
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: diagnostic, rejects-valid
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
This used to be possible:
struct Foo
{
void func1(){}
void func2() const
{alias Fun = typeof();}
}
until FE 2.072 but now produces the following error message:
> Error: mutable method `Foo.func1` is not callable using a `const` `this`
What's sure:
- this should work always inside `typeof()` since the intention is not to use
the delegate.
- the error message is wrong for the same reason.
What's less sure:
- should `` always working as long as not called ?
For now the following workaround has to be used:
alias Fun = typeof(&(cast()this).func1);
--
Re: This thread on Hacker News terrifies me
On 08/31/2018 07:20 PM, H. S. Teoh wrote: The problem is that there is a disconnect between academia and the industry. The goal in academia is to produce new research, to find ground-breaking new theories that bring a lot of recognition and fame to the institution when published. It's the research that will bring in the grants and enable the institution to continue existing. As a result, there is heavy focus on the theoretical concepts, which are the basis for further research, rather than pragmatic tedium like how to debug a program. I don't know where you've been but it doesn't match anything I've ever seen. Everything I've ever seen: The goal in academia is to advertise impressive-looking rates for graduation and job placement. This maximizes the size of the application pool which, depending on the school, means one of two things: 1. More students paying ungodly tuition rates. Thus making the schools and their administrators even richer. (Pretty much any public liberal arts school.) or 2. Higher quality students (defined by the school as "more likely to graduate and more likely to be placed directly in a job"), thus earning the school the right to demand an even MORE ungodly tuition from the fixed-size pool of students they accept. Thus making the schools and their administrators even richer. (Pretty much any private liberal arts school.) Achieving the coveted prize of "We look attractive to applicants" involves: First: As much of a revolving-door system as they can get away with without jeopardizing their accreditation. And secondly: Supplementing the basic Computer Science theory with awkward, stumbling, half-informed attempts at placating the industry's brain-dead, know-nothing HR monkeys[1] with the latest hot trends. For me, at the time, that meant Java 2 and the "Thou must OOP, for OOP is all" religion. [1] "I don't know anything about programming, but I'm good at recognizing people who are good at it." <-- A real quote from a real HR monkey I once made the mistake of attempting basic communication with. But then, let's not forget that schools have HR, too. Which leads to really fun teachers like the professor I had for a Computer Networking class: He had a PhD in Computer Science. He would openly admit that C was the only language he knew. Ok, fair enough so far. But...upon my explaining to him how he made a mistake grading my program, I found *myself* forced to teach the *Computer Science professor* how strings (remember...C...null-terminated) worked in the *only* language he knew. He had NO freaking clue! A freakin' CS PhD! Forget "theory vs practical" - if you do not know the *fundamental basics* of EVEN ONE language, then you *CANNOT* function in even the theoretical or research realms, or teach it. Computer science doesn't even *exist* without computer programming! Oh, and this, BTW, was a school that pretty much any Clevelander will tell you "Oh! Yea, that's a really good school, it has a fantastic reputation!" Compared to what? Ohio State Football University?
Re: This thread on Hacker News terrifies me
On Saturday, September 1, 2018 9:18:17 PM MDT Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > On 08/31/2018 03:50 PM, Walter Bright wrote: > [From your comment in that thread] > > > fill up your system disk to near capacity, then try to run various > > apps and system utilities. > > I've had that happen on accident once or twice recently. KDE does NOT > handle it well: *Everything* immediately either hangs or dies as soon as > it gains focus. Well, I guess could be worse, but it still really irks > me: "Seriously, KDE? You can't even DO NOTHING without trying to write > to the disk? And you, you other app specifically designed for dealing > with large numbers of large files, why in the world would you attempt to > write GB+ files without ever checking available space?" I suspect that if KDE is choking, it's due to issues with files in /tmp, since they like to use temp files for stuff, and I _think_ that some of it is using unix sockets, in which case they're using the socket API to talk between components, and I wouldn't ever expect anyone to check disk space with that - though I _would_ expect them to check for failed commands and handling it appropriately, even if the best that they can do is close the program with a pop-up. I think that what it ultimately comes down to though is that a lot of applications treat disk space like they treat memory. You don't usually check whether you have enough memory. At best, you check whether a particular memory allocation succeeded and then try to handle it sanely if it failed. With D, we usually outright kill the program if we fail to allocate memory - and really, if you're using std.stdio and std.file for all of your file operations, you'll probably get the same thing, since an exception would be thrown on write failure, and if you didn't catch it, then it will kill your program (though if you do catch it, it obviously can vary considerably what happens). The C APIs on the other hand require that you check the return value, and some of the C++ APIs require the same. So, if you're not doing that right, you can quickly get your program into a weird state if functions that you expect to always succeed start failing. So honestly, I don't find it at all surprising when an application can't handle not being able to write to disk. Ideally, it _would_ handle it (even if it's simply by shutting down, because it can't handle not having enough disk space), but for most applications, it really is thought of like running out of memory. So, isn't tested for, and no attempt is made to make it sane. I would have hoped that something like KDE would have sorted it out by now given that it's been around long enough that more than one person would have run into the problem and complained about it, but given that it's a suite of applications developed in someone's free time, it wouldn't surprise me at all if the response was to just get more disk space. Honestly, for some of this stuff, I think that the only way that it's ever going to work sanely is if extreme failure conditions result in Errors or Exceptions being thrown, and the program being killed. Most code simply isn't ever going to be written to handle such situations, and a for a _lot_ of programs, they really can't continue without those resources - which is presumably, why the way D's GC works is to throw an OutOfMemoryError when it can't allocate anything. Anything C-based (and plenty of C++-based programs too) is going to have serious problems though thanks to the fact that C/C++ programs often use APIs where you have to check a return code, and if it's a function that never fails under normal conditions, most programs aren't going to check it. Even diligent programmers are bound to miss some of them. - Jonathan M Davis
Re: This thread on Hacker News terrifies me
On 09/01/2018 05:06 PM, Ola Fosheim Grøstad wrote: If you have a specific context (like banking) then you can develop a software method that specifies how to build banking software, and repeat it, assuming that the banks you develop the method for are similar Of course, banking has changed quite a lot over the past 15 years (online + mobile). Software often operates in contexts that are critically different and that change in somewhat unpredictable manners. Speaking of, that always really gets me: The average ATM is 24/7. Sure, there may be some downtime, but what, how much? For the most part, these things were more or less reliable decades ago, from a time with *considerably* less of the "best practices" and accumulated experience, know-how, and tooling we have today. And over the years, they still don't seem to have screwed ATMs up too badly. But contrast that to my bank's phone "app": This thing *is* rooted firmly in modern technology, modern experience, modern collective knowledge, modern hardware and...The servers it relies on *regularly* go down for several hours at a time during the night. That's been going on for the entire 2.5 years I've been using it. And for about an hour the other day, despite using the latest update, most of the the buttons on the main page were *completely* unresponsive. Zero acknowledgement of presses whatsoever. But I could tell the app wasn't frozen: The custom-designed text entry boxes still handled focus events just fine. Tech from 1970's: Still working fine. Tech from 2010's: Pfffbbttt!!! Clearly something's gone horribly, horribly wrong with modern software development.
Re: This thread on Hacker News terrifies me
On 08/31/2018 05:09 PM, H. S. Teoh wrote: It's precisely for this reason that the title "software engineer" makes me cringe on the one hand, and snicker on the other hand. I honestly cannot keep a straight face when using the word "engineering" to describe what a typical programmer does in the industry these days. Science is the reverse-engineering of reality to understand how it works. Engineering is the practical application of scientific knowledge. I don't know, maybe those are simplified, naive definitions. But I've long been of the opinion that programming is engineering...*if* and only if...you're doing it right. Of course, my background is primarily from programming itself, not from an existing engineering field, so I certainly won't claim that what I do necessarily qualifies as "engineering", but it is something I try to aspire to, FWIW.
Re: This thread on Hacker News terrifies me
On 08/31/2018 03:50 PM, Walter Bright wrote: https://news.ycombinator.com/item?id=17880722 Typical comments: "`assertAndContinue` crashes in dev and logs an error and keeps going in prod. Each time we want to verify a runtime assumption, we decide which type of assert to use. We prefer `assertAndContinue` (and I push for it in code review)," Yea, that one makes me cringe. I could at least understand "unwind the stack 'till you're at least out of this subsystem, and THEN MAYBE abort/retry (but not ignore)", though I know you disagree on that. But to just...continue as if nothing happened...Ugh. Just reminds me of common dynamic scripting language design and why I never liked those languages: If the programmer wrote something nonsensical, best to do something completely random instead of giving them an error message! "Stopping all executing may not be the correct 'safe state' for an airplane though!" Honestly, comments like this suggest to me someone who's operating under the false assumption that "stop all executing" means "permanently stop all of the software running on all components of the plane" rather than "stop (and possibly restart) one of several redundant versions of one particular subsystem". Which suggests they only read comments and not the article. Interestingly, the same user also said: "Software development often does seem like a struggle between reliability/robustness and safety/correctness." WAT?! That's like saying, "Speaker design often seems like a struggle between loudness versus volume." Each one *requires* the other. Scary. "One faction believed you should never intentionally crash the app" I can understand how people may naively come to that conclusion: "Duh, crashing is bad, so why would you do it intentionally?" But, of course, the reasoning is faulty. There's also the "It depends on your industry/audience. You're talking airplanes, but my software isn't critical enough to bother with the same principles." I wonder if it might help to remind such people that's *exactly* how MS ended up with Windows Me: This is well-known: After Win3.11, MS decided that businesses required more reliability from their OS than the home users needed. So they split Windows into two product lines: WinNT for business (more focus on reliability) and Win95 for home (speed and features were more important). Things started out mostly ok. Win95 wasn't quite as reliable as NT, but not a gigantic difference, and it was expected. Then Win98...some more issues, while NT stayed more or less as-was. Then WinMe hit. BOOM! By that point, the latest in the WinNT line was "Win2k", which was STILL regarded as pretty well stable, so MS did what's probably the smartest move they've ever made: Killed off the 9x/Me codebase, added DirectX to Win2k and called it "WinXP". And it spent a whole decade widely hailed as the first ever home version of Windows to not be horrible. So yea, I don't care how non-critical you think your software is. If it's worth using, then it's important enough. And on and on. It's unbelievable. The conventional wisdom in software for how to deal with programming bugs simply does not exist. In my observation, there doesn't seem to be much conventional wisdom in software in general. Everything, no matter how basic or seemingly obvious, is up for big, major debate. (Actually, not even restricted to programming.) [From your comment in that thread] > fill up your system disk to near capacity, then try to run various apps and system utilities. I've had that happen on accident once or twice recently. KDE does NOT handle it well: *Everything* immediately either hangs or dies as soon as it gains focus. Well, I guess could be worse, but it still really irks me: "Seriously, KDE? You can't even DO NOTHING without trying to write to the disk? And you, you other app specifically designed for dealing with large numbers of large files, why in the world would you attempt to write GB+ files without ever checking available space?" Seriously, nothing in tech ever improves. Every step forward comes with a badly-rationalized step back. Things just get shuffled around, rubble gets bounced, trends get obsessively chased in circles, and ultimately there's little, if any, overall progress. "What Andy giveth, Bill taketh away." Replace Andy/Bill with any one of thousands of different pairings, it still holds. And there's no motivation for any of it to change. Capitalism rewards those who make more money by selling more flashy garbage that's bad enough to create more need for more garbage to deal with the flaws from the last round of garbage. It doesn't reward those who make a better product that actually reduces need for more. Sometimes something decent will come along, and briefly succeed by virtue of being good. But it's temporary and inevitably gets killed off by the next positive feedback loop of inferiority.
Re: John Regehr on "Use of Assertions"
On Saturday, September 1, 2018 2:15:15 PM MDT Walter Bright via Digitalmars- d wrote: > https://blog.regehr.org/archives/1091 > > As usual, John nails it in a particularly well-written essay. > > "ASSERT(expr) > Asserts that an expression is true. The expression may or may not be > evaluated. If the expression is true, execution continues normally. > If the expression is false, what happens is undefined." > > Note the "may or may not be evaluated." We've debated this here before. > I'm rather pleased that John agrees with me on this. I.e. the optimizer > can assume the expression is true and use that information to generate > better code, even if the assert code generation is turned off. Personally, my concern about letting the compiler optimize based on assertions has to do with whether it violates @safe. IMHO, it defeats the purpose of @safe if adding an assertion can result in @system code due to optimizations. I'm fine with it optimizing so long as the optimizations will not result in @safe code becoming @system in the case where the assertion would have failed if it were compiled in. If @safe allows @system optimizations than it isn't actually @safe, because while we don't want assertions to ever turn out to be false, they sometimes do turn out to be false, and if they're not compiled in, it's not going to be caught. That then is obviously a bug, but at least it isn't one that's going to corrupt memory (at least if it's in @safe code), but if the compiler is allowed to optimize based on the assertion to the point that the code could corrupt memory if the assertion would have failed, then that's a serious problem and a total violation of the promises made by @safe. And actually, it can't add @system optimizations even in @system code, because that completely defeats the ability of the programmer to verify the code for @safety in order to use @trusted. If the compiler can add @safe optimizations based on assertions, then that's fine with me (though I know that some others don't agree), but they have to be @safe even when the assertion would have failed if it were compiled in. If they're ever @system, then @safe isn't actually @safe. - Jonathan M Davis
Re: DMD cross compiler
On Sat, 1 Sep 2018 at 18:55, Joakim via Digitalmars-d wrote: > > On Saturday, 1 September 2018 at 20:12:24 UTC, Manu wrote: > > I know there's been discussion on this before, I just want a > > definitive reference. > > > > It looks like it would be relatively straight forward for DMD > > to be a > > cross-compiler. > > A few version() statements could be runtime if's, and that's > > pretty much it. > > When hacking on parts of DMD, I frequently make hacks that turn > > such > > versions into runtime if's to test multiple targets from the > > one dev > > workflow. > > > > It would be about 100 times more convenient to supply an arg, > > than make hacks all over the code... so, why not? > > What specifically do you want to cross-compile to, something like > Windows to macOS? LDC already does all this, ie the one compiler > cross-compiles to every other platform with a single flag, may > just want to use it. Yes, but we're talking about DMD...
Re: -op can be quite strange
On Saturday, 1 September 2018 at 23:29:01 UTC, Nicholas Wilson wrote: On Saturday, 1 September 2018 at 14:48:55 UTC, Jonathan Marler wrote: Note that we would want this to be a new option so as not to break anyone depending on "-op" semantics. Maybe "-om" for "output path based on 'Module' name"? LDC has this already as -oq, FWIW. I knew those LDC folks were smart :) Has there been any attempt to add -oq to dmd?
Re: John Regehr on "Use of Assertions"
On 9/1/2018 5:47 PM, Nick Sabalausky (Abscissa) wrote: All in all, John is very non-committal about the whole thing. He probably got tired of arguing about it :-)
Re: DMD cross compiler
On Saturday, 1 September 2018 at 20:12:24 UTC, Manu wrote: I know there's been discussion on this before, I just want a definitive reference. It looks like it would be relatively straight forward for DMD to be a cross-compiler. A few version() statements could be runtime if's, and that's pretty much it. When hacking on parts of DMD, I frequently make hacks that turn such versions into runtime if's to test multiple targets from the one dev workflow. It would be about 100 times more convenient to supply an arg, than make hacks all over the code... so, why not? What specifically do you want to cross-compile to, something like Windows to macOS? LDC already does all this, ie the one compiler cross-compiles to every other platform with a single flag, may just want to use it.
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 01:05:10 UTC, Martin Nowak wrote: Glad to announce D 2.082.0. The Windows installer gave me no warning messages this time. Thanks, everyone. Mike
Release D 2.082.0
Glad to announce D 2.082.0. This release comes with more efficient update functions for associative arrays, unsafe code in debug blocks, UDAs for function parameters, an improved dependency resolution and avoidance of online update checks for dub, and signed Windows binaries. http://dlang.org/download.html http://dlang.org/changelog/2.082.0.html -Martin
Re: Engine of forum
On 09/01/2018 07:46 PM, Walter Bright wrote: On 9/1/2018 3:58 PM, Adam D. Ruppe wrote: On Saturday, 1 September 2018 at 22:10:27 UTC, Nick Sabalausky wrote: I've used StackOverflow. It's NOT a place for asking and answering questions. I generally agree, but the D tag on it isn't so bad since most the annoying regulars keep away. It is more the domain of me and a handful of other regular D folks (though indeed, sometimes the annoying types step in to shut stuff down, I often will just answer it anyway (ab)using my 20,000 magic internet points to comment on closed stuff if I happen to see it in time) That's good to hear. Although, can't help fearing how the environment there might chance if it did become the new official D.learn. Sometimes I get caught up in Reddit/Hackernews karma. Then, I remember that it's absurdly meaningless. Maybe if Reddit/Hackernews would let me exchange karma for a tote bag or t-shirt :-) Nah, man, go to Dave & Busters or Round One for your trinkets. Skee-Ball beats internet debates any day ;) (Come to think of it...why am I here and not there now? They have imports! Immmports)
Re: John Regehr on "Use of Assertions"
On 09/01/2018 08:44 PM, Nick Sabalausky (Abscissa) wrote: You're both wrong. ;) Or actually, you're both right... That said, it IS a very interesting, well-written article.
Re: John Regehr on "Use of Assertions"
On 09/01/2018 08:44 PM, Nick Sabalausky (Abscissa) wrote: "Are Assertions Enabled in Production Code?" "This is entirely situational." "The question of whether it is better to stop or keep going when an internal bug is detected is not a straightforward one to answer." All in all, John is very non-committal about the whole thing.
Re: John Regehr on "Use of Assertions"
On 09/01/2018 07:54 PM, Walter Bright wrote: On 9/1/2018 3:23 PM, Guillaume Boucher wrote: On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright wrote: [John agrees with me.] [No, he doesn't.] [Yea-huh, he does.] You're both wrong. ;) Or actually, you're both right... There's a section with the following heading: "Are Assertions Enabled in Production Code?" First sentence of that section: "This is entirely situational." One point for "John agrees with Walter." HOWEVER, Walter has also expressed that a program should never continue after an assert failure. The concluding text of the same section: "[...rather interesting counterexample from NASA/Mars...] The question of whether it is better to stop or keep going when an internal bug is detected is not a straightforward one to answer." One point for "John disagrees with Walter."
Re: John Regehr on "Use of Assertions"
On 9/1/2018 3:23 PM, Guillaume Boucher wrote: On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright wrote: Note the "may or may not be evaluated." We've debated this here before. I'm rather pleased that John agrees with me on this. I.e. the optimizer can assume the expression is true and use that information to generate better code, even if the assert code generation is turned off. You only read what you want to hear or what? His essay is built up in a way where he shows two opposing interpretations of asserts. Assertions as "bug detectors" or as "optimizer hints". He then discusses which one of those is the better one. The quote you gave is the definition from a proponent of the "optimizer hint" camp and not necessarily what John agrees with. His conclusion in the essay is that in general it makes sense to have assertions enabled even in release builds because a slightly worse performance is worth it to have more robust programs and he has backed this up by a lot of examples. He says: "Therefore, the compiler should feel free to optimize the program under the assumption that the asserted condition holds. Although this might be what we want — in fact it would be really cool if adding assertions made our code faster rather than slower — it’s not an interpretation that is universally useful. As developers, we might want to count on a certain kind of behavior when an assertion fails." "not ... universally useful" is not quite not agreeing at all. Furthermore, he wrote a follow-up post about "assume" (https://blog.regehr.org/archives/1096). Assume seems to be what you think assert is, but there is actually a *huge* difference. We assert a condition when we believe it to be true in every non-buggy execution of our program, but we want to be notified if this isn’t the case. In contrast, we assume a condition when our belief in its truth is so strong that we don’t care what happens if it is ever false. In other words, while assertions are fundamentally pessimistic, assumptions are optimistic. So no, John doesn't agree with you on this *at all*. I don't interpret it that way. Disabling runtime assert checking turns them into assumes. John is implying asserts should never be disabled.
Re: Engine of forum
On 9/1/2018 3:58 PM, Adam D. Ruppe wrote: On Saturday, 1 September 2018 at 22:10:27 UTC, Nick Sabalausky wrote: I've used StackOverflow. It's NOT a place for asking and answering questions. I generally agree, but the D tag on it isn't so bad since most the annoying regulars keep away. It is more the domain of me and a handful of other regular D folks (though indeed, sometimes the annoying types step in to shut stuff down, I often will just answer it anyway (ab)using my 20,000 magic internet points to comment on closed stuff if I happen to see it in time) Sometimes I get caught up in Reddit/Hackernews karma. Then, I remember that it's absurdly meaningless. Maybe if Reddit/Hackernews would let me exchange karma for a tote bag or t-shirt :-)
Re: -op can be quite strange
On Saturday, 1 September 2018 at 14:48:55 UTC, Jonathan Marler wrote: Note that we would want this to be a new option so as not to break anyone depending on "-op" semantics. Maybe "-om" for "output path based on 'Module' name"? LDC has this already as -oq, FWIW.
Re: Engine of forum
On Saturday, 1 September 2018 at 22:10:27 UTC, Nick Sabalausky wrote: I've used StackOverflow. It's NOT a place for asking and answering questions. I generally agree, but the D tag on it isn't so bad since most the annoying regulars keep away. It is more the domain of me and a handful of other regular D folks (though indeed, sometimes the annoying types step in to shut stuff down, I often will just answer it anyway (ab)using my 20,000 magic internet points to comment on closed stuff if I happen to see it in time)
Re: Engine of forum
On 08/22/2018 01:28 PM, H. S. Teoh wrote: On Wed, Aug 22, 2018 at 04:06:38PM +, Neia Neutuladh via Digitalmars-d wrote: [...] I'm a little paranoid about centralized services like Github. I'd prefer a federated service for source control / project management, where you could easily fork projects from my server to yours and send back pull requests. Then there would be no extra cost for hosting your own vs using an existing instance. My fingers are very tightly crossed, hoping, hoping, hoping for good things from Tim Berners-Lee's Solid: https://github.com/solid/solid (Introduction, docs and project repo.) https://solid.mit.edu/ (The obligatory zero-meaningful-information "manager's introduction", but worth having bookmarked anyway.) If we're lucky, maybe someday Solid will pan out enough to have a re-decentralized Github built on top. In fact, git itself was designed with such a decentralized usage pattern in mind. Ironically, people have rebuilt centralized platforms on top of it, and even to the point of building walled gardens like github. I don't argue against the usefulness of the features that github provides, but I'm also wary of the fact that it's basically a walled garden /nod /nod Exactly how I always saw it. Another frustrating irony I noticed: Git was deliberately built from the ground up for performance. In fact, that was always one of its biggest selling points, esp. in comparison to other VCSes. But then GitHub, built specifically and exclusively around Git, has only in the last couple years or so become...uhh...*NOT* completely insanely absurdly slow. Still not "fast" or lean, mind you. Just not *horrifically* slow. It's as if GitHub was founded by people saying "Hey! Git is seriously awesome! In fact, Git is s freaking awesome that...'know what? 'know what we should do? We should build a service around Git that throws away ALL the things that make Git awesome! Isn't that a fantastic idea!!!" If I were a Silicon Valley VC, that'd get my money! I've been low-key thinking about making a federated github, one where exporting your data is as simple as a `git clone; git submodule update --init`. Probably nothing will come of it, though. A big "same here" to all parts of this ;)
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 20:48:27 UTC, Walter Bright wrote: On 9/1/2018 5:25 AM, tide wrote: and that all bugs can be solved with asserts I never said that, not even close. But I will maintain that DVD players still hanging on a scratched DVD after 20 years of development means there's some cowboy engineering going on, and an obvious lack of concern about that from the manufacturer. Firstly, you have to take into account the context around why that bug exists and why it is not fixed and it comes does to a risk-cost trade off. Product managers are totally driven by budget and in consumer goods they dictate the engineering resources. I think you'll find most large DVD manufactures have discovered that it is not cost effective to give engineers the budget to fix these annoying bugs. This is because most consumers will be annoyed but then go out and purchase som other product by the same manufacturer. I.e. these bugs do not harm their brand enough. This leads to the situation where the engineering is shoddy not because the programmers are bad engineers, but because they don't even get the chance to engineer due to time constraints. Secondly, DVD players and critical flight systems are apples and oranges in terms of engineering rigor required. One will mildly annoy the odd consumer, who 9 times of 10 will still purchase products again and the other will likely kill 100s of people. To put it another way; one will give the engineers *zero* resources to work on non-blocking bugs and the other must have *zero* non-blocking bugs. Cheers, Norm
Re: This thread on Hacker News terrifies me
On 9/1/2018 7:36 AM, Walter Bright wrote: > On 9/1/2018 2:15 AM, Paulo Pinto wrote: >> On Saturday, 1 September 2018 at 08:19:49 UTC, Walter Bright wrote: >>> On 8/31/2018 11:59 PM, Paulo Pinto wrote: > For example, in any CS program, are there any courses at all about > this? Yes, we had them on my degree, >>> >>> I'm curious how the courses you took compared with the articles I >>> wrote about it. >> >> I will read the articles later, but as overview, we learned about: >> [...] > It appears to have nothing related to what the articles are about. > > I'm rather sad that I've never seen these ideas outside of the aerospace > industry. Added to that is all the pushback on them I get here, on > reddit, and on hackernews. Some people do. I should take this opportunity to plug one of Alan Kay's great talks. "Programming and Scaling" https://www.youtube.com/watch?v=YyIQKBzIuBY But Kay definitely isn't a Hacker News/Reddit darling, even though he's well respected. He's too critical of the current state of software engineering. Rightfully so, if you ask me.
Re: anyway to debug nogc code with writeln?
You can strip off any attribute with SetFunctionAttributes:
import std.stdio;
// Adapted from std.traits.SetFunctionAttributes documentation
import std.traits;
auto assumeNoGC(T)(T t)
if (isFunctionPointer!T || isDelegate!T)
{
enum attrs = functionAttributes!T | FunctionAttribute.nogc;
return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs)) t;
}
void f(T)(auto ref T) {
writeln("yo");
}
@nogc void main() {
assumeNoGC(() => f(3));
// or
assumeNoGC( { writeln("yo"); });
}
Ali
Re: John Regehr on "Use of Assertions"
On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright wrote: Note the "may or may not be evaluated." We've debated this here before. I'm rather pleased that John agrees with me on this. I.e. the optimizer can assume the expression is true and use that information to generate better code, even if the assert code generation is turned off. You only read what you want to hear or what? His essay is built up in a way where he shows two opposing interpretations of asserts. Assertions as "bug detectors" or as "optimizer hints". He then discusses which one of those is the better one. The quote you gave is the definition from a proponent of the "optimizer hint" camp and not necessarily what John agrees with. His conclusion in the essay is that in general it makes sense to have assertions enabled even in release builds because a slightly worse performance is worth it to have more robust programs and he has backed this up by a lot of examples. Furthermore, he wrote a follow-up post about "assume" (https://blog.regehr.org/archives/1096). Assume seems to be what you think assert is, but there is actually a *huge* difference. We assert a condition when we believe it to be true in every non-buggy execution of our program, but we want to be notified if this isn’t the case. In contrast, we assume a condition when our belief in its truth is so strong that we don’t care what happens if it is ever false. In other words, while assertions are fundamentally pessimistic, assumptions are optimistic. So no, John doesn't agree with you on this *at all*.
Re: Engine of forum
On 08/21/2018 10:18 AM, Seb wrote: There are a few good points to move D.learn to Stack Overflow and that's actually one thing that we have talked about a few times and somehow never has happened. In the D survey there was a 2:1 "consensus" for StackOverflow. Eeew, god no. That would be HORRIBLE. I've used StackOverflow. It's NOT a place for asking and answering questions. It's a place where anybody who fancies themself a control freak can come play out their hall-monitor/web-moderator fantasies all while earning points toward nifty stickers(!!!) and leveling-up their self-righteousness stats to earn bigger and better tools for exerting control over others. I'm not even joking: StackOverflow might not have intended it, but it really IS more of a mixed-reality social MMO than a Q tool. I'm amazed that anyone who's tried it can still take it seriously. In D.learn: People post questions. Other people post answers. Done. In StackOverflow: Attempts to ask/answer regularly just get shame-slapped into oblivion by any one of the hundreds (thousands?) of members mostly just there to play the meta-game.
anyway to debug nogc code with writeln?
I would like to debug a few things and need to insert print
statements to figure things out. I thought that using debug print
would be ok in nogc code?
Seems it make the compiler infer f as not nogc though so this is
basically unworkable unless I go through my entire source code
and remove the @nogc attribute wherever function f is used.
Anyway around this?
Here's example code:
import std.stdio;
void f(T)(auto ref T) {
debug writeln("yo");
}
@nogc void main() {
f(3);
}
Error: @nogc function D main cannot call non-@nogc function
onlineapp.f!int.f
Cheers,
- Ali
Re: Engine of forum
On 08/31/2018 03:28 PM, tide wrote: Don't use a NNTP client, I prefer to just use a browser. For many of us it's the opposite. If you prefer to use a browser then you're free to keep using it. So you've never posted a snippet of code on here? I honestly doubt that. Syntax formatting is useful even if you only post 2 lines of code. No wonder these boards are the way they are with opinions like that. Syntax highlighting of code snippets would be nice. You could bring it up at DFeed's issue tracker.
Re: This thread on Hacker News terrifies me
On 9/1/2018 2:33 PM, Gambler wrote: Alan Kay, Joe Armstrong, Jim Coplien - just to name a few famous people who talked about this issue. It's amazing that so many engineers still don't get it. I'm inclined to put some blame on the recent TDD movement. They often to seem stress low-level code perfectionism, while ignoring high-level architecture and runtime resilience (in other words, system thinking). Yup. The worst notions in the industry are: 1. We can make this software bug-free by using Fad Technique X. 2. Since our software has no bugs in it, we needn't concern ourselves with what happens when it fails. 3. If it does fail, since we have no plan for that due to (2), we must let it proceed anyway. What could possibly go wrong?
Re: Engine of forum
On 08/21/2018 05:41 PM, tide wrote: What about if you accidentially press a button that posts the comment? Then the world ends and everybody dies horribly. Erm...wait, I mean: You post a follow-up and move on. Why can't syntax formatting be implemented, does anyone disagree that is a useless feature? What for? To reinvent the wonders that non-plaintext email unleashed on the world? To add an extra tick in some marketing blurb? Fire and Motion: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ (Skip the first half. Do a text search for "Fire and Motion" and read from there on.)
Re: This thread on Hacker News terrifies me
On 8/31/2018 3:50 PM, Walter Bright wrote: > https://news.ycombinator.com/item?id=17880722 > > Typical comments: > > "`assertAndContinue` crashes in dev and logs an error and keeps going in > prod. Each time we want to verify a runtime assumption, we decide which > type of assert to use. We prefer `assertAndContinue` (and I push for it > in code review)," > > "Stopping all executing may not be the correct 'safe state' for an > airplane though!" > > "One faction believed you should never intentionally crash the app" > > "One place I worked had a team that was very adamant about not really > having much error checking. Not much of any qc process, either. Wait for > someone to complain about bad data and respond. Honestly, this worked > really well for small, skunkworks type projects that needed to be nimble." > > And on and on. It's unbelievable. The conventional wisdom in software > for how to deal with programming bugs simply does not exist. > > Here's the same topic on Reddit with the same awful ideas: > > https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/ > > > No wonder that DVD players still hang when you insert a DVD with a > scratch on it, and I've had a lot of DVD and Bluray players over the > last 20 years. No wonder that malware is everywhere. All too true. A while ago I worked for a large financial company. Many production systems had zero monitoring. A server with networking issues could continue to misbehave _for hours_ until someone somewhere noticed thousands of error messages and manually intervened. There were also very few data quality checks. Databases could have duplicate records, missing records or obviously inconsistent information. Most systems just continued to process corrupt data as if nothing happened, propagating it further and further. Some crucial infrastructure had no usable data backups. With all this in mind, you would be surprised to hear how much they talked about "software quality". It's just that their notion of quality revolved around having no bugs ever go into production and never bringing down any systems. There were ever increasing requirements around unit test coverage, opinionated coding standards and a lot of paperwork associated with every change. Needless to say, it didn't work very well, and they had round half a dozen outages of varying sizes _every day_. Alan Kay, Joe Armstrong, Jim Coplien - just to name a few famous people who talked about this issue. It's amazing that so many engineers still don't get it. I'm inclined to put some blame on the recent TDD movement. They often to seem stress low-level code perfectionism, while ignoring high-level architecture and runtime resilience (in other words, system thinking).
Re: Engine of forum
On 08/20/2018 11:42 PM, Ali wrote: Every now and then someone new to D comes and ask, why arent we using better forum software. There *is* better forum software than what they're used to using. *MUCH* better. It's called Thunderbird. :)
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 09/01/2018 07:12 AM, Chris wrote: Hope is usually the last thing to die. But one has to be wise enough to see that sometimes there is nothing one can do. As things are now, for me personally D is no longer an option, because of simple basic things, like autodecode, a flaw that will be there forever, poor support for industry technologies (Android, iOS) Much as I hate to agree, that IS one thing where I'm actually in the same boat: My primary current paid project centers around converting some legacy Flash stuff to...well, to NOT Flash obviously. I *want* to use D for this very badly. But I'm not. I'm using Unity3D because: 1. For our use right now: It has ready-to-go out-of-the-box WebAsm support (or is it asm.js? Whatever...I can't keep up with the neverending torrent of rubble-bouncing from the web client world.) 2. For our use later: It has ready-to-go out-of-the-box iOS/Android support (along with just about any other platform we could ever possibly hope to care about). 3. It has all the robust multimedia functionality we need ready-to-go on all platforms (actually, its capabilities are totally overkill for us, but that's not a bad problem to have). 4. C# isn't completely totally horrible. I will be migrating the server back-end to D, but I *really* wish I could be doing the client-side in D too, even if that meant having to build an entire 2D engine off nothing more than SDL. Unfortunately, I just don't feel I can trust the D experience to be robust enough on those platforms right now, and I honestly have no idea when or even if it will get there (Maybe I'm wrong on that. I hope I am. But that IS my impression even as the HUUUGE D fan I am.)
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 11:32:32 UTC, Jonathan M Davis wrote: I'm not sure that I really agree that software engineering isn't engineering, but the folks who argue against it do have a point in that software engineering is definitely not like most other engineering disciplines, and good engineering practices are nowhere near as well-defined in software engineering as those in other engineering fields. Most engineering fields have a somewhat stable/slow moving context in which they operate. If you have a specific context (like banking) then you can develop a software method that specifies how to build banking software, and repeat it, assuming that the banks you develop the method for are similar Of course, banking has changed quite a lot over the past 15 years (online + mobile). Software often operates in contexts that are critically different and that change in somewhat unpredictable manners. But road engineers have a somewhat more stable context, they can adapt their methodology over time. Context does change even there, but at a more predictable pace. Of course, this might be primarily because computers are new. Businesses tend to use software/robotics in a disruptive manner to get a competitive edger over the competitors. So the users themselves creates disruptive contexts in their search for the "cutting edge" or "competitive edge". As it becomes more and more intertwined into how people do business it might become more stable and then you might see methods for specific fields that are more like engineering in older established fields. (like building railways).
If I have an external test runner, can I get visibility up internal types only for version(unittest) ?
mypackage:
internaltype.d
package struct InternalType {}
package template isInternalType(T) { ... }
externaltype.d
auto doStuff() {
return InternalType();
}
testfile.d
@("Make sure under scenario X that InternalType is returned")
unittest {
static assert(isInternalType!(typeof(doStuff()));
}
I could've used version to do this maybe? but it doesn't seem to
work because I tested it by doing:
internaltype.d
version(unittest) {
package:
}
struct InternalType {
...
}
template isInternalType(T) { ... }
And using isInternalType in testfile.d does not seem to issue the
warning:
Deprecation: internaltype.isInternalType(T) is not visible from
module testfile
Is there anyway to get visibility of internal types in test files.
Cheers,
- Ali
Re: This thread on Hacker News terrifies me
On 9/1/2018 5:33 AM, tide wrote: It is vastly different, do you know what fly by wire is? Yes, I do. Do you know I worked for three years on critical flight controls systems at Boeing? I said so in the article(s). These ideas are not mine, I did not come up with them in 5 minutes at the keyboard. They're central to the aerospace design industry, and their fantastic safety record is testament to how effective they are. If the system controlling that just stops working, how do you expect the pilot to fly the plane? https://www.digitalmars.com/articles/b40.html May I draw your attention back to the "Dual Path" section. Fly by wire failures are no different in principle from a total hydraulic system failure on a fully powered flight control system. Airliners do suffer total hydraulic failures now and then, despite being unable to fly without hydraulics, yet land safely. I'll give you one guess how that is done :-) I can give you a brief rundown on how it works after you guess.
Re: This thread on Hacker News terrifies me
On 9/1/2018 5:25 AM, tide wrote: and that all bugs can be solved with asserts I never said that, not even close. But I will maintain that DVD players still hanging on a scratched DVD after 20 years of development means there's some cowboy engineering going on, and an obvious lack of concern about that from the manufacturer.
Re: (u)byte calling char overload instead of int
On Saturday, 1 September 2018 at 17:17:37 UTC, puffi wrote: Hi, Is it by design that when calling functions with either ubyte or byte variables the char overload is called instead of the int (or generic) one? It seems this is by design. "If two or more functions have the same match level, then partial ordering is used to try to find the best match. Partial ordering finds the most specialized function." char is more specialized than int, and since the implicit conversion byte->char exists, it is called. Even f(1UL) will call f(char) rather than f(long).
Re: ldc2 crashes when trying to compile my app
On Saturday, 1 September 2018 at 20:35:52 UTC, Per Nordlöw wrote:
On Saturday, 1 September 2018 at 19:52:14 UTC, kinke wrote:
`_Z7DtoLValP6DValue` may be suitable...
Is this a C++-symbol?
import core.demangle;
demangle("_Z7DtoLValP6DValue")
returns the same string...
It's C++.
Demangled via
c++filt -n _Z7DtoLValP6DValue
returns
DtoLVal(DValue*)
Re: ldc2 crashes when trying to compile my app
On Saturday, 1 September 2018 at 19:52:14 UTC, kinke wrote:
`_Z7DtoLValP6DValue` may be suitable...
Is this a C++-symbol?
import core.demangle;
demangle("_Z7DtoLValP6DValue")
returns the same string...
Re: This thread on Hacker News terrifies me
On 9/1/2018 1:18 AM, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? [...] John Regehr has some excellent advice, much better than mine: https://blog.regehr.org/archives/1091
Re: Engine of forum
On 8/31/2018 3:16 AM, Andrey wrote: Forum posts should be informative and contain meaningful text that will be understandable for readers. And if required, it should contain videos / images / screenshots / quotes / links, etc. It already highlights quotes and links. As for the rest, the D forum is not a free hosting service for pictures, videos, manuscripts, music, or project source code. There are free services for that (youtube, imgur, github, etc.) which you're welcome to link to from a post. Posts should be short, on topic and to the point. Quoting of the antecedent should be minimal. It is very strange to hear from programmer that "syntax formatting" is useless feature. It's not useful for snippets of code. Worse, often people want to write grammatically incorrect code for purposes of illustration, highlighting that would be a nuisance.
John Regehr on "Use of Assertions"
https://blog.regehr.org/archives/1091 As usual, John nails it in a particularly well-written essay. "ASSERT(expr) Asserts that an expression is true. The expression may or may not be evaluated. If the expression is true, execution continues normally. If the expression is false, what happens is undefined." Note the "may or may not be evaluated." We've debated this here before. I'm rather pleased that John agrees with me on this. I.e. the optimizer can assume the expression is true and use that information to generate better code, even if the assert code generation is turned off.
DMD cross compiler
I know there's been discussion on this before, I just want a definitive reference. It looks like it would be relatively straight forward for DMD to be a cross-compiler. A few version() statements could be runtime if's, and that's pretty much it. When hacking on parts of DMD, I frequently make hacks that turn such versions into runtime if's to test multiple targets from the one dev workflow. It would be about 100 times more convenient to supply an arg, than make hacks all over the code... so, why not?
Re: ldc2 crashes when trying to compile my app
On Saturday, 1 September 2018 at 19:35:53 UTC, Per Nordlöw wrote: What should I grep for when trying to Dustmite this? `_Z7DtoLValP6DValue` may be suitable. - I don't use dustmite and prefer manual minimization; e.g., by adding `-vv > bla.log` to the crashing commandline. The last lines in that (pretty huge) log file should give you an idea of which function call makes it crash, and possibly even why (it's apparently expecting something in memory which isn't). Of further help may be a CI build with enabled assertions, downloadable from https://github.com/ldc-developers/ldc/releases/CI.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote: https://news.ycombinator.com/item?id=17880722 Typical comments: "`assertAndContinue` crashes in dev and logs an error and keeps going in prod. Each time we want to verify a runtime assumption, we decide which type of assert to use. We prefer `assertAndContinue` (and I push for it in code review)," "Stopping all executing may not be the correct 'safe state' for an airplane though!" "One faction believed you should never intentionally crash the app" "One place I worked had a team that was very adamant about not really having much error checking. Not much of any qc process, either. Wait for someone to complain about bad data and respond. Honestly, this worked really well for small, skunkworks type projects that needed to be nimble." And on and on. It's unbelievable. The conventional wisdom in software for how to deal with programming bugs simply does not exist. Here's the same topic on Reddit with the same awful ideas: https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/ No wonder that DVD players still hang when you insert a DVD with a scratch on it, and I've had a lot of DVD and Bluray players over the last 20 years. No wonder that malware is everywhere. It's because programming is done completely wrong. All we do is program like it's 1952 all wrapped up in a nice box and bow tie. WE should have tools and a compiler design that all work interconnected with complete graphical interfaces that aren't based in the text gui world(an IDE is just a fancy text editor). I'm talking about 3D code representation using graphics so projects can be navigated visually in a dynamic way and many other things. The current programming model is reaching diminishing returns. Programs cannot get much more complicated because the environment in which they are written cannot support them(complexity != size). We have amazing tools available to do amazing things but programming is still treated like punch cards, just on acid. I'd like to get totally away from punch cards. I total rewrite of all aspects of programming should be done(from "object" files(no more, they are not needed, at least not in the form they are), the IDE(it should be more like a video game(in the sense of graphical use) and provide extensive information and debugging support all at a finger tip away), from the tools, to the design of applications, etc. One day we will get there...
ldc2 crashes when trying to compile my app
per:~/Work/knet] $ dub run --compiler=ldmd2 --build=release-nobounds The determined compiler type "ldc" doesn't match the expected type "dmd". This will probably result in build errors. WARNING: A deprecated branch based version specification is used for the dependency gmp-d. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. WARNING: A deprecated branch based version specification is used for the dependency knet:phobos-next. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. Warning: License in subpackage knet:phobos-next is different than it's parent package, this is discouraged. Performing "release-nobounds" build using ldmd2 for x86_64. gmp-d ~master: target for configuration "library" is up to date. knet:phobos-next ~master: building configuration "library"... knet ~master: building configuration "application"... /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x1a)[0x28919ba] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_ZN4llvm3sys17RunSignalHandlersEv+0x3e)[0x288fc7e] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2[0x288fda2] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f998c24e890] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z7DtoLValP6DValue+0xa)[0xcebd3a] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z15DtoCallFunctionR3LocP4TypeP6DValueP5ArrayIP10ExpressionEPN4llvm5ValueE+0xb34)[0xc86fe4] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2[0xc90eab] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2[0xc9116f] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z6toElemP10Expression+0x6d)[0xc8ca0d] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2[0xc92426] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z6toElemP10Expression+0x6d)[0xc8ca0d] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z17DtoVarDeclarationP14VarDeclaration+0x7e)[0xc4882e] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z17DtoDeclarationExpP7Dsymbol+0x1d1)[0xc4b8e1] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2[0xc8e806] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z10toElemDtorP10Expression+0x6d)[0xc8dced] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2[0xc79b40] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2[0xc7b2b4] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2[0xc7b2b4] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2[0xc7acfe] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z14Statement_toIRP9StatementP7IRState+0x24)[0xc79744] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z17DtoDefineFunctionP15FuncDeclarationb+0xc49)[0xc3ee49] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2[0xc33d63] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z19Declaration_codegenP7DsymbolP7IRState+0x24)[0xc367a4] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z13codegenModuleP7IRStateP6Module+0xa5)[0xc56135] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_ZN3ldc13CodeGenerator4emitEP6Module+0x99)[0xd02939] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z14codegenModulesR5ArrayIP6ModuleE+0x186)[0xcd8716] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z13mars_mainBodyR5ArrayIPKcES3_+0x1aa0)[0xafaa60] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_Z7cppmainiPPc+0x1e17)[0xcd6507] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv+0x50)[0x29d67c0] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2(_d_run_main+0x1a6)[0x29d6646] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f998b8b6b97] /home/per/.local/ldc2-1.11.0-linux-x86_64/bin/ldc2[0xa22525] What should I grep for when trying to Dustmite this?
Re: Cannot make sense of LLD linker error with ldc 1.11.0
On Saturday, 1 September 2018 at 18:46:32 UTC, Nordlöw wrote: Thanks! Is there usually only apps and not libs that are supposed to have linker flags like these? In this specific case, I'm not sure it's a good idea to set the linker in the dub config. Does it absolutely require gold, i.e., not work properly with bfd? There used to be issues with `-flto=thin` and bfd on Linux, but LDC now defaults to `-linker=gold` in that case.
[Issue 19085] std.experimental.allocator.makeArray should work with void
https://issues.dlang.org/show_bug.cgi?id=19085 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/6479a70a3b409871aae4a4a9a044cf429d6c1ca1 Fix Issue 19085 - std.experimental.allocator.makeArray should work with void https://github.com/dlang/phobos/commit/ab169cefe5bc17870ae77bbd55132735fa64a5cb Merge pull request #6670 from wilzbach/fix-19085 Fix Issue 19085 - std.experimental.allocator.makeArray should work with void merged-on-behalf-of: Nathan Sashihara --
[Issue 19085] std.experimental.allocator.makeArray should work with void
https://issues.dlang.org/show_bug.cgi?id=19085 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Cannot make sense of LLD linker error with ldc 1.11.0
On Thursday, 30 August 2018 at 20:36:02 UTC, kinke wrote: On Thursday, 30 August 2018 at 19:41:38 UTC, Nordlöw wrote: I'm using the tar.xz for x64 Linux. Ok? You're explicitly adding `-link-internally` in your top-level dub.sdl: dflags "-link-internally" platform="linux-ldc" # use GNU gold linker If you want to go with gold, as your comment suggests, you'd use `-linker=gold` instead. For more context wrt. `-link-internally` clumsiness on non-Windows, see https://github.com/ldc-developers/ldc/issues/2717. Thanks! Is there usually only apps and not libs that are supposed to have linker flags like these?
Re: Is this a good idea?
On Saturday, 1 September 2018 at 17:08:25 UTC, Peter Alexander
wrote:
On Saturday, 1 September 2018 at 16:20:11 UTC, Dr.No wrote:
why move flush to outside the synchronized block?
flush should be thread safe. In general, yiu want as little
code as possible to run under the lock. Not that important
though.
trying out this approach I found to be ok except in some
cases, the output look like that:
...
also there's that extra ♪◙ character. Thos sounds memory
violation somewhere.
This only happens when using parallel. Any guess what's
possibily happeing?
Hard to say without seeing code. Agree it looks like a race.
I'll try to make a reduced version of the program so that your
guys can help me find out what's wrong.
One guess:
In the code:
foreach(x; parallel(arr)) {
auto a = f(x);
auto res = g(a);
synchronized {
stdout.writeln(res);
stdout.flush();
}
assuming res is a class type, is res's adress unique due whole
loop execution or it can be overritten by another thread? for
example:
the writeln() call block is locked until thread3 finish printing,
thread2 has just finished and now is waiting for thread3 free the
resource but before that happens, thread2 just finish. Can
thread2 overrite the res adress in any way?
I need clarifation on that to try find out what's wrong with this
code.
for more info: g() does have the last statement as return new
myClass()
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Saturday, 1 September 2018 at 12:33:49 UTC, rjframe wrote: C++ is sometimes used for projects in which Stroustrup would say it's obviously the wrong language for the job. D is far more likely to require justification based on technical merit. If D becomes another C++, why bother taking a chance with D when you can just use C++, use a well-supported, commonly-used compiler, and hire from a bigger pool of jobseekers? Stroustrup also said, that "achieving any degree of compatibility [with C/C++] is very hard, as the C/C++ experience shows." (reference => http://stroustrup.com/hopl-almost-final.pdf (2007) (and here refers to D on page 42 btw - that was 11 years ago now). And yet, D is very intent on doing just that, while also treading its own path. I personally think this is why D has not taken off, as many would hope. It's hard. I think it's also why D won't take off, as many hope. It's hard. Stroustrup was correct (back in the 90's). Yes, it really is hard. Made even harder now, since C++ has evolved into a 'constantly' moving target...
(u)byte calling char overload instead of int
Hi, Is it by design that when calling functions with either ubyte or byte variables the char overload is called instead of the int (or generic) one?
[Issue 18142] checkedint opOpAssign doesn't accept a checkedint
https://issues.dlang.org/show_bug.cgi?id=18142 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/2ca2824f7ec5da981ae676060f2c0cfde7f06eaf Fix issue 18142 - checkint opOpAssign doesn't accept checkedints https://github.com/dlang/phobos/commit/e7990e0f79c6d06a58ad79e12bb92de8bc848f63 Merge pull request #6685 from dhasenan/checkedint_opopassign Fix issue 18142 - checkint opOpAssign doesn't accept checkedints merged-on-behalf-of: Nathan Sashihara --
Re: Is this a good idea?
On Saturday, 1 September 2018 at 16:20:11 UTC, Dr.No wrote: why move flush to outside the synchronized block? flush should be thread safe. In general, yiu want as little code as possible to run under the lock. Not that important though. trying out this approach I found to be ok except in some cases, the output look like that: ... also there's that extra ♪◙ character. Thos sounds memory violation somewhere. This only happens when using parallel. Any guess what's possibily happeing? Hard to say without seeing code. Agree it looks like a race.
Re: extern __gshared const(char)* symbol fails
On Friday, 31 August 2018 at 17:50:17 UTC, Steven Schveighoffer
wrote:
...
When you use const char* in D, it's expecting a *pointer* to be
stored at that address, not the data itself. So using it means
segfault. The static array is the correct translation, even
though it leaks implementation details.
In C, it's working because C has the notion of a symbol being
where an array starts. D has no concept of a C array like that,
every array must have a length. So there is no equivalent you
can use in D -- you have to supply the length.
I think this is only correct for dynamic arrays. For static
arrays I have the impression that it works exactly as in C, i.e.
the address of the array is the address of the first array
element. See this simple code:
import std.stdio;
import std.array;
void main()
{
// static array
ulong [4] ulArr1 = [0,1,2,3];
ulong *p1 = ulArr1.ptr;
ulong *p2 = &(ulArr1[0]);
ulong [4] *p3 =
writeln("same pointers: ", cast(void *)p1 == cast(void *)p2);
writeln("same pointers: ", cast(void *)p3 == cast(void *)p2);
writeln("");
// dynamic array
ulong [] ulArr2 = [0,1,2,3];
p1 = ulArr2.ptr;
p2 = &(ulArr2[0]);
ulong [] *p5 =
writeln("same pointers: ", cast(void *)p1 == cast(void *)p2);
writeln("same pointers: ", cast(void *)p5 == cast(void *)p2);
} // end main()
This produces (with dmd):
same pointers: true
same pointers: true
same pointers: true
same pointers: false
Re: Is this a good idea?
On Thursday, 30 August 2018 at 21:09:35 UTC, Peter Alexander
wrote:
On Thursday, 30 August 2018 at 19:59:17 UTC, Dr.No wrote:
I would to process the current block in parallel but priting
need to be theread-safe so I'm using
foreach(x; parallel(arr)) {
auto a = f(x);
auto res = g(a);
synchronized {
stdout.writeln(res);
stdout.flush();
}
}
Since f() and g() are some heavy functions, I'd like to
process in parallel but the printing (doesn't need to respect
order but must be thread-safe) hence I'm using synchronized.
Is this counter-productive in any way?
I don't see any problem with that assuming f and g are
significantly more expensive than writeln. The flush can be
moved outside the synchronized block.
why move flush to outside the synchronized block?
trying out this approach I found to be ok except in some cases,
the output look like that:
outjson = {"barCode":"1","ade":"1"}
outjson = {"barCode":"2","ade":"2"}
outjson = {"barCode":"3","ade":"3"}
outjson = {"barCode":"4","ade":"4"}
outjson = {"barCode":"5","ade":"5"}
// and so on...
then there is this output:
outjson = {"barCode":"20","ade":"20"}♪◙outjson =
{"barCode":"X21","ade":"21"}
within the synchronized block.
This is supposed to be:
outjson = {"barCode":"20","ade":"20"}
outjson = {"barCode":"X21","ade":"21"}
also there's that extra ♪◙ character. Thos sounds memory
violation somewhere.
This only happens when using parallel. Any guess what's possibily
happeing?
-op can be quite strange
The -od (output directory) and -op (perserve source paths) work great when you're compiling multiple modules in a single invocation. For example, say we have the following: /foolib/src/foo/bar.d /myapp/src/main.d Current Directory: /myapp ``` dmd -I=../foolib/src -I=src -od=obj -op -c src/main.d ../foolib/src/foo/bar.d ``` This example shows a weird unexpected result. Because I've specified "../foolib/src/foo/bar.d" on the command line, the compiler will put the object file here: obj/../foolib/src/foo/bar.o which means it will go here: /myapp/foolib/src/foo/bar.o This is very strange. Because it has a ".." in the name, it doesn't even get put in the "obj" folder specified by "-od". What makes it worse is if you ad used "-i" instead of giving it on the command line: ``` dmd -I=../foolib/src -I=src -od=obj -op -c src/main.d -i ``` then it would be in: obj/foo/bar.o I thought about this for a bit an realized that maybe there's a better way. Instead of telling the compiler to append the "relative path" of the source file from CWD to the output directory like this: `/.d` -> `//.o` `../foolib/src/foo/bar.d` -> `obj/../foolib/src/foo/bar.o` we could tell the compiler to use the path relative of the source file from the package root. Let's call it the "package path": `//.d` -> `//.o` `../foolib/src/foo/bar.d` -> `obj/foo/bar.o` This would mean modules would go to the same place whether they were explicitly given on the command line or whether they were a "compiled import" via "-i". It also handles conflicts because each fully-qualified module name (and by extension each "package path" / "module name" combo) must be unique in a compiler invocation. Note that we would want this to be a new option so as not to break anyone depending on "-op" semantics. Maybe "-om" for "output path based on 'Module' name"?
Re: D is dead
On Saturday, September 1, 2018 8:31:36 AM MDT H. S. Teoh via Digitalmars-d
wrote:
> This change may also address the current hackish implementation of
> subclass contracts (which involves catching Errors, an arguably
> dangerous thing to do), though I'm not 100% sure.
AFAIK, there's absolutely nothing required to fix that other than just
implementing it. As I understand it, the assertions act normally and thus
throw AssertErrors, but there should be no technical reason why they
couldn't be transformed into something else. e.g.
in
{
assert(foo < 7);
}
could be lowered to something like
in
{
if(foo < 7)
return false;
return true;
}
The only differences would then be if any functions called in the contract
resulted in an AssertError (sinc that would no longer count as a contract
failure - which is arguably a bug fix) and that explicitly throwing an
AssertError wouldn't work anymore - but I expect that that's rare enough
that it wouldn't be all that big a deal.
- Jonathan M Davis
Re: D is dead
On Sat, Sep 01, 2018 at 01:26:01PM +, rjframe via Digitalmars-d wrote: > On Thu, 23 Aug 2018 07:27:56 +, JN wrote: [...] > > (has anyone ever used contracts?). > > I do. Me too. They are very useful to express intent, even if the current implementation leaves some things to be desired. > It's a shame D doesn't take them seriously. Not sure what you mean by that. Care to elaborate? > As it is, I generally use them solely to express intent, which you > don't get by placing asserts in the function body. I often read the > function signature of functions I'm calling without reading the body, > so separating the asserts from the body is helpful. [...] Yes. The current implementation of contracts leaves some things to be desired, but I'm hopeful after the recent syntax revamp was accepted and merged into git master. The next milestone to fight for is pushing the checking of contracts to the caller, rather than the callee. This will be important to solve the currently very annoying (and debilitating) problem with binary shared libraries, in that it will allow the same shared binaries to be used when compiling both with and without contracts. It should be the end user's build script that decides whether or not contracts are compiled in, but currently this is not the case. This change may also address the current hackish implementation of subclass contracts (which involves catching Errors, an arguably dangerous thing to do), though I'm not 100% sure. T -- Старый друг лучше новых двух.
Re: This thread on Hacker News terrifies me
On 02/09/2018 1:15 AM, Jonathan M Davis wrote: On Saturday, September 1, 2018 6:46:38 AM MDT rikki cattermole via Digitalmars-d wrote: On 02/09/2018 12:21 AM, tide wrote: On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote: On 01/09/2018 12:40 PM, tide wrote: On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: On 8/31/2018 2:40 PM, tide wrote: I don't think I've ever had a **game** hung up in a black screen and not be able to close it. I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix. Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries. And yet they manage to run a JVM with Java on it. Not the one's Walter is talking about. I rarely have to power cycle any smart device, even my phone which is running so much shit on it. For some reason I have memories related to DVD players containing a JVM to provide interactivity. But it doesn't look like those memory were based on anything. So ignore me. I don't know if any DVD players have ever used Java, but all Blu-ray players do require it, because unfortunately, the Blu-ray spec allows for the menus to be done via Java (presumably so that they can be fancier than what was possible on DVDs). - Jonathan M Davis Harry potter 1&2 had games as part of their menus as of 2001/2, so it was already pretty sophisticated.
Re: D is dead
On Thu, 23 Aug 2018 07:27:56 +, JN wrote: > I think a large part is defining what kind of users D wants to attract. I've begun wondering whether "pragmatism" is sometimes used as a code word for indecision. > Is it possible to make a language that both groups would be happy to > use? Perhaps, or perhaps the gap is too wide. Is adding features like > dip1000 and betterC spreading ourselves too thin? Perhaps. Perhaps there > are features that aren't really used, and should be reworked or cut from > the language instead I do think that D can do it. And I think D is the only language I've looked at that can do it. But I think it's going to take Walter and Andrei, in conversation with the core team, putting together a real list of priorities and setting a high-level direction. Look at what the end goal really is and what it will take to get there. The current high level document tends to read as a list of what's already being worked on, but piecemeal improvements probably aren't going to cut it -- this goes back to the leverage conversation Andrei started earlier. > (has anyone ever used contracts?). I do. It's a shame D doesn't take them seriously. As it is, I generally use them solely to express intent, which you don't get by placing asserts in the function body. I often read the function signature of functions I'm calling without reading the body, so separating the asserts from the body is helpful. And they're often useful on interfaces.
Re: This thread on Hacker News terrifies me
On Saturday, September 1, 2018 6:37:13 AM MDT tide via Digitalmars-d wrote: > On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright > > wrote: > > On 8/31/2018 7:28 PM, tide wrote: > >> I'm just wondering but how would you code an assert to ensure > >> the variable for a title bar is the correct color? Just how > >> many asserts are you going to have in your real-time game that > >> can be expected to run at 144+ fps ? > > > > Experience will guide you on where to put the asserts. > > > > But really, just apply common sense. It's not just for > > software. If you're a physicist, and your calculations come up > > with a negative mass, you screwed up. If you're a mechanical > > engineer, and calculate a force of billion pounds from dropping > > a piano, you screwed up. If you're an accountant, and calculate > > that you owe a million dollars in taxes on a thousand dollars > > of income, you screwed up. If you build a diagnostic X-ray > > machine, and the control software computes a lethal dose to > > administer, you screwed up. > > > > Apply common sense and assert on unreasonable results, because > > your code is broken. > > That's what he, and apparently you don't get. How are you going > to use an assert to check that the color of a title bar is valid? > Try and implement that assert, and let me know what you come up > with. I don't think that H. S. Teoh's point was so much that you should be asserting anything about the colors in the graphics but rather that problems in the graphics could be a sign of a deeper, more critical problem and that as such the fact that there are graphical glitches is not necessary innocuous. However, presumably, if you're going to put assertions in that code, you'd assert things about the actual logic that seems critical and not anything about the colors or whatnot - though if the graphical problems would be a sign of a deeper problem, then the assertions could then prevent the graphical problems, since the program would be killed before they happened due to the assertions about the core logic failing. - Jonathan M Davis
Re: This thread on Hacker News terrifies me
On Saturday, September 1, 2018 6:46:38 AM MDT rikki cattermole via Digitalmars-d wrote: > On 02/09/2018 12:21 AM, tide wrote: > > On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote: > >> On 01/09/2018 12:40 PM, tide wrote: > >>> On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: > On 8/31/2018 2:40 PM, tide wrote: > > I don't think I've ever had a **game** hung up in a black screen > > and not be able to close it. > > I've had that problem with every **DVD player** I've had in the last > 20 years. Power cycling is the only fix. > >>> > >>> Two very different things, odds are your DVD players code aren't even > >>> written with a complete C compiler or libraries. > >> > >> And yet they manage to run a JVM with Java on it. > > > > Not the one's Walter is talking about. I rarely have to power cycle any > > smart device, even my phone which is running so much shit on it. > > For some reason I have memories related to DVD players containing a JVM > to provide interactivity. But it doesn't look like those memory were > based on anything. So ignore me. I don't know if any DVD players have ever used Java, but all Blu-ray players do require it, because unfortunately, the Blu-ray spec allows for the menus to be done via Java (presumably so that they can be fancier than what was possible on DVDs). - Jonathan M Davis
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 13:03:50 UTC, rikki cattermole wrote: On 02/09/2018 12:57 AM, tide wrote: On Saturday, 1 September 2018 at 12:49:12 UTC, rikki cattermole wrote: On 02/09/2018 12:37 AM, tide wrote: On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? Experience will guide you on where to put the asserts. But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up. Apply common sense and assert on unreasonable results, because your code is broken. That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with. If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color. But that isn't something I'd go test... Too much system-y stuff that can modify it. And you're putting that into production code? Cause that's the entire point of this topic :). like Walter has been arguing, are better left untested in production. That's not what Walter has been arguing.
Re: This thread on Hacker News terrifies me
On 02/09/2018 12:57 AM, tide wrote: On Saturday, 1 September 2018 at 12:49:12 UTC, rikki cattermole wrote: On 02/09/2018 12:37 AM, tide wrote: On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? Experience will guide you on where to put the asserts. But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up. Apply common sense and assert on unreasonable results, because your code is broken. That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with. If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color. But that isn't something I'd go test... Too much system-y stuff that can modify it. And you're putting that into production code? Cause that's the entire point of this topic :). Goodness no. I can BSOD Windows just by writing user-land code that pretty much every program uses (yes related). Some things can definitely be tested in an assert, however like Walter has been arguing, are better left untested in production. Keep in mind, a window whose decorations has changed color, is a very reasonable and should be expected situation. It is no where near an error. This is one of the reasons I wouldn't bother with automated UI testing. Too many things can make it fail that is not related to your code, and integration may as well not exist cross-platform anyway. Let alone be well defined.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 12:49:12 UTC, rikki cattermole wrote: On 02/09/2018 12:37 AM, tide wrote: On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? Experience will guide you on where to put the asserts. But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up. Apply common sense and assert on unreasonable results, because your code is broken. That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with. If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color. But that isn't something I'd go test... Too much system-y stuff that can modify it. And you're putting that into production code? Cause that's the entire point of this topic :).
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thu, 23 Aug 2018 14:29:23 +, bachmeier wrote: > Weka is an awesome project, but I don't know that most people > considering D should use your experience as the basis of their decision. > At least in my areas, I expect considerable growth in the usage of D > over the next 10 years. Maybe it won't see much traction as a C++ > replacement for large projects like Weka. As long as D calls itself a systems language (which I believe is still the case), the experience of organizations building large systems is extremely important -- for organizations that want to build large systems.
Re: This thread on Hacker News terrifies me
On 02/09/2018 12:21 AM, tide wrote: On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote: On 01/09/2018 12:40 PM, tide wrote: On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: On 8/31/2018 2:40 PM, tide wrote: I don't think I've ever had a **game** hung up in a black screen and not be able to close it. I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix. Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries. And yet they manage to run a JVM with Java on it. Not the one's Walter is talking about. I rarely have to power cycle any smart device, even my phone which is running so much shit on it. For some reason I have memories related to DVD players containing a JVM to provide interactivity. But it doesn't look like those memory were based on anything. So ignore me.
Re: This thread on Hacker News terrifies me
On 02/09/2018 12:37 AM, tide wrote: On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? Experience will guide you on where to put the asserts. But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up. Apply common sense and assert on unreasonable results, because your code is broken. That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with. If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color. But that isn't something I'd go test... Too much system-y stuff that can modify it.
Re: D is dead
On Sat, 01 Sep 2018 11:25:31 +, rjframe wrote: > Should you have to fix the bugs you run into? No. But if they keep you > from doing your work, it seems like the economics of fixing D's bugs can > make sense. If Weka were to assign its own priorities to D's bugs*, and > have one person, once a week, fix the largest-priority bug, how big of > an investment would that be, and would the return be worth it? Many bugs > will definitely not be worth your time, but others might. You've answered this already; my apologies for the noise. --Ryan
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? Experience will guide you on where to put the asserts. But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up. Apply common sense and assert on unreasonable results, because your code is broken. That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 08:05:58 UTC, Walter Bright wrote: On 8/31/2018 5:47 PM, tide wrote: I've already read them before. Why don't you explain what is wrong with it rather than posting articles. Because the articles explain the issues at length. Explaining why your proposal is deeply flawed was the entire purpose I wrote them. I didn't write a proposal. I was explaining a flaw in your proposal. You are just taking one line comments without even thinking about the context. We can start with the observation that a fly-by-wire is not a fundamentally different system than a fully powered hydraulic system or even a pilot muscle cable system, when we're talking about safety principles. It is vastly different, do you know what fly by wire is? It means the computer is taking input digitally and applying the commands from the digital input into actual output. If the system controlling that just stops working, how do you expect the pilot to fly the plane? While all they are doing is moving a digital sensor that is doing nothing because the system that reads it input hit an assert. There's nothing magic about software. It's just more complicated (a fact that makes it even MORE important to adhere to sound principles, not throw them out the window). I didn't say to throw them the door, I'm saying there's a lot of different ways to do things. And using asserts isn't the one ring to rule all safety measures. There are different methods, and depending on the application, as with anything, has it's pros and cons where a different method will be more suitable.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thu, 23 Aug 2018 15:35:45 +, Joakim wrote: >> * Language complexity >> >> Raise your hand if you know how a class with both opApply and the >> get/next/end functions behaves when you pass it to foreach. >> How about a struct? Does it matter if it allows copying or not? >> >> The language was built because C++ was deemed too complex! Please see >> the thread about lazy [1] for a case where a question actually has an >> answer, but nobody seems to know it (and the person who does know it is >> hard pressed to explain the nuance that triggers this). > > By this rationale, C++ should be dead by now. Why do you think it's > fatal to D? It's worth noting that C++ isn't always chosen for its technical merits. It's a well-known language whose more or less standard status in certain domains means it's the default choice; C++ is sometimes used for projects in which Stroustrup would say it's obviously the wrong language for the job. D is far more likely to require justification based on technical merit. If D becomes another C++, why bother taking a chance with D when you can just use C++, use a well-supported, commonly-used compiler, and hire from a bigger pool of jobseekers?
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 07:59:27 UTC, Walter Bright wrote: On 8/31/2018 5:40 PM, tide wrote: On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: On 8/31/2018 2:40 PM, tide wrote: I don't think I've ever had a **game** hung up in a black screen and not be able to close it. I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix. Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries. Doesn't matter. It's clear that DVD player software is written by cowboy programmers who likely believe that it's fine to continue running a program after it has entered an invalid state, presumably to avoid annoying customers. Newer DVD/Bluray players have an ethernet port on the back. I'd never connect such a P.O.S. malware incubator to my LAN. It does matter, I've programmed on embedded systems where the filename length was limited to 10 or so characters. There were all kinds of restrictions, how do you know when you have to power cycle that isn't an assert being hit and having the powercycle is the result of a hardware limitation that these "cowboy programmers" had no control over ? You are making a lot of wild assumptions to try and prove a point, and that all bugs can be solved with asserts (which they can't). Hey guys race conditions aren't a problem, just use an assert, mission fucking accomplished.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote: On 01/09/2018 12:40 PM, tide wrote: On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: On 8/31/2018 2:40 PM, tide wrote: I don't think I've ever had a **game** hung up in a black screen and not be able to close it. I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix. Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries. And yet they manage to run a JVM with Java on it. Not the one's Walter is talking about. I rarely have to power cycle any smart device, even my phone which is running so much shit on it.
Re: D is dead
On Thu, 23 Aug 2018 15:34:34 +, Matheus wrote: > Well, I'm D hobbyist and of course it's not a perfect language and you > have some valid points, but on the other hand I think it's very > disrespectful to come into a community and say the product that people > are working mainly as volunteers and without any payment "is dead". > > Matheus. Not necessarily. If you see somebody's about to drive off a cliff, warning them is a good thing to do. If someone thinks the direction D is headed will lead to the end of the language as a good/viable choice for programmers, then trying to change that direction is the best thing s/he can do.
Re: D is dead
On Thu, 23 Aug 2018 19:34:46 +, Abdulhaq wrote: > There is a class of developers who expect things to Just Work TM, > especially if they are told that it Just Works. Each time that they > discover some combination of features that doesn't work they have to > refactor their code and remember not to try that again. Ultimately the > developer painfully learns the things that they should not attempt to > use, or they give up before the process is complete and leave. I expect > the pain caused by this is much more acute in a commercial environment > where the pressure is on. > > Long term D developers have learnt not to bother with certain features > or combinations of features and forget all the pain they went through to > get that knowledge. They are ones saying, come in the water's lovely. +1 It's easy to recommend D to someone because it does X, Y, and Z so well, not realizing they need X, Y, and B. And D has a honeymoon period - it's so awesome and will solve all our problems... until you dig deeper, trying to get more and more out of it and struggle to make sense of how to make it fit together. The pragmatic approach to language design has its downsides.
Re: This thread on Hacker News terrifies me
On 9/1/2018 3:49 AM, Dennis wrote: On Friday, 31 August 2018 at 22:23:09 UTC, Walter Bright wrote: For example, in any CS program, are there any courses at all about this? In Year 1 Q4 of my Bachelor CS, there was a course "Software Testing and Quality Engineering" which covered things like test types (unit, end-to-end, smoke etc.), code coverage and design by contract. They taught how to implement invariants, preconditions and postconditions in Java by manually placing asserts (since unlike D, there's no `in`, `out` or `invariant` keywords in Java) but I don't recall anything related to recovery from errors, or using aviation safety principles to make a safe system from unreliable parts. They said that you can decide between security and performance when choosing to leave asserts on/off in release builds. Sigh. It's not just the software industry. Industry outside of aerospace appears to be ignorant of it. See the Deepwater Horizon, Fukushima, medical devices, Toyota car computers, it just goes on and on. One of my favorite examples is when the power failed in New Orleans during a storm, and the city flooded. Guess where the backup generators were located? In the basements! The flooding took them out. Only one building had power after the disaster, and they'd located the emergency generator above sea level. Only one did that. The backups were destroyed by the same situation that caused the need for the backups - flooding from power failure. Completely worthless design, because the systems were coupled.
Re: D is dead
On Thu, 23 Aug 2018 04:02:37 -0700, Walter Bright wrote: > On 8/23/2018 2:09 AM, Shachar Shemesh wrote: >> * The community >> >> Oh boy. >> >> Someone who carries weight needs to step in when the forum is trying to >> squash down on criticism. For Mecca, I'm able to do that [2], but for >> D, this simply doesn't happen. > > If someone is trying to squash criticism, I would like to see what > you're referring to. If a post contains unprofessional behavior, like > using f--k or harassing people, it will get removed. Simply being > critical is not removed (if it was, this this thread would have > disappeared). One problem is that "professional" has a broad range of meanings, and as variety of cultures are represented here. I've had bosses that thought things like "What's the f--- @^Q@#$ is wrong with you?" was professional if the person "deserved" it. It would be nice to have a published code of conduct; it doesn't need to be large or formal, just a simple definition of professional, respectful behavior. Anybody would be able to point to it, rather than hope you or someone who's around enough to feel comfortable calling someone out is on the NG at the time.
Re: This thread on Hacker News terrifies me
On 9/1/2018 2:15 AM, Paulo Pinto wrote: On Saturday, 1 September 2018 at 08:19:49 UTC, Walter Bright wrote: On 8/31/2018 11:59 PM, Paulo Pinto wrote: For example, in any CS program, are there any courses at all about this? Yes, we had them on my degree, I'm curious how the courses you took compared with the articles I wrote about it. I will read the articles later, but as overview, we learned about: [...] It appears to have nothing related to what the articles are about. I'm rather sad that I've never seen these ideas outside of the aerospace industry. Added to that is all the pushback on them I get here, on reddit, and on hackernews. I see the results all the time. Like when someone can use a radio to hack into a car computer via the keyless door locks, and take over the steering and braking system. Even worse, when engineers discuss that, it never occurs to them that critical systems should be electrically separate from the infotainment system and anything that receives wireless data. They just talk about "fixing the bug". BTW, people who run spy networks figured this out long ago. It's all divided up by "need to know" rules and cells. Any spy captured and tortured can only give up minimal information, not something that will allow the enemy to roll up the entire network.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? Experience will guide you on where to put the asserts. (...) Apply common sense and assert on unreasonable results, because your code is broken. Your examples are valid, but I just wanted to say the game development is a bit of a 'special' case in software engineering because there is often no clear 'correct' output for an input. The desired output is simply one that makes the players happy, which is subjective. Take for example a 3D game where a car gets stuck between bollards and launches into the air. The problem is that real-time physics engines work in discrete steps and try to solve constraints by adding force to push overlapping bodies away from each other. When a rigid body gets stuck inside another rigid body, the force it generates can be comically large. This problem is well known but a 'proper' fix is not easy, it's often solved by designing the geometry so that cars can't get stuck like that. Would an `assert(car.yVelocity < 200 m/s)` that causes the game to crash when that happens really make the game better? Many players actually enjoy such glitches. They don't like when their character randomly clips through the floor and falls into a void however. But how would you assert that doesn't happen? There's no formal definition for it. By the way, I'm sure the way the Unity game engine treats asserts will make you cry: "A failure of an assertion method does not break the control flow of the execution. On a failure, an assertion message is logged (LogType.Assert) and the execution continues."[1] That's in debug builds, in release builds they are removed completely. So my `Assert.IsNotNull()` fails but the assert message quickly gets buried under a slew of errors. Note that the game keeps running, the 'C# script component' of the entity in question just ceases to work. "The show must go on!" [1] https://docs.unity3d.com/ScriptReference/Assertions.Assert.html
Re: This thread on Hacker News terrifies me
On Saturday, September 1, 2018 2:19:07 AM MDT Kagamin via Digitalmars-d wrote: > On Friday, 31 August 2018 at 21:09:21 UTC, H. S. Teoh wrote: > >> Some countries do have engineering certifications and > >> professional permits for software engineering, but its still a > >> minority. > > > > [...] > > > > It's precisely for this reason that the title "software > > engineer" makes me cringe on the one hand, and snicker on the > > other hand. I honestly cannot keep a straight face when using > > the word "engineering" to describe what a typical programmer > > does in the industry these days. > > Huh? I'm pretty sure they mean it was a management decision. Why > do you blame engineers for doing what they are asked to do? > Making them write code properly is as simple as paying for > exactly that. I think that his point was more that it's sometimes argued that software engineering really isn't engineering in the classical sense. If you're talking about someone like a civil engineer for instance, the engineer applies well-known and established principles to everything they do in a disciplined way. The engineering aspects of civil engineering aren't subjective at all. They're completely based in the physical sciences. Software engineering on the other hand isn't based on the physical sciences at all, and there really isn't general agreement on what good software engineering principles are. There are aspects of it that are very much like engineering and others that are very much subjective. Someone else could probably explain it better than I could, but based on some definitions of engineering, software engineering definitely doesn't count, but it _does_ have aspects of engineering, so it can be argued either way. Wikipedia even has a "controversy" section on its page for software engineering that talks briefly about it: https://en.wikipedia.org/wiki/Software_engineering I'm not sure that I really agree that software engineering isn't engineering, but the folks who argue against it do have a point in that software engineering is definitely not like most other engineering disciplines, and good engineering practices are nowhere near as well-defined in software engineering as those in other engineering fields. Issues with management cause other problems on top of all of that, but even if you have a group of software engineers doing their absolute best to follow good software engineering principles without any kind of management interference, what they're doing is still very different from most engineering disciplines, and it likely wouldn't be hard for another group of competent software engineers to make solid arguments about why the good software engineering practices that they're following actually aren't all that good. - Jonathan M Davis
Re: D is dead
On Thu, 23 Aug 2018 21:04:36 +0300, Shachar Shemesh wrote: > On 23/08/18 20:52, bachmeier wrote: >> On Thursday, 23 August 2018 at 17:19:41 UTC, Ali wrote: >>> On Thursday, 23 August 2018 at 16:22:54 UTC, Shachar Shemesh wrote: On 23/08/18 17:01, Steven Schveighoffer wrote: My main job is to develop for Weka, not develop D itself. >>> >>> Weka, at some point, made the strategic decision to use a non >>> mainstream language >>> >>> I dont think Weka, have a choice, they have to invest in the >>> development of D itself >> >> I hope a startup can choose D without having to do that. Otherwise D is >> not really a viable option for startups because they need to focus on >> survival rather than language development. > > This! > > Maybe Weka can afford it, but being all smug about it is a destructive > attitude to have. I know that some of Weka's leadership are > uncomfortable about the fact that we, almost by definition, are facing > language related issues that no-one in the community has before us. > > Weka is in a good place, and is going in a good direction, but don't > forget that we are up against giants, and are selling a product where > 0.1% failure is considered the same as utter failure. Being able to > trust the compiler was supposed to be a given. > > Yes, Weka is, at this point, committed. The next start-up isn't. > > Shachar I don't really understand this reasoning; a compiler is a dependency, much like a third party library. When a dependency gets in the way of your product, you have to make a choice. If you can't afford 0.1% failure, then if the compiler is holding you back, the choice seems to be fix the compiler, replace the compiler/ language, or don't do what you want to do. Should you have to fix the bugs you run into? No. But if they keep you from doing your work, it seems like the economics of fixing D's bugs can make sense. If Weka were to assign its own priorities to D's bugs*, and have one person, once a week, fix the largest-priority bug, how big of an investment would that be, and would the return be worth it? Many bugs will definitely not be worth your time, but others might. * I don't know that it's common, but I have maintained third-party bugs in my own tracker; this makes it easy to check their changelog against the bugs I care about, especially when I don't subscribe to the bug in their tracker for one reason or other. Being able to prioritize their bugs against bugs in my own project also helps me decide whether to spend my time fixing the third-party library.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 31 August 2018 at 18:24:40 UTC, Laeeth Isharc wrote: On Friday, 31 August 2018 at 09:37:55 UTC, Chris wrote: On Wednesday, 29 August 2018 at 23:47:11 UTC, Laeeth Isharc wrote: On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote: 9. I hope D will be great again Are you someone who lives by hope and fears about things that have a meaning for you? Or do you prefer to take action? If the latter, what do you think might be some small step you could take to move the world towards the direction in which you think it should head. My experience of life is that in the end one way and another everything one does, big or small, turns out to matter and also that great things can have quite little beginnings. So what could you do towards the end you hope for ? Hope is usually the last thing to die. But one has to be wise enough to see that sometimes there is nothing one can do. As things are now, for me personally D is no longer an option, because of simple basic things, like autodecode, a flaw that will be there forever, poor support for industry technologies (Android, iOS) and the constant "threat" of code breakage. The D language developers don't seem to understand the importance of these trivial matters. I'm not just opinionating, by now I have no other _choice_ but to look for alternatives - and I do feel a little bit sad.
Re: This thread on Hacker News terrifies me
On Saturday, September 1, 2018 1:59:27 AM MDT Walter Bright via Digitalmars- d wrote: > On 8/31/2018 5:40 PM, tide wrote: > > On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: > >> On 8/31/2018 2:40 PM, tide wrote: > >>> I don't think I've ever had a **game** hung up in a black screen and > >>> not be able to close it. > >> > >> I've had that problem with every **DVD player** I've had in the last 20 > >> years. Power cycling is the only fix. > > > > Two very different things, odds are your DVD players code aren't even > > written with a complete C compiler or libraries. > > Doesn't matter. It's clear that DVD player software is written by cowboy > programmers who likely believe that it's fine to continue running a > program after it has entered an invalid state, presumably to avoid > annoying customers. > > Newer DVD/Bluray players have an ethernet port on the back. I'd never > connect such a P.O.S. malware incubator to my LAN. Unfortunately, in the case of Blu-ray players, if you don't, at some point, you likely won't be able to play newer Blu-rays, because they keep updating the DRM on the discs, requiring updates to the players - which is annoying enough on its own, but when you consider that if it weren't for the DRM, there wouldn't be any reason to hook up a Blu-ray player to a network, the fact that the DRM essentially requires it is that much more egregious. But sadly, increasingly, they seem to want you to hook up all of your stray electronics to the network, which is anything but safe. Fortunately, not all of them actually require it (e.g. I've never hooked up my TV to any network, and I see no value in anything it runs that would require it), but too many do. - Jonathan M Davis
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 31 August 2018 at 15:43:13 UTC, H. S. Teoh wrote: [...] I wasn't talking about that, but about the fact that users are slowly but surely nudged into a certain direction. And yes, D was advertised as a "no ideology language". Sorry, "slowly but surely nudged" sounds very different from "forcing you into a new paradigm every 1 1/2 years". So which is it? A nudge, presumably from recommended practices which you don't really have to follow (e.g., I don't follow all D recommended practices in my own code), or a strong coercion that forces you to rewrite your code in a new paradigm or else? T Ah yeah, fair play to you. I knew I someone would see the force / nudge thing. You're nudged over the years until you end up being forced to use a certain paradigm. There's nothing wrong with languages "forcing" you to use certain paradigms as long as it's clear from the start and you know what you're in for. But moving the goalposts as you go along is a bit meh. I remember that Walter said that once he didn't care about (or even understand) templates. Then it was all templates, now it's functional programming (which I like). What will be next? Forced `assert` calls in every function? I can already see it... But, again, it's this attitude of nitpicking over words (nudge / force) instead of addressing the issues that alarms me. It's not a good sign.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 22:23:09 UTC, Walter Bright wrote: For example, in any CS program, are there any courses at all about this? In Year 1 Q4 of my Bachelor CS, there was a course "Software Testing and Quality Engineering" which covered things like test types (unit, end-to-end, smoke etc.), code coverage and design by contract. They taught how to implement invariants, preconditions and postconditions in Java by manually placing asserts (since unlike D, there's no `in`, `out` or `invariant` keywords in Java) but I don't recall anything related to recovery from errors, or using aviation safety principles to make a safe system from unreliable parts. They said that you can decide between security and performance when choosing to leave asserts on/off in release builds. In Year 2 Q1 there was a follow-up "Software Engineering Methods" course which talked about Design Patterns (the GoF ones), process (SCRUM / Agile), and designing (with UML and other graphs). No other courses since then talked about software engineering, they were more focused on specific fields (big data, signal processing, embedded systems) and fundamental computer science (algorithms, complexity theory, programming languages).
Re: This thread on Hacker News terrifies me
On 31/08/18 23:22, Steven Schveighoffer wrote: On 8/31/18 3:50 PM, Walter Bright wrote: https://news.ycombinator.com/item?id=17880722 Typical comments: "`assertAndContinue` crashes in dev and logs an error and keeps going in prod. Each time we want to verify a runtime assumption, we decide which type of assert to use. We prefer `assertAndContinue` (and I push for it in code review)," e.g. D's assert. Well, actually, D doesn't log an error in production. -Steve I think it's the music of the thing rather than the thing itself. Mecca has ASSERT, which is a condition always checked and that always crashes the program if it fails, and DBG_ASSERT, which, like D's built in assert, is skipped in release mode (essentially, an assert where you can log what went wrong without using the GC needing format). When you compare this to what Walter was quoting, you get the same end result, but a vastly different intention. It's one thing to say "this ASSERT is cheap enough to be tested in production, while this DBG_ASSERT one is optimized out". It's another to say "well, in production we want to keep going no matter what, so we'll just ignore the asserts". Shachar
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 08:19:49 UTC, Walter Bright wrote: On 8/31/2018 11:59 PM, Paulo Pinto wrote: For example, in any CS program, are there any courses at all about this? Yes, we had them on my degree, I'm curious how the courses you took compared with the articles I wrote about it. I will read the articles later, but as overview, we learned about: - requirements gathering - architecture design based on several methodologies, back then it was Booch, ER, Coad and the newly introduced UML - introduction to way to manage source control, rcs and cvs - design by contract, via Eiffel - use of abstract data types as means to achieve clean architectures with separation of concerns - ways to perform testing, way before unit testing was even a thing - we had a semester project going from requirements gathering, design and implementation that was validated how well it achieved those goals. Which on my year it was the implementation of subway ticketing system with automatic control of access doors, just the software part. The sensors and door controls were simulated. And the implementation of a general purpose B+ tree library, another semester long project, whose integration tests where not available to us. We had one week time to make our library could link and successfully execute all the tests that the teacher came up with for the acceptance testing phase. We did not have access to their source code, we just provided our lib.a.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 21:09:21 UTC, H. S. Teoh wrote: Some countries do have engineering certifications and professional permits for software engineering, but its still a minority. [...] It's precisely for this reason that the title "software engineer" makes me cringe on the one hand, and snicker on the other hand. I honestly cannot keep a straight face when using the word "engineering" to describe what a typical programmer does in the industry these days. Huh? I'm pretty sure they mean it was a management decision. Why do you blame engineers for doing what they are asked to do? Making them write code properly is as simple as paying for exactly that.
