Re: This thread on Hacker News terrifies me
On 09/03/2018 12:46 AM, H. S. Teoh wrote: On Sun, Sep 02, 2018 at 09:33:36PM -0700, H. S. Teoh wrote: [...] The reason I picked memory corruption is because it's a good illustration of how badly things can go wrong when code that is known to have programming bugs continue running unchecked. [...] P.S. And memory corruption is also a good illustration of how a logic error in one part of the program can cause another completely unrelated part of the program to malfunction. The corruption could have happened in your network stack, but it overwrites memory used by your GPU code. You cannot simply assume that just because the network module has nothing to do with the GPU module, that a GPU code assertion failure cannot be caused by a memory corruption in the network module. Therefore, you also cannot assume that an assertion in the GPU code can be safely ignored, because by definition, the program's logic is flawed, and so any assumptions you may have made about it may no longer be true, and blindly continuing to run the code means the possibility of actually executing a remote exploit instead of the GPU code you thought you were about to execute. Isn't that assuming the parts aren't @safe? ;) Anything less is unsafe, because being in an invalid state means you cannot predict what the program will do when you try to recover it. Your state graph may look nothing like what you thought it should look like, so an action that you thought would bring the program into a known state may in fact bring it into a different, unknown state, which can exhibit any arbitrary behaviour. You mean attempting to doing things, like say, generate a stack trace or format/display the name of the Error class and a diagnostic message? ;) Not to say it's all-or-nothing of course, but suppose it IS memory corruption and trying to continue WILL cause some bigger problem like arbitrary code execution. In that case, won't the standard Error class stuff still just trigger that bigger problem, anyway?
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sunday, 2 September 2018 at 14:48:34 UTC, lurker wrote: after the beta i tried it the final again - just to be fair. 1.) install d, install visual d. 2.) trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.) VS2017 - displays a problem on startup 4.) creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? i guess you don't intend to draw crowds to D and just keep talking on how to this and that a little better in the compiler pet project. is D that dead that the releases are not tested or do you want to keep all windows users out? Oh and also your error is probably that you're missing the C++ build tools which come with the correct linker for x64, as far as I remember.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sunday, 2 September 2018 at 14:48:34 UTC, lurker wrote: after the beta i tried it the final again - just to be fair. 1.) install d, install visual d. 2.) trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.) VS2017 - displays a problem on startup 4.) creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? i guess you don't intend to draw crowds to D and just keep talking on how to this and that a little better in the compiler pet project. is D that dead that the releases are not tested or do you want to keep all windows users out? Visual D is not official, remember that. Most people would go with VS Code anyway.
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 01:05:10 UTC, Martin Nowak wrote: http://dlang.org/changelog/2.082.0.html -Martin gdb exception catching looks pretty useful to me!
Re: expectations 0.1.0
On 09/02/2018 11:23 PM, Paul Backus wrote: This is a really clever technique. As you said, hard to say whether it's worth it compared to just throwing an exception normally, but still, really clever. IMO, it's worth it. First of all, it decreases the asymmetry between `Expected!void` and other `Expected!T`. But more than that, there's one of the core benefits of of expected: What's awesome about expected is that by providing only one function, the caller can decide whether they want a `foo()` that throws, or a `tryFoo()` that lets them manually handle the case where it doesn't work (and is potentially nothrow). Note that the above has *nothing* to do with retrieving a value. Retrieving a value is merely used by the implementation as a trigger to lazily decide whether the caller wants `foo` or `tryFoo`. Going out of scope without making the choice could also be considered another trigger point. In fact, this "out-of-scope without being checked" could even be used as an additional trigger for even the non-void variety. After all: what if an error occurs, but the caller checks *neither* value nor hasValue? There's only one possible downside I see: What if the caller *intentionally* wants to ignore the error condition? Yes, that's generally bad practice, and signifies maybe it shouldn't be an exception in the first place. But consider Scriptlike: It has functions like `tryMkdir` and `tryRmdir` with the deliberate purpose letting people say "Unlike Phobos's mkdir/rmdir, I don't care whether the directory already exists or not, just MAKE SURE it exists (or doesn't) and don't bother me with the details!" I suppose for cases like those, it's perfectly worth leaving it up to expectation's user to design, create and document a "Don't worry about the failure" variant, should they so choose. Probably safer that way, anyway.
Re: This thread on Hacker News terrifies me
On Sun, Sep 02, 2018 at 09:33:36PM -0700, H. S. Teoh wrote: [...] > The reason I picked memory corruption is because it's a good > illustration of how badly things can go wrong when code that is known to > have programming bugs continue running unchecked. [...] P.S. And memory corruption is also a good illustration of how a logic error in one part of the program can cause another completely unrelated part of the program to malfunction. The corruption could have happened in your network stack, but it overwrites memory used by your GPU code. You cannot simply assume that just because the network module has nothing to do with the GPU module, that a GPU code assertion failure cannot be caused by a memory corruption in the network module. Therefore, you also cannot assume that an assertion in the GPU code can be safely ignored, because by definition, the program's logic is flawed, and so any assumptions you may have made about it may no longer be true, and blindly continuing to run the code means the possibility of actually executing a remote exploit instead of the GPU code you thought you were about to execute. When the program logic is known to be flawed, by definition the program is in an invalid state with unknown (and unknowable -- because it implies that your assumptions were false) consequences. The only safe recourse is to terminate the program to get out of that state and restart from a known safe state. Anything less is unsafe, because being in an invalid state means you cannot predict what the program will do when you try to recover it. Your state graph may look nothing like what you thought it should look like, so an action that you thought would bring the program into a known state may in fact bring it into a different, unknown state, which can exhibit any arbitrary behaviour. (This is why certain security holes are known as "arbitrary code execution": the attacker exploits a loophole in the program's state graph to do something the programmer never thought the program could do -- because the programmer's assumptions turned out to be wrong.) T -- This sentence is false.
Re: Static foreach bug?
On Sunday, 2 September 2018 at 20:01:08 UTC, Neia Neutuladh wrote: On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote: Woud be so much more maintainable if I could have each statement into a variable that could be maintained properly. You could extract the body of the static foreach into a [template] function. I'm aware of that, but it's an unnecessary work around for something as trivial as the alternative would have been.
Re: This thread on Hacker News terrifies me
On Mon, Sep 03, 2018 at 03:21:00AM +, tide via Digitalmars-d wrote: [...] > Any graphic problems are going to stem probably more from shaders and > interaction with the GPU than any sort of logic code. [...] > What he was talking about was basically that, he was saying how it > could be used to identify possible memory corruption, which is > completely absurd. That's just stretching it's use case so thin. You misquote me. I never said asserts could be used to *identify* memory corruption -- that's preposterous. What I'm saying is that when an assert failed, it *may* be caused by a memory corruption (among many other possibilities), and that is one of the reasons why it's a bad idea to keep going in spite of the assertion failure. The reason I picked memory corruption is because it's a good illustration of how badly things can go wrong when code that is known to have programming bugs continue running unchecked. When an assertion fails it basically means the program has a logic error, and what the programmer assumed the program will do is wrong. Therefore, by definition, you cannot predict what the program will actually do -- and remote exploits via memory corruption is a good example of how your program can end up doing something completely different from what it was designed to do when you keep going in spite of logic errors. Obviously, assertions aren't going to catch *all* memory corruptions, but given that an assertion failure *might* be caused by a memory corruption, why would anyone in their sane mind want to allow the program to keep going? We cannot catch *all* logic errors by assertions, but why would anyone want to deliberately ignore the logic errors that we *can* catch? T -- If creativity is stifled by rigid discipline, then it is not true creativity.
Re: Load entire file, as a char array.
On Monday, 3 September 2018 at 03:19:39 UTC, Neia Neutuladh wrote:
On Monday, 3 September 2018 at 03:04:57 UTC, Chris Katko wrote:
This should be simple? All I want to do is load an entire
file, and access individual bytes. The entire thing. I don't
want to have know the file size before hand, or "guess" and
have a "maximum size" buffer.
So far, all google searches for "dlang binary file read" end
up not working for me.
Thank you.
http://dpldocs.info/experimental-docs/std.file.read.1.html
import std.file : read;
auto bytes = read("filename");
This gives you a void[], which you can cast to ubyte[] or
char[] or whatever you need.
That works great! I thought all file i/o had to through the File
class.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sun, 2 Sep 2018 at 16:05, Andre Pany via Digitalmars-d wrote: > > On Sunday, 2 September 2018 at 14:48:34 UTC, lurker wrote: > > after the beta i tried it the final again - just to be fair. > > > > 1.) install d, install visual d. > > 2.) trying to to look at options under visual d without a > > project crashes VS2017 - latest > > service pack. > > 3.) VS2017 - displays a problem on startup > > 4.) creating the dummy project - compile for x64. error > > something is missing. > > 5.) deinstall everything and wait for another year > > > > this crap does not even work out of the box - what else is not > > tested in D? > > > > i guess you don't intend to draw crowds to D and just keep > > talking on how to this and that a little better in the compiler > > pet project. > > > > is D that dead that the releases are not tested or do you want > > to keep all windows users out? > > There are a lot of motivated people here willing to help you to > get your issue solved if you provide the details. > > I can confirm that DMD is working like a charm for me (different > visual studio versions on build servers, MS build tools on local > pc). I use IntelliJ instead of Visual Studio, but that is only my > personal preferation. > > Kind regards > Andre I'm currently installing VS2017 to test your anecdote (been on 2015 for ages)... although I use VS2017 at work and haven't had any problems.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 13:21:27 UTC, Jonathan M Davis wrote: 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 Any graphic problems are going to stem probably more from shaders and interaction with the GPU than any sort of logic code. Not that you can really use asserts to ensure you are making calls to something like Vulkan correctly. There are validation layers for that, which are more helpful than assert would ever be. They still have a cost, as an example my engine runs at 60+ FPS on my crappy phone without the validation layers. But with them enabled I get roughly less than half that 10-15 fps, depending on where I'm looking. So using them in production code isn't exactly possible. What he was talking about was basically that, he was saying how it could be used to identify possible memory corruption, which is completely absurd. That's just stretching it's use case so thin.
Re: expectations 0.1.0
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev
wrote:
Please correct me if I'm wrong, but from looking at the code,
given e.g.:
Expected!void copyFile(string from, string to);
nothing prevents me from writing:
void main() { copyFile("nonexistent", "target"); }
The success value is silently discarded, so we end up with a
"ON ERROR RESUME NEXT" situation again, like badly written C
code.
This is definitely a big weakness of `Expected!void`, and one I
hadn't considered when writing the code. With a normal
`Expected!T`, the fact that you care about the return value is
what forces you to check for the error, but that doesn't apply
when the return value is `void`.
I'm not sure at this point if it's better to leave
`Expected!void` in for the sake of completeness, or remove it so
that nobody's tempted to shoot themself in the foot. Definitely
something to think about.
One way we could improve on this in theory is to let functions
return a successfulness value, which is converted into a thrown
exception IFF the function failed AND the caller didn't check
if an error occurred.
Draft implementation:
struct Success(E : Exception)
{
private E _exception;
private bool checked = false;
@property E exception() { checked = true; return _exception; }
@property ok() { return exception is null; }
@disable this(this);
~this() { if (_exception && !checked) throw _exception; }
}
This is a really clever technique. As you said, hard to say
whether it's worth it compared to just throwing an exception
normally, but still, really clever.
Re: Load entire file, as a char array.
On Monday, 3 September 2018 at 03:04:57 UTC, Chris Katko wrote:
This should be simple? All I want to do is load an entire file,
and access individual bytes. The entire thing. I don't want to
have know the file size before hand, or "guess" and have a
"maximum size" buffer.
So far, all google searches for "dlang binary file read" end up
not working for me.
Thank you.
http://dpldocs.info/experimental-docs/std.file.read.1.html
import std.file : read;
auto bytes = read("filename");
This gives you a void[], which you can cast to ubyte[] or char[]
or whatever you need.
Load entire file, as a char array.
This should be simple? All I want to do is load an entire file, and access individual bytes. The entire thing. I don't want to have know the file size before hand, or "guess" and have a "maximum size" buffer. So far, all google searches for "dlang binary file read" end up not working for me. Thank you.
Re: This thread on Hacker News terrifies me
On 09/02/2018 09:20 PM, Walter Bright wrote: On 9/1/2018 8:18 PM, Nick Sabalausky (Abscissa) wrote: [...] My take on all this is people spend 5 minutes thinking about it and are confident they know it all. Wouldn't it be nice if we COULD do that? :) A few years back some hacker claimed they'd gotten into the Boeing flight control computers via the passenger entertainment system. I don't know the disposition of this case, but if true, such coupling of systems is a gigantic no-no. Some engineers would have some serious 'splainin to do. Wonder if it could've just been a honeypot. (Or just someone who was full-of-it.) Although, I'm not sure how much point there would be to a honeypot if the systems really were electronically isolated.
Re: This thread on Hacker News terrifies me
On 09/02/2018 07:17 PM, Gambler wrote: But in general, I believe the statement about comparative reliability of tech from 1970s is true. I'm perpetually impressed with is all the mainframe software that often runs mission-critical operations in places you would least expect. I suspect it may be because, up until around the 90's, in order to get any code successfully running on the computer at all, you pretty much had to know at least a thing or two about how a computer works and how to use it. And performance/efficiency issues were REALLY obvious. Not to mention the institutional barriers to entry: Everyone didn't just have a computer in their pocket, or even in their den at home. (Plus the machines themselves tended to be simpler: It's easier to write good code when a single programmer can fully understand every byte of the machine and their code is all that's running.) In the 50's/60's in particular, I imagine a much larger percentage of programmers probably had either some formal engineering background or something equally strong. But now, pretty much anyone can (and often will) cobble together something that more-or-less runs. Ie, there used to be a stronger barrier to entry, and the machines/tools tended to be less tolerant of problems.
Re: This thread on Hacker News terrifies me
On 9/1/2018 8:18 PM, Nick Sabalausky (Abscissa) wrote: [...] My take on all this is people spend 5 minutes thinking about it and are confident they know it all. A few years back some hacker claimed they'd gotten into the Boeing flight control computers via the passenger entertainment system. I don't know the disposition of this case, but if true, such coupling of systems is a gigantic no-no. Some engineers would have some serious 'splainin to do.
Re: expectations 0.1.0
On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote:
expectations is an error-handling library that lets you bundle
exceptions together with return values. It is based on Rust's
Result [1] and C++'s proposed std::expected. [2] If
you're not familiar with those, Andrei's NDC Oslo talk, "Expect
the Expected" [3], explains the advantages of this approach to
error handling in considerable detail.
Sorry, I didn't watch the talk, but this sounds like something
that's been on my mind for a while.
There are generally two classic approaches to error handling:
- Error codes. Plus: no overhead. Minus: you need to remember to
check them. Some languages force you to check them, but it
results in very noisy code in some cases (e.g.
https://stackoverflow.com/a/3539342/21501).
- Exceptions. Plus: simple to use. Minus: unnecessary (and
sometimes considerable) overhead when failure is not exceptional.
Now, Rust's Result works because it forces you to check the error
code, and provides some syntax sugar to pass the result up the
stack or abort if an error occurred. D, however, has nothing to
force checking the return value of a function (except for pure
functions, which is inapplicable for things like I/O).
Please correct me if I'm wrong, but from looking at the code,
given e.g.:
Expected!void copyFile(string from, string to);
nothing prevents me from writing:
void main() { copyFile("nonexistent", "target"); }
The success value is silently discarded, so we end up with a "ON
ERROR RESUME NEXT" situation again, like badly written C code.
One way we could improve on this in theory is to let functions
return a successfulness value, which is converted into a thrown
exception IFF the function failed AND the caller didn't check if
an error occurred.
Draft implementation:
struct Success(E : Exception)
{
private E _exception;
private bool checked = false;
@property E exception() { checked = true; return _exception; }
@property ok() { return exception is null; }
@disable this(this);
~this() { if (_exception && !checked) throw _exception; }
}
Success!E failure(E)(E e) { return Success!E(e); }
Success!Exception copyFile(string from, string to)
{
// dummy
if (from == "nonexistent")
return failure(new Exception("EEXIST"));
else
return typeof(return)();
}
void main()
{
import std.exception;
copyFile("existent", "target");
assert(!copyFile("nonexistent", "target").ok);
assertThrown!Exception({ copyFile("nonexistent", "target"); }());
}
This combines some of the advantages of the two approaches above.
In the above draft I used a real exception object for the
payload, constructing which still has a significant overhead (at
least over an error code), though we do get rid of a try/catch if
an error is not an exceptional situation. The advantage of using
a real exception object is that its stack trace is generated when
the exception is instantiated, and not when it's thrown, which
means that the error location inside the copyFile implementation
is recorded; but the same general idea would work with a
numerical error code payload too.
Any thoughts?
Re: expectations 0.1.0
On Sunday, 2 September 2018 at 23:38:41 UTC, Per Nordlöw wrote: On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote: expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expected. [2] If you're not familiar with those, Andrei's NDC Oslo talk, "Expect the Expected" [3], explains the advantages of this approach to error handling in considerable detail. Incidentally, I've already proposed `Expected` into Phobos std.experimental.typecons here https://github.com/dlang/phobos/pull/6686 Is it ok if I try to merge your effort into this pull request? I don't think expectations has reached a high enough level of quality yet to be ready for inclusion in Phobos. However, if you'd like to submit it for comments as a WIP, or use it as a reference for your own implementation, that's completely fine, and I'd be happy to help you.
Re: Example of using C API from D?
On 03/09/2018 5:07 AM, Russel Winder wrote: On Mon, 2018-09-03 at 01:00 +1200, rikki cattermole via Digitalmars-d- learn wrote: […] You don't need to create a complete binding for something to use a subset of it. True, but all too often you find there are so many interdependencies of names, you end up binding most of the API. I tried fiddling with Fontconfig using Python which has no binding and was able to hack up just enough using CFFI to get things working. So I think in this case a subset for the application is feasible – as opposed to creating a complete binding. You won't need to actually fill out any c struct's that you don't need either. Make them opaque as long as they are referenced via pointer and not by value. Writing up a Derelict style binding is easy enough since e.g. SharedLib struct handles most of the work (from util package). https://github.com/DerelictOrg/DerelictUtil/blob/master/source/derelict/util/sharedlib.d#L118 I am not convinced this is a good approach since you do not get the signatures at compile time. The advantage of a binding, or subset of a binding is that you get full compiler support. Ugh, you do know that the linker which does all the hard work doesn't know anything about the signature of the C function? That is the part SharedLib replaces. You will of course define it with a proper signature on D's side with a helpful cast :) i.e. https://github.com/DerelictOrg/DerelictGL3/blob/master/source/derelict/opengl/versions/gl1x.d
Re: expectations 0.1.0
On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote: expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expected. [2] If you're not familiar with those, Andrei's NDC Oslo talk, "Expect the Expected" [3], explains the advantages of this approach to error handling in considerable detail. Incidentally, I've already proposed `Expected` into Phobos std.experimental.typecons here https://github.com/dlang/phobos/pull/6686 Is it ok if I try to merge your effort into this pull request?
Re: This thread on Hacker News terrifies me
On 9/1/2018 11:42 PM, Nick Sabalausky (Abscissa) wrote: > 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. I wouldn't vouch for ATM reliability. You would be surprised what kinds of garbage software they run. Think Windows XP for OS: http://info.rippleshot.com/blog/windows-xp-still-running-95-percent-atms-world But in general, I believe the statement about comparative reliability of tech from 1970s is true. I'm perpetually impressed with is all the mainframe software that often runs mission-critical operations in places you would least expect. Telecom systems are generally very reliable, although it feels that started to change recently.
Re: DIP25/DIP1000: My thoughts round 2
On Sunday, 2 September 2018 at 05:14:58 UTC, Chris M. wrote: Hopefully that was coherent. Again this is me for me to get my thoughts out there, but also I'm interested in what other people think about this. Thanks! Please add anything you think is missing to https://github.com/dlang/dlang.org/pull/2453 since Walter doesn't seem to be interested.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sunday, 2 September 2018 at 14:48:34 UTC, lurker wrote: after the beta i tried it the final again - just to be fair. 1.) install d, install visual d. 2.) trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.) VS2017 - displays a problem on startup 4.) creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? i guess you don't intend to draw crowds to D and just keep talking on how to this and that a little better in the compiler pet project. is D that dead that the releases are not tested or do you want to keep all windows users out? There are a lot of motivated people here willing to help you to get your issue solved if you provide the details. I can confirm that DMD is working like a charm for me (different visual studio versions on build servers, MS build tools on local pc). I use IntelliJ instead of Visual Studio, but that is only my personal preferation. Kind regards Andre
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Sunday, 2 September 2018 at 14:48:34 UTC, lurker wrote: after the beta i tried it the final again - just to be fair. 1.) install d, install visual d. 2.) trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.) VS2017 - displays a problem on startup 4.) creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? i guess you don't intend to draw crowds to D and just keep talking on how to this and that a little better in the compiler pet project. is D that dead that the releases are not tested or do you want to keep all windows users out? Don't worry, that is just the beginning... It's like that in all aspects. The design is fundamentally flawed and no one seems to care(or recognize it). Software is far too complex now days to be using mentalities of the 60's and 70's.
Re: Release D 2.082.0
On Sun, 2 Sep 2018 at 03:05, Laurent Tréguier via Digitalmars-d-announce wrote: > > On Sunday, 2 September 2018 at 01:05:10 UTC, Martin Nowak wrote: > > signed Windows binaries. > > This makes D look so much more professional than having > smartscreen warn you about a potential threat. This is probably > the single best feature of this release IMO. ^^ Thanks so much for getting this across the line everyone!
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 12:08:37 UTC, Martin Nowak wrote: Seems like they knew most artifacts within the installer by now, scanning for the submitted binary was a lot faster than last time. I guess we should keep an eye on this for the next releases, could you take care of this Mike? Take care of what exactly? What specifically needs to be done?
Re: DStep rocks [was Example of using C API from D?]
On Sunday, 2 September 2018 at 17:49:45 UTC, Russel Winder wrote:
On Sun, 2018-09-02 at 18:28 +0100, Russel Winder wrote:
[…]
It turns out that the GIR file is not usable, and so the
girtod route is not feasible. I shall try the DStep route.
Failing that it seems there is
https://github.com/WebFreak001/fontconfig-d
which is a manual transform of a snapshot of the C API, so not
an
ideal
way, but a definite backstop position. It seems someone has
trodden
the
"using Fontconfig in D" path before me.
I compiled DStep master/HEAD (v0.2.3-16-g1308991) against LLVM
6.0 and it seems to have done a rather splendid job of creating
a D binding to Fontconfig. Low-level obviously, but Fontconfig
is seriously low level anyway.
Now to work out how to make the project auto generate this D
module so as to avoid having it in the repository, and
potentially inconsistent with the platform in use.
You could also look at dpp. That's worked for most things I tried
and was written in part to avoid the problem of macros changing
behaviour at build time.
Example here:
https://run.dlang.io/?compiler=dmd=%23include%20%0Avoid%20main()%20%7B%0A%20%20%20%20printf("Hello%20dpp.");%0A%7D
https://github.com/atilaneves/dpp
Re: This thread on Hacker News terrifies me
On Sunday, 2 September 2018 at 04:59:49 UTC, Nick Sabalausky (Abscissa) wrote: A. People not caring enough about their own craft to actually TRY to learn how to do it right. Well, that is an issue. That many students enroll into programming courses, not because they take pride in writing good programs, but because they think that working with computers would somehow be an attractive career path. Still, my impression is that students that write good programs also seem to be good at theory. B. HR people who know nothing about the domain they're hiring for. Well, I think that goes beyond HR people. Also lead programmers in small businesses that either don't have an education or didn't do too well, will feel that someone that does know what they are doing is a threat to their position. Another issue is that management does not want to hire people who they think will get bored with their "boring" software projects... So they rather hire someone less apt that will not quit the job after 6 months... So there are a lot of dysfunctional aspects at the very foundation of software development processes in many real world businesses. I wouldn't expect anything great to come out of this... I also suspect that many managers don't truly understand that one good programmer can replace several bad ones... C. Overall societal reliance on schooling systems that: - Know little about teaching and learning, - Even less about software development, Not sure what you mean by this. In many universities you can sign up for the courses you are interested in. It is really up to the student to figure out what their profile should be. Anyway, since there are many methodologies, you will have to train your own team in your specific setup. With a well rounded education a good student should have the knowledge that will let them participate in discussions about how to structure the work. So there is really no way for any university to teach you exactly what the process should be like. This is no different from other fields. Take a sawmill; there are many ways to structure the manufacturing process in a sawmill. Hopefully people with an education is able to grok the process and participate in discussions about how to improve it, but the specifics is dependent on the concrete sawmill production line.
Re: John Regehr on "Use of Assertions"
On 09/01/2018 04:15 PM, Walter Bright wrote: https://blog.regehr.org/archives/1091 This does make me think of one thing: Shouldn't assert expressions be required to be pure? (even if only weakly pure) Not sure how much practical problems that would create, but at least in theory it certainly sounds like the right thing.
Re: This thread on Hacker News terrifies me
On 09/01/2018 03:47 PM, Everlast wrote: 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... GUI programming has been attempted a lot. (See Scratch for one of the latest, possibly most successful attempts). But there are real, practical reasons it's never made significant in-roads (yet). There are really two main, but largely independent, aspects to what you're describing: Visual representation, and physical interface: A. Visual representation: - By visual representation, I mean "some kind of text, or UML-ish diagrams, or 3D environment, etc". What's important to keep in mind here is: The *fundamental concepts* involved in programming are inherently abstract, and thus equally applicable to whatever visual representation is used. If you're going to make a diagram-based or VR-based programming tool, it will still be using the same fundamental concepts that are already established in text-based programming: Imperative loops, conditionals and variables. Functional/declarative immutability, purity and high-order funcs. Encapsulation. Pipelines (like ranges). Etc. And indeed, all GUI based programming tools have worked this way. Because how *else* are they going to work? If what you're really looking for is something that replaces or transcends all of those existing, fundamental programming concepts, then what you're *really* looking for is a new fundamental programming concept, not a visual representation. And ance you DO invent a new fundamental programming concept, being abstract, it will again be applicable to a variety of possible visual representations. That said, it is true some concepts may be more readily amenable to certain visual representations than others. But, at least for all the currently-known concepts, any combination of concept and representation can certainly be made to work. B. Physical interface: -- By this I mean both actual input devices (keyboards, controllers, pointing devices) and also the mappings from their affordances (ie, what you can do with them: push button x, tilt stick's axis Y, point, move, rotate...) to specific actions taken on the visual representation (navigate, modify, etc.) The mappings, of course, tend to be highly dependant on the visual representation (although, theoretically, they don't strictly HAVE to be). The devices themselves, less so: For example, many of us use a pointing device to help us navigate text. Meanwhile, 3D modelers/animators find it's MUCH more efficient to deal with their 3D models and environments by including heavy use of the keyboard in their workflow instead of *just* a mouse and/or wacom alone. An important point here, is that using a keyboard has a tendency to be much more efficient for a much wider range of interactions than, say, a pointing device, like a mouse or touchscreen. There are some things a mouse or touchscreen is better at (ie, pointing and learning curve), but even on a touchscreen, pointing takes more time than pushing a button and is somewhat less composable with additional actions than, again, pushing/holding a key on a keyboard. This means that while pointing, and indeed, direct manipulation in general, can be very beneficial in an interface, placing too much reliance on it will actually make the user LESS productive. The result: --- For programming to transcend the current text/language model, *without* harming either productivity or programming power (as all attempts so far have done), we will first need to invent entirely new high-level concepts which are simultaneously both simple/high-level enough AND powerful enough to obsolete most of the nitty-gritty lower-level concepts we programmers still need to deal with on a regular basis. And once we do
Re: Static foreach bug?
On Sunday, 2 September 2018 at 19:42:20 UTC, bauss wrote: Woud be so much more maintainable if I could have each statement into a variable that could be maintained properly. You could extract the body of the static foreach into a [template] function.
Re: John Regehr on "Use of Assertions"
On Sunday, 2 September 2018 at 02:32:31 UTC, Jonathan M Davis
wrote:
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
I believe asserts are the general case of which bounds checking
is a specific instance. @safe code is only @safe if
bounds-checking is enabled for @safe.
void foo(int[] a) @safe
{
a[0] = 1;
}
is only really guaranteed safe if a bounds check is done, because
[] is a valid array for a caller to pass.
void foo(int[] a) @safe
{
assert(a.length == 1);
a[0] = 1;
}
if asserts can be used as guarantees for the optimiser even when
removed, this code is only @safe when asserts are enabled
(because otherwise the bounds checks would be elided as they are
guaranteed to pass).
So, essentially we just have to treat asserts like bounds checks
and @safe will work as expected.
P.S.
// assert
debug assert(cond, msg);
// assume
assert(cond, msg);
Re: Static foreach bug?
On Sunday, 2 September 2018 at 18:07:10 UTC, Jonathan M Davis
wrote:
On Sunday, September 2, 2018 7:21:05 AM MDT bauss via
Digitalmars-d wrote:
Is there a reason why you cannot create a separate scope
within a static foreach?
The below will not compile:
```
enum a = ["a" : "a", "b" : "b", "c" : "c"];
static foreach (k,v; a)
{
{
enum b = k;
enum c = v;
}
}
```
It works if it's in a function of course.
This creates a big limitation when you're trying to ex. loop
through members of inherited classes, interfaces etc. and then
want to store the information in variables, because you cannot
do it. Which means to work around it you have to do it all in
an ugly one-liner.
Is it intended behavior? If so, why? If not is there a
workaround until it can be fixed?
If you're not inside a function, why would it even be useful to
be able to do that? That would be the equivalent of
{
enum b = "a";
enum c = "a";
}
{
enum b = "b";
enum c = "b";
}
{
enum b = "c";
enum c = "c";
}
Creating scopes like that isn't legal outside of a function
(hence the compiler error), but even if it were, what good
would it do you? There's no way to refer to those scopes. The
only way that such declarations would make sense is if they're
inside scopes with their own names so that they can be referred
to via those names (e.g. inside a struct or template) or if
they aren't in separate scopes and have unique names (which
would mean giving them names other than b and c rather than
trying to scope them). I fail to see why what you're
complaining about here would even be useful.
Now, the fact that it's a bit of a pain to give each of those
enums a unique name can certainly be annoying, and that's a
problem with static foreach in general, but I don't understand
why creating an extra scope like you're trying to do here would
be at all useful outside of a function. What are you really
trying to do here?
- Jonathan M Davis
Let me demonstrate why it's useful with just this unmaintainable
piece of code:
```
final class ClassName : SoapBinding, Interface
{
public:
final:
this()
{
super();
}
import __stdtraits = std.traits;
static foreach (member; __traits(derivedMembers, Interface))
{
mixin
(
mixin("(__stdtraits.ReturnType!" ~ member ~ ").stringof") ~
" " ~
member ~
"(" ~
mixin("parameters!" ~ member) ~
") { /* Do stuff ... */ }"
);
}
}
```
Woud be so much more maintainable if I could have each statement
into a variable that could be maintained properly.
Re: [OT] college
On 09/02/2018 05:43 AM, Joakim wrote: Most will be out of business within a decade or two, as online learning takes their place. I kinda wish I could agree with that, but schools are too much of a sacred cow to be going anywhere anytime soon. And for that matter, the online ones still have to tackle many of the same challenges anyway, WRT successful and effective teaching. Really the only difference is "physical classroom vs no physical classroom". Well, that and maybe price, but the community colleges have had the uni's well beat on price for a long time (even manage to do a good job teaching certain things, depending on the instructor), but they haven't made the uni's budge: The best they've been able to do is establish themselves as a supplement to the uni's, where people start out with some of their gen-ed classes at the (comparatively) cheap community colleges for the specific purpose of later transferring to a uni.
Re: DCD 0.9.11 & D-Scanner 0.5.10
On Sunday, 2 September 2018 at 04:52:22 UTC, Basile B. wrote: 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 Better use https://github.com/dlang-community/DCD/releases/tag/v0.9.12
[Issue 19199] Use core.bitops intrinsics during CTFE
https://issues.dlang.org/show_bug.cgi?id=19199 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19199] Use core.bitops intrinsics during CTFE
https://issues.dlang.org/show_bug.cgi?id=19199 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/d157dc65fb7038490b61798e2c92fd31901e Fix Issue 19199 - Use core.bitops intrinsics during CTFE dmd.builtin.eval_popcnt had the wrong type: should always be int rather than matching the type of the argument. https://github.com/dlang/dmd/commit/3dab4374fe584301c2cbb75ef69fa9b9a803e3f6 Merge pull request #8627 from n8sh/builtin-bitops-19199 Fix Issue 19199 - Use core.bitops intrinsics during CTFE merged-on-behalf-of: Petar Kirov --
Re: Static foreach bug?
On Sunday, September 2, 2018 7:21:05 AM MDT bauss via Digitalmars-d wrote:
> Is there a reason why you cannot create a separate scope within a
> static foreach?
>
> The below will not compile:
>
> ```
> enum a = ["a" : "a", "b" : "b", "c" : "c"];
>
> static foreach (k,v; a)
> {
> {
> enum b = k;
> enum c = v;
> }
> }
> ```
>
> It works if it's in a function of course.
>
> This creates a big limitation when you're trying to ex. loop
> through members of inherited classes, interfaces etc. and then
> want to store the information in variables, because you cannot do
> it. Which means to work around it you have to do it all in an
> ugly one-liner.
>
> Is it intended behavior? If so, why? If not is there a workaround
> until it can be fixed?
If you're not inside a function, why would it even be useful to be able to
do that? That would be the equivalent of
{
enum b = "a";
enum c = "a";
}
{
enum b = "b";
enum c = "b";
}
{
enum b = "c";
enum c = "c";
}
Creating scopes like that isn't legal outside of a function (hence the
compiler error), but even if it were, what good would it do you? There's no
way to refer to those scopes. The only way that such declarations would make
sense is if they're inside scopes with their own names so that they can be
referred to via those names (e.g. inside a struct or template) or if they
aren't in separate scopes and have unique names (which would mean giving
them names other than b and c rather than trying to scope them). I fail to
see why what you're complaining about here would even be useful.
Now, the fact that it's a bit of a pain to give each of those enums a unique
name can certainly be annoying, and that's a problem with static foreach in
general, but I don't understand why creating an extra scope like you're
trying to do here would be at all useful outside of a function. What are you
really trying to do here?
- Jonathan M Davis
Re: DCD 0.9.11 & D-Scanner 0.5.10
On Sunday, 2 September 2018 at 15:45:45 UTC, Nordlöw wrote: On Sunday, 2 September 2018 at 04:52:22 UTC, Basile B. wrote: 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 Great! Professional. Well thnaks but, hum, actually DCD 0.9.12 is coming directly today. There was an indescribable mess with scopes. For example try ``` import core.thread; Thread t; t. ``` the dot completions for t are completely wrong and many stuff miss.
Re: DStep rocks [was Example of using C API from D?]
On Sun, 2018-09-02 at 18:28 +0100, Russel Winder wrote: > […] > It turns out that the GIR file is not usable, and so the girtod route > is not feasible. I shall try the DStep route. Failing that it seems > there is > > https://github.com/WebFreak001/fontconfig-d > > which is a manual transform of a snapshot of the C API, so not an > ideal > way, but a definite backstop position. It seems someone has trodden > the > "using Fontconfig in D" path before me. I compiled DStep master/HEAD (v0.2.3-16-g1308991) against LLVM 6.0 and it seems to have done a rather splendid job of creating a D binding to Fontconfig. Low-level obviously, but Fontconfig is seriously low level anyway. Now to work out how to make the project auto generate this D module so as to avoid having it in the repository, and potentially inconsistent with the platform in use. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Example of using C API from D?
On Sun, 2018-09-02 at 18:11 +0100, Russel Winder wrote: > […] > I am not sure if DStep is the right tool for creating a complete D > binding to Fontconfig. Given that Fontconfig has a GIR file, using > girtod may well be the better route. It turns out that the GIR file is not usable, and so the girtod route is not feasible. I shall try the DStep route. Failing that it seems there is https://github.com/WebFreak001/fontconfig-d which is a manual transform of a snapshot of the C API, so not an ideal way, but a definite backstop position. It seems someone has trodden the "using Fontconfig in D" path before me. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Example of using C API from D?
On Sun, 2018-09-02 at 15:40 +, Arun Chandrasekaran via Digitalmars- d-learn wrote: > […] > > You can look at zmqd[1] as an example. I've been using it in > production. I've also used dstep[2] to translate C headers to D. > > [1] https://github.com/kyllingstad/zmqd > [2] https://github.com/jacob-carlborg/dstep zmqd itself is just a thin D wrapper around deimos.zmq which is where the C stuff is. Looks like a lot of repetition, and it is manual – but very useful for the task of the moment, so thanks for the pointer. For 0MQ, using DStep might be better than the hand crafted zmqd/diemos.zmq. I am not sure if DStep is the right tool for creating a complete D binding to Fontconfig. Given that Fontconfig has a GIR file, using girtod may well be the better route. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Example of using C API from D?
On Mon, 2018-09-03 at 01:00 +1200, rikki cattermole via Digitalmars-d- learn wrote: > […] > You don't need to create a complete binding for something to use a > subset of it. True, but all too often you find there are so many interdependencies of names, you end up binding most of the API. I tried fiddling with Fontconfig using Python which has no binding and was able to hack up just enough using CFFI to get things working. So I think in this case a subset for the application is feasible – as opposed to creating a complete binding. > Writing up a Derelict style binding is easy enough since e.g. > SharedLib > struct handles most of the work (from util package). > > https://github.com/DerelictOrg/DerelictUtil/blob/master/source/derelict/util/sharedlib.d#L118 I am not convinced this is a good approach since you do not get the signatures at compile time. The advantage of a binding, or subset of a binding is that you get full compiler support. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 15:33:09 UTC, Laurent Tréguier wrote: On Sunday, 2 September 2018 at 14:42:41 UTC, lurker wrote: after the beta i tried it again - just to be fair. 1.) install d, install visual d. 2.)trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.)VS2017 - displays a problem on startup 4.)creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? With the Windows SDK, the Windows Universal C Runtime and the VC++ v14.15 installed with Visual Studio Installer, I can compile for x64. What does it say is missing ? if i remember correctly (5.), it wants a different/other version of the tool chain. never the less, i'll continue using c# and not install (1.) again, since in earlier versions of D i eventually had to deinstall VS2017 and then reinstall it fresh. too much work. btw, 1. was the only plugin i had.
Re: DCD 0.9.11 & D-Scanner 0.5.10
On Sunday, 2 September 2018 at 04:52:22 UTC, Basile B. wrote: 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 Great! Professional.
Re: Example of using C API from D?
On Sunday, 2 September 2018 at 12:52:11 UTC, Russel Winder wrote: I am rewriting a C++ program in D, but need to access a C library that has no D binding: this is a GtkD based program which has a Pango binding, but Pango doesn't offer the information I need, that is hidden in the underlying Fontconfig C API. I could create a complete D binding for Fontconfig using the GIR files but that seems a bit over the top. Can anyone point me at an example of a D program using a C API that has structs, enums and functions so I can see if I just hack enough for my use or go on to the full binding activity. You can look at zmqd[1] as an example. I've been using it in production. I've also used dstep[2] to translate C headers to D. [1] https://github.com/kyllingstad/zmqd [2] https://github.com/jacob-carlborg/dstep
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 14:42:41 UTC, lurker wrote: after the beta i tried it again - just to be fair. 1.) install d, install visual d. 2.)trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.)VS2017 - displays a problem on startup 4.)creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? With the Windows SDK, the Windows Universal C Runtime and the VC++ v14.15 installed with Visual Studio Installer, I can compile for x64. What does it say is missing ?
Re: Static foreach bug?
On Sunday, 2 September 2018 at 13:21:05 UTC, bauss wrote:
Is there a reason why you cannot create a separate scope within
a static foreach?
The below will not compile:
```
enum a = ["a" : "a", "b" : "b", "c" : "c"];
static foreach (k,v; a)
{
{
enum b = k;
enum c = v;
}
}
```
It works if it's in a function of course.
[...]
At the global scope it cant work since there even block
statements are not possible, just this
```
{
enum b = 0;
enum c = 0;
}
```
doesn't compile; and this is what you tried to add in the `static
foreach` body. So if i understand correctly this is even not a
`static foreach` issue here.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
after the beta i tried it the final again - just to be fair. 1.) install d, install visual d. 2.) trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.) VS2017 - displays a problem on startup 4.) creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D? i guess you don't intend to draw crowds to D and just keep talking on how to this and that a little better in the compiler pet project. is D that dead that the releases are not tested or do you want to keep all windows users out?
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 01:16:40 UTC, Mike Franklin wrote: 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 after the beta i tried it again - just to be fair. 1.) install d, install visual d. 2.)trying to to look at options under visual d without a project crashes VS2017 - latest service pack. 3.)VS2017 - displays a problem on startup 4.)creating the dummy project - compile for x64. error something is missing. 5.) deinstall everything and wait for another year this crap does not even work out of the box - what else is not tested in D?
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. It shouldn't allow side-effects then though. https://run.dlang.io/is/P6VnYd Also a common source of bugs in C.
Re: Static foreach bug?
On Sunday, 2 September 2018 at 13:26:55 UTC, Petar Kirov [ZombineDev] wrote: It's intended, but with the possibility to add special syntax for local declarations in the future left open, as per: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md#local-declarations Is there any plans to implement it soon or is this going to be another half done feature?
Re: Static foreach bug?
On Sunday, 2 September 2018 at 13:21:05 UTC, bauss wrote:
Is there a reason why you cannot create a separate scope within
a static foreach?
The below will not compile:
```
enum a = ["a" : "a", "b" : "b", "c" : "c"];
static foreach (k,v; a)
{
{
enum b = k;
enum c = v;
}
}
```
It works if it's in a function of course.
This creates a big limitation when you're trying to ex. loop
through members of inherited classes, interfaces etc. and then
want to store the information in variables, because you cannot
do it. Which means to work around it you have to do it all in
an ugly one-liner.
Is it intended behavior? If so, why? If not is there a
workaround until it can be fixed?
It's intended, but with the possibility to add special syntax for
local declarations in the future left open, as per:
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md#local-declarations
Static foreach bug?
Is there a reason why you cannot create a separate scope within a
static foreach?
The below will not compile:
```
enum a = ["a" : "a", "b" : "b", "c" : "c"];
static foreach (k,v; a)
{
{
enum b = k;
enum c = v;
}
}
```
It works if it's in a function of course.
This creates a big limitation when you're trying to ex. loop
through members of inherited classes, interfaces etc. and then
want to store the information in variables, because you cannot do
it. Which means to work around it you have to do it all in an
ugly one-liner.
Is it intended behavior? If so, why? If not is there a workaround
until it can be fixed?
Re: Static foreach bug?
On Sunday, 2 September 2018 at 13:21:05 UTC, bauss wrote: Is there a reason why you cannot create a separate scope within a static foreach? You can try it out here: https://run.dlang.io/is/7DgwCk
Re: Example of using C API from D?
On 03/09/2018 12:52 AM, Russel Winder wrote: I am rewriting a C++ program in D, but need to access a C library that has no D binding: this is a GtkD based program which has a Pango binding, but Pango doesn't offer the information I need, that is hidden in the underlying Fontconfig C API. I could create a complete D binding for Fontconfig using the GIR files but that seems a bit over the top. Can anyone point me at an example of a D program using a C API that has structs, enums and functions so I can see if I just hack enough for my use or go on to the full binding activity. You don't need to create a complete binding for something to use a subset of it. Writing up a Derelict style binding is easy enough since e.g. SharedLib struct handles most of the work (from util package). https://github.com/DerelictOrg/DerelictUtil/blob/master/source/derelict/util/sharedlib.d#L118
Example of using C API from D?
I am rewriting a C++ program in D, but need to access a C library that has no D binding: this is a GtkD based program which has a Pango binding, but Pango doesn't offer the information I need, that is hidden in the underlying Fontconfig C API. I could create a complete D binding for Fontconfig using the GIR files but that seems a bit over the top. Can anyone point me at an example of a D program using a C API that has structs, enums and functions so I can see if I just hack enough for my use or go on to the full binding activity. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: extern __gshared const(char)* symbol fails
On Friday, 31 August 2018 at 18:49:26 UTC, James Blachly wrote: 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. In case you weren't aware of it, take a look at atilaneves DPP on GitHub or code.dlang.org. auto translates C headers at build time and mostly it just works. If it doesn't, file an issue and in time it will be fixed.
Re: This thread on Hacker News terrifies me
On Sunday, 2 September 2018 at 06:25:47 UTC, Nick Sabalausky (Abscissa) wrote: On 08/31/2018 07:47 PM, Jonathan M Davis wrote: 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. This is why we really should bring back the ancient practice of apprenticeship, that we've mostly gotten away from. Doesn't have to be identical to the old system in every detail, but who better to teach XYZ to members a new generation than those who ARE experts at XYZ. Sure, teaching in and of itself is a skill, and not every domain expert is a good teacher. But like any skill, it can be learned. And after all: Who really stands a better chance at passing on expertise?: A. Someone who already has the expertise, but isn't an expert in teaching. B. Someone who is an expert at teaching, but doesn't posses what's being taught anyway. Hint: No matter how good of a teacher you are, you can't teach what you don't know. Heck, if all else fails, pair up domain experts WITH teaching experts! No need for any jacks-of-all-trades: When people become domain experts, just "apprentice" them in a secondary skill: Teaching their domain. Sounds a heck of a lot better to me than the ridiculous current strategy of: Separate the entire population into "theory" (ie, Academia) and "practical" (ie, Industry) even though it's obvious that the *combination* of theory and practical is essential for any good work on either side. Have only the "theory" people do all the teaching for the next generation of BOTH "theory" and "practical" folks. Students then gain the "practical" side from...what, the freaking ether From the industry which doesn't care about quality, only profit??? From the "theory" folk that are never taught the "practical"??? From where, out of a magical freaking hat?!?!? I agree. I have been arguing the same for a few years now. https://www.quora.com/With-6-million-job-openings-in-the-US-why-are-people-complaining-that-there-are-no-jobs-available/answer/Laeeth-Isharc?srid=7h We de-emphasized degrees and those are information only unless for work permits it is a factor (and sadly it is) and also are open to hiring people with less vocationally relevant degrees. A recent hire I made was a chap who studied music at Oxford and played the organ around the corner. His boss is a Fellow in Maths at Trinity College, Cambridge and us very happy with him. And we started hiring apprentices ourselves. The proximate trigger for me to make it happen was a frustrating set of interviews with more career-oriented people from banks for a support role in London. "Is it really asking too much to expect that somebody who works on computers should actually like playing with them ?" So we went to a technical college nearby where someone in the group lives and we made a start this year and in time it will grow. The government introduced an apprenticeship programme. I don't think many people use it yet because it's not adapted to commercial factors. But anything new is bad in the first version and it will get better.
Re: This thread on Hacker News terrifies me
On 9/1/18 6:29 AM, Shachar Shemesh wrote: 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. 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". Which is exactly what Phobos and Druntime do (ignore asserts in production). I'm not sure how the intention makes any difference. The obvious position of D is that asserts and bounds checks shouldn't be used in production -- that is how we ship our libraries. It is what the "-release" switch does. How else could it be interpreted? -Steve
Re: LDC 1.11.0
On 08/18/2018 06:47 PM, kinke wrote: > Glad to announce LDC 1.11: > > * Rudimentary support for compiling & linking directly to WebAssembly. > See the dedicated Wiki page [1] for how to get started. Nice one! > [1] https://wiki.dlang.org/Generating_WebAssembly_with_LDC
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: 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? That's why the people that adopt D will inordinately be principals not agents in the beginning. They will either be residual claimants on earnings or will have acquired the authority to make decisions without persuading a committee that makes decisions on the grounds of social factors. If D becomes another C++ ? C++ was ugly from the beginning (in my personal subjective assessment) whereas D was designed by people with good taste. That's why it appeals inordinately to people with good taste. In Hong Kong we had some difficulty hiring a support person for a trading floor. Spoke in some cases to the most senior person in HK for even large and well-known funds (small office in this case) and they simply were not good enough. Thanks to someone from the D community I met a headhunter who used to be at Yandex but realized the money was better as a headhunter. They don't have many financial clients I think, don't have connections on the talent side in finance. But the runners up were by far better than anyone we had found through other sources and the best was outstanding. Good job, I said. It's funny that the person we hired came from a big bank when other headhunters are looking in the same place and know that world better. By the way, how many people did you interact with to find X ? In London if a headhunter puts 10 people before you and you are really pretty happy then that's a good day. He said two hundred ! And they had to come up with a hiring test too. So the basic reason they could find good people in technology in finance when others couldn't is that they have much better taste. Do you see ? The others knew many more people, they had experience doing it, and somebody who had to persuade a committee would have found it hard to justify. Programming ability follows a Pareto curve - see the best and the rest. There might be many more C++, Python and C# programmers. The incidence of outstanding ones is lower than in the D community for the very reason that only someone obtuse or very smart will learn D for career reasons - intrinsic motivation draws the highest talent. It depends if your model of people doing work is an army of intelligent trained monkeys or a force made up of small elite groups of the best people you have ever worked with. Of course the general of the trained monkey army is going to be difficult to persuade. And so ? On the other hand, someone who is smart and has good taste and has earned the right to decide - D is a less popular language that has fewer tutorials and less shiny IDE and debugger support. Well if you're a small company and you are directly or in effect a proxy owner of the residual (ie an owner of some kind) it's a pragmatic question and saying nobody got fired for buying IBM - that's missing the point because the success is yours and the failure is yours and you can't pass the buck. The beauty of being the underdog is that it's easy to succeed. You don't need to be the top dog, and in fact it's not strategically wise to do something that might think you stand a chance - let them think what they want. The underdog just needs to keep improving and keep getting more adoption, which I don't have much doubt is happening. Modern people can be like children in their impatience sometimes! I've only been programming since 1983 so I had the benefit of high level languages like BBC BASIC, C, a Forth I wrote myself, and Modula 3. And although I had to write a disassembler at least I has assemblers built in. Programming using a hex keypad is not that satisfying after a while. It takes a long time to develop a language, its ecosystem and community. An S curve is quite
Re: Copr repository providing dmd and dub for Fedora, EPEL and Mageia
On 08/31/2018 09:49 PM, Laurent Tréguier wrote: > 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. We definitely want to switch the official dmd binaries to ldc or gdc at some point as well. Would be great to do a somewhat concerted switch with all the external packagers.
Re: Release D 2.082.0
On 09/02/2018 03:16 AM, Mike Franklin wrote: > 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. Seems like they knew most artifacts within the installer by now, scanning for the submitted binary was a lot faster than last time. I guess we should keep an eye on this for the next releases, could you take care of this Mike?
Re: anyway to debug nogc code with writeln?
On Saturday, 1 September 2018 at 21:53:03 UTC, aliak wrote:
Anyway around this?
I don't know if your situation allows it, but you can mark f
explicitly as always @nogc. If your design assumes that it's
@nogc, it's a good idea to add the attribute anyway.
You can also use the C printf function:
```
import core.stdc.stdio: printf;
printf("yo\n");
```
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Saturday, 1 September 2018 at 18:35:30 UTC, TheSixMillionDollarMan wrote: On Saturday, 1 September 2018 at 12:33:49 UTC, rjframe wrote: [...] 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... D++
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 01:05:10 UTC, Martin Nowak wrote: signed Windows binaries. This makes D look so much more professional than having smartscreen warn you about a potential threat. This is probably the single best feature of this release IMO.
[OT] college
On Sunday, 2 September 2018 at 07:56:09 UTC, Nick Sabalausky (Abscissa) wrote: On 09/02/2018 02:06 AM, Joakim wrote: On Sunday, 2 September 2018 at 05:16:43 UTC, Nick Sabalausky (Abscissa) wrote: 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. Why? Please don't tell me you believe this nonsense: "Wadhwa... argues (I am not joking) that partying is a valuable part of the college experience because it teaches students interpersonal skills." https://www.forbes.com/sites/jerrybowyer/2012/05/22/a-college-bubble-so-big-even-the-new-york-times-and-60-minutes-can-see-it-sort-of/ Learning skills from partying? Hah hah, no, no, it's not about anything like that. :) (Social skills matter, but obviously plenty of other ways to practice those.) No, it's just that honing skills isn't the only thing in life that matters. Simply living life while you're here is important too, for its own sake, even if you only realize it after the fact. Eh, having fun should be part of the college experience of course, but I suspect most of those out partying were taking it far beyond that. I bet many of them regret that today. You're right that college is largely an irrelevant playground, precisely because of the incoherent combination of theory and bows to what they think are popular industry practices that you laid out. Most will be out of business within a decade or two, as online learning takes their place.
[Issue 19195] Support pragma to specify linker directives
https://issues.dlang.org/show_bug.cgi?id=19195 --- Comment #1 from Manu --- https://github.com/dlang/dmd/pull/8654 --
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 1 September 2018 at 21:18:27 UTC, Nick Sabalausky (Abscissa) wrote: 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.) "when or even if" I'm in the same situation but I can't wait anymore. Apps are everywhere these days and if you can't provide some sort of app, you're not in a good position. It's the realty of things, it's not a game, for many of us our jobs depend on it. Btw, why did I get this message yesterday: "Your message has been saved, and will be posted after being approved by a moderator." My message hasn't shown up yet as it hasn't been approved yet ;)
[Issue 19212] Add versions for C++ runtimes.
https://issues.dlang.org/show_bug.cgi?id=19212 --- Comment #1 from Manu --- PR: https://github.com/dlang/dmd/pull/8652 --
[Issue 19212] New: Add versions for C++ runtimes.
https://issues.dlang.org/show_bug.cgi?id=19212 Issue ID: 19212 Summary: Add versions for C++ runtimes. Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com Add known versions for the C++ runtime. --
Re: This thread on Hacker News terrifies me
On Sunday, 2 September 2018 at 04:21:44 UTC, Jonathan M Davis
wrote:
On Saturday, September 1, 2018 9:18:17 PM MDT Nick Sabalausky
(Abscissa) via Digitalmars-d wrote:
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.
One reason why programs using stdio do fail with disk space
errors is that they don't know that fclose() can be the function
reporting it, not the fwrite()/fputs()/fprintf(). I can not count
the number of times I saw things like that:
FILE *fd = fopen(...,"w");
if(fwrite(buffer, length, 1)<1) {
fine error handling
fclose(fd);
on disk fullness the fwrite might have accepted the data, but
only the fclose() really flushed the data to disk, only detecting
the lack of space at that moment.
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.
Indeed, since some of those error checks also differ from OS to
OS, some cases might detect things in one setting but not in
others. See my example above, on DOS or if setvbuf() was set to
NULL it would not possibly happen as the fwrite() would always
flush() the data to disk and the error condition would be catched
nearly 99.% of times.
Re: This thread on Hacker News terrifies me
On 09/02/2018 02:06 AM, Joakim wrote: On Sunday, 2 September 2018 at 05:16:43 UTC, Nick Sabalausky (Abscissa) wrote: 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. Why? Please don't tell me you believe this nonsense: "Wadhwa... argues (I am not joking) that partying is a valuable part of the college experience because it teaches students interpersonal skills." https://www.forbes.com/sites/jerrybowyer/2012/05/22/a-college-bubble-so-big-even-the-new-york-times-and-60-minutes-can-see-it-sort-of/ Learning skills from partying? Hah hah, no, no, it's not about anything like that. :) (Social skills matter, but obviously plenty of other ways to practice those.) No, it's just that honing skills isn't the only thing in life that matters. Simply living life while you're here is important too, for its own sake, even if you only realize it after the fact.
Re: This thread on Hacker News terrifies me
On 09/02/2018 12:21 AM, Jonathan M Davis wrote: The C APIs on the other hand require that you check the return value, and some of the C++ APIs require the same. Heh, yea, as horrifically awful as return value errors really are, I have to admit, with them, at least it's actually *possible* to handle these low-resource situations sanely, instead of D's "not-so-right-thing by default" approach of *guaranteeing* that all software under the same circumstance just freaks out and runs screaming like KDE. (Much as I love D, and as much as I believe in "fail fast", the "Error" class still irritates me to no end. My usual approach to dealing with it is to stick my fingers in my ears and go "La la la la la!!! It doesn't affect me!!! There's no such thing as non-Exceptions being thrown!!! La la la". Not exactly a sound engineering principle. If we actually HAD the mechanisms Walter advocates for *dealing* with fail-fast processes, then I might have a different opinion. But we *don't*, it's just code-n-pray for now, and nothing of the sort is even on the most pie-in-the-sky roadmap.) 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. Under current tools and approaches, that is, unfortunately, probably very true. However... Most code simply isn't ever going to be written to handle such situations, This is 2018. We all have a freaking Dick Tracy wireless supercomputer, that can believably simulate entire connected alternate realities, in realtime...in our pockets! Right now! If we, the collective software development community of 2018, can't get far enough off our collective asses and *do something about* (as opposed to *completely ignore and never bother even so much as an automated test*) something as basic, obvious, *automatable*, and downright *timeless* as...not having our software freak out in the absence of resources we're not even freaking using...Well, then we, as an entire profession...genuinely SU*K. Hard. (And yes, I am definitely including myself in that judgement. I'm more than willing to change my prehistoric-programmer ways. But implementation-wise there's relevant domain experience I lack, so I can't make this all happen by myself, so there needs to be some buy-in.) Anything C-based (and plenty of C++-based programs too) is going to have serious problems though Well, yea. No mystery or surprise there. Another reason I tend to be a bit dismayed at the continued popularity of those languages (not that I'm unaware of all the reasons for their continued popularity).
[Issue 19200] Variant operators don't overload correctly
https://issues.dlang.org/show_bug.cgi?id=19200 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19200] Variant operators don't overload correctly
https://issues.dlang.org/show_bug.cgi?id=19200 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/71fc01cc63ee28648bdcd19faf8255c4dfeaf290 Fix issue 19200 https://github.com/dlang/phobos/commit/4873119553666819b4810a1318998eaad7476b08 Merge pull request #6684 from Biotronic/issue-19200 Fix issue 19200 - Variant operators don't overload correctly merged-on-behalf-of: Petar Kirov --
expectations 0.1.0
expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expected. [2] If you're not familiar with those, Andrei's NDC Oslo talk, "Expect the Expected" [3], explains the advantages of this approach to error handling in considerable detail. Features: - `Expected` values can be treated as either return codes or exceptions. - Functions that return `Expected` values can be composed easily using a monadic interface (`andThen`). - `Expected!void` is valid and (hopefully) works the way you'd expect. - Everything, except for `opEquals` (which depends on `Object.opEquals`), works in @safe code. This is very much a work in progress; all comments and feedback are welcome. Documentation: https://pbackus.github.io/expectations/expectations.html DUB: https://code.dlang.org/packages/expectations Code: https://github.com/pbackus/expectations [1] https://doc.rust-lang.org/std/result/enum.Result.html [2] https://wg21.link/p0323r7 [3] https://www.youtube.com/watch?v=nVzgkepAg5Y
Re: This thread on Hacker News terrifies me
On 08/31/2018 07:47 PM, Jonathan M Davis wrote: 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. This is why we really should bring back the ancient practice of apprenticeship, that we've mostly gotten away from. Doesn't have to be identical to the old system in every detail, but who better to teach XYZ to members a new generation than those who ARE experts at XYZ. Sure, teaching in and of itself is a skill, and not every domain expert is a good teacher. But like any skill, it can be learned. And after all: Who really stands a better chance at passing on expertise?: A. Someone who already has the expertise, but isn't an expert in teaching. B. Someone who is an expert at teaching, but doesn't posses what's being taught anyway. Hint: No matter how good of a teacher you are, you can't teach what you don't know. Heck, if all else fails, pair up domain experts WITH teaching experts! No need for any jacks-of-all-trades: When people become domain experts, just "apprentice" them in a secondary skill: Teaching their domain. Sounds a heck of a lot better to me than the ridiculous current strategy of: Separate the entire population into "theory" (ie, Academia) and "practical" (ie, Industry) even though it's obvious that the *combination* of theory and practical is essential for any good work on either side. Have only the "theory" people do all the teaching for the next generation of BOTH "theory" and "practical" folks. Students then gain the "practical" side from...what, the freaking ether From the industry which doesn't care about quality, only profit??? From the "theory" folk that are never taught the "practical"??? From where, out of a magical freaking hat?!?!?
Re: This thread on Hacker News terrifies me
On Sunday, 2 September 2018 at 05:16:43 UTC, Nick Sabalausky (Abscissa) wrote: 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. Why? Please don't tell me you believe this nonsense: "Wadhwa... argues (I am not joking) that partying is a valuable part of the college experience because it teaches students interpersonal skills." https://www.forbes.com/sites/jerrybowyer/2012/05/22/a-college-bubble-so-big-even-the-new-york-times-and-60-minutes-can-see-it-sort-of/
Re: The final form of the keyboard = ShionKeys
I took the project rooted in ipfs. Short URL: https://bit.do/keyboards I no longer have a fixed email, so don't send any information to my past public emails.
