Re: SegFault with HibernateD

[Ali Çehreli via Digitalmars-d-learn]

On 01/12/2018 06:50 PM, Venkat wrote:
> Sorry about all these posts. Wish there were an edit button.

That's ok. :) These are actually newsgroups (see NNTP protocol). 
Newsgroups don't have any edit functionality. The "forum" is just a web 
interface to newsgroups.


Ali

Re: Using Postgres connection functions

[Joe via Digitalmars-d-learn]

Going beyond the connection, there are various other libpq 
functions that use a similar pattern of values passed using 
multiple parallel C arrays, e.g.,


   PGresult *PQexecParams(PGconn *conn,
   const char *command,
   int nParams,
   const Oid *paramTypes,
   const char * const *paramValues,
   const int *paramLengths,
   const int *paramFormats,
   int resultFormat);

Each of the `paramXxxxs' arguments are arrays (Oid is an alias 
for uint).


   PGresult *PQprepare(PGconn *conn,
const char *stmtName,
const char *query,
int nParams,
const Oid *paramTypes);

   PGresult *PQexecPrepared(PGconn *conn,
 const char *stmtName,
 int nParams,
 const char * const *paramValues,
 const int *paramLengths,
 const int *paramFormats,
 int resultFormat);

My point is that there seems to be a need to have a generic or 
generalized mechanism for passing these argument arrays from D to 
C.

Re: [howto] Serve ddox documentation on github.io deployed by Travis CI

[Seb via Digitalmars-d-announce]

On Saturday, 13 January 2018 at 04:59:25 UTC, Martin Nowak wrote:
On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo 
wrote:

[...]


What do you mean with "taking care of it"?
It's a bit of a hen and egg problem, first you need a project 
before you can register it with code.dlang.org. So that seems 
like a sub-optimal place to help with project setup.


[...]


Citing Sönke:

The whole dub init -t feature is planned to be replaced by a 
more general approach, so it would be rather wasteful to invest 
more time than necessary in this. The new approach basically 
would simply look for a ":example" (or similar) sub package for 
the first dependency specified to dub init, uses that as the 
base for the newly created package, and would then just adjust 
the recipe according to the remaining init parameters.


https://github.com/dlang/dub/pull/1326#issuecomment-357233196

Re: [howto] Serve ddox documentation on github.io deployed by Travis CI

[Martin Nowak via Digitalmars-d-announce]

On Wednesday, 10 January 2018 at 08:50:37 UTC, Bastiaan Veelo 
wrote:
Maybe worthwile to add this scaffolding to dub or some other 
tool? Anyone volunteering?


This could be a good idea. Probably even better is to let 
code.dlang.org take care of it, which would make the whole 
token issue and setup obsolete.


What do you mean with "taking care of it"?
It's a bit of a hen and egg problem, first you need a project 
before you can register it with code.dlang.org. So that seems 
like a sub-optimal place to help with project setup.


Dub init would be much better suited. We should figure out to 
make the existing init templates extensible anyhow.

Re: Using Postgres connection functions

[Joe via Digitalmars-d-learn]

On Saturday, 13 January 2018 at 04:26:06 UTC, Adam D. Ruppe wrote:

If and only if the values are known at compile time, you can do:

const char** keywords = ["hostaddr".ptr, "port".ptr, 
"dbname".ptr, null].ptr;


or even do it inline:


PQconnectdbParams(["hostaddr".ptr, "port".ptr, "dbname".ptr, 
null].ptr, ditto_for_values, 1);


The keywords are (or could be) known at compile time, but almost 
by definition, the associated values are only known at runtime.

Re: Using Postgres connection functions

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

On Saturday, 13 January 2018 at 04:17:02 UTC, Joe wrote:
It only compiled after I removed the second 'const' in the 
first and second arguments.


Yeah, D's const applies down the chain automatically, so you 
don't write it twice there.



string[] keywords = ["hostaddr", "port", "dbname"];
string[] values = ["127.0.0.1", "5432", "testdb"];



conn = PQconnectdbParams(cast(const char **)kws,
 cast(const char **)vals, 1);

So my question is: is there an easier or better way of passing 
two arrays of C null-terminated strings to an extern(C) 
function?


If and only if the values are known at compile time, you can do:

const char** keywords = ["hostaddr".ptr, "port".ptr, 
"dbname".ptr, null].ptr;


or even do it inline:


PQconnectdbParams(["hostaddr".ptr, "port".ptr, "dbname".ptr, 
null].ptr, ditto_for_values, 1);




Otherwise, what you did there is decent... being a C style of 
array of arrays, it will need to be coded in a C style with stuff 
like malloc and toStringz to convert D to C strings too.

Using Postgres connection functions

[Joe via Digitalmars-d-learn]

I'm trying to learn how to use D to connect (and send queries) to 
Postgres, i.e., libpq in C. Postgres has three families of 
connection functions: PQsetdbLogin which takes multiple 
individual arguments (all as const char *), PQconnectdb which 
takes a single connection string (which Postgres then has to 
parse into keywords/values) and PQconnectdbParams (introduced 
with PG 9.0 in 2010) which takes two arrays of char pointers, one 
for the keywords and another for the values, i.e., it's 
pre-parsed, and I believe, more convenient for callers since it's 
most likely that they get the parameter values from command line 
arguments, environment values or UI dialogs, so it saves the 
connection string formatting on the caller side and the 
parsing/decomposing on the library side.


In spite of the latter considerations, it appears most D 
libraries for Postgres only support connection string usage (only 
derelict-pq has a declaration for PQconnectdbParams--but I 
haven't tested it).


In any case, I tried to use PQconnectdbParams by first declaring 
it, as per the Postgres manual, with


extern(C)
{
struct PGconn;

PGconn *PQconnectdbParams(const char * const * keywords,
  const char * const * values,
  int expand_dbname);
}

This caused ldc2, on Linux, to complain as follows:

connection.d(30): Error: found 'const' when expecting ')'
connection.d(30): Error: semicolon expected following function 
declaration

connection.d(30): Error: declaration expected, not '*'

It only compiled after I removed the second 'const' in the first 
and second arguments.


The hard thing was figuring out how to pass the keyword/values 
arrays, defined as:


string[] keywords = ["hostaddr", "port", "dbname"];
string[] values = ["127.0.0.1", "5432", "testdb"];

to the D invocation of PQconnectdbParams.  I ended up with the 
following, which looks like covering a patient with lots of 
bandaids and looking the other way (and I had to modify the 
arrays above with a fixed length).


extern(C) char * [keywords.length + 1] kws;
extern(C) char * [keywords.length + 1] vals;
foreach (i, k; keywords) {
kws[i] = cast(char *)toStringz(k);
vals[i] = cast(char *)toStringz(values[i]);
}
kws[keywords.length] = null;  // Postgres wants the NULL 
termination

vals[keywords.length] = null;

conn = PQconnectdbParams(cast(const char **)kws,
 cast(const char **)vals, 1);

I assume that in a real program I'd have to malloc the C arrays, 
since I wouldn't know beforehand how many parameters there would 
be (or I could define them with a static size of about 30 since 
that's how many connection parameters are recognized currently).


So my question is: is there an easier or better way of passing 
two arrays of C null-terminated strings to an extern(C) function?

Re: Some Observations on the D Development Process

[Walter Bright via Digitalmars-d]

On 1/9/2018 6:53 PM, Mike Franklin wrote:

I couldn't find any cases like that.  If you know of them, please
explicitly identify them for me.


I already fixed them.

Re: continue in static foreach

[Seb via Digitalmars-d-learn]

On Saturday, 13 January 2018 at 01:07:24 UTC, Marc wrote:

On Friday, 12 January 2018 at 22:03:53 UTC, H. S. Teoh wrote:
On Fri, Jan 12, 2018 at 10:03:40PM +, Marc via 
Digitalmars-d-learn wrote:

How do I use?

> static foreach(enum string member; members) {
>static if(isFunction!(__traits(getMember, C, member))) {
>continue;
>}

give error:

> must use labeled continue within static foreach

then I tried:

> outer:static foreach(enum string member; members) {
>static if(isFunction!(__traits(getMember, C, member))) {
>continue outer;
>}

give error:

> Error: enclosing label outer for continue not found

How do I fix it?


Unfortunately, this is currently not supported. You'll have to 
use an else-clause to handle the case when the condition is 
false.



T


thanks


It was mentioned in DIP1010, but that bit hasn't been accepted 
yet:


https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md#static-break-and-static-continue

Re: Tuple DIP

[jmh530 via Digitalmars-d]

On Saturday, 13 January 2018 at 02:15:37 UTC, Basile B. wrote:

On Saturday, 13 January 2018 at 02:08:03 UTC, jmh530 wrote:

[snip]
Also, Proposal 1 starts with this example
auto (a, b) = tuple(1, "2");
(int a, string b) = tuple(1, "2");
but it also looks natural to be able to write
(int, string) (a, b) = tuple(1, "2");


Really ?
After the type should be the declarator. In this example 
there's no declarator but if you add it then it becomes very 
strange:


(int, string) ab (a, b) = tuple(1, "2");


I left out a word there...I had meant that it would be natural to 
replace the auto version with that version. I would think it 
would work in combination with Proposal 3.


If
auto (a, b) = tuple(1, "2");
works, then surely
__Tuple!(int, string) (a, b) = tuple(1, "2");
should work, which is equivalent to
(int, string) (a, b) = tuple(1, "2");

Re: SegFault with HibernateD

[Venkat via Digitalmars-d-learn]

Sorry about all these posts. Wish there were an edit button. I 
meant PreparedStatement in mysqlddbc driver, not HibernateD.

Re: SegFault with HibernateD

[Venkat via Digitalmars-d-learn]

I think there is a bug with PreparedStatement class in 
HibernateD. ddbc fails when I use a PreparedStatement. The code 
below shows that. I will create an issue with HibernateD.



int main(string[] args) {

string url = 
"mysql://localhost:3306/webmarx?user=webmarx_dev,password=webm@rx";


// creating Connection
auto conn = createConnection(url);
scope(exit) conn.close();

// creating Statement
auto stmt = conn.createStatement();
scope(exit) stmt.close();

 PreparedStatement prepStatement = 
conn.prepareStatement("SELECT * FROM preferences_wm ORDER BY id");

 scope(exit) prepStatement.close();
 ResultSet rs = prepStatement.executeQuery();

writeln(rs.getFetchSize());
return 0;
}

Re: Tuple DIP

[Basile B. via Digitalmars-d]

On Saturday, 13 January 2018 at 02:18:20 UTC, Basile B. wrote:

On Saturday, 13 January 2018 at 02:15:37 UTC, Basile B. wrote:

On Saturday, 13 January 2018 at 02:08:03 UTC, jmh530 wrote:

[...]


Really ?
After the type should be the declarator. In this example 
there's no declarator but if you add it then it becomes very 
strange:


(int, string) ab (a, b) = tuple(1, "2");


Forgot to say that on the other hand

  (int a, string b) ab = tuple(1, "2");

works better.


Better check twice than one. Actually i see now that there's no 
Declarator as used here, i.e for the whole tuple. Curious.

Re: Tuple DIP

[Basile B. via Digitalmars-d]

On Saturday, 13 January 2018 at 02:08:03 UTC, jmh530 wrote:

On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
As promised [1], I have started setting up a DIP to improve 
tuple ergonomics in D:

[snip]


I'm glad you're working on this.

Proposal 1 is a little terse in explaining what you mean by 
unpacking AliasSeqs. You might explain it in a little more 
detail.


Also, Proposal 1 starts with this example
auto (a, b) = tuple(1, "2");
(int a, string b) = tuple(1, "2");
but it also looks natural to be able to write
(int, string) (a, b) = tuple(1, "2");


Really ?
After the type should be the declarator. In this example there's 
no declarator but if you add it then it becomes very strange:


(int, string) ab (a, b) = tuple(1, "2");

Re: Tuple DIP

[Basile B. via Digitalmars-d]

On Saturday, 13 January 2018 at 02:15:37 UTC, Basile B. wrote:

On Saturday, 13 January 2018 at 02:08:03 UTC, jmh530 wrote:

On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
As promised [1], I have started setting up a DIP to improve 
tuple ergonomics in D:

[snip]


I'm glad you're working on this.

Proposal 1 is a little terse in explaining what you mean by 
unpacking AliasSeqs. You might explain it in a little more 
detail.


Also, Proposal 1 starts with this example
auto (a, b) = tuple(1, "2");
(int a, string b) = tuple(1, "2");
but it also looks natural to be able to write
(int, string) (a, b) = tuple(1, "2");


Really ?
After the type should be the declarator. In this example 
there's no declarator but if you add it then it becomes very 
strange:


(int, string) ab (a, b) = tuple(1, "2");


Forgot to say that on the other hand

  (int a, string b) ab = tuple(1, "2");

works better.

Re: Tuple DIP

[jmh530 via Digitalmars-d]

On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
As promised [1], I have started setting up a DIP to improve 
tuple ergonomics in D:

[snip]


I'm glad you're working on this.

Proposal 1 is a little terse in explaining what you mean by 
unpacking AliasSeqs. You might explain it in a little more detail.


Also, Proposal 1 starts with this example
auto (a, b) = tuple(1, "2");
(int a, string b) = tuple(1, "2");
but it also looks natural to be able to write
(int, string) (a, b) = tuple(1, "2");
it looks from some of the other proposals that if they combine 
together then this would also work.


Proposal 3 could use an example with named tuples.

In proposal 6, how does
auto (a, _) = t;
expand for multiple? Would you be forced to do
auto (a, _, _, _, _, _) = t;
if the tuple has 6 entries?

Re: Tuple DIP

[SrMordred via Digitalmars-d]

On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:

As promised [1], I have started setting up a DIP to improve

+1, please.

Re: Another take on decimal data types

[rumbu via Digitalmars-d-announce]

On Friday, 12 January 2018 at 13:09:42 UTC, kdevel wrote:


$ dmd nosine.d decimal.git/libdecimal.a
decimal/package.d(10505): Error: undefined identifier 
decimalCapAngle


Sorry, broke some code when I made the split. Now it's working.

Re: Tuple DIP

[rikki cattermole via Digitalmars-d]

On 12/01/2018 10:44 PM, Timon Gehr wrote:
As promised [1], I have started setting up a DIP to improve tuple 
ergonomics in D:


https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md


This DIP aims to make code like the following valid D:

---
auto (a, b) = (1, 2);
(int a, int b) = (1, 2);
---

---
foreach((sum, diff); [(1, 2), (4, 3)].map!((a, b) => (a + b, a - b)))
{
     writeln(sum, " ", diff);
}
/+ prints:
3 -1
7 1
+/
---

Before going ahead with it, I'd like some preliminary community input:

- I'm not yet completely satisfied with the DIP.
   (See section "Limitations".)
   Please let me know suggestions or further concerns you might have.


- There are good example use cases missing. While I'm confident I could
   invent a few of them given a little time, I thought maybe I can
   expedite the process and make the point more convincingly by asking
   for use cases you encountered in your own code. The DIP already
   contains an example due to bearophile.


[1] https://forum.dlang.org/post/or625h$2hns$1...@digitalmars.com


I really dislike the syntax, it looks hard to parse.

#{int, string}

Where T... all equal types

#{1, "str"}

Where T... all equal values
Alternatively:

#(1, "str")

Since it is "arguments" to "construct" it.
Doesn't that look easier to parse and use?


It can be just a bit of syntax suger around (in object.di):

struct Tuple(T...) {
alias Types = T;

T args;

// opIndex/opIndexAssign
}

Re: continue in static foreach

[Marc via Digitalmars-d-learn]

On Friday, 12 January 2018 at 22:03:53 UTC, H. S. Teoh wrote:
On Fri, Jan 12, 2018 at 10:03:40PM +, Marc via 
Digitalmars-d-learn wrote:

How do I use?

> static foreach(enum string member; members) {
>static if(isFunction!(__traits(getMember, C, member))) {
>continue;
>}

give error:

> must use labeled continue within static foreach

then I tried:

> outer:static foreach(enum string member; members) {
>static if(isFunction!(__traits(getMember, C, member))) {
>continue outer;
>}

give error:

> Error: enclosing label outer for continue not found

How do I fix it?


Unfortunately, this is currently not supported. You'll have to 
use an else-clause to handle the case when the condition is 
false.



T


thanks

Re: SegFault with HibernateD

[Venkat via Digitalmars-d-learn]

On Friday, 12 January 2018 at 08:55:13 UTC, Rene Zwanenburg wrote:
Hard to guess what the issue is, I'd attach a debugger to see 
where it crashes.


It fails at the sql() method in Command struct in 
mysql-native-1.1.4/mysql-native/source/mysql/commands.d. This is 
what gdb says when I do a disp _sql.


1: _sql = 

I'm sorry I am new to systems programming, would that mean _sql 
is null ?

Re: Tuple DIP

[Timon Gehr via Digitalmars-d]

On 13.01.2018 01:20, Mark wrote:


Could we also support function tuples?


In principle, yes, though I imagine it is a lot harder to argue for its 
inclusion than for that of the features currently proposed in the DIP, 
because existing language features already come rather close.



For instance:

int sum(int a, int b) { return a+b; }
int diff(int a, int b) { return a-b; }

(int, int) f = (sum, diff) // no ";" for consistency with existing syntax


No ";" is inconsistent. Also the type of f cannot be (int, int), and 
(sum, diff) would try to call sum and diff with 0 arguments and fail.



int (x,y) = f(1, 2); // x=3, y=-1
int (w,z) = (1, 2).f() // same as above, UFCS
int (u,v) = (1, 2).(sum, diff) // same as above, "lambda tuple"

In the last example, (sum, diff) is basically lowered to (x,y) => 
(sum(x,y), diff(x,y)).


I think this is easy enough to achieve without dedicated syntax:

import std.typecons;

template apply(F...){
auto apply(T)(T arg){
import std.conv, std.range, std.algorithm;
return 
mixin(text("(",iota(F.length).map!(i=>text("F[",i,"](arg)")).join(","),")"));

}
}

void main(){
int sum(int a, int b) { return a+b; }
int diff(int a, int b) { return a-b; }
auto (u,v)=(1,2).apply!(sum, diff);
import std.stdio;
writeln(u," ",v);
}

Re: Tuple DIP

[Rubn via Digitalmars-d]

Should include an example of returning a tuple from a function. I 
know one of the pains with variadic templates is that they can't 
be returned.


So maybe something that goes over the following use case:


auto returnTuple(Args...)(Args args)
{
return args;
}


(int a, float b) = returnTuple(4, 1.0f);


Or just returning your regular tuple:


(int, float) returnSomeTuple()
{
return (10, 1.0f); // or whatever
}

Re: SegFault with HibernateD

[Venkat via Digitalmars-d-learn]

On Friday, 12 January 2018 at 12:41:34 UTC, Mike Parker wrote:


I see now. I glossed right over that execution output. On 
Windows, I don't recall ever seeing a dub exception from dub 
from a segfault. Just checked by accessing a null pointer and 
there's nothing thrown from dub. Is that a Linux thing?


 Thankyou for the reply. Yes I am running the app on Linux. I 
will report the issue.

Re: Tuple DIP

[Chris M. via Digitalmars-d]

On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
As promised [1], I have started setting up a DIP to improve 
tuple ergonomics in D:


[...]


Yes please

Re: Tuple DIP

[Timon Gehr via Digitalmars-d]

On 13.01.2018 00:16, Basile B. wrote:

On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
As promised [1], I have started setting up a DIP to improve tuple 
ergonomics in D:


https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md


markdown trick: you can use


```diff
```

for a nicer grammar section.


Updated, thanks!

Re: Tuple DIP

[Mark via Digitalmars-d]

On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
As promised [1], I have started setting up a DIP to improve 
tuple ergonomics in D:


https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md


This DIP aims to make code like the following valid D:

---
auto (a, b) = (1, 2);
(int a, int b) = (1, 2);
---

---
foreach((sum, diff); [(1, 2), (4, 3)].map!((a, b) => (a + b, a 
- b)))

{
writeln(sum, " ", diff);
}
/+ prints:
3 -1
7 1
+/
---

Before going ahead with it, I'd like some preliminary community 
input:


- I'm not yet completely satisfied with the DIP.
  (See section "Limitations".)
  Please let me know suggestions or further concerns you might 
have.



- There are good example use cases missing. While I'm confident 
I could
  invent a few of them given a little time, I thought maybe I 
can
  expedite the process and make the point more convincingly by 
asking
  for use cases you encountered in your own code. The DIP 
already

  contains an example due to bearophile.


[1] https://forum.dlang.org/post/or625h$2hns$1...@digitalmars.com


Could we also support function tuples? For instance:

int sum(int a, int b) { return a+b; }
int diff(int a, int b) { return a-b; }

(int, int) f = (sum, diff) // no ";" for consistency with 
existing syntax

int (x,y) = f(1, 2); // x=3, y=-1
int (w,z) = (1, 2).f() // same as above, UFCS
int (u,v) = (1, 2).(sum, diff) // same as above, "lambda tuple"

In the last example, (sum, diff) is basically lowered to (x,y) => 
(sum(x,y), diff(x,y)).

[Issue 18233] building with -m64 doesn't work with sc.ini from the zip distribution and VS2017

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/e9b2864e1b0f59415045533423c64447b3e468aa
fix issue 18233 - building with -m64 doesn't work with sc.ini from the zip
distribution and VS2017

remove sc.ini entries for sections Environment64 and Environment32mscoff, these
are automatically detected by DMD

https://github.com/dlang/dmd/commit/a81d286dd69dafb6d8c2605804602b19e98634dd
Merge pull request #7686 from rainers/cleanup_ini

fix issue 18233 - building with -m64 doesn't work with sc.ini from zip
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 18233] building with -m64 doesn't work with sc.ini from the zip distribution and VS2017

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: The name "Phobos" in user-facing docs

[ag0aep6g via Digitalmars-d]

On 01/12/2018 11:26 PM, Michael wrote:
Tango was the original, and Phobos was introduced for D2 as a 
competing library.


Phobos is the original. In D1, Tango was an alternative standard 
library. With D2, you have Phobos as the standard library and you can 
use Tango on top of it. http://code.dlang.org/packages/tango

Re: The name "Phobos" in user-facing docs

[John Gabriele via Digitalmars-d]

On Friday, 12 January 2018 at 22:24:16 UTC, Dukc wrote:

On Friday, 12 January 2018 at 21:24:40 UTC, John Gabriele wrote:
 1. It has its own name. Phobos. This is unusual. I don't know 
of any other language who's std lib has any name other than 
"the {lang} standard library". Why does it have its own 
distinct name, and why do I (as a user) need to know it?


Because Walter Bright's company is named Digital Mars, D was 
initially named "Mars programming language". I am fairly 
certain that's the original reason for the name of the library. 
After all, why change it now when it's in common use? Where I 
live we have a saying: "A dear child has many names".


I don't think it should be changed, just removed from a few 
user-facing spots to increase clarity and remove any doubt about 
what's the D standard library.


Links and titles should just say "D Standard Library" or "Library 
Reference", and not mention "Phobos". It's a distraction to new 
users or possibly-returning-users who were around during the 
D1->D2 std lib transition.


On , it appears to me that 
it shouldn't say "phobos" anywhere (it's only in the top 
paragraphs as it is). Though maybe Walter or others like Phobos 
mentioned there for nostalgic reasons.


Anyhow, my comments aren't intended as complaints, but rather 
what I see as low-hanging easy marketing improvements for D.

Re: Tuple DIP

[Basile B. via Digitalmars-d]

On Friday, 12 January 2018 at 22:44:48 UTC, Timon Gehr wrote:
As promised [1], I have started setting up a DIP to improve 
tuple ergonomics in D:


https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md


markdown trick: you can use


```diff
```

for a nicer grammar section.

Re: Tuple DIP

[Timon Gehr via Digitalmars-d]

On 12.01.2018 23:44, Timon Gehr wrote:


---
auto (a, b) = (1, 2);
(int a, int b) = (1, 2);
---


(The two lines are two independent examples :o).)

Re: Tuple DIP

[Timon Gehr via Digitalmars-d]

On 12.01.2018 23:44, Timon Gehr wrote:

...

Before going ahead with it, I'd like some preliminary community input:
...
Also, if you have more links to forum posts requesting related features, 
that would be useful (googling turned up the ones that are in the DIP, 
but I know that there were more).

Tuple DIP

[Timon Gehr via Digitalmars-d]

As promised [1], I have started setting up a DIP to improve tuple 
ergonomics in D:


https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md


This DIP aims to make code like the following valid D:

---
auto (a, b) = (1, 2);
(int a, int b) = (1, 2);
---

---
foreach((sum, diff); [(1, 2), (4, 3)].map!((a, b) => (a + b, a - b)))
{
writeln(sum, " ", diff);
}
/+ prints:
3 -1
7 1
+/
---

Before going ahead with it, I'd like some preliminary community input:

- I'm not yet completely satisfied with the DIP.
  (See section "Limitations".)
  Please let me know suggestions or further concerns you might have.


- There are good example use cases missing. While I'm confident I could
  invent a few of them given a little time, I thought maybe I can
  expedite the process and make the point more convincingly by asking
  for use cases you encountered in your own code. The DIP already
  contains an example due to bearophile.


[1] https://forum.dlang.org/post/or625h$2hns$1...@digitalmars.com

Re: The name "Phobos" in user-facing docs

[Michael via Digitalmars-d]

On Friday, 12 January 2018 at 22:26:38 UTC, Michael wrote:

On Friday, 12 January 2018 at 21:24:40 UTC, John Gabriele wrote:

[...]


I mean, you're correct to say it's an artifact of D being an 
old language. Tango was the original, and Phobos was introduced 
for D2 as a competing library. I don't see this as being 
confusing for new users. When I learnt D, I simply understood 
that the standard library was called "Phobos" instead of "STL" 
some other associated term. It didn't ever become confusing, 
and when I learnt about Tango I was immediately made aware (by 
the context) that Tango was simply the old standard library, 
where Phobos had replaced it. This isn't any more confusing 
than C99, C11 etc. as versioning numbers for updates to the 
language and their libraries. D1 and Tango, D2 and Phobos. I 
don't think it's common to get the impression that Tango is 
still a competing library, though that may differ for some 
users.


I also just really like the name and hope that kind of convention 
continues. You have a core language (Digital Mars (the planet), 
or D) and its accompanying moon (Tango, then Phobos). I think it 
suits the language.

Re: The name "Phobos" in user-facing docs

[Tony via Digitalmars-d]

I had similar feelings when starting out with D - "why don't they 
say "standard library" instead of "Phobos"? I don't know that it 
would change D's image, but I think it would be better for 
newcomers if they only saw "standard library".

Re: The name "Phobos" in user-facing docs

[Michael via Digitalmars-d]

On Friday, 12 January 2018 at 21:24:40 UTC, John Gabriele wrote:
After having started learning some D lately, two things about 
the standard library have struck me:


 1. It has its own name. Phobos. This is unusual. I don't know 
of any other language who's std lib has any name other than 
"the {lang} standard library". Why does it have its own 
distinct name, and why do I (as a user) need to know it?


 2. There is evidently *still* some lingering FUD out there 
about some long-since-settled dual-standard-library issue. I 
haven't been around here long enough, but I still see 
references to Tango here and there.


I think it would help D's image to simply remove the name 
"phobos" from any user-facing docs. That is, change "phobos" to 
"the standard library" everywhere users would be looking. (Of 
course, *internally* the name "phobos" may still be useful for 
repo names, mailing list names, and what have you.)


Just the fact that the std lib *has* it's own user-facing name 
suggests that there may be more than one standard library (or 
else, why would it need its own special name to begin with?). 
It may also imply that the door is open for some other young 
upstart library to swoop in usurp the title of official 
standard library. The standard library having its own distinct 
user-facing name appears to sow confusion.


Maybe, historically, it was useful to have distinct names for 
competing potential D standard libraries, in order to 
distinguish them. Is that still the case?


I mean, you're correct to say it's an artifact of D being an old 
language. Tango was the original, and Phobos was introduced for 
D2 as a competing library. I don't see this as being confusing 
for new users. When I learnt D, I simply understood that the 
standard library was called "Phobos" instead of "STL" some other 
associated term. It didn't ever become confusing, and when I 
learnt about Tango I was immediately made aware (by the context) 
that Tango was simply the old standard library, where Phobos had 
replaced it. This isn't any more confusing than C99, C11 etc. as 
versioning numbers for updates to the language and their 
libraries. D1 and Tango, D2 and Phobos. I don't think it's common 
to get the impression that Tango is still a competing library, 
though that may differ for some users.

Re: The name "Phobos" in user-facing docs

[Dukc via Digitalmars-d]

On Friday, 12 January 2018 at 21:24:40 UTC, John Gabriele wrote:
 1. It has its own name. Phobos. This is unusual. I don't know 
of any other language who's std lib has any name other than 
"the {lang} standard library". Why does it have its own 
distinct name, and why do I (as a user) need to know it?


Because Walter Bright's company is named Digital Mars, D was 
initially named "Mars programming language". I am fairly certain 
that's the original reason for the name of the library. After 
all, why change it now when it's in common use? Where I live we 
have a saying: "A dear child has many names".

Re: continue in static foreach

[H. S. Teoh via Digitalmars-d-learn]

On Fri, Jan 12, 2018 at 10:03:40PM +, Marc via Digitalmars-d-learn wrote:
> How do I use?
> 
> > static foreach(enum string member; members) {
> > static if(isFunction!(__traits(getMember, C, member))) {
> > continue;
> > }
> 
> give error:
> 
> > must use labeled continue within static foreach
> 
> then I tried:
> 
> > outer:static foreach(enum string member; members) {
> > static if(isFunction!(__traits(getMember, C, member))) {
> > continue outer;
> > }
> 
> give error:
> 
> > Error: enclosing label outer for continue not found
> 
> How do I fix it?

Unfortunately, this is currently not supported. You'll have to use an
else-clause to handle the case when the condition is false.


T

-- 
Why waste time reinventing the wheel, when you could be reinventing the engine? 
-- Damian Conway

continue in static foreach

[Marc via Digitalmars-d-learn]

How do I use?


static foreach(enum string member; members) {
static if(isFunction!(__traits(getMember, C, m ember))) 
{
continue;
}


give error:


must use labeled continue within static foreach


then I tried:


outer:static foreach(enum string member; members) {
static if(isFunction!(__traits(getMember, C, > 
member))) {
continue outer;
}


give error:


Error: enclosing label outer for continue not found


How do I fix it?

The name "Phobos" in user-facing docs

[John Gabriele via Digitalmars-d]

After having started learning some D lately, two things about the 
standard library have struck me:


 1. It has its own name. Phobos. This is unusual. I don't know of 
any other language who's std lib has any name other than "the 
{lang} standard library". Why does it have its own distinct name, 
and why do I (as a user) need to know it?


 2. There is evidently *still* some lingering FUD out there about 
some long-since-settled dual-standard-library issue. I haven't 
been around here long enough, but I still see references to Tango 
here and there.


I think it would help D's image to simply remove the name 
"phobos" from any user-facing docs. That is, change "phobos" to 
"the standard library" everywhere users would be looking. (Of 
course, *internally* the name "phobos" may still be useful for 
repo names, mailing list names, and what have you.)


Just the fact that the std lib *has* it's own user-facing name 
suggests that there may be more than one standard library (or 
else, why would it need its own special name to begin with?). It 
may also imply that the door is open for some other young upstart 
library to swoop in usurp the title of official standard library. 
The standard library having its own distinct user-facing name 
appears to sow confusion.


Maybe, historically, it was useful to have distinct names for 
competing potential D standard libraries, in order to distinguish 
them. Is that still the case?

Re: Some Observations on the D Development Process

[Ali Çehreli via Digitalmars-d]

On 01/11/2018 02:15 PM, Johan Engelen wrote:

And I've been working for a long time on a fuzzing article. It's almost 
done!


- Johan



A fuzzy font would suit that article. :o)

Ali

Re: How to move an associative array between modules?

[H. S. Teoh via Digitalmars-d-learn]

On Fri, Jan 12, 2018 at 08:46:50PM +, WhatMeWorry via Digitalmars-d-learn 
wrote:
[...]
> I hate to keep being a bother, but my project with the below static
> this() now compiles fine, but aborts during runtime with a "a problem
> caused the program to stop working ..."

Is there a way to get at the actual error message? That would be
immensely more helpful in diagnosing the problem.

One potential pitfall of static this(), though unlikely given your
circumstances, is if there are multiple modules that use static this()
and there's a circular dependency somewhere.  If this is the problem,
splitting the static this() into a separate module may help.

If all else fails, you *could* just move the initialization code into
main() (or a function called by main()).  It's uglier, but should get
things going again until you have more time to investigate how to fix
the problem.


T

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. 
-- Donald Knuth

Re: How to move an associative array between modules?

[WhatMeWorry via Digitalmars-d-learn]

On Thursday, 11 January 2018 at 23:29:30 UTC, Adam D. Ruppe wrote:

On Thursday, 11 January 2018 at 23:20:44 UTC, WhatMeWorry wrote:
When I simply move the array out of main() but still in app.d, 
the compiler returns
Error: expression ["SCRATCH":Track("scratch.wav", 
cast(Sound)1, 0, null),...  is not a constant.


Can I use "static if" or "static this()", or "mixin" or some 
other technique?


Yeah, just declare the array outside, then initialize it inside 
a static this() constructor.


int[int] foo;
static this() {
  foo = [1:1];
}



I hate to keep being a bother, but my project with the below 
static this() now compiles fine, but aborts during runtime with a 
"a problem caused the program to stop working ..."


Does static if have some pitfalls I'm unaware of?

static this()
{
tracks["SCRATCH"] = Track("scratch.wav", Sound.SOUND_EFFECT, 
ONCE,null );


// or this form code segment

Track[string] tracks =
[
"SCRATCH" : Track("scratch.wav", Sound.SOUND_EFFECT, 
ONCE,null )

];

}

I even tried just foo = [1:1]; but that crashed during run time.

I have a writeln() statement just after main() so I know it is 
occurring before main().

Re: union/toString: crash/segfault: What's happening here?

[H. S. Teoh via Digitalmars-d-learn]

On Fri, Jan 12, 2018 at 10:49:45AM -0800, H. S. Teoh via Digitalmars-d-learn 
wrote:
> On Fri, Jan 12, 2018 at 11:09:47AM +, kdevel via Digitalmars-d-learn 
> wrote:
> [...]
[...]
> > https://issues.dlang.org/show_bug.cgi?id=18232
> 
> Yep, definitely a codegen bug.  Apparently, local variables in union
> member functions aren't initialized to .init as they should be.
[...]

Fix: https://github.com/dlang/dmd/pull/7687

Temporary workaround: explicitly initialize your local variables in
union member functions.


T

-- 
Life begins when you can spend your spare time programming instead of watching 
television. -- Cal Keegan

[Issue 18232] Union methods fail to initialize local variables to .init

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

   Keywords||pull

--- Comment #5 from hst...@quickfur.ath.cx ---
https://github.com/dlang/dmd/pull/7687

--

Re: Bump the minimal version required to compile DMD to 2.076.1

[Thomas Mader via Digitalmars-d]

On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

Motivation
--

1) It's required for Walter's work on using -betterC for the 
backend conversion:


https://github.com/dlang/dmd/pull/6907

2) We start to run into random failures lately, e.g.

https://github.com/braddr/d-tester/issues/63
https://github.com/dlang/dmd/pull/7569#issuecomment-356992048

3) There's also WIP to move dmd-cxx to 2.076.1:

https://github.com/dlang/dmd/pull/7595

So if we have to bump the minimal dmd version required to build 
DMD anyways for (1), let's be clear about it and state it.


Anyone objecting?


TLDR; I hope dmd needs a properly maintained bootstrap compiler 
branch with release tags of new versions every now and then as 
ldc does.


For packaging dmd on NixOS it is important to have a bootstrap 
compiler because the entire package tree of the distribution is 
build from scratch and no custom binaries can be used. (Well you 
can patch binaries with patchelf but that's not very nice and 
should probably only used for binary blobs)


Currently dmd 2.067.1 is used on NixOS as a bootstrap compiler 
and the last time I tried dmd-cxx it didn't work because of some 
build problems.
dmd 2.067.1 doesn't build with gcc6 which is the default for 
NixOS. This is not much of a problem because it can be easily 
overwritten to use gcc5 for the bootstrap compiler but still.
I also needed to patch things for the newest dmd version which I 
am slowly trying to upstream but since there are no bootstrap 
backports I can't get rid of those patches in the bootstrap 
package.


Which frontend version such a bootstrap branch has doesn't matter 
for me as long as it is maintained and I can build the newest 
version of dmd and all unit tests run successfully.

Re: Why is this valued zeroed?

[Marc via Digitalmars-d-learn]

On Friday, 12 January 2018 at 05:14:12 UTC, Jonathan M Davis 
wrote:
On Thursday, January 11, 2018 14:07:18 Ali Çehreli via 
Digitalmars-d-learn wrote:

[...]


And if all what you're doing is printing the value out, you 
might as well just print the Duration directly rather than 
calling total. Duration.toString returns the units in a 
human-readable format such as "2 secs, 300 msecs, and 24 μs" or 
"29 msecs".


https://dlang.org/phobos/core_time.html#.Duration.toString

And if you're doing something like adding up the time spent, 
then you'd be better off keeping it in a Duration than 
converting it to long holding seconds or milliseconds or 
whatever.


- Jonathan M Davis


I do use that value as following:

int t = fileSize / countOfByetsDownloaded * 
duration.total!"seconds";


I print that value there for testing only, if I was getting the 
values correctly.


Thank you all guys for the answers.

[Issue 18232] Union methods fail to initialize local variables to .init

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from hst...@quickfur.ath.cx ---
More interesting clues: running a union method inside CTFE containing a local
variable without an explicit initializer causes a CTFE error "cannot modify
variable at compile time", whereas explicitly initializing the local variable
works.

--
union U {
int method() {
int x; // causes CTFE failure unless explicitly initialized
return x;
}
}
enum y = U.init.method();
--

--

Re: union/toString: crash/segfault: What's happening here?

[H. S. Teoh via Digitalmars-d-learn]

On Fri, Jan 12, 2018 at 11:09:47AM +, kdevel via Digitalmars-d-learn wrote:
[...]
> On Friday, 12 January 2018 at 02:16:39 UTC, Adam D. Ruppe wrote:
[...]
> > I'd file this as a compiler codegen bug.
> 
> https://issues.dlang.org/show_bug.cgi?id=18232

Yep, definitely a codegen bug.  Apparently, local variables in union
member functions aren't initialized to .init as they should be.  Digging
into the compiler code right now to see if I can find where the problem
is...


T

-- 
Only boring people get bored. -- JM

Re: Release D 2.078.0

[Andre Pany via Digitalmars-d-announce]

On Friday, 12 January 2018 at 18:25:37 UTC, Rainer Schuetze wrote:


IMO removing the detected entries from sc.ini should be good 
enough: https://github.com/dlang/dmd/pull/7686. The linker path 
is built from the other VC variables. I've based it on stable 
in the hope it will make it into 2.078.1.


The more involved changes I mentioned are 
https://github.com/dlang/installer/pull/281 and 
https://github.com/dlang/dmd/pull/7500.


Thanks for your great work!

Kind regards
Andre

Re: Possible dmd 2.078 regression ?

[Basile B. via Digitalmars-d-learn]

On Friday, 12 January 2018 at 18:50:10 UTC, Basile B. wrote:

On Friday, 12 January 2018 at 17:58:30 UTC, Stefan Koch wrote:

On Friday, 12 January 2018 at 14:13:22 UTC, Basile B. wrote:
I have a simple program that only compiles if the dependency 
is not pre-compiled as a static library. It worked fine 
before.

I guess a mangle problem ?


Yes and quite old...apparently it's more a 2.074.x regression.
i'm digging right now.


digger: Commit 1e7b526b40852e9b85df3684430e371034cdf7ec (1/1) is 
untestable.

digger: There are only untestable commits left to bisect.
digger: The first bad commit could be any of:
digger: 1e7b526b40852e9b85df3684430e371034cdf7ec
digger: 6fecaa8232a427fb3ca29c5a5245e08fc43b71b1
digger: f0410bea1ad2b130884964d603b34e729b3e4f69
object.Exception@bisect.d(186): We cannot bisect more!

Re: Bump the minimal version required to compile DMD to 2.076.1

[Joakim via Digitalmars-d]

On Friday, 12 January 2018 at 17:17:02 UTC, Seb wrote:

On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:

On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

Motivation
--

1) It's required for Walter's work on using -betterC for the 
backend conversion:


https://github.com/dlang/dmd/pull/6907


Not really, he just wants to dogfood betterC on the dmd 
backend when it's ported to D.


Yeah and that requires:

-mv switch
- removal of the generated assert helper functions

Both are features which aren't present in 2.068
The entire reason why the PR wasn't merged yet is because the 
auto-tester hasn't been updated (and no one hacked these 
features into the gdc Perl wrapper).


Let me rephrase what I wrote, as you did mention originally that 
bumping the compiler version was only required for betterC.  
Walter wants to translate the dmd backend to D, but it doesn't 
have to be betterC, as others in that PR thread point out.


On Friday, 12 January 2018 at 17:17:25 UTC, Jonathan Marler wrote:

On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:

On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

2) We start to run into random failures lately, e.g.

https://github.com/braddr/d-tester/issues/63
https://github.com/dlang/dmd/pull/7569#issuecomment-356992048


Seem like issues with 32-bit OS X instead.



It's actually a bug in dmd 2.068.2.  I was able to reproduce 
the segfault on my macbook.


Meaning what, it's reproducible with the 64-bit OS X tests also?

If I went to the next version of dmd, namely, 2.069.0 then the 
issue went away.  I was also able to get a stack trace:

---
Obj::term(char const*) + 2285
obj_end(Library*, File*) + 37
tryMain(unsigned long, char const**) + 12066
_start + 203
start + 33
---

The `+  ` is referring to the code offset in bytes from 
the beginning of the function, so the actual line of code where 
the invalid access occurs is somewhere inside Obj::term.  
Unfortunately, that function is quite large (over 700 lines).


If we want to continue supporting dmd 2.068.2, I would 
recommend patching this bug.  I don't know how long we have 
been using this specific version of dmd 2.068.2 on the 
autotester, does anyone know?


For now, I think you have no choice but to simply work around 
whatever that bug is.  We should drop support for 32-bit OS X 
sometime soon, and if that fixes the issue, you have no problem.

[Issue 18232] Union methods fail to initialize local variables to .init

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from hst...@quickfur.ath.cx ---
Minimized code:
--
union U {
int method() {
int x;
return x;
}
}
--

The disassembly shows that x is never initialized to 0, and a garbage value is
returned.

--

[Issue 18232] Union methods fail to initialize local variables to .init

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

Summary|string variable in toString |Union methods fail to
   |method of Union: invalid|initialize local variables
   |code (crash/segfault)   |to .init

--

Re: Release D 2.078.0

[Rainer Schuetze via Digitalmars-d-announce]

On 12.01.2018 12:42, Andre Pany wrote:

On Monday, 8 January 2018 at 22:41:31 UTC, Rainer Schuetze wrote:


Unfortunately the corresponding installer PRs didn't make it into the 
release, so you still have to remove most options of section 
Environment64 from sc.ini yourself. This should be enough


[Environment64]
LIB=%@P%\..\lib64
DFLAGS=%DFLAGS% -L/OPT:NOICF

When using the 7z dmd file, the most harmful setting is LINKCMD, that 
doesn't work for VS2017.


Any chance to get the corresponding PR with 2.078.1 point release?
I also tried it with the Build Tools for Visual Studio 2017 and it 
neither works.


I think the link path could be easily retrieved.
You could check whether the first element of %PATH% contains a file 
link.exe

and use this one if the file path also starts with %VCINSTALLDIR%.

Example:
Path=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\BuildTools\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64;...


VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\BuildTools\VC\


Kind regards
André



IMO removing the detected entries from sc.ini should be good enough: 
https://github.com/dlang/dmd/pull/7686. The linker path is built from 
the other VC variables. I've based it on stable in the hope it will make 
it into 2.078.1.


The more involved changes I mentioned are 
https://github.com/dlang/installer/pull/281 and 
https://github.com/dlang/dmd/pull/7500.

[Issue 18232] string variable in toString method of Union: invalid code (crash/segfault)

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from hst...@quickfur.ath.cx ---
Note also, the name `toString` is irrelevant to this bug.  The same codegen bug
appears if you rename the method to something else, like 'member'.

Furthermore, the local variable doesn't have to be a string; any local variable
without an initializer would also exhibit the same missing initialization, it
doesn't initialize the local to .init, as it should.

--

[Issue 18233] building with -m64 doesn't work with sc.ini from the zip distribution and VS2017

[d-bugmail--- via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Rainer Schuetze  ---
https://github.com/dlang/dmd/pull/7686

--

[Issue 18232] string variable in toString method of Union: invalid code (crash/segfault)

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #1 from hst...@quickfur.ath.cx ---
The crash is caused by wrong codegen for the toString() method. Here's a
comparison of a toString() method for a struct vs. for a union:

Struct code:

struct Jack
{
float f;
int i;
string toString()
{
string s;
return s;
}
}


Generated assembly for Jack.toString:

   447dc:   55  push   %rbp
   447dd:   48 8b ecmov%rsp,%rbp
   447e0:   31 c0   xor%eax,%eax
   447e2:   31 d2   xor%edx,%edx
   447e4:   5d  pop%rbp
   447e5:   c3  retq   


As can be easily seen, this basically initializes the string s to have
.ptr=null, .length=0, returned by value in %eax and %edx. This is the correct
behaviour.

Union code (basically the same as the struct code, just change 'struct' to
'union'):

union Jack
{
float f;
int i;
string toString()
{
string s;
return s;
}
}


Generated assembly for Jack.toString:

   4471c:   55  push   %rbp
   4471d:   48 8b ecmov%rsp,%rbp
   44720:   48 83 ec 10 sub$0x10,%rsp
   44724:   48 8b 55 f8 mov-0x8(%rbp),%rdx
   44728:   48 8b 45 f0 mov-0x10(%rbp),%rax
   4472c:   c9  leaveq 
   4472d:   c3  retq   


Here, the 'sub' line appears to be allocating space on the stack for a local
variable, presumeably s.  But then it fails to initialize s before loading it
into the return registers %rdx and %rax.  I'm assuming that this is probably
why the allocation of the local variable never got elided, as it was in the
struct case -- the optimizer doesn't see the missing initialization of s, so it
cannot elide the loads from the stack.

So it looks like the bug is caused by failure to initialize s when generating
code for a union vs. a struct.  Why, though, is a mystery to me, since toString
never actually references `this`, so in theory whether `this` is a struct or
union shouldn't matter.

--

[Issue 18233] New: building with -m64 doesn't work with sc.ini from the zip distribution and VS2017

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18233
   Summary: building with -m64 doesn't work with sc.ini from the
zip distribution and VS2017
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: r.sagita...@gmx.de

vs-auto-detection does not work with the Visual Studio 2017 Community version:

dmd app.d -m64

Error: can't run 'C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\\bin\link.exe', check PATH

--

Re: Possible dmd 2.078 regression ?

[Stefan Koch via Digitalmars-d-learn]

On Friday, 12 January 2018 at 14:13:22 UTC, Basile B. wrote:
I have a simple program that only compiles if the dependency is 
not pre-compiled as a static library. It worked fine before. 
Please test this


---
if [ ! -d "iz" ]; then
git clone https://www.github.com/BBasile/iz.git
fi

cd iz/scripts
sh compile.sh
cd ../

#fails to link
dmd samples/dictionnary_suffixarray.d lib/iz.a -Iimport > 
ddemangle



#on the other hand, this works...
dub samples/dictionnary_suffixarray.d <<< "q"

#or even this...
dmd samples/dictionnary_suffixarray.d import/iz/strings.d 
import/iz/memory.d -Iimport

---

and tell me what do you think: regression or not ?


I guess a mangle problem ?

[Issue 18193] module config is in file 'rt/config.d' which cannot be read

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/10afa6944bb3ac479cbcabc5499a86136907b95f
Fix issue 18193 - module config is in file 'rt/config.d' which cannot be read
(edit)

src/rt isn't shipped with druntime's imports, so it can't be
imported directly from core.runtime. This PR fixes importing rt.config
from a public druntime module by replacing it with an extern
definition.

To reproduce the bug create a file that imports 'core.runtime' and
compile it with:
dmd -unittest -deps filename.d

The error is:
/usr/include/dmd/druntime/import/core/runtime.d(653): Error: module
config is in file 'rt/config.d' which cannot be read

https://github.com/dlang/druntime/commit/105d4a5ca279316665b3b796bf5ca7d249595caf
Add test to the bug 18193

--

Re: Bump the minimal version required to compile DMD to 2.076.1

[Seb via Digitalmars-d]

On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:

On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

Motivation
--

1) It's required for Walter's work on using -betterC for the 
backend conversion:


https://github.com/dlang/dmd/pull/6907


Not really, he just wants to dogfood betterC on the dmd backend 
when it's ported to D.


Yeah and that requires:

-mv switch
- removal of the generated assert helper functions

Both are features which aren't present in 2.068
The entire reason why the PR wasn't merged yet is because the 
auto-tester hasn't been updated (and no one hacked these features 
into the gdc Perl wrapper).

Re: Bump the minimal version required to compile DMD to 2.076.1

[Jonathan Marler via Digitalmars-d]

On Friday, 12 January 2018 at 16:50:21 UTC, Joakim wrote:

On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

2) We start to run into random failures lately, e.g.

https://github.com/braddr/d-tester/issues/63
https://github.com/dlang/dmd/pull/7569#issuecomment-356992048


Seem like issues with 32-bit OS X instead.



It's actually a bug in dmd 2.068.2.  I was able to reproduce the 
segfault on my macbook.  If I went to the next version of dmd, 
namely, 2.069.0 then the issue went away.  I was also able to get 
a stack trace:

---
Obj::term(char const*) + 2285
obj_end(Library*, File*) + 37
tryMain(unsigned long, char const**) + 12066
_start + 203
start + 33
---

The `+  ` is referring to the code offset in bytes from the 
beginning of the function, so the actual line of code where the 
invalid access occurs is somewhere inside Obj::term.  
Unfortunately, that function is quite large (over 700 lines).


If we want to continue supporting dmd 2.068.2, I would recommend 
patching this bug.  I don't know how long we have been using this 
specific version of dmd 2.068.2 on the autotester, does anyone 
know?

Re: invalid or corrupt file: duplicate COMDAT / Previous Definition Different

[Anonymouse via Digitalmars-d-learn]

On Wednesday, 10 January 2018 at 20:53:24 UTC, Anonymouse wrote:
None of the (version specifiers in the) build configurations I 
have touch upon the part of the fairly innocent code mentioned 
in the error message, if I'm reading it right. 
(https://github.com/zorael/kameloso/blob/c00ca4489e39348bd4b1678c95c1b12636df307c/source/kameloso/plugins/common.d#L424)


struct Foo
{
this(Regex!char) { /* ... */ }
this(StaticRegex!char) { /* ... */ }
}

It seems like the problem there is that StaticRegex is only an 
alias to Regex, so I'm overloading it twice. It rhymes well with 
the linked bug.


/++
A $(D StaticRegex) is $(D Regex) object that contains D code 
specially

generated at compile-time to speed up matching.
No longer used, kept as alias to Regex for backwards 
compatibility.

+/
public alias StaticRegex = Regex;  // <--

Reducing it to just that doesn't reproduce the error message 
though. As long as Regex!char can house both ctRegex!"foo" and 
"foo".regex it works for me.

Re: Bump the minimal version required to compile DMD to 2.076.1

[Joakim via Digitalmars-d]

On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

Motivation
--

1) It's required for Walter's work on using -betterC for the 
backend conversion:


https://github.com/dlang/dmd/pull/6907


Not really, he just wants to dogfood betterC on the dmd backend 
when it's ported to D.



2) We start to run into random failures lately, e.g.

https://github.com/braddr/d-tester/issues/63
https://github.com/dlang/dmd/pull/7569#issuecomment-356992048


Seem like issues with 32-bit OS X instead.


3) There's also WIP to move dmd-cxx to 2.076.1:

https://github.com/dlang/dmd/pull/7595


No idea when that will be ready.

So if we have to bump the minimal dmd version required to build 
DMD anyways for (1), let's be clear about it and state it.


Anyone objecting?


This is going to require changes to ldc/gdc CI, as they actually 
maintain and test against that last C++ version of the common D 
frontend.  It will also affect ports to new platforms, as it 
presents another hoop to jump through.


I see little reason to jump now.  If it's done, it needs to be 
clearly documented.

Re: Can you introspect predicate arity and if it's an equality predicate?

[Seb via Digitalmars-d-learn]

On Friday, 12 January 2018 at 13:04:30 UTC, aliak wrote:

On Friday, 12 January 2018 at 10:55:53 UTC, Seb wrote:

On Friday, 12 January 2018 at 00:16:07 UTC, aliak wrote:

Hi, so basically is there a way to:

void func(alias pred = null, Range)(Range range) {
  // 1) check if pred(ElementType!Range.init, 
ElementType!Range.init) is equality

  // 2) check if isUnary!pred
  // 3) check if isBinary!pred
}

[...]


It isn't possible yet, but will be very soon: 
https://github.com/dlang/dmd/pull/7484


Thats to compare whether lambdaA == lambdaB right? Not if 
lambda(a, b) == lambda(b, a) == true <- i guess this is not 
possible anyway without knowing the entire set of inputs)


Yes. The implementation is actually pretty straight-forward:
Serialize to AST and compare.

Re: Bump the minimal version required to compile DMD to 2.076.1

[Seb via Digitalmars-d]

On Friday, 12 January 2018 at 16:21:25 UTC, Stefan Koch wrote:

On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

Motivation
--

1) It's required for Walter's work on using -betterC for the 
backend conversion:


https://github.com/dlang/dmd/pull/6907

2) We start to run into random failures lately, e.g.

https://github.com/braddr/d-tester/issues/63
https://github.com/dlang/dmd/pull/7569#issuecomment-356992048

3) There's also WIP to move dmd-cxx to 2.076.1:

https://github.com/dlang/dmd/pull/7595

So if we have to bump the minimal dmd version required to 
build DMD anyways for (1), let's be clear about it and state 
it.


Anyone objecting?


Yes! we cannot keep bumping the version of the compiler, 
personally I find 2.072 rather steep!

really we should be able to build with 2.068.


FYI: There has never been an official bump to 2.072
You can still build dmd with 2.068 - that's the version 
auto-tester uses.


However, I think you didn't understand my question.
We _will_ bump the minimal required version to compile DMD soon 
(see [1]).
That being said, what's the point in wasting hours of hours 
working around the bugs in 2.068.2 when we will do the bump one 
month later anyways?


[1] https://github.com/dlang/dmd/pull/6907

Re: Bump the minimal version required to compile DMD to 2.076.1

[Stefan Koch via Digitalmars-d]

On Friday, 12 January 2018 at 16:13:39 UTC, Seb wrote:

Motivation
--

1) It's required for Walter's work on using -betterC for the 
backend conversion:


https://github.com/dlang/dmd/pull/6907

2) We start to run into random failures lately, e.g.

https://github.com/braddr/d-tester/issues/63
https://github.com/dlang/dmd/pull/7569#issuecomment-356992048

3) There's also WIP to move dmd-cxx to 2.076.1:

https://github.com/dlang/dmd/pull/7595

So if we have to bump the minimal dmd version required to build 
DMD anyways for (1), let's be clear about it and state it.


Anyone objecting?


Yes! we cannot keep bumping the version of the compiler, 
personally I find 2.072 rather steep!

really we should be able to build with 2.068.

Bump the minimal version required to compile DMD to 2.076.1

[Seb via Digitalmars-d]

Motivation
--

1) It's required for Walter's work on using -betterC for the 
backend conversion:


https://github.com/dlang/dmd/pull/6907

2) We start to run into random failures lately, e.g.

https://github.com/braddr/d-tester/issues/63
https://github.com/dlang/dmd/pull/7569#issuecomment-356992048

3) There's also WIP to move dmd-cxx to 2.076.1:

https://github.com/dlang/dmd/pull/7595

So if we have to bump the minimal dmd version required to build 
DMD anyways for (1), let's be clear about it and state it.


Anyone objecting?

Re: Proposal for a standard Decimal type in alpha

[Jack Stouffer via Digitalmars-d-announce]

On Thursday, 21 December 2017 at 13:59:28 UTC, Jack Stouffer 
wrote:

...


While I believe my library has certain API advantages, I'm really 
not interested in duplicating a bunch of work when rumbu's 
version is pretty much complete, so I'm dropping this.

Re: Exposing pred from SortedRange and changes to algorithms that assumeSorted

[aliak via Digitalmars-d]

On Friday, 12 January 2018 at 10:53:04 UTC, Seb wrote:
canFind uses find internally, which already has a shortcut for 
SortedRange.
I don't like contains either, but the idea was to have a 
separate method with different performance guarantees as 
canFind is typically O(n).

Anyways I have tried to deprecate it:

https://github.com/dlang/phobos/pull/5651

Maybe you have better arguments?


Ah I see. Nah I don't have better arguments :p Think yours were 
good enough. If I understood correctly the argument to keeping 
contains is because it means "here is a function that searches 
logarithmically"? Is that correct? While I do agree "contains" 
indicates some kind of quick(er) check functionality over an 
algorithm with the word find in it, I can't quite elaborate why 
that's the case, but I think it only applies when there's 
context, and not "generically", and because I've used hash maps a 
lot. The problem is that it's not enforceable and hence cannot be 
depended upon, so I don't think it's a good argument in the 
current scenario. A better convention would be to have the 
indiction of complexity explicitly in the name, i.e. name it 
"locagirhtmicFind" or "binarySearch", etc, and have that on a 
SortedRange. But I assume that ship has sailed...


Tried looking for other languages which differentiate between 
find/search/exists/contains/etc based on complexity and I don't 
think there are any? Are there?


Swift does "contains"
C++ does "find"
Rust does "contains" (and find??)
Julia does "searchsorted"

None of them make any complexity promises, the only one I can 
look at and would be surprised if it didn't do a faster search is 
the Julia one.






Now to your main question:

Exposing doesn't help much, because you can't compare them, but 
there is WIP on lambda comparisons:


https://github.com/dlang/dmd/pull/7484

With it, the default lamdas can be compared for equality and 
what you want to do can/will be done.


Aha ok so basically you're saying that even if pred was public 
then I can't make sure R1.pred == R2.pred so it does't make it a 
100% guarantee right? But regardless of that wouldn't making pred 
public be needed to do the above anyway? I.e. if an algorithm 
wants to make sure the SortedRange preds were the same it still 
needs to access them right? And if the algorithms are single 
ranged, then you don't need to compare any lambdas then - i.e. 
canFind just uses whatever pred was in SortedRange.


Or did I maybe misunderstand?

Cheers

Possible dmd 2.078 regression ?

[Basile B. via Digitalmars-d-learn]

I have a simple program that only compiles if the dependency is 
not pre-compiled as a static library. It worked fine before. 
Please test this


---
if [ ! -d "iz" ]; then
git clone https://www.github.com/BBasile/iz.git
fi

cd iz/scripts
sh compile.sh
cd ../

#fails to link
dmd samples/dictionnary_suffixarray.d lib/iz.a -Iimport > 
ddemangle



#on the other hand, this works...
dub samples/dictionnary_suffixarray.d <<< "q"

#or even this...
dmd samples/dictionnary_suffixarray.d import/iz/strings.d 
import/iz/memory.d -Iimport

---

and tell me what do you think: regression or not ?

Re: Another take on decimal data types

[Joakim via Digitalmars-d-announce]

On Thursday, 11 January 2018 at 22:07:42 UTC, H. S. Teoh wrote:
On Thu, Jan 11, 2018 at 04:38:57PM -0500, Steven Schveighoffer 
via Digitalmars-d-announce wrote:

On 1/11/18 4:12 PM, kdevel wrote:
> On Thursday, 11 January 2018 at 20:40:01 UTC, Dmitry 
> Olshansky wrote:

> > What did you expect?
> 
> To be honest: A compile time error. Modern C compilers can 
> check such format strings. Example: GCC 6:


But dmd isn't a C compiler, nor does it have to worry about 
the problems C has (namely, untyped varargs). To dmd, printf 
is just another function, there's nothing special about it.

[...]

Yeah, checking C-style printf formats isn't dmd's problem.

The Phobos equivalent of printf, however, *does* support 
compile-time format checking in the latest version:


writefln!"%s %d %d"("abc", 1); // "Orphan format specifier: %d"
	writefln!"%s %d"("abc", 1, 2); // "Orphan format arguments: 
args[2..3]"
	writefln!"%s %d"(1, "abc");// "Incorrect format specifier 
for range: %d"
	writefln!"%f"(1);  // "incompatible format 
character for integral argument: %f"


Best of all, this is all done via CTFE in the library code, no 
hard-coding in the compiler necessary.  You can implement your 
own compile-time checker for your own DSLs in the same way, 
without needing to hack the compiler.


Interesting, guess this was added last April with dmd 2.074?

https://dlang.org/changelog/2.074.0.html#std-format-formattedWrite

You or someone should write up a blog post about this, with both 
this example and expanding on how D enables this kind of 
functionality in general.

[Issue 17462] Order of base interfaces affects compiler behavior

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #1 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/7684

--

[Issue 17462] Order of base interfaces affects compiler behavior

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

   Severity|enhancement |normal

--

Re: Another take on decimal data types

[kdevel via Digitalmars-d-announce]

On Monday, 8 January 2018 at 22:16:25 UTC, rumbu wrote:
- all std.math functions implemented (even logarithms and 
trigonometry);


nosine.d
```
import std.stdio;
// import std.math;
import decimal;

void nosine (T) ()
{
   T d = T(1.1);
   writeln (sin(d));
}

void main ()
{
   nosine!decimal32;
   nosine!decimal64;
   nosine!decimal128;
}
```

$ dmd nosine.d decimal.git/libdecimal.a
decimal/package.d(10505): Error: undefined identifier 
decimalCapAngle
decimal/package.d(5364): Error: template instance 
decimal.decimalSin!(Decimal!32) error instantiating

nosine.d(8):instantiated from here: sin!(Decimal!32)
nosine.d(13):instantiated from here: nosine!(Decimal!32)
decimal/package.d(10505): Error: undefined identifier 
decimalCapAngle
decimal/package.d(5364): Error: template instance 
decimal.decimalSin!(Decimal!64) error instantiating

nosine.d(8):instantiated from here: sin!(Decimal!64)
nosine.d(14):instantiated from here: nosine!(Decimal!64)
decimal/package.d(10505): Error: undefined identifier 
decimalCapAngle
decimal/package.d(5364): Error: template instance 
decimal.decimalSin!(Decimal!128) error instantiating

nosine.d(8):instantiated from here: sin!(Decimal!128)
nosine.d(15):instantiated from here: nosine!(Decimal!128)

Re: Floating Point Literals: float (f) and real (L) suffix issue

[Simen Kjærås via Digitalmars-d-learn]

On Friday, 12 January 2018 at 12:57:37 UTC, kdevel wrote:

On Friday, 12 January 2018 at 12:45:59 UTC, kdevel wrote:

suffix.d
```
void main ()
{
   real r = 1.L;
   float f = 1.f;
}
```

$ dmd suffix.d
suffix.d(3): Error: no property 'L' for type 'int'
suffix.d(4): Error: no property 'f' for type 'int'

According to the grammar in dmd2/html/d/spec/lex.html both are 
valid FloatLiterals. Any comments?


Just found this on the same page

| If a floating literal has a . and a type suffix, at least one 
digit must be in-between:

|
| 1f; // OK
| 1.f; // forbidden
| 1.; // OK, double

Is there a rational for this restriction?


int foo(int n) { return n * 2; }

assert(2.foo == 4);

Now simply replace foo with f or L. I believe this ambiguity is 
the whole reason.


--
  Simen

Re: Can you introspect predicate arity and if it's an equality predicate?

[aliak via Digitalmars-d-learn]

On Friday, 12 January 2018 at 10:55:53 UTC, Seb wrote:

On Friday, 12 January 2018 at 00:16:07 UTC, aliak wrote:

Hi, so basically is there a way to:

void func(alias pred = null, Range)(Range range) {
  // 1) check if pred(ElementType!Range.init, 
ElementType!Range.init) is equality

  // 2) check if isUnary!pred
  // 3) check if isBinary!pred
}

[...]


It isn't possible yet, but will be very soon: 
https://github.com/dlang/dmd/pull/7484


Thats to compare whether lambdaA == lambdaB right? Not if 
lambda(a, b) == lambda(b, a) == true <- i guess this is not 
possible anyway without knowing the entire set of inputs)

Re: Can you introspect predicate arity and if it's an equality predicate?

[aliak via Digitalmars-d-learn]

On Friday, 12 January 2018 at 08:18:02 UTC, Simen Kjærås wrote:

On Friday, 12 January 2018 at 00:16:07 UTC, aliak wrote:

Hi, so basically is there a way to:

void func(alias pred = null, Range)(Range range) {
  // 1) check if pred(ElementType!Range.init, 
ElementType!Range.init) is equality

  // 2) check if isUnary!pred
  // 3) check if isBinary!pred
}


For 2 and 3, there's std.traits.arity. However, as you point 
out, it has some problems with templated functions. This 
template will handle those cases in conjunction with 
std.traits.arity:


import std.traits : arity, isCallable;

template arity(alias Fn, Args...)
if (is(typeof(Fn!Args)) && isCallable!(typeof(Fn!Args)))
{
enum arity = .arity!(Fn!Args);
}

unittest {
assert(arity!(() => 1) == 0);
assert(arity!(a => a, int) == 1);
assert(arity!((a,b) => a, int, float) == 2);

void test(T)(T,T,T) {}
assert(arity!(test, int) == 3);
}


Thank you! That leading period too ... noice!

Checking if a function is the equality function is much harder. 
Consider this function:


bool compare(int a, int b) {
if (a == 2 && b = 3) return true;
return a == b;
}

Clearly this is not an equality function, but for the vast 
majority of inputs, it behaves exactly the same.


There are other examples that make this hard. It's perfectly 
possible to overload opEquals and have it ignore some fields, 
or even access a database on the other side of the atlantic 
ocean. In these cases, evaluating the equality of two objects 
is not testable at compile time, and you simply cannot know.


In your examples you use string functions ("a == b", e.g.). 
These can of course be compared (you might want to do some 
processing, as "a==b" should give the same result as "b
==  a"). There's cases here where you can't be sure, of 
course.


All in all, I believe you're trying to solve the wrong problem, 
but I might be wrong. Care to give a bit more information so I 
get a better idea of why you want to do this?


Nah, your gut was spot on :D What I was trying to do didn't 
really make any sense. I'm learning D by playing with generic 
algorithms (trying to recreate a javascript functional library 
called lodash), and was trying to be "too smart". My thought 
process was I want a function that finds the intersection between 
two arrays, and I want to allow the user to pass in an equality 
predicate as well, in which case the intersection will return 
elements that return true for the equality predicate, and the 
algorithm would then not care about sortedness and do a naive 
O(n*m) approach (ie: for each element in a check if it exists in 
b and return it as one of the intersection elements).


If the predicate was not an equality predicate than it'd be 
assumed to be the predicate that was used to sort the array (in 
the case that they're sorted) and then a faster O(n) algorithm 
can be used.


The unary/binary stuff was to determine if the predicate was a 
unary predicate, in which case a transformation is applied to 
each elements and you have an algorithm that returns the 
transformed intersected elements.


Realized that the binary equality predicate is just a special 
case of the unary transformation predicate so I actually don't 
need to (and obviously as you point out can't reliable) test that 
a binary predicate is an equality one.


Cheers, and thanks for your input!

Re: Floating Point Literals: float (f) and real (L) suffix issue

[kdevel via Digitalmars-d-learn]

On Friday, 12 January 2018 at 12:45:59 UTC, kdevel wrote:

suffix.d
```
void main ()
{
   real r = 1.L;
   float f = 1.f;
}
```

$ dmd suffix.d
suffix.d(3): Error: no property 'L' for type 'int'
suffix.d(4): Error: no property 'f' for type 'int'

According to the grammar in dmd2/html/d/spec/lex.html both are 
valid FloatLiterals. Any comments?


Just found this on the same page

| If a floating literal has a . and a type suffix, at least one 
digit must be in-between:

|
| 1f; // OK
| 1.f; // forbidden
| 1.; // OK, double

Is there a rational for this restriction?

Re: Another take on decimal data types

[kdevel via Digitalmars-d-announce]

On Friday, 12 January 2018 at 05:18:15 UTC, rumbu wrote:

On Thursday, 11 January 2018 at 23:57:29 UTC, kdevel wrote:
What about the failed comparison:





You are right in fact, there is also a failed comparison. Now 
corrected.


Works. Thanks for the changes!

Floating Point Literals: float (f) and real (L) suffix issue

[kdevel via Digitalmars-d-learn]

suffix.d
```
void main ()
{
   real r = 1.L;
   float f = 1.f;
}
```

$ dmd suffix.d
suffix.d(3): Error: no property 'L' for type 'int'
suffix.d(4): Error: no property 'f' for type 'int'

According to the grammar in dmd2/html/d/spec/lex.html both are 
valid FloatLiterals. Any comments?

[Issue 18232] string variable in toString method of Union: invalid code (crash/segfault)

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ag0ae...@gmail.com

--

Re: SegFault with HibernateD

[Mike Parker via Digitalmars-d-learn]

On Friday, 12 January 2018 at 08:55:13 UTC, Rene Zwanenburg wrote:


It looks to me like the program is being run through dub, and 
dub is just reporting the program's exit code.




I see now. I glossed right over that execution output. On 
Windows, I don't recall ever seeing a dub exception from dub from 
a segfault. Just checked by accessing a null pointer and there's 
nothing thrown from dub. Is that a Linux thing?

Re: Is old style compile-time foreach redundant?

[Seb via Digitalmars-d-learn]

On Sunday, 7 January 2018 at 02:17:02 UTC, Stefan Koch wrote:

On Sunday, 7 January 2018 at 01:08:44 UTC, H. S. Teoh wrote:
On Sun, Jan 07, 2018 at 12:55:27AM +, Stefan Koch via 
Digitalmars-d-learn wrote:
On Saturday, 6 January 2018 at 23:25:58 UTC, Ali Çehreli 
wrote:
> Is 'static foreach' sufficient for all needs or is there 
> any value for regular foreach over compile-time sequences?

[...]

No it's not.
When you can use the old style do so. Since it puts less 
stress on the

compiler in the general case.


Really? Based on a recent post by Jonathan Davis, the new 
static foreach actually runs faster in certain use cases.



T


That might be true.
If you are hitting some constant factor, however the big-o for 
static foreach is worse then for tuple foreach.



FWIW there isn't any measurable performance penalty / difference.
We moved to use static foreach on Phobos recently: 
https://github.com/dlang/phobos/pull/5989

Re: Release D 2.078.0

[Andre Pany via Digitalmars-d-announce]

On Monday, 8 January 2018 at 22:41:31 UTC, Rainer Schuetze wrote:


Unfortunately the corresponding installer PRs didn't make it 
into the release, so you still have to remove most options of 
section Environment64 from sc.ini yourself. This should be 
enough


[Environment64]
LIB=%@P%\..\lib64
DFLAGS=%DFLAGS% -L/OPT:NOICF

When using the 7z dmd file, the most harmful setting is 
LINKCMD, that doesn't work for VS2017.


Any chance to get the corresponding PR with 2.078.1 point release?
I also tried it with the Build Tools for Visual Studio 2017 and 
it neither works.


I think the link path could be easily retrieved.
You could check whether the first element of %PATH% contains a 
file link.exe

and use this one if the file path also starts with %VCINSTALLDIR%.

Example:
Path=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\BuildTools\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64;...


VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual 
Studio\2017\BuildTools\VC\


Kind regards
André

Re: Can you introspect predicate arity and if it's an equality predicate?

[cuxu via Digitalmars-d-learn]

мinterest Ask. our service 
https://reviews-up.com/android-app-reviews/ with the help of 
specialists will help you in promoting your application and 
solving this issue

Re: Release D 2.078.0

[Andre Pany via Digitalmars-d-announce]

On Friday, 12 January 2018 at 10:13:13 UTC, Leandro Lucarella 
wrote:


From what I saw in the code, I think what it does is just 
override where the code was actually placed when you compiled, 
so tools to visualize the coverage can show you the source code.


* https://dlang.org/code_coverage.html#switchsrcpath
* 
https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L83-L84
* 
https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L211


BTW, to just report coverage of certain files you can just 
compile with `-cov` those files. I guess that should work 
(maybe? :).


Thanks for the clarification.

Kind regards
André

Re: union/toString: crash/segfault: What's happening here?

[kdevel via Digitalmars-d-learn]

Thanks for the quick answer!

On Friday, 12 January 2018 at 02:16:39 UTC, Adam D. Ruppe wrote:

On Friday, 12 January 2018 at 00:54:03 UTC, kdevel wrote:

$ dmd crash.d
$ ./crash


Nicholas Wilson is right that you can use = "" to work around 
it, but with strings, null is supposed to behave the same way.


And this gives different (each wrong) behavior on -m32 vs -m64, 
which leads me to believe you actually found a compiler bug.


dmd -O crash even produces a binary which segfaults on my machine.

Calling u.toString directly also leads to random spam, which 
means it isn't even the library.


I'd file this as a compiler codegen bug.


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

[Issue 18232] New: string variable in toString method of Union: invalid code (crash/segfault)

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18232
   Summary: string variable in toString method of Union: invalid
code (crash/segfault)
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: kde...@vogtner.de

crash.d
---
import std.stdio;

union U {
   float f;
   int i;
   string toString ()
   {
  string s;
  return s;
   }
}

void main ()
{
   U u;
   writeln (u);
}
---

$ dmd crash
$ dmd
std.exception.ErrnoException@/.../dmd2/linux/bin64/../../src/phobos/std/stdio.d(2776):
 (Bad address)

??:? @safe int std.exception.errnoEnforce!(int,
"/.../dmd2/linux/bin64/../../src/phobos/std/stdio.d", 2776uL).errnoEnforce(int,
lazy immutable(char)[]) [0x43f20a]
??:? @safe void
std.stdio.File.LockingTextWriter.put!(immutable(char)[]).put(immutable(char)[])
[0x4422a7]
??:? @safe void std.range.primitives.doPut!(std.stdio.File.LockingTextWriter,
immutable(char)[]).doPut(ref std.stdio.File.LockingTextWriter, ref
immutable(char)[]) [0x44224b]
??:? @safe void std.range.primitives.put!(std.stdio.File.LockingTextWriter,
immutable(char)[]).put(ref std.stdio.File.LockingTextWriter, immutable(char)[])
[0x44222b]
??:? void std.format.formatObject!(std.stdio.File.LockingTextWriter, crash.U,
char).formatObject(ref std.stdio.File.LockingTextWriter, ref crash.U, ref
const(std.format.FormatSpec!(char).FormatSpec)) [0x44220a]
??:? void std.format.formatValue!(std.stdio.File.LockingTextWriter, crash.U,
char).formatValue(ref std.stdio.File.LockingTextWriter, ref crash.U, ref
const(std.format.FormatSpec!(char).FormatSpec)) [0x44219d]
??:? uint std.format.formattedWrite!(std.stdio.File.LockingTextWriter, char,
crash.U).formattedWrite(ref std.stdio.File.LockingTextWriter, const(char[]),
crash.U) [0x43e703]
??:? void std.stdio.File.write!(crash.U, char).write(crash.U, char) [0x43e3f5]
??:? void std.stdio.writeln!(crash.U).writeln(crash.U) [0x43e389]
??:? _Dmain [0x43e344]

http://forum.dlang.org/thread/wrasraxuptrqwakrs...@forum.dlang.org

--

[Issue 18231] New: multiwayMerge could be optimized

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18231
   Summary: multiwayMerge could be optimized
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

See: https://forum.dlang.org/post/mpiabfjzoymdyfrej...@forum.dlang.org

See also:
-
https://github.com/libmir/mir-algorithm/blob/master/source/mir/algorithm/setops.d

--

[Issue 18230] multiwayUnion sets wrong pred lambdas

[d-bugmail--- via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

 OS|Linux   |All

--

[Issue 18230] New: multiwayUnion sets wrong pred lambdas

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18230
   Summary: multiwayUnion sets wrong pred lambdas
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

See: https://forum.dlang.org/post/mpiabfjzoymdyfrej...@forum.dlang.org

Introduced in https://github.com/dlang/phobos/pull/5620

See also:
-
https://github.com/libmir/mir-algorithm/blob/master/source/mir/algorithm/setops.d

--

Re: Can you introspect predicate arity and if it's an equality predicate?

[Seb via Digitalmars-d-learn]

On Friday, 12 January 2018 at 00:16:07 UTC, aliak wrote:

Hi, so basically is there a way to:

void func(alias pred = null, Range)(Range range) {
  // 1) check if pred(ElementType!Range.init, 
ElementType!Range.init) is equality

  // 2) check if isUnary!pred
  // 3) check if isBinary!pred
}

[...]


It isn't possible yet, but will be very soon: 
https://github.com/dlang/dmd/pull/7484

Re: Exposing pred from SortedRange and changes to algorithms that assumeSorted

[Seb via Digitalmars-d]

On Friday, 12 January 2018 at 09:52:36 UTC, aliak wrote:
Would it be an acceptable enhancement to phobos to expose the 
predicate in SortedRange 
(https://dlang.org/library/std/range/sorted_range.html)?


The rationale behind it would be so that functions like 
setDifference 
(https://dlang.org/library/std/algorithm/setops/set_difference.html) or any function that requires a sorted range to "run" does not need to be provided the sorting predicate, ie:


setDifference
largestPartialIntersection
largestPartialIntersectionWeighted
multiwayUnion
setIntersection
setSymmetricDifference
setUnion
multiwayMerge

Where functions do required ranges to be sorted and a predicate 
passed in, this enhancement should reduce programmer errors 
(i.e. providing the wrong predicate to the algorithm that was 
used to sort the range that you want to operate on). The 
sortedrange knows how it was sorted, so there should be no need 
to duplicate that (unless there are maybe some valid reasons?).


It would also make for SortedRange itself to be made lighter 
(maybe not a good idea at this point but it can be done at 
least) by moving it's functionality in to algorithms that are 
already there. Eg, "SortedRange.contains" can be done by 
algorithm.canFind:


auto canFind(Range, T)(Range range, T element) if 
(isSortedRange!Range) {

  // do binary search for element
}


canFind uses find internally, which already has a shortcut for 
SortedRange.
I don't like contains either, but the idea was to have a separate 
method with different performance guarantees as canFind is 
typically O(n).

Anyways I have tried to deprecate it:

https://github.com/dlang/phobos/pull/5651

Maybe you have better arguments?



Now to your main question:

Exposing doesn't help much, because you can't compare them, but 
there is WIP on lambda comparisons:


https://github.com/dlang/dmd/pull/7484

With it, the default lamdas can be compared for equality and what 
you want to do can/will be done.


PS: Is this the correct place for posts like this? Apologies if 
not :s


Yeah I think it is.

Re: Release D 2.078.0

[Leandro Lucarella via Digitalmars-d-announce]

On Wednesday, 10 January 2018 at 05:35:05 UTC, Andre Pany wrote:
On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak 
wrote:

Glad to announce D 2.078.0.

This release comes with runtime detection of Visual Studio 
installation paths, an integral promotion transition for unary 
operations on byte and short sized integers, more -betterC 
features, and a couple of language and library tweaks.


Thanks to everyone involved in this  
https://dlang.org/contributors.html.


http://downloads.dlang.org/releases/2.x/2.078.0/ 
http://dlang.org/changelog/2.078.0.html


- -Martin


What is the purpose of the coverage option "srcpath"?

In my scenario I have a folder "dependencies" and a folder 
"source". I want to generate

code coverage only for the files in folder "source".

dmd -unittest -cov source/app.d dependencies/dep.d
app.exe --DRT-covopt="srcpath:./source dstpath:./cov"

By specifying "srcpath" there are 2 empty files created in 
folder cov:

source-app.lst
dependencies-dep.lst

I thought by specifying "srcpath" I limit the code coverage 
generation to the files located in folder source...


From what I saw in the code, I think what it does is just 
override where the code was actually placed when you compiled, so 
tools to visualize the coverage can show you the source code.


* https://dlang.org/code_coverage.html#switchsrcpath
* 
https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L83-L84
* 
https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L211


BTW, to just report coverage of certain files you can just 
compile with `-cov` those files. I guess that should work (maybe? 
:).

[Issue 18218] __traits(isDeprecated, creal) should return true

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/18accb5d8dc4edc4afcf45d72897f774e08f7431
Fix Issue 18218 - __traits(isDeprecated, creal) should return true

https://github.com/dlang/dmd/commit/537b214fd7cc1c1d0333dd2e6f077ef6e700630f
Merge pull request #7665 from wilzbach/fix-18218

Fix Issue 18218 - __traits(isDeprecated, creal) should return true
merged-on-behalf-of: Iain Buclaw 

--

[Issue 18218] __traits(isDeprecated, creal) should return true

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--