On Tuesday, 24 January 2017 at 20:51:49 UTC, Stefan Koch wrote:
On Tuesday, 24 January 2017 at 16:41:12 UTC, ixid wrote:
On Tuesday, 24 January 2017 at 16:27:50 UTC, ixid wrote:
On Tuesday, 24 January 2017 at 15:57:48 UTC, Las wrote:
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
I am trying to compile some code and it takes around 6 seconds.
Even if I change one line in one module, it takes the same time.
There are about 20 different d modules.
I used to get around 1-2 second compile times several months ago
on different projects.
I did upgrade a few things and it
On Tuesday, 24 January 2017 at 21:41:12 UTC, Profile Anaysis
wrote:
On Tuesday, 24 January 2017 at 21:36:50 UTC, Profile Anaysis
wrote:
...
Maybe with all this talk of the new CTFE engine being
developed, a similar mechanism can be used optionally? This
could help with debugging also.
In
On Tuesday, 24 January 2017 at 20:15:38 UTC, Dlearner wrote:
Hey all!
I'm learning programming through D and having a really good
time (much better than with C++ or Python). I'm aiming to make
little games with it as a hobby so I've learned some OpenGL
stuff.
But, I feel like I'm learning
On Tuesday, 24 January 2017 at 21:36:50 UTC, Profile Anaysis
wrote:
On Tuesday, 24 January 2017 at 16:49:03 UTC, TheFlyingFiddle
wrote:
On Tuesday, 24 January 2017 at 16:41:13 UTC, TheFlyingFiddle
wrote:
Everything turned out s much better than expected :)
Added bonus is that mixin output
On Tuesday, 24 January 2017 at 21:36:50 UTC, Profile Anaysis
wrote:
...
Maybe with all this talk of the new CTFE engine being developed,
a similar mechanism can be used optionally? This could help with
debugging also.
In debug mode, the cfte mixin's are written to disk with hash, if
they
On Tuesday, 24 January 2017 at 16:49:03 UTC, TheFlyingFiddle
wrote:
On Tuesday, 24 January 2017 at 16:41:13 UTC, TheFlyingFiddle
wrote:
Everything turned out s much better than expected :)
Added bonus is that mixin output can be viewed in the generated
files :D
Could you post your
On Tuesday, 24 January 2017 at 21:14:08 UTC, pineapple wrote:
On Tuesday, 24 January 2017 at 20:15:38 UTC, Dlearner wrote:
Hey all!
I'm learning programming through D and having a really good
time (much better than with C++ or Python). I'm aiming to
make little games with it as a hobby so
On Tuesday, 24 January 2017 at 20:15:38 UTC, Dlearner wrote:
Hey all!
I'm learning programming through D and having a really good
time (much better than with C++ or Python). I'm aiming to make
little games with it as a hobby so I've learned some OpenGL
stuff.
But, I feel like I'm learning
On Tuesday, 24 January 2017 at 16:41:12 UTC, ixid wrote:
On Tuesday, 24 January 2017 at 16:27:50 UTC, ixid wrote:
On Tuesday, 24 January 2017 at 15:57:48 UTC, Las wrote:
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
[...]
Submit a bug report then.
I will if it turns out the
Hey all!
I'm learning programming through D and having a really good time
(much better than with C++ or Python). I'm aiming to make little
games with it as a hobby so I've learned some OpenGL stuff.
But, I feel like I'm learning more library code rather than D
concepts and idioms, especially
So I have a window (Windows), and my wndProc is basically the
same as the one on the windows guides. However, even though
WM_CLOSE gets passed (and I can use if(msg == WM_CLOSE)), I can't
seem to set my shouldClose flag. I've confirmed that I still get
the event within my processMessage
On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis
wrote:
So, while it makes sense to say that .ptr can't be used in
@safe code, it really doesn't make sense to suggest [0] as
an alternative.
That may well be. But I believe everything that can provably be
@safe are made so even
On Tuesday, 24 January 2017 at 16:41:13 UTC, TheFlyingFiddle
wrote:
Everything turned out s much better than expected :)
Added bonus is that mixin output can be viewed in the generated
files :D
On Tuesday, 24 January 2017 at 12:19:33 UTC, ketmar wrote:
On Tuesday, 24 January 2017 at 12:14:05 UTC, TheFlyingFiddle
wrote:
unittest
{
enum s = import("myfile");
}
Is there something similar to this for outputting files at
compile-time?
no. this is by design, so it won't be fixed.
On Tuesday, 24 January 2017 at 16:27:50 UTC, ixid wrote:
On Tuesday, 24 January 2017 at 15:57:48 UTC, Las wrote:
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
This code:
T tFunc(alias F, T)(T n) {
n.F;
return n;
}
Produces this error:
Error: no property 'F' for
On Tuesday, 24 January 2017 at 15:57:48 UTC, Las wrote:
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
This code:
T tFunc(alias F, T)(T n) {
n.F;
return n;
}
Produces this error:
Error: no property 'F' for type 'int[]' (or whatever type I
use).
The alias rules
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
This code:
T tFunc(alias F, T)(T n) {
n.F;
return n;
}
Produces this error:
Error: no property 'F' for type 'int[]' (or whatever type I
use).
I believe UFCS is supposed to only work with top-level functions.
I don't
On Tuesday, 24 January 2017 at 13:11:41 UTC, ixid wrote:
This code:
T tFunc(alias F, T)(T n) {
n.F;
return n;
}
Produces this error:
Error: no property 'F' for type 'int[]' (or whatever type I
use).
The alias rules for functions seem to be incompatible with
UFCS, F(n)
On Tuesday, 24 January 2017 at 12:19:33 UTC, ketmar wrote:
On Tuesday, 24 January 2017 at 12:14:05 UTC, TheFlyingFiddle
wrote:
unittest
{
enum s = import("myfile");
}
Is there something similar to this for outputting files at
compile-time?
no. this is by design, so it won't be fixed.
On Tuesday, 24 January 2017 at 12:14:05 UTC, TheFlyingFiddle
wrote:
unittest
{
enum s = import("myfile");
}
Is there something similar to this for outputting files at
compile-time?
no. this is by design, so it won't be fixed. sorry. you may use
build script that will create the code
On Tuesday, 24 January 2017 at 11:19:58 UTC, TheFlyingFiddle
wrote:
Does D have any facilities that could make this possible?
It seems that there is a feature I was unaware of/forgot called
Import Expressions.
unittest
{
enum s = import("myfile");
}
Is there something similar to this
On Tuesday, January 24, 2017 11:50:16 Rene Zwanenburg via Digitalmars-d-
learn wrote:
> On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis
>
> wrote:
> > Likely because it does bounds checking, so you at least know
> > that it's not null. But I don't see why that would really
> >
On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis
wrote:
Likely because it does bounds checking, so you at least know
that it's not null. But I don't see why that would really
improve much considering that the odds are that you're really
going to be accessing far more than just the
On Tuesday, 24 January 2017 at 11:32:47 UTC, TheFlyingFiddle
wrote:
On Tuesday, 24 January 2017 at 11:28:17 UTC, Atila Neves wrote:
void main() {
foo;
}
void foo() @safe {
int[] array;
auto ptr = array.ptr;
}
foo.d(7): Deprecation: array.ptr cannot be used in @safe code,
use [0]
On Monday, January 23, 2017 22:26:58 bitwise via Digitalmars-d-learn wrote:
> Is it ok to memcpy/memmove a struct in D?
>
> Quote from here:
> https://dlang.org/spec/garbage.html
>
> "Do not have pointers in a struct instance that point back to the
> same instance. The trouble with this is if the
On Tuesday, January 24, 2017 11:28:17 Atila Neves via Digitalmars-d-learn
wrote:
> void main() {
> foo;
> }
>
> void foo() @safe {
> int[] array;
> auto ptr = array.ptr;
> }
>
>
> foo.d(7): Deprecation: array.ptr cannot be used in @safe code,
> use [0] instead
>
>
> [0] is
On Tuesday, 24 January 2017 at 11:28:17 UTC, Atila Neves wrote:
void main() {
foo;
}
void foo() @safe {
int[] array;
auto ptr = array.ptr;
}
foo.d(7): Deprecation: array.ptr cannot be used in @safe code,
use [0] instead
[0] is incredibly ugly and feels like an unnecessary
On Tuesday, 24 January 2017 at 11:28:17 UTC, Atila Neves wrote:
void main() {
foo;
}
void foo() @safe {
int[] array;
auto ptr = array.ptr;
}
foo.d(7): Deprecation: array.ptr cannot be used in @safe code,
use [0] instead
[0] is incredibly ugly and feels like an unnecessary
void main() {
foo;
}
void foo() @safe {
int[] array;
auto ptr = array.ptr;
}
foo.d(7): Deprecation: array.ptr cannot be used in @safe code,
use [0] instead
[0] is incredibly ugly and feels like an unnecessary hack,
and I'm wondering why it's @safe.
Atila
Context:
I am currently writing a small library that compiles sql strings
at compile-time and generates query objects.
Something like this:
unittest
{
mixin Sql!(q{
select feed.url, feed.title
from users
join user_feeds as feed
on users.id = feed.user
31 matches
Mail list logo
