On Mon, Feb 26, 2018 at 07:50:10PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
[...]
> One case that I found interesting was that in writing
> core.time.convClockFreq so that it didn't require floating point
> values, it not only avoided the inaccuracies caused by using FP, but
> it
On Monday, February 26, 2018 18:33:13 H. S. Teoh via Digitalmars-d-learn
wrote:
> Well, the way I deal with floating point is, design my code with the
> assumption that things will be inaccurate, and compensate accordingly.
The way that I usually deal with it is to simply not use floating point
On Mon, Feb 26, 2018 at 05:18:00PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Monday, February 26, 2018 16:04:59 H. S. Teoh via Digitalmars-d-learn
> wrote:
[...]
> > (There *are* exact representations for certain subsets of
> > irrationals that allow fast computation that does
On Monday, February 26, 2018 17:49:21 H. S. Teoh via Digitalmars-d-learn
wrote:
> On Tue, Feb 27, 2018 at 12:26:56AM +, psychoticRabbit via Digitalmars-
d-learn wrote:
> > On Tuesday, 27 February 2018 at 00:04:59 UTC, H. S. Teoh wrote:
> > > A 64-bit double can only hold about 14-15 decimal
On Tue, Feb 27, 2018 at 12:26:56AM +, psychoticRabbit via
Digitalmars-d-learn wrote:
> On Tuesday, 27 February 2018 at 00:04:59 UTC, H. S. Teoh wrote:
> >
> > A 64-bit double can only hold about 14-15 decimal digits of
> > precision. Anything past that, and there's a chance your
> >
On Tuesday, 27 February 2018 at 00:04:59 UTC, H. S. Teoh wrote:
A 64-bit double can only hold about 14-15 decimal digits of
precision. Anything past that, and there's a chance your
"different" numbers are represented by exactly the same bits
and the computer can't tell the difference.
T
On Monday, February 26, 2018 16:04:59 H. S. Teoh via Digitalmars-d-learn
wrote:
> On Mon, Feb 26, 2018 at 11:34:06PM +, psychoticRabbit via
> Digitalmars-d-learn wrote: [...]
>
> > and what's going on here btw?
> >
> > assert( 1 == 1.01 ); // assertion error in DMD but not
>
On Mon, Feb 26, 2018 at 11:34:06PM +, psychoticRabbit via
Digitalmars-d-learn wrote:
[...]
> and what's going on here btw?
>
> assert( 1 == 1.01 ); // assertion error in DMD but not in
> LDC
> assert( 1 == 1.001 ); // no assertion error??
>
> (compiled in
On Sunday, 25 February 2018 at 14:52:19 UTC, Steven Schveighoffer
wrote:
1 == 1.0, no?
no. at least, not when a language forces you to think in terms of
types.
1 is an int.
1.0 is a floating point.
I admit, I've never printed output without using format
specifiers, but still, if I say
On Sunday, 25 February 2018 at 21:35:33 UTC, ketmar wrote:
add postblit debug prints, and you will see.
I get that it will call the postblit since it creates a temporary.
What I expected though was that.
auto s = S(0).foo(1);
Would become something like:
S s; s.__ctor(0).foo(1);
But maybe
Kayomn wrote:
On Monday, 26 February 2018 at 21:04:51 UTC, TheFlyingFiddle wrote:
On Monday, 26 February 2018 at 20:50:35 UTC, Kayomn wrote:
[...]
Don't think you can alias member variables directly.
You could do this though:
struct Player {
Entity entity;
ref auto pos() inout {
On Monday, 26 February 2018 at 21:04:51 UTC, TheFlyingFiddle
wrote:
On Monday, 26 February 2018 at 20:50:35 UTC, Kayomn wrote:
[...]
Don't think you can alias member variables directly.
You could do this though:
struct Player {
Entity entity;
ref auto pos() inout { return
On Monday, 26 February 2018 at 20:50:35 UTC, Kayomn wrote:
I've been experimenting with D's Better C mode, and I have a
question regarding something that I started thinking about
after watching one of Jonathon Blow's talks on data-oriented
programming - more specifically the aspect of fake
I've been experimenting with D's Better C mode, and I have a
question regarding something that I started thinking about after
watching one of Jonathon Blow's talks on data-oriented
programming - more specifically the aspect of fake "inheritance"
I have the following code. My question is if
On Monday, 16 January 2017 at 19:44:34 UTC, Russel Winder wrote:
On Mon, 2017-01-16 at 17:47 +, King_DuckZ via
Digitalmars-d-learn wrote:
[…]
> Meson can build D stuff out of the box.
>
Hadn't heard of this before, I'll have a look. Btw I don't see
any mention of D on their home page.
On Monday, 26 February 2018 at 18:01:07 UTC, Marc wrote:
I've tried both gdb and windbg debugger both it either get a
"received signal ?" from gdb or crash the GUI application
(windbg).
The error is:
core.exception.OutOfMemoryError@src\core\exception.d(696):
Memory allocation failed
How do
On Monday, 26 February 2018 at 19:02:36 UTC, Arredondo wrote:
This worked. Thank you jmh530!
I feel like at this moment, lubeck should be clearly marked
"not Windows ready", as not everybody will have the
inclination/patience to deal with incompatible object file
formats or the Windows
On Monday, 26 February 2018 at 17:40:05 UTC, jmh530 wrote:
On Monday, 26 February 2018 at 17:12:51 UTC, Arredondo wrote:
Okay, so I just finished configuring WSL. The way I want to
use my app is having it read from stdin, do some calculations,
and write to stdout, in an infinite cycle. I
On Wed, Feb 21, 2018 at 11:16:44PM -0500, Nick Sabalausky (Abscissa) via
Digitalmars-d-learn wrote:
> Are there any tutorials or articles out there for "getting started
> with converting a C++ codebase to D one module at a time?" Or at the
> very least: tips, tricks, lessions learned, from those
I've tried both gdb and windbg debugger both it either get a
"received signal ?" from gdb or crash the GUI application
(windbg).
The error is:
core.exception.OutOfMemoryError@src\core\exception.d(696):
Memory allocation failed
How do I find out the source of the error?
On Monday, 26 February 2018 at 17:12:51 UTC, Arredondo wrote:
Okay, so I just finished configuring WSL. The way I want to use
my app is having it read from stdin, do some calculations, and
write to stdout, in an infinite cycle. I wanted to feed this to
some higher level algorithms in Wolfram
On Monday, 26 February 2018 at 05:15:48 UTC, jmh530 wrote:
On Sunday, 25 February 2018 at 14:25:04 UTC, Arredondo wrote:
On Friday, 23 February 2018 at 16:56:13 UTC, jmh530 wrote:
I had given up and used WSL at this point rather than compile
it myself with CMAKE. Less of a headache.
I don’t
On Monday, 26 February 2018 at 14:42:58 UTC, Adam D. Ruppe wrote:
On Monday, 26 February 2018 at 14:38:22 UTC, ParticlePeter
wrote:
This cool, I didn't know that we can name mixins when
instantiating but also never taught that there could be any
purpose for naming. Works, thanks.
oh yes,
On Monday, 26 February 2018 at 14:38:22 UTC, ParticlePeter wrote:
This cool, I didn't know that we can name mixins when
instantiating but also never taught that there could be any
purpose for naming. Works, thanks.
oh yes, there's a lot of cool things with mixin. You might want
to skim my
On Monday, 26 February 2018 at 14:02:56 UTC, Adam D. Ruppe wrote:
On Monday, 26 February 2018 at 12:30:24 UTC, ParticlePeter
wrote:
Is this expected behavior?
yes sort of, but there are bugs associated with it too...
I wrote about this in the "Tip of the Week" section here before
On Monday, 26 February 2018 at 12:30:24 UTC, ParticlePeter wrote:
Is this expected behavior?
yes sort of, but there are bugs associated with it too...
I wrote about this in the "Tip of the Week" section here before
http://arsdnet.net/this-week-in-d/2016-feb-07.html
there's a workaround
On Monday, 26 February 2018 at 13:09:40 UTC, ParticlePeter wrote:
Thanks for clarification, unfortunately your suggestion doesn't
work.
Since when is alias this = something; supposed to work?
alias Common.this this; doesn't work as well and following also
not:
struct Baz {
Foo foo;
alias
On Monday, 26 February 2018 at 12:47:48 UTC, Jonathan M Davis
wrote:
On Monday, February 26, 2018 12:30:24 ParticlePeter via
Digitalmars-d-learn wrote:
mixin template Common() {
private int m_member;
this( int m ) { m_member = m; }
}
struct Foo {
mixin Common;
}
struct Bar {
mixin
On Monday, February 26, 2018 12:30:24 ParticlePeter via Digitalmars-d-learn
wrote:
> mixin template Common() {
>private int m_member;
>this( int m ) { m_member = m; }
> }
>
> struct Foo {
>mixin Common;
> }
>
> struct Bar {
>mixin Common;
>this( int m, float n ) { m_member = m
mixin template Common() {
private int m_member;
this( int m ) { m_member = m; }
}
struct Foo {
mixin Common;
}
struct Bar {
mixin Common;
this( int m, float n ) { m_member = m * n; }
}
auto foo = Foo(1); // ok
auto b_1 = Bar( 1, 2 ); // ok
auto b_2 = Bar( 3 ); // Error:
30 matches
Mail list logo
