Re: Embrace the from template?
On Friday, August 24, 2018 7:03:37 PM MDT Jonathan Marler via Digitalmars-d wrote: > > What uses does this actually have, I only see one example from > > the article and it is an oversimplistic example that > > effectively translates to either phobos being used or not being > > used. All the extra bloat this template would add to the > > already bloated if constraints is not welcome at all. The > > potential small benefit this might add isn't worth the > > unreadable mess it will turn code into. > > I can't help but laugh when you say "all the extra bloat this > template would add..." :) Sorry, I don't mean to insult but that > really gave me a laugh. > > I hate to be blunt, but its clear from your response that you > failed to grok the original post, which makes anything else I say > pointless. So I'm going to slowly back away from this > one...step...step..step*stp**s*...* It actually does add more template instantiations - and therefore arguably more bloat. It's just that because it more tightly ties importing to the use of the symbol, it reduces how many symbols you import unnecessarily, which can therefore reduce the bloat. So, if the symbol is used everywhere anyway, then from just adds bloat, whereas if it really is used in a more restricted way, then it reduces compilation times. The reason that I personally hate from's guts is because of how verbose it is. I'd _much_ rather see lazy importing be added like Walter likes to bring up from time to time. It should get us the reduction in compile times without all of the verbosity. As such, I would hate to see from in a place like object.d (or honestly, anywhere in druntime or Phobos), because then it might be used in Phobos all over the place, and I simply don't want to have to deal with it. It's bad enough that we're using scoped and local imports all over the place. They do help with tying imports to what uses them (and in the case of templated code can actually result in imports only happening when they need to), but it's so painfully verbose. I'd much rather not see the situation get that much worse by from being considered best practice instead of just fixing the compiler so that it's more efficient at importing and thus avoiding all of that extra verbosity in the code. - Jonathan M Davis
Re: Parallelizing factorial computation
On Friday, 24 August 2018 at 20:43:46 UTC, Peter Alexander wrote: On Friday, 24 August 2018 at 13:04:47 UTC, Uknown wrote: I was quite surprised by the fact that parallel ran so much slower than recursive and loop implementations. Does anyone know why? n = 100 is too small to see parallelism gains. Try n = 1 https://run.dlang.io/is/XDZTSd I was using n = 1 originally, I reduced it because that wasn't running on run.dlang. Tried this again on my machine and you were right.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, August 24, 2018 6:54:38 PM MDT Joakim via Digitalmars-d wrote: > On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote: > > On 8/24/2018 6:04 AM, Chris wrote: > >> For about a year I've had the feeling that D is moving too > >> fast and going nowhere at the same time. D has to slow down > >> and get stable. D is past the experimental stage. Too many > >> people use it for real world programming and programmers value > >> and _need_ both stability and consistency. > > > > Every programmer who says this also demands new (and breaking) > > features. > > Heh, thought this proggit comment thread was funny given this > complaint, some C++ users feel it's moving too fast now: > > "In the last few years it has basically become a different > language, the feature creep is insane. I stopped caring about new > features since C++11, and progressively used the language less > and less." > > Another user: > > "I remember being really excited about C++11 - and I think it > really did add some much needed features. But it's been getting > more and more out of hand since then..." > https://www.reddit.com/r/programming/comments/99rnuq/comment/e4q8iqn LOL. Yeah. Basically, we all somehow want stuff to be completely stable and never break any of our code, but we also want new stuff that improves the language - which frequently requires breaking existing code (and even if it doesn't require breaking existing code, adding features always risks breaking existing ones - even simply fixing bugs risks introducing new ones). There are better and worse ways to handle change, but I think that we're pretty much all fundamentally conflicted in what we want. You simply can't have everything stay the same and have it change at the same time, and yet, that's basically what everyone wants. Pretty much the only way to get around that would be to have a perfect language with no bugs, and that's obviously not happening even if we could all agree on what the "perfect" language would entail (which we're clearly not going to do). - Jonathan M Davis
Re: Is @safe still a work-in-progress?
On 8/23/2018 5:58 PM, Chris M. wrote: Seems to be more of a warning of what issues we may face if DIP25/DIP1000 are finally implemented. It would be good to consider NLLs as well before D is committed. No point in repeating issues that have already been studied. DIP25 waqs "finally implemented" several years ago, and works well. DIP1000 was implemented as well, it works, but it didn't cover the case of returning through a ref parameter. There's no way to "thoroughly vet" them before implementing. It doesn't happen with C++, either, somebody builds an implementation and then people try it out.
Re: Is @safe still a work-in-progress?
On 8/23/2018 6:32 AM, Steven Schveighoffer wrote: Furthermore any member function (or UFCS function for that matter) REQUIRES the first parameter to be the aggregate. How do you make a member function that stuffs the return into a different parameter properly typecheck? What I propose is that the function interface be refactored so it does fit into these patterns. Is that an unreasonable requirement? I don't know. But it doesn't seem to be, as I haven't run into it yet. Phobos doesn't do this by accident. It's how constructors work (see above) and how pipeline programming works. Constructors I agree are reasonable to consider `this` to be the return value. On that point, I would say we should definitely go ahead with making that rule, and I think it will lead to no confusion whatsoever. pipeline programming depends on returning something other than `void`, so I don't see how this applies. grep Phobos for instances of put() and see its signature. It's part of pipeline programming, and it's all over the place. You would have to consider the shortest liftetime and assume everything goes there. That's right. It would restrict your legitimate calls. Maybe that's a good thing. Having multiple simultaneous routes of data out of a function is not good practice (note that it is impossible with functional programming). If you absolutely must have it, the exit routes can be aggregated into a struct, then pass that struct as the first argument. I want to stress that it may be a valid solution, but we should strive to prove the solutions are the best possible rather than just use duct-tape methodology. I don't know how to prove anything with programming languages. It should even be considered that perhaps there are better solutions even than the approach dip1000 has taken. People have hypothesized that for several years, and so far none have been forthcoming beyond a few hand-wavy generalities. I also want to point out that the attitude of 'we could just fix it, but nobody will pull my request' is unhelpful. We want to make sure we have the best solution possible, don't take criticism as meaningless petty bickering. People are genuinely trying to make sure D is improved. Hostility towards reviews or debate doesn't foster that. I'm not hostile to debate. I just don't care for "this is uncharted territory, so let's do nothing" which has been going on for probably 4 years now, coincident with "scope is incomplete, D sux". I.e. lead, follow, or get out of the way :-)
Re: Is @safe still a work-in-progress?
On 8/23/2018 8:14 AM, Steven Schveighoffer wrote: If I had to design a specific way to allow the common case to be easy, but still provide a mechanism for the uncommon cases, I would say: 1. define a compiler-recognized attribute (e.g. @__sink). 2. If @__sink is applied to any parameter, that is effectively the return value. 3. In the absence of a @__sink designation on non-void-returning functions, it applies to the return value. 4. In the absence of a @__sink designation on void returning functions, it applies to the first parameter. 5. Inference of @__sink happens even on non-templates. 6. If @__sink is attributed on multiple parameters, you assume all return parameters are assigned to all @__sink parameters for the purposes of verifying lifetimes are not exceeded. 'ref' is already @__sink.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 8/24/2018 4:22 PM, tide wrote:
struct SomeStruct
{
void foo() {
// use SomeStruct
}
}
void broken()
{
void function() foo =
foo(); // runtime error, isn't actually safe uses wrong calling convention
as well
}
Not really lack of feature so much as there exists broken code. This has been
valid code for god knows how long. At some point it was usable in @safe, but it
looks you can't take an address of a member function without "this" as well in
safe anymore.
That's because it isn't safe. But being able to take the address is important
for system work.
[Issue 19188] Dub detects wrong(ish) platform on aarch64 systems
https://issues.dlang.org/show_bug.cgi?id=19188 elpenguin...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --
[Issue 19188] Dub detects wrong(ish) platform on aarch64 systems
https://issues.dlang.org/show_bug.cgi?id=19188 --- Comment #1 from elpenguin...@gmail.com --- er, I guess this should have been filed on github instead. my bad --
[Issue 19188] New: Dub detects wrong(ish) platform on aarch64 systems
https://issues.dlang.org/show_bug.cgi?id=19188 Issue ID: 19188 Summary: Dub detects wrong(ish) platform on aarch64 systems Product: D Version: D2 Hardware: Other OS: All Status: NEW Severity: trivial Priority: P1 Component: tools Assignee: nob...@puremagic.com Reporter: elpenguin...@gmail.com when dub is compiled on an aarch64 system, the architecture is detected as arm_hardfloat. it's not wrong, but it's not accurate either. it should be detected as aarch64. --
Re: Embrace the from template?
On Saturday, 25 August 2018 at 00:40:54 UTC, tide wrote: On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote: Ever since I read https://dlang.org/blog/2017/02/13/a-new-import-idiom/ I've very much enjoyed using the new `from` template. It unlocks new idioms in D and have been so useful that I thought it might be a good addition to the core language. I've found that having it in a different place in each project and always having to remember to import it makes it much less ubiquitous for me. One idea is we could add this template to `object.d`. This would allow it to be used from any module that uses druntime without having to import it first. The template itself is also very friendly to "bloat" because it only has a single input parameter which is just a string, extremely easy to memoize. Also, unless it is instantiated, adding it to object.d will have virtually no overhead (just a few AST nodes which would dwarfed by what's already in object.d). It would also be very easy to add, a single PR with 4 lines of code to druntime and we're done. Of course, if we don't want to encourage use of the `from` template then this is not what we'd want. Does anyone have any data/experience with from? All I know is my own usage so feel free to chime in with yours. What uses does this actually have, I only see one example from the article and it is an oversimplistic example that effectively translates to either phobos being used or not being used. All the extra bloat this template would add to the already bloated if constraints is not welcome at all. The potential small benefit this might add isn't worth the unreadable mess it will turn code into. I can't help but laugh when you say "all the extra bloat this template would add..." :) Sorry, I don't mean to insult but that really gave me a laugh. I hate to be blunt, but its clear from your response that you failed to grok the original post, which makes anything else I say pointless. So I'm going to slowly back away from this one...step...step..step*stp**s*...*
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote: On 8/24/2018 6:04 AM, Chris wrote: For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. Every programmer who says this also demands new (and breaking) features. Heh, thought this proggit comment thread was funny given this complaint, some C++ users feel it's moving too fast now: "In the last few years it has basically become a different language, the feature creep is insane. I stopped caring about new features since C++11, and progressively used the language less and less." Another user: "I remember being really excited about C++11 - and I think it really did add some much needed features. But it's been getting more and more out of hand since then..." https://www.reddit.com/r/programming/comments/99rnuq/comment/e4q8iqn
Re: Embrace the from template?
On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote: Ever since I read https://dlang.org/blog/2017/02/13/a-new-import-idiom/ I've very much enjoyed using the new `from` template. It unlocks new idioms in D and have been so useful that I thought it might be a good addition to the core language. I've found that having it in a different place in each project and always having to remember to import it makes it much less ubiquitous for me. One idea is we could add this template to `object.d`. This would allow it to be used from any module that uses druntime without having to import it first. The template itself is also very friendly to "bloat" because it only has a single input parameter which is just a string, extremely easy to memoize. Also, unless it is instantiated, adding it to object.d will have virtually no overhead (just a few AST nodes which would dwarfed by what's already in object.d). It would also be very easy to add, a single PR with 4 lines of code to druntime and we're done. Of course, if we don't want to encourage use of the `from` template then this is not what we'd want. Does anyone have any data/experience with from? All I know is my own usage so feel free to chime in with yours. What uses does this actually have, I only see one example from the article and it is an oversimplistic example that effectively translates to either phobos being used or not being used. All the extra bloat this template would add to the already bloated if constraints is not welcome at all. The potential small benefit this might add isn't worth the unreadable mess it will turn code into.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 11:55:47 UTC, Petar Kirov [ZombineDev] wrote: One of the things that makes Go successful is the quality/ease of use of its toolchain. They have full cross-compilation support out of the box because they don't rely on anything from the C toolchain (libc, linker, etc.). They implement implement everything themselves, from the syscall layer This is something that has caused breakage on newer versions of macos, and broadly makes it difficult to port to new OSes. Something that might be worth pursuing, though, is implementing some of the things in core.stdc in pure d, like printf or strcmp, but printf *would* ultimately forward to the actual libc fwrite.
Re: "The D Way" to run a sequence of executables?
On Friday, 24 August 2018 at 17:36:25 UTC, Matthew OConnor wrote:
I'd like to run a sequence of executables with something like
std.process.execute, but I would like the sequence to error out
if one of the executables returns a non-zero return code. What
is the recommended way to do this? A wrapper that throws
exceptions? Checking return values?
Here'd be a neat way if you don't mind it not terminating early.
The first call will need a dummy value for prevStatus where the
status field is 0.
import std.typecons;
alias ExecuteTuple = Tuple!(int,"status",string,"output");
ExecuteTuple call(ExecuteTuple prevStatus, string process)
{
import std.process;
if (prevStatus.status != 0)
return prevStatus;
else
return execute(process);
}
Re: D is dead
On Friday, 24 August 2018 at 22:52:07 UTC, Steven Schveighoffer wrote: I really don't want to see dlang have to maintain posix system calls on all supported OSes when that's already being done for us. Windows makes this simpler -- the system calls are separate from the C runtime. It would be nice if Posix systems were that way, but it's both silly to reinvent the system calls (they are on every OS anyways, and in shared-library form), and a maintenance nightmare. Keep in mind that we only need to implement the system calls that we need. I haven't looked into Phobos, and probably never will. My interest is mostly in druntime. At this time, I think we only need 2: `sbrk` and `mmap` for `malloc`. I don't consider that much of a maintenance burden, and `malloc` and friends are my least concern at the moment. We're disproportionately leveraging libc in druntime; there are only a few things needed from libc for druntime, and I think I can demonstrate benefit writing them in D (or if someone else wants to, please do, I may never even get to it). If I even stick around in the D community long enough to pursue this, this change it'll be incremental and I'll demonstrate benefit each step of the way. Mike
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 22:42:19 UTC, Walter Bright wrote:
On 8/24/2018 12:42 PM, tide wrote:
Some problems require new features like how taking the address
of a member function without an object returns a function
pointer, but requires a delegate where C++ has member function
pointers, D just has broken unusable code. Or old features
that were implemented poorly (C++ mangling for example).
How to do member function pointers in D:
https://www.digitalmars.com/articles/b68.html
struct SomeStruct
{
void foo() {
// use SomeStruct
}
}
void broken()
{
void function() foo =
foo(); // runtime error, isn't actually safe uses wrong
calling convention as well
}
Not really lack of feature so much as there exists broken code.
This has been valid code for god knows how long. At some point it
was usable in @safe, but it looks you can't take an address of a
member function without "this" as well in safe anymore.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, August 24, 2018 4:44:31 PM MDT Dominikus Dittes Scherkl via Digitalmars-d wrote: > You're underestimating the benefits. It's not just to be > eventually slightly faster. It makes @safe versions possible, > this in turn avoids a lot of @trusted calls, so reduces review > effort. It allows also to develop own kernels (for maybe new > hardware) without needing a c-toolchain an it makes D more self > contained. There are certainly more advantages. And if you don't > like it, the c stuff remains there for you to use. It doesn't reduce the number of @trusted calls at all. Best case, you're talking about using @trusted with syscall instead of a function like stat, and for many of the C functions, it's perfectly reasonable to just mark their bindings as @trusted, eliminating the need to use @trusted yourself entirely. You're not reducing the number of uses of @trusted. All you get out of it is that then you've written the OS code using @system rather than relying on the C programmers to do their job when writing basic OS stuff. You then might catch a problem writing that code that someone writing the same code in C wouldn't have caught as easily, but that's it. You're bypassing a _heavily_ used and tested piece of code written by experts just because you want to be able to have @safe verify it, or because you want to avoid it simply because it's C. And because of the prevalence of pointers to local addresses in such code, there's a pretty good chance that a lot of it will have to be hand-vetted and marked with @trusted anyway instead of being able to take advantage of @safe. And if someone wants to write an OS in D, then fine. They can do it. There's nothing about our current approach that stops them. As I understand it, there have already been a couple of projects to do exactly that, but you're not going to replace the major OSes with D any time soon (or likely ever), and the vast majority of D code is going to be interacting with those OSes - most of which provide their public APIs via C (many via the same POSIX API). By using libc like everyone else, we get to take advantage of that work and work with a more portable API, risking fewer bugs in the process. Right now, we don't have to test all of the bindings in druntime to death, because they're just bindings, and we can rely on the libc guys to have done their job, whereas we would then be doing their jobs if we insisted on bypassing libc. It's a maintenance nightmare for little to no benefit. I don't want to have to deal with it as a maintainer, and I don't want programs that I write to be bypassing libc using a custom implementation just because someone decided that they didn't like the fact that it was in C instead of D. - Jonathan M Davis
Re: D is dead
On 8/24/18 6:16 PM, Jonathan M Davis wrote: On Friday, August 24, 2018 7:46:57 AM MDT Mike Franklin via Digitalmars-d wrote: On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote: I think that you're crazy. No, I just see more potential in D than you do. To be clear, I'm not calling you crazy in general. I'm calling the idea of bypassing libc to call syscalls directly under any kind of normal circumstances crazy. There is tons of work to be done around here to improve D, and IMHO, reimplementing OS functions just because they're written in C is a total waste of time and an invitation for bugs - in addition to making the druntime code that much less portable, since it bypasses the API layer that was standardized for POSIX systems. Let me say that I both agree with Jonathan and with Mike. I think we should reduce Phobos dependence on the user-library part of libc, while at the same time, not re-inventing how the OS bindings are called. For example, using Martin's std.io library instead of . I really don't want to see dlang have to maintain posix system calls on all supported OSes when that's already being done for us. Windows makes this simpler -- the system calls are separate from the C runtime. It would be nice if Posix systems were that way, but it's both silly to reinvent the system calls (they are on every OS anyways, and in shared-library form), and a maintenance nightmare. For platforms that DON'T have an OS abstraction, or it's split out from the user library part of libc, it would be perfectly acceptable to write a shim there if needed. I'd be surprised if it's not already present in C form. -Steve
Re: Patterns to avoid GC with capturing closures?
On Friday, 24 August 2018 at 15:18:13 UTC, Peter Alexander wrote:
I can write scaleAll like this:
auto scaleAll(int[] xs, int m) @nogc {
return repeat(m).zip(xs).map!(mx => mx[0] * mx[1]);
}
So that repeat(m) stores m, but it is quite hacky to work like
this.
Here's a spoonful of sugar to help that go down easier:
https://run.dlang.io/is/8lTmZg
Re: "The D Way" to run a sequence of executables?
On Friday, August 24, 2018 11:36:25 AM MDT Matthew OConnor via Digitalmars- d-learn wrote: > I'd like to run a sequence of executables with something like > std.process.execute, but I would like the sequence to error out > if one of the executables returns a non-zero return code. What is > the recommended way to do this? A wrapper that throws exceptions? > Checking return values? AFAIK, you're only two options are to either make consequitive calls to one of the execute family of functions where you check the return code and act accordingly (whether you use exceptions to deal with it is up to you, but either way, you have to check the result of each call to execute, since it doesn't throw), or you use one of the functions which uses the shell (e.g. executeShell) and write it out the way you would on the command-line with ||'s and/or &&'s. Either way, Phobos doesn't provide any functions that are specifically for calling a sequence of executables rather than just one. So, you're going to have to figure out how to put that together in a way that works best for you and what you're doing given what std.process has. - Jonathan M Davis
Re: Embrace the from template?
On 8/24/18 6:29 PM, Jonathan Marler wrote: On Friday, 24 August 2018 at 20:36:06 UTC, Seb wrote: On Friday, 24 August 2018 at 20:04:22 UTC, Jonathan Marler wrote: I'd gladly fix it but alas, my pull requests are ignored :( They aren't! It's just that sometimes the review queue is pretty full. I have told you before that your contributions are very welcome (like they are from everyone else) and if there's anything blocking your productivity you can always ping me on Slack. Don't tempt me to start contributing again :) I had months where I got almost no attention on a dozen or so PRs...I love to contribute but I'd have to be mad to continue throwing dozens of hours of work away. I thought we were going to get the unittest import problem solved, but then you closed the PR abruptly (we did get phobos to stop compiling with -dip1000 so we could work around the linker errors). In any case, I can understand the feeling of frustration. I also have no power to force others to review who make important decisions, so I can't guarantee it won't happen again. I myself would love to have the time to get more reps with the compiler code, but I'm hopelessly lost when reviewing dmd stuff currently. If the problem gets solved I'll willingly start working again, but I don't think anything's changed. I'll just be blunt -- I don't think "the problem" is ever going to get solved. This is the world of volunteer OSS development, and nobody has control over anyone's time but themselves. Things could go great for a month and then stagnate. If you hit on something that some VIP is looking to solve, it may get a lot of attention. But I would recommend letting a PR stay open, pinging reviewers, etc. instead of closing them. Don't give up hope that it will not ever be merged. -Steve
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 8/24/2018 12:42 PM, tide wrote: Some problems require new features like how taking the address of a member function without an object returns a function pointer, but requires a delegate where C++ has member function pointers, D just has broken unusable code. Or old features that were implemented poorly (C++ mangling for example). How to do member function pointers in D: https://www.digitalmars.com/articles/b68.html
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 22:16:25 UTC, Jonathan M Davis wrote: On Friday, August 24, 2018 7:46:57 AM MDT Mike Franklin via Digitalmars-d wrote: On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote: > I think that you're crazy. No, I just see more potential in D than you do. To be clear, I'm not calling you crazy in general. I'm calling the idea of bypassing libc to call syscalls directly under any kind of normal circumstances crazy. There is tons of work to be done around here to improve D, and IMHO, reimplementing OS functions just because they're written in C is a total waste of time and an invitation for bugs - in addition to making the druntime code that much less portable, since it bypasses the API layer that was standardized for POSIX systems. It's the kind of thing that's going to cause us way more work, more bugs, and make us that much less compatible with existing libraries. And for what? To _maybe_ get slightly better performance (which you probably won't get)? I honestly think that trying to bypass libc to talk to the kernel directly is actively worse than just using libc much as it would be great if we somehow lived in a world where every library we used was written in D. But the reality of the matter is that there is a _lot_ out there already written in C where it simply makes no sense to try to replace it. We're always going to need to interoperate with C unless we somehow convince all of the C developers to at least switch to -betterC (which obviously isn't happening). - Jonathan M Davis You're underestimating the benefits. It's not just to be eventually slightly faster. It makes @safe versions possible, this in turn avoids a lot of @trusted calls, so reduces review effort. It allows also to develop own kernels (for maybe new hardware) without needing a c-toolchain an it makes D more self contained. There are certainly more advantages. And if you don't like it, the c stuff remains there for you to use.
Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like
On Friday, 24 August 2018 at 20:59:34 UTC, aliak wrote:
THis is true. And might be interesting to try out actually. Can
you access the types in a SumType via index?
I'm thinking because Optional behaves like a range, and I guess
I'd define a SumType!(T, None), then a rough outline may be:
struct None {}
immutable none = None();
struct(T) {
SumType(T, None) opt;
T front() {
return opt[0]; // what to do here?
}
}
Or I guess I should maybe do it like this?:
return opt.match!(
(T val) => val,
(None) => T.init,
);
I think this is probably the best way:
@property T front() {
return opt.match!(
(T val) => val,
(None) {
assert(false, "called .front on an empty range");
return T.init; // for return type inference
}
);
}
You could also do it with `tryMatch` and
`std.exception.assertNotThrown`. It makes the code a little
nicer, but involving exceptions at all seemed like unnecessary
overhead to me.
Re: Embrace the from template?
On Friday, 24 August 2018 at 20:36:06 UTC, Seb wrote: On Friday, 24 August 2018 at 20:04:22 UTC, Jonathan Marler wrote: I'd gladly fix it but alas, my pull requests are ignored :( They aren't! It's just that sometimes the review queue is pretty full. I have told you before that your contributions are very welcome (like they are from everyone else) and if there's anything blocking your productivity you can always ping me on Slack. Don't tempt me to start contributing again :) I had months where I got almost no attention on a dozen or so PRs...I love to contribute but I'd have to be mad to continue throwing dozens of hours of work away. If the problem gets solved I'll willingly start working again, but I don't think anything's changed.
Re: Embrace the from template?
On Friday, 24 August 2018 at 18:34:20 UTC, Daniel N wrote: On Friday, 24 August 2018 at 12:06:15 UTC, Anton Fediushin wrote: I just published it on the dub registry in public domain (I hope Daniel Nielsen is ok with that. After all, it's just 3 lines of code) Package page: https://from.dub.pm/ I'm fine with it, public domain is great! Although I would greatly prefer object.d since I don't use dub myself. FYI Andrei has an open pull request: https://github.com/dlang/druntime/pull/1756 But it's stalled due to a bug: https://issues.dlang.org/show_bug.cgi?id=17181 Me too. I've found from meanwhile defined in so many different places, we really need it to be part of standard D. I don't get it why it can't be merged just because of a bug that affects also other local imports. Ok, with the bug it can't be used everywhere in phobos, but it remains useful in so many other places.
Re: Cross compile windows programs on linux
On Friday, August 24, 2018 3:28:37 PM MDT Nick Sabalausky (Abscissa) via Digitalmars-d-learn wrote: > On 08/24/2018 12:30 PM, John Burton wrote: > > On Friday, 24 August 2018 at 15:26:30 UTC, kinke wrote: > >> On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote: > >>> Is in the subject. Are there any cross compilers that will run on a > >>> linux system but compile D code using Win32 into a windows .exe file, > >>> preferably 64 bit? I can find hints of cross compilers but not really > >>> seen anything packaged up? > >> > >> See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org. > > > > Oh thank you. > > I did a search but somehow missed that > > You could probably also just run the windows version of the compiler > under wine. I think I remember hearing of people doing that. That will probably work, but actually running the program that you build is another story. I actually originally developed the Windows-specific portion of std.datetime using wine, and I ended up with some bugs in my code, because the way that wine behaved when running it did not actually match what Windows did like it was supposed to. However, what dmd itself does has so little to do with the Win32 API that building code using dmd shouldn't be a problem. - Jonathan M Davis
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, August 24, 2018 7:46:57 AM MDT Mike Franklin via Digitalmars-d wrote: > On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote: > > I think that you're crazy. > > No, I just see more potential in D than you do. To be clear, I'm not calling you crazy in general. I'm calling the idea of bypassing libc to call syscalls directly under any kind of normal circumstances crazy. There is tons of work to be done around here to improve D, and IMHO, reimplementing OS functions just because they're written in C is a total waste of time and an invitation for bugs - in addition to making the druntime code that much less portable, since it bypasses the API layer that was standardized for POSIX systems. It's the kind of thing that's going to cause us way more work, more bugs, and make us that much less compatible with existing libraries. And for what? To _maybe_ get slightly better performance (which you probably won't get)? I honestly think that trying to bypass libc to talk to the kernel directly is actively worse than just using libc much as it would be great if we somehow lived in a world where every library we used was written in D. But the reality of the matter is that there is a _lot_ out there already written in C where it simply makes no sense to try to replace it. We're always going to need to interoperate with C unless we somehow convince all of the C developers to at least switch to -betterC (which obviously isn't happening). - Jonathan M Davis
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Fri, Aug 24, 2018 at 09:48:33PM +, Meta via Digitalmars-d wrote: > On Friday, 24 August 2018 at 21:43:45 UTC, Steven Schveighoffer wrote: > > According to this comment: > > https://github.com/dlang/phobos/pull/5291#issuecomment-360929553 > > > > There was no way to get a deprecation to work. > > > > When we can't get a deprecation to work, we face a hard decision -- > > actually break code right away, print lots of crappy errors, or just > > leave the bug unfixed. > > > > -Steve > > Ah, that's unfortunate. Damned if you do, damned if you don't. > > I still don't agree with making a breaking change to Phobos. I'm kinda on the fence about this, actually. OT1H I actually *want* D to have breaking changes that will give longer-term benefits, like removing cruft that shouldn't have been there in the first place, or straightening out decisions that in retrospect were poorly made. But OTOH I have also experienced the annoyance of random code breaking upon compiler upgrades, especially if the breakage happens in old code that I don't quite remember the intricacies of, or worse, in 3rd party code whose upstream has become non-responsive or has abandoned the project, or it's just too urgent to wait for upstream to address the problem, which I then have to debug and fix myself. I don't know how to reconcile these two. Perhaps if we had the manpower, we could maintain older versions for long enough to allow users to gradually rewrite to work with newer compilers, while the development branch can be bolder in making breaking changes that ultimately will result in a better, cleaner language. But I doubt we have the kind of manpower it takes to maintain something like that. T -- People demand freedom of speech to make up for the freedom of thought which they avoid. -- Soren Aabye Kierkegaard (1813-1855)
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 21:53:18 UTC, H. S. Teoh wrote: I think it's clear by now that most of D's woes are not really technical in nature, but managerial. Agreed. I'm not sure how to improve this situation, since I'm no manager type either. Money is the only feasible solution IMO. How many people posting on this forum would quit their job tomorrow and solely contribute to OSS and/or work on their own projects if money wasn't an issue? The majority of people don't like being told what to do, and only want to work on what they're interested in. The only way to get them to work on something they're not interested in is to pay them.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Fri, Aug 24, 2018 at 09:12:40PM +, Meta via Digitalmars-d wrote: > On Friday, 24 August 2018 at 17:12:53 UTC, H. S. Teoh wrote: > > I got bitten by this just yesterday. Update dmd git master, update > > vibe.d git master, now my vibe.d project doesn't compile anymore due > > to some silly string.d error somewhere in one of vibe.d's > > dependencies. :-/ > > While we're airing grievances about code breakages, I hit this little > gem the other day, and it annoyed me enough to complain about it: > https://github.com/dlang/phobos/pull/5291#issuecomment-414196174 > > What really gets me is the actual removal of the symbol. If it had > been left there with a deprecation message, I would've caught the > problem immediately at the source and fixed it in a few minutes. > Instead, I spent an hour or so tracing "execution" paths through a > codebase that I'm unfamiliar with to figure out why a static if branch > is no longer being taken. Ironically, I was the one who pushed the merge button on that PR. :-/ Mea culpa. But we had discussed this particular change at length before, and it was clear that there was no clean way to effect the change; every approach would lead to a mess. I forget the details now, but I think Jonathan's approach was the least of the evils among the options we had. Though you do have an extremely good point about deprecating it first, or somehow warning the user in some way, so that when things do break, the solution is clear and doesn't require hours of tracing through 3rd party code. I'm not sure if it was actually possible for deprecation to work on this particular change, but in any case, we should have tried harder to communicate the cause (and possible solution(s)) of the breakage to users. > On the topic of this thread... I was a bit confused with Dicebot's > decision to leave at the time, because he seemed to like dip1000 but > then later had a heel turn and left. Looking back through newsgroup > threads, it seems like it was mostly that he disagreed with the > project management side of things (which he also brings up in his > article); an incomplete version of the feature being merged with code > in the main branch having to be adjusted to support it. People have > complained about it before, and it's distressingly common in D. Why > it's not done in a feature branch and then merged in, I don't know, > but I do agree with his objections. I think it's clear by now that most of D's woes are not really technical in nature, but managerial. I'm not sure how to improve this situation, since I'm no manager type either. It's a known problem among techies that we tend to see all problems as technical in nature, or solvable via technical solutions, when in reality what's actually needed is someone with real management skills. Hammer and nail, and all that, y'know. Unfortunately, we techies also tend to resist non-technical "interference", especially from non-techies (like manager types). I used to have that attitude too (and probably still do to some extent), and only with age did I begin realizing this about myself. It's not an easy problem to fix in practice, especially in a place like here, where we're driven primarily by the technical aspects of D, and for the most part outside of any financial or other motivations that might have served to moderate things a little. T -- Some days you win; most days you lose.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 21:43:45 UTC, Steven Schveighoffer wrote: According to this comment: https://github.com/dlang/phobos/pull/5291#issuecomment-360929553 There was no way to get a deprecation to work. When we can't get a deprecation to work, we face a hard decision -- actually break code right away, print lots of crappy errors, or just leave the bug unfixed. -Steve Ah, that's unfortunate. Damned if you do, damned if you don't. I still don't agree with making a breaking change to Phobos.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 8/24/18 5:12 PM, Meta wrote: On Friday, 24 August 2018 at 17:12:53 UTC, H. S. Teoh wrote: I got bitten by this just yesterday. Update dmd git master, update vibe.d git master, now my vibe.d project doesn't compile anymore due to some silly string.d error somewhere in one of vibe.d's dependencies. :-/ While we're airing grievances about code breakages, I hit this little gem the other day, and it annoyed me enough to complain about it: https://github.com/dlang/phobos/pull/5291#issuecomment-414196174 What really gets me is the actual removal of the symbol. If it had been left there with a deprecation message, I would've caught the problem immediately at the source and fixed it in a few minutes. Instead, I spent an hour or so tracing "execution" paths through a codebase that I'm unfamiliar with to figure out why a static if branch is no longer being taken. According to this comment: https://github.com/dlang/phobos/pull/5291#issuecomment-360929553 There was no way to get a deprecation to work. When we can't get a deprecation to work, we face a hard decision -- actually break code right away, print lots of crappy errors, or just leave the bug unfixed. -Steve
Re: Cross compile windows programs on linux
On 08/24/2018 12:30 PM, John Burton wrote: On Friday, 24 August 2018 at 15:26:30 UTC, kinke wrote: On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote: Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up? See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org. Oh thank you. I did a search but somehow missed that You could probably also just run the windows version of the compiler under wine. I think I remember hearing of people doing that.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 17:12:53 UTC, H. S. Teoh wrote: I got bitten by this just yesterday. Update dmd git master, update vibe.d git master, now my vibe.d project doesn't compile anymore due to some silly string.d error somewhere in one of vibe.d's dependencies. :-/ While we're airing grievances about code breakages, I hit this little gem the other day, and it annoyed me enough to complain about it: https://github.com/dlang/phobos/pull/5291#issuecomment-414196174 What really gets me is the actual removal of the symbol. If it had been left there with a deprecation message, I would've caught the problem immediately at the source and fixed it in a few minutes. Instead, I spent an hour or so tracing "execution" paths through a codebase that I'm unfamiliar with to figure out why a static if branch is no longer being taken. On the topic of this thread... I was a bit confused with Dicebot's decision to leave at the time, because he seemed to like dip1000 but then later had a heel turn and left. Looking back through newsgroup threads, it seems like it was mostly that he disagreed with the project management side of things (which he also brings up in his article); an incomplete version of the feature being merged with code in the main branch having to be adjusted to support it. People have complained about it before, and it's distressingly common in D. Why it's not done in a feature branch and then merged in, I don't know, but I do agree with his objections.
Re: Optional and NotNull version 0.5.0 - swift optional like and scala option like
On Wednesday, 22 August 2018 at 22:49:52 UTC, Paul Backus wrote:
On Wednesday, 22 August 2018 at 22:11:05 UTC, aliak wrote:
On Monday, 20 August 2018 at 19:52:53 UTC, jmh530 wrote:
It's interesting that both sumtype and optional have match
templates. Maybe scope to combine these projects?
That'd be cool. Optional uses .match on a "some" or "none"
range, while SumType uses it on a union. So ideas on how to go
about it?
In theory, Optional(T) could be implemented as a wrapper around
SumType!(T, None), which would let it reuse SumType's match
method. I'm not sure if it'd be worth the effort to convert at
this point, though.
THis is true. And might be interesting to try out actually. Can
you access the types in a SumType via index?
I'm thinking because Optional behaves like a range, and I guess
I'd define a SumType!(T, None), then a rough outline may be:
struct None {}
immutable none = None();
struct(T) {
SumType(T, None) opt;
T front() {
return opt[0]; // what to do here?
}
}
Or I guess I should maybe do it like this?:
return opt.match!(
(T val) => val,
(None) => T.init,
);
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 24.08.2018 22:46, Timon Gehr wrote: s->*mptr(args) you write mptr(s, args) Oops. Wither the first code sample should be s.*mptr(args) or the second code sample should be mptr(*s, args)
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 24.08.2018 21:42, tide wrote: Some problems require new features like how taking the address of a member function without an object returns a function pointer, but requires a delegate That is indeed broken behavior (and I think there is a DIP to fix it), but member function pointers are not really a necessary language feature. where C++ has member function pointers, D just has broken unusable code. You can use a T function(ref S, Args) in place of a T (S::*)(Args) (for S a value type, otherwise you don't need the ref). Then, instead of auto mptr = ::foo; you write auto mptr = (ref S s, Args args) => s.foo(args); (This is a bit more typing, but it can be automated, such that you only write getMPtr!(S.foo) or similar.) instead of s->*mptr(args) you write mptr(s, args) The syntax is more obvious, it is more general, and at least some C++ compilers will do the same thing under the hood.
Re: Parallelizing factorial computation
On Friday, 24 August 2018 at 13:04:47 UTC, Uknown wrote: I was quite surprised by the fact that parallel ran so much slower than recursive and loop implementations. Does anyone know why? n = 100 is too small to see parallelism gains. Try n = 1 https://run.dlang.io/is/XDZTSd
Re: Embrace the from template?
On Friday, 24 August 2018 at 20:04:22 UTC, Jonathan Marler wrote: I'd gladly fix it but alas, my pull requests are ignored :( They aren't! It's just that sometimes the review queue is pretty full. I have told you before that your contributions are very welcome (like they are from everyone else) and if there's anything blocking your productivity you can always ping me on Slack.
Re: Embrace the from template?
On Friday, 24 August 2018 at 13:54:51 UTC, Jonathan Marler wrote: Good to know others are using it. Of course making it a core part of the language would mean that IDEs would be free to add support for it, whether it was added to `object.d` or with some other means such as a new syntax, i.e. (import std.stdio).writefln(...) I didn't quite understand your last point. Adding `from` to `object.d` wouldn't make it a keyword, it would still be an identifier. And you could still use it as an identifier in your own code. haha oops, complete brain fart :p - you're correct on both accounts.
Re: D is dead
On Thursday, 23 August 2018 at 11:02:31 UTC, Mike Franklin wrote: On Thursday, 23 August 2018 at 10:41:03 UTC, Jonathan M Davis wrote: Languages pretty much always get more complicated over time, and unless we're willing to get rid of more stuff, it's guaranteed to just become more complicated over time rather than less. "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery I think that's actually a mistranslation from what he actually said, but it's still quite good. Liberties were taken there, but it's probably more applicable to this situation than a lot of the times C/Unix beards try to play it as though their tech of choice is beyond culpability. For context, he's talking about the process of aeronautical engineering and the thrust of this statement is really commentary on effort and elegance. A little before that, he talks about the grand irony that so much thoughtful effort and design goes into refining things so they're as simple as possible. But "simple" is relative to the thing and the task (my understanding is that "simple" kind of conflates "reliable" here, too). So this is where he rightly acknowledges that the process of refinement isn't a waste for what it removes even though it's often much greater than the effort to create something in the first place. It's wrapped in a broader understanding that you have to have something that works at all before you can streamline it. -Wyatt
Re: Embrace the from template?
On Friday, 24 August 2018 at 18:34:20 UTC, Daniel N wrote: On Friday, 24 August 2018 at 12:06:15 UTC, Anton Fediushin wrote: I just published it on the dub registry in public domain (I hope Daniel Nielsen is ok with that. After all, it's just 3 lines of code) Package page: https://from.dub.pm/ I'm fine with it, public domain is great! Although I would greatly prefer object.d since I don't use dub myself. FYI Andrei has an open pull request: https://github.com/dlang/druntime/pull/1756 But it's stalled due to a bug: https://issues.dlang.org/show_bug.cgi?id=17181 Thanks. This PR is year and a half old so I'm not sure if we'll see it merged this year at all. Fingers crossed.
Re: Embrace the from template?
On Friday, 24 August 2018 at 13:48:09 UTC, Jonathan Marler wrote: On Friday, 24 August 2018 at 12:06:15 UTC, Anton Fediushin wrote: On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote: [...] There's no reason to mess with `object.d` or add it to phobos. Just make a dub package and use it! I just published it on the dub registry in public domain (I hope Daniel Nielsen is ok with that. After all, it's just 3 lines of code) Package page: https://from.dub.pm/ Have a good day and don't overthink simple things, Anton It's good to see there are people who are still optimistic about dub. I remember that same feeling so many years ago :) It got better, I think. It's far from being perfect but there's no way I'm building something like vibe-d manually or with *shivers* make.
Re: Embrace the from template?
On Friday, 24 August 2018 at 18:34:20 UTC, Daniel N wrote:I don't use dub myself. On Friday, 24 August 2018 at 18:34:20 UTC, Daniel N wrote: FYI Andrei has an open pull request: https://github.com/dlang/druntime/pull/1756 Oh well I guess great minds think alike :) Too bad it's been stalled due to a bug. I'd gladly fix it but alas, my pull requests are ignored :(
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote: On 8/24/2018 6:04 AM, Chris wrote: For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. Every programmer who says this also demands new (and breaking) features. Some problems require new features like how taking the address of a member function without an object returns a function pointer, but requires a delegate where C++ has member function pointers, D just has broken unusable code. Or old features that were implemented poorly (C++ mangling for example).
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote: On 8/24/2018 6:04 AM, Chris wrote: For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. Every programmer who says this also demands new (and breaking) features. There's also who demands less (and may be breaking) features.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 8/24/2018 6:04 AM, Chris wrote: For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. Every programmer who says this also demands new (and breaking) features.
Re: Beta 2.082.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/17/2018 10:01 PM, Martin Nowak wrote: > Glad to announce the first beta for the 2.082.0 release, ♥ to the > 47 contributors for this release. > > http://dlang.org/download.html#dmd_beta > http://dlang.org/changelog/2.082.0.html > > As usual please report any bugs at https://issues.dlang.org Second Beta live now. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAluAW24ACgkQsnOBFhK7 GTn/Dg/8Daattu9zLZL8C7KdEjuMZnJoJk+SeXsFdbDHa3Y1mndRuu+Fq/m1xSCp gbBcnVedD64N4iLfSP2rvJusbcVR9s7F+Q2YqcYPsa7AKNTjTUMgrqCD71DbFx1l Zq+HEnOmdS5ZabcHVl9zt29w91Y4uGQXWhKKmxq9l1YCmR4Y7dIW2xYNmNfjuNFQ c5yQk/+UrLyxQmpiR1g+E/NChUJYwG8fhYFtUDHChSksvCxqZkgUUyONM+oV9g5J fJ04S0xUSVhf2m++q8TaHBw3NexG0oI/Rs78yLY31l/9BRU6bvgZEd0QBBSyUWRK c8vx+SvxsGnzgK1N+xOupug1IWHg1fN/nUMmNYm5F2dyHAp0oeW8G/OqAT8DtHYp xD/Tam+vHaPPq/jl1POPECz2hMtT+yd2wRsL/+2WrO6FiE5l7LayVCmAsLtqqHjn UplpjhObmt/VstvgaFzobI5+C0EzbJJUwe+S+ErhVFcazud6fjb3SOnwA3cSuJXt rHi9Jzbwrk+T15JjKF1LZf/+r99Awi9igSRAA3Qa+Qx/CXCu845vyTG0Uodqx65E 2QTS4IItdrR6sNL44w38JJdhfle8O6xFgSX6wLSbJ7GTGVNclTaIMuHi+lW/6ai2 XdmJg/eHoXWzWW0WGq5peb5MeT4OkqGWKe1JhICU+DU5WP7Wmt8= =BLdX -END PGP SIGNATURE-
Re: D is dead
On 8/23/2018 6:57 PM, Shachar Shemesh wrote: At this point I can either use the work-around I already have and (try to, obviously unsuccessfully) forget about it, file a bug report that will be (justifiably) ignored because no-one else can reproduce it, or spend an unknown amount of time (two days would probably be low-balling at this point) in trying to get this to reproduce on a watered down version of the code. Which would you pick? You should file a bug report, even with no example. It'll still be a clue, sometimes I can find problems without an example. But still, assuming it is a compiler bug is a dodgy practice. I've drilled down on a lot of bug reports that the submitter was absolutely sure was a compiler bug, that turned out to be invalid.
Re: Cross compile windows programs on linux
On Friday, 24 August 2018 at 16:30:56 UTC, John Burton wrote: On Friday, 24 August 2018 at 15:26:30 UTC, kinke wrote: On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote: Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up? See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org. Oh thank you. I did a search but somehow missed that LLD has a nasty bug when using large static data members. https://bugs.llvm.org/show_bug.cgi?id=38645 I got access violations in the resulting binary when using it for linking complex apps. Be aware.
Re: Embrace the from template?
On Friday, 24 August 2018 at 12:06:15 UTC, Anton Fediushin wrote: I just published it on the dub registry in public domain (I hope Daniel Nielsen is ok with that. After all, it's just 3 lines of code) Package page: https://from.dub.pm/ I'm fine with it, public domain is great! Although I would greatly prefer object.d since I don't use dub myself. FYI Andrei has an open pull request: https://github.com/dlang/druntime/pull/1756 But it's stalled due to a bug: https://issues.dlang.org/show_bug.cgi?id=17181
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 17:12:53 UTC, H. S. Teoh wrote: [snip] This is probably completely unrealistic, but I've been thinking about the possibility of adding *all* D codebases to the CI infrastructure, including personal projects and what-not. Set it up such that any breakages send a notification to the author(s) in advance of a PR being checked in, so that they have time to respond. I'm not sure how this would work in practice since you have to deal with dead / unmaintained projects and/or slow/unresponsive authors, and some PRs you might want to push through regardless of breakage. But it would be nice to know exactly how much code we're breaking out there. A worthy goal. If you could get some download statistics from dub (i.e. like total downloads past month), then you could probably create a few buckets and rules so you could make sure that there aren't breakages in the most downloaded projects while not worrying about dead projects that aren't being downloaded anyway.
Re: How to best implement a DSL?
On Saturday, 28 July 2018 at 17:01:22 UTC, rikki cattermole wrote: You missed my point here. There is nothing special about parsing at CTFE, you're just restricted as to the language features you can use (e.g. no extern's), that's it. Is there an example of how this could be done?
"The D Way" to run a sequence of executables?
I'd like to run a sequence of executables with something like std.process.execute, but I would like the sequence to error out if one of the executables returns a non-zero return code. What is the recommended way to do this? A wrapper that throws exceptions? Checking return values?
Re: D is dead
On 8/24/18 10:02 AM, David Nadlinger wrote: On Friday, 24 August 2018 at 03:53:38 UTC, David Nadlinger wrote: […] All this is not to say that nothrow constructors aren't a good idea, though. This was meant to say nothrow DEstructors, as hopefully obvious from context. —David I was about to throw down some constructive criticism, but you caught it early ;)
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Fri, Aug 24, 2018 at 04:58:12PM +, jmh530 via Digitalmars-d wrote: > On Friday, 24 August 2018 at 16:00:10 UTC, bachmeier wrote: > > > > You simply can't share a D program with anyone else. It's an endless > > cycle of compiler upgrades and figuring out how to fix code that > > stops compiling. I got bitten by this just yesterday. Update dmd git master, update vibe.d git master, now my vibe.d project doesn't compile anymore due to some silly string.d error somewhere in one of vibe.d's dependencies. :-/ In the past this appeared to be a problem with out-of-date build targets, that was fixed by rebuilding everything from scratch. But this time appears to be something else... > > It doesn't work for those of us that are busy. Why there is not a > > stable branch with releases once a year is quite puzzling. (And no, > > "just use the old compiler" is not an answer.) > > ...hmm...I can't recall anyone ever suggesting to have a stable > branch. It's a good idea. > > That being said, I see forward progress on reducing breakage. The CI > infrastructure has improved a lot and there are a number of dub > projects that also get checked. This is probably completely unrealistic, but I've been thinking about the possibility of adding *all* D codebases to the CI infrastructure, including personal projects and what-not. Set it up such that any breakages send a notification to the author(s) in advance of a PR being checked in, so that they have time to respond. I'm not sure how this would work in practice since you have to deal with dead / unmaintained projects and/or slow/unresponsive authors, and some PRs you might want to push through regardless of breakage. But it would be nice to know exactly how much code we're breaking out there. Part of this is my suspicion that certain big, scary breaking changes actually may not have that big of an impact as we imagine, and could be worthwhile in the long run to get rid of wrinkles in the language and end up with a better, cleaner design that will last longer into the future. But I'm probably just dreaming. T -- VI = Visual Irritation
Re: D is dead
On Friday, 24 August 2018 at 03:53:38 UTC, David Nadlinger wrote: […] All this is not to say that nothrow constructors aren't a good idea, though. This was meant to say nothrow DEstructors, as hopefully obvious from context. —David
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 16:00:10 UTC, bachmeier wrote: You simply can't share a D program with anyone else. It's an endless cycle of compiler upgrades and figuring out how to fix code that stops compiling. It doesn't work for those of us that are busy. Why there is not a stable branch with releases once a year is quite puzzling. (And no, "just use the old compiler" is not an answer.) ...hmm...I can't recall anyone ever suggesting to have a stable branch. It's a good idea. That being said, I see forward progress on reducing breakage. The CI infrastructure has improved a lot and there are a number of dub projects that also get checked.
[Issue 19187] __traits(compiles) segfaults on access to partially undefined overload set from import
https://issues.dlang.org/show_bug.cgi?id=19187 --- Comment #1 from FeepingCreature --- https://github.com/dlang/dmd/pull/8613 pr up --
[Issue 19187] __traits(compiles) segfaults on access to partially undefined overload set from import
https://issues.dlang.org/show_bug.cgi?id=19187 FeepingCreature changed: What|Removed |Added Severity|enhancement |normal --
Re: Cross compile windows programs on linux
On Friday, 24 August 2018 at 15:26:30 UTC, kinke wrote: On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote: Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up? See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org. Oh thank you. I did a search but somehow missed that
[Issue 19187] New: __traits(compiles) segfaults on access to partially undefined overload set from import
https://issues.dlang.org/show_bug.cgi?id=19187
Issue ID: 19187
Summary: __traits(compiles) segfaults on access to partially
undefined overload set from import
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: default_357-l...@yahoo.de
Repro:
$ cat test1.d
import test2;
enum test = __traits(compiles, test2.foo);
$ cat test2.d
template test() { }
alias foo = test;
alias foo = NONEXISTENT;
$ dmd test1.d
Segmentation fault (core dumped)
$
--
Re: Fast OpenGL-based visualization engine mainly for animated two-dimensional graphs
24.08.2018 17:38, Per Nordlöw пишет: On Friday, 24 August 2018 at 14:34:46 UTC, Per Nordlöw wrote: On Friday, 24 August 2018 at 14:03:08 UTC, drug wrote: imgui, but now I'm replacing it by nuklear. Is nuklear a software project that can be found somewhere? Ahh, I presume you mean - https://github.com/vurtun/nuklear - https://github.com/mogud/nukleard I use dpp to make binding to nuklear, my second attempt https://github.com/drug007/beholder In general I'd like to make an utility that can read some files and draw their content. First of all I'm interested in time series visualization. Also it would be nice to have something like simple form of ParaView https://www.paraview.org
Re: GDC with D frontend 2.081.2
On Friday, 24 August 2018 at 05:35:13 UTC, Eugene Wissner wrote: I prepared GDC/GCC 7.3.0 binaries for x86-64 Linux built on Ubuntu 18.04: Thank you, this is very important work! I'll add a gdc package to GNU Guix (the packager for GNU) sometime soon.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On 25/08/2018 4:00 AM, bachmeier wrote: On Friday, 24 August 2018 at 13:04:28 UTC, Chris wrote: For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. I've started moving some things to other languages myself. The problem is that D, in its current form, has a process that is specially optimized to make it as unusable as possible. 1. There will be no D version 3. 2. There will be no major breaking changes like autodecoding unless we think they're important (and there are no guidelines on what's important, just whatever comes to someone's mind on a particular day). 3. There are many trivial breaking changes made, and they can come in any release. 4. The more releases the better. You simply can't share a D program with anyone else. It's an endless cycle of compiler upgrades and figuring out how to fix code that stops compiling. It doesn't work for those of us that are busy. Why there is not a stable branch with releases once a year is quite puzzling. (And no, "just use the old compiler" is not an answer.) Hmm, would a every 2 year LTS be reasonable? We're currently doing about 1 major every 2 months now. This can be used for boot strapping purposes too, while keeping the number of compilers required minimal.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 13:04:28 UTC, Chris wrote: For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. I've started moving some things to other languages myself. The problem is that D, in its current form, has a process that is specially optimized to make it as unusable as possible. 1. There will be no D version 3. 2. There will be no major breaking changes like autodecoding unless we think they're important (and there are no guidelines on what's important, just whatever comes to someone's mind on a particular day). 3. There are many trivial breaking changes made, and they can come in any release. 4. The more releases the better. You simply can't share a D program with anyone else. It's an endless cycle of compiler upgrades and figuring out how to fix code that stops compiling. It doesn't work for those of us that are busy. Why there is not a stable branch with releases once a year is quite puzzling. (And no, "just use the old compiler" is not an answer.)
Bitcoin in D
I write code in D to serialize and deserialize bitcoin block headers for educations puropseses as i just start with D, i add some more function and i upload it to github https://github.com/cvsae/bitcoind
Re: Cross compile windows programs on linux
On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote: Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up? See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org.
Re: Patterns to avoid GC with capturing closures?
On 8/24/18 11:18 AM, Peter Alexander wrote:
Consider this code, which is used as an example only:
auto scaleAll(int[] xs, int m) {
return xs.map!(x => m * x);
}
As m is captured, the delegate for map will rightly allocate the closure
in the GC heap.
In C++, you would write the lambda to capture m by value, but this is
not a facility in D.
I can write scaleAll like this:
auto scaleAll(int[] xs, int m) @nogc {
return repeat(m).zip(xs).map!(mx => mx[0] * mx[1]);
}
So that repeat(m) stores m, but it is quite hacky to work like this.
I could write my own range that does this, but this is also not desirable.
Are there any established patterns, libraries, or language features that
can help avoid the GC allocation in a principled way here?
This is somewhat related to a suggestion I had last month:
https://forum.dlang.org/post/pjnue1$olt$1...@digitalmars.com
I also hate to have such a thing allocate. The only scalable solution I
can think of is to write your own range function which has the
appropriate state saved by value. But then you lose all the goodies from
Phobos.
Having a way to capture state and give that state to std.algorithm
ranges would be really cool.
-Steve
Patterns to avoid GC with capturing closures?
Consider this code, which is used as an example only:
auto scaleAll(int[] xs, int m) {
return xs.map!(x => m * x);
}
As m is captured, the delegate for map will rightly allocate the
closure in the GC heap.
In C++, you would write the lambda to capture m by value, but
this is not a facility in D.
I can write scaleAll like this:
auto scaleAll(int[] xs, int m) @nogc {
return repeat(m).zip(xs).map!(mx => mx[0] * mx[1]);
}
So that repeat(m) stores m, but it is quite hacky to work like
this.
I could write my own range that does this, but this is also not
desirable.
Are there any established patterns, libraries, or language
features that can help avoid the GC allocation in a principled
way here?
[Issue 16396] Octal value 08 should result in error
https://issues.dlang.org/show_bug.cgi?id=16396 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Steven Schveighoffer --- oops, I realized this is already fixed! *** This issue has been marked as a duplicate of issue 19059 *** --
[Issue 19059] Invalid integer literal 08 and 09 allowed
https://issues.dlang.org/show_bug.cgi?id=19059 --- Comment #9 from Steven Schveighoffer --- *** Issue 16396 has been marked as a duplicate of this issue. *** --
[Issue 16396] Octal value 08 should result in error
https://issues.dlang.org/show_bug.cgi?id=16396 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer --- PR: https://github.com/dlang/dmd/pull/8612 Note that 008 correctly was diagnosed, due to a quirk in the way the literals were parsed. --
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote: I honestly don't see how attempting to divorce druntime from libc does anything but increase the amount of work that we have to do and increase the likelihood that basic OS functionality is going to be buggy, since we will have then reimplemented it rather than using the same core OS functionality that everyone else is using. +1 Now that the leadership talks about Leverage points http://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/ When rated from 1 to 9 this is a 10, it likely brings negative value. This is even worse if D_SIMD version of AVX is implemented because of that, loosing precious Walter-time (an illiquid asset) for a non-existent fraction of users: also a 10. Whereas merely adding colors to DUB would be a 7. I feel even more uneasy by all that @safe focus, as if native programmers started to care overnight. No, we still don't. People say they do.
Re: Fast OpenGL-based visualization engine mainly for animated two-dimensional graphs
On Friday, 24 August 2018 at 14:34:46 UTC, Per Nordlöw wrote: On Friday, 24 August 2018 at 14:03:08 UTC, drug wrote: imgui, but now I'm replacing it by nuklear. Is nuklear a software project that can be found somewhere? Ahh, I presume you mean - https://github.com/vurtun/nuklear - https://github.com/mogud/nukleard
Re: Fast OpenGL-based visualization engine mainly for animated two-dimensional graphs
On Friday, 24 August 2018 at 14:03:08 UTC, drug wrote: imgui, but now I'm replacing it by nuklear. Is nuklear a software project that can be found somewhere?
Re: D's flaws
On Friday, 24 August 2018 at 13:34:57 UTC, Shachar Shemesh wrote:
On 24/08/18 13:43, nkm1 wrote:
I think Walter was talking more about "scope (failure)
destroy(this)" at the top of all your structs? I don't know if
it has some gotchas, though (as I don't use RAII in D...).
No, unlike what I suggest, that doesn't work without carefully
reviewing every single place you put it to see whether the
constructor actually supports destructing a partially
constructed object.
Shachar
So I guess you're saying you also use "= void" as default
initializer for some things. Otherwise, it's already a
requirement that all default-initialized things should be
destructible...
Yeah, I do agree that these kinds of things are not very well
supported by D. I do not agree that it means the language is
doomed (from a techincal standpoint, at least). Moving in a more
Java-esque direction ("Fast like C++ but with good GC" (so, in
reality, slower than C++ but faster than JVM)) would be a
reasonable strategy for D. Seems like it's not going to happen,
though.
[Issue 15732] std.function partial does not work with function / delegate references
https://issues.dlang.org/show_bug.cgi?id=15732
ZombineDev changed:
What|Removed |Added
CC||petar.p.ki...@gmail.com
--- Comment #3 from ZombineDev ---
Since the https://github.com/dlang/phobos/pull/6497 was merged, a fixed version
of the example above compiles:
auto partial_application () {
// definition of a basic function on 3 parameters using lambda syntax
auto basic = (float a, float b, float c) => a + b / c;
// partially apply value to basic
import std.functional : partial;
alias partial!(basic, 1) apply1;
return // now OK, didn't compile before
}
void main(string[] args) {
auto test = partial_application();
import std.stdio : writeln;
writeln("result: ", test(2, 3)); // 1 + (2/3) = 1.7
}
I see no reason why the GitHub -> Bugzilla integration didn't close the issue
automatically, so I'm closing it manually.
--
Re: Fast OpenGL-based visualization engine mainly for animated two-dimensional graphs
24.08.2018 16:32, Per Nordlöw пишет: Is anybody working on a D-based really fast OpenGL-based visualization engine that supports tessellation of 2d primitives on the GPU? For instance, if I want to animate a huge amount of circles (in a 2d-graph) and I would like to only have to send an array of centers and radiuses and optionally colors, and transparencies to the GPU and then have the circles tessellated and rasterized there. I need this for visualizing and animating huge graphs (potentially millions of nodes) using the powers present in modern day GPUs. I'm interested in both pure-D implementations and wrappers over open-source C/C++ based implementations supported by Linux. Does a Vulkan-based implementation in D provide any benefits with regards to CPU-to-GPU-data-transfer and on-GPU-tesselation? I also need an engine to draw 2d (and 3d later) primitives like you've described above. I have a couple of unfinished attempts to make something like it. My specific is ability to inspect the data using some treeview widget. I considered GTK and Qt (both pure Qt and Qml) and they were too complex to make such user interface. The most suitable variant for me was dear imgui, but now I'm replacing it by nuklear. Generally I have no complete solution to the problem, but I'd like to join efforts to create it.
Re: Embrace the from template?
On Friday, 24 August 2018 at 10:58:29 UTC, aliak wrote: On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote: Ever since I read https://dlang.org/blog/2017/02/13/a-new-import-idiom/ I've very much enjoyed using the new `from` template. It unlocks new idioms in D and have been so useful that I thought it might be a good addition to the core language. I've found that having it in a different place in each project and always having to remember to import it makes it much less ubiquitous for me. One idea is we could add this template to `object.d`. This would allow it to be used from any module that uses druntime without having to import it first. The template itself is also very friendly to "bloat" because it only has a single input parameter which is just a string, extremely easy to memoize. Also, unless it is instantiated, adding it to object.d will have virtually no overhead (just a few AST nodes which would dwarfed by what's already in object.d). It would also be very easy to add, a single PR with 4 lines of code to druntime and we're done. Of course, if we don't want to encourage use of the `from` template then this is not what we'd want. Does anyone have any data/experience with from? All I know is my own usage so feel free to chime in with yours. One of the first things I do after a dub init is create a file called internal.d with the from template in it. My only gripe about this template is it's "autocompletion-able-ness" in IDEs and if that can be handled. I would not want it globally imported though, "from" is quite popular as an identifier and D doesn't let you use keywords as identifiers. Cheers, - Ali Good to know others are using it. Of course making it a core part of the language would mean that IDEs would be free to add support for it, whether it was added to `object.d` or with some other means such as a new syntax, i.e. (import std.stdio).writefln(...) I didn't quite understand your last point. Adding `from` to `object.d` wouldn't make it a keyword, it would still be an identifier. And you could still use it as an identifier in your own code.
Re: Embrace the from template?
On Friday, 24 August 2018 at 12:06:15 UTC, Anton Fediushin wrote: On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote: [...] There's no reason to mess with `object.d` or add it to phobos. Just make a dub package and use it! I just published it on the dub registry in public domain (I hope Daniel Nielsen is ok with that. After all, it's just 3 lines of code) Package page: https://from.dub.pm/ Have a good day and don't overthink simple things, Anton It's good to see there are people who are still optimistic about dub. I remember that same feeling so many years ago :)
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote: I think that you're crazy. No, I just see more potential in D than you do. Mike
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 13:17:11 UTC, Dejan Lekic wrote: On Friday, 24 August 2018 at 13:04:28 UTC, Chris wrote: There is exactly where I am - I am using Java (and more recently Python) for serious stuff. So I'm not alone. I am however in favour of D moving fast (that is why many Java programmers moved to Kotlin/Scala!). [snip] Yes, but D is already there in many ways. Other languages (like Java) are trying to catch up with D. And like in Java, new features should be a bonus, something you may use later, but not break existing code.
Fast OpenGL-based visualization engine mainly for animated two-dimensional graphs
Is anybody working on a D-based really fast OpenGL-based visualization engine that supports tessellation of 2d primitives on the GPU? For instance, if I want to animate a huge amount of circles (in a 2d-graph) and I would like to only have to send an array of centers and radiuses and optionally colors, and transparencies to the GPU and then have the circles tessellated and rasterized there. I need this for visualizing and animating huge graphs (potentially millions of nodes) using the powers present in modern day GPUs. I'm interested in both pure-D implementations and wrappers over open-source C/C++ based implementations supported by Linux. Does a Vulkan-based implementation in D provide any benefits with regards to CPU-to-GPU-data-transfer and on-GPU-tesselation?
Re: D is dead
On 24/08/18 13:43, nkm1 wrote: I think Walter was talking more about "scope (failure) destroy(this)" at the top of all your structs? I don't know if it has some gotchas, though (as I don't use RAII in D...). No, unlike what I suggest, that doesn't work without carefully reviewing every single place you put it to see whether the constructor actually supports destructing a partially constructed object. Shachar
[Issue 19084] Symbol not resolved in string mixin in template struct
https://issues.dlang.org/show_bug.cgi?id=19084
--- Comment #3 from Jonathan Marler ---
struct Bar(T) {
mixin("T foo;");
}
T in this case is not a "symbol name string", it is an alias to a symbol. But
don't be confused, you can't actually create T with an alias, meaning `alias T
= Foo` won't work. You have to use the fully qualified name of `Foo` but
because `Foo` is inside a unittest, it's prvate and you cannot access it. The
only way to access the type is if the code inside unittest "passes" the type
alias to you through a template type parameter:
unittest
{
struct Foo { }
Bar!Foo bar; // passing Foo to Bar so it can access it
}
// out here we cannot access Foo because it is private to the unittest
// the only way we can access it is if code inside of unittest passes it
// us through a template type parameter
--
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, August 24, 2018 6:05:40 AM MDT Mike Franklin via Digitalmars-d wrote: > > You're basically trying to bypass the OS' public API if you're > > trying to bypass libc. > > No I'm trying to bypass libc and use the OS API directly. And my point is that most OSes consider libc to be their OS API (Linux doesn't, but it's very much abnormal in that respect). Trying to bypass it means reimplementing core OS functionality and risking all of the bugs that go with it. It's also _far_ less portable - especially on *nix systems where the POSIX API gives you what you need in a mostly cross-platform manner (whereas syscalls aren't cross-platform at all). Trying to skip libc to call syscalls directly means that D programs risk not acting like programs written in other languages doing the same thing, and it seriously increases the maintenance cost, because then we have to worry about implementing core libc functionality that we currently get simply by linking against libc. I honestly don't see how attempting to divorce druntime from libc does anything but increase the amount of work that we have to do and increase the likelihood that basic OS functionality is going to be buggy, since we will have then reimplemented it rather than using the same core OS functionality that everyone else is using. If you're talking about avoiding libc functions like strcmp that's one thing, but if you're talking about reimplementing stuff that uses syscalls, then honestly, I think that you're crazy. Even if we were overflowing with extra manpower, I would think that that was a terrible idea, and given that we're _not_ overflowing with extra manpower, it's an even worse idea. - Jonathan M Davis
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 13:04:28 UTC, Chris wrote: I've been working with Java recently and although it is not an exciting language, it does the job and it does it well. You can rely on it to get the job done - and get it done fast. And you know that your code will still work next week, month or in 5 years. In everyday programming life you don't care about the latest fancy features. Imo, D should slow down, take inventory, do some spring cleaning and work on useful libraries and a sound ecosystem. I don't care what color the bike shed is as long as there are bikes in there that actually work. Atm, I'm not considering D for any important and or big projects. There is exactly where I am - I am using Java (and more recently Python) for serious stuff. I am however in favour of D moving fast (that is why many Java programmers moved to Kotlin/Scala!). The only problem with D is that there should be stable release of D2 (two times a year, like Fedora for an example), and this stable release gets only security updates and bug-fixes! I know this would require someone to maintain all this (it is a full-time job!)...
Cross compile windows programs on linux
Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up?
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Wednesday, 22 August 2018 at 11:59:37 UTC, Paolo Invernizzi wrote: Just found by chance, if someone is interested [1] [2]. /Paolo [1] https://gitlab.com/mihails.strasuns/blog/blob/master/articles/on_leaving_d.md [2] https://blog.mist.global/articles/My_concerns_about_D_programming_language.html Two things: 1. from the blog "You can't assume that next compiler upgrade won't suddenly break your project or any of its transitive dependencies." 2. it took till 2018 to fix this: https://issues.dlang.org/show_bug.cgi?id=16739 As to 1.: this is my biggest fear and chagrin: with every new version my code might break. And new versions come quite frequently. Having to spend time fixing what wasn't broke a week ago is a nightmare. As to 2: just keeps you from writing code For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. I've been working with Java recently and although it is not an exciting language, it does the job and it does it well. You can rely on it to get the job done - and get it done fast. And you know that your code will still work next week, month or in 5 years. In everyday programming life you don't care about the latest fancy features. Imo, D should slow down, take inventory, do some spring cleaning and work on useful libraries and a sound ecosystem. I don't care what color the bike shed is as long as there are bikes in there that actually work. Atm, I'm not considering D for any important and or big projects.
Parallelizing factorial computation
I was messing and tried comparing the performance of different ways to compute the factorial of a number. Here's the benchmark results: recursive: 244 ms, 283 μs, and 2 hnsecs loop: 241 ms, 412 μs, and 3 hnsecs parallel: 1 sec, 784 ms, 829 μs, and 5 hnsecs https://run.dlang.io/is/uyVlqu I was quite surprised by the fact that parallel ran so much slower than recursive and loop implementations. Does anyone know why?
Re: LDC 1.11.0
On Friday, 24 August 2018 at 12:21:32 UTC, Uknown wrote: On Tuesday, 21 August 2018 at 15:31:16 UTC, Joakim wrote: On Sunday, 19 August 2018 at 10:11:42 UTC, 鲜卑拓跋枫 wrote: [...] I tried looking for a RISC-V VPS or dev board recently and found basically nothing, just two boards from SiFive that are too small or too expensive. There is the SHAKTI Program by IIT Madras : http://shakti.org.in/about.html I've actually heard of it, what of it? Is someone using it in a production environment, or do they have a VPS or dev board? If not, academic projects sitting half-finished in some grad students' computers somewhere aren't relevant to my questions.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 12:25:58 UTC, Paolo Invernizzi wrote: On Wednesday, 22 August 2018 at 11:59:37 UTC, Paolo Invernizzi wrote: Just found by chance, if someone is interested [1] [2]. /Paolo After having seen all the discussions around Mihails post in these days, I'm puzzled by one fact. There was no discussions around one paragraph: "You can't assume there is any control over how declared vision documents get executed in practice. You can't trust any promises from language authors because they don't keep any track of those." I think that this is one of the central points of the post, so why? /Paolo I think I touched it indirectly. There is every time "the feature" that will make D most popular language in the world, be it safety (which will kill C) or betterC (which will kill C?), RC instead of GC or whatever. A lot of work is done, but after some time everyone loses interest and the written code becomes a mess. Look how are Phobos containers implemented, there is no consistent memory model.
[Issue 19176] Dmd crashes because of __traits(getUnitTests)
https://issues.dlang.org/show_bug.cgi?id=19176 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/5eab3c11e253c97061f7f37e9507ff4bb2a9bd35 Fix Issue 19176 - Dmd crashes because of __traits(getUnitTests) https://github.com/dlang/dmd/commit/8e8a84c2be8f51319e28c228910fb9bc216b48e1 Merge pull request #8574 from JinShil/fix_19176 Fix Issue 19176 - Dmd crashes because of __traits(getUnitTests) merged-on-behalf-of: Jacob Carlborg --
[Issue 19176] Dmd crashes because of __traits(getUnitTests)
https://issues.dlang.org/show_bug.cgi?id=19176 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Wednesday, 22 August 2018 at 11:59:37 UTC, Paolo Invernizzi wrote: Just found by chance, if someone is interested [1] [2]. /Paolo After having seen all the discussions around Mihails post in these days, I'm puzzled by one fact. There was no discussions around one paragraph: "You can't assume there is any control over how declared vision documents get executed in practice. You can't trust any promises from language authors because they don't keep any track of those." I think that this is one of the central points of the post, so why? /Paolo
Re: LDC 1.11.0
On Tuesday, 21 August 2018 at 15:31:16 UTC, Joakim wrote: On Sunday, 19 August 2018 at 10:11:42 UTC, 鲜卑拓跋枫 wrote: [...] I tried looking for a RISC-V VPS or dev board recently and found basically nothing, just two boards from SiFive that are too small or too expensive. There is the SHAKTI Program by IIT Madras : http://shakti.org.in/about.html
Re: D is dead
On Friday, 24 August 2018 at 09:52:20 UTC, Walter Bright wrote: On 8/24/2018 1:45 AM, Trass3r wrote: Are you referring to http://wg21.link/P0709 ? Yes. (please don't use link shorteners, they tend to go poof) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf I expect it to always point to the latest revision. Not sure if it's an official WG21 service though. Anyway, very interesting paper and approach. I'm eager to see how this will work out.
