[Issue 16474] CTFE pow

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16474

ki...@gmx.net changed:

   What|Removed |Added

 CC||ki...@gmx.net

--- Comment #11 from ki...@gmx.net ---
(In reply to uplink.coder from comment #10)
> (In reply to kinke from comment #9)
> > 
> > So how does newCTFE interact with CTFloat at the moment? This is an
> > important piece for cross-compilers. And is there an estimate for when
> > newCTFE will land?
> 
> It does currently not use CTFloat at all.
> It only implements add, sub, mul and div and mod for floats/doubles.
> As well as float <=> double <=> long/int casts.

[Sorry about hijacking this issue.] Okay, but as guys clearly expect most of
the math functionality to be available at CTFE too, newCTFE will eventually
have to feature a similar system of CTFE builtins (ddmd.builtin). Currently, it
plugs into function calls and tries to match the callee name in a map of
mangled name => CTFE implementation. The builtins are required for functions
whose source code isn't available for CTFE, such as compiler intrinsics, inline
assembly and C library functions.

So newCTFE discriminates between 32-bit float and 64-bit double but lacks
support for real_t, as opposed to the current interpreter, which uses real_t
exclusively (in RealExp). So the current floating-point builtin implementations
expect host/compiler-specific real_t values, but extending those to allow for
all 3 (float, double, real_t) should be straightforward.

newCTFE should at some point support real_t and use it to represent target
reals at compile-time. It's most likely the host real type, but it may also be
a software implementation as custom type with overloaded binops (GDC afaik,
possibly LDC at some point), with a specific size and alignment, and more
advanced functionality provided by helper struct CTFloat.

--

[Issue 16191] std/digest/digest.d should be renamed to package.d

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16191

Vladimir Panteleev  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17724

--

[Issue 17724] digest is not a template declaration, it is a module

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17724

Vladimir Panteleev  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16191

--

[Issue 17724] New: digest is not a template declaration, it is a module

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17724

  Issue ID: 17724
   Summary: digest is not a template declaration, it is a module
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

/ test.d 
import std.digest.digest;
import std.digest.md;

alias foo = digest!MD5;
/

test.d(4): Error: std.digest.digest at test.d(1) conflicts with
std.digest.digest(Hash, Range)(auto ref Range range) if (!isArray!Range &&
isDigestibleRange!Range) at .../phobos/std/digest/package.d(432)
test.d(4): Error: template instance digest!MD5 digest is not a template
declaration, it is a module

--

[Issue 16474] CTFE pow

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16474

--- Comment #10 from uplink.co...@googlemail.com ---
(In reply to kinke from comment #9)
> 
> So how does newCTFE interact with CTFloat at the moment? This is an
> important piece for cross-compilers. And is there an estimate for when
> newCTFE will land?

It does currently not use CTFloat at all.
It only implements add, sub, mul and div and mod for floats/doubles.
As well as float <=> double <=> long/int casts.

--

[Issue 16474] CTFE pow

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16474

--- Comment #9 from ki...@gmx.net ---
(In reply to uplink.coder from comment #7)
> (In reply to ZombineDev from comment #6)
> > Manu, you may be interested in trying LDC as it will soon support much more
> > intrinsics at CTFE than dmd. For reference:
> > https://github.com/ldc-developers/ldc/pull/2259 I'm not sure if specifically
> > the pow operator is supported (though pow is supported as a function call).

I started that work due to a recent ping of this issue and me accidentally
noticing it. ;)
So the pow operator is working with that PR for LDC; there a static assert in
the last line of the test.

> Do they interface with the CTFE engine ?
> That'd be crazy :)

I detect a few more key primitive functions (ldexp, isNaN, isInfinity,
isFinite...) as builtins and forward to proper implementations in CTFloat. I
also had to make std.math.exp2() CTFE-able for 80-bit reals by not using the
inline assembly code for CTFE. DMD may need a few more builtins or
CTFE-friendly Phobos implementations to get all of this working as well; I'll
open a DMD PR for the ones required by LDC.

So how does newCTFE interact with CTFloat at the moment? This is an important
piece for cross-compilers. And is there an estimate for when newCTFE will land?

--

[Issue 16474] CTFE pow

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16474

--- Comment #8 from ZombineDev  ---
I don't think so, but see the PR for yourself ;)

--

[Issue 16474] CTFE pow

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16474

--- Comment #7 from uplink.co...@googlemail.com ---
(In reply to ZombineDev from comment #6)
> Manu, you may be interested in trying LDC as it will soon support much more
> intrinsics at CTFE than dmd. For reference:
> https://github.com/ldc-developers/ldc/pull/2259 I'm not sure if specifically
> the pow operator is supported (though pow is supported as a function call).

Do they interface with the CTFE engine ?
That'd be crazy :)

--

[Issue 16474] CTFE pow

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16474

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--- Comment #6 from ZombineDev  ---
Manu, you may be interested in trying LDC as it will soon support much more
intrinsics at CTFE than dmd. For reference:
https://github.com/ldc-developers/ldc/pull/2259 I'm not sure if specifically
the pow operator is supported (though pow is supported as a function call).

--

[Issue 17723] Replace Facebook on the front page with Weka.io

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17723

Richard Cattermole  changed:

   What|Removed |Added

 CC||alphaglosi...@gmail.com

--- Comment #1 from Richard Cattermole  ---
If Netflix were willing, it would probably be a better choice.

But no reason we cannot have one chosen from a couple, randomly per
request/day.

--

[Issue 17723] New: Replace Facebook on the front page with Weka.io

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17723

  Issue ID: 17723
   Summary: Replace Facebook on the front page with Weka.io
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: shish...@hotmail.com

To the best of my knowledge, Facebook is no longer actively using D
while I don't object to keeping Facebook in the "Orgs Using D" page 
putting it on the front page feel deceptive 

I think we should replace it by a company that actively use D, such as Weka or
others

--