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
> {
>
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,
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
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
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
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
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;
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
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.
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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 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()
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); //
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
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
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
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:
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
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
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
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é
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
37 matches
Mail list logo
