Is there a way to generate a single visuald project file for all
dub configurations, selecting the configuration from the visual
studio configuration manager? Or do I have to generate a separate
project for each configuration?
On Friday, 17 June 2016 at 11:10:12 UTC, Gary Willoughby wrote:
Thanks, I forgot to mention I'm also doing lots of other stuff
in the constructor to private fields too.
struct Foo(T)
{
private int _bar;
private void* _baz;
this(int bar = 8)
{
this._bar = bar;
std.process.wait() will wait for a child process to exit and
return its exit code. How can this be done in Vibe.d, without
blocking other fibers and without creating a new thread?
In my library I did it like this:
https://github.com/CyberShadow/ae/blob/master/sys/process.d
(register a SIGCHLD
On Friday, 17 June 2016 at 10:50:55 UTC, Gary Willoughby wrote:
I have a struct where I need to perform default initialization
of some members but the compiler doesn't allow to define a
default constructor which allow optional arguments.
This is a fairly recent change (2.068->2.069 or 2.070),
time_t is 64-bit on windows:
https://msdn.microsoft.com/en-us/library/1f4c8f33.aspx
On Friday, 17 June 2016 at 13:11:35 UTC, Kagamin wrote:
time_t is 64-bit on windows:
https://msdn.microsoft.com/en-us/library/1f4c8f33.aspx
Windows does not have the concept of "time_t". The C runtime in
use does.
We use the DigitalMars C runtime for the 32-bit model, which is
the default
Hi,
I try to write a wrapper for a library. I translated the C++
header coding.
While the wrapper is working fine in linux, on windows the
library complains
the struct size is too small while calling it.
This is the reduced example:
import core.stdc.time: time_t;
import std.stdio;
On Friday, 17 June 2016 at 03:41:02 UTC, Adam D. Ruppe wrote:
It actually has been on my todo list for a while to change the
decoder to generate less garbage. I have had trouble in the
past with temporary arrays being pinned by false pointers and
the memory use ballooning from that, and the
On Friday, 17 June 2016 at 06:54:36 UTC, Andre Pany wrote:
Is this behavior correct?
Yes. time_t is defined as C long on Linux (meaning it'll be
64-bit in 64-bit programs), however it's always 32-bit on the
Windows C runtimes we use.
On Friday, 17 June 2016 at 06:18:59 UTC, Basile B. wrote:
On Thursday, 16 June 2016 at 09:18:54 UTC, TheDGuy wrote:
On Thursday, 16 June 2016 at 08:20:00 UTC, Basile B. wrote:
Yes it's "WorkingDirectory" (and not current...). But
otherwise you can use args[0]. Actually using the cwd in a
On Friday, 17 June 2016 at 07:11:28 UTC, Vladimir Panteleev wrote:
On Friday, 17 June 2016 at 06:54:36 UTC, Andre Pany wrote:
Is this behavior correct?
Yes. time_t is defined as C long on Linux (meaning it'll be
64-bit in 64-bit programs), however it's always 32-bit on the
Windows C
On Friday, June 17, 2016 13:21:04 Vladimir Panteleev via Digitalmars-d-learn
wrote:
> On Friday, 17 June 2016 at 13:11:35 UTC, Kagamin wrote:
> > time_t is 64-bit on windows:
> > https://msdn.microsoft.com/en-us/library/1f4c8f33.aspx
>
> Windows does not have the concept of "time_t". The C
On Friday, 17 June 2016 at 14:29:57 UTC, Russel Winder wrote:
A priori, assuming I am not missing anything, this behaviour
seems entirely reasonable.
I agree that when using non-daemon threads (and I personally
think that should be the default) that it is. But I cannot bring
that into
On Saturday, 18 June 2016 at 01:20:16 UTC, Joerg Joergonson wrote:
Error: undefined identifier 'sleep', did you mean function
'Sleep'?
"import core.thread; sleep(10);"
It is `Thread.sleep(10.msecs)` or whatever time - `sleep` is a
static member of the Thread class.
They mention to use
I have something like
class X;
class subfoo : X;
class subbaz : X;
class foo : X
{
subfoo bar;
}
class baz : X;
which I have modified so that
class subbaz : subfoo;
class baz : foo;
(essentially baz is now a derivation of foo while before it was
of X)
the problem is that subbaz uses
On Friday, 17 June 2016 at 16:58:42 UTC, OpenJelly wrote:
Trying to set up an IDE on Windows 7 with code completion but
my issues keep coming back to DCD. The tests failed the one
time I could get the tests to go beyond it waiting for another
instance of DCD to close. The path is added to my
On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:
On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
ok, then it's somewhere in TrueColorImage or the loading of
the png.
So, opengltexture actually does reallocate if the size isn't
right for the texture... and your
On Saturday, 18 June 2016 at 01:44:28 UTC, Joerg Joergonson wrote:
I simply removed your nextpowerof2 code(so the width and height
wasn't being enlarged) and saw no memory change). Obviously
because they are temporary buffers, I guess?
right, the new code free() them right at scope exit.
If
On Friday, 17 June 2016 at 14:39:32 UTC, kinke wrote:
On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
LDC x64 uses about 250MB and 13% cpu.
I couldn't check on x86 because of the error
phobos2-ldc.lib(gzlib.c.obj) : fatal error LNK1112: module
machine type 'x64' conflicts
On Saturday, 18 June 2016 at 01:46:32 UTC, Adam D. Ruppe wrote:
On Saturday, 18 June 2016 at 01:44:28 UTC, Joerg Joergonson
wrote:
I simply removed your nextpowerof2 code(so the width and
height wasn't being enlarged) and saw no memory change).
Obviously because they are temporary buffers, I
On Saturday, 18 June 2016 at 01:57:49 UTC, Joerg Joergonson wrote:
Ok. Also, maybe the GC hasn't freed some of those temporaries
yet.
The way GC works in general is it allows allocations to just
continue until it considers itself under memory pressure. Then,
it tries to do a collection.
On Saturday, 18 June 2016 at 00:56:57 UTC, Joerg Joergonson wrote:
On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:
[...]
Yes, same here! Great! It runs around 122MB in x86 and 107MB
x64. Much better!
[...]
Yeah, strange but good catch! It now works in x64! I modified
it
The CPU usage is consistently very low on my computer. I still
don't know what could be causing it for you, but maybe it is
the temporary garbage... let us know if the new patches make a
difference there.
Ok, I tried the breaking at random method and I always ended up
in system code and no
On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:
On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
[...]
So, opengltexture actually does reallocate if the size isn't
right for the texture... and your image was one of those sizes.
[...]
Cool, I'll check all
On Friday, 17 June 2016 at 19:49:18 UTC, Johan Engelen wrote:
Hi all,
Is there another way to get access to Voldemort class
methods, or private class members, other than using
Voldemort data is pretty well protected though. Because unlike
protection attributes, modularizing stuff in
On 17.06.2016 23:00, Nordlöw wrote:
I want to create a function that takes a variadic number of arguments
all of a specific type, say T, without having to create GC-allocated
heap array.
Is there a better way than:
f(Args...)(Args args)
if (allSameType!(Args, T);
in terms of template
On Friday, 17 June 2016 at 20:12:53 UTC, cy wrote:
writeln("see ",wow," for any equipment you need.");
Oh, and as you can see it's important to automate that, so you
don't make any mistakes while copying.
Trying to set up an IDE on Windows 7 with code completion but my
issues keep coming back to DCD. The tests failed the one time I
could get the tests to go beyond it waiting for another instance
of DCD to close. The path is added to my PATH variable, I've
rebuilt it from source with the .bat
Hi all,
Is there another way to get access to Voldemort class methods,
or private class members, other than using "pragma(mangle, ...)"
on user symbols?
Example code:
In library, and _should not_ be changed :
```
Object getObject() {
class Vold : Object {
int store;
I want to create a function that takes a variadic number of
arguments all of a specific type, say T, without having to create
GC-allocated heap array.
Is there a better way than:
f(Args...)(Args args)
if (allSameType!(Args, T);
in terms of template bloat?
On Friday, 17 June 2016 at 21:20:01 UTC, Timon Gehr wrote:
On 17.06.2016 23:00, Nordlöw wrote:
I want to create a function that takes a variadic number of
arguments
all of a specific type, say T, without having to create
GC-allocated
heap array.
Is there a better way than:
f(Args...)(Args
On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
ok, then it's somewhere in TrueColorImage or the loading of the
png.
So, opengltexture actually does reallocate if the size isn't
right for the texture... and your image was one of those sizes.
The texture pixel size needs to
On Friday, 17 June 2016 at 04:54:27 UTC, Joerg Joergonson wrote:
LDC x64 uses about 250MB and 13% cpu.
I couldn't check on x86 because of the error
phobos2-ldc.lib(gzlib.c.obj) : fatal error LNK1112: module
machine type 'x64' conflicts with target machine type 'X86'
not sure what that means
On Fri, 2016-06-17 at 00:14 +, Moritz Maxeiner via Digitalmars-d-
learn wrote:
> So, I am probably overlooking something obvious, but here goes:
> According to my understanding of daemon threads and what is
> documented here[1],
> this following program should terminate once the druntime
On Friday, 17 June 2016 at 13:21:04 UTC, Vladimir Panteleev wrote:
Windows does not have the concept of "time_t". The C runtime in
use does.
The D bindings don't copy that behavior.
D defining C runtime type different from C runtime causes this
error.
On Friday, 17 June 2016 at 16:16:48 UTC, Kagamin wrote:
On Friday, 17 June 2016 at 13:21:04 UTC, Vladimir Panteleev
wrote:
Windows does not have the concept of "time_t". The C runtime
in use does.
The D bindings don't copy that behavior.
D defining C runtime type different from C runtime
On Thursday, 16 June 2016 at 09:18:54 UTC, TheDGuy wrote:
On Thursday, 16 June 2016 at 08:20:00 UTC, Basile B. wrote:
Yes it's "WorkingDirectory" (and not current...). But
otherwise you can use args[0]. Actually using the cwd in a
program is often an error because there is no guarantee that
glfw sux. simpledisplay.d rox.
https://github.com/adamdruppe/arsd
http://dpldocs.info/experimental-docs/arsd.simpledisplay.html
On Wednesday, 15 June 2016 at 21:06:01 UTC, Joerg Joergonson
wrote:
My thinking is that CoCreateinstance is suppose to give us a
pointer to the interface so we can use it, if all this stuff is
crashing does that mean the interface is invalid or not being
assigned properly or is there far more
On Friday, 17 June 2016 at 10:50:55 UTC, Gary Willoughby wrote:
I have a struct where I need to perform default initialization
of some members but the compiler doesn't allow to define a
default constructor which allow optional arguments.
struct Foo(T)
{
private int _bar;
this(int bar
I have a struct where I need to perform default initialization of
some members but the compiler doesn't allow to define a default
constructor which allow optional arguments.
struct Foo(T)
{
private int _bar;
this(int bar = 1)
{
this._bar = bar;
}
}
auto foo =
On Friday, 17 June 2016 at 10:53:40 UTC, Lodovico Giaretta wrote:
struct Foo(T)
{
private int _bar = 1;
this(int bar)
{
this._bar = bar;
}
}
auto foo = Foo!(string)();
This should do the trick.
Thanks, I forgot to mention I'm also doing lots of other stuff in
the
The Factory-Pattern would be a good idea.
On Thursday, 16 June 2016 at 19:52:58 UTC, OpenJelly wrote:
Trying to get VS Code to work with code-d... can't get dcd to
work with it. It says it's failed to kill the dcd server when I
try to reload it. It wasn't appearing in task manager (but
dcd-client was) and manually starting it up
I have been using Textadept ( http://foicica.com/textadept/ ) with
Textadept-d ( https://github.com/Hackerpilot/textadept-d ). I use mostly on
Linux for development, but I've recently spent two or three days on Windows
and things worked well enough for me.
(Coming for someone who has used Emacs
45 matches
Mail list logo
