Re: new int[]
On Wednesday, January 10, 2018 22:50:22 Nathan S. via Digitalmars-d-learn
wrote:
> On Wednesday, 10 January 2018 at 22:46:30 UTC, ag0aep6g wrote:
> > If I understand correctly, the goal is to have the `int[]`
> > itself on the GC heap.
>
> The code
>
> void main(string[] args) @nogc
> {
> int[] x = [1, 2, 3];
> }
>
>
> won't compile, because "array literal in @nogc function 'D main'
> may cause GC allocation". But "may" isn't the same as "will".
> What determines it? That's a kind of goofy error message now that
> I think about it.
If there are cases where it doesn't allocate, it probably depends on
compiler optimizations. If it's able to determine that x doesn't escape the
function, it might allocate it on the stack. I don't know. But @nogc is
about guaranteeing that it _won't_ allocate using the GC, so "may" is enough
to make it illegal for @nogc. It's also possible that this particular case
will always allocate, but the error message is also used in other code where
it's not guaranteed to allocate. Recently, in a discussion on improving
error messages Walter did mention that there are cases in the compiler where
the same piece of code generates errors for a variety of cases and that it
would probably be better to make some of those less generic so that the
error messages can be more specific.
- Jonathan M Davis
Re: new int[]
On Wednesday, 10 January 2018 at 22:46:30 UTC, ag0aep6g wrote:
If I understand correctly, the goal is to have the `int[]`
itself on the GC heap.
That's correct.
You can make an `int[][]` with one element, and then take the
address of that element:
void main()
{
int[]* x = &[[1, 2, 3]][0];
int[]* x2 = [[1, 2, 3]].ptr; /* same */
}
That's an interesting solution. I'm not sure which one I prefer,
the wrapper or this one. Still... I feel like the language should
just allow allocating an array itself on the GC heap :(
Re: new int[]
On Wednesday, 10 January 2018 at 22:48:48 UTC, Adam D. Ruppe wrote: General word of warning: if you pass it to C and the C function holds on to that pointer for any reason beyond its immediate execution, you could be looking at a problem because the D GC can't see C function memory and may free it after the function returns. Thanks! I don't think it applies to me, because the void* pointer is reachable from a root pointer on the D side.
Re: new int[]
On 01/10/2018 02:46 PM, ag0aep6g wrote:
On 01/10/2018 11:35 PM, Luís Marques wrote:
Due to compatibility with some C code, I basically need to do this:
struct Wrapper
{
int[] x;
}
void main()
{
void* ctxptr = new Wrapper([1, 2, 3]);
auto context = cast(Wrapper*) ctxptr;
writeln(context.x);
}
How can I do that without the wrapper? `new int[]` isn't supported,
even though that's exactly what I want.
If I understand correctly, the goal is to have the `int[]` itself on the
GC heap. You can make an `int[][]` with one element, and then take the
address of that element:
void main()
{
int[]* x = &[[1, 2, 3]][0];
int[]* x2 = [[1, 2, 3]].ptr; /* same */
}
I was writing the same for a no-initial-value version:
void main() {
void *v = cast(void*)((new int[][](1)).ptr);
*(cast(int[]*)v) ~= 42;
}
I hope it's correct. :o)
Ali
Re: new int[]
On Wednesday, 10 January 2018 at 22:46:30 UTC, ag0aep6g wrote:
If I understand correctly, the goal is to have the `int[]`
itself on the GC heap.
The code
void main(string[] args) @nogc
{
int[] x = [1, 2, 3];
}
won't compile, because "array literal in @nogc function 'D main'
may cause GC allocation". But "may" isn't the same as "will".
What determines it? That's a kind of goofy error message now that
I think about it.
Re: new int[]
On Wednesday, 10 January 2018 at 22:46:30 UTC, ag0aep6g wrote: If I understand correctly, the goal is to have the `int[]` itself on the GC heap. General word of warning: if you pass it to C and the C function holds on to that pointer for any reason beyond its immediate execution, you could be looking at a problem because the D GC can't see C function memory and may free it after the function returns.
Re: new int[]
On 01/10/2018 11:35 PM, Luís Marques wrote:
Due to compatibility with some C code, I basically need to do this:
struct Wrapper
{
int[] x;
}
void main()
{
void* ctxptr = new Wrapper([1, 2, 3]);
auto context = cast(Wrapper*) ctxptr;
writeln(context.x);
}
How can I do that without the wrapper? `new int[]` isn't supported, even
though that's exactly what I want.
If I understand correctly, the goal is to have the `int[]` itself on the
GC heap. You can make an `int[][]` with one element, and then take the
address of that element:
void main()
{
int[]* x = &[[1, 2, 3]][0];
int[]* x2 = [[1, 2, 3]].ptr; /* same */
}
Re: new int[]
Is there any problem with:
import std.stdio;
void main(string[] args)
{
int[] x = [1, 2, 3];
writeln(x);
}
https://run.dlang.io/is/CliWcz
Re: new int[]
On Wednesday, 10 January 2018 at 22:35:01 UTC, Luís Marques wrote: How can I do that without the wrapper? `new int[]` isn't supported, even though that's exactly what I want. Just to be extra clear: I really do want a normal D slice, it can't be a fixed-length array.
new int[]
Due to compatibility with some C code, I basically need to do
this:
struct Wrapper
{
int[] x;
}
void main()
{
void* ctxptr = new Wrapper([1, 2, 3]);
auto context = cast(Wrapper*) ctxptr;
writeln(context.x);
}
How can I do that without the wrapper? `new int[]` isn't
supported, even though that's exactly what I want.
Re: invalid or corrupt file: duplicate COMDAT / Previous Definition Different
On Wednesday, 10 January 2018 at 20:19:50 UTC, Benjamin Thaut wrote: Am 10.01.2018 um 20:32 schrieb Anonymouse: I don't have a reduced testcase yet. I figured I'd ask if it's something known before making the effort. Are you by any chance mixing debug and release builds? Or are the -version specifiers different when compiling the various parts of your program? Check your compiler flags and ansure that they are the same over your entire build process. Especiall -debug -relase -inline -O -version Admittedly I am alternating between building debug and unittest builds, but I'm only using dub, no separate compilation. I have limited control of the version specifiers other than through the build configurations, so there's not a whole lot to mix. $ dub clean Cleaning package at C:\cygwin\home\zorael\src\kameloso... $ dub build -c cygwin -a x86_64 Performing "debug" build using dmd for x86_64. kameloso 1.0.0-beta.2+commit.57.g90fdd1d: building configuration "cygwin"... Linking... kameloso.obj : fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '_D8kameloso7plugins6common8BotRegex6__ctorMFNcxEQBuQBoQBj10NickPolicyS3std5regex8internal2ir__T5RegexTaZQjZSQEcQDwQDrQDn' Error: linker exited with status 1179 dmd failed with exit code 1179. None of the (version specifiers in the) build configurations I have touch upon the part of the fairly innocent code mentioned in the error message, if I'm reading it right. (https://github.com/zorael/kameloso/blob/c00ca4489e39348bd4b1678c95c1b12636df307c/source/kameloso/plugins/common.d#L424)
Re: invalid or corrupt file: duplicate COMDAT / Previous Definition Different
On Wednesday, 10 January 2018 at 19:32:28 UTC, Anonymouse wrote: /usr/bin/ld: Warning: size of symbol I think your case is this bug: https://issues.dlang.org/show_bug.cgi?id=15324 Another COMDAT error is: https://issues.dlang.org/show_bug.cgi?id=16687
Re: TransitiveBaseTypeTuple doesn't seemed to print the symbols as well.
On Wednesday, 10 January 2018 at 20:38:20 UTC, 12345swordy wrote: You know a equivalent template that does that? No, though you could just AliasSeq!(D, TransitiveBaseTypeTuple!D) and make it yourself. Though note that __traits(allMembers, D) already includes all members, including those from base classes too, so you might just want to use that.
Re: TransitiveBaseTypeTuple doesn't seemed to print the symbols as well.
On Wednesday, 10 January 2018 at 19:26:58 UTC, Adam D. Ruppe wrote: On Wednesday, 10 January 2018 at 19:07:46 UTC, 12345swordy wrote: I noticed, can't fix it cause it won't let me edit it. OK, I'd just use foreach there anyway tho (then it actually builds!). But, hopefully once you get it running, you'll see that the base type tuple just gives the bases: it will print two lines, one for the base class Object and one for your interface A. Neither of them have constructors! It won't print the class D itself You know a equivalent template that does that?
Re: invalid or corrupt file: duplicate COMDAT / Previous Definition Different
Am 10.01.2018 um 20:32 schrieb Anonymouse: I don't have a reduced testcase yet. I figured I'd ask if it's something known before making the effort. Are you by any chance mixing debug and release builds? Or are the -version specifiers different when compiling the various parts of your program? Check your compiler flags and ansure that they are the same over your entire build process. Especiall -debug -relase -inline -O -version -- Kind Regards Benjamin Thaut
Re: Error: out of memory
On Wednesday, 10 January 2018 at 19:21:21 UTC, Adam D. Ruppe wrote: On Wednesday, 10 January 2018 at 19:15:00 UTC, Anonymouse wrote: I don't see a 64 bit release though... might have to try to build it yourself from source using visual studio. It's a long time I don't understand why there's not a 64bit distribution... (along with a debug build of rt/phobos, btw) /Paolo
Re: Error: out of memory
On Wed, Jan 10, 2018 at 07:21:21PM +, Adam D. Ruppe via Digitalmars-d-learn wrote: [...] > (and ugh dmd REALLY needs to get its memory consumption under control! > maybe just enabling the GC would help sometimes.) Yeah, no kidding! Recently I also ran into trouble with dmd's memory consumption competing with Firefox, another big, fat memory hog. I had to kill the Firefox process just so I have enough free RAM for dmd not to bail out in the middle of compilation. While the latest D motto seems to be fast, fast, and faster, fast does you no good if you can't even finish compilation in the first place. We need to have an option to turn on the GC and/or otherwise push dmd toward the memory end of the speed/memory tradeoff, instead of being stuck up fast creek without a memory paddle. T -- Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin
Re: Error: out of memory
On Wednesday, 10 January 2018 at 19:21:21 UTC, Adam D. Ruppe wrote: On Wednesday, 10 January 2018 at 19:15:00 UTC, Anonymouse wrote: I want to test it on a Windows 10 PC now but compilation with dmd (2.078.1) fails, both with --arch x86 and x86_64. LDC works, but it easily takes twice the time to build. In both cases, it is running a 32 bit dmd, just generating 64 bit code. I don't see a 64 bit release though... might have to try to build it yourself from source using visual studio. (and ugh dmd REALLY needs to get its memory consumption under control! maybe just enabling the GC would help sometimes.) Ugh, okay. Thanks, I'll try that.
invalid or corrupt file: duplicate COMDAT / Previous Definition Different
I haven't been testing my project on Windows for a while, and on top of having issues with out of memory errors when unittesting I see I can't build it normally either. dmd is 2.078.0. $ dub build -c cygwin -a x86_64 Performing "debug" build using dmd for x86_64. kameloso 1.0.0-beta.2+commit.57.g90fdd1d: building configuration "cygwin"... Linking... kameloso.obj : fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '_D8kameloso7plugins6common8BotRegex6__ctorMFNcxEQBuQBoQBj10NickPolicyS3std5regex8internal2ir__T5RegexTaZQjZSQEcQDwQDrQDn' Error: linker exited with status 1179 dmd failed with exit code 1179. $ dub build -c cygwin Performing "debug" build using dmd for x86. kameloso 1.0.0-beta.2+commit.57.g90fdd1d: building configuration "cygwin"... Linking... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html .dub\build\cygwin-debug-windows-x86-dmd_2078-270D5D6B34387418CFDA6A068E7A60D9\kameloso.obj(kameloso) Offset 7A92EH Record Type 00C3 Error 1: Previous Definition Different : _D8kameloso7plugins6common8BotRegex6__ctorMFNcxEQBuQBoQBj10NickPolicyS3std5regex8internal2ir__T5RegexTaZQjZSQEcQDwQDrQDn .dub\build\cygwin-debug-windows-x86-dmd_2078-270D5D6B34387418CFDA6A068E7A60D9\kameloso.obj(kameloso) Offset 7AE18H Record Type 00C3 Error 1: Previous Definition Different : _D8kameloso7plugins6common8BotRegex6__ctorMFNcS3std5regex8internal2ir__T5RegexTaZQjZSQDfQCzQCuQCq Error: linker exited with status 2 dmd failed with exit code 2. LDC 1.7.0 builds just fine. There are similar error messages when compiling on linux, but they don't error out (linking succeeds despite them). /usr/bin/ld: Warning: size of symbol `_D8kameloso7plugins6common8BotRegex6__ctorMFNcxEQBuQBoQBj10NickPolicyS3std5regex8internal2ir__T5RegexTaZQjZSQEcQDwQDrQDn' changed from 46 in .dub/build/posix-debug-linux.posix-x86_64-dmd_2078-8E23DC2771FEB27EF0FE1CC8F3984CAA/kameloso.o to 49 in .dub/build/posix-debug-linux.posix-x86_64-dmd_2078-8E23DC2771FEB27EF0FE1CC8F3984CAA/kameloso.o /usr/bin/ld: Warning: size of symbol `_D8kameloso7plugins6common8BotRegex6__ctorMFNcS3std5regex8internal2ir__T5RegexTaZQjZSQDfQCzQCuQCq' changed from 40 in .dub/build/posix-debug-linux.posix-x86_64-dmd_2078-8E23DC2771FEB27EF0FE1CC8F3984CAA/kameloso.o to 43 in .dub/build/posix-debug-linux.posix-x86_64-dmd_2078-8E23DC2771FEB27EF0FE1CC8F3984CAA/kameloso.o I don't have a reduced testcase yet. I figured I'd ask if it's something known before making the effort.
Re: TransitiveBaseTypeTuple doesn't seemed to print the symbols as well.
On Wednesday, 10 January 2018 at 19:07:46 UTC, 12345swordy wrote: I noticed, can't fix it cause it won't let me edit it. OK, I'd just use foreach there anyway tho (then it actually builds!). But, hopefully once you get it running, you'll see that the base type tuple just gives the bases: it will print two lines, one for the base class Object and one for your interface A. Neither of them have constructors! It won't print the class D itself
Re: Error: out of memory
On Wednesday, 10 January 2018 at 19:15:00 UTC, Anonymouse wrote: I've been building and testing my project on linux, juggling the ~5GB+ RAM needed to actually compile, but it's been working. I want to test it on a Windows 10 PC now but compilation with dmd (2.078.1) That's naturally supposed to be 2.078.0.
Re: Error: out of memory
On Wednesday, 10 January 2018 at 19:15:00 UTC, Anonymouse wrote: I want to test it on a Windows 10 PC now but compilation with dmd (2.078.1) fails, both with --arch x86 and x86_64. LDC works, but it easily takes twice the time to build. In both cases, it is running a 32 bit dmd, just generating 64 bit code. I don't see a 64 bit release though... might have to try to build it yourself from source using visual studio. (and ugh dmd REALLY needs to get its memory consumption under control! maybe just enabling the GC would help sometimes.)
Error: out of memory
I've been building and testing my project on linux, juggling the ~5GB+ RAM needed to actually compile, but it's been working. I want to test it on a Windows 10 PC now but compilation with dmd (2.078.1) fails, both with --arch x86 and x86_64. LDC works, but it easily takes twice the time to build. $ dub test Running custom 'unittest' configuration. Performing "unittest" build using dmd for x86. requests 0.6.0: target for configuration "std" is up to date. kameloso 1.0.0-beta.2+commit.56.g8ecd737: building configuration "unittest"... [... deprecation spam ...] Error: out of memory dmd failed with exit code 1. The machine has 32 gigabytes of memory[1], so I don't believe that for a second. Any ideas? [1]: https://i.imgur.com/l5L6BIF.png
Re: TransitiveBaseTypeTuple doesn't seemed to print the symbols as well.
On Wednesday, 10 January 2018 at 18:45:17 UTC, Adam D. Ruppe
wrote:
On Wednesday, 10 January 2018 at 18:31:17 UTC, 12345swordy
wrote:
for(int x = 0; x < TL.length; x++)
{
auto b = [__traits(allMembers, TL[0])];
Simple mistake there...
I noticed, can't fix it cause it won't let me edit it.
This auto b = [__traits(allMembers, TL[0])];
is meant to be auto b = [__traits(allMembers, TL[x])];
Re: Rvalue references
On 1/10/18 12:59 PM, Dgame wrote: On Wednesday, 10 January 2018 at 14:41:21 UTC, Steven Schveighoffer wrote: On 1/10/18 3:08 AM, Dgame wrote: On Wednesday, 10 January 2018 at 01:56:02 UTC, Steven Schveighoffer wrote: But current auto ref is what we have, so I would recommend using it. I would recommend to ignore auto ref for rvalue references. It generates 2^N functions where N is the amount of auto ref parameters. That the most awful template bloat I've ever seen. It only generates 2^N functions if you call it 2^N different ways. Most of the time you call it the same way. If that would be true we wouldn't need auto ref at all. The author of the function may not be the one calling it, so he doesn't know the way you like to call it. All I'm saying is to think about that your 2^N prediction requires 2^N lines of code, all calling it different ways. It's not likely to happen. -Steve
Re: TransitiveBaseTypeTuple doesn't seemed to print the symbols as well.
On Wednesday, 10 January 2018 at 18:31:17 UTC, 12345swordy wrote:
for(int x = 0; x < TL.length; x++)
{
auto b = [__traits(allMembers, TL[0])];
Simple mistake there...
TransitiveBaseTypeTuple doesn't seemed to print the symbols as well.
I expect ["__ctor", "__dtor", "toString", "toHash", "opCmp",
"opEquals"], instead I got ["toString", "toHash", "opCmp",
"opEquals", "Monitor", "factory"]
Care anyone explain why it is?
Source is the following:
import std.stdio;
import std.traits;
interface A
{
}
class D : A
{
this()
{
}
~this()
{
}
}
void main()
{
alias TL = TransitiveBaseTypeTuple!D;
for(int x = 0; x < TL.length; x++)
{
auto b = [__traits(allMembers, TL[0])];
writeln(b);
}
}
Re: Storing struct in a array
On Tuesday, 9 January 2018 at 19:05:48 UTC, thedeemon wrote:
On Tuesday, 9 January 2018 at 18:09:58 UTC, Vino wrote:
It is possible to store struct in a array ans use the same
in csvReader
Sure, you can just pass the type of your struct to csvReader:
Array!T1 T1s;
reader(fName, T1s); // pass the array Type as a function
parameter
First you write a template function that takes an array of some
generic type and fills it with records from CSV file:
void readData(DataType)(string fname, ref Array!DataType arr) {
foreach (record; fname.readText.csvReader!DataType('\t')) {
arr ~= record;
}
}
Then you can use it in your main program with different types:
struct S1 { string name; string value; int other; }
struct S2 { int a; string b; }
void main () {
...
if (someCondition) {
Array!S1 arr1;
readData("data1.csv", arr1);
} else {
Array!S2 arr2;
readData("data2.csv", arr2);
}
}
A little advice. Kindly pause and spend an evening reading this
book:
http://ddili.org/ders/d.en/
Currently your code pieces look like a soup produced by someone
who still confuses variables and types, and lacks basic
programming skills. Read the book, don't rush with writing
broken code.
Hi Deemon,
I agree that my code is broken code and I am a Newbie in the
world of programming, the confusion begin when i started writing
the second module, and now i was able to find the issue, and the
real requirement. The requirement is as below.
Program: The below program works.
auto reader(MyStruct) (File fname, auto ref MyStruct st) {
alias ColumnTypes = AliasSeq!(MyStruct);
foreach (record;
fname.byLineCopy().joiner("\n").csvReader!(Tuple!ColumnTypes)(null)) {
writeln(record[0], record[1], record[2]);
}
void main () {
auto fname =
File("C:\\Users\\bheev1\\Desktop\\Current\\Script\\Others\\Table2.csv");
auto Table = baseName(stripExtension(fname));
struct S1 { string Name; string Country; int Age; }
S1 Table1s;
reader(File(fname), join([Table, "1s"]));
}
The requirement is as below
The function reader should store the data in column wise Array
and return the same.
Array!has to be taken from the header data as the CSV file has header
Name, Country, Age using records.header)
e.g
Array!string Name; (records.header[0]);
Array!string Country;(records.header[1]);
Array!string Age;(records.header[2]);
and return the above arrays
From,
Vino.B
Re: Is there a way to get this associative array initialization to work?
On 2018-01-10 17:29, Steven Schveighoffer wrote:
Right, but it doesn't work in variable declarations if that variable is
part of an associative array.
In other words:
struct S
{
int x;
}
struct T
{
S s;
}
T t = {s: {x: 1}}; // nesting works here
S[] arr = [{x: 1}, {x:2}]; // and here
S[string] aa = ["first": {x: 1}, "second": {x: 2}]; // but not here???
Aha, I see. Didn't expect any of those to work.
--
/Jacob Carlborg
Re: Rvalue references
On Wednesday, 10 January 2018 at 14:41:21 UTC, Steven Schveighoffer wrote: On 1/10/18 3:08 AM, Dgame wrote: On Wednesday, 10 January 2018 at 01:56:02 UTC, Steven Schveighoffer wrote: But current auto ref is what we have, so I would recommend using it. I would recommend to ignore auto ref for rvalue references. It generates 2^N functions where N is the amount of auto ref parameters. That the most awful template bloat I've ever seen. It only generates 2^N functions if you call it 2^N different ways. Most of the time you call it the same way. -Steve If that would be true we wouldn't need auto ref at all.
Re: Is there a way to get this associative array initialization to work?
On 1/10/18 10:11 AM, Jacob Carlborg wrote:
On 2018-01-10 00:19, Steven Schveighoffer wrote:
https://issues.dlang.org/buglist.cgi?list_id=218715=not%20an%20associative%20array%20initializer_type=allwordssubstr_format=advanced=---
Note, I think you need at least Sound.SOUND_EFFECT, etc.
This bug looks particularly relevant:
https://issues.dlang.org/show_bug.cgi?id=11221
I think it should really work.
It's not just in associative arrays it doesn't work. It basically only
works in variables declarations:
https://issues.dlang.org/show_bug.cgi?id=15692
Right, but it doesn't work in variable declarations if that variable is
part of an associative array.
In other words:
struct S
{
int x;
}
struct T
{
S s;
}
T t = {s: {x: 1}}; // nesting works here
S[] arr = [{x: 1}, {x:2}]; // and here
S[string] aa = ["first": {x: 1}, "second": {x: 2}]; // but not here???
-Steve
Re: Is there a way to get this associative array initialization to work?
On 2018-01-10 00:19, Steven Schveighoffer wrote: https://issues.dlang.org/buglist.cgi?list_id=218715=not%20an%20associative%20array%20initializer_type=allwordssubstr_format=advanced=--- Note, I think you need at least Sound.SOUND_EFFECT, etc. This bug looks particularly relevant: https://issues.dlang.org/show_bug.cgi?id=11221 I think it should really work. It's not just in associative arrays it doesn't work. It basically only works in variables declarations: https://issues.dlang.org/show_bug.cgi?id=15692 -- /Jacob Carlborg
Re: Rvalue references
On 1/10/18 3:08 AM, Dgame wrote: On Wednesday, 10 January 2018 at 01:56:02 UTC, Steven Schveighoffer wrote: But current auto ref is what we have, so I would recommend using it. I would recommend to ignore auto ref for rvalue references. It generates 2^N functions where N is the amount of auto ref parameters. That the most awful template bloat I've ever seen. It only generates 2^N functions if you call it 2^N different ways. Most of the time you call it the same way. -Steve
Vibe-d issue with timer in separate thread on debug builds
Hi, I have an app that uses vibe tasks, fibers and timers
extensively, and I found an issue only for debug builds, when
canceling a timer. However the code in question works just fine
in the release build.
But having this here makes testing certain things in my program a
pain, since it'll crash on the assert in question:
vibe-d-0.8.2/vibe-d/core/vibe/core/drivers/libevent2.d:474
debug assert(m_ownerThread is () @trusted { return
Thread.getThis(); } ());
Also, not sure I understand that assert properly... Is it
checking the stop timer call is fired from the main thread the
event loop is running? That would be bad, since basically that
timer run from a child thread.
need help with vibe.d receive()
Hi! I make multi-task event bus, but there is a problem with the task stops. Please see end of file https://github.com/crimaniak/d-vision/blob/master/src/vision/eventbus.d Expected behavior: After sending the StopEvent message in line 244 it is must be detected in listeners (line 147), so all listeners must set exit flag to 'true' and quit immediately. De-facto behavior: StopEvent() message is not detected by the first delegate in line 147 (logger task logs this message by the handler in line 185), so subscribed tasks never exit and test stops on line 248. I tried to play with yield() and sleep(), with 'shared' attributes and so on, but without result. Can you say please what I am doing wrong here? 'dub test' can be used to play with tests.
How to pass --DRT-covopt to dub test?
Hi, I have some issues to find out how I can pass --DRT-covopt to dub test. I am pretty sure this should work, but dub doesn't like it: dub test --coverage -- --DRT-covopt "dstpath:./cov" ... Running .\cov-sample.exe dstpath:./cov ... Is there s.th. I miss? Kind regards André
Re: Rvalue references
On Wednesday, 10 January 2018 at 01:56:02 UTC, Steven Schveighoffer wrote: But current auto ref is what we have, so I would recommend using it. I would recommend to ignore auto ref for rvalue references. It generates 2^N functions where N is the amount of auto ref parameters. That the most awful template bloat I've ever seen.
