Re: LDC now supports Windows MSVC x86/x64 as first class targets

[Manu via Digitalmars-d-announce]

On 22 March 2016 at 03:12, Kagamin via Digitalmars-d-announce
 wrote:
> 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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15819

Timothee Cour  changed:

   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)));

[via Digitalmars-d-bugs]

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)));

[via Digitalmars-d-bugs]

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)));

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15819

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com
   Severity|enhancement |major

--

[Issue 15573] -O -inline causes wrong code with idiv instruction

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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

[Jonathan M Davis via Digitalmars-d]

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

[yeyesnake via Digitalmars-d]

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

[Jakob Ovrum via Digitalmars-d]

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

[tsbockman via Digitalmars-d-learn]

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 ?

[Nicholas Wilson via Digitalmars-d-learn]

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

[via Digitalmars-d-bugs]

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?

[Walter Bright via Digitalmars-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

[deadalnix via Digitalmars-d-announce]

Got the news first hand by David Majnemer first hand not so long 
ago. Congrats guys :)

Re: size_t index=-1;

[tsbockman via Digitalmars-d-learn]

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

[tsbockman via Digitalmars-d]

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;

[Steven Schveighoffer via Digitalmars-d-learn]

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

[Xinok via Digitalmars-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;

[tsbockman via Digitalmars-d-learn]

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

[ref2401 via Digitalmars-d-learn]

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]

[Tamas via Digitalmars-d]

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

[Jonathan M Davis via Digitalmars-d]

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

[FreeSlave via Digitalmars-d]

I made example and described issue in github repository:

https://github.com/MyLittleRobo/dub-coverage-test

Re: size_t index=-1;

[Steven Schveighoffer via Digitalmars-d-learn]

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

[Craig Dillabaugh via Digitalmars-d]

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

[H. S. Teoh via Digitalmars-d]

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

[Atila Neves via Digitalmars-d]

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

[Jacob Carlborg via Digitalmars-d]

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

[tsbockman via Digitalmars-d-learn]

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

[Brad Roberts via Digitalmars-d]

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

[poliklosio via Digitalmars-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

[Daniel Kozak via Digitalmars-d]

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;

[tsbockman via Digitalmars-d-learn]

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

[Daniel Kozak via Digitalmars-d]

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

[Adam D. Ruppe via Digitalmars-d-learn]

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

[wobbles via Digitalmars-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

[via Digitalmars-d-bugs]

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

[Suliman via Digitalmars-d]

Try to look at https://github.com/ljubobratovicrelja/dcv

[Issue 15818] New: Multiple function declarations without definition cause ambiguity overloading error

[via Digitalmars-d-bugs]

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

[Steven Schveighoffer via Digitalmars-d-learn]

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

[Dmitry Olshansky via Digitalmars-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;

[Steven Schveighoffer via Digitalmars-d-learn]

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

[Karabuta via Digitalmars-d-learn]

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

[Kagamin via Digitalmars-d]

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

[Kagamin via Digitalmars-d-announce]

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?

[Bauss via Digitalmars-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

[Guillaume Piolat via Digitalmars-d-announce]

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

[Andrea Fontana via Digitalmars-d-announce]

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

[Guillaume Piolat via Digitalmars-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

[Adam D. Ruppe via Digitalmars-d-learn]

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

[Andrei Alexandrescu via Digitalmars-d]

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15817

Kenji Hara  changed:

   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

[wobbles via Digitalmars-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

[Nordlöw via Digitalmars-d-learn]

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15817

Kenji Hara  changed:

   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

[Nordlöw via Digitalmars-d-learn]

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

[Nordlöw via Digitalmars-d-learn]

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

[Joakim via Digitalmars-d]

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

[Adam D. Ruppe via Digitalmars-d]

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

[Vincent R via Digitalmars-d]

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

[Vincent R via Digitalmars-d]

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

[Craig Dillabaugh via Digitalmars-d]

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?

[denizzzka via Digitalmars-d-learn]

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

[Timothee Cour via Digitalmars-d]

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]

[Seb via Digitalmars-d]

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

[wobbles via Digitalmars-d-learn]

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]

[Timothee Cour via Digitalmars-d]

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

[Nick Treleaven via Digitalmars-d]

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

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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

[Nick Treleaven via Digitalmars-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

[Manuel Maier via Digitalmars-d-announce]

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

[Vincent R via Digitalmars-d]

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

[ZombineDev via Digitalmars-d-learn]

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

[ag0aep6g via Digitalmars-d-learn]

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

[ZombineDev via Digitalmars-d-learn]

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

[Nordlöw via Digitalmars-d-learn]

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

[ZombineDev via Digitalmars-d-learn]

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

[Vincent R via Digitalmars-d]

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

[Martin Tschierschke via Digitalmars-d]

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

[Manuel Maier via Digitalmars-d-announce]

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

[angel via Digitalmars-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

[burjui via Digitalmars-d-announce]

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

[thedeemon via Digitalmars-d-learn]

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5944

Timothee Cour  changed:

   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

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15798

Ender KaShae  changed:

   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

[Eugene Wissner via Digitalmars-d-announce]

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.