How to debug GC leak

[Andrew Benton via Digitalmars-d-learn]

I'm looking for a memory leak in my use of vibe.d JSON objects.  
The gc profiler built into the runtime only shows allocation 
count and allocation bytes, so I can make guesses around what 
might have leaked, but I can't be sure where or when, or exactly 
what leaked.


I'm sure someone else has run into this problem before.  How did 
you solve it?  I had hoped to also get a view into what was freed 
and when.

Re: Deploying D web servers

[Seb via Digitalmars-d]

On Sunday, 17 December 2017 at 17:06:32 UTC, cloutiy wrote:

Hi,

In the Javascript world there are services that provide a quick 
and simple means of deploying websites.


I've used things like surge.sh, netlify. I'm sure there are 
many others.


Is there something similar that exists for the D world?

Regards


If you use static linking, you can just rsync/scp your binary to 
your server.

No 5GB checkout of node_modules (with >1000 cat pics) required.

If you like an automatic pipeline, you could have a look at the 
heroku-buildpack-d [1].

Guide: https://tour.dlang.org/tour/en/vibed/deploy-on-heroku
In action:
- https://github.com/dlang-bots/dlang-bot 
(https://dlang-bot.herokuapp.com)

- https://github.com/dlang/dub-registry/pull/231


[1] https://github.com/MartinNowak/heroku-buildpack-d

Re: How to pack a struct to a ubyte[] in a more "The D way" style ?

[Binghoo Dang via Digitalmars-d-learn]

Thanks for your idea.

On Monday, 18 December 2017 at 05:08:24 UTC, Jonathan M Davis 
wrote:

 ubyte[] makeCMDPacket(RCPCmd cmd, in ubyte[] data)
 {
 this.preamble = RCPPKT_PRE;
 this.hdr.msgtype = RCPMSG_CMD;
 this.hdr.cmdcode =  cast (ubyte) cmd;
 this.hdr.len = 0x & data.length;


Why are you using & instead of simply casting to ushort? 
Casting would be more idiomatic. Or you can use to!ushort if 
you want to verify the size at runtime and have a ConvException 
thrown if the value is too large.




I'm using & because I'm using a C-Style. and the length needs to 
be packed into 2bytes, for casting, I don't know what will happen 
if data.length is greater. In C & C++, this kind of the cast will 
cause errors. I don't know what D will do for this.



```

It's basically a C-style code, and it works perfect, But I 
know that this is not a "D-way", So, any suggestions?


I'd suggest that you check out std.bitmanip if you haven't.

https://dlang.org/phobos/std_bitmanip.html

append, peek, read, and write in particular are useful if 
you're putting various integral values into an array of ubyte[] 
or reading them from it. Glancing over what you have, I'm 
pretty sure that all of the bitshifts and bitwise &'s and can 
be removed by using append or write to write the data to the 
array and peek or read to read from it.


Also, as far as D style goes, variables and enum values are 
usually given camelCase names, whereas you've named your enum 
values in all uppercase and your variables names in all 
lowercase, and you've underscores in the middle of names. But 
of course, you can do what you want on that. It's just that if 
you make any libraries public (e.g. on code.dlang.org), it's 
better to follow the D naming guidelines for anything in the 
public API:


https://dlang.org/dstyle.html

- Jonathan M Davis


Yeah, thanks for the suggestion, I will check bit manipulation 
more in detail. I just heard of that, but I just did a 
misunderstanding that I think that is for packing and unpacking 
of bits.

Re: How to pack a struct to a ubyte[] in a more "The D way" style ?

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, December 18, 2017 03:00:47 Binghoo Dang via Digitalmars-d-learn 
wrote:
> hi,
>
> I'm a dlang newbie, and I recently made a program that interacts
> with an RFID Reader, it's basically a Serial-Port communication
> model. And after 2 days, I finally got a working code like these:
>
> ```
>  enum RCPCmd{
>  RCPCMD_GET_REGION = 0x06,
>  RCPCMD_SET_REGION = 0x07,
>  RCPCMD_SYS_RESET = 0x08,
>  ...
>
>  RCPCMD_START_AUTOREAD2 = 0x36,
>  RCPCMD_STOP_AUTOREAD2 = 0x37,
>
>  RCPCMD_WRITE_TYPEC_TAGDATA = 0x46,
>
>  RCPCMD_FAIL = 0xFF
>  }
>
>  enum {
>  RCPMSG_CMD = 0x00,
>  RCPMSG_RESP = 0x01,
>  RCPMSG_NOTIFY = 0x02
>  }
>
>  private struct RCProtocol
>  {
>  enum {
>  RCPPKT_PRE = 0xBB,
>  RCPPKT_END = 0x7E
>  }
>
>  align(1) struct RCPacketHdr {
>  ubyte msgtype;
>  ubyte cmdcode;
>  ushort len;
>  }
>
>  /**
>   * These kind of members will be need only for private
> var for making a cmd packet.
>   * But access-able as a parsed result for a incomming
> packet.
>   */
>  ubyte preamble;
>  RCPacketHdr hdr;
>  ubyte[] payload; //ubyte[len] of payload.
>  ubyte end;
>  ushort crc16;
>
>  ubyte[] makeCMDPacket(RCPCmd cmd, in ubyte[] data)
>  {
>  this.preamble = RCPPKT_PRE;
>  this.hdr.msgtype = RCPMSG_CMD;
>  this.hdr.cmdcode =  cast (ubyte) cmd;
>  this.hdr.len = 0x & data.length;

Why are you using & instead of simply casting to ushort? Casting would be
more idiomatic. Or you can use to!ushort if you want to verify the size at
runtime and have a ConvException thrown if the value is too large.

>  this.end = RCPPKT_END;
>  this.payload = data.dup;
>
>  ubyte [] pkt;
>  pkt ~= this.hdr.msgtype;
>  pkt ~= this.hdr.cmdcode;
>  pkt ~= this.hdr.len >> 8;
>  pkt ~= this.hdr.len & 0xff;
>  pkt = this.preamble ~ pkt ~ this.payload ~ this.end;
>
>  // calc crc16 for Preamble + HDR + Data + END
>  this.crc16 = new RCPCRC16().calc(pkt);
>
>  pkt ~= this.crc16 >> 8;
>  pkt ~= this.crc16 & 0xff;
>
>  return pkt;
>  }
>
>  int parseRespPacket(in ubyte[] recv)
>  {
>  const size_t len = recv.length;
>  if (recv is null)
>  return PARSE_ERR;
>
>  if (len < 8)
>  return PARSE_ERR_PKTLEN;
>
>  if (recv[0] !is RCPPKT_PRE)
>  return PARSE_ERR_PKTHEAD;
>
>  this.preamble = recv[0];
>  this.hdr.msgtype = recv[1];
>  this.hdr.cmdcode = recv[2];
>  this.hdr.len = (recv[3] << 8) + 0xff & recv[4];
>
>  if ( this.hdr.len > (len - 8))
>  return PARSE_ERR_PKT;
>
>  this.end = recv[5+this.hdr.len];
>
>  if (this.end != RCPPKT_END)
>  return PARSE_ERR_PKT;
>
>  this.payload = recv[5 .. (5+this.hdr.len)].dup;
>
>  ubyte [] pkt;
>  pkt ~= this.hdr.msgtype;
>  pkt ~= this.hdr.cmdcode;
>  pkt ~= this.hdr.len >> 8;
>  pkt ~= this.hdr.len & 0xff;
>  pkt = this.preamble ~ pkt ~ this.payload ~ this.end;
>
>  // calc crc16 for Preamble + HDR + Data + END
>  const ushort desired_crc = new RCPCRC16().calc(pkt);
>
>  this.crc16 = (recv[6+this.hdr.len] << 8) +
> recv[7+this.hdr.len];
>  if (this.crc16 != desired_crc) {
>  writefln("-- PARSE ERR: CRC, desired = %04X,
> actuall is %04X", this.crc16, desired_crc);
>  return PARSE_ERR_CRC;
>  }
>
>  return PARSE_OK;
>  }
>  }
>
> ```
>
> It's basically a C-style code, and it works perfect, But I know
> that this is not a "D-way", So, any suggestions?

I'd suggest that you check out std.bitmanip if you haven't.

https://dlang.org/phobos/std_bitmanip.html

append, peek, read, and write in particular are useful if you're putting
various integral values into an array of ubyte[] or reading them from it.
Glancing over what you have, I'm pretty sure that all of the bitshifts and
bitwise &'s and can be removed by using append or write to write the data to
the array and peek or read to read from it.

Also, as far as D style goes, variables and enum values are usually given
camelCase names, whereas you've named your enum values in all uppercase and
your variables names in all lowercase, and you've underscores in the middle
of names. But of course, you can do what you want on that. It's just that if
you make any libraries public (e.g. on code.dlang.org), it's better to
follow the D 

Re: Deploying D web servers

[rikki cattermole via Digitalmars-d]

On 17/12/2017 10:26 PM, Mengu wrote:

On Sunday, 17 December 2017 at 21:07:45 UTC, bauss wrote:

On Sunday, 17 December 2017 at 17:06:32 UTC, cloutiy wrote:

Hi,

In the Javascript world there are services that provide a quick and 
simple means of deploying websites.


I've used things like surge.sh, netlify. I'm sure there are many others.

Is there something similar that exists for the D world?

Regards


Map a drive to your server and have DUB build to it.


what does this mean?


Its a Windows thing.

For poisx you would mount via e.g. sshfs instead of mapping to a drive.

[Issue 18083] -w doesn't work for the ddoc build

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

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

Seb  changed:

   What|Removed |Added

   Severity|major   |normal

--

[Issue 18100] crt_constructor not allow to init immutable

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

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

--- Comment #1 from changlon  ---
crt_constructor can be call from anywhere. If so it is not able to init
immutable.

But if it it not able to init immutable,  it will be much less useful from
BetterC (compare to static this).

--

[Issue 18100] New: crt_constructor not allow to init immutable

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

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

  Issue ID: 18100
   Summary: crt_constructor  not allow to init immutable
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: chang...@gmail.com

=== code 
static immutable int my_i ;
int test(){
return 3;
}

shared static this(){
my_i = test();  // work 
}
pragma(crt_constructor) extern(C) void init1(){
my_i = test(); //   Error: cannot modify immutable expression my_i
}
==

--

[Issue 18099] New: betterC check throw statements error!

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

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

  Issue ID: 18099
   Summary: betterC check throw statements error!
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: chang...@gmail.com

 code ==
struct TypePool {
struct SliceType {
this(SliceType ) {}
~this() {}
}
struct {
auto slice(){
SliceType _slice ;
return _slice ;
}
}
}


dmd -betterC app.d 
Error: Cannot use throw statements with -betterC

--

Re: run.dlang.io - a modern way to run D code

[Seb via Digitalmars-d-announce]

On Sunday, 17 December 2017 at 22:57:58 UTC, Walter Bright wrote:

On 12/16/2017 2:45 AM, Iain Buclaw wrote:

However dmd doesn't do assembly output. ;-)


dmd -c test
obj2asm test.obj >test.asm


FYI: There's http://asm.dlang.org which seems to be a bit 
outdated.
Moreover, there's an open issue to add DMD to d.godbolt.org: 
https://github.com/mattgodbolt/compiler-explorer/issues/306

How to pack a struct to a ubyte[] in a more "The D way" style ?

[Binghoo Dang via Digitalmars-d-learn]

hi,

I'm a dlang newbie, and I recently made a program that interacts 
with an RFID Reader, it's basically a Serial-Port communication 
model. And after 2 days, I finally got a working code like these:


```
enum RCPCmd{
RCPCMD_GET_REGION = 0x06,
RCPCMD_SET_REGION = 0x07,
RCPCMD_SYS_RESET = 0x08,
...

RCPCMD_START_AUTOREAD2 = 0x36,
RCPCMD_STOP_AUTOREAD2 = 0x37,

RCPCMD_WRITE_TYPEC_TAGDATA = 0x46,

RCPCMD_FAIL = 0xFF
}

enum {
RCPMSG_CMD = 0x00,
RCPMSG_RESP = 0x01,
RCPMSG_NOTIFY = 0x02
}

private struct RCProtocol
{
enum {
RCPPKT_PRE = 0xBB,
RCPPKT_END = 0x7E
}

align(1) struct RCPacketHdr {
ubyte msgtype;
ubyte cmdcode;
ushort len;
}

/**
 * These kind of members will be need only for private 
var for making a cmd packet.
 * But access-able as a parsed result for a incomming 
packet.

 */
ubyte preamble;
RCPacketHdr hdr;
ubyte[] payload; //ubyte[len] of payload.
ubyte end;
ushort crc16;

ubyte[] makeCMDPacket(RCPCmd cmd, in ubyte[] data)
{
this.preamble = RCPPKT_PRE;
this.hdr.msgtype = RCPMSG_CMD;
this.hdr.cmdcode =  cast (ubyte) cmd;
this.hdr.len = 0x & data.length;
this.end = RCPPKT_END;
this.payload = data.dup;

ubyte [] pkt;
pkt ~= this.hdr.msgtype;
pkt ~= this.hdr.cmdcode;
pkt ~= this.hdr.len >> 8;
pkt ~= this.hdr.len & 0xff;
pkt = this.preamble ~ pkt ~ this.payload ~ this.end;

// calc crc16 for Preamble + HDR + Data + END
this.crc16 = new RCPCRC16().calc(pkt);

pkt ~= this.crc16 >> 8;
pkt ~= this.crc16 & 0xff;

return pkt;
}

int parseRespPacket(in ubyte[] recv)
{
const size_t len = recv.length;
if (recv is null)
return PARSE_ERR;

if (len < 8)
return PARSE_ERR_PKTLEN;

if (recv[0] !is RCPPKT_PRE)
return PARSE_ERR_PKTHEAD;

this.preamble = recv[0];
this.hdr.msgtype = recv[1];
this.hdr.cmdcode = recv[2];
this.hdr.len = (recv[3] << 8) + 0xff & recv[4];

if ( this.hdr.len > (len - 8))
return PARSE_ERR_PKT;

this.end = recv[5+this.hdr.len];

if (this.end != RCPPKT_END)
return PARSE_ERR_PKT;

this.payload = recv[5 .. (5+this.hdr.len)].dup;

ubyte [] pkt;
pkt ~= this.hdr.msgtype;
pkt ~= this.hdr.cmdcode;
pkt ~= this.hdr.len >> 8;
pkt ~= this.hdr.len & 0xff;
pkt = this.preamble ~ pkt ~ this.payload ~ this.end;

// calc crc16 for Preamble + HDR + Data + END
const ushort desired_crc = new RCPCRC16().calc(pkt);

this.crc16 = (recv[6+this.hdr.len] << 8) + 
recv[7+this.hdr.len];

if (this.crc16 != desired_crc) {
writefln("-- PARSE ERR: CRC, desired = %04X, 
actuall is %04X", this.crc16, desired_crc);

return PARSE_ERR_CRC;
}

return PARSE_OK;
}
}

```

It's basically a C-style code, and it works perfect, But I know 
that this is not a "D-way", So, any suggestions?


Thanks!

Re: Diamond Full-stack MVC / Template Engine - v2.5.4 Released!

[Sönke Ludwig via Digitalmars-d-announce]

Just a quick note that the information in the README about Diet 
templates is not up to date anymore. The diet-ng package [1] does not 
have any external dependencies except for Phobos and is implemented in 
terms of generic ranges.


[1] https://github.com/rejectedsoftware/diet-ng

Re: run.dlang.io - a modern way to run D code

[Walter Bright via Digitalmars-d-announce]

On 12/16/2017 2:45 AM, Iain Buclaw wrote:

However dmd doesn't do assembly output. ;-)


dmd -c test
obj2asm test.obj >test.asm

Re: Deploying D web servers

[Mengu via Digitalmars-d]

On Sunday, 17 December 2017 at 21:07:45 UTC, bauss wrote:

On Sunday, 17 December 2017 at 17:06:32 UTC, cloutiy wrote:

Hi,

In the Javascript world there are services that provide a 
quick and simple means of deploying websites.


I've used things like surge.sh, netlify. I'm sure there are 
many others.


Is there something similar that exists for the D world?

Regards


Map a drive to your server and have DUB build to it.


what does this mean?

Re: Released vibe.d 0.8.2

[Sönke Ludwig via Digitalmars-d-announce]

Am 17.12.2017 um 21:56 schrieb bauss:

On Sunday, 17 December 2017 at 20:55:15 UTC, bauss wrote:

    private Nullable!string _path;


Also does this really make sense?

Why not just have it:

private string _path;

Then instead of:
     string path() @safe {
     if (_path.isNull) {
     _path = urlDecode(requestPath.toString);
     }
     return _path.get;
     }

You could have:
     string path() @safe {
     if (!_path) {
     _path = urlDecode(requestPath.toString);
     }
     return _path;
     }


That would certainly be possible. Using a `Nullable` is mainly just more 
explicit.

Re: Released vibe.d 0.8.2

[Sönke Ludwig via Digitalmars-d-announce]

Am 17.12.2017 um 21:55 schrieb bauss:

On Sunday, 17 December 2017 at 19:13:44 UTC, Sönke Ludwig wrote:
But what do you mean with anything will break using `.path`? It 
follows the usual deprecation path - currently it's just documented as 
deprecated. In one or two releases, the `deprecated` attribute will be 
set and a few releases later it will finally be removed. By that time 
projects will have had quite some time to react on the deprecation.


HTTPServerRequest.path does not have the same definition as previously.

It has been changed from a field to a getter function.


True, this can be a breaking change, but setting this field looks like 
something that is outside of any sane use case. The field should ideally 
have been const/immutable before.




Tbh. it should just have been marked with deprecated instead of being 
removed, as you do specify is the normal deprecation process.


What do you mean with this? Keeping the field with a `deprecated` 
attribute, and at the same time add the getter property?




0.8.1:
     /** The _path part of the URL.

     Remarks: This field is only set if 
HTTPServerOption.parseURL is set.

     */
     string path;

0.8.2:
     /** Deprecated: The _path part of the URL.

     Note that this function contains the decoded version of the
     requested path, which can yield incorrect results if the path
     contains URL encoded path separators. Use `requestPath` 
instead to

     get an encoding-aware representation.
     */
     string path() @safe {
     if (_path.isNull) {
     _path = urlDecode(requestPath.toString);
     }
     return _path.get;
     }

     private Nullable!string _path;

There should still have been a setter property like:

void path(string newPath);

Which should be marked with deprecated until it could be safely removed.

Re: Deploying D web servers

[bauss via Digitalmars-d]

On Sunday, 17 December 2017 at 17:06:32 UTC, cloutiy wrote:

Hi,

In the Javascript world there are services that provide a quick 
and simple means of deploying websites.


I've used things like surge.sh, netlify. I'm sure there are 
many others.


Is there something similar that exists for the D world?

Regards


Map a drive to your server and have DUB build to it.

Re: Released vibe.d 0.8.2

[bauss via Digitalmars-d-announce]

On Sunday, 17 December 2017 at 19:13:44 UTC, Sönke Ludwig wrote:
But what do you mean with anything will break using `.path`? It 
follows the usual deprecation path - currently it's just 
documented as deprecated. In one or two releases, the 
`deprecated` attribute will be set and a few releases later it 
will finally be removed. By that time projects will have had 
quite some time to react on the deprecation.


HTTPServerRequest.path does not have the same definition as 
previously.


It has been changed from a field to a getter function.

Tbh. it should just have been marked with deprecated instead of 
being removed, as you do specify is the normal deprecation 
process.


0.8.1:
/** The _path part of the URL.

			Remarks: This field is only set if HTTPServerOption.parseURL 
is set.

*/
string path;

0.8.2:
/** Deprecated: The _path part of the URL.

Note that this function contains the decoded version of 
the
requested path, which can yield incorrect results if 
the path
			contains URL encoded path separators. Use `requestPath` 
instead to

get an encoding-aware representation.
*/
string path() @safe {
if (_path.isNull) {
_path = urlDecode(requestPath.toString);
}
return _path.get;
}

private Nullable!string _path;

There should still have been a setter property like:

void path(string newPath);

Which should be marked with deprecated until it could be safely 
removed.

Re: Released vibe.d 0.8.2

[bauss via Digitalmars-d-announce]

On Sunday, 17 December 2017 at 20:55:15 UTC, bauss wrote:

private Nullable!string _path;


Also does this really make sense?

Why not just have it:

private string _path;

Then instead of:
string path() @safe {
if (_path.isNull) {
_path = urlDecode(requestPath.toString);
}
return _path.get;
}

You could have:
string path() @safe {
if (!_path) {
_path = urlDecode(requestPath.toString);
}
return _path;
}

Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

[ParticlePeter via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 20:09:02 UTC, ParticlePeter wrote:
On Sunday, 17 December 2017 at 19:29:00 UTC, ParticlePeter 
wrote:

On Sunday, 17 December 2017 at 19:16:02 UTC, ParticlePeter

[snip]

LINKCMD=%VCINSTALLDIR%\bin\HostX32\x64\link.exe

or

LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe


First one is BS, of course it must be:

LINKCMD=%VCINSTALLDIR%\bin\HostX86\x64\link.exe


Filed a bug:
https://issues.dlang.org/show_bug.cgi?id=18098

[Issue 18095] Add support for pragma(mangle) on alias declarations

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

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

--- Comment #1 from Jacob Carlborg  ---
https://github.com/dlang/dmd/pull/7458

--

[Issue 18098] New: Issues with path to VS2017 x64 linker in sc.ini [Environment64] AFTER pull 227

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

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

  Issue ID: 18098
   Summary: Issues with path to VS2017 x64 linker in sc.ini
[Environment64] AFTER pull 227
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: particlepe...@gmx.de

sc.ini [Environment64]: the installer detects VS 2017 (%VCINSTALLDIR%, L47)
correctly but (L54) sets:

LINKCMD=%VCINSTALLDIR%\bin\HostX86\x86\link.exe

In my scenario (see bellow) this leads to following error:

fatal error C1905: Front end and back end not compatible (must target same
processor).
LINK : fatal error LNK1257: code generation failed
Error: linker exited with status 1257
dmd failed with exit code 1257.

The error does not occur when sc.ini L54 is changed to:

LINKCMD=%VCINSTALLDIR%\bin\HostX86\x64\link.exe

or

LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe

I assume that the path variable set at L62 should be change correspondingly,
but had no issues with it so far.


My scenario is a mixed c++/s project. I am linking to a c++ static library
which I build myself with VS2017 for x64 (https://github.com/ocornut/imgui).

Related:
Issue 17280
Issue 17320
https://github.com/dlang/installer/pull/227
https://forum.dlang.org/post/qffzjttlcjzlgmmhk...@forum.dlang.org

--

Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

[ParticlePeter via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 19:29:00 UTC, ParticlePeter wrote:
On Sunday, 17 December 2017 at 19:16:02 UTC, ParticlePeter 
wrote:

On Sunday, 17 December 2017 at 17:56:47 UTC, John wrote:

I don't think so, all that would need to be changed is this 
line:


https://github.com/dlang/dmd/blob/v2.077.1/ini/windows/bin/sc.ini#L53

Not very many people use it I guess if it's been there for 8 
months lol.


Hm, actually that line IS uncommented in my installed sc.ini 
and VCINSTALLDIR is properly detected. Any idea what still 
might go wrong?


Think I figured it out. For me it works when changing that 
particular line to:


LINKCMD=%VCINSTALLDIR%\bin\HostX32\x64\link.exe

or

LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe


First one is BS, of course it must be:

LINKCMD=%VCINSTALLDIR%\bin\HostX86\x64\link.exe

[Issue 18097] New: [REG2.077] Unittest function is undefined identifier

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

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

  Issue ID: 18097
   Summary: [REG2.077] Unittest function is undefined identifier
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johanenge...@weka.io

Pre 2.077, this code worked:
```
unittest // first unittest
{
}

unittest // second unittest
{
auto a = (__traits(identifier, __traits(parent, {  })));
auto b = &__traits(parent, {  });

//auto c = &__unittestL3_2; // dlang 2.076
//auto c = &__unittest_dummy_d_3_2; //dlang 2.077
}
```

The purpose of the code is to obtain the address of the unittest function.
Either `a` or `b` work, and directly naming the unittest function also works
(`c`).

With 2.077, we get the error:
```
dummy.d-mixin-5(5): Error: undefined identifier __unittest_dummy_d_3_1, did you
mean function __unittest_dummy_d_3_1?
```

This regression was probably introduced by
https://github.com/dlang/dmd/pull/6727 , where the symbol name of unittest
function is set during semantic analysis probably too late for this identifier
resolution?

Note: the first unittest is needed to trigger the bug.

--

[Issue 18097] [REG2.077] Unittest function is undefined identifier

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

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

johanenge...@weka.io changed:

   What|Removed |Added

   Keywords||industry

--

Re: Fold in Parallelism

[Ali Çehreli via Digitalmars-d-learn]

On 12/17/2017 08:11 AM, Vino wrote:

>   As per the document form std.parallelism it states that we can use
> taskPool.reduce so can we use the same for fold (taskPool.fold) as
> basically both are same with slight variation on seed values, if
> possible can can we define the same in the below lines

fold has only been added to std.algorithm. Opened an enhancement request:

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

Ali

[Issue 18096] New: Add fold() to std.parallelism

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

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

  Issue ID: 18096
   Summary: Add fold() to std.parallelism
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: acehr...@yahoo.com

At least for parity with std.algorithm, add fold() to std.parallelism.

Ali

--

Re: Passing anonymous enums as function parameters

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, December 17, 2017 12:47:26 kerdemdemir via Digitalmars-d-learn 
wrote:
> What I meant with anonymous enums was:
> https://dlang.org/spec/enum.html#anonymous_enums. Maybe I
> couldn't explain well but I believe D have anonymous enums. I am
> sorry I have forgotten to remove " :string" in my example from
> the "enum : string". Please stretch out ": string" part my
> problem is not related with that.

That's pretty much just declaring manifest constants with braces so that you
don't repeat the keyword enum a bunch of times.

enum
{
a = "foo",
b = "bar",
c = "baz";
}

is identical to

enum a = "foo";
enum b = "bar";
enum c = "baz";

and it will even let you mix types, e.g.

enum
{
a = "foo",
b = 42
}

which you can't do with actual enums. You're not declaring a new type.
You're just declaring a bunch of constants. They're really not enums in the
classic sense, and for the most part, folks around here aren't going to call
them enums. If anything, a number of folks complain that the keyword enum
was reused for manifest constants. I don't know why the documentation has a
section for "anonymous enums" separate from manifest constants, since
they're really not a different thing, and AFAIK, pretty much no one calls
them that - though at least they're right next to the documentation for
manifest constants.

- Jonathan M Davis

Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

[ParticlePeter via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 19:16:02 UTC, ParticlePeter wrote:

On Sunday, 17 December 2017 at 17:56:47 UTC, John wrote:

I don't think so, all that would need to be changed is this 
line:


https://github.com/dlang/dmd/blob/v2.077.1/ini/windows/bin/sc.ini#L53

Not very many people use it I guess if it's been there for 8 
months lol.


Hm, actually that line IS uncommented in my installed sc.ini 
and VCINSTALLDIR is properly detected. Any idea what still 
might go wrong?


Think I figured it out. For me it works when changing that 
particular line to:


LINKCMD=%VCINSTALLDIR%\bin\HostX32\x64\link.exe

or

LINKCMD=%VCINSTALLDIR%\bin\HostX64\x64\link.exe

Re: What does rt/sections_elf_shared.d do? (Porting dmd to musl)

[Joakim via Digitalmars-d]

On Sunday, 17 December 2017 at 12:45:58 UTC, Yuxuan Shui wrote:
I'm trying to get dmd and phobos working with musl. Right now I 
have a bootstrapped compiler built with musl, which seems to 
work fine. However user applications will segmentation fault 
before even reaches main.


I investigated a bit. Looks like musl is not happy with how 
druntime uses dlopen related functions. When a D library loads, 
it tries to call _d_dso_registry, which will try to get a 
handle of the library using dlopen. Meaning dlopen will be 
called on the library itself while it's still loading. This 
seems to break musl. Although this might also be a bug on musl 
side: it tries to call init functions even when RTLD_NOLOAD is 
passed to dlopen.


However, going through sections_elf_shared.d, it makes me feel 
it's doing some magic tricks with dl functions, but I don't 
know what for?


If my understand is correct, it's used to register TLS storage 
to GC. If that's the case, there must be simpler ways to do 
that.


It does various things to setup the ELF executable for BSD and 
linux/Glibc, including support for using the stdlib as a shared 
library: take a look at the much simpler sections_android or 
sections_solaris for the minimum of what's required.


You can use sections_elf_shared with the shared library support 
turned off, by adding the SHARED=0 flag when building druntime.  
I'd do that first before trying to modify the source for Musl.

Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

[ParticlePeter via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 17:56:47 UTC, John wrote:

I don't think so, all that would need to be changed is this 
line:


https://github.com/dlang/dmd/blob/v2.077.1/ini/windows/bin/sc.ini#L53

Not very many people use it I guess if it's been there for 8 
months lol.


Hm, actually that line IS uncommented in my installed sc.ini and 
VCINSTALLDIR is properly detected. Any idea what still might go 
wrong?

Re: Released vibe.d 0.8.2

[Sönke Ludwig via Digitalmars-d-announce]

Am 17.12.2017 um 16:24 schrieb bauss:

On Sunday, 17 December 2017 at 14:13:05 UTC, WebFreak001 wrote:

On Sunday, 17 December 2017 at 12:52:57 UTC, bauss wrote:
This shouldn't have been released as 0.8.2, because it has a lot of 
breaking changes.


For an instance anything that relies on HTTPServerRequest.path will 
break.


I'm aware that there has been added the "requestPath" property, but 
it's still a breaking change to all existing code that relies on the 
old "path" property. Especially when it's used to manipulate the path 
you receive.


Diamond cannot currently be used with latest release of vibe.d, 
because of this and it was relying on vibe.d with following dependency:


"vibe-d": "~>0.8.1"

0.8.2 should not be a breaking change, assuming you follow semantic 
versioning.


https://semver.org/


4. Major version zero (0.y.z) is for initial development. Anything may 
change at any time. The public API should not be considered stable.


0.x.Y should always be compatible with 0.x.Z without breaking changes.

Since it's MAJOR.MINOR.PATCH

This is a patch release 0.8.1 to 0.8.2 which means:

"PATCH version when you make backwards-compatible bug fixes."

Even a minor version should be backward-compatible.

"MINOR version when you add functionality in a backwards-compatible 
manner, and"


I'm all for deprecating said features, but plain removing them in a 
release like this is a breaking change and should at the very least be a 
minor version upgrade, but definitely not a patch.


The above was actually a quote from the spec, so there is no doubt that 
any 0.x.y release may contain breaking changes. But apart from that, the 
development has always gone this way so far. I just made 0.8.0 a new 
"minor" version, because it is in many ways a much larger step than the 
previous releases and not all breaking changes could reasonably follow 
the usual deprecation paths.


However, as individual sub packages are separated out into their own 
repositories (such as diet-ng and vibe-core), their versioning will 
start as 1.0.0 and will follow the usual versioning rules for >= 1.x.y 
releases.


But what do you mean with anything will break using `.path`? It follows 
the usual deprecation path - currently it's just documented as 
deprecated. In one or two releases, the `deprecated` attribute will be 
set and a few releases later it will finally be removed. By that time 
projects will have had quite some time to react on the deprecation.

[Issue 18094] Crash on variadic arguments

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

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

--- Comment #2 from Basile B.  ---
It prefers "in string[]" over "string". Add the "in" parameter storage class to
the overload that takes a string and it works.

---
void Put(in string[] items...)
{
foreach(item;items) Put(item);
}
void Put(in string item) { }
void test1()
{
immutable string[] optsldc=["a","a"];
Put(optsldc);
}
void main()
{
return test1();
}
---

The problem is, firstly, that the overload rules for this case are not
specified.

https://dlang.org/spec/function.html#overload-sets

--

Re: Where is sleep()?

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

On Sunday, 17 December 2017 at 17:01:37 UTC, Steven Schveighoffer 
wrote:
I searched for "sleep" in "library", core.thread was the first 
result.


Yeah, me too (followed by core.time, std.datetime.stopwatch, and 
std.datetime...), but it isn't obvious any of them are actual 
winners.


If you already basically know what you're looking for, it can 
refresh, but if it is first time


core.thread - D Programming Language
https://dlang.org/phobos/core_thread.html
Jump to: getAll · getThis · id · isDaemon · isRunning · join · 
name · opApply · priority · PRIORITY_DEFAULT · PRIORITY_MAX · 
PRIORITY_MIN · sleep · start · this · yield. class Thread ;. This 
class encapsulates all threading functionality for the D 
programming language. As thread manipulation is a required 
facility for garbage ...



doesn't really indicate it was a good hit and when the click the 
page, even finding that jumplist takes a second search. This is 
one of the better results I tend to get off the official site.



Whereas mine gives:

http://dpldocs.info/sleep

core.​thread.​Thread.​sleep

Suspends the calling thread for at least the supplied period. 
This may result in multiple OS calls if period is greater than 
the maximum sleep duration supported by the operating system.



immediately, right there on the result page. As well as other 
hits such as vibe.d's sleep.

[Issue 17708] Escape control characters in std.conv.to error messages

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

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

Jon Degenhardt  changed:

   What|Removed |Added

 CC||jrdemail2000-dl...@yahoo.co
   ||m

--- Comment #1 from Jon Degenhardt  ---
Encountered this case in my tools
(https://github.com/eBay/tsv-utils-dlang/issues/96). A user was processing a
DOS file (with `\r\n` line endings) on a Unix box, byLine left the extraneous
`\r` at the end of the line. My tool tried to convert to double, and output the
error text when this failed due to the `\r`. The formatting of the output is
quite confusing, as `\r` actually repositions to the start of the line,
effectively deleting the initial part of the output line. The result:

  ' when converting from type const(char)[] to type doubleUnexpected '

For my tools I'll add explicit detection of DOS line endings on Unix boxes,
it's just too common when getting data files from a variety of sources.
However, it'd be helpful to update error message generation to handle `\r` and
other non-printing characters.

--

Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

[John via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 17:15:57 UTC, ParticlePeter wrote:

On Sunday, 17 December 2017 at 16:40:46 UTC, John wrote:

Yah the sc.ini file is wrong for Environment64.


[Environment64]
LIB="%@P%\..\lib64"

.
.
.

; Windows installer uncomments the version detected
LINKCMD=%VCINSTALLDIR%\bin\HostX86\x86\link.exe


Thanks! Is this a known, reported bug?


I don't think so, all that would need to be changed is this line:

https://github.com/dlang/dmd/blob/v2.077.1/ini/windows/bin/sc.ini#L53

Not very many people use it I guess if it's been there for 8 
months lol.

[Issue 18094] Crash on variadic arguments

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

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

Re: Lazily parse a JSON text file using stdx.data.json?

[David Gileadi via Digitalmars-d]

On 12/17/17 3:28 AM, WebFreak001 wrote:

On Sunday, 17 December 2017 at 04:34:22 UTC, David Gileadi wrote:
uh I don't know about stdx.data.json but if you didn't manage to succeed 
yet, I know that asdf[1] works really well with streaming json. There is 
also an example how it works.


[1]: http://asdf.dub.pm


Thanks, reading the whole file into memory worked fine. However, asdf 
looks really cool. I'll definitely look into next time I need to deal 
with JSON.

Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

[ParticlePeter via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 16:40:46 UTC, John wrote:

Yah the sc.ini file is wrong for Environment64.


[Environment64]
LIB="%@P%\..\lib64"

.
.
.

; Windows installer uncomments the version detected
LINKCMD=%VCINSTALLDIR%\bin\HostX86\x86\link.exe


Thanks! Is this a known, reported bug?

Deploying D web servers

[cloutiy via Digitalmars-d]

Hi,

In the Javascript world there are services that provide a quick 
and simple means of deploying websites.


I've used things like surge.sh, netlify. I'm sure there are many 
others.


Is there something similar that exists for the D world?

Regards

[Issue 18095] New: Add support for pragma(mangle) on alias declarations

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

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

  Issue ID: 18095
   Summary: Add support for pragma(mangle) on alias declarations
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: d...@me.com

This allows to override the mangling of a type in an alias declaration as
follows:

pragma(mangle, "foo") alias foo = int;
static assert(foo.mangleof == "foo");
static assert(int.mangleof == "i");

Overriding the mangling of a type in an alias allows for more generic solution
to get the correct mangling of `c_long/c_ulong` for C++ functions. With the
current solution the compiler is looking for a struct with the name
`__c_long/__c_ulong` and special cases the mangling for that particular struct.
Since D doesn't have implicit conversions to structs one are also forced
cast/explicitly construct a `__c_long` struct when calling a function which
uses the `__c_long` type as a parameter. With an alias that's not necessary
anymore.

--

Re: Where is sleep()?

[Steven Schveighoffer via Digitalmars-d-learn]

On 12/17/17 8:32 AM, Adam D. Ruppe wrote:

On Sunday, 17 December 2017 at 08:32:20 UTC, Ryan David Sheasby wrote:

What am I missing?


the official search is hard to use, so I made my own. When looking for 
something, try dpldocs.info/search_term


http://dpldocs.info/sleep

and here it pops right up.



I searched for "sleep" in "library", core.thread was the first result.

Now, it would be good to have it link directly to the sleep function 
itself, but it looks like searching in the library only links to the 
one-page-per-module version of the docs.


If I change google's terms to site:dlang.org/library instead of 
site:dlang.org/phobos, then searching for sleep gives me the 
Thread.sleep function as the first result.


-Steve

Re: Function signature testing with is expression.

[Alexandru Ermicioi via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 16:19:00 UTC, ag0aep6g wrote:
On Sunday, 17 December 2017 at 14:44:15 UTC, Alexandru Ermicioi 
wrote:

Suppose:

struct F {
static void foo(T)(T i, int o) {}
}

enum bool check(T) = is(F.foo!T == void function(Z, int), Z);

enum correct = check!int;


Upon running it will return false, though, by logic is 
expression could deduce that F.foo is conformat to function 
signature in check test.


Here, `F.foo!T` is the function itself, not its type. You 
forgot `typeof`.


It is interesting that it will not work with global functions 
as well:



void foo(int i, double d) {};
enum bool check = is(typeof(foo) == void function(int, 
double));



It will be as well evaluated to false.


Write `typeof()` to make it work.

There are two kinds of function types in D:

1) "Proper" function types, e.g. `typeof(foo)` which gets 
printed as "void(int i, double d)", and
2) function pointer types, e.g. `typeof()` which gets 
printed as "void function(int i, double d)".


As you see, the second kind is the one you're comparing 
against. I don't think you can use the first kind directly in 
an IsExpression. The first kind is really rather useless, as 
far as I know. Argubaly, the language would be nicer without it.


Thanks for help, ag0aep6g and Ali.

Now it is more clear why it didn't work. Although I did try to 
use FunctionTypeOf, which failed, and it seems due to explanation 
about two kinds of function types. It seems that FunctionTypeOf 
returns first kind which does not work with is expression, and 
not second.

See the example (first line):

--
import std.traits;

struct T {
static void coo(M)(M e, int i);
}

void main() {
	pragma(msg, is(FunctionTypeOf!(!int) == void function(Z, 
int), Z));
	pragma(msg, is(FunctionTypeOf!(!X) == void function(X, 
int), X));

pragma(msg, is(typeof(!int) == void function(Z, int), Z));
pragma(msg, is(typeof(!X) == void function(X, int), X));
}
--

If run, first line will return false (even without &).

The initial question was related actually to another thing that 
I've tried to do, which is pattern matching on templated 
functions. It failed, see line 2, and 4.


It seems that now it is impossible to do pattern matching on 
templates, only on instantiated types.
Is there any possibility to check the internals of a template 
without instantiating it?
It would be good for using Policy pattern where you want for 
example to test passed policy, has a templated function with a 
desired signature for it.

Re: Lazily parse a JSON text file using stdx.data.json?

[Steven Schveighoffer via Digitalmars-d]

On 12/17/17 4:44 AM, Jonathan M Davis wrote:


If I were seriously looking at
reading in a file lazily as a forward range, I'd look at
http://code.dlang.org/packages/iopipe, though as I understand it, it's very
much a work in progress.


There is an even more work-in-progress library built on that, but it's 
not yet in dub (this was the library I wrote for my dconf talk this 
year): https://github.com/schveiguy/jsoniopipe


This kind of demonstrates how to parse json data lazily with pretty high 
performance.


It really depends on what you are trying to do, though.


As for auto-decoding, yeah, it sucks. You can work around it with stuff like
std.utf.byCodeUnit, but auto-decoding is a problem all around, and it's one
that we're likely stuck with, because unfortunately, we haven't found a way
to remove it without breaking everything.


I think there eventually will have to be a day of reckoning for 
auto-decoding. But it probably will take a monumental effort to show how 
it can be done without being too painful for existing code. I still 
believe it can be done.


-Steve

Re: Where is sleep()?

[Ali Çehreli via Digitalmars-d-learn]

On 12/17/2017 12:32 AM, Ryan David Sheasby wrote:

> I've searched high and low but can't
> seem to find a simple sleep/delay/wait/pause function in the core or in
> phobos.

Prepending "dlang" to Google searches has been working well for me. 
Googling for "dlang sleep" lists the documentation as the first hit for 
me. Same with "dlang phobos sleep", "dlang druntime sleep", etc.


Ali

Re: Passing anonymous enums as function parameters

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-12-17 12:49, kerdemdemir wrote:

I have an enum statement :

enum : string
{
     KErdem
     Ali
     Zafer
     Salih
     //etc...
}


I don't want to give a name to my enum class since I am accessing this 
variables very often.


But I also have a function like:

double ReturnCoolNess( /* Is there any way? */ enumVal )
{
   switch (enumVal)
   {
 case KErdem:
 {
     return 0.0
 }
 case Ali:
 {
     return 100.0;
 }
 case Salih:
 {
     return 100.0;
 }
     // etc..
   }
}

Is there any way I still keep my enum anonymous and be able to call 
functions with different enumarations. Or is there any other way to call 
named enums without type name ?


You have three options:

* Specify "string" as the type of the parameter for the ReturnCoolNess 
function. Note that this will allow any string to be passed to this function


* Use the "with" statement to avoid having to specify the enum name. 
This needs to be used in every place you want to access the enum members


enum Foo : string
{
KErdem
Ali
Zafer
Salih
//etc...
}

double ReturnCoolNess(Foo enumVal )
{
with(Foo)
switch (enumVal)
{
case KErdem:
{
return 0.0
}
case Ali:
{
return 100.0;
}
case Salih:
{
return 100.0;
}
// etc..
}
}

* Use "alias" to make the enum members available without having to 
specify the enum name:


enum Foo : string
{
KErdem
Ali
Zafer
Salih
//etc...
}

alias KErdem = Foo.KErdem
alias Ali = Foo.Ali
// etc...

Now you can access the enum members through the aliases. Specify "Foo" 
as the type of the parameter in the ReturnCoolNess function. Generating 
these alias can be automated with some metaprogramming and string mixins.


--
/Jacob Carlborg

Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

[John via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 15:57:08 UTC, ParticlePeter wrote:
I upgraded from DMD 2.074.1 (!) to 2.077.1 and tried to compile 
a mixed c++/d project (DMD links to one c++ lib). Here is the 
full error message:


fatal error C1905: Front end and back end not compatible (must 
target same processor).

LINK : fatal error LNK1257: code generation failed
Error: linker exited with status 1257
dmd failed with exit code 1257.

No such problems with my previous DMD version.

What has changed with linking since then? (Skimmed through 
changelogs but found nothing).


I found a workaround with specifying LINKCMD64 to my VS 2017 
linker, but this is not a viable solution. The project must 
build with DMD on any system with VS installed without me 
knowing its exact location.


What can I do to make it run out of the box and without the 
link command specified?


Yah the sc.ini file is wrong for Environment64.


[Environment64]
LIB="%@P%\..\lib64"

.
.
.

; Windows installer uncomments the version detected
LINKCMD=%VCINSTALLDIR%\bin\HostX86\x86\link.exe

Re: Dynamic Array reserve

[Steven Schveighoffer via Digitalmars-d-learn]

On 12/17/17 11:18 AM, Vino wrote:

On Sunday, 17 December 2017 at 00:45:06 UTC, Ali Çehreli wrote:

On 12/16/2017 03:58 PM, Steven Schveighoffer wrote:


[...]


I was going to suggest the same to Vino and I was writing the 
following program to demonstrate how low the number of allocations is.


[...]


Hi Steven /Ali,

   Initially we use the native array and we observed the execution time 
was higher so we  then we changed all the native array to container 
array and we were able to see some performance gain, the memory usage is 
not a constrain for us, are main goal is how fast the program can 
perform. Please let me know your thoughts on the same.




Yeah, the main reason to use Array is for performance.

Note, you may have better performance with Appender as well, as it does 
not need to query the GC for metadata.


-Steve

Re: Dynamic Array reserve

[Vino via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 00:45:06 UTC, Ali Çehreli wrote:

On 12/16/2017 03:58 PM, Steven Schveighoffer wrote:


[...]


I was going to suggest the same to Vino and I was writing the 
following program to demonstrate how low the number of 
allocations is.


[...]


Hi Steven /Ali,

  Initially we use the native array and we observed the execution 
time was higher so we  then we changed all the native array to 
container array and we were able to see some performance gain, 
the memory usage is not a constrain for us, are main goal is how 
fast the program can perform. Please let me know your thoughts on 
the same.


From,
Vino.B

Re: Function signature testing with is expression.

[ag0aep6g via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 14:44:15 UTC, Alexandru Ermicioi 
wrote:

Suppose:

struct F {
static void foo(T)(T i, int o) {}
}

enum bool check(T) = is(F.foo!T == void function(Z, int), Z);

enum correct = check!int;


Upon running it will return false, though, by logic is 
expression could deduce that F.foo is conformat to function 
signature in check test.


Here, `F.foo!T` is the function itself, not its type. You forgot 
`typeof`.


It is interesting that it will not work with global functions 
as well:



void foo(int i, double d) {};
enum bool check = is(typeof(foo) == void function(int, double));


It will be as well evaluated to false.


Write `typeof()` to make it work.

There are two kinds of function types in D:

1) "Proper" function types, e.g. `typeof(foo)` which gets printed 
as "void(int i, double d)", and
2) function pointer types, e.g. `typeof()` which gets printed 
as "void function(int i, double d)".


As you see, the second kind is the one you're comparing against. 
I don't think you can use the first kind directly in an 
IsExpression. The first kind is really rather useless, as far as 
I know. Argubaly, the language would be nicer without it.

Fold in Parallelism

[Vino via Digitalmars-d-learn]

HI All,

 As per the document form std.parallelism it states that we can 
use taskPool.reduce so can we use the same for fold 
(taskPool.fold) as basically both are same with slight variation 
on seed values, if possible can can we define the same in the 
below lines


Tried the below but getting an error
auto SdFiles = Array!ulong(dirEntries("C:\\TEMP\\BACKUP", 
SpanMode.depth).map!(a => a.size).taskPool.fold!((a,b) => a + b) 
(x))[];
Error : Srvnscleaner.d(89): Error: function 
std.parallelism.taskPool () is not callable using argument types 
(MapResult!(__lambda2, DirIterator))


auto SdFiles = Array!ulong(dirEntries("C:\\TEMP\\BACKUP", 
SpanMode.depth).map!(a => a.size).fold!((a,b) => a + b) 
(x)).taskPool[];


Error : Size.d(89): Error: function std.parallelism.taskPool () 
is not callable using argument types (Array!ulong)



From,
Vino.B

Re: Function signature testing with is expression.

[Ali Çehreli via Digitalmars-d-learn]

On 12/17/2017 06:44 AM, Alexandru Ermicioi wrote:

> It is interesting that it will not work with global functions as well:
>
> 
> void foo(int i, double d) {};
> enum bool check = is(typeof(foo) == void function(int, double));
> 

There, the address-of operator is missing. This works:

void foo(int i, double d) {};
static assert(is(typeof() == void function(int, double)));

Ali

Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

[ParticlePeter via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 15:57:08 UTC, ParticlePeter wrote:
I upgraded from DMD 2.074.1 (!) to 2.077.1 and tried to compile 
a mixed c++/d project (DMD links to one c++ lib). Here is the 
full error message:


Forgot most important info, ita an x64 project those used VS 
linker by default afaik.

Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible

[ParticlePeter via Digitalmars-d-learn]

I upgraded from DMD 2.074.1 (!) to 2.077.1 and tried to compile a 
mixed c++/d project (DMD links to one c++ lib). Here is the full 
error message:


fatal error C1905: Front end and back end not compatible (must 
target same processor).

LINK : fatal error LNK1257: code generation failed
Error: linker exited with status 1257
dmd failed with exit code 1257.

No such problems with my previous DMD version.

What has changed with linking since then? (Skimmed through 
changelogs but found nothing).


I found a workaround with specifying LINKCMD64 to my VS 2017 
linker, but this is not a viable solution. The project must build 
with DMD on any system with VS installed without me knowing its 
exact location.


What can I do to make it run out of the box and without the link 
command specified?

Re: What does rt/sections_elf_shared.d do? (Porting dmd to musl)

[Yuxuan Shui via Digitalmars-d]

On Sunday, 17 December 2017 at 12:45:58 UTC, Yuxuan Shui wrote:
However, going through sections_elf_shared.d, it makes me feel 
it's doing some magic tricks with dl functions, but I don't 
know what for?




Looks like it's also repeating some work that is already done by 
the dynamic linker...

Re: Released vibe.d 0.8.2

[bauss via Digitalmars-d-announce]

On Sunday, 17 December 2017 at 14:13:05 UTC, WebFreak001 wrote:

On Sunday, 17 December 2017 at 12:52:57 UTC, bauss wrote:
This shouldn't have been released as 0.8.2, because it has a 
lot of breaking changes.


For an instance anything that relies on HTTPServerRequest.path 
will break.


I'm aware that there has been added the "requestPath" 
property, but it's still a breaking change to all existing 
code that relies on the old "path" property. Especially when 
it's used to manipulate the path you receive.


Diamond cannot currently be used with latest release of 
vibe.d, because of this and it was relying on vibe.d with 
following dependency:


"vibe-d": "~>0.8.1"

0.8.2 should not be a breaking change, assuming you follow 
semantic versioning.


https://semver.org/


4. Major version zero (0.y.z) is for initial development. 
Anything may change at any time. The public API should not be 
considered stable.


0.x.Y should always be compatible with 0.x.Z without breaking 
changes.


Since it's MAJOR.MINOR.PATCH

This is a patch release 0.8.1 to 0.8.2 which means:

"PATCH version when you make backwards-compatible bug fixes."

Even a minor version should be backward-compatible.

"MINOR version when you add functionality in a 
backwards-compatible manner, and"


I'm all for deprecating said features, but plain removing them in 
a release like this is a breaking change and should at the very 
least be a minor version upgrade, but definitely not a patch.

Function signature testing with is expression.

[Alexandru Ermicioi via Digitalmars-d-learn]

Hi,

Have someone tried to test a function against a signature using 
is expression?


Suppose:

struct F {
static void foo(T)(T i, int o) {}
}

enum bool check(T) = is(F.foo!T == void function(Z, int), Z);

enum correct = check!int;


Upon running it will return false, though, by logic is expression 
could deduce that F.foo is conformat to function signature in 
check test.


It is interesting that it will not work with global functions as 
well:



void foo(int i, double d) {};
enum bool check = is(typeof(foo) == void function(int, double));


It will be as well evaluated to false.

So, the question is, is it I'm doing something wrong, that it 
doesn't work, or is it not implemented?
If not implemented, what simple and short alternatives are 
available?


Thanks.

Re: D client for ROS

[Johan Engelen via Digitalmars-d]

On Wednesday, 22 November 2017 at 22:16:12 UTC, thinwybk wrote:

On Wednesday, 22 November 2017 at 19:02:17 UTC, thinwybk wrote:

On Saturday, 29 July 2017 at 10:21:32 UTC, Johan Engelen wrote:

Hi all,
  Are there any robot folks out here that are working with 
ROS and would be able to work on creating a D client library 
for it?



a bit late... yes, I am working in robotics and I would be 
interrested in helping out. I know that other people visit ROS 
and D meetups in munich and could be interrested as well.




Have you considered to post on discourse.ros.org (client 
libraries) https://discourse.ros.org/c/client-libraries as 
well? You would propably get more response there.


Andrei thought it could be a good GSoC project.
It may take a bit of effort to define the project such that the D 
community at large can benefit from it. I'm thinking about 
possible additions to dub/other tool to support a more complex 
build setup like ROS is using; but perhaps it is not needed with 
D's more advanced capabilities in comparison to C++.


Shall we schedule a time for an online chat/discussion (slack, 
gitter, ...) to see how to proceed?  (and discuss tech things 
like ROS1 or ROS2, step-plan and minimum requirements, ...)


cheers,
  Johan

Re: Released vibe.d 0.8.2

[WebFreak001 via Digitalmars-d-announce]

On Sunday, 17 December 2017 at 12:52:57 UTC, bauss wrote:
This shouldn't have been released as 0.8.2, because it has a 
lot of breaking changes.


For an instance anything that relies on HTTPServerRequest.path 
will break.


I'm aware that there has been added the "requestPath" property, 
but it's still a breaking change to all existing code that 
relies on the old "path" property. Especially when it's used to 
manipulate the path you receive.


Diamond cannot currently be used with latest release of vibe.d, 
because of this and it was relying on vibe.d with following 
dependency:


"vibe-d": "~>0.8.1"

0.8.2 should not be a breaking change, assuming you follow 
semantic versioning.


https://semver.org/


4. Major version zero (0.y.z) is for initial development. 
Anything may change at any time. The public API should not be 
considered stable.

[Issue 18094] Crash on variadic arguments

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

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

anonymous4  changed:

   What|Removed |Added

   Keywords|wrong-code  |

--- Comment #1 from anonymous4  ---
Look like it prefers variadic overload. Is it intended?

--

Clarity about extern(Windows)/extern(System)

[Mike Parker via Digitalmars-d-learn]

For years now, I've been under the impression that the 
distinction between extern(Windows) and extern(System) actually 
mattered. I recall extern(System) was first added to the language 
to resolve this situation for C bindings:


version(Windows) extern(Windows):
else extern(C):

Which, or course, does not work. Yet, it's now been pointed out 
to me [1] that the documentation says the following [2]:


The Windows convention is distinct from the C convention only on 
Win32 platforms, where it is equivalent to the stdcall convention.


This implies that extern(Windows) and extern(System) behave the 
same way. My limited testing on a 64-bit Linux VM shows no 
problems when binding a C function as extern(C) or 
extern(Windows), and the disassembly looks the same.



[1]: https://github.com/Extrawurst/DerelictFmod/pull/3
[2]: https://dlang.org/spec/attribute.html#linkage

Re: Where is sleep()?

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

On Sunday, 17 December 2017 at 08:32:20 UTC, Ryan David Sheasby 
wrote:

What am I missing?


the official search is hard to use, so I made my own. When 
looking for something, try dpldocs.info/search_term


http://dpldocs.info/sleep

and here it pops right up.

[Issue 17938] Detect immutable variadic arguments

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

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18094

--

[Issue 18094] New: Crash on variadic arguments

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

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

  Issue ID: 18094
   Summary: Crash on variadic arguments
   Product: D
   Version: D2
  Hardware: x86_64
   URL: https://run.dlang.io/is/8LkLsm
OS: All
Status: NEW
  Keywords: wrong-code
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dfj1es...@sneakemail.com

int test1()
{
static immutable string[] optsldc=["a","a"];
Put(optsldc);
return 0;
}
void Put(string item)
{
}
void Put(in string[] items...)
{
assert(items.length!=0);
foreach(item;items)Put(item);
}
int main(string[] args)
{
return test1();
}

This code crashes when run.

--

[Issue 18089] AArch64: Need Quadruple float support in CTFE hashOf / core.internal.convert.parse

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

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

--- Comment #3 from Iain Buclaw  ---
So from a CTFE standpoint, its support cent/ucent, or support unions.

--

Re: Released vibe.d 0.8.2

[bauss via Digitalmars-d-announce]

This shouldn't have been released as 0.8.2, because it has a lot 
of breaking changes.


For an instance anything that relies on HTTPServerRequest.path 
will break.


I'm aware that there has been added the "requestPath" property, 
but it's still a breaking change to all existing code that relies 
on the old "path" property. Especially when it's used to 
manipulate the path you receive.


Diamond cannot currently be used with latest release of vibe.d, 
because of this and it was relying on vibe.d with following 
dependency:


"vibe-d": "~>0.8.1"

0.8.2 should not be a breaking change, assuming you follow 
semantic versioning.


https://semver.org/

Re: Passing anonymous enums as function parameters

[kerdemdemir via Digitalmars-d-learn]

What I meant with anonymous enums was:
https://dlang.org/spec/enum.html#anonymous_enums. Maybe I 
couldn't explain well but I believe D have anonymous enums. I am 
sorry I have forgotten to remove " :string" in my example from 
the "enum : string". Please stretch out ": string" part my 
problem is not related with that.


I am not sure if it is a good one but I found a solution for my 
problem


double ReturnCoolNess(U)( U enumVal )
{
  switch (enumVal)
  {
case KErdem:
{
return 0.0
}
case Ali:
{
return 100.0;   
}
case Salih:
{
return 100.0;   
}
// etc..
  }
}

ReturnCoolNess(KErdem); ---> Compiles


D does not have anonymous enums. Either you're declaring an 
enum which creates a new type and therefore has a name and a 
base type, or you're just creating manifest constants that 
don't create a new type. e.g.


enum MyEnum : string
{
a = "hello",
b = "foo",
c = "dog",
d = "cat"
}

vs

enum string a = "hello";
enum string b = "foo";
enum string c = "dog";
enum string d = "cat";

or

enum a = "hello";
enum b = "foo";
enum c = "dog";
enum d = "cat";

If you want a function to accept values that aren't tied to a 
specific enum, then just have the function take the base type.


Now, within sections of code, you can use the with statement to 
reduce how often you have to use the enum type's name, e.g.


with(MyEnum) switch(enumVal)
{
case a: { .. }
case b: { .. }
case c: { .. }
case d: { .. }
}

but you can't have an enum without a name or just choose not to 
use an enum's name. With how enums work in D, there's really no 
point in having them if you're not going to treat them as their 
own type or refer to them via the enum type's name. If that's 
what you want to do, then just create a bunch of manifest 
constants.


- Jonathan M Davis

What does rt/sections_elf_shared.d do? (Porting dmd to musl)

[Yuxuan Shui via Digitalmars-d]

I'm trying to get dmd and phobos working with musl. Right now I 
have a bootstrapped compiler built with musl, which seems to work 
fine. However user applications will segmentation fault before 
even reaches main.


I investigated a bit. Looks like musl is not happy with how 
druntime uses dlopen related functions. When a D library loads, 
it tries to call _d_dso_registry, which will try to get a handle 
of the library using dlopen. Meaning dlopen will be called on the 
library itself while it's still loading. This seems to break 
musl. Although this might also be a bug on musl side: it tries to 
call init functions even when RTLD_NOLOAD is passed to dlopen.


However, going through sections_elf_shared.d, it makes me feel 
it's doing some magic tricks with dl functions, but I don't know 
what for?


If my understand is correct, it's used to register TLS storage to 
GC. If that's the case, there must be simpler ways to do that.

Re: Does D have class' attributes like C#'s?

[SealabJaster via Digitalmars-d-learn]

On Saturday, 16 December 2017 at 19:57:30 UTC, Marc wrote:

Does D have something similar?


As others have said, D has UDAs.

An alternative to using __traits(getAttributes) is to use 
std.traits.getUDAs [1]


I've made a small example using std.traits.getUDAs, based off of 
your example. [2]


[1] https://dlang.org/library/std/traits/get_ud_as.html
[2] https://run.dlang.io/is/PTfEcw(I hope that link works)

Re: Passing anonymous enums as function parameters

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, December 17, 2017 11:49:58 kerdemdemir via Digitalmars-d-learn 
wrote:
> I have an enum statement :
>
> enum : string
> {
>  KErdem
>  Ali
>  Zafer
>  Salih
>  //etc...
> }
>
>
> I don't want to give a name to my enum class since I am accessing
> this variables very often.
>
> But I also have a function like:
>
> double ReturnCoolNess( /* Is there any way? */ enumVal )
> {
>switch (enumVal)
>{
>   case KErdem:
>   {
>   return 0.0
>   }
>   case Ali:
>   {
>   return 100.0;
>   }
>   case Salih:
>   {
>   return 100.0;
>   }
>  // etc..
>}
> }
>
> Is there any way I still keep my enum anonymous and be able to
> call functions with different enumarations. Or is there any other
> way to call named enums without type name ?

D does not have anonymous enums. Either you're declaring an enum which
creates a new type and therefore has a name and a base type, or you're just
creating manifest constants that don't create a new type. e.g.

enum MyEnum : string
{
a = "hello",
b = "foo",
c = "dog",
d = "cat"
}

vs

enum string a = "hello";
enum string b = "foo";
enum string c = "dog";
enum string d = "cat";

or

enum a = "hello";
enum b = "foo";
enum c = "dog";
enum d = "cat";

If you want a function to accept values that aren't tied to a specific enum,
then just have the function take the base type.

Now, within sections of code, you can use the with statement to reduce how
often you have to use the enum type's name, e.g.

with(MyEnum) switch(enumVal)
{
case a: { .. }
case b: { .. }
case c: { .. }
case d: { .. }
}

but you can't have an enum without a name or just choose not to use an
enum's name. With how enums work in D, there's really no point in having
them if you're not going to treat them as their own type or refer to them
via the enum type's name. If that's what you want to do, then just create a
bunch of manifest constants.

- Jonathan M Davis

Passing anonymous enums as function parameters

[kerdemdemir via Digitalmars-d-learn]

I have an enum statement :

enum : string
{
KErdem
Ali
Zafer
Salih
//etc...
}


I don't want to give a name to my enum class since I am accessing 
this variables very often.


But I also have a function like:

double ReturnCoolNess( /* Is there any way? */ enumVal )
{
  switch (enumVal)
  {
case KErdem:
{
return 0.0
}
case Ali:
{
return 100.0;   
}
case Salih:
{
return 100.0;   
}
// etc..
  }
}

Is there any way I still keep my enum anonymous and be able to 
call functions with different enumarations. Or is there any other 
way to call named enums without type name ?

[Issue 18093] [Reg 2.071] MSCOFF: dmd crashes when overriding a C++ method in a mixin template

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

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

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||ice, pull

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

--

Re: Lazily parse a JSON text file using stdx.data.json?

[WebFreak001 via Digitalmars-d]

On Sunday, 17 December 2017 at 04:34:22 UTC, David Gileadi wrote:
I'm a longtime fan of dlang, but haven't had a chance to do 
much in-depth dlang programming, and especially not range 
programming. Today I thought I'd use stdx.data.json to read 
from a text file. Since it's a somewhat large file, I thought 
I'd create a text range from the file and parse it that way. 
stdx.data.json has a great interface for lazily parsing text 
into JSON values, so all I had to do was turn a text file into 
a lazy range of UTF-8 chars that stdx.data.json's lexer could 
use. (In my best Clarkson voice:) How hard could it be?


[...]


uh I don't know about stdx.data.json but if you didn't manage to 
succeed yet, I know that asdf[1] works really well with streaming 
json. There is also an example how it works.


[1]: http://asdf.dub.pm

Re: Diamond Full-stack MVC / Template Engine - v2.5.4 Released!

[bauss via Digitalmars-d-announce]

These are the features that are upcoming for the next releases.

* Getting rid of deprecated feature usage with mysql-native.
* SEO API
* Soap/Webservice support

Diamond Full-stack MVC / Template Engine - v2.5.4 Released!

[bauss via Digitalmars-d-announce]

I'm happy to announce that Diamond v2.5.4 has just been released.

This release comes with the following features:

* Bug fixes
* Websocket support
* White-space support for multi-line i18n translations.
* Specialized routes (Can fetch resources from external, internal 
and local locations.)


Github: https://github.com/DiamondMVC/Diamond

DUB: http://code.dlang.org/packages/diamond

Thank you!

Re: Dub generate import files

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-12-17 02:32, Venkat wrote:
dmd has the -H and -Hd switches. Does dub have any setting to make it 
generate D interface files ?


Not that I know of, but you can create your own build type for that [1]

[1] http://code.dlang.org/package-format?lang=sdl#build-types

--
/Jacob Carlborg

Re: Does D have class' attributes like C#'s?

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-12-16 22:11, Marc wrote:

I can't "pack" an object, right? In C#, TextSize is a class and 256 is 
constructor's first argument. In D it's pretty much an array but I guess 
it's close enough. Thanks!


In D it's an tuple of basically anything that is known at compile time, 
values or types:


alias foo = int;

struct TextSize
{
int value;
}

int bar(int a) { return a; }

@(foo, 3, "asd", TextSize(256), bar(3))
class A {}

The following syntax is syntax sugar:

@TextSize(256)
class B {}

For:

@(TextSize(256))
class B {}

What's happening is that TextSize (all structs) has an implicit 
construct for all fields. An instance of TextSize is constructed at 
compile time and is used as a value in the UDA tuple.


The UDAs only exists during compile time (unless you explicitly save 
them somehow). Runtime reflection cannot be used, but compile time 
reflection can be used, using the "getAttribute" traits [1[


[1] https://dlang.org/spec/traits.html#getAttributes

--
/Jacob Carlborg

Re: Scope failure is not preventing application crush in case of uncaught exceptions

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, December 17, 2017 09:32:53 codephantom via Digitalmars-d-learn 
wrote:
> On Sunday, 17 December 2017 at 08:26:03 UTC, Jonathan M Davis
>
> wrote:
> > assert(0) does indeed turn into a HLT instruction in -release
> > mode (as does any assertion that's known to be false at compile
> > time). It's a special case intended for marking code that's
> > supposed to be unreachable. Without -release, failed assertions
> > throw AssertErrors, so they're Errors not Exceptions, though I
> > think that scope statements currently catch and then rethrow
> > Throwable rather than Exception, which is why AssertErrors
> > would be affected.
> >
> > - Jonathan M Davis
>
> It's a little confusing, because Andrei's book says that
> scope(failure) guarantees statement will be executed, if and only
> if the current scope is exited by throwing an 'exception'.
>
> One could *mistakingly* take that as meaning, throwing an object
> rooted in the 'Exception' subclass of Throwable.
>
> Of course assert actually throws an exception too, but it's a
> special kind of exception rooted in the 'Error' subclass of
> Throwable.
>
> Perhaps, to be clearer, Andrei's book should have said:
> scope(failure) guarantees statement will be executed, if and only
> if the current scope is exited by throwing an object that
> inherits from type Throwable. That would include, objects rooted
> in the 'Exception' subclass, as well as objects rooted in 'Error'
> subclass.
>
> In which case, there's no bug in that code. It's doing what it's
> meant to be doing.

Well, exception vs Exception can be confusing, but there is actually no
guarantee whatsoever spec-wise that scope statements work with Errors - the
same goes for any other clean-up code (such as destructors or finally
blocks). Some stuff like nothrow functions make it impossible, and Walter
has been adamant that trying to recover from an Error is an incredibly bad
idea and that programs in general are far better off exiting on an Error
than trying to do any recovery from it (since by definition, when an Error
is thrown, the program is in a buggy and unknown state). Given Walter's
stance on it, I'm honestly a bit surprised that Error is a Throwable rather
than being designed to just immediately kill the program right then an
there, though under _rare_ circumstances, when you know exactly what you're
doing aand catch the Error pretty much at the point it was thrown, you can
get away with it for certain types of Errors like OutOfMemoryError.

However, at some point a while back, someone went into druntime and made it
so that destructors, scope statements, and finally blocks run as much as
possible when Errors are thrown - which isn't always but is a lot of the
time. So, on some level, right now, clean-up code does get run when an Error
is thrown, but it's not guaranteed and can't be guaranteed. Given Walter's
stance on it, I'm surprised that druntime has never been changed so that it
only does clean-up on Exceptions, but for now at least, we have a bit of a
halfway mess with how Errors are handled.

Basically, code shouldn't be relying on Errors either triggering or not
triggering clean-up code such as scope statements. They are only guaranteed
to run when an Exception is thrown and may or may not run when any other
kind of Throwable is thrown.

- Jonathan M Davis

[Issue 18093] New: [Reg 2.071] MSCOFF: dmd crashes when overriding a C++ method in a mixin template

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

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

  Issue ID: 18093
   Summary: [Reg 2.071] MSCOFF: dmd crashes when overriding a C++
method in a mixin template
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: r.sagita...@gmx.de

When building dmd itself with -m64 or -m32mscoff on windows, dmd crashes,
current master with this stack trace:

DMD v2.077.1
 DEBUG

object.Error@(0): Access Violation

0x00494DA6 in FuncDeclaration at c:\s\d\rainers\dmd\src\dmd\func.d(618)
0x004579F5 in DsymbolSemanticVisitor at
c:\s\d\rainers\dmd\src\dmd\dsymbolsem.d(4512)
0x0045864E in DsymbolSemanticVisitor at
c:\s\d\rainers\dmd\src\dmd\dsymbolsem.d(4858)
0x00497DA9 in FuncDeclaration at c:\s\d\rainers\dmd\src\dmd\func.d(2276)
...

It builds just fine with -m32. Dustmite reduces this to

//

struct ASTCodegen {}

extern (C++) class ParseTimeVisitor(AST)
{
void visit() {}
}
template ParseVisitMethods(AST)
{
override void visit() {}
}

class GenericTransitiveVisitor(AST) : ParseTimeVisitor!AST
{
mixin ParseVisitMethods!AST;
}

alias SemanticTimeTransitiveVisitor = GenericTransitiveVisitor!ASTCodegen;

//

This crashes starting with dmd 2.071, but produces a correct error message
about mismatched override (as -m32 does for all versions).

Adding extern(C++) to the override method in ParseVisitMethods makes it compile
in all versions and targets.

--

Re: Scope failure is not preventing application crush in case of uncaught exceptions

[Anonymouse via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 08:10:06 UTC, codephantom wrote:

On Sunday, 17 December 2017 at 00:10:27 UTC, Anonymouse wrote:
If you return inside a scopeguard though, the exception (or 
error!) is swallowed. https://run.dlang.io/is/GEtQ6D


The scope guard will not 'swallow' it, if you use -release mode.

Which suggests to me, that assert(0) operates differently when 
'not' using -release mode.


My 'guess' is, that release mode issues a halt instruction, 
whereas in non-release mode it is just an exception like any 
other exception.


Apologies. I chose assert(0) just to show that it catches Errors 
too, so just replace it with throw new Exception and it behaves 
the same without opening that can of worms.

Re: Lazily parse a JSON text file using stdx.data.json?

[Jonathan M Davis via Digitalmars-d]

On Saturday, December 16, 2017 21:34:22 David Gileadi via Digitalmars-d 
wrote:
> I'm a longtime fan of dlang, but haven't had a chance to do much
> in-depth dlang programming, and especially not range programming. Today
> I thought I'd use stdx.data.json to read from a text file. Since it's a
> somewhat large file, I thought I'd create a text range from the file and
> parse it that way. stdx.data.json has a great interface for lazily
> parsing text into JSON values, so all I had to do was turn a text file
> into a lazy range of UTF-8 chars that stdx.data.json's lexer could use.
> (In my best Clarkson voice:) How hard could it be?
>
> Several hours later, I've finally given up and am just reading the whole
> file into a string. There may be a magic incantation I could use to make
> it work, but I can't find it, and frankly I can't see why I should need
> an incantation in the first place. It really ought to just be a method
> of std.stdio.File.
>
> Apparently some of the complexity is caused by autodecoding (e.g. joiner
> returns a range of dchar from char ranges), and some of the fault may be
> in stdx.data.json, but either way I'm surprised that I couldn't do it.
> This is the kind of thing I expected to be ground level stuff.

I don't know what problems specifically you were hitting, but a lot of
range-based stuff (especially parsing) requires forward ranges so that there
can be some amount of lookahead (having just a basic input range can be
incredibly restrictive), and forward ranges and lazily reading from a file
don't tend to go together very well, because it tends to require allocating
buffers that then have to be copied on save. It gets to be rather difficult
to do it efficiently. std.stdio.File does support lazily reading in a file,
which works well with foreach, but if you're trying to process the entire
file as a range, it's usually just way easier to read in the entire file at
once and operate on it as a dynamic array. The option halfway in between is
to use std.mmfile so that the file gets treated as a dynamic array but the
OS is reading it in piecemeal for you. If I were seriously looking at
reading in a file lazily as a forward range, I'd look at
http://code.dlang.org/packages/iopipe, though as I understand it, it's very
much a work in progress.

As for auto-decoding, yeah, it sucks. You can work around it with stuff like
std.utf.byCodeUnit, but auto-decoding is a problem all around, and it's one
that we're likely stuck with, because unfortunately, we haven't found a way
to remove it without breaking everything.

- Jonathan M Davis

Re: Where is sleep()?

[codephantom via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 08:32:20 UTC, Ryan David Sheasby 
wrote:
Hey guys. First time poster here. I've searched high and low 
but can't seem to find a simple sleep/delay/wait/pause function 
in the core or in phobos. The most recent information I can 
find about it is this forum post from 12 years ago: 
http://forum.dlang.org/thread/avr99b$b8j$2...@digitaldaemon.com In 
which they suggest using std.c.time which is now depreciated 
and seems to have been replaced by core.stdc.time which doesn't 
have any sleep functions... What am I missing?


// --

import std.stdio;
import core.thread;

void main()
{
int waitTime = 5;

writeln("Waiting ", waitTime, " seconds...");
Thread.sleep(waitTime.seconds);
writeln("Done waiting!");
}
// --

Re: Scope failure is not preventing application crush in case of uncaught exceptions

[codephantom via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 08:26:03 UTC, Jonathan M Davis 
wrote:
assert(0) does indeed turn into a HLT instruction in -release 
mode (as does any assertion that's known to be false at compile 
time). It's a special case intended for marking code that's 
supposed to be unreachable. Without -release, failed assertions 
throw AssertErrors, so they're Errors not Exceptions, though I 
think that scope statements currently catch and then rethrow 
Throwable rather than Exception, which is why AssertErrors 
would be affected.


- Jonathan M Davis



It's a little confusing, because Andrei's book says that 
scope(failure) guarantees statement will be executed, if and only 
if the current scope is exited by throwing an 'exception'.


One could *mistakingly* take that as meaning, throwing an object 
rooted in the 'Exception' subclass of Throwable.


Of course assert actually throws an exception too, but it's a 
special kind of exception rooted in the 'Error' subclass of 
Throwable.


Perhaps, to be clearer, Andrei's book should have said: 
scope(failure) guarantees statement will be executed, if and only 
if the current scope is exited by throwing an object that 
inherits from type Throwable. That would include, objects rooted 
in the 'Exception' subclass, as well as objects rooted in 'Error' 
subclass.


In which case, there's no bug in that code. It's doing what it's 
meant to be doing.

Re: Where is sleep()?

[Ryan David Sheasby via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 08:40:53 UTC, rikki cattermole 
wrote:

On 17/12/2017 8:32 AM, Ryan David Sheasby wrote:
Hey guys. First time poster here. I've searched high and low 
but can't seem to find a simple sleep/delay/wait/pause 
function in the core or in phobos. The most recent information 
I can find about it is this forum post from 12 years ago: 
http://forum.dlang.org/thread/avr99b$b8j$2...@digitaldaemon.com 
In which they suggest using std.c.time which is now 
depreciated and seems to have been replaced by core.stdc.time 
which doesn't have any sleep functions... What am I missing?


That link is not relevant to D.

https://dlang.org/phobos/core_thread.html#.Thread.sleep


Crap sorry you're right. I pasted the wrong link. This is the one 
I was talking about: 
http://forum.dlang.org/thread/diuepu$2ebg$1...@digitaldaemon.com

Re: Where is sleep()?

[rikki cattermole via Digitalmars-d-learn]

On 17/12/2017 8:32 AM, Ryan David Sheasby wrote:
Hey guys. First time poster here. I've searched high and low but can't 
seem to find a simple sleep/delay/wait/pause function in the core or in 
phobos. The most recent information I can find about it is this forum 
post from 12 years ago: 
http://forum.dlang.org/thread/avr99b$b8j$2...@digitaldaemon.com In which 
they suggest using std.c.time which is now depreciated and seems to have 
been replaced by core.stdc.time which doesn't have any sleep 
functions... What am I missing?


That link is not relevant to D.

https://dlang.org/phobos/core_thread.html#.Thread.sleep

[Issue 18089] AArch64: Need Quadruple float support in CTFE hashOf / core.internal.convert.parse

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

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

--- Comment #2 from Johannes Pfau  ---
Yes, it's a more advanced issue. From a cursory look I'd say the algorithm /
approach should work for quadruple floats as well. However, every temporary
variable has to be checked whether the data type is large enough for quadruple
floats. I think this is the case for everything except for the mantissa, which
does not fit into an ulong. Maybe we can simply use a ulong[2] in the Float
struct, then fix shiftrRound.

However, I think there were efforts in phobos to introduce a generic
FloatTraits type which may also be applicable here and avoids some code
duplication? It is also quite sad, that 600 lines in the convert module are
required for CTFE, whereas a few lines of union/cast code suffices for
runtime

--

Where is sleep()?

[Ryan David Sheasby via Digitalmars-d-learn]

Hey guys. First time poster here. I've searched high and low but 
can't seem to find a simple sleep/delay/wait/pause function in 
the core or in phobos. The most recent information I can find 
about it is this forum post from 12 years ago: 
http://forum.dlang.org/thread/avr99b$b8j$2...@digitaldaemon.com In 
which they suggest using std.c.time which is now depreciated and 
seems to have been replaced by core.stdc.time which doesn't have 
any sleep functions... What am I missing?

Re: Scope failure is not preventing application crush in case of uncaught exceptions

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, December 17, 2017 08:10:06 codephantom via Digitalmars-d-learn 
wrote:
> On Sunday, 17 December 2017 at 00:10:27 UTC, Anonymouse wrote:
> > If you return inside a scopeguard though, the exception (or
> > error!) is swallowed. https://run.dlang.io/is/GEtQ6D
>
> The scope guard will not 'swallow' it, if you use -release mode.
>
> Which suggests to me, that assert(0) operates differently when
> 'not' using -release mode.
>
> My 'guess' is, that release mode issues a halt instruction,
> whereas in non-release mode it is just an exception like any
> other exception.

assert(0) does indeed turn into a HLT instruction in -release mode (as does
any assertion that's known to be false at compile time). It's a special case
intended for marking code that's supposed to be unreachable. Without
-release, failed assertions throw AssertErrors, so they're Errors not
Exceptions, though I think that scope statements currently catch and then
rethrow Throwable rather than Exception, which is why AssertErrors would be
affected.

- Jonathan M Davis

Re: Scope failure is not preventing application crush in case of uncaught exceptions

[codephantom via Digitalmars-d-learn]

On Sunday, 17 December 2017 at 00:10:27 UTC, Anonymouse wrote:
If you return inside a scopeguard though, the exception (or 
error!) is swallowed. https://run.dlang.io/is/GEtQ6D


The scope guard will not 'swallow' it, if you use -release mode.

Which suggests to me, that assert(0) operates differently when 
'not' using -release mode.


My 'guess' is, that release mode issues a halt instruction, 
whereas in non-release mode it is just an exception like any 
other exception.