Re: Google Summer of Code 2016 Only A Few Hours Left

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-02-22 23:32, jmh530 wrote:

On Monday, 22 February 2016 at 20:00:09 UTC, Dave wrote:


The Stan Math Library is a header-only C++ library as Eigen is. Is
there a chance to port such big libraries including many macros with
htod (unfortunately I do not have a Windows-OS to try it out)?


On posix, you could try dstep.


Unfortunately DStep cannot create bindings for C++. It also doesn't 
handle macros. Handle #define is work in progress.


--
/Jacob Carlborg

Re: C++ UFCS update

[Era Scarecrow via Digitalmars-d]

On Tuesday, 23 February 2016 at 07:22:26 UTC, Ola Fosheim Grøstad 
wrote:
I have to ask: How will adding a new token help us or improve 
the language?


How will it not help?


 How about let's rephrase this as a short example. Let's say we 
add @ for a symbol which by default just duplicates +. So:


 a @ b; //is a + b

 So:

 x[] @ y[] //is legal now too.

 foreach(i,a; x) {
   //I'll assume $ is also the same as multiply, just for fun
   //also no clue what this code would be for
 zz@=x[i@b]@y[i$(b@c)@z]$a;
//vs zz+=x[i+b]+y[i*(b+c)+z]*a;
 }


 If | effectively does the same as . (at least that's the 
impression I get, maybe I'm totally wrong), what benefit does it 
give other than confusing or obfuscating code?


 Before adding it in, I'd need a clean proof of concept of why 
it's a good idea to add.

Re: constant expression

[Ali Çehreli via Digitalmars-d-learn]

On 02/22/2016 11:38 PM, Nicholas Wilson wrote:


I've tried with both mutable and immutable a module scope. Scope I want
is global (don't care about mutability)



Uncomment immutable if you want immutable and remove 'shared' if you 
want multiple of this per thread (probably not).


/* immutable */ string[string] ctodtypes;

shared static this() {
ctodtypes =
[
"void"  : "void",
"uint32_t"  : "uint",
"uint64_t"  : "ulong",
"int32_t"   : "int",
"int64_t"   : "long",
"char"  : "char",
"uint8_t"   : "ubyte",
"size_t": "size_t",
"float" : "float"
 ];
}

void main() {
ctodtypes["hello"] = "world";
}

Ali

Re: constant expression

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 23 February 2016 at 07:26:01 UTC, Ali Çehreli wrote:

On 02/22/2016 09:52 PM, Nicholas Wilson wrote:

How is this not a constant expression ?
auto ctodtypes =
[
 "void"  : "void",
 "uint32_t"  : "uint",
 "uint64_t"  : "ulong",
 "int32_t"   : "int",
 "int64_t"   : "long",
 "char"  : "char",
 "uint8_t"   : "ubyte",
 "size_t": "size_t",
 "float" : "float"
];
dmd complains
source/emit/registryemitter.d(7): Error: non-constant 
expression
["void":"void", "uint32_t":"uint", "uint64_t":"ulong", 
"int32_t":"int",
"int64_t":"long", "char":"char", "uint8_t":"ubyte", 
"size_t":"size_t",

"float":"float"]


Because it's mutable: :)

ctodtypes["hello"] = "world";

What context are you using it in?

Ali


I've tried with both mutable and immutable a module scope. Scope 
I want is global (don't care about mutability)

Re: constant expression

[Ali Çehreli via Digitalmars-d-learn]

On 02/22/2016 09:52 PM, Nicholas Wilson wrote:

How is this not a constant expression ?
auto ctodtypes =
[
 "void"  : "void",
 "uint32_t"  : "uint",
 "uint64_t"  : "ulong",
 "int32_t"   : "int",
 "int64_t"   : "long",
 "char"  : "char",
 "uint8_t"   : "ubyte",
 "size_t": "size_t",
 "float" : "float"
];
dmd complains
source/emit/registryemitter.d(7): Error: non-constant expression
["void":"void", "uint32_t":"uint", "uint64_t":"ulong", "int32_t":"int",
"int64_t":"long", "char":"char", "uint8_t":"ubyte", "size_t":"size_t",
"float":"float"]


Because it's mutable: :)

ctodtypes["hello"] = "world";

What context are you using it in?

Ali

Re: C++ UFCS update

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 22 February 2016 at 10:09:47 UTC, Era Scarecrow wrote:
I have to ask: How will adding a new token help us or improve 
the language?


How will it not help?

Re: [OT] Some neat ideas from the Kotlin language

[rsw0x via Digitalmars-d]

On Tuesday, 23 February 2016 at 06:49:46 UTC, Tobias Müller wrote:

rsw0x  wrote:
On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller 
wrote:

[...]


D has this too, but only for nullable types afaik.

if(byte* ptr = someFunc()){
//...
}




That's not quite the same as there are no non-nullable pointers 
in D.
There's no guarantee from the type system that the byte* is not 
null and

there are no compiler checks involved.
It's a simple runtime check.

OTOH in the examples in Kotlin/Rust the variable 'var' changes 
its type

from 'int?' to plain 'int'.
In Kotlin this is done with static analysis, in Rust with 
rebinding of the

name.

Tobi


Rust's Option checks are not done at compile-time in most 
cases unless something changed drastically in the past ~18 months.

Re: std.experimental.logger.Logger writeLogMsg is @safe?

[Minas Mina via Digitalmars-d-learn]

On Monday, 22 February 2016 at 23:03:38 UTC, Jonathan M Davis 
wrote:
On Monday, February 22, 2016 22:22:01 Minas Mina via 
Digitalmars-d-learn wrote:

[...]


Short answer:

[...]


Great, thanks.

Re: [OT] Some neat ideas from the Kotlin language

[Tobias Müller via Digitalmars-d]

rsw0x  wrote:
> On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller 
> wrote:
>> Yuxuan Shui  wrote:
>>> [...]
>> 
>> In Rust that would be:
>> 
>> let var : Option = ...;
>> if let Some(var) = var {
>> // You can use var here
>> }
>> 
>> It works for every enum (= tagged union), not just Option
>> 
>> Swift also has "if let".
>> 
>> It's not much more verbose but more explicit.
>> Changing the type of a variable based on static analysis is 
>> just advanced
>> obfuscation. It hurts readability and the gain is questionable. 
>> At least it
>> only works for nullable types.
>> 
>> Tobi
> 
> D has this too, but only for nullable types afaik.
> 
> if(byte* ptr = someFunc()){
> //...
> }
> 
> 

That's not quite the same as there are no non-nullable pointers in D.
There's no guarantee from the type system that the byte* is not null and
there are no compiler checks involved.
It's a simple runtime check.

OTOH in the examples in Kotlin/Rust the variable 'var' changes its type
from 'int?' to plain 'int'.
In Kotlin this is done with static analysis, in Rust with rebinding of the
name.

Tobi

constant expression

[Nicholas Wilson via Digitalmars-d-learn]

How is this not a constant expression ?
auto ctodtypes =
[
"void"  : "void",
"uint32_t"  : "uint",
"uint64_t"  : "ulong",
"int32_t"   : "int",
"int64_t"   : "long",
"char"  : "char",
"uint8_t"   : "ubyte",
"size_t": "size_t",
"float" : "float"
];
dmd complains
source/emit/registryemitter.d(7): Error: non-constant expression 
["void":"void", "uint32_t":"uint", "uint64_t":"ulong", 
"int32_t":"int", "int64_t":"long", "char":"char", 
"uint8_t":"ubyte", "size_t":"size_t", "float":"float"]

[Issue 15689] std.typecons.RefCounted doesn't work in ctfe

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #1 from Jack Stouffer  ---
I guess the best solution is to integrate std.experimental.allocator when it
gets moved to std.  The second best would be to add a ctfe check and if true,
then allocate with the GC instead?

--

get stacktrace across all threads

[Timothee Cour via Digitalmars-d-learn]

It would be nice to have an api to get stacktrace across threads; it would
be particularly useful for server applications (eg vibe.d).
Has anyone implemented something similar?
I guess one would need to use signal handlers to interrupt each thread?

Re: [OT] Some neat ideas from the Kotlin language

[Russel Winder via Digitalmars-d]

On Mon, 2016-02-22 at 19:33 +, Ice Create Man via Digitalmars-d
wrote:
> On Thursday, 18 February 2016 at 23:33:45 UTC, Yuxuan Shui wrote:
> > Just come across Kotlin today, and found some interesting ideas 
> > skimming through its tutorial:
> > 
> > [...]
> 
> Both those issues predate both Kotlin and Swift. C# has had both 
> of them for as long as I've been coding in the language. Nothing 
> new here.

But lots of what Kotlin, and Ceylon, are doing are new… on the JVM. I
like new, I like progress and evolution. Just because an idea is not
objectively new, doesn't mean it isn't new and useful. Context and
application can be as refreshing as having a brand new idea. Just think
in programming languages today actors, dataflow, CSP are new, despite
being 50-ish, and 40-ish years old.
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Can D "prevents segfaults, and guarantees thread safety"?

[Chris Wright via Digitalmars-d-learn]

On Tue, 23 Feb 2016 04:28:14 +, mahdi wrote:

> A selling point of Rust language is that it "prevents segfaults,
> and guarantees thread safety". Is there a library in D language which
> provides same features?

D is more for providing safe defaults than for entirely preventing 
problems.

The @safe annotation is intended to provide more guarantees. It allows 
you to dereference null, but otherwise it prevents memory errors (aside 
from some outstanding issues around casting to and from void[]).

Re: Can D "prevents segfaults, and guarantees thread safety"?

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

On Tuesday, 23 February 2016 at 04:28:14 UTC, mahdi wrote:
A selling point of Rust language is that it "prevents 
segfaults, and guarantees thread safety". Is there a library in 
D language which provides same features?


The core d runtime (including the garbage collector) does such 
things.


GC, when used pervasively, eliminates use-after-free bugs. Array 
bounds checking eliminates buffer overflow bugs. Automatic 
initialization of variables covers random pointers that way.


Those are the sources of most security problems in C code (though 
not most segfaults - null is still there, but null usually isn't 
a security problem on desktop and server hardware (idk about 
phones)).


.net, Java, D, javascript, python, the list goes on, these 
languages all do pretty good jobs at taking care of this class of 
bug. It isn't something unique to Rust. (though garbage 
collection is typically a major part of the standard solution, 
and Rust does that differently, that's why it is interesting, not 
that it solves these problems, but that it does it a bit 
differently than the accepted mainstream solution.)


Thread safety is a bit trickier but D's use of default 
thread-local data tries to attack it too.



The problem with D's solution is too many people recommend 
turning them off in the name of performance benchmarks :(

Can D "prevents segfaults, and guarantees thread safety"?

[mahdi via Digitalmars-d-learn]

A selling point of Rust language is that it "prevents segfaults, 
and guarantees thread safety". Is there a library in D language 
which provides same features?

[Issue 14383] [ddoc] documented unittests don't work for module declaration

[via Digitalmars-d-bugs]

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

--- Comment #3 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/ee69cc59c06587a39c7f7603a30ab8a5d0fa2e4e
Fix issue 14383: attach ddoc unittests to module declaration

Turns out that the ddoc code already handles generating docs for module
unittests; all that was missing was that the parser wasn't attaching
these unittests to the module declaration.

https://github.com/D-Programming-Language/dmd/commit/17ae1b37c42a1abed81cce68bcb6c0957e486e5a
Merge pull request #5465 from quickfur/issue14383

Issue 14383: attach ddoc unittests to module declaration

--

Re: Alternate databases

[Andrew Edwards via Digitalmars-d-learn]

On 2/21/16 12:23 AM, yawniek wrote:

On Saturday, 20 February 2016 at 13:09:53 UTC, Andrew Edwards wrote:

I'm searching for client drivers for the following databases. Are the
any available?

https://rethinkdb.com/docs/install-drivers/
http://docs.basho.com/riak/latest/dev/references/client-implementation/

Thanks,
Andrew


none for riak afaik, for rethink i found:

https://github.com/search?utf8=%E2%9C%93=language%3Ad+rethinkdb=Repositories=searchresults


if you try them, please report back if any of them is already usablee



Thank you very much for the links. Will do.

Re: vk.xml

[Nicholas Wilson via Digitalmars-d-learn]

On Monday, 22 February 2016 at 07:00:42 UTC, Nicholas Wilson 
wrote:

On Sunday, 21 February 2016 at 15:18:44 UTC, ZombineDev wrote:

[...]


Thanks for the tips. I used AA and just got it to compile! :) 
:| :( but fails to link.

Undefined symbols for architecture x86_64:
  "_D28TypeInfo_xC4arsd3dom7Element6__initZ", referenced from:
  _D29TypeInfo_AxC4arsd3dom7Element6__initZ in app.o
  "_D4arsd3dom12__ModuleInfoZ", referenced from:
  _D3app12__ModuleInfoZ in app.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)

--- errorlevel 1
any Ideas?

[...]


It was because i was using dmd directly as opposed to dub. Derp!

Re: Unum II announcement

[Charles via Digitalmars-d]

On Monday, 22 February 2016 at 21:27:31 UTC, Nick B wrote:

On Monday, 22 February 2016 at 17:15:54 UTC, Charles wrote:
On Monday, 22 February 2016 at 13:11:47 UTC, Guillaume Piolat 
wrote:


 Slide 12, 0101 is repeated. The top
one should actually be 0111 I believe (this error also 
repeats).


I will check with John re this error.



Aside from that, the notes were super useful, not sure if you 
could add them in there.


Its likely that we can not add the Notes to the PDF, which is 
why I recommended to everyone, to download the presentation, 
and read it via Powerpoint, then you can see all the Notes.


Nick


I saw you looking for heavy math users. I work with quite a few 
actuaries, but I probably wouldn't be able to convince them to 
use anything if there wasn't a way to use it with either SAS or 
R. SAS can import C functions, but that's about it in terms of 
interop.


If you don't find people with D, this might be an opportunity.

Re: Disappointing inflexibility of argument passing with "alias this"

[Jonathan M Davis via Digitalmars-d]

On Monday, 22 February 2016 at 18:28:04 UTC, Dicebot wrote:

On 02/22/2016 08:20 PM, rsw0x wrote:

On Monday, 22 February 2016 at 18:11:58 UTC, H. S. Teoh wrote:
On Mon, Feb 22, 2016 at 06:07:26PM +, rsw0x via 
Digitalmars-d wrote:
On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe 
wrote:

>[...]

explicitly-implicit constructors are badly needed, I could 
write an essay on this


AFAICT, implicit ctors are not supported by design.


T


It is a bad design.


It is arguable opinion.


Yeah. Sometimes having implicit conversions is great. Other 
times, it creates tons of problems. C++ allows a lot of implicit 
stuff, and it becomes really easy to have unexpected conversions 
going on, and it can be difficult to figure out exactly what code 
is being called. For the most part, D doesn't have any of those 
problems, but it arguably loses some usability as a result. So, 
it's highly debatable.


Personally, I think that the big place that implicit conversions 
are a disaster is generic code. It makes it really easy to have 
stuff pass template constraints due to implicit conversions and 
then have the wrong behavior inside the templated code, because 
the conversion is never forced, and it doesn't act the same way 
as it would if the conversion had been forced and possibly even 
ends up being converted for some of expressions in the function 
and not converted in others. For non-templated code, it's a lot 
more debatable, but when it comes to templated code, I really 
wish that alias this didn't exist.


- Jonathan M Davis

Re: Issues

[ag0aep6g via Digitalmars-d-learn]

On 22.02.2016 23:56, Andre wrote:

I was wondering how people in this D community think about the number of
issues with NEW status...

It could scare individuals/organizations to start with D, when they get
the impression that there are a large and growing number of issues that
are open (for years). I know this is not a fair interpretation of what's
going on, but it's a conclusion one could make.


I guess my reopening of issue 4763 [1] got you here. Old issues may be 
embarrassing, but I believe closing them without proper resolution, just 
because they're old, is very bad practice.


Regarding old enhancement request that never got anywhere, it's 
certainly tempting to just throw them away, but I think it's a bad move 
when a single member of the community just closes issues that have been 
filed by someone else. That would make for bad weather in the community.


Instead, I suggest to engage in discussion with the proponent(s) of the 
request. Or implement the request and try to get it merged.



- Is there a preferred way to clean things up?


Fix stuff :P


A resolution status?


Not sure what kind of status you're looking for. There's WONTFIX, but 
you shouldn't apply it just because an issue is old. As far as I know, 
we don't use LATER and REMIND.



A maximum time?


No.


- Or perhaps the bugtracker (https://dlang.org/bugstats.php) needs to be
adjusted for irrelevant things..


What do you mean by "irrelevant"? If you think an issue is irrelevant, 
please argue your point in the comments section of the issue.


Maybe all enhancement requests (that are not closely followed by an 
implementation) are "irrelevant"? I could understand that viewpoint, but 
that's not how we operate at the moment. If you want us to go in that 
direction, ask about it in the General group, and if there's consensus 
to do away with (long-lived) enhancement requests, mass-close them.


By the way, I don't like the bugstats.php page all that much. Some time 
ago I've played around with charts and put this together:


https://issues.dlang.org/chart.cgi?category=D===normal%20bugs=enhancement%20requests=major%20bugs=minor%20bugs=critical%20bugs=blockers=trivial%20bugs=regressions=101=104=100=102=99=98=103=97=98=data%20sets%20by%20severity=wrap=600=650

I think it's more interesting than the one on bugstats.php. But it 
doesn't go back as far - it only started counting when I created it. 
Then I gave up.



- Or is it a non-issue and should we just ignore the tail of the list?


Not ignore it, work towards reducing it by actually resolving stuff.


[1] https://issues.dlang.org/show_bug.cgi?id=4763

Re: Issues

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, February 22, 2016 22:56:26 Andre via Digitalmars-d-learn wrote:
>
> I was wondering how people in this D community think about the
> number of issues with NEW status...
>
> It could scare individuals/organizations to start with D, when
> they get the impression that there are a large and growing number
> of issues that are open (for years). I know this is not a fair
> interpretation of what's going on, but it's a conclusion one
> could make.
>
> - Is there a preferred way to clean things up? A resolution
> status? A maximum time?
>
> - Or perhaps the bugtracker (https://dlang.org/bugstats.php)
> needs to be adjusted for irrelevant things..
>
> - Or is it a non-issue and should we just ignore the tail of the
> list?

Well, if you'll notice th list of resolved issues is going up way faster
than the list of new issues. So, while bugzilla likely could use some effort
on cleaning up bugs in it (which some people do do from time to time), that
chart really doesn't look bad.

- Jonathan M Davis

Re: Issues

[Mathias Lang via Digitalmars-d-learn]

On Monday, 22 February 2016 at 22:56:26 UTC, Andre wrote:


I was wondering how people in this D community think about the 
number of issues with NEW status...




NEW just means 'not resolved'. Things are rarely assigned, and 
usually go straight
from 'NEW' to 'RESOLVED'. An intermediate status, when a PR is 
open, could be assigned by the dlang bot, but I don't know if 
that would bring much.


It could scare individuals/organizations to start with D, when 
they get the impression that there are a large and growing 
number of issues that are open (for years). I know this is not 
a fair interpretation of what's going on, but it's a conclusion 
one could make.


And that's a fair point. Though the number of resolved issues 
grows much faster than the new ones.


- Is there a preferred way to clean things up? A resolution 
status? A maximum time?


It's a case by case basis really. Whenever you hit a new issue, 
search the bug tracker before opening a new one. You might find 
two or more issues related to the same bug. In this case, I 
recommend closing (as DUPLICATE) the one which is either the 
least documented, or the newer one.
Bear in minds issues are not created equals, as some are very 
broad / require significant design adjustment (e.g. 'object is 
not const correct'), while some are trivial (some broken links in 
the doc for example).


Some are also just enhancement request (valid or not), and it 
might be interesting to move them somewhere else (DIP most 
likely).


If you want to help triaging, I suggest going through the bug 
reports and trying to reproduce with the latest release (skipping 
the D1 only bugs). It's quite likely you'll find a decent amount 
of bugs that were already fixed, but hasn't been marked as such. 
You can then try to link them to Github P.R. (if possible) and 
close them.

Re: std.experimental.logger.Logger writeLogMsg is @safe?

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, February 22, 2016 22:22:01 Minas Mina via Digitalmars-d-learn wrote:
> I'm trying to inherit from Logger, and I my custom logger to
> print to stdout using writeln(). But I can't because writeLogMsg
> is @safe, whereas writeln() is @system.
>
> Why is writeLogMsg @safe? This is too restrictive.

Short answer:

Use @trusted on the function overrides.

Long answer:

Well, if the logger isn't @safe, then it can't be easily used in @safe code,
which would be a bit of a disaster, and from what I know of the logger API
(though I'm not super familiar with it), there's really no reason why it
shouldn't be @safe given that it's passing strings along, and derived
classes just need to print those strings. So, derived classes that want to
be @safe just need to be able to operate on strings safely. And if you can't
guarantee that that's @safe, then you have a problem.

Now, obviously writeln isn't @safe (and maybe it should be inferred as such
most of the time, but that's a separate issue), but what you can do so long
as you can guarantee that using writeln is actually @safe (which it should
be if all you're feeding it is strings), then you can mark your overrides
as @trusted, and that should work with inheritance.

- Jonathan M Davis

Issues

[Andre via Digitalmars-d-learn]

I was wondering how people in this D community think about the 
number of issues with NEW status...


It could scare individuals/organizations to start with D, when 
they get the impression that there are a large and growing number 
of issues that are open (for years). I know this is not a fair 
interpretation of what's going on, but it's a conclusion one 
could make.


- Is there a preferred way to clean things up? A resolution 
status? A maximum time?


- Or perhaps the bugtracker (https://dlang.org/bugstats.php) 
needs to be adjusted for irrelevant things..


- Or is it a non-issue and should we just ignore the tail of the 
list?

[Issue 4763] Few possible changes on std.stdio.File

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ag0ae...@gmail.com
 Resolution|FIXED   |---

--- Comment #2 from ag0ae...@gmail.com ---
(In reply to Andre from comment #1)
> Cleanup: issue is very old
> 
> (if any of the proposed changes is still needed, file seperately)

Reopening. Age is not a reason to close issues.

A quick look suggests that the first point is still actual: `open` seems to do
exactly the same as destructing and constructing [1].

Regarding the second point, as Steven Schveighoffer explains in issue 4087,
comment 4, a struct declaration in another one does not make for context
pointers. So that point is invalid.

The suggested code change from the third point has apparently been done [1]. So
that is fixed.

So, what would be left to satisfy this enhancement request would be to
deprecate and subsequently remove std.stdio.File.open. We could of course
create a separate issue for that and close this one. I don't know if that buys
us anything, though.


[1]
https://github.com/D-Programming-Language/phobos/blob/972227d286d2d31b76b32f3bc819e9aa50b8cfb0/std/stdio.d#L472-L476

--

std.experimental.logger.Logger writeLogMsg is @safe?

[Minas Mina via Digitalmars-d-learn]

I'm trying to inherit from Logger, and I my custom logger to 
print to stdout using writeln(). But I can't because writeLogMsg 
is @safe, whereas writeln() is @system.


Why is writeLogMsg @safe? This is too restrictive.

[Issue 4763] Few possible changes on std.stdio.File

[via Digitalmars-d-bugs]

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

Andre  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alver...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Andre  ---
Cleanup: issue is very old

(if any of the proposed changes is still needed, file seperately)

--

[Issue 15714] [ndslice] byElement seems to be missing some slicing primitives

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

Summary|byElement seems to be   |[ndslice] byElement seems
   |missing some slicing|to be missing some slicing
   |primitives  |primitives

--

[Issue 15715] [ndslice] rangeHasMutableElements is not defined

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

Summary|rangeHasMutableElements is  |[ndslice]
   |not defined |rangeHasMutableElements is
   ||not defined

--

Re: Unum II announcement

[Nick B via Digitalmars-d]

On Monday, 22 February 2016 at 17:15:54 UTC, Charles wrote:
On Monday, 22 February 2016 at 13:11:47 UTC, Guillaume Piolat 
wrote:


 Slide 12, 0101 is repeated. The top

one should actually be 0111 I believe (this error also repeats).


I will check with John re this error.



Aside from that, the notes were super useful, not sure if you 
could add them in there.


Its likely that we can not add the Notes to the PDF, which is why 
I recommended to everyone, to download the presentation, and read 
it via Powerpoint, then you can see all the Notes.


Nick

[Issue 15715] New: rangeHasMutableElements is not defined

[via Digitalmars-d-bugs]

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

  Issue ID: 15715
   Summary: rangeHasMutableElements is not defined
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

https://github.com/DlangScience/mir/issues/12

--

[Issue 15714] New: byElement seems to be missing some slicing primitives

[via Digitalmars-d-bugs]

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

  Issue ID: 15714
   Summary: byElement seems to be missing some slicing primitives
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

https://github.com/DlangScience/mir/issues/11

--

[Issue 15540] [ndslice] sliced ignores ReplaceArrayWithPointer for named ranges

[via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Илья Ярошенко  ---
Fixed https://github.com/D-Programming-Language/phobos/pull/3931

--

[Issue 15656] ddox should recognize special meaning of '_' in ddoc, else may generate broken links.

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

  Component|phobos  |dlang.org

--

Re: [OT] Some neat ideas from the Kotlin language

[Yuxuan Shui via Digitalmars-d]

On Monday, 22 February 2016 at 19:33:12 UTC, Ice Create Man wrote:
On Thursday, 18 February 2016 at 23:33:45 UTC, Yuxuan Shui 
wrote:
Just come across Kotlin today, and found some interesting 
ideas skimming through its tutorial:


[...]


Both those issues predate both Kotlin and Swift. C# has had 
both of them for as long as I've been coding in the language. 
Nothing new here.


Sure that Optional types and dynamic casts have been there for 
ages. But this is the first time I see a compiler does the 
unwrapping & casting for you based on static analyses.


And Xinok pointed out we have been using the same technique for 
detecting uninitialized variables, so what Kotlin does can be 
seen as a small, but clever, extension of this.

Re: [OT] Some neat ideas from the Kotlin language

[Ice Create Man via Digitalmars-d]

On Thursday, 18 February 2016 at 23:33:45 UTC, Yuxuan Shui wrote:
Just come across Kotlin today, and found some interesting ideas 
skimming through its tutorial:


[...]


Both those issues predate both Kotlin and Swift. C# has had both 
of them for as long as I've been coding in the language. Nothing 
new here.

Re: Simple performance question from a newcomer

[sigod via Digitalmars-d-learn]

On Sunday, 21 February 2016 at 16:20:30 UTC, bachmeier wrote:

On Sunday, 21 February 2016 at 14:32:15 UTC, dextorious wrote:
I had heard while reading up on the language that in D 
explicit loops are generally frowned upon and not necessary 
for the usual performance reasons.


First, a minor point, the D community is usually pretty careful 
not to frown on a particular coding style (unlike some 
communities) so if you are comfortable writing loops and it 
gives you the fastest code, you should do so.


On the performance issue, you can see this related post about 
performance with reduce:

http://forum.dlang.org/post/mailman.4829.1434623275.7663.digitalmar...@puremagic.com

This was Walter's response:
http://forum.dlang.org/post/mlvb40$1tdf$1...@digitalmars.com

And this shows that LDC flat out does a better job of 
optimization in this case:

http://forum.dlang.org/post/mailman.4899.1434779705.7663.digitalmar...@puremagic.com


I can't agree with that. Between `for` and `foreach` you should 
choose one that is more readable/understandable for particular 
situation. It's compiler's task to optimize such small things.

Re: compilation issues (dmd, rdmd, ldc2)

[kraxli via Digitalmars-d-learn]

On Sunday, 21 February 2016 at 22:53:17 UTC, anonymous wrote:

On 21.02.2016 22:51, kraxli wrote:


Great this all works and good to know that D links as basic 
gcc/llvm link. Thanks a lot to everybody - very helpful!

Re: Unum II announcement

[Guillaume Piolat via Digitalmars-d]

On Monday, 22 February 2016 at 17:42:07 UTC, Basile Burg wrote:


"Reverse all bits but the first one and add 1, to reciprocate. 
Works without exception. +1 and –1 do not change."


There's magic out there ;)


What I don't get is: is there an exposant anymore? I don't see 
any mention of it.

Re: Disappointing inflexibility of argument passing with "alias this"

[Adam D. Ruppe via Digitalmars-d]

On Monday, 22 February 2016 at 18:11:58 UTC, H. S. Teoh wrote:

AFAICT, implicit ctors are not supported by design.


I agree with them that implicitly implicit ctors are a bad 
design, but explicitly implicit ctors I think are a different 
issue because then it is clear that the designer intended it and 
we can ask if it is sane to use or not.


Explicitly implicit ctors are like:

struct Foo {
   @implicit this(int a) {}
}

since it has the attribute, the compiler will allow it to be used 
when calling a function that expects a Foo using an int (unless 
some other thing matches better).


Calling that explicitly is already allowed:

Foo a = 1; // works with that now

Re: Disappointing inflexibility of argument passing with "alias this"

[Dicebot via Digitalmars-d]

On 02/22/2016 08:20 PM, rsw0x wrote:
> On Monday, 22 February 2016 at 18:11:58 UTC, H. S. Teoh wrote:
>> On Mon, Feb 22, 2016 at 06:07:26PM +, rsw0x via Digitalmars-d wrote:
>>> On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote:
>>> >[...]
>>>
>>> explicitly-implicit constructors are badly needed, I could write an
>>> essay on this
>>
>> AFAICT, implicit ctors are not supported by design.
>>
>>
>> T
> 
> It is a bad design.

It is arguable opinion.

Re: Disappointing inflexibility of argument passing with "alias this"

[H. S. Teoh via Digitalmars-d]

On Mon, Feb 22, 2016 at 06:20:09PM +, rsw0x via Digitalmars-d wrote:
> On Monday, 22 February 2016 at 18:11:58 UTC, H. S. Teoh wrote:
> >On Mon, Feb 22, 2016 at 06:07:26PM +, rsw0x via Digitalmars-d wrote:
> >>On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote:
> >>>[...]
> >>
> >>explicitly-implicit constructors are badly needed, I could write an
> >>essay on this
> >
> >AFAICT, implicit ctors are not supported by design.
> >
> >
> >T
> 
> It is a bad design.

Don't shoot the messenger. Take it up with Walter / Andrei.


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- 
Napoleon Bonaparte

Re: Disappointing inflexibility of argument passing with "alias this"

[rsw0x via Digitalmars-d]

On Monday, 22 February 2016 at 18:11:58 UTC, H. S. Teoh wrote:
On Mon, Feb 22, 2016 at 06:07:26PM +, rsw0x via 
Digitalmars-d wrote:
On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe 
wrote:

>[...]

explicitly-implicit constructors are badly needed, I could 
write an essay on this


AFAICT, implicit ctors are not supported by design.


T


It is a bad design.

Re: Disappointing inflexibility of argument passing with "alias this"

[H. S. Teoh via Digitalmars-d]

On Mon, Feb 22, 2016 at 06:07:26PM +, rsw0x via Digitalmars-d wrote:
> On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote:
> >On Monday, 22 February 2016 at 17:22:51 UTC, Carl Sturtivant wrote:
> >>struct Test { int i; alias i this; }
> >>[...]
> >>The assignment is fine, but the call is rejected by dmd.
> >
> >
> >Test t = 1;
> >
> >is rejected too because alias this is not a constructor and a
> >function call would be construction.
> >
> >I do think it would be very nice to have explicitly implicit
> >constructors which would cover both these cases (then we can do
> >user-defined types that accept the null literal in function calls too
> >just like built in arrays!), but I don't think it has anything to do
> >with alias this.
> 
> explicitly-implicit constructors are badly needed, I could write an
> essay on this

AFAICT, implicit ctors are not supported by design.


T

-- 
Ruby is essentially Perl minus Wall.

Re: Disappointing inflexibility of argument passing with "alias this"

[rsw0x via Digitalmars-d]

On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote:
On Monday, 22 February 2016 at 17:22:51 UTC, Carl Sturtivant 
wrote:

struct Test { int i; alias i this; }
[...]
The assignment is fine, but the call is rejected by dmd.



Test t = 1;

is rejected too because alias this is not a constructor and a 
function call would be construction.


I do think it would be very nice to have explicitly implicit 
constructors which would cover both these cases (then we can do 
user-defined types that accept the null literal in function 
calls too just like built in arrays!), but I don't think it has 
anything to do with alias this.


explicitly-implicit constructors are badly needed, I could write 
an essay on this

Re: @mutable

[Nick Treleaven via Digitalmars-d]

On Monday, 22 February 2016 at 17:28:03 UTC, Guillaume Chatelet 
wrote:

static make() {


The return type is missing for the make() function:


I'm pretty sure static here works just like 'static auto'. In D I 
think you can use storage classes (and even attributes) to imply 
auto:


const foo(){return 5;}

assert(foo() == 5);

Re: Unum II announcement

[Basile Burg via Digitalmars-d]

On Monday, 22 February 2016 at 05:08:13 UTC, Nick B wrote:
"For those of you who think you have already seen unums, this 
is a different approach. Every one of the slides here is 
completely new and has not been presented before the Multicore 
2016 conference [in Wgtn, NZ]."


Here is the link as promised to the new presentation by John 
Gustafson:

http://www.johngustafson.net/unums.html


I strongly recommend that you download the presentation 
[Powerpoint, 35 pages] as there are lots of Notes with the 
presentation.


Note that the previous thread re Unums, can be found here:
https://forum.dlang.org/thread/quzsjahniokjotvta...@forum.dlang.org


I welcome any feedback, especially from Walter or Andrei.


cheers Nick


"Reverse all bits but the first one and add 1, to reciprocate. 
Works without exception. +1 and –1 do not change."


There's magic out there ;)

Re: Disappointing inflexibility of argument passing with "alias this"

[Adam D. Ruppe via Digitalmars-d]

On Monday, 22 February 2016 at 17:22:51 UTC, Carl Sturtivant 
wrote:

struct Test { int i; alias i this; }
[...]
The assignment is fine, but the call is rejected by dmd.



Test t = 1;

is rejected too because alias this is not a constructor and a 
function call would be construction.


I do think it would be very nice to have explicitly implicit 
constructors which would cover both these cases (then we can do 
user-defined types that accept the null literal in function calls 
too just like built in arrays!), but I don't think it has 
anything to do with alias this.

Re: @mutable

[Guillaume Chatelet via Digitalmars-d]

static make() {


The return type is missing for the make() function:

Disappointing inflexibility of argument passing with "alias this"

[Carl Sturtivant via Digitalmars-d]

struct Test { int i; alias i this; }
auto testFunct( Test i){ }

void main() {
Test t;
t = 1;
testFunct( 1);
}


The assignment is fine, but the call is rejected by dmd.

See also
http://forum.dlang.org/post/fqfonkcdcjuwbaacq...@forum.dlang.org

Re: Unum II announcement

[Charles via Digitalmars-d]

On Monday, 22 February 2016 at 13:11:47 UTC, Guillaume Piolat 
wrote:
On Monday, 22 February 2016 at 11:34:25 UTC, Guillaume Piolat 
wrote:
PDF link: 
http://www.pdf-archive.com/2016/02/22/multicore2016-jlg/multicore2016-jlg.pdf


Just a heads up:

Unfortunately there's an issue with the fonts as well as some 
typos in this.


Ex: Slide 3 the infinity and minus signs don't show up in symbol 
font on my PC (Win7 w/ Office 2013). This reoccurs for every copy 
of the diagram. Slide 12, 0101 is repeated. The top one should 
actually be 0111 I believe (this error also repeats).


Aside from that, the notes were super useful, not sure if you 
could add them in there.

Re: GSoC Deadline Friday

[Bruno Medeiros via Digitalmars-d-announce]

On 16/02/2016 13:46, Craig Dillabaugh wrote:

The Google Summer of Code deadline is this Friday.

I would like confirmation from the following individuals if they can
mentor GSOC this summer.

Iain Buclaw
Bruno Medeiros
Martin Nowak (and as backup Admin)
Jacob Ovrum

And as backup mentors
   Adam D. Ruppe
   Dmitry Olshansky

I know for some of you (Iain) the offer to mentor was a 'standing offer'
of sorts, but it would still be good to get confirmation. Also the
poster 'Dragos Carp' volunteered as a possible mentor for the Protocol
Buffers/Flatbuffers work ... so could you please add a short bio to the
mentor's page (or post something here):

http://wiki.dlang.org/GSOC_mentors

We have a decent number of ideas, but the page could use some work.

http://wiki.dlang.org/GSOC_2016_Ideas

In particular if you can add info to the 'Its Good To Know' sections
(such as links to DConf videos), or flesh out some existing ideas that
help is welcome.  I will continue to try and improve that page.


Nope, I won't be available to mentor GSoC this year I'm afraid.

--
Bruno Medeiros
https://twitter.com/brunodomedeiros

Re: Google Summer of Code 2016 Only A Few Hours Left

[jmh530 via Digitalmars-d-announce]

On Friday, 19 February 2016 at 21:10:45 UTC, Dave wrote:


Good starting points for a GSOC project would be "to port" 
mc-stan.org or some optimization algorithms from Coin-OR.org 
(please let me be more particular and independent of existing 
work if there is any interest for such a project!).


This is what I was talking about:
https://code.dlang.org/packages/libnlopt
https://code.dlang.org/packages/nloptd

Re: Simple performance question from a newcomer

[dextorious via Digitalmars-d-learn]

On Sunday, 21 February 2016 at 16:20:30 UTC, bachmeier wrote:
First, a minor point, the D community is usually pretty careful 
not to frown on a particular coding style (unlike some 
communities) so if you are comfortable writing loops and it 
gives you the fastest code, you should do so.


On the performance issue, you can see this related post about 
performance with reduce:

http://forum.dlang.org/post/mailman.4829.1434623275.7663.digitalmar...@puremagic.com

This was Walter's response:
http://forum.dlang.org/post/mlvb40$1tdf$1...@digitalmars.com

And this shows that LDC flat out does a better job of 
optimization in this case:

http://forum.dlang.org/post/mailman.4899.1434779705.7663.digitalmar...@puremagic.com


While I certainly do not doubt the open mindedness of the D 
community, it was in part Walter Bright's statement during a 
keynote speech of how "loops are bugs" that motivated me to look 
at D for a fresh approach to writing numerical code. For decades, 
explicit loops have been the only way to attain good performance 
for certain kinds of code in virtually all languages (discounting 
a few quirky high level languages like MATLAB) and the notion 
that this need not be the case is quite attractive to many 
people, myself included.


While the point Walter makes, that there is no mathematical 
reason ranges should be slower than loops and that loops are 
generally easier to get wrong is certainly true, D is the first 
general purpose language I've ever seen that makes this sentiment 
come close to reality.

Re: Simple performance question from a newcomer

[dextorious via Digitalmars-d-learn]

First of all, I am pleasantly surprised by the rapid influx of 
helpful responses. The community here seems quite wonderful. In 
the interests of not cluttering the thread too much, since the 
advice given here has many commonalities, I will only try to 
respond once to each type of suggestion.


On Sunday, 21 February 2016 at 16:29:26 UTC, ZombineDev wrote:
The problem is not with ranges, but with the particualr 
algorithm used for summing. If you look at the docs 
(http://dlang.org/phobos-prerelease/std_algorithm_iteration.html#.sum) you'll see that if the range has random-access `sum` will use the pair-wise algorithm. About the second and third tests, the problem is with DMD which should not be used when measuring performance (but only for development, because it has fast compile-times).

...
According to `dub --verbose`, my command-line was roughly this:
ldc2 -ofapp -release -O5 -singleobj -w source/app.d
../../../../.dub/packages/mir-0.10.1-alpha/source/mir/ndslice/internal.d
../../../../.dub/packages/mir-0.10.1-alpha/source/mir/ndslice/iteration.d
../../../../.dub/packages/mir-0.10.1-alpha/source/mir/ndslice/package.d
../../../../.dub/packages/mir-0.10.1-alpha/source/mir/ndslice/selection.d
../../../../.dub/packages/mir-0.10.1-alpha/source/mir/ndslice/slice.d


It appears that I cannot use the GDC compiler for this particular 
problem due to it using a comparatively older version of the DMD 
frontend (I understand Mir requires >=2.068), but I did manage to 
get LDC working on my system after a bit of work. Since I've been 
using dub to manage my project, I used the default "release" 
build type. I also tried compiling manually with LDC, using the 
-O5 switch you mentioned. These are the results (I increased the 
iteration count to lessen the noise, the array is now 1x20, 
each function is run a thousand times):


DMDLDC (dub)LDC (-release -enable-inlining 
-O5 -w -singleobj)

sumtest1:12067 ms  6899 ms  1940 ms
sumtest2: 3076 ms  1349 ms   452 ms
sumtest3: 2526 ms   847 ms   434 ms
sumtest4: 5614 ms  1481 ms   452 ms

The sumtest1, 2 and 3 functions are as given in the first post, 
sumtest4 uses the range.reduce!((a, b) => a + b) approach to 
enforce naive summation. Much to my satisfaction, the 
range.reduce version is now exactly as quick as the traditional 
loop and while function inlining isn't quite perfect, the 4% 
performance penalty incurred by the 10_000 function calls (or 
whatever inlined form the function finally takes) is quite 
acceptable.


I do have to wonder, however, about the default settings of dub 
in this case. Having gone through its documentation, I might 
still not have guessed to try the compiler options you provided, 
thereby losing out on a 2-3x performance improvement. What build 
options did you use in your dub.json that it managed to translate 
to the correct compiler switches?

Re: constructing module level immutable variables at runtime?

[Steven Schveighoffer via Digitalmars-d]

On 2/22/16 9:58 AM, Danni Coy via Digitalmars-d wrote:

That worked however it seems that you can only do the assignments
within the shared static this() and not from functions called by the
initialiser which might change how I do things



This is true. The compiler wants to be super-sure that you are only 
setting it once.


However, this can be alleviated by changing how you do things. Factor 
out the code that sets it, and have it instead return a value. Then you 
can do this:


shared static this() {
   num_triggers = myCrazyFunction();
}

Of course, myCrazyFunction must not depend on any other static 
variables, as those might not be initialized.


startup initialization can be very tricky.

-Steve

Re: constructing module level immutable variables at runtime?

[Danni Coy via Digitalmars-d]

That worked however it seems that you can only do the assignments
within the shared static this() and not from functions called by the
initialiser which might change how I do things

Re: constructing module level immutable variables at runtime?

[Steven Schveighoffer via Digitalmars-d]

On 2/22/16 2:36 AM, Danni Coy via Digitalmars-d wrote:

On Mon, Feb 22, 2016 at 5:29 PM, Sönke Ludwig
 wrote:

I was wrong, there is obviously a language/compiler bug here. It compiles if
you remove the "= void", but it does so for "shared static this" as well as
for "static this". It really shouldn't in the latter case.


Interesting... It definately seems like should work when explicitly
asking the variable not the instantiated and not in a thread local
initialiser.



I'm not sure the =void has any effect anyway, it's likely just going to 
write the entire static segment with some initial value.


So I'd say remove the =void, and you should be good.

-Steve

Re: template mixins vs alias

[Daniel Kozak via Digitalmars-d-learn]

In your case I would guess with -O -release -inline it would generate 
assambly with same (similar) speed.


But in this case it would be different:

mixin template Test()
{
int returnInit() { return int.init; }
}


int returnInitImpl() { return int.init; }


class A
{
mixin Test!(); // add virtual method
}

class B
{
alias returnInit = returnInitImpl;
}


import std.stdio;

void main()
{
auto a = new A();
auto b = new B();

a.returnInit().writeln;
b.returnInit().writeln;
}

Dne 22.2.2016 v 15:12 Andrea Fontana via Digitalmars-d-learn napsal(a):

On Monday, 22 February 2016 at 13:56:19 UTC, anonymous wrote:

On Monday, 22 February 2016 at 13:35:10 UTC, Andrea Fontana wrote:

Check this code:
http://dpaste.dzfl.pl/fcf876acbbdc

Structs A and B do the same things, in different way.

Is there any difference/limitation between those?

Andrea


The mixin variant generates a method. That means, you can reference 
members of the struct in the function.


Of course, but that's not the case.

What's nicer about the alias version is that you see what symbol is 
being generated. It's obvious that `alias returnInit = 
returnInitImpl!int;` creates a symbol "returnInit". In the mixin 
variant, you have to read the template's source to see that.


I wonder whether one version generates faster assembly or not.

Re: Qt's MOC getting replicated in D for Calypso

[Dicebot via Digitalmars-d-announce]

On 02/22/2016 12:20 PM, Dicebot wrote:
> The very reason why Calypso doesn't work with C++ so well is also the
> reason why you won't be able to generate bindings easily - it calls C++
> code directly without creating intermediate D interface in any form.

Typo: "very reason why Calypso DOES work with C++ so well"

Re: Qt's MOC getting replicated in D for Calypso

[bachmeier via Digitalmars-d-announce]

On Monday, 22 February 2016 at 10:20:35 UTC, Dicebot wrote:

The very reason why Calypso doesn't work with C++ so well is 
also the reason why you won't be able to generate bindings 
easily - it calls C++ code directly without creating 
intermediate D interface in any form.


I wanted to clarify that it doesn't currently claim to be a tool 
for creating C++ bindings, so as not to mislead someone trying 
out the language.

Re: Decoding Pattern to a Tuple

[Artur Skawina via Digitalmars-d-learn]

On 02/19/16 19:10, Nordlöw via Digitalmars-d-learn wrote:
> Have anybody put together a generalised form of findSplit that can split and 
> decode using a compile time parameters somewhat like
> 
> "(1)-(2.0)".decode!("(", int, ")", char, "(", double, ")")
> 
> evaluates to
> 
> to a
> 
> tuple!(int, char, double)
> 
> with value
> 
> tuple(1, '-', 2.0)

In practice, that isn't necessarily a good idea, because this kind
of project-local helpers add a level of obfuscation. But as the
language is missing /real/ pattern-matching, this functionality is
reinvented again and again. Here's a simple version that takes a
single pattern string with the individual patterns placed between
"{%" and "%}", and that doesn't support `char` directly (char can be
easily gotten from the string).

   template decode(string P, alias S) {
  alias T(A...) = A;
  static if (P.length) {
 import std.algorithm, std.conv;
 enum PS = findSplit(P, `{%`);
 static assert (PS[0]==S[0..PS[0].length]);
 enum PE = findSplit(PS[2], `%}`);
 enum PP = findSplit(PE[2], "{%")[0];
 enum SS = findSplit(S[PS[0].length..$], PP);
 alias decode = T!(mixin(`to!(`~PE[0]~`)(SS[0])`), 
decode!(PE[2][PP.length..$], SS[2]));
  }
  else
 alias decode = T!();
   }

   enum a = decode!("({%int%}){%string%}({%double%})", "(1)-(2.0)");
   pragma(msg, typeof(a));
   pragma(msg, a);


Just a POC hack; don't use as-is; does not support user defined types
(it would have to be a mixin to be able to do that).

artur

Re: template mixins vs alias

[Andrea Fontana via Digitalmars-d-learn]

On Monday, 22 February 2016 at 13:56:19 UTC, anonymous wrote:
On Monday, 22 February 2016 at 13:35:10 UTC, Andrea Fontana 
wrote:

Check this code:
http://dpaste.dzfl.pl/fcf876acbbdc

Structs A and B do the same things, in different way.

Is there any difference/limitation between those?

Andrea


The mixin variant generates a method. That means, you can 
reference members of the struct in the function.


Of course, but that's not the case.

What's nicer about the alias version is that you see what 
symbol is being generated. It's obvious that `alias returnInit 
= returnInitImpl!int;` creates a symbol "returnInit". In the 
mixin variant, you have to read the template's source to see 
that.


I wonder whether one version generates faster assembly or not.

Re: [WIP] Native SQLite Database reader (works at CTFE)

[Stefan Koch via Digitalmars-d]

Another small update.

So far ldc has the lead in my performance test
ldc2 produces significantly faster results then gdc or dmd.
I will have a look at the IR and see how I can "port" the 
optimisations it does to the sourceCode.

Re: Running DMD tests on Windows / build requirements

[Daniel Murphy via Digitalmars-d]

On 22/02/2016 5:42 AM, Vladimir Panteleev wrote:

On Saturday, 20 February 2016 at 13:41:36 UTC, Martin Krejcirik wrote:

Dne 20. 2. 2016 v 13:40 kinke napsal(a):

You may want to have a look at
http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC#Running_the_dmd-testsuite_tests
for some tools prerequisites.


I have gnu make, but it doesn't work:

D:\prac4\dmd\test>make -f Makefile
Creating output directory: test_results
! was unexpected at this time.
make: *** [test_results/.created] Error 255


I believe you need to run the tests from a POSIX environment, e.g.
Cygwin or MSYS.

The error message indicates that it attempted to execute a command with
POSIX shell syntax using the Windows command interpreter.



I've been using my own test runner for years.  I probably should try and 
push some of this upstream at some point...


test.bat (in dmd/src)
@echo off
start runtest %*

runtest.bat (in dmd/src)
@echo off
cd ..\test
copy ..\src\dmd.exe .\
copy ..\..\phobos\phobos.lib .\
dir *.d /s/b > alltests.txt
dmd d_do_test2
d_do_test2 %*
pause
exit

And d_do_test2.d (in dmd/test) (attached)

Run like
test
or
test fast

from dmd/src

It works, mostly
module d_do_test;

import std.algorithm;
import std.array;
import std.conv;
import std.exception;
import std.file;
import std.format;
import std.process;
import std.random;
import std.regex;
import std.stdio;
import std.string;
import core.sys.posix.sys.wait;

void usage()
{
write("d_do_test   \n"
  "\n"
  "   input_dir: one of: compilable, fail_compilation, runnable\n"
  "   test_name: basename of test case to run\n"
  "   test_extension: one of: d, html, or sh\n"
  "\n"
  "   example: d_do_test runnable pi d\n"
  "\n"
  "   relevant environment variables:\n"
  "  ARGS:  set to execute all combinations of\n"
  "  REQUIRED_ARGS: arguments always passed to the compiler\n"
  "  DMD:   compiler to use, ex: ../src/dmd\n"
  "  CC:C++ compiler to use, ex: dmc, g++\n"
  "  OS:win32, win64, linux, freebsd, osx\n"
  "  RESULTS_DIR:   base directory for test results\n"
  "   windows vs non-windows portability env vars:\n"
  "  DSEP:   or /\n"
  "  SEP:   \\ or /\n"
  "  OBJ:  .obj or .o\n"
  "  EXE:  .exe or \n");
}

enum TestMode
{
COMPILE,
FAIL_COMPILE,
RUN
}

struct TestArgs
{
TestMode mode;

bool compileSeparately;
string   executeArgs;
string[] sources;
string[] cppSources;
string[] objcSources;
string   permuteArgs;
string   compileOutput;
string   gdbScript;
string   gdbMatch;
string   postScript;
string   requiredArgs;
string   requiredArgsForLink;
// reason for disabling the test (if empty, the test is not disabled)
string[] disabledPlatforms;
bool disabled;
}

struct EnvData
{
string all_args;
string dmd;
string results_dir;
string sep;
string dsep;
string obj;
string exe;
string os;
string compiler;
string ccompiler;
string model;
string required_args;
bool dobjc;
}

bool findTestParameter(string file, string token, ref string result)
{
auto tokenStart = std.string.indexOf(file, token);
if (tokenStart == -1) return false;

auto lineEndR = std.string.indexOf(file[tokenStart .. $], "\r");
auto lineEndN = std.string.indexOf(file[tokenStart .. $], "\n");
auto lineEnd  = lineEndR == -1 ?
(lineEndN == -1 ? file.length : lineEndN) :
(lineEndN == -1 ? lineEndR: min(lineEndR, lineEndN));

//writeln("found ", token, " in line: ", file.length, ", ", tokenStart, ", 
", tokenStart+lineEnd);
//writeln("found ", token, " in line: '", file[tokenStart .. 
tokenStart+lineEnd], "'");

result = strip(file[tokenStart+token.length .. tokenStart+lineEnd]);
// skips the :, if present
if (result.length > 0 && result[0] == ':')
result = strip(result[1 .. $]);

//writeln("arg: '", result, "'");

string result2;
if (findTestParameter(file[tokenStart+lineEnd..$], token, result2))
result ~= " " ~ result2;

return true;
}

bool findOutputParameter(string file, string token, out string result, string 
sep)
{
bool found = false;

while (true)
{
auto istart = std.string.indexOf(file, token);
if (istart == -1)
break;
found = true;

// skips the :, if present
if (file[istart] == ':') ++istart;

enum embed_sep = "---";
auto n = std.string.indexOf(file[istart .. $], embed_sep);

enforce(n != -1, "invalid "~token~" format");
istart += n + embed_sep.length;
while (file[istart] == '-') ++istart;
if (file[istart] == '\r') ++istart;
if (file[istart] == '\n') ++istart;

auto 

Re: template mixins vs alias

[anonymous via Digitalmars-d-learn]

On Monday, 22 February 2016 at 13:35:10 UTC, Andrea Fontana wrote:

Check this code:
http://dpaste.dzfl.pl/fcf876acbbdc

Structs A and B do the same things, in different way.

Is there any difference/limitation between those?

Andrea


The mixin variant generates a method. That means, you can 
reference members of the struct in the function.


Silly example:

mixin template Test(T)
{
auto returnX() { return x; }
}
struct A
{
int x;
mixin Test!int;
}


With the alias variant you get an alias to a free function, not a 
method. So you couldn't reference x like above.


What's nicer about the alias version is that you see what symbol 
is being generated. It's obvious that `alias returnInit = 
returnInitImpl!int;` creates a symbol "returnInit". In the mixin 
variant, you have to read the template's source to see that.

IDE - Coedit 2 update 1

[Basile Burg via Digitalmars-d-announce]

This is a hotfix release that you should consider seriously only 
if you use CE, particularly under a linux system, otherwise it 
doesn't matter that much.


see https://github.com/BBasile/Coedit/releases/tag/2_update_1

template mixins vs alias

[Andrea Fontana via Digitalmars-d-learn]

Check this code:
http://dpaste.dzfl.pl/fcf876acbbdc

Structs A and B do the same things, in different way.

Is there any difference/limitation between those?

Andrea

Re: Unum II announcement

[Guillaume Piolat via Digitalmars-d]

On Monday, 22 February 2016 at 11:34:25 UTC, Guillaume Piolat 
wrote:

On Monday, 22 February 2016 at 05:08:13 UTC, Nick B wrote:
Here is the link as promised to the new presentation by John 
Gustafson:

http://www.johngustafson.net/unums.html


I strongly recommend that you download the presentation 
[Powerpoint, 35 pages] as there are lots of Notes with the 
presentation.




This looks way better than the previous iteration. Waiting for 
more written material. Definately worth a second look.


PDF link: 
http://www.pdf-archive.com/2016/02/22/multicore2016-jlg/multicore2016-jlg.pdf

[Issue 15581] foreach should avoid bounds checking

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
 Status|NEW |RESOLVED
   Hardware|x86_64  |All
 Resolution|--- |FIXED

--

[Issue 15581] foreach should avoid bounds checking

[via Digitalmars-d-bugs]

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

--- Comment #1 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/b2cfb9bd01c33b873ca9e7a6c9be986a5feac00a
Issue 15581: Disabling bounds checking in ForEachStatement

https://github.com/D-Programming-Language/dmd/commit/3002a9683619957ce0d3f1379f99970f1664d087
Merge pull request #5470 from gchatelet/disable_bounds_checking_in_foreach

Issue 15581: Disabling bounds checking in ForEachStatement

--

Re: Unum II announcement

[Guillaume Piolat via Digitalmars-d]

On Monday, 22 February 2016 at 05:08:13 UTC, Nick B wrote:
Here is the link as promised to the new presentation by John 
Gustafson:

http://www.johngustafson.net/unums.html


I strongly recommend that you download the presentation 
[Powerpoint, 35 pages] as there are lots of Notes with the 
presentation.




This looks way better than the previous iteration. Waiting for 
more written material. Definately worth a second look.

Re: Qt's MOC getting replicated in D for Calypso

[Dicebot via Digitalmars-d-announce]

On 02/22/2016 01:30 AM, bachmeier wrote:
> On Sunday, 21 February 2016 at 22:23:10 UTC, Kagamin wrote:
>> On Sunday, 21 February 2016 at 17:21:51 UTC, Brad Roberts wrote:
>>> Is there anything preventing Calypso from turning into a code and
>>> interface generator?  Making it an application that is part of the
>>> build rather than a plug in to ldc would make it available to both
>>> dmd and gdc users, no?
>>
>> That's DStep: https://github.com/jacob-carlborg/dstep
> 
> I don't think that works for C++, and it's not complete.

The very reason why Calypso doesn't work with C++ so well is also the
reason why you won't be able to generate bindings easily - it calls C++
code directly without creating intermediate D interface in any form.

Re: Qt's MOC getting replicated in D for Calypso

[Kagamin via Digitalmars-d-announce]

On Sunday, 21 February 2016 at 23:30:14 UTC, bachmeier wrote:

I don't think that works for C++, and it's not complete.


At least it's intended to generate bindings, Calypso does very 
different thing. So if one wants bindings generation, it would be 
easier to implement missing functionality in DStep.

Re: C++ UFCS update

[Era Scarecrow via Digitalmars-d]

On Monday, 22 February 2016 at 08:07:03 UTC, Ola Fosheim Grøstad 
wrote:
Adding a new token is done in less than an hour, and a 
non-breaking change...


I have to ask: How will adding a new token help us or improve the 
language?

Re: Neovim autocompletion using deoplete

[Idan Arye via Digitalmars-d]

On Sunday, 21 February 2016 at 22:56:23 UTC, landaire wrote:

On Sunday, 21 February 2016 at 19:46:50 UTC, Idan Arye wrote:


No offense LoL. People who have time to get offended by 
hearing their project is inferior to another project, should 
better use that time to improve that project of them!


I'm not sure where I said or how you got the idea I was 
offended, but thanks for the encouragement.


Sorry, I thought my English was better than that... I meant "not 
offense taken"...

Re: Decoding Pattern to a Tuple

[Nordlöw via Digitalmars-d-learn]

On Friday, 19 February 2016 at 22:16:10 UTC, Ali Çehreli wrote:

On 02/19/2016 11:04 AM, Ali Çehreli wrote:

> can be templatized:

Not ready for prime time but now it's templatized:


Thanks!

Re: C++ UFCS update

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 21 February 2016 at 22:32:23 UTC, Walter Bright wrote:
I'm not thrilled about overloading | with a non-arithmetic 
purpose. I hated iostreams' use of << from the beginning.


Adding a new token is done in less than an hour, and a 
non-breaking change...