How to debug GC leak
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: How to pack a struct to a ubyte[] in a more "The D way" style ?
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 ?
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
How to pack a struct to a ubyte[] in a more "The D way" style ?
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: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible
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
Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible
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
Re: Fold in Parallelism
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
Re: Passing anonymous enums as function parameters
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
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: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible
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: Where is sleep()?
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.
Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible
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.
Re: Linker error since upgrade to DMD 2.077.1: fatal error C1905: Front end and back end not compatible
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?
Re: Where is sleep()?
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.
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: Where is sleep()?
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
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
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
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
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.
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
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.
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
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
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?
Function signature testing with is expression.
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.
Clarity about extern(Windows)/extern(System)
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()?
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.
Re: Passing anonymous enums as function parameters
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
Re: Does D have class' attributes like C#'s?
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
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
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 ?
Re: Dub generate import files
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?
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
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
Re: Scope failure is not preventing application crush in case of uncaught exceptions
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: Where is sleep()?
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
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()?
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()?
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
Where is sleep()?
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
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
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.
