Re: This thread on Hacker News terrifies me
Then there are polytechnics which I went to for my degree, where the focus was squarely on Industry and not on academia at all. But in saying that, we had third year students starting out not understanding how cli arguments work so... Proper software engineering really takes 5+ years just to get started, 10+ to become actually good at it. Sadly that won't be acceptable in our current society.
Re: This thread on Hacker News terrifies me
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.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 22:05:18 UTC, H. S. Teoh wrote: On Fri, Aug 31, 2018 at 09:40:50PM +, tide via Digitalmars-d wrote: On Friday, 31 August 2018 at 21:31:02 UTC, 0xEAB wrote: [...] > Furthermore, how often have we cursed about games that hung > up with a blackscreen and didn't let us close them by any > mean other than logging off? If they just crashed, we'd not > have run into such problems. That's assuming an assert catches every error. Not all bugs are going to be caught by an assert. I don't think I've ever had a game hung up in a black screen and not be able to close it. I have, and that's only one of the better possible scenarios. I've had games get into a bad state, which becomes obvious as visual glitches, and then proceed to silently and subtly corrupt the save file so that on next startup all progress is lost. Had the darned thing aborted at the first visual glitch or unexpected internal state, instead of blindly barging on pretending that visual glitches are not a real problem, the save file might have still been salvageable. (Yes, visual glitches, in and of themselves, aren't a big deal. Most people may not even notice them. But when they happen unexpectedly, they can be a symptom of a deeper, far more serious problem. Just like an assert detecting that some variable isn't the expected value. Maybe the variable isn't even anything important; maybe it just controls the color of the title bar or something equally irrelevant. But it could be a sign that there's been a memory corruption. It could be a sign that the program is in the middle of being exploited by a security hack. The unexpected value in the variable isn't merely an irrelevant thing that we can safely ignore; it could be circumstantial evidence of something far more serious. Continuing to barrel forward in spite of clear evidence pointing to a problem is utterly foolish.) T 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 ?
Re: Looking for a mentor for SAoC
On Monday, 27 August 2018 at 20:47:08 UTC, Stefam Koch wrote: I guess I could help you out with coff. generating it is not the problem but linking it on windows currently requires the MS linker. which may not be desired. then again ... I think binutils do support coff as well. I might need you as a mentor. Currently I'm thinking out of the milestones, I probably can fully convert Mago to D by the end of September, in October I'll work on getting the COFF64 support at the same level as 32 bit ones, November and December will be spent with developing a GUI and bug fixes.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 22:27:47 UTC, Walter Bright wrote: On 8/31/2018 2:21 PM, tide wrote: On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote: "Stopping all executing may not be the correct 'safe state' for an airplane though!" Depends on the aircraft and how it is implemented. If you have a plane that is fly by wire, and you stop all executing then even the pilot no longer has control of the plane anymore, which would be very bad. I can't even read the rest of posting after this. Please read the following articles, then come back. Assertions in Production Code https://www.digitalmars.com/articles/b14.html Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html Designing Safe Software Systems Part 2 https://www.digitalmars.com/articles/b40.html I've already read them before. Why don't you explain what is wrong with it rather than posting articles. You are just taking one line comments without even thinking about the context.
Re: This thread on Hacker News terrifies me
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.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 23:47:40 UTC, Jonathan M Davis wrote: The are plenty of cases where the teachers actually do an excellent job teaching the material that the courses cover. It's just that the material is often about theoretical computer science - and this is actually stuff that can be very beneficial to becoming an excellent programmer. However, many teachers really aren't great programmers. They aren't necessarily bad programmers, but unless they spent a bunch of time in industry before teaching, odds are that they don't have all of the software engineering skills that the students are going to need once they get into the field. And most courses aren't designed to teach students the practical skills. Imagine getting a Industrial Engineer that switched over to become a teacher, showing up to teach Visual Basic and Database normalization. That same teacher used one of those red little VB books for his study material ( been 20+ years ago, not sure if they still exist ). The students ended up helping each other fixing issues because the teacher was useless. It was even so bad, he took examples out of the book, little bit reformatted the questions and used that for tests. Of course one of our fellow students figure this out, he got his hands on the book and voila, every test answer. Worst was that the teacher was so BORING, that nobody wanted to sit in the front of the class, because his database class was so bad, people literally needed to keep each other up from falling asleep. I am not joking! You can guess that i never learned database normalization in school and ended up doing it on my own. So yea, first hand experience with bad teachers. The guy that did C++ was way better and you actually learned from him. A bit scary guy but knew his stuff. Teachers make all the difference for children/students to learn anything. If they are boring, burned out or just doing it to earn money, it shows in the lacking responds and score of the students. A good teacher draws in the students and helps them focus. A good teacher does not make things over complicated and does not assume that everybody understand. Seen brilliant teachers that are horrible at teaching because they are so smart ( or repeated the same material so much ), they assume everybody understands everything as they do. Teacher make all the difference in teaching but a lot is so politicizes/internal power games, ... that good teachers tend to leave and bad ones just end up doing the job, because its a good government/public servant job with nice vacation perks ( here in the EU ).
Re: This thread on Hacker News terrifies me
On Fri, Aug 31, 2018 at 05:47:40PM -0600, Jonathan M Davis via Digitalmars-d wrote: [...] > The school I went to (Cal Poly, San Luis Obispo) at least tries to > focus on the practical side of things (their motto is "learn by > doing"), and when I went there, they even specifically had a Software > Engineering degree where you had to take a year-long course where you > did a project in a team for a company. But at least at the time, the > big difference between the SE and CS degrees was that they required > more classes with group work and fewer theoretical classes, and there > certainly weren't any classes on something like debugging. The > software engineering-centric classes focused more on a combination of > teaching stuff like classic design patterns and then having you do > projects in groups. And that was helpful, but it still didn't really > prepare you for what you were going to be doing in your full-time job. > It's still better than what a lot of schools do though. I'm frequently > shocked by how little many CS graduates know when they first get out > of school. [...] I suppose it depends on the school. And yes, I've seen CS graduates who have literally never written a program longer than 1 page. I cannot imagine what kind of shock they must have felt upon getting a job in the industry and being faced, on their first day, with a 2 million LOC codebase riddled with hacks, last-minute-rushed fixes, legacy code that nobody understands anymore, inconsistent / non-existent documentation, and being tasked with fixing a bug of unclear description and unknown root cause which could be literally *anywhere* in those 2 million LOC. I was lucky that I was spared of most of the shock due to having spent a lot of time working on personal projects while at school, and thereby picking up many practical debugging skills. T -- Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds
Re: This thread on Hacker News terrifies me
On Friday, August 31, 2018 5:20:08 PM MDT H. S. Teoh via Digitalmars-d wrote: > A consequence of this disconnect is that the incentives are set up all > wrong. Professors are paid to publish research papers, not to teach > students. Teaching is often viewed as an undesired additional burden > you're obligated to carry out, a chore that you just want to get over > with in the fastest, easiest possible way, so that you can go back to > doing research. After all, it's the research that will win you the > grants, not the fact that you won teaching awards 3 years in a row, or > that your students wrote a glowing review of your lectures. So the > quality of teaching already suffers. The are plenty of cases where the teachers actually do an excellent job teaching the material that the courses cover. It's just that the material is often about theoretical computer science - and this is actually stuff that can be very beneficial to becoming an excellent programmer. However, many teachers really aren't great programmers. They aren't necessarily bad programmers, but unless they spent a bunch of time in industry before teaching, odds are that they don't have all of the software engineering skills that the students are going to need once they get into the field. And most courses aren't designed to teach students the practical skills. How that goes exactly depends on the school, with some schools actually trying to integrate software engineering stuff, but many really don't. So, even if the schools do an excellent job teaching what they're trying to teach, it still tends to be on the theoretical side of things. But that may be improving. Still, the theoretical side is something that programmers should be learning. It's just that it isn't enough on its own, and it serves more as a good foundation than as the set of skills that you're going to be using directly on the job on a day to day basis. The school I went to (Cal Poly, San Luis Obispo) at least tries to focus on the practical side of things (their motto is "learn by doing"), and when I went there, they even specifically had a Software Engineering degree where you had to take a year-long course where you did a project in a team for a company. But at least at the time, the big difference between the SE and CS degrees was that they required more classes with group work and fewer theoretical classes, and there certainly weren't any classes on something like debugging. The software engineering-centric classes focused more on a combination of teaching stuff like classic design patterns and then having you do projects in groups. And that was helpful, but it still didn't really prepare you for what you were going to be doing in your full-time job. It's still better than what a lot of schools do though. I'm frequently shocked by how little many CS graduates know when they first get out of school. - Jonathan M Davis
Re: This thread on Hacker News terrifies me
On Fri, Aug 31, 2018 at 04:45:57PM -0600, Jonathan M Davis via Digitalmars-d wrote: > On Friday, August 31, 2018 4:23:09 PM MDT Walter Bright via Digitalmars-d > wrote: [...] > > That won't fix anything, because there is NO conventional wisdom in > > software engineering for how to deal with program bugs. I suspect I > > am the first to try to apply principles from aerospace to general > > engineering (including software). > > > > For example, in any CS program, are there any courses at all about > > this? > > There are probably some somewhere, but most CS programs really aren't > about writing good software or even being a software engineer. Some > definitely try to bring some focus on that, but it's far, far more > common that the focus is on computer science concepts and not on > software engineering. A good CS program gives you a lot of theory, but > they're rarely big on the practical side of things. [...] > It's often pretty scary how poor the average programer is, and in my > experience, when trying to hire someone, you can end up going through > a lot of really bad candidates before finding someone even passable > let alone good. [...] 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. The goal in the industry is to produce working software. The industry doesn't really care if you discovered an amazing new way of thinking about software; they want to actually produce software that can be shipped to the customer, even if it isn't using the latest and greatest theoretical concepts. So they don't really care how good a grasp you have on computability theory, but they *do* care a lot that you know how to debug a program so that it can be shipped on time. (They don't care *how* you debug the program, just that you know how to to it, and do it efficiently.) A consequence of this disconnect is that the incentives are set up all wrong. Professors are paid to publish research papers, not to teach students. Teaching is often viewed as an undesired additional burden you're obligated to carry out, a chore that you just want to get over with in the fastest, easiest possible way, so that you can go back to doing research. After all, it's the research that will win you the grants, not the fact that you won teaching awards 3 years in a row, or that your students wrote a glowing review of your lectures. So the quality of teaching already suffers. Then the course material itself is geared toward producing more researchers, rather than industry workers. After all, the institution needs to replace aging and retiring faculty members in order to continue existing. To do that, it needs to produce students who can become future researchers. And since research depends on theory, theory is emphasized, and pragmatism like debugging skills aren't really relevant. On the other side of the disconnect, the industry expects that students graduating from prestigious CS programs ought to know how to program. The hiring manager sees a degree from MIT or Stanford and is immediately impressed; but he doesn't have the technical expertise to realize what that degree actually means: that the student excelled in the primarily theory-focused program, which may or may not translate to practical skills like programming and debugging ability that would make them productive in the industry. All the hiring manager knows is that institution Y is renowned for their CS program, and therefore he gives more weight to candidates who hold a degree from Y, even if that actually doesn't guarantee that the candidate will be a good programmer. As a result, the software department is filled up with people who are good at theory, but whose practical programming skills can range anywhere from passably good to practically non-existent. And now these people with wide-ranging programming abilities have to work together as a team. Is it any wonder at all that the quality of the resulting software is so bad? T -- Amateurs built the Ark; professionals built the Titanic.
Re: This thread on Hacker News terrifies me
On Friday, August 31, 2018 4:23:09 PM MDT Walter Bright via Digitalmars-d wrote: > On 8/31/2018 1:42 PM, Paulo Pinto wrote: > > Some countries do have engineering certifications and professional > > permits for software engineering, but its still a minority. > > That won't fix anything, because there is NO conventional wisdom in > software engineering for how to deal with program bugs. I suspect I am > the first to try to apply principles from aerospace to general > engineering (including software). > > For example, in any CS program, are there any courses at all about this? There are probably some somewhere, but most CS programs really aren't about writing good software or even being a software engineer. Some definitely try to bring some focus on that, but it's far, far more common that the focus is on computer science concepts and not on software engineering. A good CS program gives you a lot of theory, but they're rarely big on the practical side of things. I think that it's a rarity for programmers to graduate college with a good understanding of how to be a good software engineer in the field. That's the sort of thing that they're much more likely to learn on the job, and plenty of jobs don't do a good job with it. Motivated programmers can certainly find resources for learning good software engineering skills and/or find mentors who can help them learn them - and many programmers do - but it's _very_ easy to learn enough programming to get a job and get by without being very good at it. And if a programmer isn't really motivated to improve themselves, it's highly unlikely that they're going to have good software engineering skills. It's often pretty scary how poor the average programer is, and in my experience, when trying to hire someone, you can end up going through a lot of really bad candidates before finding someone even passable let alone good. - Jonathan M Davis
Re: This thread on Hacker News terrifies me
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.
Re: This thread on Hacker News terrifies me
On 8/31/2018 2:21 PM, tide wrote: On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote: "Stopping all executing may not be the correct 'safe state' for an airplane though!" Depends on the aircraft and how it is implemented. If you have a plane that is fly by wire, and you stop all executing then even the pilot no longer has control of the plane anymore, which would be very bad. I can't even read the rest of posting after this. Please read the following articles, then come back. Assertions in Production Code https://www.digitalmars.com/articles/b14.html Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html Designing Safe Software Systems Part 2 https://www.digitalmars.com/articles/b40.html
Re: This thread on Hacker News terrifies me
On 8/31/2018 1:42 PM, Paulo Pinto wrote: Some countries do have engineering certifications and professional permits for software engineering, but its still a minority. That won't fix anything, because there is NO conventional wisdom in software engineering for how to deal with program bugs. I suspect I am the first to try to apply principles from aerospace to general engineering (including software). For example, in any CS program, are there any courses at all about this?
Re: This thread on Hacker News terrifies me
On Fri, Aug 31, 2018 at 09:40:50PM +, tide via Digitalmars-d wrote: > On Friday, 31 August 2018 at 21:31:02 UTC, 0xEAB wrote: [...] > > Furthermore, how often have we cursed about games that hung up with > > a blackscreen and didn't let us close them by any mean other than > > logging off? If they just crashed, we'd not have run into such > > problems. > > That's assuming an assert catches every error. Not all bugs are going > to be caught by an assert. I don't think I've ever had a game hung up > in a black screen and not be able to close it. I have, and that's only one of the better possible scenarios. I've had games get into a bad state, which becomes obvious as visual glitches, and then proceed to silently and subtly corrupt the save file so that on next startup all progress is lost. Had the darned thing aborted at the first visual glitch or unexpected internal state, instead of blindly barging on pretending that visual glitches are not a real problem, the save file might have still been salvageable. (Yes, visual glitches, in and of themselves, aren't a big deal. Most people may not even notice them. But when they happen unexpectedly, they can be a symptom of a deeper, far more serious problem. Just like an assert detecting that some variable isn't the expected value. Maybe the variable isn't even anything important; maybe it just controls the color of the title bar or something equally irrelevant. But it could be a sign that there's been a memory corruption. It could be a sign that the program is in the middle of being exploited by a security hack. The unexpected value in the variable isn't merely an irrelevant thing that we can safely ignore; it could be circumstantial evidence of something far more serious. Continuing to barrel forward in spite of clear evidence pointing to a problem is utterly foolish.) T -- Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy
Re: Engine of forum
On Friday, 24 August 2018 at 01:43:54 UTC, Walter Bright wrote: Why can't syntax formatting be implemented, does anyone disagree that is a useless feature? It's a useless feature. Formatting is needed for longer form text, which is not really appropriate for the forum. Forum posts should be short and to the point - posting an article or manifesto should be posted separately, with a link to it in the forum. Moreover, for those who really want to show their code: There are sites like run.dlang.io or dpaste.dzfl.pl. They don't just store one's code snippets for viewing them with syntax highlighting, they also come with the handy feature of allowing one to execute them directly via their webservice.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 21:40:50 UTC, tide wrote: The asserts being there still cause slow downs in things that would otherwise not be slow. Like how D does assert checks for indices. After the bug is fixed and the app is debugged, there's no need to keep those assertions. The release switch will do the job. Anyway, what's that got to do with the topic of this thread? That's assuming an assert catches every error. Not all bugs are going to be caught by an assert. not really, at least that's not what I meant. (well, in theory one could write enough assertions to detect any error, but... nvm, I agree with you). What I meant were apps misbehaving because of obviously ignored errors. I don't think I've ever had a game hung up in a black screen and not be able to close it. Lucky one :)
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 21:31:02 UTC, 0xEAB wrote: On Friday, 31 August 2018 at 21:21:16 UTC, tide wrote: Depends on the software being developed, for a game? Stopping at every assert would be madness. Let a lone having an over ubundance of asserts. Can't even imagine how many asserts there would be in for something like a matrix multiplication. If one is aware that something is asserting quite often, why don't they just fix the bug that causes that assertion to fail? The asserts being there still cause slow downs in things that would otherwise not be slow. Like how D does assert checks for indices. Furthermore, how often have we cursed about games that hung up with a blackscreen and didn't let us close them by any mean other than logging off? If they just crashed, we'd not have run into such problems. That's assuming an assert catches every error. Not all bugs are going to be caught by an assert. I don't think I've ever had a game hung up in a black screen and not be able to close it.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 21:21:16 UTC, tide wrote: Depends on the software being developed, for a game? Stopping at every assert would be madness. Let a lone having an over ubundance of asserts. Can't even imagine how many asserts there would be in for something like a matrix multiplication. If one is aware that something is asserting quite often, why don't they just fix the bug that causes that assertion to fail? Furthermore, how often have we cursed about games that hung up with a blackscreen and didn't let us close them by any mean other than logging off? If they just crashed, we'd not have run into such problems.
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: "Stopping all executing may not be the correct 'safe state' for an airplane though!" Depends on the aircraft and how it is implemented. If you have a plane that is fly by wire, and you stop all executing then even the pilot no longer has control of the plane anymore, which would be very bad. "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. Depends on the software being developed, for a game? Stopping at every assert would be madness. Let a lone having an over ubundance of asserts. Can't even imagine how many asserts there would be in for something like a matrix multiplication. An operation that would otherwise be branchless having numerous branches for all the index checks that would be done. Twice per scalar value access. And so on and so on. 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. TIL people still use DVD players all the while my desktops and laptops from the last 7+ years have not even had an optical drive.
Re: Assertions in production code on Reddit
On Fri, Aug 31, 2018 at 02:02:39PM -0700, Walter Bright via Digitalmars-d-announce wrote: > On 8/31/2018 1:19 PM, Nick Sabalausky (Abscissa) wrote: > > (IF the programmer in question even has the expertise to implement > > such a system correctly anyway - and most don't). > > The closer you can get to the ideal, the better. It's not all or > nothing. > > I'll have done my job if people would just quit justifying sticking > their fingers in their ears and shouting lalalalalalalalal when a bug > is detected. > > Don't you find it terrifying that nobody has even written a book on > the topic? Maybe you should write the first one. :-D T -- Never wrestle a pig. You both get covered in mud, and the pig likes it.
Re: This thread on Hacker News terrifies me
On Fri, Aug 31, 2018 at 08:42:38PM +, Paulo Pinto via Digitalmars-d wrote: > On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote: > > https://news.ycombinator.com/item?id=17880722 [...] > > 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: [...] > 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. Where are the procedures, documentations, verification processes, safeguards, certifications, culpability, etc., etc., that make engineering the respected profession that it is? They are essentially absent in typical software development environments, or only poorly aped in the most laughable ways. Most "enterprise" software has no proper design document at all; what little documentation does exist is merely a lip-service shoddy hack-job done after the fact to justify the cowboying that has gone on before. It's an embarrassment to call this "engineering", and a shame to real engineers who have actual engineering procedures to follow. Until the software industry gets its act together and become a real, respectable engineering field, we will continue to suffer from unreliable software that malfunctions, eats your data, and crashes on unusual inputs for no good reason other than that it was never properly engineered. And malware and catastrophic security breaches will continue to run rampant in spite of millions and billions of dollars being poured into improving security every year. And of course, more and more of modern life is becoming dependent on devices controlled by software of such calibre (IoT... *shudder*). It's a miracle that society hasn't collapsed yet! T -- There are three kinds of people in the world: those who can count, and those who can't.
Re: Assertions in production code on Reddit
On 8/31/2018 1:19 PM, Nick Sabalausky (Abscissa) wrote: (IF the programmer in question even has the expertise to implement such a system correctly anyway - and most don't). The closer you can get to the ideal, the better. It's not all or nothing. I'll have done my job if people would just quit justifying sticking their fingers in their ears and shouting lalalalalalalalal when a bug is detected. Don't you find it terrifying that nobody has even written a book on the topic?
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. You would probably enjoy this talk. "Hayley Denbraver We Are 3000 Years Behind: Let's Talk About Engineering Ethics" https://www.youtube.com/watch?v=jUSJePqplDA I think that until lawsuits and software refunds due to malfunctions escalate to a critical level, the situation will hardly change. Some countries do have engineering certifications and professional permits for software engineering, but its still a minority. -- Paulo
Re: This thread on Hacker News terrifies me
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
Re: Assertions in production code on Reddit
On 08/30/2018 05:31 PM, Walter Bright wrote: https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/ > >High reliability is not achieved by making perfect designs, it is >achieved by making designs that are tolerant of failure. Runtime >checking is essential to this, as when a fault is detected the program >can go into a controlled state doing things like: > >aborting before more harm is done >alerting the user that the results are not reliable >saving any work in process >engaging any backup system >restarting the system from a known good state >going into a 'safe mode' to await further instructions > I'm totally all for all of this in principle. But here's the problem: Aside from "abort the process immediately once...uhh, once the faulty process itself has already successfully *detected itself to be faulty*" (ie, already a violation of the basic principles being promoted in the article), we don't actually HAVE ready-to-use facilities for any of this. Since we don't actually have such facilities, getting people to actually code by them IS going to be an even bigger uphill battle than trying to get them to unittest without any ready-to-use unittesting facilities. And then THAT leads to yet another problem: If they're not actually coding by those principles (which they're obviously not doing because the facilities to do so aren't there), then they ARE occasionally going to be needing *some* code to be run after the fault occurs: For example: - Evaluating the assert condition to even detect something went wrong at all. - Generating the assert failure reporting string. - Generating the stack trace. - Sending the failure string and stack trace to the logging process. Oh wait, we don't have an external logging process facility... - Directly reporting and logging and the failure string and stack trace. (And that list still ignores any cleanup the OS can't/doesn't know to do on our behalf.) And, shit, if it's even POSSIBLE to do any of that within "the process that's already in an undefined state", then clearly we already have enough successful intra-process compartmentalization that the "At this point, we can't rely on ANYTHING!!!" notion is demonstrably bogus anyway. Don't get me wrong, I'd LOVE to be able to do things as you suggest: To have all my fault-handling functionality and STILL have zero-reliance on the faulty process. But we DON'T have those facilities, therefore, nobody outside aeronautics, pacemaker firmware, etc, is realistically going to be able to justify going to all bother of creating such facilities to go along with their website, or text editor, or number-crunching tool, or videogame, etc... (IF the programmer in question even has the expertise to implement such a system correctly anyway - and most don't).
This thread on Hacker News terrifies me
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.
Re: Copr repository providing dmd and dub for Fedora, EPEL and Mageia
On Friday, 31 August 2018 at 19:41:59 UTC, Martin Nowak wrote: Nice one. I see that you're using ldc as bootstrap/host compiler. While that will result in faster binaries (in particular useful for dmd), the official binaries releases are still built with dmd for now. Just worth noting as it might lead to specific bugs not present in the official binaries. I actually used dmd until very recently, and still use dmd on Mageia and EPEL. I switched to ldc because of weird linker errors on Fedora 29, but since it's still in development I have no idea if this is the problem comes from dmd or Fedora. I might go back to using dmd if it turns out to work again.
Re: Copr repository providing dmd and dub for Fedora, EPEL and Mageia
On Friday, 31 August 2018 at 18:44:23 UTC, Laurent Tréguier wrote: The repo is used just like any other Copr repo: sudo dnf copr enable tcg/devel sudo dnf install dmd dub Since Copr also allows building packages for EPEL and Mageia, I'm launching builds for them as well. [1] https://copr.fedorainfracloud.org/coprs/tcg/devel/ Nice one. I see that you're using ldc as bootstrap/host compiler. While that will result in faster binaries (in particular useful for dmd), the official binaries releases are still built with dmd for now. Just worth noting as it might lead to specific bugs not present in the official binaries.
Re: Engine of forum
On Friday, 24 August 2018 at 01:43:54 UTC, Walter Bright wrote: Nearly 20 years of the D forum consumes 2,800,000 4K blocks, or somewhat over a gigabyte. Not bad. Using years is about a pointless as using lines of code to evaluate a project. There's some sites that have received more throughput of users and their activity in one year than this site has seen in 20.
Re: Engine of forum
On Friday, 24 August 2018 at 01:43:54 UTC, Walter Bright wrote: On 8/21/2018 2:41 PM, tide wrote: What about if you accidentially press a button that posts the comment? That's really up to your NNTP client's design, which we didn't implement. There are lots of NNTP clients to choose from. Don't use a NNTP client, I prefer to just use a browser. Why can't syntax formatting be implemented, does anyone disagree that is a useless feature? It's a useless feature. Formatting is needed for longer form text, which is not really appropriate for the forum. Forum posts should be short and to the point - posting an article or manifesto should be posted separately, with a link to it in the forum. Also, there is no need to post pictures, emoji, banners, or other cruft one sees in other forums. Especially pictures, as those eat up server space and bandwith at a terrifying rate. Nearly 20 years of the D forum consumes 2,800,000 4K blocks, or somewhat over a gigabyte. Not bad. 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.
[Issue 19207] std.algorithm.subsitute wrong results for single subrange substitution
https://issues.dlang.org/show_bug.cgi?id=19207 ajiesk...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||ajiesk...@gmail.com --- Comment #1 from ajiesk...@gmail.com --- Link to his PR: https://github.com/dlang/phobos/pull/6687 --
Re: extern __gshared const(char)* symbol fails
On Friday, 31 August 2018 at 17:50:17 UTC, Steven Schveighoffer
wrote:
What the C compiler is doing is storing it as data, and then
storing the symbol to point at the first element in the data.
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.
NKML also wrote:
You need to declare your extern array as array in D and also in
C, so that the compiler would know what that is (an array, not
a pointer). In many situations C compiler would silently
convert an array into a pointer (when it already knows its
dealing with array), but it won't convert a pointer into an
array.
Thank you Steve and NKML for your very clear and concise answers.
This makes perfect sense.
I would like not to write as a static array in D because I cannot
guarantee future version of the library to which I am linking
would not change the length of the data. Steve's trick, below,
looks like the ticket.
Alternatively, you can treat it as a const char:
extern(C) extern const(char) seq_nt16_str;
void main()
{
import core.stdc.stdio;
printf("%s\n", _nt16_str); // should print the string
}
You could wrap it like this:
pragma(mangle, "seq_nt16_str");
private extern(C) extern const(char) _seq_nt16_str_STORAGE;
@property const(char)* seq_nt16_str()
{
return &_seq_nt16_str_STORAGE;
}
To make the code look similar.
-Steve
That is a great trick, and I will use it.
[Issue 15737] forward reference error in std.format
https://issues.dlang.org/show_bug.cgi?id=15737 ajiesk...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||ajiesk...@gmail.com Resolution|--- |FIXED --- Comment #3 from ajiesk...@gmail.com --- I just tested that with DMD v2.081.2, both of the mentioned examples now compile and run without errors. This issue is thus fixed. --
Re: extern __gshared const(char)* symbol fails
On Friday, 31 August 2018 at 17:18:58 UTC, Neia Neutuladh wrote: On Friday, 31 August 2018 at 06:20:09 UTC, James Blachly wrote: Hi all, ... When linking to this library from D, I have declared it as: extern __gshared const(char)* seq_nt16_str; ***But this segfaults when I treat it like an array (e.g. by accessing members by index).*** I believe this should be extern extern(C)? I'm surprised that this segfaults rather than having a link error. A bare `extern` means "this symbol is defined somewhere else". `extern(C)` means "this symbol should have C linkage". I am so sorry -- I should have been more clear that this is in the context of a large header-to-D translation .d file, so the whole thing is wrapped in extern(C) via an extern(C): at the top of the file.
Copr repository providing dmd and dub for Fedora, EPEL and Mageia
Hello D people! (and especially, for this thread, RPM-based Linux users) As dmd 2.082.0 is coming very soon, I thought I'd share this here. I've been using Fedora for quite a while now, and have made a Copr repository to have some tools I didn't find in official Fedora repositories [1]. It contains a few development related packages, among which dmd, phobos and dub at their latest stable version. The repo is used just like any other Copr repo: sudo dnf copr enable tcg/devel sudo dnf install dmd dub Since Copr also allows building packages for EPEL and Mageia, I'm launching builds for them as well. [1] https://copr.fedorainfracloud.org/coprs/tcg/devel/
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
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 ?
Re: extern __gshared const(char)* symbol fails
On Friday, 31 August 2018 at 06:20:09 UTC, James Blachly wrote:
Hi all,
I am linking to a C library which defines a symbol,
const char seq_nt16_str[] = "=ACMGRSVTWYHKDBN";
In the C sources, this is an array of 16 bytes (17 I guess,
because it is written as a string).
In the C headers, it is listed as extern const char
seq_nt16_str[];
When linking to this library from another C program, I am able
to treat seq_nt16_str as any other array, and being defined as
[] fundamentally it is a pointer.
No. This is a misconception. Fundamentally, it's an array.
When linking to this library from D, I have declared it as:
extern __gshared const(char)* seq_nt16_str;
***But this segfaults when I treat it like an array (e.g. by
accessing members by index).***
Because I know the length, I can instead declare:
extern __gshared const(char)[16] seq_nt16_str;
My question is: Why can I not treat it opaquely and use it
declared as char* ? Does this have anything to do with it being
a global stored in the static data segment?
For the same reason you can't do it in C.
--- main.c ---
#include
extern const char* array; /* then try array[] */
int main(void)
{
printf("%.5s\n", array);
return 0;
}
--- lib.c ---
const char array[] = "hello world";
# gcc -o main main.c lib.c
# ./main
Segmentation fault
You need to declare your extern array as array in D and also in
C, so that the compiler would know what that is (an array, not a
pointer). In many situations C compiler would silently convert an
array into a pointer (when it already knows its dealing with
array), but it won't convert a pointer into an array.
Re: How to use listener.d example?
On Friday, 31 August 2018 at 07:38:54 UTC, Marcin wrote:
https://github.com/dlang/dmd/blob/master/samples/listener.d
Can some one add more comment to that example?
I need to make code that connects to local application, very
similar to this.
Assumptions:
1. Create an application that listens to arguments.
2. Create an application that will send arguments to the
application mentioned above.
3. The application will return the sine (argument) to the
client.
4. All communication must be realized via console.
Another, more structured way to do this is with an RPC framework
like Apache Thrift. With Thrift, you'd write an interface
description:
---
namespace d math.api
service Sine
{
double sine(1: double value);
}
---
In your application, you'd have something like:
---
import vibe.d;
import vibethrift;
import math.api.Sine;
class SineImpl : Sine
{
double sine(double value)
{
static import std.math;
return std.math.sin(value);
}
}
void main()
{
serve!Sine(new SineImpl, "0.0.0.0", );
return runApplication();
}
---
Then you use the corresponding Thrift client to make requests
against it.
You could also do this with Vibe and REST:
---
import vibe.d;
class Sine
{
@path("/sine")
string getSine(double value)
{
static import std.math;
import std.conv : to;
return std.math.sin(value).to!string;
}
}
void main()
{
auto settings = new HTTPServerSettings;
settings.port = ;
auto router = new URLRouter;
router.registerWebInterface(new Sine);
listenHTTP(settings, router);
runApplication();
}
---
And then you can point your browser at
http://localhost:/sine?value=1.5 and get back 0.997495. You
can similarly use std.net.curl to make the request.
But let's say you want to do everything yourself.
That script is the server. Line 55 is the thing that handles the
input. You need to put your code there.
The remote application might send input in multiple packets. That
means you have to collect input somewhere and figure out where
the end is. You can either pass a length as the first part
(usually a 4-byte value in network byte order), or require a
special character to terminate the commend (I recommend the ASCII
Record Separator character, U+001E, or the like), or know enough
about your input to figure out where it ends anyway.
Once you get the end of your input, you send it off somewhere to
parse and process. It's up to you how you want to send numbers
across. When you're done, you need to convert the output numbers
back to bytes somehow and send them back with socket.send(), and
then you close the connection.
Once you've got that working, you need to write a client that
does pretty much the same thing, but Socket.connect instead of
the bind/listen/accept business, and you can just use Socket.read
for the response rather than dealing with a SocketSet.
Re: extern __gshared const(char)* symbol fails
On 8/31/18 2:20 AM, James Blachly wrote:
Hi all,
I am linking to a C library which defines a symbol,
const char seq_nt16_str[] = "=ACMGRSVTWYHKDBN";
In the C sources, this is an array of 16 bytes (17 I guess, because it
is written as a string).
In the C headers, it is listed as extern const char seq_nt16_str[];
When linking to this library from another C program, I am able to treat
seq_nt16_str as any other array, and being defined as [] fundamentally
it is a pointer.
When linking to this library from D, I have declared it as:
extern __gshared const(char)* seq_nt16_str;
***But this segfaults when I treat it like an array (e.g. by accessing
members by index).***
Because I know the length, I can instead declare:
extern __gshared const(char)[16] seq_nt16_str;
My question is: Why can I not treat it opaquely and use it declared as
char* ? Does this have anything to do with it being a global stored in
the static data segment?
What the C compiler is doing is storing it as data, and then storing the
symbol to point at the first element in the data.
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.
Alternatively, you can treat it as a const char:
extern(C) extern const(char) seq_nt16_str;
void main()
{
import core.stdc.stdio;
printf("%s\n", _nt16_str); // should print the string
}
You could wrap it like this:
pragma(mangle, "seq_nt16_str");
private extern(C) extern const(char) _seq_nt16_str_STORAGE;
@property const(char)* seq_nt16_str()
{
return &_seq_nt16_str_STORAGE;
}
To make the code look similar.
-Steve
Re: extern __gshared const(char)* symbol fails
On 8/31/18 1:18 PM, Neia Neutuladh wrote: On Friday, 31 August 2018 at 06:20:09 UTC, James Blachly wrote: Hi all, I am linking to a C library which defines a symbol, const char seq_nt16_str[] = "=ACMGRSVTWYHKDBN"; In the C sources, this is an array of 16 bytes (17 I guess, because it is written as a string). In the C headers, it is listed as extern const char seq_nt16_str[]; When linking to this library from another C program, I am able to treat seq_nt16_str as any other array, and being defined as [] fundamentally it is a pointer. When linking to this library from D, I have declared it as: extern __gshared const(char)* seq_nt16_str; ***But this segfaults when I treat it like an array (e.g. by accessing members by index).*** I believe this should be extern extern(C)? I'm surprised that this segfaults rather than having a link error. Yeah, I had to add extern(C) in my tests to get it to link. I think he must have extern(C): somewhere above. -Steve
Re: Is there any reason to use non-ref foreach?
On Friday, 31 August 2018 at 12:52:17 UTC, bauss wrote: In reality you're micro-optimizing something that doesn't require it. I think you misunderstood. I wasn't trying to optimize, I was looking for a general way to iterate. I can't see the benefit other than added complexity. I just explained it. Iterating by ref works with elements that have postblits disabled, iterating by value doesn't. I was wondering that if iterating by ref is the most general way to iterate, why it isn't the default? Is there some big implication in using it?
Re: extern __gshared const(char)* symbol fails
On Friday, 31 August 2018 at 06:20:09 UTC, James Blachly wrote: Hi all, I am linking to a C library which defines a symbol, const char seq_nt16_str[] = "=ACMGRSVTWYHKDBN"; In the C sources, this is an array of 16 bytes (17 I guess, because it is written as a string). In the C headers, it is listed as extern const char seq_nt16_str[]; When linking to this library from another C program, I am able to treat seq_nt16_str as any other array, and being defined as [] fundamentally it is a pointer. When linking to this library from D, I have declared it as: extern __gshared const(char)* seq_nt16_str; ***But this segfaults when I treat it like an array (e.g. by accessing members by index).*** I believe this should be extern extern(C)? I'm surprised that this segfaults rather than having a link error. A bare `extern` means "this symbol is defined somewhere else". `extern(C)` means "this symbol should have C linkage". When I try it with just `extern`, I see a link error: scratch.o: In function `_Dmain': scratch.d:(.text._Dmain[_Dmain]+0x7): undefined reference to `_D7scratch5cdataPa' collect2: error: ld returned 1 exit status Error: linker exited with status 1
Re: Is there any reason to use non-ref foreach?
On Friday, 31 August 2018 at 12:52:17 UTC, bauss wrote: So basically ... Instead of copying the value, you're just copying the address. I can't see the benefit other than added complexity. I assume a benefit could be observed if you are copying a large struct instead of an int.
Re: D is dead
On Friday, 31 August 2018 at 08:36:27 UTC, Nick Treleaven wrote: I hadn't understood the rationale for lazy variadic functions https://dlang.org/spec/function.html#lazy_variadic_functions I don't know if this has been updated too but this sentence makes no sense : "Then each of the arguments whose type does not match that of the delegate is converted to a delegate."
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Fri, Aug 31, 2018 at 03:13:30PM +, Chris via Digitalmars-d wrote: > On Friday, 31 August 2018 at 14:38:36 UTC, H. S. Teoh wrote: > > On Fri, Aug 31, 2018 at 09:37:55AM +, Chris via Digitalmars-d wrote: > > [...] > > > 3. moving the goal posts all the time and forcing you into a new > > > paradigm every 1 1/2 years (first it was "ranges", then > > > "templates" and now it's "functional", wait OOP will come back one > > > day). > > [...] > > > > Wait, what? Since when has this ever been a "choose one paradigm > > among many" deal? Templates are what enables range-based idioms to > > succeed, and ranges are what makes it possible to write > > functional-like code in D. Since when have they become mutually > > exclusive?! [...] > 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 -- IBM = I'll Buy Microsoft!
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 31 August 2018 at 14:38:36 UTC, H. S. Teoh wrote: On Fri, Aug 31, 2018 at 09:37:55AM +, Chris via Digitalmars-d wrote: [...] 3. moving the goal posts all the time and forcing you into a new paradigm every 1 1/2 years (first it was "ranges", then "templates" and now it's "functional", wait OOP will come back one day). [...] Wait, what? Since when has this ever been a "choose one paradigm among many" deal? Templates are what enables range-based idioms to succeed, and ranges are what makes it possible to write functional-like code in D. Since when have they become mutually exclusive?! T 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".
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Fri, Aug 31, 2018 at 09:37:55AM +, Chris via Digitalmars-d wrote: [...] > 3. moving the goal posts all the time and forcing you into a new > paradigm every 1 1/2 years (first it was "ranges", then "templates" > and now it's "functional", wait OOP will come back one day). [...] Wait, what? Since when has this ever been a "choose one paradigm among many" deal? Templates are what enables range-based idioms to succeed, and ranges are what makes it possible to write functional-like code in D. Since when have they become mutually exclusive?! T -- Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel
Re: How to use math functions in dcompute?
On Thursday, 30 August 2018 at 10:34:33 UTC, Sobaya wrote: On Monday, 27 August 2018 at 12:47:45 UTC, Nicholas Wilson wrote: On Monday, 27 August 2018 at 09:57:18 UTC, Sobaya wrote: On Monday, 27 August 2018 at 09:41:34 UTC, 9il wrote: On Monday, 27 August 2018 at 08:25:14 UTC, Sobaya wrote: I'm using dcompute(https://github.com/libmir/dcompute). In the development, I have got to use math functions such as sqrt in @compute function. But LDC says "can only call functions from other @compute modules in @compute code", so can't I call any math functions with dcompute? Is there any way to use predefined math functions in dcompute? Thanks. You may want to try ldc.intrinsics / mir.math.common Do you mean llvm_sqrt in ldc.intrinsics? These functions are also not @compute code, so they cause the same error. Thanks for bringing this to my attention, will fix soon. In the meantime you may declare your own intrinsics in a @compute module and it should work. as in @compute module mymath; pragma(LDC_intrinsic, "llvm.sqrt.f#") T llvm_sqrt(T)(T val) if (__traits(isFloating, T)); This will work if you are targeting CUDA, SPIRV may not like it because the backend is less... mature. Thank you for replaying. Surely the definition you told me works for "sqrt". But "cos" and "sin" does not work. The error message is LLVM ERROR: Cannot select: 0xd76ffd8: f32 = fcos ConstantFP:f32<0.00e+00> 0xd76ff70: f32 = ConstantFP<0.00e+00> What's wrong? SPIR-V or CUDA? for SPIR-V try pragma(mangle, "_Z3sinf") float sin(float); pragma(mangle, "_Z3cosf") float cos(float); more generally see https://github.com/KhronosGroup/SPIR-Tools/wiki/SPIR-2.0-built-in-functions If this is a problem with CUDA you could try using the NVPTX intrinsics pragma(LDC_intrinsic, "llvm.nvvm.namegoeshere") T namegoeshere(Args a); If you need to use both SPIR-V and CUDA then see the hackery e.g. https://github.com/libmir/dcompute/blob/master/source/dcompute/std/index.d#L45 LLVM will be released on September 5th I will fix up this shortly after. Sorry for the alpha state of things right now. Nic
Re: Is there any reason to use non-ref foreach?
On Friday, 31 August 2018 at 09:59:20 UTC, Dukc wrote:
For me, it seems that for generality you should always add ref
into foreach loop variable. The reason is this:
import std.experimental.all;
struct NoCopies
{ @disable this(this);
int payload;
}
void main()
{ auto range = new NoCopies[20];
foreach(const ref el; range) el.payload.writeln;
}
Without ref qualifier in el, this won't work because it would
make a copy. Unlike ref as a function argument, it does not
enforce refness:
import std.experimental.all;
void main()
{ auto range = iota(20).map!(x => x + 2);
foreach(const ref el; range) el.writeln;
}
This compiles, even though range elements are rvalues.
This seems to imply, for me, that for generality one should
always use ref in foreach loop variables. If the vairable has
to be guarded against changes, it should const ref, not
unqualified.
But considering unqualified is the default, I am probably
missing something here. Performance?
It makes sense in your simplified examples, but in practice it
doesn't, because it will depend on each situation, what type of
data you're enumerating etc.
And I bet you there are some gotchas using just ref.
In reality you're micro-optimizing something that doesn't require
it.
Remember that basically the difference is this.
foreach (i; values) {
...
}
for (int _ = 0; _ < values; _++)
{
auto i = values[_];
...
}
VS
foreach (ref i; values) {
...
}
for (int _ = 0; _ < values; _++)
{
auto i = [_];
...
}
So basically ... Instead of copying the value, you're just
copying the address.
I can't see the benefit other than added complexity.
Re: Can't print enum values
On Friday, 31 August 2018 at 12:21:48 UTC, aliak wrote:
auto ToUnderlyingType(alias a)() {
return cast(OriginalType!(typeof(a)))a;
}
void print(T...)(T args) {
writeln(staticMap!(ToUnderlyingType, args));
}
Oohhh. So easy! Killed 2 days - and templates and mixins tried...
And the solution was to use TEMPLATE function with alias not
regular...
Thank you!
[Issue 19202] deprecated eponymous template prints no warning
https://issues.dlang.org/show_bug.cgi?id=19202 Mike Franklin changed: What|Removed |Added Keywords||pull --
[Issue 19202] deprecated eponymous template prints no warning
https://issues.dlang.org/show_bug.cgi?id=19202 --- Comment #2 from Mike Franklin --- Attempted fix: https://github.com/dlang/dmd/pull/8645 --
Re: Can't print enum values
On Friday, 31 August 2018 at 10:51:51 UTC, Andrey wrote:
On Thursday, 30 August 2018 at 12:04:26 UTC, vit wrote:
On Thursday, 30 August 2018 at 11:34:36 UTC, Andrey wrote:
On Thursday, 30 August 2018 at 11:09:40 UTC, vit wrote:
[...]
I want to create a reusable template for this purpose.
Why I can't use "staticMap" so that compiler it self would do
this:
[...]
Just wrap some some symbol "args" with some expression at
compile time.
It is the same as in C++:
[...]
D doesn't have expanding like C++
Unfortunately D has only simple automatic expading.
So how can one implement a reusable template "apply some
function to each argument in template parameter pack" in D?
auto ToUnderlyingType(alias a)() {
return cast(OriginalType!(typeof(a)))a;
}
void print(T...)(T args) {
writeln(staticMap!(ToUnderlyingType, args));
}
[Issue 19202] deprecated eponymous template prints no warning
https://issues.dlang.org/show_bug.cgi?id=19202 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com --- Comment #1 from Mike Franklin --- According to digger, this regression was introduced by https://github.com/dlang/dmd/pull/5135 --
Re: Engine of forum
On Friday, 31 August 2018 at 10:37:05 UTC, rikki cattermole wrote: On 31/08/2018 10:16 PM, Andrey wrote: Any self-respecting website related to programming or developing something, has in its composition a place where people can comfortably and freely discuss pressing issues. Not some weird news group. Feel free to argue this for projects like the Linux kernel. If you succeed it is safe to say we will too. Some subsystems of the Linux kernel like DRM are migrating their development to GitLab. They'll still be using mailing lists as the primary communication channel, but perhaps using GitLab merge requests and issues is not far off either. Sometimes when the right incentives like easier infrastructure management and developer productivity are in place unthinkable things like that do happen. Only time will tell ;) https://about.gitlab.com/2018/08/20/freedesktop-org-migrates-to-gitlab/
Re: Can't print enum values
On Thursday, 30 August 2018 at 12:04:26 UTC, vit wrote: On Thursday, 30 August 2018 at 11:34:36 UTC, Andrey wrote: On Thursday, 30 August 2018 at 11:09:40 UTC, vit wrote: [...] I want to create a reusable template for this purpose. Why I can't use "staticMap" so that compiler it self would do this: [...] Just wrap some some symbol "args" with some expression at compile time. It is the same as in C++: [...] D doesn't have expanding like C++ Unfortunately D has only simple automatic expading. So how can one implement a reusable template "apply some function to each argument in template parameter pack" in D?
Re: Solving the impossible?
On Thursday, 30 August 2018 at 21:40:40 UTC, Everlast wrote: On Thursday, 30 August 2018 at 00:10:42 UTC, Paul Backus wrote: [...] This is not true! You claim that I'm making a blanket statement about what mathematicians would view then you do the same. [...] If ... implies "an arbitrary number of" and you have: (A...)(A a) (A)(A a...) A... = an arbitrary number of types A a... = an arbitrary number of parameters *typed* as A. When you have a list of Ts the type is denoted as "T[]". This is consistent with D's type system.
Re: Engine of forum
On 31/08/2018 10:16 PM, Andrey wrote: Any self-respecting website related to programming or developing something, has in its composition a place where people can comfortably and freely discuss pressing issues. Not some weird news group. Feel free to argue this for projects like the Linux kernel. If you succeed it is safe to say we will too.
Re: Engine of forum
On Friday, 24 August 2018 at 01:43:54 UTC, Walter Bright wrote: On 8/21/2018 2:41 PM, tide wrote: What about if you accidentially press a button that posts the comment? That's really up to your NNTP client's design, which we didn't implement. There are lots of NNTP clients to choose from. Why can't syntax formatting be implemented, does anyone disagree that is a useless feature? It's a useless feature. Formatting is needed for longer form text, which is not really appropriate for the forum. Forum posts should be short and to the point - posting an article or manifesto should be posted separately, with a link to it in the forum. Also, there is no need to post pictures, emoji, banners, or other cruft one sees in other forums. Especially pictures, as those eat up server space and bandwith at a terrifying rate. Nearly 20 years of the D forum consumes 2,800,000 4K blocks, or somewhat over a gigabyte. Not bad. 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. And should be written so that it is convenient to read - with formatting, highlighting, indentation... It is very strange to hear from programmer that "syntax formatting" is useless feature. Possibility to vote for message, append "thank you" and mark some message as an answer it also increases readability. Any self-respecting website related to programming or developing something, has in its composition a place where people can comfortably and freely discuss pressing issues. Not some weird news group.
Is there any reason to use non-ref foreach?
For me, it seems that for generality you should always add ref
into foreach loop variable. The reason is this:
import std.experimental.all;
struct NoCopies
{ @disable this(this);
int payload;
}
void main()
{ auto range = new NoCopies[20];
foreach(const ref el; range) el.payload.writeln;
}
Without ref qualifier in el, this won't work because it would
make a copy. Unlike ref as a function argument, it does not
enforce refness:
import std.experimental.all;
void main()
{ auto range = iota(20).map!(x => x + 2);
foreach(const ref el; range) el.writeln;
}
This compiles, even though range elements are rvalues.
This seems to imply, for me, that for generality one should
always use ref in foreach loop variables. If the vairable has to
be guarded against changes, it should const ref, not unqualified.
But considering unqualified is the default, I am probably missing
something here. Performance?
Re: [OT] Leverage Points
On Thursday, 30 August 2018 at 11:45:00 UTC, Joakim wrote: (Quoting from the article I think). Kuhn and Lakatos. Paradigm shifts don't take place when the dominant paradigm is defeated by logical or empirical means. Paradigm shifts take place when for some reason people say "how about we stop talking about that, and start talking about this instead". Not sure why you'd call that anything other than defeat. :) FWIW, it's the point of Lakatos's work: he argues that a paradigm can't be defeated by logical or empirical means. It takes zero effort to not do anything, so status quo is easily maintained.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
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: Julia is great. I don't see it as a competitor to D but for us one way researchers might access libraries written in D. One could do quite a lot in it, but I don't much fancy embedding Julia in Excel for example, though you could. Or doing DevOps in Julia. Perhaps more of a Matlab substitute. Look around and you can find people grumpy about any language that's used. http://www.zverovich.net/2016/05/13/giving-up-on-julia.html Languages really aren't in a battle to the death with each other. I find this zero-sum mindset quite peculiar. I'm old enough to a) not become enthusiastic about a language and b) know that you can find fault with any language. It's not about "life or death". D was promising and I liked it and it did things for me no other language could do for me - back in the day. Nowadays many languages have similar features, especially the useful ones that have proven to be, well, useful and not the latest fad. But D has some major issues that have become clear to me after using it for quite a while: 1. unsolved issues like autodecode that nobody seems to care about 2. obvious facepalm moments all over the place (see 1.) 3. moving the goal posts all the time and forcing you into a new paradigm every 1 1/2 years (first it was "ranges", then "templates" and now it's "functional", wait OOP will come back one day). Yeah, a language that doesn't come with a paradigm or ideology, no, a language that only nudges you into a certain direction and makes your code look old and just s "not modern" according to the latest CS fashion of the day. "Why do you complain? If you think C++ (as the D leadership did for a long time), of course your code will break, you knob! If it breaks it's for your own good (for now)." 4. nitpicking over details of half baked features that shouldn't be there in the first place, but hey! let's break valid existing code to fix them - or not - or, what about @volatileSafeUB (it's sooo not C++)? Yeah, sounds great. We'll just have to issue a compiler message "error: cannot assign `size_t` to `size_t`" 5. complete and utter negligence of developer reality (ARM, Android, iOS, tools etc.). It's all left to spare time enthusiasts - and their code will break in 4 weeks too. Just you wait and see 6. the leadership doesn't address the issues and gives evasive answers as in "Programmers who..." or on hindsight you're always wiser, other engineers have made mistakes too 7. I've seen it all before, many times, and it's a sign of a sinking ship, rearranging the deck chairs on the Titanic 8. what a pity 9. I hope D will be great again
[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing
https://issues.dlang.org/show_bug.cgi?id=17934
Mike Franklin changed:
What|Removed |Added
CC||slavo5...@yahoo.com
--- Comment #7 from Mike Franklin ---
(In reply to Martin Nowak from comment #0)
> /**
> There seems to be now way to write this functions so
> that the compiler infers the return value as scope.
> */
> List list() @trusted
> {
> return List(malloc(1));
> }
>
> void test() @safe
> {
> Elem elem;
> {
> //scope l = list(); // works with explicit scope
> auto l = list(); // not inferred as scope
> elem = l.front; // escapes, b/c l isn't scoped
> }
> }
Why does `scope` need to be inferred? What's wrong with the user being
required to attribute `scope` to the declaration.
What about having `scope` apply to return values of functions, so `list()`
could be written as `scope List list() @trusted`?
--
Re: D is dead
On Thursday, 23 August 2018 at 09:09:40 UTC, Shachar Shemesh wrote: Please see the thread about lazy [1] for a case where a question actually has an answer, but nobody seems to know it I updated the spec for lazy parameters to add a link to lazy variadic functions at the end, and for the latter I added a simpler version of Steven Schveighoffer's examples of both. So at least in future someone with a similar problem might find out that lazy variadics is another option. https://dlang.org/spec/function.html#lazy-params https://dlang.org/spec/function.html#lazy_variadic_functions I hadn't understood the rationale for lazy variadic functions just from reading the spec. If I learn something that should be mentioned in the spec, I try to make a pull. Failing that, we can file bugzilla issues for missing documentation, even if it's only an enhancement for clarification.
[Issue 19097] Extend Return Scope Semantics
https://issues.dlang.org/show_bug.cgi?id=19097 --- Comment #10 from Mike Franklin --- Some comments from the forum worth visiting with regard to this proposal: https://forum.dlang.org/post/plja2k$28r0$1...@digitalmars.com https://forum.dlang.org/post/pljpnr$7g9$1...@digitalmars.com --
[Issue 19210] Poor error message for `return` function parameter that is not `ref`
https://issues.dlang.org/show_bug.cgi?id=19210 Mike Franklin changed: What|Removed |Added Keywords||safe Severity|enhancement |normal --
[Issue 19210] New: Poor error message for `return` function parameter that is not `ref`
https://issues.dlang.org/show_bug.cgi?id=19210
Issue ID: 19210
Summary: Poor error message for `return` function parameter
that is not `ref`
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: slavo5...@yahoo.com
@safe:
ref int identity(return ref int x)
{
return x;
}
ref int fun(return int x)
{
return identity(x); //Error: returning identity(x) escapes a reference to
parameter x, perhaps annotate with return
}
void main()
{
int i;
int j = fun(i);
}
$ dmd -dip25 main.d
https://run.dlang.io/is/lvvRUR
The problem is that `x`, in function `fun` is already annotated with `return`,
so the error message doesn't make sense. I believe there should be an error
message emitted disallowing `return` on parameters that are not `ref` or `out`,
but I'm not sure
--
How to use listener.d example?
https://github.com/dlang/dmd/blob/master/samples/listener.d Can some one add more comment to that example? I need to make code that connects to local application, very similar to this. Assumptions: 1. Create an application that listens to arguments. 2. Create an application that will send arguments to the application mentioned above. 3. The application will return the sine (argument) to the client. 4. All communication must be realized via console. input: 1 1,2,3 4 5 44 Output: "a =" 1 "sin (a) =" 0.84147 "a =" 1 "sin (a) =" 0.84147 "a =" 2 "sin (a) =" 0.9092 "a =" 3 "sin (a) =" 0.14112 "a =" 4 "sin (a) =" -0.756 "a =" 5 "sin (a) =" 0.9589 "a =" 44 "sin (a) =" 0.0177 Can some one help me write a server and client app? I will use it to create more complicated application.
extern __gshared const(char)* symbol fails
Hi all, I am linking to a C library which defines a symbol, const char seq_nt16_str[] = "=ACMGRSVTWYHKDBN"; In the C sources, this is an array of 16 bytes (17 I guess, because it is written as a string). In the C headers, it is listed as extern const char seq_nt16_str[]; When linking to this library from another C program, I am able to treat seq_nt16_str as any other array, and being defined as [] fundamentally it is a pointer. When linking to this library from D, I have declared it as: extern __gshared const(char)* seq_nt16_str; ***But this segfaults when I treat it like an array (e.g. by accessing members by index).*** Because I know the length, I can instead declare: extern __gshared const(char)[16] seq_nt16_str; My question is: Why can I not treat it opaquely and use it declared as char* ? Does this have anything to do with it being a global stored in the static data segment?
