Re: Option types and pattern matching.

[Rikki Cattermole via Digitalmars-d]

On 25/10/15 7:05 PM, Nerve wrote:

On Sunday, 25 October 2015 at 05:53:32 UTC, Rikki Cattermole wrote:

I'm pretty sure e.g. opEquals/opCmp should work here.
Shouldn't need to switch upon a primitive type. Theoretically could do
it on a e.g. struct. Which has the special comparison that you want.


Hm...these are boolean operators. This means we can only compare two
cases at a time, does it not? Negates the strength of a switch/pattern
match, unless there's something I'm missing.


Well you only need to compare two cases.
I need to spend a bit of time, to see if what I think can be done, is 
actually possible. Essentially toying with your 'Some' types comparison 
rules.



What are these variable length structs you mention, and their special
comparisons? How would we use them?


Oh the idea was a complete flop. It's just an example of how welcoming 
ideas are. Just no guarantee they'll make it to even a consideration 
from Walter.

Re: `clear`ing a dynamic array

[qsdfghjk via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 13:18:26 UTC, Shriramana Sharma 
wrote:
Hello. I had first expected that dynamic arrays (slices) would 
provide a `.clear()` method but they don't seem to. Obviously I 
can always effectively clear an array by assigning an empty 
array to it, but this has unwanted consequences that `[]` 
actually seems to allocate a new dynamic array and any other 
identifiers initially pointing to the same array will still 
show the old contents and thus it would no longer test true for 
`is` with this array. See the following code:


import std.stdio;
void main()
{
  int a[] = [1,2,3,4,5];
  int b[] = a;
  writeln(a);
  writeln(b);
  //a.clear();
  a = [];
  writeln(a);
  writeln(b);
}

which outputs:

[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
[]
[1, 2, 3, 4, 5]

How to make it so that after clearing `a`, `b` will also point 
to the same empty array? IOW the desired output is:


[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
[]
[]

... and any further items added to `a` should also reflect in 
`b`.


If you don't want to mess with pointers (as sugggested in the 
first answer) you can also use std.typecons.RefCounted:


---
import std.stdio;
import std.typecons;

RefCounted!(int[]) b;

void main()
{
  int[] a = [1,2,3,4,5];
  b = a;
  writeln(a);
  writeln(b);
  a = [];
  writeln(a);
  writeln(b);
}

Re: `clear`ing a dynamic array

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, October 25, 2015 09:34:25 Shriramana Sharma via Digitalmars-d-learn 
wrote:
> rsw0x wrote:
>
> > use std.container.array
>
> Thanks all for all the recommendations. When would one use
> std.array.appender with a built-in array vs std.container.array.Array? What
> are the pros and cons on either side?

Appender is for when you you know that you're going to be doing a whole
bunch of appending to an array, and you'd normally only use it when
initially filling in the array, after which you'd just get the array out of
it and use the array. Appender really isn't intended to be used as a
container - just as a way to make appending more efficient or to have an
output range which is an array but which is appended to by put rather than
just assigning to its existing elements. You don't use Appender to not use
arrays or to get full reference semantics from an array.

If you want a container rather than a dynamic array - especially if you're
looking for full reference semantics - then use std.container.array.Array.

- Jonathan M Davis

Re: Option types and pattern matching.

[Nerve via Digitalmars-d]

On Sunday, 25 October 2015 at 05:53:32 UTC, Rikki Cattermole 
wrote:

I'm pretty sure e.g. opEquals/opCmp should work here.
Shouldn't need to switch upon a primitive type. Theoretically 
could do it on a e.g. struct. Which has the special comparison 
that you want.


Hm...these are boolean operators. This means we can only compare 
two cases at a time, does it not? Negates the strength of a 
switch/pattern match, unless there's something I'm missing.


What are these variable length structs you mention, and their 
special comparisons? How would we use them?

Re: Option types and pattern matching.

[cym13 via Digitalmars-d]

On Sunday, 25 October 2015 at 05:45:15 UTC, Nerve wrote:
On Sunday, 25 October 2015 at 05:05:47 UTC, Rikki Cattermole 
wrote:
Since I have no idea what the difference between Some(_), None 
and default. I'll assume it's already doable.


_ represents all existing values not matched. In this case, 
Some(_) represents any integer value that is not 7. None 
specifically matches the case where no value has been returned. 
We are, in most languages, also able to unwrap the value:


match x {
Some(7) => "Lucky number 7!",
Some(n) => "Not a lucky number: " ~ n,
None => "No value found"
}

Or something to that effect. The equivalent switch statement 
right now would be:


if (x.hasValue()) {
switch (*x.peek!(int)) {
case 7:writeln("Lucky number seven!"); break;
default:   writeln("Not a lucky number: ", 
*x.peek!(int)); break;

}
} else {
writeln("No value.");
}

This does not return a value (is a procedural structure); the 
switch cannot match null; in order to unwrap, we must call 
peek() again; and between the extra if-else and the break 
statements, this is not as clean.


As a note, pattern matching could almost be considered an 
extended form of the ?: operator, which matches over value 
cases rather than boolean truthiness.


Apologies if this is all below you, I'm not in Andrei's or 
Walter's league, just an interested party trying to make 
suggestions to better the language.


Although it doesn't exactly fit the problem at hand I'd like to 
mention
predSwitch. For most cases it does what you could expect from 
pattern
matching I think. Here is an example showing its strength and 
limits on your

showcase:

import std.conv;
import std.stdio;
import std.algorithm.comparison;
import std.variant;


void main(string[] args) {
Variant x;

x = 42;

if (x.hasValue) {
x.predSwitch!((a,b) => *a.peek!int == b) (
7,  "Lucky number!",
42, "This should be a lucky number too!",
"No luck, the number was " ~ x.to!string
).writeln;
}
else {
writeln("No value");
}
}

Re: Kinds of containers

[Jonathan M Davis via Digitalmars-d]

On Sunday, 25 October 2015 at 05:37:02 UTC, deadalnix wrote:
On Saturday, 24 October 2015 at 19:33:03 UTC, David Nadlinger 
wrote:

On Friday, 23 October 2015 at 17:44:55 UTC, deadalnix wrote:
Collection!T and Collection!const(T) are 2 completely 
different types.


Isn't this also required anyway because of covariance vs. 
contravariance considerations?


 — David


It is close, but not exactly the same. 
Covariance/contravariance can be emutalted via alias this 
without too much trouble for a container (however, it is hard 
to ensure correctness, but I'd assume not too hard). On the 
other hand, the qualifier thing turtle from the collection to 
the element in the collection, which is not that easy to 
achieve.


The bigger problem is probably ranges rather than containers. We 
get tail-const slices from arrays all the time, but opSlice with 
no arguments isn't really a range operation (none of the range 
traits require it), and it's pretty painful to get it to make 
tail-const work with opSlice anyway (though I know that the EMSI 
guys were jumping through all kinds of hoops to make it work, so 
their containers make actually handle it reasonably well). Plus 
there's the fun problem of how declaring opSlice on a range 
causes foreach to call it, which essentially means that your 
range can get saved accidentally, which can be problematic 
(especially for ranges like RefRange).


It's been a while since I sat down and worked through the various 
issues that we have here. I should probably do that soon and see 
if I can distill them down well enough to come up with a DIP to 
resolve them - or at least to clearly present them so that they 
can be discussed. What we have right now mostly works, but it 
falls apart in some corner cases - especially if you want to be 
able to operate on a range like you would an array.


- Jonathan M Davis

Re: Option types and pattern matching.

[Rikki Cattermole via Digitalmars-d]

On 25/10/15 7:15 PM, Rikki Cattermole wrote:

On 25/10/15 7:05 PM, Nerve wrote:

On Sunday, 25 October 2015 at 05:53:32 UTC, Rikki Cattermole wrote:

I'm pretty sure e.g. opEquals/opCmp should work here.
Shouldn't need to switch upon a primitive type. Theoretically could do
it on a e.g. struct. Which has the special comparison that you want.


Hm...these are boolean operators. This means we can only compare two
cases at a time, does it not? Negates the strength of a switch/pattern
match, unless there's something I'm missing.


Well you only need to compare two cases.
I need to spend a bit of time, to see if what I think can be done, is
actually possible. Essentially toying with your 'Some' types comparison
rules.


What are these variable length structs you mention, and their special
comparisons? How would we use them?


Oh the idea was a complete flop. It's just an example of how welcoming
ideas are. Just no guarantee they'll make it to even a consideration
from Walter.


Just alter the value in v1 under the main function, to see the different 
behaviors.


It's slightly backwards, you expect what is default to be a case. I'm 
sure you can handle changing the logic of opEquals to be what you want.


Also to get a version of Foo that has haveVal as false, probably should 
be a static method, instead of that custom usage. Not to mention 
templating it ext. ext.


struct Foo {
int val;
bool haveVal = true;

alias val this;

bool opEquals(Foo f) {
if (haveVal == f.haveVal) {
if (haveVal)
return val == f.val;
else
return true;
} else
return false;
}
}

void main() {
import std.stdio : writeln;
Foo v1 = Foo(0, false);

switch(v1) {
case 8:
writeln(9);
break;
case 6:
writeln(6);
break;
case Foo(0, false):
writeln("no value");
break;
default:
writeln("unknown: ", v1.val);
break;
}
}

Re: `clear`ing a dynamic array

[Olivier Pisano via Digitalmars-d-learn]

On Sunday, 25 October 2015 at 04:04:29 UTC, Shriramana Sharma 
wrote:

rsw0x wrote:


use std.container.array


Thanks all for all the recommendations. When would one use 
std.array.appender with a built-in array vs 
std.container.array.Array? What are the pros and cons on either 
side?


Appender is a small wrapper that enables you to get an output 
range from a built-in array. It allocates using the GC. If you 
have an array and you need to pass it to a function that takes an 
output range, you can use it.


std.container.Array is a reference counted container that is 
equivalent to std::shared_ptr in C++. It is not 
reliant on the GC.

Re: Option types and pattern matching.

[Jacob Carlborg via Digitalmars-d]

On 2015-10-25 06:01, Nerve wrote:

Hello D community! First time poster, I'm utterly fascinated with this
language's mix of features. It's powerful and expressive.

There are just two conveniences I'd like to see out of D. The first is
pattern matching, a functional construct which can unwrap tuples or
other containers, usually evaluates to a value (in most languages), and
which almost always idiomatically enforces the programmer to match over
every possible case of a given type.

While ML-inspired languages like F# and OCaml have some good pattern
matching syntax, it's not syntax which would fit in to D; I suggest
taking inspiration of Rusts's matching construct.

match x {
 Some(7) => "Lucky number 7!",
 Some(_) => "No lucky number.",
 None => "No value found"
}

 From that bit of code, we can see another feature at work: The Option
type. It wraps another type (i.e. Option int, Option Car) and represents
a wrapped presence of a value of that type (Some(n), Some(aCar)) or an
absence of that type (None).

Combined with pattern matching, we end up with a safe, functional
construct which can replace a switch statement in most cases, returns a
value, is incredibly compact and readable, and can be used with Options
to ensure that we always account for the possibility of a value not
present, eliminating a whole class of errors when we use it judiciously.

My only concern is that switch statements, while horrendous
syntactically, are extremely performant and essentially compile to a
series of branches.

Are there any counter-arguments for the implementation of these two
features? Is D in a state where language additions have come to a stop?


Both of these can be implemented in library code. Although the syntax 
won't be as nice.


I wouldn't mind having pattern matching as a language feature.

--
/Jacob Carlborg

Re: Does D's GC release memory back to the OS?

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, October 25, 2015 05:49:42 Richard White via Digitalmars-d-learn 
wrote:
> Just wondering if D's GC release memory back to the OS?
> The documentation for the GC.minimize
> (http://dlang.org/phobos/core_memory.html#.GC.minimize) seems to
> imply that it does,
> but watching my OS's memory usage for various D apps doesn't
> support this.

It is my understanding that the GC does not normally ever return memory to
the OS (though it's been worked on quite a bit over the last couple of
years, so that may have changed - probably not though, since that wouldn't
really help memory performance and could actually hurt it). minimize's
documentation clearly indicates that it returns memory to the OS, but that
doesn't necessarily mean that the GC ever does that on its own. It just
means that the GC provides a way for the programmer to tell it to return
memory to the OS. And I would guess that calling minimize frequently would
harm performance. It probably mostly makes sense after you know that your
program has used a lot of memory for something and isn't going to need that
memory again. But the functions in core.memory are intended for performance
tweaking for the adventurous and/or those who really need to tweak
performance as opposed to something that a typical program would do.

- Jonathan M Davis

Re: Option types and pattern matching.

[TheFlyingFiddle via Digitalmars-d]

On Sunday, 25 October 2015 at 05:45:15 UTC, Nerve wrote:
On Sunday, 25 October 2015 at 05:05:47 UTC, Rikki Cattermole 
wrote:
Since I have no idea what the difference between Some(_), None 
and default. I'll assume it's already doable.


_ represents all existing values not matched. In this case, 
Some(_) represents any integer value that is not 7. None 
specifically matches the case where no value has been returned. 
We are, in most languages, also able to unwrap the value:


match x {
Some(7) => "Lucky number 7!",
Some(n) => "Not a lucky number: " ~ n,
None => "No value found"
}


You can do something very similar to that. With slightly 
different syntax.


import std.traits;
import std.conv;
import std.variant;
struct CMatch(T...) if(T.length == 1)
{
   alias U = typeof(T[0]);
   static bool match(Variant v)
   {
  if(auto p = v.peek!U)
 return *p == T[0];
  return false;
   }
}

auto ref match(Handlers...)(Variant v)
{
   foreach(handler; Handlers)
   {
  alias P = Parameters!handler;
  static if(P.length == 1)
  {
 static if(isInstanceOf!(CMatch, P[0]))
 {
if(P[0].match(v))
   return handler(P[0].init);
 }
 else
 {
if(auto p = v.peek!(P[0]))
   return handler(*p);
 }
  }
  else
  {
 return handler();
  }
   }

   assert(false, "No matching pattern");
}

unittest
{
Variant v = 5;
string s = v.match!(
(CMatch!7) => "Lucky number seven",
(int n)=> "Not a lucky number: " ~ n.to!string,
() => "No value found!");

   writeln(s);
}

Re: Sociomantic Labs is looking for Software Developers! (D language)

[Andrej Mitrovic via Digitalmars-d-announce]

On 10/24/15, Rikki Cattermole via Digitalmars-d-announce
 wrote:
> If you guys ever want an office in New Zealand (perhaps night/day style
> for e.g. testing) or want remote workers, please let me know.

For what it's worth there are plenty of Kiwis in our office, you would
feel right at home if you decided to move! :)

Regards,
A.M.

Re: My experience from learning Polish language

[Marc Schütz via Digitalmars-d]

On Sunday, 25 October 2015 at 05:15:04 UTC, Ali Çehreli wrote:

On 10/24/2015 04:15 AM, Cauterite wrote:
On Saturday, 24 October 2015 at 11:01:24 UTC, grumpyalittle 
wrote:
My name is Daisy and I was on Erasmus program in Poland. 
During


This looks like spam to me.


Of course spam but it's pretty amusing. :) It must have 
happened like this:


- Polish language school, which happens to be named PROLOG 
hires spammers for some effective spamming.


- Clueless spammers search for newsgroups that are related to 
"prolog language".


- Prolog happens to be a programming language. So is D, and we 
get the spam. :)


And one of the new sample programs on the start page is an RPN 
calculator :-P

[Issue 15247] New: Object's destructor should be pure @safe nothrow @nogc

[via Digitalmars-d-bugs]

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

  Issue ID: 15247
   Summary: Object's destructor should be pure @safe nothrow @nogc
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

The destructor of Object does nothing so it should not be maximally
conservative (as is today). User-defined classes should inherit the pure @safe
nothrow @nogc attributes for destructor.

If a user-defined class includes fields that have destructors, the generated
destructor will also generate the attributes appropriately.

--

[Issue 15245] New: tools do not support --version flag properly

[via Digitalmars-d-bugs]

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

  Issue ID: 15245
   Summary: tools do not support --version flag properly
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: joseph.wakel...@webdrake.net

None of the D tools adequately supports the version flag:

(1) rdmd supports the --version flag but gives only the day of build (e.g.
20151025) rather than the actual version tag;

(2) catdoc, changed, dget, dustmite and tolf all exit with an uncaught
exception;

(3) ddmangle reports an unrecognized option and prints help.

Since the tools repository is subject to similar version tagging to dmd,
druntime and phobos, it would seem appropriate that the tools support a
--version flag with similar output to dmd --version.

--

Re: My experience from learning Polish language

[Russel Winder via Digitalmars-d]

On Sat, 2015-10-24 at 22:15 -0700, Ali Çehreli via Digitalmars-d wrote:
> […]
> 
> (Why did I write all this?)

Explanations help people understand. I for one am pleased you took the
time.

-- 
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: DConf 2016, Berlin: Call for Submissions is now open!

[ponce via Digitalmars-d-announce]

On Friday, 23 October 2015 at 16:37:20 UTC, Andrei Alexandrescu 
wrote:


http://dconf.org/2016/index.html


Do you need a new logo this year? I would be happy to make 
another, better one.

Re: `clear`ing a dynamic array

[anonymous via Digitalmars-d-learn]

On Sunday, 25 October 2015 at 11:45:53 UTC, Shriramana Sharma 
wrote:
http://dlang.org/arrays.html#resize says: """Also, you may wish 
to utilize the phobos reserve function to pre-allocate array 
data to use with the append operator."""


I presume this means 
http://dlang.org/phobos/std_array.html#.Appender.reserve but 
how `append` is considered an operator is beyond me.


That sentence doesn't refer to std.array.Appender. `reserve` 
means . The append 
operator is `~=`.

[Issue 15128] "IP_ADD_MEMBERSHIP" error in winsock2.d

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/e854d0e207652ebfa9d84b21d74ef399196351f7
fix Issue 15128 - "IP_ADD_MEMBERSHIP" error in winsock2.d

https://github.com/D-Programming-Language/druntime/commit/043457fd28fe6ae0363548c6572939ff024ca12a
Merge pull request #1409 from CyberShadow/pull-20151015-182746

fix Issue 15128 - "IP_ADD_MEMBERSHIP" error in winsock2.d

--

[Issue 15128] "IP_ADD_MEMBERSHIP" error in winsock2.d

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

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

--

Re: `clear`ing a dynamic array

[Shriramana Sharma via Digitalmars-d-learn]

Thanks all, for your replies.

Jonathan M Davis via Digitalmars-d-learn wrote:

> If you want a container rather than a dynamic array - especially if you're
> looking for full reference semantics - then use std.container.array.Array.

Hmmm, pardon me but while I'm sure I don't specifically require reference 
semantics, I'm not sure how you mean to contrast a "container" vs a "dynamic 
array". Both are aware of their content count and both are iterable, no? Is 
it that by "container" you mean that something that owns its contents and is 
responsible for deleting them all when it itself is deleted?

-- 
Shriramana Sharma, Penguin #395953

Re: `clear`ing a dynamic array

[Shriramana Sharma via Digitalmars-d-learn]

Jonathan M Davis via Digitalmars-d-learn wrote:

> Appender really isn't intended to be used as a
> container - just as a way to make appending more efficient or to have an
> output range which is an array

I get the part about Appender helping to make an output range of a regular 
array, but I'm not sure how it is supposed to make appending "more 
efficient". I just had a look at the std.array code for appender and 
couldn't figure what was so special – obviously it's my limited knowledge. 

http://dlang.org/arrays.html#resize says: """Also, you may wish to utilize 
the phobos reserve function to pre-allocate array data to use with the 
append operator."""

I presume this means 
http://dlang.org/phobos/std_array.html#.Appender.reserve but how `append` is 
considered an operator is beyond me.

Anyhow, is `reserve` the only thing that makes this more efficient? How is 
this more efficient than setting the .length of the dynamic array directly? 
I see there's a lot of logic going into ensureAddable() but doesn't this 
logic happen within druntime for the regular dynamic arrays itself?

-- 
Shriramana Sharma, Penguin #395953 

[Issue 10488] Reg (2.063): Template this paramter doesn't work properly

[via Digitalmars-d-bugs]

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

Marc Schütz  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||schue...@gmx.net
 Resolution|INVALID |---
   Severity|regression  |enhancement

--- Comment #3 from Marc Schütz  ---
IMO the fact that `typeof(this)` is allowed in static methods is a compelling
argument to allow this. It has interesting applications when combined with
inheritance, see this forum post:

http://forum.dlang.org/post/n0gl6m$1oms$1...@digitalmars.com

Therefore I'm reopening this issue as an enhancement request.

--

Re: Compilation time profiling

[tired_eyes via Digitalmars-d-learn]

On Saturday, 24 October 2015 at 22:16:35 UTC, Vladimir Panteleev 
wrote:

On Saturday, 24 October 2015 at 21:56:05 UTC, tired_eyes wrote:
Hi, are there any tools for compilation time profiling? I'm 
trying to find what part of the code increases compilation 
time and don't want to stumble around.


There's this:

https://github.com/CyberShadow/DBuildStat

Example output:

https://github.com/rejectedsoftware/vibe.d/issues/208#issuecomment-15875240


Wow, looks promising, thank you! This definitely should be 
mentioned in the wiki. Mind if I do?

Re: Calypso progress report (+ updated MingW64 build)

[Elie Morisse via Digitalmars-d-announce]

On Sunday, 25 October 2015 at 21:42:15 UTC, Stefan wrote:

Hello,

// compile with: ldc2 -cpp-args -std=gnu++11 main.d

modmap (C++) "cmath";

import (C++) std._;

import std.stdio;

int main()
{
  writeln(sin(cast(float)0.8159));
return 0;
}

gives a lot of "error: constexpr function never produces a 
constant expression" messages. Not sure this is supposed to 
work?


Hi and thank you for testing!

The code compiles and runs with C++11 disabled, I don't know why 
these errors occur while generating the PCH with C++11 enabled, 
looking into it.

Re: Playing SIMD

[Matthias Bentrup via Digitalmars-d]

On Sunday, 25 October 2015 at 19:37:32 UTC, Iakh wrote:

Is it optimal and how do you implement this stuf?



I think it's better to use PMOVMSKB to avoid storing the PCMPEQB 
result in memory and you need only one BSF instruction.

Re: DConf 2016, Berlin: Call for Submissions is now open!

[Andrei Alexandrescu via Digitalmars-d-announce]

On 10/25/15 8:04 AM, ponce wrote:

On Friday, 23 October 2015 at 16:37:20 UTC, Andrei Alexandrescu wrote:


http://dconf.org/2016/index.html


Do you need a new logo this year? I would be happy to make another,
better one.


Yes please! Forgot to mention that. Many thanks!! -- Andrei

Re: Calypso progress report (+ updated MingW64 build)

[Stefan via Digitalmars-d-announce]

Hello,

// compile with: ldc2 -cpp-args -std=gnu++11 main.d

modmap (C++) "cmath";

import (C++) std._;

import std.stdio;

int main()
{
  writeln(sin(cast(float)0.8159));
return 0;
}

gives a lot of "error: constexpr function never produces a 
constant expression" messages. Not sure this is supposed to work?

Heroku Buildpack for D

[Martin Nowak via Digitalmars-d-announce]

I wrote a buildpack for Heroku to easily deploy D apps.
The script is based on the Travis-CI build script, so you can 
select the same compilers (using a .d-compiler file) and get the 
same DC/DMD env vars.


https://github.com/MartinNowak/heroku-buildpack-d

[Issue 15230] Inconsistent std.range.SortedRange predicate checks

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #1 from Jack Stouffer  ---
I would consider this as "working as intended", as the checks are only supposed
to happen in debug mode. In a PR of mine, I asked @schveiguy if it made any
sense to have any checks in a function that is supposed to be assuming
something. He said it's strange, but it's nice to have something that double
checks for you, in debug mode only.

--

Re: LDC 0.16.0 has been released!

[Martin Nowak via Digitalmars-d-announce]

On Thursday, 22 October 2015 at 19:00:07 UTC, Kai Nacke wrote:

Hi everyone,

LDC 0.16.0, the LLVM-based D compiler, is available for 
download!


Great job and impressive bugfix list.
Could someone please update 
https://ldc-developers.github.io/LATEST.


-Martin

Re: Kinds of containers

[Jonathan M Davis via Digitalmars-d]

On Sunday, 25 October 2015 at 15:42:02 UTC, Andrei Alexandrescu 
wrote:

Jonathan, do you have a link to your work?


Sorry, but no. I haven't mucked around with this issue recently, 
and whatever I have left on the topic is either buried in a 
newsgroup post somewhere or buried on my hard drive somewhere 
where I wouldn't know where to find it. Searching on the 
newsgroup for discussions on tail-const would find stuff related 
to this if you want to go spelunking, since it's the tail-const 
issues where the fact that const(Foo!T) and Foo!(const T) aren't 
related typically comes up and likely causes the largest problems.


The EMSI containers may have some interesting stuff with regards 
to the problem, since I know that those guys tried very hard to 
be able to support tail-const ranges.


The main thing that I recall is that if you want to be able to 
get a tail-const range from a const range, you have to use a 
static if to protect the const opSlice declaration so that you 
don't end up with a recursive template instantiation (since it 
has to return another instantiation of the range's template). And 
even then, an opSlice with no arguments isn't technically a 
standard range function, because none of the range traits require 
it (so you can't rely on a range having it). Rather, it's a 
container function for getting a range. And even if it were a 
range function, it wouldn't get the special treatment that arrays 
get when being passed to a templated function (IFTI infers an 
array's type as being a tail-const slice, which doesn't happen 
with anything else), and even if it did, a const range wouldn't 
implicitly convert to its tail-const variant without an alias 
this, which is likely to create a whole other set of problems - 
particularly since implicit conversions tend to wreak havoc in 
generic code.


Handling tail-const with ranges in a manner consistent with 
arrays and supporting $ with ranges are probably the two big 
places that ranges can't currently emulate the behavior of 
arrays. The $ problem is technically solvable as-is, but without 
some form of https://issues.dlang.org/show_bug.cgi?id=7177 being 
implemented, changing hasSlicing or isRandomAccessRange to 
require that a range works with $ would likely break too much 
code, so no range-based code can really using $ unless it 
explicitly checks for it. However, I'm not sure that the 
tail-const problems is solvable without further language 
improvements. We likely need some sort of standard way to convert 
a const(Foo!T) to a Foo!(const T) - possibly via opSlice, since 
it wouldn't make sense for something that wasn't emulating an 
array. And we might need to make changes to IFTI so that it 
infers tail-const for ranges (at least if they provide such a 
conversion), but I'm not sure what the implications of that are.


There's also the issue of accidentally slicing ranges (e.g. 
https://issues.dlang.org/show_bug.cgi?id=14619 ) which can cause 
incorrect behavior in at least some cases, depending on the range 
type - and if a range is a reference type, then slicing it would 
be akin to saving it, which could mean allocating. So, unlike 
with arrays, we probably don't want ranges in general to get 
sliced just because they're passed to a function, meaning that we 
may just want IFTI to not play fun games with ranges and let 
arrays be special there.


In any case, I should probably try and find time soon to sit down 
and at least go over the issues in detail again so that I'm 
clearer on them and could possibly present a DIP intended to 
resolve them. I haven't dug through them recently, and my general 
approach up until now when I've needed to actually get work done 
has been to just not use const or inout with ranges.


- Jonathan M Davis

Re: Playing SIMD

[anonymous via Digitalmars-d]

On 25.10.2015 20:37, Iakh wrote:

Full exaple with comparation of algorithms (SIMD, naive, binary search):
http://dpaste.dzfl.pl/f3b8989841e3


From there:

void runBinary()
{
static int i = 0;
naiveIndexOf(cast(ubyte)(i++/ArraySize + 1), arr);
}


runBinary calls naiveIndexOf. You're not testing binaryIndexOf.

Re: Compilation time profiling

[Vladimir Panteleev via Digitalmars-d-learn]

On Sunday, 25 October 2015 at 12:21:33 UTC, tired_eyes wrote:
On Saturday, 24 October 2015 at 22:16:35 UTC, Vladimir 
Panteleev wrote:

On Saturday, 24 October 2015 at 21:56:05 UTC, tired_eyes wrote:
Hi, are there any tools for compilation time profiling? I'm 
trying to find what part of the code increases compilation 
time and don't want to stumble around.


There's this:

https://github.com/CyberShadow/DBuildStat

Example output:

https://github.com/rejectedsoftware/vibe.d/issues/208#issuecomment-15875240


Wow, looks promising, thank you! This definitely should be 
mentioned in the wiki. Mind if I do?


Good idea, I added 
http://wiki.dlang.org/Development_tools#Build_time_profiling. 
Also added a README to DBuildStat's repo.

Re: `clear`ing a dynamic array

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, October 25, 2015 17:15:50 Shriramana Sharma via Digitalmars-d-learn 
wrote:
> Jonathan M Davis via Digitalmars-d-learn wrote:
>
> > Appender really isn't intended to be used as a
> > container - just as a way to make appending more efficient or to have an
> > output range which is an array
>
> I get the part about Appender helping to make an output range of a regular
> array, but I'm not sure how it is supposed to make appending "more
> efficient". I just had a look at the std.array code for appender and
> couldn't figure what was so special – obviously it's my limited knowledge.

There is bookkeeping in the GC involved with appending to a dynamic array
(e.g. it has to look up whether there is room to grow into the buffer that
backs the dynamic array or even whether the dynamic array is even backed by
a GC-allocated buffer at all). Appender takes advantage of the fact that
it's designed specifically for appending and keeps track of certain things
on its own, bypassing a lot of what ~= normally does in an effort to make
the specific use case of appending a bunch of times in a row efficient. So,
it bypasses a lot of the checks that ~= is normally forced to do, but the
result is that it's really just for constructing an array up front, whereas
~= can be used whenever, and I'm not sure that Appender even works correctly
if you do something like get the array from it and start operating on it
separately from the Appender and then continue to use the Appender. Really,
you're supposed to use it to fill the array with its initial values, get the
array out of the Appender, and then stop using the Appender.

- Jonathan M Davis

DMD is slow for matrix maths?

[Etienne Cimon via Digitalmars-d]

I've been playing around with perf and my web server and found 
that the bottleneck is by far the math module of Botan: 
https://github.com/etcimon/botan/blob/master/source/botan/math/mp/mp_core.d


I'm probably a bit naive but I was wishing for some inlining to 
happen. I see LOTS of CPU time spent on "pop" instructions to 
return from a simple multiply function, and the pragma(inline, 
true) was refused on all of these. So, should I wait for an 
inline? Should I import another library? Should I rewrite all the 
maths in assembly manually for each processor? Should I write 
another library that must be compiled with LDC/release for maths?


I think the best option would be for an inline feature in DMD 
that works, but I'm wondering what the stance is right now about 
the subject?

[Issue 15245] tools do not support --version flag properly

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
At least DustMite is a separate project that is included with DMD for
convenience, thus is not tied to the DMD release schedule. It does not have a
version because it has no releases - a release is effectively a push to GitHub.

--

[Issue 15245] tools do not support --version flag properly

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Priority|P1  |P5
   Hardware|x86_64  |All
 OS|Linux   |All

--

Re: Playing SIMD

[Iakh via Digitalmars-d]

On Sunday, 25 October 2015 at 22:17:58 UTC, Matthias Bentrup 
wrote:

On Sunday, 25 October 2015 at 19:37:32 UTC, Iakh wrote:

Is it optimal and how do you implement this stuf?



I think it's better to use PMOVMSKB to avoid storing the 
PCMPEQB result in memory and you need only one BSF instruction.


Yeah but PMOVMSKB not implemented in core.simd.

Bit more comprehensive here:
http://forum.dlang.org/post/20150923115833.054fdb09@marco-toshiba

[Issue 15245] tools do not support --version flag properly

[via Digitalmars-d-bugs]

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

--- Comment #3 from Vladimir Panteleev  ---
(In reply to Joseph Rushton Wakeling from comment #2)
> ... and yet the repo is tagged with dmd release numbers.

The DustMite repo isn't. The code in the D-P-L tools repo is a copy from
https://github.com/CyberShadow/DustMite , updated periodically.

--

Re: Playing SIMD

[Andrei Alexandrescu via Digitalmars-d]

On 10/25/15 6:57 PM, Iakh wrote:

On Sunday, 25 October 2015 at 21:13:56 UTC, Andrei Alexandrescu wrote:

[...]
This is compelling but needs a bit of work to integrate. Care to work
on a PR that makes std.algorithm use it? Thanks! -- Andrei


First of all I need sort of investigation about PRs and std.algorithm.
But in general challenge accepted.


Thanks! -- Andrei

Re: An annoying compile issue

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

On Monday, 26 October 2015 at 03:44:31 UTC, WhatMeWorry wrote:
First, isn't Vector!(float,3) a template which creates a tuple 
consisting of float, float, float; so aren't the argument types 
identical?


I'm not familiar with the gl3n library so I'm not sure what their 
Vector is, but most D templates are not created from tuples and 
don't work that way.


Looking at the source, it indeed seems to be based on a static 
array rather than a tuple:

https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L49

---
 vt[dimension] vector; /// Holds all coordinates, length conforms 
dimension.

---

Which means there's no simple, built-in way to getting a tuple 
out of that. You could write one though, and recently there was a 
post about maybe putting that in Phobos, but it isn't there now.



model = model.scale(size.x, size.y, 1.0f);


meh that's prolly what I'd do... unless you wanted to modify the 
library and add some expansion code to that vector type.

Re: An annoying compile issue

[Rikki Cattermole via Digitalmars-d-learn]

On 26/10/15 4:44 PM, WhatMeWorry wrote:

I'm porting over some C++/glm/openGL code.  I've used gl3n for a while
now (successfully) to port over glm code, but I've got this pebble in my
shoe:

glm::mat4 model;
model = glm::scale(model, glm::vec3(size, 1.0f));   // size is a vec2

So my D code consists of:

mat4 model;
model = model.scale(vec3(size, 1.0f));  // size is a vec2


Error: function gl3n.linalg.Matrix!(float, 4, 4).Matrix.scale (float x,
float y, float z) is not callable using argument types (Vector!(float, 3))


First, isn't Vector!(float,3) a template which creates a tuple
consisting of float, float, float; so aren't the argument types identical?


It is not a tuple.
vec2 != vec3. They are different types altogether.

Re: Calypso progress report (+ updated MingW64 build)

[Laeeth Isharc via Digitalmars-d-announce]

On Monday, 26 October 2015 at 01:39:52 UTC, Elie Morisse wrote:

On Sunday, 25 October 2015 at 21:42:15 UTC, Stefan wrote:

Hello,

// compile with: ldc2 -cpp-args -std=gnu++11 main.d

modmap (C++) "cmath";

import (C++) std._;

import std.stdio;

int main()
{
  writeln(sin(cast(float)0.8159));
return 0;
}

gives a lot of "error: constexpr function never produces a 
constant expression" messages. Not sure this is supposed to 
work?


It's fixed with the latest commit.


any chance of some release builds on github when the time is 
right?  I've tried a few times, and somewhat embarrassingly each 
time I get a bit further, but still never made it to a usable 
version of ldc-calypso.  I didn't want to file bug report as 
figure you have better things to do at this stage and it's a 
moving target. ldc itself I can compile fine (without your mods).


I'd be interested in seeing if quantlib is usable.  it's a 
library that's quite popular in finance world, and might open up 
the set of people that are interested in exploring D.

Re: Calypso progress report (+ updated MingW64 build)

[Elie Morisse via Digitalmars-d-announce]

On Monday, 26 October 2015 at 01:52:37 UTC, Laeeth Isharc wrote:
any chance of some release builds on github when the time is 
right?  I've tried a few times, and somewhat embarrassingly 
each time I get a bit further, but still never made it to a 
usable version of ldc-calypso.  I didn't want to file bug 
report as figure you have better things to do at this stage and 
it's a moving target. ldc itself I can compile fine (without 
your mods).


I'd be interested in seeing if quantlib is usable.  it's a 
library that's quite popular in finance world, and might open 
up the set of people that are interested in exploring D.


Hi Laeeth,

Were you trying to build it on Linux? I uploaded a Linux build: 
http://www.homo-nebulus.fr/dlang/Calypso-x86_64-Ubuntu15_04-2015_10_25.tar.xz


The build process got much simpler 2 weeks ago though, now that 
it doesn't depend on an LLVM source tree and an external Clang 
executable anymore it's almost identical to building LDC.


Let me know how Calypso fares with quantlib.

Re: DMD is slow for matrix maths?

[H. S. Teoh via Digitalmars-d]

On Mon, Oct 26, 2015 at 02:37:16AM +, Etienne Cimon via Digitalmars-d wrote:
> I've been playing around with perf and my web server and found that
> the bottleneck is by far the math module of Botan:
> https://github.com/etcimon/botan/blob/master/source/botan/math/mp/mp_core.d
> 
> I'm probably a bit naive but I was wishing for some inlining to
> happen. I see LOTS of CPU time spent on "pop" instructions to return
> from a simple multiply function, and the pragma(inline, true) was
> refused on all of these.  So, should I wait for an inline? Should I
> import another library? Should I rewrite all the maths in assembly
> manually for each processor? Should I write another library that must
> be compiled with LDC/release for maths?
> 
> I think the best option would be for an inline feature in DMD that
> works, but I'm wondering what the stance is right now about the
> subject?

For an immediate solution to performance-related issues, I recommend
using GDC or LDC (with maximum optimization options) instead of DMD.

If you must use DMD, I recommend filing an enhancement request and
bothering Walter about it.


T

-- 
MS Windows: 64-bit rehash of 32-bit extensions and a graphical shell for a 
16-bit patch to an 8-bit operating system originally coded for a 4-bit 
microprocessor, written by a 2-bit company that can't stand 1-bit of 
competition.

Re: Kinds of containers

[Timon Gehr via Digitalmars-d]

On 10/25/2015 08:33 PM, Andrei Alexandrescu wrote:

On 10/24/2015 07:03 PM, Timon Gehr wrote:

On 10/24/2015 09:22 PM, Andrei Alexandrescu wrote:

On 10/24/15 3:19 PM, Timon Gehr wrote:

Even if this was possible, it would not be a very good idea. Persistent
data structures have use cases that would be hindered by required
transitive immutability.


This part I don't quite get.


The slots are not mutable, but they are not /transitively/ immutable
either. Note that this does not require any special effort, nor does it
/prevent/ stored elements from being (transitively) immutable. Scala
does it this way. (Haskell as well, basically.)


I see. Well, this will be unpleasant to implement in D.

One simple way to do so would be to have accessors return rvalues:

T front() { ... }

Then you get to change the indirections of T, if any, but not what's
stored in the container directly.

Problem is accessing every element by rvalue is likely to be inefficient
in the general case (even on data without copy ctors).


Andrei



As I mentioned, the cheap way out for performance would be to provide 
what you suggested (persistent topology, arbitrary reference access to 
slots). Users can then use type qualifiers at their own discretion. 
There could probably even be short aliases to automatically have 
immutable elements. What's important is that use cases for mutable 
elements are not ruled out. They don't necessarily need to be on the 
path of least resistance.

[Issue 15245] tools do not support --version flag properly

[via Digitalmars-d-bugs]

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

--- Comment #2 from Joseph Rushton Wakeling  ---
> It does not have a version because it has no releases - a release is 
> effectively a push to GitHub.

... and yet the repo is tagged with dmd release numbers.

I'm not suggesting the tools _have_ to be tied to dmd release schedule, but
some kind of support of --version would make sense, even if it's just to report
the hash and date of the most recent commit.

--

Re: Playing SIMD

[Iakh via Digitalmars-d]

On Sunday, 25 October 2015 at 21:13:56 UTC, Andrei Alexandrescu 
wrote:

[...]
This is compelling but needs a bit of work to integrate. Care 
to work on a PR that makes std.algorithm use it? Thanks! -- 
Andrei


First of all I need sort of investigation about PRs and 
std.algorithm. But in general challenge accepted.

Re: `clear`ing a dynamic array

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, October 25, 2015 16:23:14 Shriramana Sharma via Digitalmars-d-learn 
wrote:
> Thanks all, for your replies.
>
> Jonathan M Davis via Digitalmars-d-learn wrote:
>
> > If you want a container rather than a dynamic array - especially if you're
> > looking for full reference semantics - then use std.container.array.Array.
>
> Hmmm, pardon me but while I'm sure I don't specifically require reference
> semantics, I'm not sure how you mean to contrast a "container" vs a "dynamic
> array". Both are aware of their content count and both are iterable, no? Is
> it that by "container" you mean that something that owns its contents and is
> responsible for deleting them all when it itself is deleted?

Dynamic arrays are really pseudo-containers. They do not own or manage their
own memory, and their memory and elements are potentially shared across
multiple dynamic arrays. And mutating one dynamic array does not normally
affect another one - even if they refer to the same memory - unless you're
mutating its elements, and if one of them ends up having to be reallocated
(e.g. because there wasn't enough room to append another element when an
append operation was attempted), then two dynamic arrays which referred to
the same memory would then refer to completely different memory.

You started out this thread talking about how you wanted to be able to
"clear" a dynamic array and have that affect other dynamic arrays which
referred to the same memory, and that doesn't make any sense with a dynamic
array, because dynamic arrays are not full reference types. They share the
memory that they point to, but mutating the length of one (either directly
or by adding or removing elements) does not affect any other dynamic array
(except insofar as it can affect when an array would have to have its memory
reallocated). That's why I talked about reference semantics.

If you want a container that you pass around where removing an element from
it or adding an element to it affects all of the other variables referring
to that same data, you need an actual container type, not a dynamic array.

If you haven't read this article yet

http://dlang.org/d-array-article.html

I'd suggest that you do. The terminology that it uses does not match the
offial terminology (e.g. per the spec, T[] is a dynamic array regardless of
what memory backs it, whereas that article refers to the GC-allocated buffer
that backs most dynamic arrays as being the dynamic array), but it should
make the semantics of D's dynamic arrays much clearer.

- Jonathan M Davis

Re: Calypso progress report (+ updated MingW64 build)

[Elie Morisse via Digitalmars-d-announce]

On Sunday, 25 October 2015 at 21:42:15 UTC, Stefan wrote:

Hello,

// compile with: ldc2 -cpp-args -std=gnu++11 main.d

modmap (C++) "cmath";

import (C++) std._;

import std.stdio;

int main()
{
  writeln(sin(cast(float)0.8159));
return 0;
}

gives a lot of "error: constexpr function never produces a 
constant expression" messages. Not sure this is supposed to 
work?


It's fixed with the latest commit.

An annoying compile issue

[WhatMeWorry via Digitalmars-d-learn]

I'm porting over some C++/glm/openGL code.  I've used gl3n for a 
while now (successfully) to port over glm code, but I've got this 
pebble in my shoe:


glm::mat4 model;
model = glm::scale(model, glm::vec3(size, 1.0f));   // size is a 
vec2


So my D code consists of:

mat4 model;
model = model.scale(vec3(size, 1.0f));  // size is a vec2


Error: function gl3n.linalg.Matrix!(float, 4, 4).Matrix.scale 
(float x, float y, float z) is not callable using argument types 
(Vector!(float, 3))



First, isn't Vector!(float,3) a template which creates a tuple 
consisting of float, float, float; so aren't the argument types 
identical?


I can workaround the issue by simply
model = model.scale(size.x, size.y, 1.0f);

but that seems like cheating :)

Is there an elegant D fix. Not to imply that there is any other 
kind.

Re: Mobile support

[Dan Olson via Digitalmars-d]

Andrei Alexandrescu  writes:

> On 10/18/15 7:55 AM, Joakim wrote:
>> Now, the download page has not traditionally listed alphas and betas.
>> But the importance of mobile is so high that I think it is worth it to
>> do so, with the appropriate cautions about alpha quality.
>
> Yes, very much so. Please make that happen. Thanks! -- Andrei

I think it makes sense to add a link to the LDC iOS releases in
http://wiki.dlang.org/Compilers.  Perhaps a row for iOS in table
"Package and/or binary availability, by platform and compiler".

I am not sure it belongs on http://dlang.org/download.html though until
somebody besides me has reported success using D in an iOS App.

How should I proceed?
-- 
Dan

Re: Vision

[Andrei Alexandrescu via Digitalmars-d]

On 10/22/2015 11:09 AM, Jonathan M Davis wrote:

Maybe the color stuff belongs in Phobos. Maybe not. But IMHO, concerns
about 3rd party projects dying off is _not_ a good reason to put
something in the standard library. I don't think that we want large
amounts of code being thrown into Phobos on the theory that the Phobos
devs will maintain it and whoever wrote it can stop caring.


Wise words. -- Andrei

Re: `clear`ing a dynamic array

[Shriramana Sharma via Digitalmars-d-learn]

anonymous wrote:

>> I presume this means
>> http://dlang.org/phobos/std_array.html#.Appender.reserve but
>> how `append` is considered an operator is beyond me.
> 
> That sentence doesn't refer to std.array.Appender. `reserve`
> means . The append
> operator is `~=`.

Thanks for that clarification. Now submitted a pull request.

-- 
Shriramana Sharma, Penguin #395953

Re: Vision

[Andrei Alexandrescu via Digitalmars-d]

Many thanks to all who replied. I have integrated feedback and moved the 
page:


http://wiki.dlang.org/Vision/2015H2

(Of course it remains open for improvement.)

One note of importance: PR activity has not grown a lot in this half - 
we have 1037 pull requests as of end of Oct 24. Compare with 1054 for 
the same period in 2014 and with 1538 for the entire H2 2014.


Please accept my apologies for being ridiculously behind schedule. I 
knew since the beginning of 2015 it's going to be a weird year: new kid, 
moving across the country, new home, new job for my spouse, leaving 
Facebook, conference travels... things are only starting to unwind 
properly now. We should be able to find the time and focus to deliver 
the vision documents in a timely manner to keep the community engaged.



Andrei

[Issue 15246] Destructor inheritance doesn't inherit attributes properly

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||accepts-invalid
 CC||ag0ae...@gmail.com
   Severity|enhancement |normal

--

Re: Is dlangui dead?

[thedeemon via Digitalmars-d]

On Tuesday, 20 October 2015 at 17:01:19 UTC, karabuta wrote:
I hope I am wrong, but dlangui seems to be abandoned for some 
time after all the hard work that went into it. I really like 
it since it was easy to setup and get things working.


Maybe the author decided it's "done and ready"?


In fact, I consider it the best option.


Yep, I'm using it in one important project and several small 
ones. So with Vadim or without, DlangUI will live.

Re: Kinds of containers

[Timon Gehr via Digitalmars-d]

On 10/25/2015 08:31 PM, Andrei Alexandrescu wrote:

On 10/23/2015 07:21 PM, bigsandwich wrote:

On Friday, 23 October 2015 at 17:44:55 UTC, deadalnix wrote:

On Friday, 23 October 2015 at 11:03:37 UTC, Andrei Alexandrescu wrote:

[...]


Sure. We have a problem when it come to collection in the fact that
type qualifier do not turtle down as one would expect.

[...]


Its not just type qualifiers. Containers of derived types have the same
problem.  This is also a problem in C++.


This is something easy to live with. In fact, mutable containers are not
supposed to even convert to containers of base objects. -- Andrei



This is true for containers with reference semantics, but not for 
containers with value semantics.


This compiles (D code):

class A{}
class B: A{}

void main(){
A[2] a;
B[2] b;
a=b;
}

This does not compile (C++ code):

class A{};
class B: A{};

int main(){
vector a;
vector b;
a=b;
}

However, the conversion would be safe. For persistent and COW 
containers, the copy would even be fast.

Re: Playing SIMD

[Andrei Alexandrescu via Digitalmars-d]

On 10/25/2015 03:37 PM, Iakh wrote:

Here is my implementatation of SIMD find. Function returns index of
ubyte in static 16 byte array with unique values.

--
immutable size_t ArraySize = 16;
int simdIndexOf(ubyte niddle, ref const ubyte[ArraySize] haystack)
{
 ubyte16 arr;
 arr.array = haystack[];
 ubyte16 niddles;
 niddles.array[] = niddle;
 ubyte16 result;
 result = __simd_sto(XMM.PCMPEQB, arr, niddles);
 alias Mask = ulong;
 static assert(2 * Mask.sizeof == result.sizeof);
 immutable BitsInByte = 8;

 if (Mask mask = *cast(Mask*)(result.array.ptr))
 {
 return bsf(mask) / BitsInByte;
 }
 else if (Mask mask = *cast(Mask*)(result.array.ptr + Mask.sizeof))
 {
 return bsf(mask) / BitsInByte + cast(int)Mask.sizeof;
 }
 else
 {
 return -1;
 }

}
--

Is it optimal and how do you implement this stuf?

Full exaple with comparation of algorithms (SIMD, naive, binary search):
http://dpaste.dzfl.pl/f3b8989841e3

Benchmark result on dpaste.dzfl.pl:
SIMD:   TickDuration(157000)
Binary: TickDuration(472000)
Naive:  TickDuration(437000)

At home with defult dub config "dub run --build=release":
SIMD:TickDuration(241566)
Binary:  TickDuration(450515)
Naive:   TickDuration(450371)


This is compelling but needs a bit of work to integrate. Care to work on 
a PR that makes std.algorithm use it? Thanks! -- Andrei

Re: Kinds of containers

[Andrei Alexandrescu via Digitalmars-d]

On 10/25/2015 05:06 PM, Timon Gehr wrote:


class A{};
class B: A{};

int main(){
 vector a;
 vector b;
 a=b;
}

However, the conversion would be safe.


Agreed. I don't see that as an important matter though; it's after all a 
coercion so a function call is plenty fine. -- Andrei

Re: Option types and pattern matching.

[Nerve via Digitalmars-d]

On Sunday, 25 October 2015 at 06:22:51 UTC, TheFlyingFiddle wrote:
You can do something very similar to that. With slightly 
different syntax.


import std.traits;
import std.conv;
import std.variant;
struct CMatch(T...) if(T.length == 1)
{
   alias U = typeof(T[0]);
   static bool match(Variant v)
   {
  if(auto p = v.peek!U)
 return *p == T[0];
  return false;
   }
}

auto ref match(Handlers...)(Variant v)
{
   foreach(handler; Handlers)
   {
  alias P = Parameters!handler;
  static if(P.length == 1)
  {
 static if(isInstanceOf!(CMatch, P[0]))
 {
if(P[0].match(v))
   return handler(P[0].init);
 }
 else
 {
if(auto p = v.peek!(P[0]))
   return handler(*p);
 }
  }
  else
  {
 return handler();
  }
   }

   assert(false, "No matching pattern");
}

unittest
{
Variant v = 5;
string s = v.match!(
(CMatch!7) => "Lucky number seven",
(int n)=> "Not a lucky number: " ~ n.to!string,
() => "No value found!");

   writeln(s);
}


That is actually freaking incredible. It evaluates to a value, 
unwraps values, matches against the None case...I guess the only 
thing it doesn't do is have compiler-enforced matching on all 
cases. Unless I'm just slow this morning and not thinking of 
other features a pattern match should have.

Re: Calypso progress report (+ updated MingW64 build)

[Elie Morisse via Digitalmars-d-announce]

On Friday, 23 October 2015 at 09:19:44 UTC, Kagamin wrote:
On Thursday, 22 October 2015 at 23:24:57 UTC, Elie Morisse 
wrote:

Default constructors are invoked


Including class fields?

class A
{
  QString s_myFilename;
  this()
  {
//is s_myFilename constructed already?
  }
}


That triggered my own assert, oops. It's fixed now, the field 
default ctor is called if the field has no initializer, just 
before A's ctor.

Re: Vision

[Andrei Alexandrescu via Digitalmars-d]

On 10/21/2015 10:17 PM, Vladimir Panteleev wrote:

On Wednesday, 21 October 2015 at 22:35:35 UTC, Andrei Alexandrescu wrote:

TWiD is an official newsletter. -- Andrei


For being an official newsletter, it doesn't get the exposure it deserves.

So Adam and I put this together today:

https://github.com/D-Programming-Language/dlang.org/pull/1136


Looks fantastic and Adam sent me word it increased traffic considerably 
- good job! -- Andrei

Re: Kinds of containers

[Andrei Alexandrescu via Digitalmars-d]

On 10/23/2015 01:44 PM, deadalnix wrote:

On Friday, 23 October 2015 at 11:03:37 UTC, Andrei Alexandrescu wrote:

On 10/22/15 1:09 AM, deadalnix wrote:

The elephant in the room: make the template parameter's type qualifier
transitive with the collection's qualifier.


Could you please give more detail on this? Thanks! -- Andrei


Sure. We have a problem when it come to collection in the fact that type
qualifier do not turtle down as one would expect.

Collection!T and Collection!const(T) are 2 completely different types.
There is a good reason for this : static if (is(T == const)) { ... } .
As a result thing like :

void foo(T)(const Collection!const(T) c) {}
void main() {
   Collection!T c;
   foo(c); // Error, GTFO !
}


Makes sense. The way I like to think about it is in terms of 
compatibility with built-in types such slices. This code works:


void foo(T)(const T[] c) {}
void main() {
  int[] c;
  foo(c); // fine
}


With the different qualifiers and implicit conversion, thing become
quite tricky. You can simulate them partially with a set of carefully
crafted alias this (but not having multiple alias this doesn't make
things any simpler) but there is the monster of mutually recursive
template instanciation that is lurking.

As far as i know, jmdavis had some good work done on this, but it was
far from perfect.


Thanks, I see. The way I see it is as the work of "alias this"; any 
failure can be ascribed as a burden on the alias this definition.


Jonathan, do you have a link to your work?


Andrei

Re: Option types and pattern matching.

[TheFlyingFiddle via Digitalmars-d]

On Sunday, 25 October 2015 at 14:43:25 UTC, Nerve wrote:
On Sunday, 25 October 2015 at 06:22:51 UTC, TheFlyingFiddle 
wrote:
That is actually freaking incredible. It evaluates to a value, 
unwraps values, matches against the None case...I guess the 
only thing it doesn't do is have compiler-enforced matching on 
all cases. Unless I'm just slow this morning and not thinking 
of other features a pattern match should have.


With some changes to the match function one could enforce that a 
default handler is always present so that all cases are handled 
or error on compilation if it's not.


Something like: (naive way)

auto ref match(Handlers...)(Variant v)
{
//Default handler must be present and be the last handler.
static assert(Parameters!(Handlers[$ - 1]).length == 0,
  "Matches must have a default handler.");
}

now

//Would be a compiler error.
v.match!((int n) => n.to!string));

//Would work.
v.match!((int n) => n.to!string),
 () => "empty");

Additionally one could check that all return types share a common 
implicit conversion type. And cast to that type in the match.


//Returns would be converted to long before being returned.
v.match!((int n)  => n, //Returns int
 (long n) => n, //Returns long
 ()   => 0);

Or if they don't share a common implicit conversion type return a 
Variant result.


Also the handlers could be sorted so that the more general 
handlers are tested later.


//Currently
v.match!((int n) => n,
 (CMatch!7) => 0,
 () => 0);

Would not really work since (int n) is tested for first so 
CMatch!7 would never get called even if the value was 7. But if 
we sort the incoming Handlers with CMatch instances at the front 
then the above would work as a user intended. This would also 
allow the empty/default case to be in any order.


For even more error checking one could make sure that no CMatch 
value intersects with another. That way if there are for example 
two cases with CMatch!7 then an assert error would be emited.


So:
v.match!((CMatch!7) => "The value 7",
 (CMatch!7) => "A seven value",
 () => "empty");

Would error with something like "duplicate value in match"

Other extensions one could do to the pattern matching is:

1. Allow more then one value in CMatch. So CMatch!(5, 7) would 
mean either 5 or 7.
2. Rust has a range syntax, this could be kind of nice. Maybe 
RMatch!(1, 10) for that.

3. Add a predicate match that takes a lambda.

//Predicate match.
struct PMatch(alias lambda)
{
alias T = Parameters!(lambda)[0];
alias this value;
T value;
static bool match(Variant v)
{
   alias P = Parameters!lambda;
   if(auto p = v.peek!P)
   {
  if(lambda(*p))
  {
  value = *p;
  return true;
  }
   }
   return false;
}
}

struct RMatch(T...) if(T.length == 2)
{
   alias C = CommonType!(typeof(T[0]), typeof(T[1]));
   C value;
   alias this value;

   static bool match(Variant v)
   {
  if(auto p = v.peek!C)
  {
 if(*p >= T[0] && *p < T[1])
 {
 value = *p;
 return true;
 }
  }
  return false;
   }
}

v.match!(
  (RMatch!(1, 10) n) => "Was (1 .. 10): " ~ n.to!string;
  (PMatch!((int x) => x % 2 == 0) n) => "Was even: " ~ 
n.to!string,
  (PMatch!((int x) => x % 2 == 1) n) => "Was odd:  " ~ 
n.to!string,

  () => "not an integer");

The PMatch syntax is not the most fun... It can be reduced 
slightly if your not using a variant but a Maybe!T type or a 
regular old type to.


The pattern matching can have more static checks and the syntax 
can look a somewhat better if we are matching on a Maybe!T type 
or a regular type instead of a variant. We could for example make 
sure that all CMatch/RMatch values have the correct type and (in 
some limited cases) ensure that all cases are covered without the 
need for a default switch.


All in all I think that something like this would be a fairly 
comprehensive library pattern matching solution. Catching many 
types of programming errors at compile-time. It could be fast as 
well if all the constants and ranges are converted into a switch 
statements (via string mixin magic).


This problem has gained my interest and I plan on implementing 
this sometime this week. I'll post a link to the source when it's 
done if anyone is interested in it.

fwiw - study of traits of popular posts on hacker news

[Laeeth Isharc via Digitalmars-d-learn]

Of course it doesn't follow that merely aping the traits of 
popular posts will produce the same result as actually having the 
essence of whatever it is that truly makes a post popular.  But 
this was still quite interesting, and it's nice to see people 
exploring the data.


http://www.dkriesel.com/en/blog/2015/1025_a_data-driven_guide_to_creating_successful_hacker_news_posts

Re: Kinds of containers

[Andrei Alexandrescu via Digitalmars-d]

On 10/24/2015 07:03 PM, Timon Gehr wrote:

On 10/24/2015 09:22 PM, Andrei Alexandrescu wrote:

On 10/24/15 3:19 PM, Timon Gehr wrote:

Even if this was possible, it would not be a very good idea. Persistent
data structures have use cases that would be hindered by required
transitive immutability.


This part I don't quite get.


The slots are not mutable, but they are not /transitively/ immutable
either. Note that this does not require any special effort, nor does it
/prevent/ stored elements from being (transitively) immutable. Scala
does it this way. (Haskell as well, basically.)


I see. Well, this will be unpleasant to implement in D.

One simple way to do so would be to have accessors return rvalues:

T front() { ... }

Then you get to change the indirections of T, if any, but not what's 
stored in the container directly.


Problem is accessing every element by rvalue is likely to be inefficient 
in the general case (even on data without copy ctors).



Andrei

Re: Kinds of containers

[Andrei Alexandrescu via Digitalmars-d]

On 10/23/2015 07:21 PM, bigsandwich wrote:

On Friday, 23 October 2015 at 17:44:55 UTC, deadalnix wrote:

On Friday, 23 October 2015 at 11:03:37 UTC, Andrei Alexandrescu wrote:

[...]


Sure. We have a problem when it come to collection in the fact that
type qualifier do not turtle down as one would expect.

[...]


Its not just type qualifiers. Containers of derived types have the same
problem.  This is also a problem in C++.


This is something easy to live with. In fact, mutable containers are not 
supposed to even convert to containers of base objects. -- Andrei

Re: Adapting Tree Structures for Processing with SIMD,Instructions

[Iakh via Digitalmars-d]

On Wednesday, 23 September 2015 at 09:58:39 UTC, Marco Leise 
wrote:

Am Tue, 22 Sep 2015 16:36:40 +
schrieb Iakh :

[...]


Implementatation of SIMD find algorithm:
http://forum.dlang.org/post/hwjbyqnovwbyibjus...@forum.dlang.org

Re: Option types and pattern matching.

[Dmitry Olshansky via Digitalmars-d]

On 25-Oct-2015 08:01, Nerve wrote:

Hello D community! First time poster, I'm utterly fascinated with this
language's mix of features. It's powerful and expressive.

There are just two conveniences I'd like to see out of D. The first is
pattern matching, a functional construct which can unwrap tuples or
other containers, usually evaluates to a value (in most languages), and
which almost always idiomatically enforces the programmer to match over
every possible case of a given type.

While ML-inspired languages like F# and OCaml have some good pattern
matching syntax, it's not syntax which would fit in to D; I suggest
taking inspiration of Rusts's matching construct.

match x {
 Some(7) => "Lucky number 7!",
 Some(_) => "No lucky number.",
 None => "No value found"
}



I humbly believe that D may just add special re-write rule to the switch 
statement in order to allow user-defined switchable types. This goes 
along nicely with the trend - e.g. foreach statement works with anything 
having static range interfaces or opApply.


All in all we've seen a lot of examples of how it's done in the library 
but always somewhat cumbersome. The next big problem would be that 
switch is a statement not expression which limits use-cases of 
user-defined pattern matching.



--
Dmitry Olshansky

Re: Option types and pattern matching.

[TheFlyingFiddle via Digitalmars-d]

On Sunday, 25 October 2015 at 18:23:42 UTC, Dmitry Olshansky 
wrote:
I humbly believe that D may just add special re-write rule to 
the switch statement in order to allow user-defined switchable 
types. This goes along nicely with the trend - e.g. foreach 
statement works with anything having static range interfaces or 
opApply.


I don't think I understand this, could you elaborate?

Re: Option types and pattern matching.

[John Colvin via Digitalmars-d]

On Sunday, 25 October 2015 at 18:15:20 UTC, TheFlyingFiddle wrote:
This problem has gained my interest and I plan on implementing 
this sometime this week. I'll post a link to the source when 
it's done if anyone is interested in it.


Without having looked at this in detail, phobos should have a 
good generic implementation of pattern matching, so you should 
consider creating a pull request (std.functional would be the 
natural home I think).

Re: Option types and pattern matching.

[Jacob Carlborg via Digitalmars-d]

On 2015-10-25 20:00, John Colvin wrote:


Without having looked at this in detail, phobos should have a good
generic implementation of pattern matching, so you should consider
creating a pull request (std.functional would be the natural home I think).


I've been waiting for this PR [1] to get merged before implementing 
pattern matching as a library function.


[1] https://github.com/D-Programming-Language/dmd/pull/5201

--
/Jacob Carlborg

Playing SIMD

[Iakh via Digitalmars-d]

Here is my implementatation of SIMD find. Function returns index 
of ubyte in static 16 byte array with unique values.


--
immutable size_t ArraySize = 16;
int simdIndexOf(ubyte niddle, ref const ubyte[ArraySize] haystack)
{
ubyte16 arr;
arr.array = haystack[];
ubyte16 niddles;
niddles.array[] = niddle;
ubyte16 result;
result = __simd_sto(XMM.PCMPEQB, arr, niddles);
alias Mask = ulong;
static assert(2 * Mask.sizeof == result.sizeof);
immutable BitsInByte = 8;

if (Mask mask = *cast(Mask*)(result.array.ptr))
{
return bsf(mask) / BitsInByte;
}
else if (Mask mask = *cast(Mask*)(result.array.ptr + 
Mask.sizeof))

{
return bsf(mask) / BitsInByte + cast(int)Mask.sizeof;
}
else
{
return -1;
}

}
--

Is it optimal and how do you implement this stuf?

Full exaple with comparation of algorithms (SIMD, naive, binary 
search):

http://dpaste.dzfl.pl/f3b8989841e3

Benchmark result on dpaste.dzfl.pl:
SIMD:   TickDuration(157000)
Binary: TickDuration(472000)
Naive:  TickDuration(437000)

At home with defult dub config "dub run --build=release":
SIMD:TickDuration(241566)
Binary:  TickDuration(450515)
Naive:   TickDuration(450371)