Re: LDC now supports Windows MSVC x86/x64 as first class targets
On 22 March 2016 at 03:12, Kagamin via Digitalmars-d-announcewrote: > On Sunday, 20 March 2016 at 14:15:19 UTC, Manu wrote: >> >> MSVC debuginfo is very good; it has data such that variables >> follow their registers around in fully optimised builds, making >> release build debugging fast and effortless. > > > That's backend feature, there are (usually) no registers on the frontend > level. Yes, that's why the C2 backend is useful; it populates the debuginfo with very high quality data.
[Issue 15819] array(x) is ok but not x.array, giving contradicting error
https://issues.dlang.org/show_bug.cgi?id=15819 Timothee Courchanged: What|Removed |Added Summary|Error: cannot resolve type |array(x) is ok but not |for temp.array(Range)(Range |x.array, giving |r) if (isIterable!Range && |contradicting error |!isNarrowString!Range &&| |!isInfinite!Range) | |//static| |assert(is(typeof(temp.array | |)));| --
[Issue 15819] Error: cannot resolve type for temp.array(Range)(Range r) if (isIterable!Range && !isNarrowString!Range && !isInfinite!Range) //static assert(is(typeof(temp.array)));
https://issues.dlang.org/show_bug.cgi?id=15819 --- Comment #1 from Timothee Cour--- update: the following passes, ie array(temp) is ok but temp.array is not; why is that? (again, self contained single file test example here: https://github.com/timotheecour/dtools/blob/master/dtools/util/emit.d ) // ... import std.array:array; static assert(is(typeof(array(temp; static assert(!is(typeof(temp.array))); --
[Issue 15819] New: Error: cannot resolve type for temp.array(Range)(Range r) if (isIterable!Range && !isNarrowString!Range && !isInfinite!Range) //static assert(is(typeof(temp.array)));
https://issues.dlang.org/show_bug.cgi?id=15819 Issue ID: 15819 Summary: Error: cannot resolve type for temp.array(Range)(Range r) if (isIterable!Range && !isNarrowString!Range && !isInfinite!Range) //static assert(is(typeof(temp.array))); Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: timothee.co...@gmail.com not sure whether it's a dmd or phobos error (or if i missed something) but: void fun(){ // ... alias Range = typeof(temp); static assert(isInputRange!Range); static assert(isIterable!Range && !isNarrowString!Range && !isInfinite!Range); static assert(is(typeof(temp.array))); // CT error } error: Error: cannot resolve type for temp.array(Range)(Range r) if (isIterable!Range && !isNarrowString!Range && !isInfinite!Range) //static assert(is(typeof(temp.array))); single file code here: https://github.com/timotheecour/dtools/blob/master/dtools/util/emit.d using: DMD64 D Compiler v2.070 (same with git head) --
[Issue 15819] Error: cannot resolve type for temp.array(Range)(Range r) if (isIterable!Range && !isNarrowString!Range && !isInfinite!Range) //static assert(is(typeof(temp.array)));
https://issues.dlang.org/show_bug.cgi?id=15819 Timothee Courchanged: What|Removed |Added CC||timothee.co...@gmail.com Severity|enhancement |major --
[Issue 15573] -O -inline causes wrong code with idiv instruction
https://issues.dlang.org/show_bug.cgi?id=15573 --- Comment #34 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/30ec03499244697e8c691c29e058c76d1571c4ec Merge pull request #5559 from yebblies/issue15573 --
[Issue 15815] [REG2.071-devel] deprecation for aliased template instance not shown
https://issues.dlang.org/show_bug.cgi?id=15815 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e9a67955f0d0d63b903423dd9a6f6aaa8f7d2470 fix Issue 15815 - deprecation for aliased template instance not shown https://github.com/D-Programming-Language/dmd/commit/d2c759f54f48e5159a962050b33481b0e26ea030 Merge pull request #5558 from 9rnsr/fix15815 --
[Issue 15455] [REG v2.065] Compiler segfault for simple nested structure
https://issues.dlang.org/show_bug.cgi?id=15455 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/414e10b3e3f5ecfa58b5be24c5e490a43281510f fix Issue 15455 - [REG v2.065] Compiler segfault for simple nested structure https://github.com/D-Programming-Language/dmd/commit/c30a55a31e97f7eb8ba80a578ec4a6a6386b5679 Merge pull request #5551 from 9rnsr/fix15455 --
[Issue 15729] [REG(master)] broken debug info for libraries
https://issues.dlang.org/show_bug.cgi?id=15729 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1737bea648d961dbc1a03dc0eb2babe2d66c322f fix Issue 15729 - broken debug info for libraries https://github.com/D-Programming-Language/dmd/commit/ed13c690af3c2910e648d86e51808d60542cebc0 Merge pull request #5548 from MartinNowak/fix15729 --
[Issue 15817] [REG2.068] ICE (with no stacktrace) instead of 'cannot index null array counts' with CTFE AA
https://issues.dlang.org/show_bug.cgi?id=15817 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/fd191357c47f33a1bbf061fef13de114ab4d0217 fix Issue 15817 - ICE (with no stacktrace) instead of 'cannot index null array counts' with CTFE AA https://github.com/D-Programming-Language/dmd/commit/db3acaa7aac600e597da66db283e646f1634afcc Merge pull request #5561 from 9rnsr/fix15817 --
Re: "default" keyword as function attribute
On Tuesday, 22 March 2016 at 02:05:20 UTC, Jakob Ovrum wrote: On Monday, 21 March 2016 at 22:58:35 UTC, Jonathan M Davis wrote: I'm inclined to think that folks should think twice before apply attributes en masse like that. Why? It makes it harder to know which attributes are actually being applied to a function, and it makes it way easier to accidentally apply attributes to a function. By putting them on the functions directly, it's very clear exactly which attributes apply, and you're not going to accidentally apply them to anything. And that becomes more critical as the file is maintained, because while you may know about all of those blanketed attributes when you first write the file, you may not realize that they're there later, and even if you do, someone else working on that file may not realize it. We've run into this with Phobos PRs where someone does the wrong thing, because they don't realize that an attribute has been applied to en masse. It makes it _way_ too easy to miss that the attribute is being applied when it's somewhere else entirely in the file. This isn't a problem for anything but @trusted. It's worse for @trusted, but it's a problem any attributes that are involved with attribute inference. By putting something like pure: or nothrow: in the file, you risk accidentally marking any function that uses attribute inference as having that attribute. And while the compiler will error out in many cases, if you're dealing with templates, it's far too easy to not catch the problem. Your unit tests may very well work perfectly fine with those attributes, whereas a different set of template arguments would fail to compile thanks to those accidentally applied attributes, and you won't catch it until you (or someone else using your code) tries to use that function with template arguments that don't work with those attributes. Another area where it causes problems is inheritance. Which attributes go on a base class function affect derived classes, possibly putting restrictions on derived classes that you don't want them to have. By using blanket attributes, it becomes easy to accidentally mark virtual functions as pure, nothrow, etc. and have those unit tests work just fine but then end up with someone else being screwed when they go to use that class, because those accidental attributes conflict with what they're trying to do. We have enough problems with making the right choices about which attributes go on virtual functions without having problems with them being applied accidentally. I can understand someone wanting to reduce the number of annotations that they need to put on declarations in D, but from what I've seen, blanket attributes are a maintenance problem, and I think that we're almost always far better off without them. You shouldn't have to search through the file to figure out which attributes apply to a function, otherwise you end up with an increase in the number of mistakes related to attributes, some of which will be quickly caught and many of which won't be. - Jonathan M Davis
Solid Wood Furniture Stores Ellesmere Port UK
F-i-n-d- -S-o-l-i-d- -W-o-o-d- -B-e-d- -s-u-p-p-l-i-e-r-s- -a-t- -w-w-w-.-s-o-l-i-d-w-o-o-d-b-e-d-s-.-c-o-.-u-k- - -s-o-l-i-d-w-o-o-d-b-e-d-s-.-c-o-.-u-k
Re: "default" keyword as function attribute
On Monday, 21 March 2016 at 22:58:35 UTC, Jonathan M Davis wrote: I'm inclined to think that folks should think twice before apply attributes en masse like that. Why? It makes it _way_ too easy to miss that the attribute is being applied when it's somewhere else entirely in the file. This isn't a problem for anything but @trusted.
Re: pass a struct by value/ref and size of the struct
On Monday, 21 March 2016 at 23:31:06 UTC, ref2401 wrote: I have got a plenty of structs in my project. Their size varies from 12 bytes to 128 bytes. Is there a rule of thumb that states which structs I pass by value and which I should pass by reference due to their size? Thanks. Not really. It depends on the platform - most especially on the details of the cache hierarchy, I think. The best answer to this kind of thing is generally: Do some benchmarks. (Although, you'll have to be somewhat skilled at benchmarking to get useful results, since the performance difference in most code is probably not that large either way.) Note, also, that functions which are doing so little work with their arguments that you can actually notice the speed difference of pass-by-ref versus pass-by-value for small data structures are likely to be inlined anyway - in which case it makes no difference which you chose (I think...). If you really just want a number, though - maybe try pass-by-reference for anything larger than 32 bytes.
way to warn about __traits(compiles , ...) that fail due to compile time interpretation lacking body ?
So I was recently trying to optimise a string substitution function by reserving capacity. however this was being used at compile time (mixin) and the body of arr.reserve(n) was not available causing a bug that was easy to observe but very difficult to determine why. As a result code was taking a wrong static if branch. I know __traits(compiles, ... ) is a blunt tool but it feels very wrong to have a function that works and complies at runtime, fail to compile at compile time and not receive any warning.
[Issue 15658] isFile isn't a template
https://issues.dlang.org/show_bug.cgi?id=15658 b2.t...@gmx.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||b2.t...@gmx.com Hardware|x86_64 |All Assignee|nob...@puremagic.com|b2.t...@gmx.com OS|Linux |All --- Comment #1 from b2.t...@gmx.com --- It's not a UFCS issue: "dirEntries()" doesn't return a range of string. It returns a range of "struct DirEntry{}"which is not a template. Latter in std.file.isFile() this member is called because in @property bool isFile(R)(auto ref R name) if (isConvertibleToString!R) { return name.isFile!(StringTypeOf!R); } it's DirEntry.isFile that get called !! --
Re: Is C++ trying to be like D?
On 3/21/2016 9:51 AM, Bauss wrote: On Sunday, 20 March 2016 at 22:49:28 UTC, Walter Bright wrote: On 3/20/2016 3:48 PM, Walter Bright wrote: Walter was replaced by a D9000 computer years ago. He was jeopardizing the mission. Or was he. Too much Human Error.
Re: LDC now supports Windows MSVC x86/x64 as first class targets
Got the news first hand by David Majnemer first hand not so long ago. Congrats guys :)
Re: size_t index=-1;
On Tuesday, 22 March 2016 at 00:18:54 UTC, Steven Schveighoffer wrote: On 3/21/16 7:43 PM, tsbockman wrote: The false positive rate would certainly be *much* lower than your outlandish 10,000 : 1 estimate, given a good compiler implementation. I wouldn't say it's outlandish given my understanding of the problem. The question is, does the pain justify the update? I haven't run it against my code or any code really, but I can see how someone is very good at making correct uses of the implicit conversion. Well that's the real problem here then, isn't it? I wouldn't want this stuff "fixed" either, if I thought false positives would outnumber useful warnings by 10,000 : 1. However, I already *know* that's not the case, from my own tests. But at this point I'm obviously not going to convince you, except by compiling some concrete statistics on what got flagged in some real code bases. And this I plan to do (in some form or other), once `checkedint` and/or the fix for DMD issue 259 are really ready. People can make an informed decision about the trade-offs then.
Re: year to date pull statistics
On Monday, 21 March 2016 at 21:25:18 UTC, H. S. Teoh wrote: Let X be the set not defined by this sentence... [OT] Your signature line is trying to make my brain explode. Last year Dicebot, myself, and a bunch of others managed to get the queue down to the high 30's / low 40's, or thereabouts. But then Dicebot quit working on Phobos, and I got busy, and things just spiralled out of control again. On topic, I do notice the queue has gotten rather long... It's to the point where I feel kind of guilty about opening new pull requests.
Re: size_t index=-1;
On 3/21/16 7:43 PM, tsbockman wrote: On Monday, 21 March 2016 at 22:29:46 UTC, Steven Schveighoffer wrote: It depends on the situation. foo may know that x is going to be short enough to fit in an int. The question becomes, if 99% of cases the user knows that he was converting to a signed value intentionally, and in the remaining 1% of cases, 99% of those were harmless "errors", then this is going to be just a nuisance update, and it will fail to be accepted. My experimentation strongly suggests that your "99.99% false positive" figure is way, *way* off. This stuff is both: Maybe, what would be a threshold that people would find acceptable? 1) Harder for people to get right than you think (you can't develop good intuition about the extent of the problem, unless you spend some time thoroughly auditing existing code bases specifically looking for this kind of problem), and also It matters not to the person who is very aware of the issue and doesn't write buggy code. His code "breaks" too. I would estimate that *most* uses of if(arr) in the wild were/are incorrect. However, in one particular user's code *0* were incorrect, even though he used it extensively. This kind of problem is what lead to the change being reverted. I suspect this change would be far more likely to create more headaches than help. 2) Easier for the compiler to figure out than you think - I was really surprised at how short the list of problems flagged by the compiler was, when I tested Lionello Lunesu's work on the current D codebase. This is highly subjective to whose code you use it on. The false positive rate would certainly be *much* lower than your outlandish 10,000 : 1 estimate, given a good compiler implementation. I wouldn't say it's outlandish given my understanding of the problem. The question is, does the pain justify the update? I haven't run it against my code or any code really, but I can see how someone is very good at making correct uses of the implicit conversion. With respect to your specific example: 1) The memory limit on a true 32-bit system is 4GiB, not 2GiB. Even with an OS that reserves some of the address space, as much as 3GiB or 3.5GiB may be exposed to a user-space process in practice. Then make it long len = x.length on a 64-bit system. Only reason I said assume it's 32-bit, is because on 64-bit CPU, using int is already an error. The architecture wasn't important for the example. Huh? The point of mine which you quoted applies specifically to 32-bit systems. 32-bit array lengths can be greater than `int.max`. Did you mean to reply to point #3, instead? You seem to spend a lot of time focusing on 32-bit architecture, which was not my point at all. My point is that most arrays and uses are short enough to be handled with a signed value as the length. If this is a generic library function, sure, we should handle all possibilities. This doesn't mean someone's command line utility processing strings from the argument list should have to worry about that (as an example). Breaking perfectly good code is something we should strive against. -Steve
Re: Defer in D
On Monday, 21 March 2016 at 17:46:05 UTC, Dmitry Olshansky wrote: ... The main use case in Go that needs it specifically as a function level primitive is this: files := []File{} for i := paths { files[i], err := os.Open(paths[i]) if err != nil { return errors.Errorf("Failed to open %s", paths[i]) } defer files[i].Close() } ... // lots of code using files So in a nutshell - lack of RAII while operating on collections of resources. D and Go have different mechanisms for handling errors/exceptions. I'll refrain from debating "A is better than B" but I haven't seen any use case which isn't already adequately covered by the existing mechanisms in D. However, one thing I do find inferior is the inability of D lambdas to capture by value. Thus, the simple example of "writeln(i)" may produce unexpected results. @Nick: https://github.com/Xinok/scrapheap/blob/master/defer.d
Re: size_t index=-1;
On Monday, 21 March 2016 at 22:29:46 UTC, Steven Schveighoffer wrote: It depends on the situation. foo may know that x is going to be short enough to fit in an int. The question becomes, if 99% of cases the user knows that he was converting to a signed value intentionally, and in the remaining 1% of cases, 99% of those were harmless "errors", then this is going to be just a nuisance update, and it will fail to be accepted. My experimentation strongly suggests that your "99.99% false positive" figure is way, *way* off. This stuff is both: 1) Harder for people to get right than you think (you can't develop good intuition about the extent of the problem, unless you spend some time thoroughly auditing existing code bases specifically looking for this kind of problem), and also 2) Easier for the compiler to figure out than you think - I was really surprised at how short the list of problems flagged by the compiler was, when I tested Lionello Lunesu's work on the current D codebase. The false positive rate would certainly be *much* lower than your outlandish 10,000 : 1 estimate, given a good compiler implementation. With respect to your specific example: 1) The memory limit on a true 32-bit system is 4GiB, not 2GiB. Even with an OS that reserves some of the address space, as much as 3GiB or 3.5GiB may be exposed to a user-space process in practice. Then make it long len = x.length on a 64-bit system. Only reason I said assume it's 32-bit, is because on 64-bit CPU, using int is already an error. The architecture wasn't important for the example. Huh? The point of mine which you quoted applies specifically to 32-bit systems. 32-bit array lengths can be greater than `int.max`. Did you mean to reply to point #3, instead?
pass a struct by value/ref and size of the struct
I have got a plenty of structs in my project. Their size varies from 12 bytes to 128 bytes. Is there a rule of thumb that states which structs I pass by value and which I should pass by reference due to their size? Thanks.
Re: emit: generalizes map, filter, joiner [proposal + implementation]
On Monday, 21 March 2016 at 11:48:52 UTC, Seb wrote: Could you try to point out whats wrong with map & filter? It's hard to do stuff like this: assert(9.iota.emit!(int,(put,a){if(a%2) put(a*a); if(a%3==0) put(a);}).equal([1,9,3,25,6,49]));
Re: "default" keyword as function attribute
On Saturday, 19 March 2016 at 14:55:00 UTC, Jakob Ovrum wrote: We often repeat advice to put `@safe:`, or some other function attribute, at the top of your modules to apply the attribute en masse. In practice this quickly becomes infeasible. Sooner or later, a generic function is introduced to idiomatic D modules, and many of them, perhaps most of them, are more general when attribute inference is used. Any explicit attribute application disables inference of that attribute. In my experience this is by far the most common reason that blanket application of attributes is impractical. I'm not necessarily against an addition to the language that would make it easier to reset the attributes to their "defaults" when attribute: or attribute{} has been used, but I confess that in general, I'm inclined to think that folks should think twice before apply attributes en masse like that. It makes it _way_ too easy to miss that the attribute is being applied when it's somewhere else entirely in the file. As ugly as it is, in general, I think that it makes far more sense to be explicit about it and put @safe, nothrow, pure, etc. directly on the functions and not use : or {}. Personally, I only ever do it with access levels, which should generally be grouped together anyway IMHO, and even then, sometimes it's confusing about whether something is public or private without digging around elsewhere in the file to figure out whether a particular section is public or private. With @safe, pure, nothrow, etc., it's even worse, because it doesn't usually make sense to group functions based on those attributes, and you often do have to change one of those attributes on a particular function. It also makes it easy to accidentally apply attributes to templated functions, which is obviously bad. So, I'd honestly be inclined to argue that doing stuff like @safe: or pure: is bad practice. - Jonathan M Davis
dub coverage analysis weirdness
I made example and described issue in github repository: https://github.com/MyLittleRobo/dub-coverage-test
Re: size_t index=-1;
On 3/21/16 4:27 PM, tsbockman wrote: On Monday, 21 March 2016 at 17:38:35 UTC, Steven Schveighoffer wrote: Your definition of when "implicit casting is really a bad idea" is almost certainly going to include cases where it really isn't a bad idea. This logic can be applied to pretty much any warning condition or safety/correctness-related compiler feature; if it were followed consistently the compiler would just always trust the programmer, like an ancient C or C++ compiler with warnings turned off. Right, if we were starting over, I'd say let's make sure you can't make these kinds of mistakes. We are not starting over though, and existing code will have intentional uses of the existing behavior that are NOT bugs. Even that may have been rejected by Walter since a goal is making C code easy to port. Note that we already have experience with such a thing: if(arr). Fixing is easy, just put if(arr.ptr). It was rejected because major users of this "feature" did not see any useful improvements -- all their usages were sound. The compiler isn't all-knowing, and there will always be cases where the user knows best (and did the conversion intentionally). That's what explicit casts are for. Existing code doesn't need to cast. People are lazy. I only would insert a cast if I needed to. Most valid code just works fine without casts, so you are going to flag lots of valid code as a nuisance. An obvious one is: void foo(ubyte[] x) { int len = x.length; } (let's assume 32-bit CPU) I'm assuming the compiler would complain about this, since technically, len could be negative! Disallowing such code or requiring a cast is probably too much. But that *is* a bad idea - there have been real-world bugs caused by doing stuff like that without checking. It depends on the situation. foo may know that x is going to be short enough to fit in an int. The question becomes, if 99% of cases the user knows that he was converting to a signed value intentionally, and in the remaining 1% of cases, 99% of those were harmless "errors", then this is going to be just a nuisance update, and it will fail to be accepted. With respect to your specific example: 1) The memory limit on a true 32-bit system is 4GiB, not 2GiB. Even with an OS that reserves some of the address space, as much as 3GiB or 3.5GiB may be exposed to a user-space process in practice. Then make it long len = x.length on a 64-bit system. Only reason I said assume it's 32-bit, is because on 64-bit CPU, using int is already an error. The architecture wasn't important for the example. -Steve
Re: GSoC 2016
On Monday, 21 March 2016 at 21:12:30 UTC, Jacob Carlborg wrote: On 2016-03-21 14:54, Craig Dillabaugh wrote: Jacob Carlborg ... if you are reading this would you be able to lend a hand in advising on the proposals? I believe these projects a mostly related to C => D conversion tools. Maybe you can email russel or myself if you can: I'm not really sure what that would imply. I recall you said you didn't have time to mentor, but might be able to provide advice. I was wondering if you might be able to read over the proposals and provide some feedback (is the proposal achievable, helpful? Can you see any obvious improvements the student could make) From my experience most of the proposals are two or three pages long - so its not too much reading. If you think you have time then feel free to email me and I can try and work something out with Russel. If you are too busy then we will make due. Cheers, Craig
Re: year to date pull statistics
On Mon, Mar 21, 2016 at 01:59:29PM -0700, Brad Roberts via Digitalmars-d wrote: > Another week, so another update to the pull statistics for the D-P-L > dmd, runtime, and phobos repositories. There's been a bit of progress > chipping away at the queue, though there's still a long way to go. > The number of open phobos pulls has grown quite a bit over the last > few weeks and months, currently 92. I don't have the details readily > available, but wasn't there a point in the last year where phobos was > down to something like 20 open pull requests? [...] Last year Dicebot, myself, and a bunch of others managed to get the queue down to the high 30's / low 40's, or thereabouts. But then Dicebot quit working on Phobos, and I got busy, and things just spiralled out of control again. T -- Let X be the set not defined by this sentence...
Re: Idea: std.build instead of dub and make-like tools
On Sunday, 20 March 2016 at 15:33:16 UTC, cym13 wrote: On Sunday, 20 March 2016 at 11:27:11 UTC, Atila Neves wrote: On Sunday, 20 March 2016 at 07:35:07 UTC, Piotrek wrote: I was thinking about simple declarative syntax plus fallback to imperative style for custom needs. That's exactly what I thought I'd accomplished ;) I will try to give a feedback on reggae after I go further with experimenting. Please do! Atila Btw I like what you've done with reggae, it's not saluted enough. Thanks! Thanks! Atila
Re: GSoC 2016
On 2016-03-21 14:54, Craig Dillabaugh wrote: Jacob Carlborg ... if you are reading this would you be able to lend a hand in advising on the proposals? I believe these projects a mostly related to C => D conversion tools. Maybe you can email russel or myself if you can: I'm not really sure what that would imply. -- /Jacob Carlborg
Re: Something wrong with GC
On Sunday, 20 March 2016 at 07:49:17 UTC, stunaep wrote: The gc throws invalid memory errors if I use Arrays from std.container. ... Not sure what to do here I don't know what your larger goal is, but maybe std.array.Appender would be a better fit?
Re: year to date pull statistics
Another week, so another update to the pull statistics for the D-P-L dmd, runtime, and phobos repositories. There's been a bit of progress chipping away at the queue, though there's still a long way to go. The number of open phobos pulls has grown quite a bit over the last few weeks and months, currently 92. I don't have the details readily available, but wasn't there a point in the last year where phobos was down to something like 20 open pull requests? total open: 260 created since 2016-01-01 and still open: 85 created closed delta 2016-03-20 - today 21 19 +2 2016-03-13 - 2016-03-19 44 51 -7 2016-03-06 - 2016-03-12 41 46 +5 2016-02-28 - 2016-03-05 54 48 -6 2016-02-21 - 2016-02-27 29 20 -9 2016-02-14 - 2016-02-20 32 36 +4 2016-02-07 - 2016-02-13 52 52 0 2016-01-31 - 2016-02-06 54 61 +7 2016-01-24 - 2016-01-30 40 37 -3 2016-01-17 - 2016-01-23 31 21-10 2016-01-10 - 2016-01-16 39 42 +3 2016-01-03 - 2016-01-09 26 33 +7 2016-01-01 - 2016-01-02 2 5 +3 --- ------ 465 471 -6 Oldest open pull for each repository: dmd: 2012-09-27 https://github.com/D-Programming-Language/dmd/pull/1145 Add -versions option to list predefined version identifiers. druntime: 2014-02-14 https://github.com/D-Programming-Language/druntime/pull/724 assumeLocal: convert shared lvalue to a non-shared one phobos: 2014-03-14 https://github.com/D-Programming-Language/phobos/pull/2011 fix Issue 12368 - std.file.write conflicts with std.stdio.write Later, Brad
Re: OpenCV bindings for D
On Monday, 21 March 2016 at 19:16:16 UTC, wobbles wrote: On Monday, 21 March 2016 at 16:01:59 UTC, Guillaume Piolat wrote: On Monday, 21 March 2016 at 15:45:36 UTC, wobbles wrote: Hi Folks, I have a project in mind that I'd like to run on my new Raspberry Pi 3. Essentially a security camera that will only record when it detects changes between frames. Now, this is already a solved problem I believe, however in the interest of learning I want to do it myself. Ideally, I'd compare two images using the OpenCV library, and ideally I'd do that from D code. However, there exists no OpenCV binding for D that I can find. Is there a technical reason for this? I understand the OpenCV C api is quite old and dated, and it's recommended to use the C++ one as a result. On that, where is C++ / D linkage at? I know very little about linking the two, but it's something I'd like to learn more about and see this as an opportunity for that - before I sink a load of time into it, however, it'd be good to know if it's even feasibly possible to do so. Thanks! It's quite easy to write bindings for libraries that have a C interface (ie most), if only a bit boring. That's the thing, it doesn't have a C interface (or more correctly, it's modern versions don't have a C interface as it has been deprecated since I think version 2.4. OpenCV is at 3.4 now). I was wondering if there was any difficulties interfacing D to the C++ API? I don't have much experience with D, but I have with OpenCV. The key class in OpenCV is cv::Mat, which is used to represent images as arguments and return values of almost every OpenCV algorithm. It is kind of a handle class - it optionally owns image data and manages its lifetime through reference counting and RAII. The sheer number of constructors is a bit overwhelming. See http://docs.opencv.org/2.4/modules/core/doc/basic_structures.html#mat-mat I would be interested to see what D experts would say about interfacing such class. My guess would be that you may have trouble exposing this directly to the D side in a useful way. You may have to write some helpers or even a wrapper on the C++ side.
Re: Question about version ( ) keyword
Dne 21.3.2016 v 15:51 Vincent R via Digitalmars-d napsal(a): Hi, When looking at core definitions like core.sys.posix.pthread I can see some "duplicated" code because it seems version doesn't support Or as we would do in C/C++ with #ifdefined. For instance if can read this: version( CRuntime_Glibc ) { enum PTHREAD_BARRIER_SERIAL_THREAD = -1; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); } else version( FreeBSD ) { enum PTHREAD_BARRIER_SERIAL_THREAD = -1; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); } else version (OSX) { } else version (Solaris) { enum PTHREAD_BARRIER_SERIAL_THREAD = -2; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); } else version (CRuntime_Bionic) { } else { static assert(false, "Unsupported platform"); } When I see this code I cannot help thinking of something like: version( CRuntime_Glibc ) || version( FreeBSD ) || version (Solaris) { if(version(Solaris)) enum PTHREAD_BARRIER_SERIAL_THREAD = -2; else enum PTHREAD_BARRIER_SERIAL_THREAD = -1; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); } else version (OSX) ||version (CRuntime_Bionic) { } else { static assert(false, "Unsupported platform"); } I suppose language creators had good reasons to not allow it but I am a bit disapointed by the aspect of this language because some files are really verbose. However I understand that this limitation allow a clear separation between different platforms... It is already has been sad why this does not work. But you can still do something like this (or maybe even something better(shorter)): version(CRuntime_Glibc) { enum PTHREAD_BARRIER_SERIAL_THREAD = -1; version = WhatEver1; } else version(FreeBSD) { enum PTHREAD_BARRIER_SERIAL_THREAD = -1; version = WhatEver1; } else version (OSX) { version = WhatEver2; } else version (Solaris) { enum PTHREAD_BARRIER_SERIAL_THREAD = -2; version = WhatEver1; } else version (CRuntime_Bionic) { version = WhatEver2; } version (WhatEver1) { int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); } else version (WhatEver2) else { static assert(false, "Unsupported platform"); } But to be fair I still prefer original code because it is obvious, which platform support what :)
Re: size_t index=-1;
On Monday, 21 March 2016 at 17:38:35 UTC, Steven Schveighoffer wrote: Your definition of when "implicit casting is really a bad idea" is almost certainly going to include cases where it really isn't a bad idea. This logic can be applied to pretty much any warning condition or safety/correctness-related compiler feature; if it were followed consistently the compiler would just always trust the programmer, like an ancient C or C++ compiler with warnings turned off. The compiler isn't all-knowing, and there will always be cases where the user knows best (and did the conversion intentionally). That's what explicit casts are for. An obvious one is: void foo(ubyte[] x) { int len = x.length; } (let's assume 32-bit CPU) I'm assuming the compiler would complain about this, since technically, len could be negative! Disallowing such code or requiring a cast is probably too much. But that *is* a bad idea - there have been real-world bugs caused by doing stuff like that without checking. With respect to your specific example: 1) The memory limit on a true 32-bit system is 4GiB, not 2GiB. Even with an OS that reserves some of the address space, as much as 3GiB or 3.5GiB may be exposed to a user-space process in practice. 2) Many 32-bit CPUs have Physical Address Extension, which allows them to support way more than 4GiB. Even a non-PAE-aware process will probably still be offered at least 3GiB on such a system. 3) Just because your program is 32-bit, does *not* mean that it will only ever run on 32-bit CPUs. On a 64-bit system, a single 32-bit process could easily have access to ~3GiB of memory. 4) Even on an embedded system (which D doesn't really support right now, anyway) with a true, 2GiB memory limit, you still have the problem that such highly platform-dependent code is difficult to find and update when the time comes to port the code to more powerful hardware. These kinds of things are why D has fixed-size integer types: to encourage writing portable code, without too many invisible assumptions about the precise details of the execution environment.
Re: Question about version ( ) keyword
Dne 21.3.2016 v 18:18 Kagamin via Digitalmars-d napsal(a): On Monday, 21 March 2016 at 14:51:48 UTC, Vincent R wrote: When I see this code I cannot help thinking of something like: version( CRuntime_Glibc ) || version( FreeBSD ) || version (Solaris) { if(version(Solaris)) enum PTHREAD_BARRIER_SERIAL_THREAD = -2; else enum PTHREAD_BARRIER_SERIAL_THREAD = -1; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); } else version (OSX) ||version (CRuntime_Bionic) { } else { static assert(false, "Unsupported platform"); } Even shorter: version(Solaris) enum PTHREAD_BARRIER_SERIAL_THREAD = -2; else enum PTHREAD_BARRIER_SERIAL_THREAD = -1; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); I do not see: static assert(false, "Unsupported platform"); so no, it is not shorter just wrong ;-)
Re: Using ffmpeg in command line with D
On Monday, 21 March 2016 at 17:26:09 UTC, Karabuta wrote: I am new to this kind of multimedia stuff and all this is currently theoretical. Will this work and is it the right approach used by video convertor front-ends? Eh, it is how I did it before, it works and is pretty easy to do.
Re: OpenCV bindings for D
On Monday, 21 March 2016 at 16:01:59 UTC, Guillaume Piolat wrote: On Monday, 21 March 2016 at 15:45:36 UTC, wobbles wrote: Hi Folks, I have a project in mind that I'd like to run on my new Raspberry Pi 3. Essentially a security camera that will only record when it detects changes between frames. Now, this is already a solved problem I believe, however in the interest of learning I want to do it myself. Ideally, I'd compare two images using the OpenCV library, and ideally I'd do that from D code. However, there exists no OpenCV binding for D that I can find. Is there a technical reason for this? I understand the OpenCV C api is quite old and dated, and it's recommended to use the C++ one as a result. On that, where is C++ / D linkage at? I know very little about linking the two, but it's something I'd like to learn more about and see this as an opportunity for that - before I sink a load of time into it, however, it'd be good to know if it's even feasibly possible to do so. Thanks! It's quite easy to write bindings for libraries that have a C interface (ie most), if only a bit boring. That's the thing, it doesn't have a C interface (or more correctly, it's modern versions don't have a C interface as it has been deprecated since I think version 2.4. OpenCV is at 3.4 now). I was wondering if there was any difficulties interfacing D to the C++ API?
[Issue 15817] [REG2.068] ICE (with no stacktrace) instead of 'cannot index null array counts' with CTFE AA
https://issues.dlang.org/show_bug.cgi?id=15817 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/fd191357c47f33a1bbf061fef13de114ab4d0217 fix Issue 15817 - ICE (with no stacktrace) instead of 'cannot index null array counts' with CTFE AA https://github.com/D-Programming-Language/dmd/commit/db3acaa7aac600e597da66db283e646f1634afcc Merge pull request #5561 from 9rnsr/fix15817 [REG2.068] Issue 15817 - ICE (with no stacktrace) instead of 'cannot index null array counts' with CTFE AA --
Re: OpenCV bindings for D
Try to look at https://github.com/ljubobratovicrelja/dcv
[Issue 15818] New: Multiple function declarations without definition cause ambiguity overloading error
https://issues.dlang.org/show_bug.cgi?id=15818 Issue ID: 15818 Summary: Multiple function declarations without definition cause ambiguity overloading error Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: rejects-valid Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: verylonglogin@gmail.com This code should compile: --- void f(int); // line 1 void f(int); void f(int); void f(int); void f(int); // line 5 void main() { f(1); // line 9 } --- main.d(9): Error: main.f called with argument types (int) matches both: main.d(1): main.f(int) and: main.d(5): main.f(int) --- If any declaration is converted to definition the code compiles. Also note the error message only reports about the first and the last declaration. --
Re: No property error message
On 3/19/16 2:36 PM, ric maicle wrote: I got an error message with the following code saying: Error: no property 'length' for type 'int[string]' Shouldn't the error message say 'length()'? No, it should say length is a property, not a function. a.length should work. Note the error message here: struct S { int x; } void main() { S s; s.x(); } function expected before (), not s.x of type int Please file a bug report. -Steve
Re: Defer in D
On 20-Mar-2016 02:16, Xinok wrote: I stumbled upon an example demonstrating defer in Go which I thought was interesting. Defer is similar to scope in D except they're called at end of function rather than end of scope; you can queue multiple defer calls by writing them inside of a loop. This implies that it internally builds a stack of delegates which are then executed LIFO once the function returns (or panics). https://tour.golang.org/flowcontrol/13 I think a library solution is elegant enough that it doesn't need to be built into the language but that doesn't mean it needs to be in Phobos either. Does anybody have a use case for "defer" that isn't already adequately covered by scope statements? The main use case in Go that needs it specifically as a function level primitive is this: files := []File{} for i := paths { files[i], err := os.Open(paths[i]) if err != nil { return errors.Errorf("Failed to open %s", paths[i]) } defer files[i].Close() } ... // lots of code using files So in a nutshell - lack of RAII while operating on collections of resources. -- Dmitry Olshansky
Re: size_t index=-1;
On 3/18/16 7:48 PM, tsbockman wrote: On Friday, 18 March 2016 at 14:51:34 UTC, Steven Schveighoffer wrote: Note, I have made these mistakes myself, and I understand what you are asking for and why you are asking for it. But these are bugs. The user is telling the compiler to do one thing, and expecting it to do something else. It's not difficult to fix, and in fact, many lines of code are written specifically to take advantage of these rules. This is why we cannot remove them. The benefit is not worth the cost. Actually, I think I confused things for you by mentioning to `cast(ulong)`. I'm not asking for a Java-style "no unsigned" system (I hate that; it's one of my biggest annoyances with Java). Rather, I'm picking on *implicit* conversions between signed and unsigned. No, I understood you meant implicit casting. I'm basically saying, "because information is lost when casting between signed and unsigned, all such casts should be explicit". This could make code rather verbose - except that from my experiments, with decent VRP the compiler can actually be surprisingly smart about warning only in those cases where implicit casting is really a bad idea. Your definition of when "implicit casting is really a bad idea" is almost certainly going to include cases where it really isn't a bad idea. The compiler isn't all-knowing, and there will always be cases where the user knows best (and did the conversion intentionally). An obvious one is: void foo(ubyte[] x) { int len = x.length; } (let's assume 32-bit CPU) I'm assuming the compiler would complain about this, since technically, len could be negative! Disallowing such code or requiring a cast is probably too much. -Steve
Using ffmpeg in command line with D
Hi all, I'm trying to convert an array of video filenames to another format using spawnProcess() from std.process. I want to convert all files in sequence with the command "ffmpeg -i filename.mp4 -o outputfile.webm" where process will be run one process after the other. I am new to this kind of multimedia stuff and all this is currently theoretical. Will this work and is it the right approach used by video convertor front-ends?
Re: Question about version ( ) keyword
On Monday, 21 March 2016 at 14:51:48 UTC, Vincent R wrote: When I see this code I cannot help thinking of something like: version( CRuntime_Glibc ) || version( FreeBSD ) || version (Solaris) { if(version(Solaris)) enum PTHREAD_BARRIER_SERIAL_THREAD = -2; else enum PTHREAD_BARRIER_SERIAL_THREAD = -1; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); } else version (OSX) ||version (CRuntime_Bionic) { } else { static assert(false, "Unsupported platform"); } Even shorter: version(Solaris) enum PTHREAD_BARRIER_SERIAL_THREAD = -2; else enum PTHREAD_BARRIER_SERIAL_THREAD = -1; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int);
Re: LDC now supports Windows MSVC x86/x64 as first class targets
On Sunday, 20 March 2016 at 14:15:19 UTC, Manu wrote: MSVC debuginfo is very good; it has data such that variables follow their registers around in fully optimised builds, making release build debugging fast and effortless. That's backend feature, there are (usually) no registers on the frontend level.
Re: Is C++ trying to be like D?
On Sunday, 20 March 2016 at 22:49:28 UTC, Walter Bright wrote: On 3/20/2016 3:48 PM, Walter Bright wrote: Walter was replaced by a D9000 computer years ago. He was jeopardizing the mission. Or was he.
Re: LDC now supports Windows MSVC x86/x64 as first class targets
On Saturday, 19 March 2016 at 13:23:48 UTC, kinke wrote: Hey all, I'm proud to announce that MSVC is fully supported now for LDC trunk. Rainer Schuetze has implemented MSVC-compatible exception handling (available since brand-new LLVM 3.8) for LDC, so that we have fully working exception chaining now on Win64. Along the way, he also added 32-bit MSVC support and a TLS alignment bugfix for Windows < 8.1 (a Windows bug/wontfix!). It requires a bleeding edge LLVM though, as Rainer's work has uncovered a few LLVM bugs which didn't make it into 3.8 final. So a round of applause for Rainer and the LLVM devs, excellent job, thank you very much! Full PDB support for LLVM is also underway... This is great, I don't have to write assembly anymore! Thanks LDC team.
mondo - a d library for mongodb
I just released on behalf of the company I work for (http://lab.2night.it) "mondo", a library to work with mongodb. Mondo is a collection of classes (and struct) built over mongo-c-driver. Low-level bindings are generated automatically using dstep + a small script to patch some issues with original source. More info on github page. It obviusly depends on mongo-c-driver library (quite easy to compile). GH: https://github.com/2night/mondo Dub: http://code.dlang.org/packages/mondo Comments are welcome. Andrea Fontana
Re: OpenCV bindings for D
On Monday, 21 March 2016 at 15:45:36 UTC, wobbles wrote: Hi Folks, I have a project in mind that I'd like to run on my new Raspberry Pi 3. Essentially a security camera that will only record when it detects changes between frames. Now, this is already a solved problem I believe, however in the interest of learning I want to do it myself. Ideally, I'd compare two images using the OpenCV library, and ideally I'd do that from D code. However, there exists no OpenCV binding for D that I can find. Is there a technical reason for this? I understand the OpenCV C api is quite old and dated, and it's recommended to use the C++ one as a result. On that, where is C++ / D linkage at? I know very little about linking the two, but it's something I'd like to learn more about and see this as an opportunity for that - before I sink a load of time into it, however, it'd be good to know if it's even feasibly possible to do so. Thanks! It's quite easy to write bindings for libraries that have a C interface (ie most), if only a bit boring. - First check in code.dlang.org or https://github.com/D-Programming-Deimos it doesn't not already exist. - Choose to create a static or dynamic bindings. For multiplatform a dynamic loader will be easier dependency-wise, for *nix systems static linking may be easier. - When porting C headers, there is a few gotchas: https://p0nce.github.io/d-idioms/#Porting-from-C-gotchas - Take inspiraton at either Deimos or Derelict to create either.
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 15:15:41 UTC, Nordlöw wrote: This is because my project has grown beyond 30klines of code and at that scale not even D's speed is enough for getting fast incremental builds through dmd. Note that lines of code isn't really important to build time... $ time dmd -c -o- dom.d cgi.d web.d sha.d libssh2.d simpledisplay.d color.d minigui.d terminal.d characterencodings.d real0m1.063s user0m0.986s sys 0m0.075s $ wc dom.d cgi.d web.d sha.d libssh2.d simpledisplay.d color.d minigui.d terminal.d characterencodings.d 6645 22789 173999 dom.d 3994 16063 123572 cgi.d 4921 18287 143876 web.d 412 1407 10066 sha.d 189478 5357 libssh2.d 8850 34060 274340 simpledisplay.d 1163 4413 27268 color.d 2785 8150 70996 minigui.d 3834 13888 114827 terminal.d 473 2819 18391 characterencodings.d 33266 122354 962692 total Yes, compiling 33,000 lines from my libs happened in about one second. My experience with slow D builds tends to be that it is caused by CTFE, not by scale.
On adding to the standard library
I just asked for a stdlib addition to be pulled back at https://github.com/D-Programming-Language/phobos/pull/4025. Such decisions are difficult because the risk is them to be interpreted as stifling creativity. That is not the case. The only reason for all library additions to go through one person/small group is to preserve a cohesive vision and style. At the opposite end, nobody wants a library that's a mishmash of styles and approaches, even if that includes some of theirs. Please make sure I know of library additions. I've been on vacation and even when I'm not I can't monitor and review all library work - it would be a full-time job that wouldn't leave me time for anything else. Please just email me directly related pull requests. I always tend to my email. Thanks, Andrei
[Issue 15817] [REG2.068] ICE (with no stacktrace) instead of 'cannot index null array counts' with CTFE AA
https://issues.dlang.org/show_bug.cgi?id=15817 Kenji Harachanged: What|Removed |Added Keywords||pull Summary|ICE (with no stacktrace)|[REG2.068] ICE (with no |instead of 'cannot index|stacktrace) instead of |null array counts' with |'cannot index null array |CTFE AA |counts' with CTFE AA --- Comment #3 from Kenji Hara --- (In reply to Timothee Cour from comment #0) > not sure whether the code should be valid or not, but regardless there > shouldn't be ICE, especially wo stacktrace It was introduced by incomplete fix of issue 9023. The fix for that issue has done in 2.068, but the ICE case didn't tested. https://github.com/D-Programming-Language/dmd/pull/5561 --
OpenCV bindings for D
Hi Folks, I have a project in mind that I'd like to run on my new Raspberry Pi 3. Essentially a security camera that will only record when it detects changes between frames. Now, this is already a solved problem I believe, however in the interest of learning I want to do it myself. Ideally, I'd compare two images using the OpenCV library, and ideally I'd do that from D code. However, there exists no OpenCV binding for D that I can find. Is there a technical reason for this? I understand the OpenCV C api is quite old and dated, and it's recommended to use the C++ one as a result. On that, where is C++ / D linkage at? I know very little about linking the two, but it's something I'd like to learn more about and see this as an opportunity for that - before I sink a load of time into it, however, it'd be good to know if it's even feasibly possible to do so. Thanks!
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 15:15:41 UTC, Nordlöw wrote: I don't see any other solution for really large projects. Except implementing memoized execution of unittests into dmd. Which I have discussed previously :)
[Issue 15817] ICE (with no stacktrace) instead of 'cannot index null array counts' with CTFE AA
https://issues.dlang.org/show_bug.cgi?id=15817 Kenji Harachanged: What|Removed |Added Keywords||CTFE, ice Hardware|x86 |All OS|Mac OS X|All --- Comment #2 from Kenji Hara --- Dustmited test case: S[] split(S)(S s) { size_t istart; S[] result; foreach (i, c ; s) result ~= s[istart .. i]; return result; } int fun(string b) { auto targets = b.split; uint[string] counts; foreach (a; targets) counts[a]++; return 0; } void fun2() { enum a = `a1`; static b = fun(a); } --
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 15:11:31 UTC, Nordlöw wrote: On Monday, 21 March 2016 at 11:36:10 UTC, wobbles wrote: This is quite annoying I feel. There probably should be an option for the -unittest flag to only compile unittests for the source files I'm passing in, and not any of the tests in the -I import paths. I very much agree. This is because my project has grown beyond 30klines of code and at that scale not even D's speed is enough for getting fast incremental builds through dmd. Therefore I've split my project into separate build using scons. With good dependency design I've reduced the build time from around 12 (via one single call to dmd) to 2 seconds. I don't see any other solution for really large projects.
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 11:36:10 UTC, wobbles wrote: This is quite annoying I feel. There probably should be an option for the -unittest flag to only compile unittests for the source files I'm passing in, and not any of the tests in the -I import paths. I very much agree.
Re: Question about version ( ) keyword
On Monday, 21 March 2016 at 14:51:48 UTC, Vincent R wrote: Hi, When looking at core definitions like core.sys.posix.pthread I can see some "duplicated" code because it seems version doesn't support Or as we would do in C/C++ with #ifdefined. For instance if can read this: [...] The language creator is against it, more info can be found in forum threads like this one: http://forum.dlang.org/thread/n0u5v3$1lsh$1...@digitalmars.com
Re: Question about version ( ) keyword
On Monday, 21 March 2016 at 14:51:48 UTC, Vincent R wrote: However I understand that this limitation allow a clear separation between different platforms... That's exactly why it is done this way, so the platforms are clearly separated from each other and always grouped together for themselves. When writing these, we try to copy/paste it from the specific platform's documentation as a whole block so it is there and correct without accidentally assuming a Linux function is the same as a FreeBSD function (for example) just because a few of them were and got grouped in an OR block, but the rest weren't and got overlooked. Doing it separately makes sure we look each thing up for the specific platform to get it right. (Version does not support an or thing itself to force this, but still if you really wanted to, you can static if or set shared version identifiers, so it is possible, just the language and library guidelines don't want you doing it that way.)
Question about version ( ) keyword
Hi, When looking at core definitions like core.sys.posix.pthread I can see some "duplicated" code because it seems version doesn't support Or as we would do in C/C++ with #ifdefined. For instance if can read this: version( CRuntime_Glibc ) { enum PTHREAD_BARRIER_SERIAL_THREAD = -1; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); } else version( FreeBSD ) { enum PTHREAD_BARRIER_SERIAL_THREAD = -1; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); } else version (OSX) { } else version (Solaris) { enum PTHREAD_BARRIER_SERIAL_THREAD = -2; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); } else version (CRuntime_Bionic) { } else { static assert(false, "Unsupported platform"); } When I see this code I cannot help thinking of something like: version( CRuntime_Glibc ) || version( FreeBSD ) || version (Solaris) { if(version(Solaris)) enum PTHREAD_BARRIER_SERIAL_THREAD = -2; else enum PTHREAD_BARRIER_SERIAL_THREAD = -1; int pthread_barrier_destroy(pthread_barrier_t*); int pthread_barrier_init(pthread_barrier_t*, in pthread_barrierattr_t*, uint); int pthread_barrier_wait(pthread_barrier_t*); int pthread_barrierattr_destroy(pthread_barrierattr_t*); int pthread_barrierattr_getpshared(in pthread_barrierattr_t*, int*); int pthread_barrierattr_init(pthread_barrierattr_t*); int pthread_barrierattr_setpshared(pthread_barrierattr_t*, int); } else version (OSX) ||version (CRuntime_Bionic) { } else { static assert(false, "Unsupported platform"); } I suppose language creators had good reasons to not allow it but I am a bit disapointed by the aspect of this language because some files are really verbose. However I understand that this limitation allow a clear separation between different platforms...
Re: How can I report what I think a compiler's frontend bug
On Monday, 21 March 2016 at 11:00:08 UTC, Vincent R wrote: On Monday, 21 March 2016 at 09:46:18 UTC, Vincent R wrote: On Monday, 21 March 2016 at 01:51:09 UTC, Marco Leise wrote: Am Sun, 20 Mar 2016 22:37:37 + schrieb Vincent R: [...] Thanks and you see I was right to post here since I finally found the problem and got an answer :-) Unfortunately at the end I get a linker error: 1000@MLVD0032 MINGW64 ~/tmp/wxd/src/Samples $ make del *.cached cd Controls make dmd -c -version=wx28 -version=__WXMSW__ -version=ANSI -I..\.. Controls.d ..\..\wx\common.d(153): Deprecation: function wx.common.new_Rectangle is deprecated ..\..\wx\common.d(153): Deprecation: function wx.common.new_Rectangle is deprecated dmd -g -of..\..\bin\Controls.exe Controls.obj ..\..\wxd.lib ..\..\wxc.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxbase28d.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxbase28d_xml.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_core.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_adv.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_html.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_xrc.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxtiffd.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxjpegd.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxpngd.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxzlibd.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxregexd.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxexpatd.lib kernel32.lib user32.lib gdi32.lib comdlg32.lib winspool.lib winmm.l! ib shell32.lib comctl32.lib ole32.lib oleaut32.lib uuid.lib rpcrt4.lib advapi32.lib wsock32.lib odbc32.lib-L/EXETYPE:NT -L/SU:WINDOWS:4.0 OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html C:\DEV\msys64\home\1000\tmp\wxWidgets-2.8.12\lib\dmc_lib\wxexpatd.lib(xmlrole) Error 168: >64K Global Types I tried with a gdc compiler compiled by myself and I was able to compile and launch my first sample application using wxWidgets-2.8. Now I have some work to do to fix all the remaining warnings and errors but I hope that wxD will be very soon an alternative to existing gui framework for D. In a perfect world I should also work on the D libraries to add support for mingwXX winpthreads because for the moment the gdc compiler is generated using --enable-threads=win32. As long as it cannot use posix thread it cannot be an official package of msys2/mingw64.
Re: GSoC 2016
On Sunday, 20 March 2016 at 15:03:16 UTC, Russel Winder wrote: Due to unforseen circumstances, I am well behind dealing wit GSoC email, an I doubt I will beable to get on top of it till Thursday. There are at least five peopl I should be having conversations with but I fear it is unlikely to happen in the next three days :-( Russel. = Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder Jacob Carlborg ... if you are reading this would you be able to lend a hand in advising on the proposals? I believe these projects a mostly related to C => D conversion tools. Maybe you can email russel or myself if you can: craig dot dillabaugh at gmail dot com Craig
Re: Can't Compile Global Semaphores?
On Monday, 27 July 2015 at 20:12:10 UTC, John Colvin wrote: Yes, but then core.sync.semaphore doesn't support being shared, so... I don't really understand how https://github.com/D-Programming-Language/druntime/blob/master/src/core/sync/semaphore.d#L356 is managing to avoid this Since that time is something cleared up? Faced with the same problem
Re: [Request] A way to extract all instance of X from a range
On Mon, Mar 21, 2016 at 4:34 AM, Nick Treleaven via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 14/03/2016 11:32, thedeemon wrote: > >> >> filter_map : ('a -> 'b option) -> 'a t -> 'b t >> >> "filter_map f e returns an enumeration over all elements x such as f y >> returns Some x, where y is an element of e." >> >> It is really convenient and comes handy in many situations. However it >> requires some common Option/Maybe type that different libraries could use. >> > > There is a pull for Option: > https://github.com/D-Programming-Language/phobos/pull/3915 > > We could have: > > // fun takes r.front and produces an Option of that type > auto mapFilter(alias fun, R)(R r); > > // turn a possibly null value into an Option > Option!T nullFilter(T)(T v) if (isNullable!T); > > auto src = [new Object(), new T(), null]; > auto res = mapFilter!(e => nullFilter(cast(T)e)); > assert(res.equal([src[1]])); > > > see my proposal [+implementation] for emit http://forum.dlang.org/post/mailman.538.1458560190.26339.digitalmar...@puremagic.com emit is more powerfull, and generalizes map,filter,joiner auto res = src.mapFilter!(e=>nullFilter(cast(T)e)); with emit: auto res = src.emit!((put,e){if(cast(T)e) put(e);});
Re: emit: generalizes map, filter, joiner [proposal + implementation]
On Monday, 21 March 2016 at 11:35:49 UTC, Timothee Cour wrote: assert(9.iota.emit!(int,(put,a){if(a%2) put(a*a);}).equal([1, 9, 25, 49])) Could you try to point out whats wrong with map & filter? assert(9.iota.filter!"a%2".map!"a*a".equal([1, 9, 25, 49])
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 10:37:31 UTC, ZombineDev wrote: On Monday, 21 March 2016 at 10:29:36 UTC, Nordlöw wrote: I want to enable unittests only at the top-level of a module compilation. If I have a module top.d that imports dep1.d dep2.d ... which all contain unittests, how do I compile top.d with only the unittests for top.d enabled? I think the easiest solution is to use http://dlang.org/spec/traits.html#getUnitTests and to run the tests you want manually. This is quite annoying I feel. There probably should be an option for the -unittest flag to only compile unittests for the source files I'm passing in, and not any of the tests in the -I import paths.
emit: generalizes map, filter, joiner [proposal + implementation]
given fun(put, a) a lambda that can call $put 0 or more times, some_range.emit!fun computes a range formed of all the calls to $put eg: assert(9.iota.emit!(int,(put,a){if(a%2) put(a*a);}).equal([1, 9, 25, 49])); in this case it can be done by combining map and filter but in other cases emit is more powerful and an equivalent (with map,filter,joiner) can be inefficient and more complex. see https://github.com/timotheecour/dtools/blob/master/dtools/util/emit.d could that be turned into std.algorithm.iteration.emit (after addressing comments) ? Any comments would be appreciated (especially regarding whether we can get rid of the 1st template argument with type deduction)
Re: [Request] A way to extract all instance of X from a range
On 14/03/2016 11:32, thedeemon wrote: filter_map : ('a -> 'b option) -> 'a t -> 'b t "filter_map f e returns an enumeration over all elements x such as f y returns Some x, where y is an element of e." It is really convenient and comes handy in many situations. However it requires some common Option/Maybe type that different libraries could use. There is a pull for Option: https://github.com/D-Programming-Language/phobos/pull/3915 We could have: // fun takes r.front and produces an Option of that type auto mapFilter(alias fun, R)(R r); // turn a possibly null value into an Option Option!T nullFilter(T)(T v) if (isNullable!T); auto src = [new Object(), new T(), null]; auto res = mapFilter!(e => nullFilter(cast(T)e)); assert(res.equal([src[1]]));
[Issue 15802] (SIGSEGV) CppMangleVisitor::source_name
https://issues.dlang.org/show_bug.cgi?id=15802 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/62aeb7fdb94bad8f07e9aab6e4858b9f93b00a1e Fix issue 15802 https://github.com/D-Programming-Language/dmd/commit/dfc005abdff1219a391658fa13f2b1b970518e46 Merge pull request #5537 from Kozzi11/fix15802 Fix issue 15802 --
[Issue 15802] (SIGSEGV) CppMangleVisitor::source_name
https://issues.dlang.org/show_bug.cgi?id=15802 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: Defer in D
On 20/03/2016 16:57, Nick Treleaven wrote: void opCall(ARGS...)(void delegate(ARGS) call, ARGS args) { stack.put(() => call(args)); } Maybe this method would be nice (does the same thing): Deferrer d; ... d.capture!writeln("i = ", i); The name capture makes it clearer the arguments are not taken by reference IMO. @Xinok: I suggest for now you put it in a Github repository somewhere.
Re: d-vulkan, automatically generated D bindings for Vulkan
On Monday, 21 March 2016 at 09:27:35 UTC, Manuel Maier wrote: On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote: https://github.com/ColonelThirtyTwo/dvulkan [...] @Alex Parrill: Thanks for sharing! Looks nice. I was just wondering... why did you write the generator in python and not in D? Just curious :) I see now... The Vulkan docs provide python modules for easier integration already. Makes sense.
Re: How can I report what I think a compiler's frontend bug
On Monday, 21 March 2016 at 09:46:18 UTC, Vincent R wrote: On Monday, 21 March 2016 at 01:51:09 UTC, Marco Leise wrote: Am Sun, 20 Mar 2016 22:37:37 + schrieb Vincent R: [...] Thanks and you see I was right to post here since I finally found the problem and got an answer :-) Unfortunately at the end I get a linker error: 1000@MLVD0032 MINGW64 ~/tmp/wxd/src/Samples $ make del *.cached cd Controls make dmd -c -version=wx28 -version=__WXMSW__ -version=ANSI -I..\.. Controls.d ..\..\wx\common.d(153): Deprecation: function wx.common.new_Rectangle is deprecated ..\..\wx\common.d(153): Deprecation: function wx.common.new_Rectangle is deprecated dmd -g -of..\..\bin\Controls.exe Controls.obj ..\..\wxd.lib ..\..\wxc.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxbase28d.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxbase28d_xml.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_core.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_adv.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_html.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxmsw28d_xrc.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxtiffd.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxjpegd.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxpngd.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxzlibd.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxregexd.lib C:/DEV/msys64/home/1000/tmp/wxWidgets-2.8.12\lib\dmc_lib\wxexpatd.lib kernel32.lib user32.lib gdi32.lib comdlg32.lib winspool.lib winmm.lib! shell32.lib comctl32.lib ole32.lib oleaut32.lib uuid.lib rpcrt4.lib advapi32.lib wsock32.lib odbc32.lib-L/EXETYPE:NT -L/SU:WINDOWS:4.0 OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html C:\DEV\msys64\home\1000\tmp\wxWidgets-2.8.12\lib\dmc_lib\wxexpatd.lib(xmlrole) Error 168: >64K Global Types
Re: /usr/bin/ld: cannot find -lphobos2
On Monday, 21 March 2016 at 10:46:27 UTC, ag0aep6g wrote: On 21.03.2016 11:19, ZombineDev wrote: DFLAGS=-I~/dev/repos/dlang/druntime/import -I~/dev/repos/dlang/phobos -L-L/home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64 [...] Linking... ... /usr/bin/ld {other stuff...} -L/home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64 -lphobos2 /usr/bin/ld: cannot find -lphobos2 However $ ls /home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64 etc libphobos2.a libphobos2.so libphobos2.so.0.70 libphobos2.so.0.70.0 libphobos2.so.0.70.o Any idea what I'm doing wrong? Asterisk expansion is a shell feature. dmd probably doesn't go through a shell when running ld. Even if it did, no expansion would be done there, because the word is looked at as a whole. With the leading "-L", the pattern doesn't match an actual path. For example, compare `echo /*` with `echo -L/*`. You have to spell the different paths out. Thanks a lot! I replaced "*" with the name of my OS and it all works! I thought that if it could replace $HOME, it ought to replace the asterisk. Probably I should add this caveat to http://wiki.dlang.org/Starting_as_a_Contributor#Running_Independent_Programs for future reference.
Re: /usr/bin/ld: cannot find -lphobos2
On 21.03.2016 11:19, ZombineDev wrote: DFLAGS=-I~/dev/repos/dlang/druntime/import -I~/dev/repos/dlang/phobos -L-L/home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64 [...] Linking... ... /usr/bin/ld {other stuff...} -L/home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64 -lphobos2 /usr/bin/ld: cannot find -lphobos2 However $ ls /home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64 etc libphobos2.a libphobos2.so libphobos2.so.0.70 libphobos2.so.0.70.0 libphobos2.so.0.70.o Any idea what I'm doing wrong? Asterisk expansion is a shell feature. dmd probably doesn't go through a shell when running ld. Even if it did, no expansion would be done there, because the word is looked at as a whole. With the leading "-L", the pattern doesn't match an actual path. For example, compare `echo /*` with `echo -L/*`. You have to spell the different paths out.
Re: Enabling Only Top-Level Unittests
On Monday, 21 March 2016 at 10:29:36 UTC, Nordlöw wrote: I want to enable unittests only at the top-level of a module compilation. If I have a module top.d that imports dep1.d dep2.d ... which all contain unittests, how do I compile top.d with only the unittests for top.d enabled? I think the easiest solution is to use http://dlang.org/spec/traits.html#getUnitTests and to run the tests you want manually.
Enabling Only Top-Level Unittests
I want to enable unittests only at the top-level of a module compilation. If I have a module top.d that imports dep1.d dep2.d ... which all contain unittests, how do I compile top.d with only the unittests for top.d enabled?
/usr/bin/ld: cannot find -lphobos2
I'm manually building dmd, druntime and phobos like so: $ cd ~/dev/repos/dlang $ git clone https://github.com/D-Programming-Language/dmd $ git clone https://github.com/D-Programming-Language/druntime $ git clone https://github.com/D-Programming-Language/phobos $ cd dmd && make -f make -f posix.mak -j4 AUTO_BOOTSTRAP=1 $ cd ../druntime && make -f make -f posix.mak -j4 $ cd ../phobos && make -f make -f posix.mak -j4 $ cat << EOF > ~/dev/repos/dlang/dmd/src/dmd.conf [Environment] DFLAGS=-I~/dev/repos/dlang/druntime/import -I~/dev/repos/dlang/phobos -L-L/home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64 EOF # required for dub $ sudo ln -s ~/dev/repos/dlang/dmd/src/dmd /bin/dmd When my I build my library with dub I can see that dmd.conf is detected correctly: $ cd $myproj (I added the following to my dub.sdl: dflags "-v" lflags "-v") $ dmd test --verbose ... Performing "unittest" build using dmd for x86_64. ... binarydmd version v2.070-devel-46cc1c6 config/home/zombinedev/dev/repos/dlang/dmd/src/dmd.conf ... Linking... ... /usr/bin/ld {other stuff...} -L/home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64 -lphobos2 /usr/bin/ld: cannot find -lphobos2 However $ ls /home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64 etc libphobos2.a libphobos2.so libphobos2.so.0.70 libphobos2.so.0.70.0 libphobos2.so.0.70.o Any idea what I'm doing wrong?
Re: How can I report what I think a compiler's frontend bug
On Monday, 21 March 2016 at 01:51:09 UTC, Marco Leise wrote: Am Sun, 20 Mar 2016 22:37:37 + schrieb Vincent R: [...] Thanks and you see I was right to post here since I finally found the problem and got an answer :-)
Re: Up-to-date DIPs list
On Thursday, 17 March 2016 at 19:03:31 UTC, Seb wrote: On Thursday, 17 March 2016 at 10:11:14 UTC, Martin Tschierschke wrote: But you need both, the possibility to vote and an overview of threads and post with highest votes. Don't be offended, but I think we are a bit off-topic here - my suggestions were about better ways to manage DIPs. What do you think about putting them into a Github repo for a first start so that potential tooling or standardization gets a lot easier? You are right, its getting off-topic, ;-) unfortunately I am not very familiar with all Git tooling, but I appreciate the idea that better tooling is needed and so Git should be a good solution, because it is used anyway by the "D-crowd". Regards mt.
Re: d-vulkan, automatically generated D bindings for Vulkan
On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote: https://github.com/ColonelThirtyTwo/dvulkan [...] @Alex Parrill: Thanks for sharing! Looks nice. I was just wondering... why did you write the generator in python and not in D? Just curious :)
Re: Defer in D
I would, actually, like to see it integrated with the core language syntax, kinda: scope(function) ... While your solution is viable from the technical point of view, having a consistent language syntax could also be nice.
Re: d-vulkan, automatically generated D bindings for Vulkan
On Sunday, 20 March 2016 at 00:52:48 UTC, Alex Parrill wrote: If I import a xcb_connection_t from some bindings, it ties d-vulkan to those bindings, which I'd rather not do. By the magic of D: version (Linux) { import xcb.xcb; } ... version (Linux) { xcb_connection_t* con; } Also you can make xcb-d dependency optional in DUB.
Re: Something wrong with GC
On Sunday, 20 March 2016 at 07:49:17 UTC, stunaep wrote: The gc throws invalid memory errors if I use Arrays from std.container. Those arrays are for RAII-style deterministic memory release, they shouldn't be freely mixed with GC-allocated things. What happens here is while initializing Array sees it got some GC-ed value type (strings), so it tells GC to look after those strings. When your program ends runtime does a GC cycle, finds your Test object, calls its destructor that calls Array destructor that tries to tell GC not to look at its data anymore. But during a GC cycle it's currently illegal to call such GC methods, so it throws an error. Moral of this story: try not to store "managed" (collected by GC) types in Array and/or try not to have Arrays inside "managed" objects. If Test was a struct instead of a class, it would work fine.
[Issue 5944] Five ideas for the stacktrace
https://issues.dlang.org/show_bug.cgi?id=5944 Timothee Courchanged: What|Removed |Added CC||timothee.co...@gmail.com --- Comment #3 from Timothee Cour --- debug info is broken with dmd: eg last frame often skipped; line numbers often off by a few lines [plus or minus], debug info also gets broken with partial recompilation with ldc these problems go away --
[Issue 15817] New: ICE (with no stacktrace) instead of 'cannot index null array counts' with CTFE AA
https://issues.dlang.org/show_bug.cgi?id=15817 Issue ID: 15817 Summary: ICE (with no stacktrace) instead of 'cannot index null array counts' with CTFE AA Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: regression Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: timothee.co...@gmail.com dmd -c -o- $bugs_D/bug_D20160320T235820.d $dmd_067_1_X -c -o- $bugs_D/bug_D20160320T235820.d Error: cannot index null array counts called from here: fun("a1.a2 b1.b2") dmd >= 68: (including DMD64 D Compiler v2.070) ICE segmentation fault with no stacktrace => very bad! not sure whether the code should be valid or not, but regardless there shouldn't be ICE, especially wo stacktrace module bugs.bug_D20160320T235820; import std.string; import std.array; int fun(string b){ auto targets=b.split.array; uint[string]counts; foreach(a;targets){ counts[a]++; } return 0; } void fun2(){ enum a=`a1.a2 b1.b2`; static int b=fun(a); } --
[Issue 15798] std.algorithm.mutation.copy takes target by value
https://issues.dlang.org/show_bug.cgi?id=15798 Ender KaShaechanged: What|Removed |Added CC||astrotha...@gmail.com --- Comment #1 from Ender KaShae --- Simply changing the Target to a ref wouldn't be backward compatible, because then it wouldn't be possible to use an rvalue as a target, which is useful for copying to an array slice, or using a range that wraps another output range, such as retro. Also, std.range.put _does_ take a reference, and can be used to copy a range. Alternatively, copy returns the state of the output range after copying, so in the MD5 example you could use `s.copy(d2).finish().toHexString` to get the correct MD5 sum. --
Re: Event Dispatcher
On Wednesday, 16 March 2016 at 15:14:57 UTC, Kagamin wrote: On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote: Why not just extend the HelloWorld class and override the hello()? Imagine you write an apllication that should support plugins. And two independent plugins extend the HelloWorld. One plugin would conflict with the another. EventDispatcher make it possible to register the events that can be used by application plugins. How about something like MEF? I didn't know about MEF before, I've just read an article about it, so correct me if I'm wrong. I think that MEF and such event dispatcher aren't comparable. Event dispatching is one of the principles how to extend the application. MEF as Wikipeda states "aims to solve the runtime extensibility problem". The important word is "runtime". So it is a higher level, it is about binding different parts of application at runtime. (As I understand it). Now Symfony, I'm inspired by, has a thing called Bundles. Bundles are just application plugins. And event dispatching can be used inside this bundles aswell. And it is the level where something like MEF would be really great. I think it should be really done, because it would make it possible for example to write closed source plugins for open source applications (it is very common in ecommerce, for example online shops, even for PHP, where you can decode your plugins with something like ioncube). Another area, where it could be used, is routing (already because plugins should be able to add routes to the application at runtime). So concepts like MEF are anyway something very useful for compiled applications/languages and I'll have to find a way to implement it on some stage. Thanks for mentioning it.