Re: C++17 is feature complete

[luminousone via Digitalmars-d]

On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

On 6/26/2016 10:18 AM, Enamex wrote:
  - template arguments that accept constant values of any type 
whatsoever

'template';


Still adding D features, I see!


Now if only they could bring over some of D's superior template 
syntax, all of the <>'s are so damned ugly, Or type reflection 
features(is this even possible in c++?).

Re: 4x faster strlen with 4 char sentinel

[chmike via Digitalmars-d-announce]

On Monday, 27 June 2016 at 05:10:37 UTC, chmike wrote:
If you store the string size in a four byte field, you get a 
hard to beat fast strlen. :)


If you have the constrain to work with null terminated strings, 
then it could be interesting to look at SIMD as was suggested or 
use one of the following algorithms to test the presence of a 0 
byte in a 4 byte or 8 byte integer when simd is not available.


https://graphics.stanford.edu/~seander/bithacks.html#ZeroInWord

Ending strings with a single null byte/char is to save space. It 
was critical in the 70´s when C was created and memory space was 
very limited. That's not the case anymore and I guess the reason 
why you assume that ending a string with 4 null chars is OK.

Re: 4x faster strlen with 4 char sentinel

[chmike via Digitalmars-d-announce]

If you store the string size in a four byte field, you get a hard 
to beat fast strlen. :)

Re: Saturating integer arithmetic

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 27 June 2016 at 04:25:56 UTC, Ola Fosheim Grøstad 
wrote:
On Monday, 27 June 2016 at 04:23:10 UTC, Ola Fosheim Grøstad 
wrote:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=adds_epi


Or in the context of 8 bit colour vectors:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=adds_epu8


Turns out a careful selected search for "saturat" gives you a 
near complete overview over the standard intrinsics with 
saturation:


https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=saturat

Re: Saturating integer arithmetic

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 27 June 2016 at 04:23:10 UTC, Ola Fosheim Grøstad 
wrote:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=adds_epi


Or in the context of 8 bit colour vectors:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=adds_epu8

Re: Saturating integer arithmetic

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 26 June 2016 at 22:34:29 UTC, Andrei Alexandrescu 
wrote:

On 06/26/2016 02:07 PM, ketmar wrote:
On Sunday, 26 June 2016 at 13:59:03 UTC, Andrei Alexandrescu 
wrote:
See the recent thread "DbI checked integral". Saturation is a 
direct
goal, and you should be able to optimize operations for each 
type by

defining relatively small hooks.


alas, it is completely inappropriate for any computation-heavy 
task.
even if dmd inliner will do some miracle and will inline some 
calls.


What is some good literature to look at for SIMD saturation 
arithmetic? -- Andrei


https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=adds_epi

Re: C++17 is feature complete

[Meta via Digitalmars-d]

On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

On 6/26/2016 10:18 AM, Enamex wrote:
  - template arguments that accept constant values of any type 
whatsoever

'template';


Still adding D features, I see!


Imitation is the sincerest form of flattery, so when is 
destructuring coming to D?


Also, the `if (init; condition) and switch (init; condition)` 
seems like a very nice idea.

Re: Slice expressions - exact evaluation order, dollar

[Timon Gehr via Digitalmars-d]

On 26.06.2016 20:08, Iain Buclaw via Digitalmars-d wrote:

On 26 June 2016 at 14:33, Timon Gehr via Digitalmars-d
 wrote:

On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote:


Old codegen:

_base = *(getBase());
_lwr = getLowerBound(_base.length);
_upr = getUpperBound(_base.length);
r = {.length=(_upr - _lwr), .ptr=_base.ptr + _lwr * 4};

---



This seems to be what I'd expect. It's also what CTFE does.
CTFE and run time behaviour should be identical. (So either one of them
needs to be fixed.)




Very likely CTFE.  Anyway, this isn't the only thing where CTFE and
Runtime do things differently.
...


All arbitrary differences should be eradicated.


Now when creating temporaries of references, the reference is stabilized
instead.

New codegen:

*(_ptr = getBase());
_lwr = getLowerBound(_ptr.length);
_upr = getUpperBound(_ptr.length);
r = {.length=(_upr - _lwr), .ptr=_ptr.ptr + _lwr * 4};
---

I suggest you fix LDC if it doesn't already do this. :-)




I'm not convinced this is a good idea. It makes (()=>base)()[lwr()..upr()]
behave differently from base[lwr()..upr()].


No, sorry, I'm afraid you are wrong there. They should both behave
exactly the same.
...


I don't see how that is possible, unless I misunderstood your previous 
explanation. As far as I understand, for the first expression, code gen 
will generate a reference to a temporary copy of base, and for the 
second expression, it will generate a reference to base directly. If 
lwr() or upr() then update the ptr and/or the length of base, those 
changes will be seen for the second slice expression, but not for the first.




I may need to step aside and explain what changed in GDC, as it had
nothing to do with this LDC bug.

==> Step

What made this subtle change was in relation to fixing bug 42 and 228
in GDC, which involved turning on TREE_ADDRESSABLE(type) bit in our
codegen trees, which in turn makes NRVO work consistently regardless
of optimization flags used - no more optimizer being confused by us
"faking it".

How is the above jargon related? Well, one of the problems faced was
that it must be ensured that lvalues continue being lvalues when
considering creating a temporary in the codegen pass.  Lvalue
references must have the reference stabilized, not the value that is
being dereferenced.  This also came with an added assurance that GDC
will now *never* create a temporary of a decl with a cpctor or dtor,
else it'll die with an internal compiler error trying. :-)
...


What is the justification why the base should be evaluated as an lvalue?


<== Step

(() => base)[lwr()..up()] will make a temporary of (() => base), but
guarantees that references are stabilized first.



(I assume you meant (() => base)()[lwr()..upr()].)

The lambda returns by value, so you will stabilize the reference to a 
temporary copy of base? (Unless I misunderstand your terminology.)



base[lwr()..upr()] will create no temporary if base has no side
effects.  And so if lwr() modifies base, then upr() will get the
updated copy.



Yes, it is clear that upr() should see modifications to memory that 
lwr() makes. The point is that the slice expression itself does or does 
not see the updates based on whether I wrap base in a lambda or not.

[Issue 15672] Casting from void[] to T[] is erroneously considered @safe

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15672] Casting from void[] to T[] is erroneously considered @safe

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/b23203607189a00227ac9636f4b4347fe85f81bf
fix Issue 15672 - Casting from void[] to T[] is erroneously considered @safe

https://github.com/dlang/dmd/commit/5ca4b331c4ce3b096b04b98edaacd97dc246c9c1
Merge pull request #5876 from WalterBright/fix15672

fix Issue 15672 - Casting from void[] to T[] is erroneously considere…

--

Re: Optimizations and performance

[ZombineDev via Digitalmars-d]

On Sunday, 26 June 2016 at 23:27:41 UTC, Jadbox wrote:

On Saturday, 25 June 2016 at 16:05:08 UTC, ZombineDev wrote:
Overall DMD completes mandel.b for 75.5% of the time of the 
previous version, LDC for 62.6% and GDC for 88.1%. The code is 
64.9% of the original (in terms of LOC).


This is what I love: less code with more performance. Great 
work on PR #91... hope it gets merged in soon.


Thanks :)
I think that by using ranges we might be able to write a solution 
with 10x less code, but AFAIK, algorithmic changes are not 
accepted, because the idea of the benchmark is to show same 
solution written in different languages.


IMHO, D is fast enough (generally speaking). To me, D is 
lacking clear practical examples (e.g. webserver using sql db), 
libraries, and success stories. The fact that there isn't an 
AWS sdk for D makes it a show stopper for most developers I 
talk to.


I am not the right guy to talk about stuff like this, because I 
really enjoy writing things from scratch. If I had the time I 
would probably follow the steps of projects like Trinix and 
PowerNex and I would try to write an OS from scratch :D
Web development is just not my thing. I am glad that there are 
other people pushing those areas with D, because it really shows 
how versatile the language is and makes the lifes of other people 
easier.


For example, see this PR [1] that adds a nice tutorial to Dlang 
Tour [2] about deploying vibe.d on Heroku. I know it's not Amazon 
AWS, but still it might be helpful. Also, I found this [3] forum 
post about AWS Lambda.


BTW have you checked Kai Nacke's book [4] about Web Development 
with D?


[1]: https://github.com/stonemaster/dlang-tour/pull/289
[2]: http://tour.dlang.org/tour/en/vibed/vibe-d-web-framework
[3]: 
http://forum.dlang.org/post/jqotefrswxhaiqtee...@forum.dlang.org

[4]: http://wiki.dlang.org/Books

Re: AWS SDK

[bachmeier via Digitalmars-d]

On Sunday, 26 June 2016 at 23:06:02 UTC, Jadbox wrote:
Is there an AWS library in the works for D? It's seriously the 
main blocker for me to push adoption of the language internally.


If not, I can try to invest time into making one, but I could 
use help.


(fyi, there's one in the works for Rust: 
https://github.com/rusoto/rusoto)


http://forum.dlang.org/post/jqotefrswxhaiqtee...@forum.dlang.org

Re: static if enhancement

[Jonathan M Davis via Digitalmars-d]

On Friday, June 24, 2016 13:54:21 Andrei Alexandrescu via Digitalmars-d wrote:
> On 6/24/16 1:15 PM, Steven Schveighoffer wrote:
> > The problem that hasn't been made clear is, why can't you just write:
> >
> > static if(condition)
> > {
> >
> > ... // some code
> > return;
> >
> > }
> >
> > // some more code
> >
> > And the answer is, I'm guessing, bug 14835 -- misguided "unreachable
> > statement" warnings.
> >
> > Should we mark your bug as a duplicate?
>
> Sorry, the problem is that the code doesn't compile at all if the static
> if is false. So I need to insert the "else".
>
> The compiler should not attempt at all to compile the code after the
> static if.

I would think that it's highly unintuitive to think that code outside of a
static if would be treated as part of an else of a static if just because
the static if happens to return at the end. Certainly, if the code after the
static if couldn't compile if the static if code didn't return, I definitely
think that the code following it needs to be in an else. Really, it seems to
me that this comes down to a complaint about the compiler producing errors
on unreachable code - which is the sort of thing that I tend to think should
not be treated as an error - _especially_ with how badly it tends to
interact with generic code.

So, as long as the code following the static if is valid without being in an
else for the static if, I'm all for having the compiler just optimize out
everything after the return without complaining - but if we're going to do
that, it really shouldn't be specific to static ifs. That would be
unreasonably inconsistent IMHO. And I don't think that it's a good idea to
treat code following a static if as if it were in an else just because of a
return statement or break statement or some other control statement in the
static if which would cause the code after it to be skipped. That would be
confusing and inconsistent IMHO, much as it would be nice to avoid the extra
braces and indentation.

So, if we're going to change things here, I think that the approach is to
stop having the compiler complain about unreachable code, which I think is
very reasonable in light of how annoying that can get - particularly with
generic code - though I'm sure that some folks will be unhappy about that
just like some folks want the compiler to complain about unused variables
(though we don't do that in part because of how badly it interacts with
various D features - like highly templatized code - and that's pretty much
the main reason that having the compiler complain about unreachable code is
so problematic, which could be an argument to have it stop complaining about
it).

- Jonathan M Davis

Re: DIP66 v1.1 (Multiple) alias this.

[mogu via Digitalmars-d]

On Monday, 27 June 2016 at 00:13:46 UTC, mogu wrote:

On Friday, 8 May 2015 at 13:57:56 UTC, Andrea Fontana wrote:
Is "multiple alias this" implementation planned in near 
future? It could be useful for a project of mine :)


I need it too, and also do static inheritance.
http://wiki.dlang.org/DIP84


I implemented a limited version of multiple alias this:
https://github.com/mogud/MultiAliasThis/blob/master/mat.d

But it's only useful in composition. Static polymorphism(by 
implicit conversion in alias this) cannot work.

Re: Button: A fast, correct, and elegantly simple build system.

[Jason White via Digitalmars-d-announce]

On Monday, 20 June 2016 at 08:21:29 UTC, Dicebot wrote:

On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote:
This actually sounds nice. Main problem that comes to my mind 
is that there is no cross-platform shell script. Even if it 
is list of plain unconditional commands there are always 
differences like normalized path form. Of course, one can 
always generate `build.d` as a shell script, but that would 
only work for D projects and Button is supposed to be a 
generic solution.


I'd make it so it could either produce a Bash or Batch script. 
Possibly also a PowerShell script because error handling in 
Batch is awful. That should cover any platform it might be 
needed on. Normalizing paths shouldn't be a problem either.


This should actually be pretty easy to implement.


Will plain sh script script also work for MacOS / BSD flavors? 
Committing just two scripts is fine but I wonder how it scales.


FYI, I implemented this feature today (no Batch/PowerShell output 
yet though):


http://jasonwhite.github.io/button/docs/commands/convert

I think Bash should work on most Unix-like platforms.

Re: DIP66 v1.1 (Multiple) alias this.

[mogu via Digitalmars-d]

On Friday, 8 May 2015 at 13:57:56 UTC, Andrea Fontana wrote:
On Saturday, 27 December 2014 at 12:28:34 UTC, Joseph Rushton 
Wakeling wrote:

On 26/12/14 19:53, Daniel N via Digitalmars-d wrote:
Anyway considering the new ways of working, when using the 
-dip switch for the
initial few releases, there is ample time to perfect all 
details.


Potentially related issue, regarding implicit conversion.  
Given a struct as follows:


struct Integer
{
int i_;

alias i_ this;
}

Can anyone explain to me why this works:

Integer i = Integer(3);
i = 5;

... but this doesn't:

Integer i = 5;

It seems unintuitive, in the circumstances.


Is "multiple alias this" implementation planned in near future? 
It could be useful for a project of mine :)


I need it too, and also do static inheritance.
http://wiki.dlang.org/DIP84

Re: C++17 is feature complete

[mogu via Digitalmars-d]

On Sunday, 26 June 2016 at 22:32:55 UTC, Walter Bright wrote:

On 6/26/2016 10:18 AM, Enamex wrote:
  - template arguments that accept constant values of any type 
whatsoever

'template';


Still adding D features, I see!


Now cpp has structured bindings although it's a limited version 
of match. So when will DIP32 and match be taken into 
consideration in D?

Re: dmd (>2.068) compiler error

[Steven Schveighoffer via Digitalmars-d]

On Sunday, 26 June 2016 at 07:01:57 UTC, ted wrote:

Unsure of exactly how to communicate this one, so posting here.

[snip]


for any dmd >2.068 causes the following error:
dmd: glue.c:809: void 
FuncDeclaration_toObjFile(FuncDeclaration*, bool): Assertion 
`fd->semanticRun == PASSsemantic3done' failed.

Aborted

However, it works find for dmd.2.068.

Any ideas?


any error like that is an internal compiler error (ice) and 
should never happen.


Please file an issue: https://issues.dlang.org

Try to reduce the code as much as possible so someone can 
reproduce it


-Steve

[Semi OT] About code review

[deadalnix via Digitalmars-d-announce]

Several people during DConf asked abut tips and tricks on code 
review. So I wrote an article about it:


http://www.deadalnix.me/2016/06/27/on-code-review/

Re: Saturating integer arithmetic

[John Colvin via Digitalmars-d]

On Sunday, 26 June 2016 at 22:34:29 UTC, Andrei Alexandrescu 
wrote:

On 06/26/2016 02:07 PM, ketmar wrote:
On Sunday, 26 June 2016 at 13:59:03 UTC, Andrei Alexandrescu 
wrote:
See the recent thread "DbI checked integral". Saturation is a 
direct
goal, and you should be able to optimize operations for each 
type by

defining relatively small hooks.


alas, it is completely inappropriate for any computation-heavy 
task.
even if dmd inliner will do some miracle and will inline some 
calls.


What is some good literature to look at for SIMD saturation 
arithmetic? -- Andrei


http://www.intel.co.uk/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
 has some stuff about saturation in it. I learned from that and the instruction 
reference.

Re: Optimizations and performance

[Jadbox via Digitalmars-d]

On Saturday, 25 June 2016 at 16:05:08 UTC, ZombineDev wrote:
Overall DMD completes mandel.b for 75.5% of the time of the 
previous version, LDC for 62.6% and GDC for 88.1%. The code is 
64.9% of the original (in terms of LOC).


This is what I love: less code with more performance. Great work 
on PR #91... hope it gets merged in soon.


IMHO, D is fast enough (generally speaking). To me, D is lacking 
clear practical examples (e.g. webserver using sql db), 
libraries, and success stories. The fact that there isn't an AWS 
sdk for D makes it a show stopper for most developers I talk to.

[Issue 16207] CTFE cast from void* to ubyte* doesn't work

[via Digitalmars-d-bugs]

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

uplink.co...@googlemail.com changed:

   What|Removed |Added

 CC||uplink.co...@googlemail.com

--- Comment #1 from uplink.co...@googlemail.com ---
The only way around this is passing ubyte[] instead of void[]

I actually like the rigorous type-safety at CTFE.

It's not a bug, It's a feature!

--

AWS SDK

[Jadbox via Digitalmars-d]

Is there an AWS library in the works for D? It's seriously the 
main blocker for me to push adoption of the language internally.


If not, I can try to invest time into making one, but I could use 
help.


(fyi, there's one in the works for Rust: 
https://github.com/rusoto/rusoto)

Re: Saturating integer arithmetic

[ketmar via Digitalmars-d]

On Sunday, 26 June 2016 at 22:34:29 UTC, Andrei Alexandrescu 
wrote:
What is some good literature to look at for SIMD saturation 
arithmetic? -- Andrei


sorry, i don't know. for me it was intel cpu manuals. certainly 
not even a good way to learn the things.

Re: C++17 is feature complete

[Walter Bright via Digitalmars-d]

On 6/26/2016 3:32 PM, Walter Bright wrote:

On 6/26/2016 10:18 AM, Enamex wrote:

  - template arguments that accept constant values of any type whatsoever
'template';


Still adding D features, I see!



Reading:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0127r1.html

shows it is something else.

Re: Call to Action: making Phobos @safe

[Walter Bright via Digitalmars-d]

On 6/26/2016 6:13 AM, Robert burner Schadek wrote:

It would be awesome if you would create that process model in the wiki and at it
to your action list
http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List



It's a wiki, feel free to add it.

Re: Saturating integer arithmetic

[Andrei Alexandrescu via Digitalmars-d]

On 06/26/2016 02:07 PM, ketmar wrote:

On Sunday, 26 June 2016 at 13:59:03 UTC, Andrei Alexandrescu wrote:

See the recent thread "DbI checked integral". Saturation is a direct
goal, and you should be able to optimize operations for each type by
defining relatively small hooks.


alas, it is completely inappropriate for any computation-heavy task.
even if dmd inliner will do some miracle and will inline some calls.


What is some good literature to look at for SIMD saturation arithmetic? 
-- Andrei

Re: C++17 is feature complete

[Walter Bright via Digitalmars-d]

On 6/26/2016 10:18 AM, Enamex wrote:

  - template arguments that accept constant values of any type whatsoever
'template';


Still adding D features, I see!

[Issue 16207] New: CTFE cast from void* to ubyte* doesn't work

[via Digitalmars-d-bugs]

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

  Issue ID: 16207
   Summary: CTFE cast from void* to ubyte* doesn't work
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

int hashOf( const(void)[] buf )
{
auto data = cast(const(ubyte)*) buf.ptr;
return 3;
}

enum hashval = hashOf("Sample_string");

-

bug.d(4): Error: pointer cast from const(void)* to const(ubyte)* is not
supported at compile time
bug.d(8):called from here: hashOf("Sample_string")

--

Re: static if enhancement

[QAston via Digitalmars-d]

On Sunday, 26 June 2016 at 21:14:16 UTC, QAston wrote:
Also - metaprogramming. You don't know the control flow of 
whatever you may be printing in a mixin, or having as a 
parameter in a template. Making such code even more difficult 
to analyze.


Also, this couples runtime control flow with conditional 
compilation. Those are orthogonal and imo should be kept that 
way. For me, that's least surprising behavior.

Re: static if enhancement

[QAston via Digitalmars-d]

On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu 
wrote:
Does anyone else find this annoying? 
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei


Please no. I'd argue that this brings more confusion than 
readibility. Imagine reading more complicated code with this. You 
have to do control flow analysis on if-block to determine whether 
code outside of if block is included in compilation. Doesn't 
sound good for reading, does it.


Imagine explaining static if block rules to new people. "Well 
static if works this way, except it doesn't create scope. Also, 
we have this another special rule, where we create else blocks 
implicitly if all paths in static-if block return early. This 
saves you writing six characters and an intendation level."


Also - metaprogramming. You don't know the control flow of 
whatever you may be printing in a mixin, or having as a parameter 
in a template. Making such code even more difficult to analyze.

Re: GTKD - CSS class color "flash" delay

[TheDGuy via Digitalmars-d-learn]

On Sunday, 26 June 2016 at 16:29:52 UTC, Mike Wey wrote:


How about this:

private void letButtonsFlash(){
foreach(Button btn;bArr){
btn.setSensitive(false);
}
for(int i = 0; i < level; i++){
Button currentButton = bArr[rndButtonBlink[i]];
ListG list = 
currentButton.getStyleContext().listClasses();
string CSSClassName = 
to!string(cast(char*)list.next().data);
currentButton.getStyleContext().addClass(CSSClassName ~ 
"-flash");

}
Timeout t = new Timeout(_delay,1,false);
}

bool timeout_delay(){
for(int i = 0; i < level; i++){
Button currentButton = bArr[rndButtonBlink[i]];
ListG list = 
currentButton.getStyleContext().listClasses();
string CSSClassName = 
to!string(cast(char*)list.next().data);

currentButton.getStyleContext().removeClass(CSSClassName ~ 
"-flash");

}
foreach(Button btn;bArr){
btn.setSensitive(true);
}
return false;
}

Sets all the buttons to the flash color and after an timeout 
removes the flash color from all the buttons.


Thanks for your answer,

but as i said before, i want to flash each button on it's own 
(the game is kinda like 'Simon Says').

Re: C++17 is feature complete

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 26 June 2016 at 17:18:48 UTC, Enamex wrote:
  - specified order of evaluation for function calls and any 
syntax with arguments (including built-in operators on 
primitive types).


But not on the arguments, as that will harm optimization too 
much. I believe this change was triggered by the lack of 
transparency in expressions with more complicated "chaining" of 
function calls/function-objects.


So in "expr1(expr2,expr3)" expr1 is evaluated first, but expr2 
and expr3 can be evaluated in any order. Right?

Re: C++17 is feature complete

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 26 June 2016 at 18:16:32 UTC, Jack Stouffer wrote:
Please be excited for modules, coming out three years from now 
(plus implementation time).


It is actually a good thing that they delay modules. It is 
difficult to get right, but it is on a separate track so it can 
come before C++Next.


The most important parts of C++17 is related to ironing out 
language quirks and providing library additions: some significant 
improvements to meta-programming, file system support and C11 
support which brings in things like aligned_alloc.


There is a significant signal in reserving the namespace 
"std"+digits, meaning there will be a major standard library 
update in C++Next (related to "ranges").

Re: executeShell doesn't work but system does

[cym13 via Digitalmars-d-learn]

On Sunday, 26 June 2016 at 17:56:08 UTC, Satoshi wrote:

On Sunday, 26 June 2016 at 15:37:03 UTC, "Smoke" Adams wrote:
system("cls") works but executeShell doesn't. system is 
depreciated.


What's going on? The docs say that it creates a new process. I 
simply want to clear the console!



I have problem with executeShell on windows 10 (LDC 1.0.0) too.
When I rewrote it into http://prntscr.com/blc9j8 it works.


OT but please, refrain from using screenshots. I know it's very 
customary on windows but I can't copy paste code from a 
screenshot to play with it and manually copying is error-prone. 
We manipulate text, let's stay with it.

Re: 4x faster strlen with 4 char sentinel

[Jay Norwood via Digitalmars-d-announce]

On Sunday, 26 June 2016 at 16:59:54 UTC, David Nadlinger wrote:
Please keep general discussions like this off the announce 
list, which would e.g. be suitable for announcing a fleshed out 
collection of high-performance string handling routines.


A couple of quick hints:
 - This is not a correct implementation of strlen, as it 
already assumes that the array is terminated by four zero 
bytes. That iterating memory with a stride of 4 instead of 1 
will be faster is a self-evident truth.
 - You should be benchmarking against a "proper" SIMD-optimised 
strlen implementation.


 — David



This is more of just an observation that the choice of the single 
zero sentinel for C string termination comes at a cost of 4x 
strlen speed vs using four terminating zeros.


I don't see a SIMD strlen implementation in the D libraries.

The strlen2 function I posted works on any string that is 
terminated by four zeros, and returns the same len as strlen in 
that case, but much faster.


How to get strings initialized with four terminating zeros at 
compile time is a separate issue.  I don't know the solution, 
else I might consider doing more with this.

Re: C++17 is feature complete

[Jack Stouffer via Digitalmars-d]

On Sunday, 26 June 2016 at 17:18:48 UTC, Enamex wrote:

https://www.reddit.com/r/cpp/comments/4pmlpz/what_the_iso_c_committee_added_to_the_c17_working/

Added stuff like:
  - a very limited destructuring syntax (structured bindings) 
(use case is for tuples; but likely to use a new reserved 
function name for general struct destructuring (like 'get<>()' 
or something);
  - template arguments that accept constant values of any type 
whatsoever 'template';

  - 'constexpr if';
  - specified order of evaluation for function calls and any 
syntax with arguments (including built-in operators on 
primitive types).


Please be excited for modules, coming out three years from now 
(plus implementation time).

Re: Saturating integer arithmetic

[ketmar via Digitalmars-d]

On Sunday, 26 June 2016 at 13:59:03 UTC, Andrei Alexandrescu 
wrote:
See the recent thread "DbI checked integral". Saturation is a 
direct goal, and you should be able to optimize operations for 
each type by defining relatively small hooks.


alas, it is completely inappropriate for any computation-heavy 
task. even if dmd inliner will do some miracle and will inline 
some calls.

Re: Slice expressions - exact evaluation order, dollar

[Iain Buclaw via Digitalmars-d]

On 26 June 2016 at 14:33, Timon Gehr via Digitalmars-d
 wrote:
> On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote:
>>
>> Old codegen:
>>
>> _base = *(getBase());
>> _lwr = getLowerBound(_base.length);
>> _upr = getUpperBound(_base.length);
>> r = {.length=(_upr - _lwr), .ptr=_base.ptr + _lwr * 4};
>>
>> ---
>
>
> This seems to be what I'd expect. It's also what CTFE does.
> CTFE and run time behaviour should be identical. (So either one of them
> needs to be fixed.)
>
>

Very likely CTFE.  Anyway, this isn't the only thing where CTFE and
Runtime do things differently.

>> Now when creating temporaries of references, the reference is stabilized
>> instead.
>>
>> New codegen:
>>
>> *(_ptr = getBase());
>> _lwr = getLowerBound(_ptr.length);
>> _upr = getUpperBound(_ptr.length);
>> r = {.length=(_upr - _lwr), .ptr=_ptr.ptr + _lwr * 4};
>> ---
>>
>> I suggest you fix LDC if it doesn't already do this. :-)
>
>
>
> I'm not convinced this is a good idea. It makes (()=>base)()[lwr()..upr()]
> behave differently from base[lwr()..upr()].

No, sorry, I'm afraid you are wrong there. They should both behave
exactly the same.

I may need to step aside and explain what changed in GDC, as it had
nothing to do with this LDC bug.

==> Step

What made this subtle change was in relation to fixing bug 42 and 228
in GDC, which involved turning on TREE_ADDRESSABLE(type) bit in our
codegen trees, which in turn makes NRVO work consistently regardless
of optimization flags used - no more optimizer being confused by us
"faking it".

How is the above jargon related? Well, one of the problems faced was
that it must be ensured that lvalues continue being lvalues when
considering creating a temporary in the codegen pass.  Lvalue
references must have the reference stabilized, not the value that is
being dereferenced.  This also came with an added assurance that GDC
will now *never* create a temporary of a decl with a cpctor or dtor,
else it'll die with an internal compiler error trying. :-)

<== Step

(() => base)[lwr()..up()] will make a temporary of (() => base), but
guarantees that references are stabilized first.

base[lwr()..upr()] will create no temporary if base has no side
effects.  And so if lwr() modifies base, then upr() will get the
updated copy.

Re: executeShell doesn't work but system does

[Satoshi via Digitalmars-d-learn]

On Sunday, 26 June 2016 at 15:37:03 UTC, "Smoke" Adams wrote:
system("cls") works but executeShell doesn't. system is 
depreciated.


What's going on? The docs say that it creates a new process. I 
simply want to clear the console!



I have problem with executeShell on windows 10 (LDC 1.0.0) too.
When I rewrote it into http://prntscr.com/blc9j8 it works.

C++17 is feature complete

[Enamex via Digitalmars-d]

https://www.reddit.com/r/cpp/comments/4pmlpz/what_the_iso_c_committee_added_to_the_c17_working/

Added stuff like:
  - a very limited destructuring syntax (structured bindings) 
(use case is for tuples; but likely to use a new reserved 
function name for general struct destructuring (like 'get<>()' or 
something);
  - template arguments that accept constant values of any type 
whatsoever 'template';

  - 'constexpr if';
  - specified order of evaluation for function calls and any 
syntax with arguments (including built-in operators on primitive 
types).

Re: 4x faster strlen with 4 char sentinel

[David Nadlinger via Digitalmars-d-announce]

Hi Jay,

On Sunday, 26 June 2016 at 16:40:08 UTC, Jay Norwood wrote:
After watching Andre's sentinel thing, I'm playing with strlen 
on char strings with 4 terminating 0s instead of a single one.  
Seems to work and is 4x faster compared to the runtime version.


Please keep general discussions like this off the announce list, 
which would e.g. be suitable for announcing a fleshed out 
collection of high-performance string handling routines.



nothrow pure size_t strlen2(const(char)* c) {
 if (c is null)
   return 0;
 size_t l=0;
 while (*c){ c+=4; l+=4;}
 while (*c==0){ c--; l--;}
 return l+1;
}


A couple of quick hints:
 - This is not a correct implementation of strlen, as it already 
assumes that the array is terminated by four zero bytes. That 
iterating memory with a stride of 4 instead of 1 will be faster 
is a self-evident truth.
 - You should be benchmarking against a "proper" SIMD-optimised 
strlen implementation.


 — David

4x faster strlen with 4 char sentinel

[Jay Norwood via Digitalmars-d-announce]

After watching Andre's sentinel thing, I'm playing with strlen on 
char strings with 4 terminating 0s instead of a single one.  
Seems to work and is 4x faster compared to the runtime version.


nothrow pure size_t strlen2(const(char)* c) {
 if (c is null)
   return 0;
 size_t l=0;
 while (*c){ c+=4; l+=4;}
 while (*c==0){ c--; l--;}
 return l+1;
}

This is the timing of my test case, which I can post if anyone is 
interested.

strlen\Release>strlen
2738
681

Re: GTKD - CSS class color "flash" delay

[Mike Wey via Digitalmars-d-learn]

On 06/26/2016 05:03 PM, TheDGuy wrote:

On Sunday, 26 June 2016 at 12:30:22 UTC, Mike Wey wrote:


You should probably increment the index in the timeout_delay function.


This leads to a Range violation exception...


How about this:

private void letButtonsFlash(){
foreach(Button btn;bArr){
btn.setSensitive(false);
}
for(int i = 0; i < level; i++){
Button currentButton = bArr[rndButtonBlink[i]];
ListG list = currentButton.getStyleContext().listClasses();
string CSSClassName = to!string(cast(char*)list.next().data);
currentButton.getStyleContext().addClass(CSSClassName ~ "-flash");
}
Timeout t = new Timeout(_delay,1,false);
}

bool timeout_delay(){
for(int i = 0; i < level; i++){
Button currentButton = bArr[rndButtonBlink[i]];
ListG list = currentButton.getStyleContext().listClasses();
string CSSClassName = to!string(cast(char*)list.next().data);
currentButton.getStyleContext().removeClass(CSSClassName ~ 
"-flash");

}
foreach(Button btn;bArr){
btn.setSensitive(true);
}
return false;
}

Sets all the buttons to the flash color and after an timeout removes the 
flash color from all the buttons.


--
Mike Wey

Re: executeShell doesn't work but system does

[ag0aep6g via Digitalmars-d-learn]

On 06/26/2016 05:37 PM, Smoke Adams wrote:

system("cls") works but executeShell doesn't. system is depreciated.


Unsolicited spelling correction: no 'i' in "deprecated".


What's going on? The docs say that it creates a new process. I simply
want to clear the console!


`system` directly prints its output, `executeShell` returns it in a 
tuple with the status code. Maybe cls works by printing some specific 
clear code. If so, you have to print the output of the command.


This works with `clear` on Linux which seems to behave similarly to 
Windows' cls:



void main()
{
import std.stdio: write, writeln;
import std.process: executeShell;
import std.exception: enforce;
writeln("A");
auto r = executeShell("clear");
enforce(r.status == 0);
write(r.output);
writeln("B");
}


`wait(spawnShell(...))` is the other suggestion from `system`'s 
deprecation message. It works for `clear`, too:



void main()
{
import std.stdio: writeln;
import std.process: spawnShell, wait;
writeln("A");
wait(spawnShell("clear"));
writeln("B");
}

Re: DbI checked integral

[Andrei Alexandrescu via Digitalmars-d]

Robert burner Schadek  wrote:
> On Saturday, 25 June 2016 at 21:32:00 UTC, Andrei Alexandrescu 
> wrote:
>> So it stands to reason that if you want to design a checked 
>> integral types offering a variety of checking policies, one 
>> point in the design space that needs to be attainable is "no 
>> checks at all". Then the syntactic shell works the same as with 
>> any policy, and ideally there's no overhead at all.
> 
> There should be away to avoid all checks, true. But I think that 
> problem is solved by alias Int = * . 

I showed you with code examples that you cannot define a user-defined type
that is interchangeable with int. So a replacement for a checked int that
adds no checks is a UDT with no checks.

>I think we have to take 
> a step back and discuss what this type should actually be used 
> for.
> IMO it is a debug type and as such should have sensible default 
> debug features
> like. Default to NaN or throwing Exceptions.

That is a side discussion as trivial as deciding the defaul second argument
for Checked(T, Hook = DefaultHook).

This has nothing to do with the design. It is obvious to me that allowing
any combination of checks allows naturally for no check. It is also trivial
to enforce that at least one check is defined, so again I'd be hard pressed
to frame this as a design matter.


Andrei

executeShell doesn't work but system does

[Smoke Adams via Digitalmars-d-learn]

system("cls") works but executeShell doesn't. system is 
depreciated.


What's going on? The docs say that it creates a new process. I 
simply want to clear the console!

[Issue 16206] New: traits getOverloads fails when one of the overload is a templatized function

[via Digitalmars-d-bugs]

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

  Issue ID: 16206
   Summary: traits getOverloads fails when one of the overload is
a templatized function
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

And the declaration order matters:

struct Foo
{
void foo(A,Z)(A a, Z z){}
void foo(float v){}
}

struct Bar
{
void bar(float v){}
void bar(A,Z)(A a, Z z){}
}

void main()
{
static assert(__traits(getOverloads, Bar, "bar").length > 0); // OK
static assert(__traits(getOverloads, Foo, "foo").length > 0); // FAILS
}

making introspection imprevisible.

--

Re: GTKD - CSS class color "flash" delay

[TheDGuy via Digitalmars-d-learn]

On Sunday, 26 June 2016 at 12:30:22 UTC, Mike Wey wrote:


You should probably increment the index in the timeout_delay 
function.


This leads to a Range violation exception...

Re: Cpp/D interface semantic

[Guillaume Chatelet via Digitalmars-d]

On Sunday, 26 June 2016 at 14:48:00 UTC, Guillaume Chatelet wrote:
Johan I saw you created a few bugs for C++ name mangling. Can 
you assigne the one for Linux to me. I'm redesigning the 
algorithm and I need as many corner cases as possible.


Note: I'm only touching the 'Linux' C++ mangling code, so I'm 
only interested C++ mangling issues on the following platform: 
TARGET_LINUX, TARGET_OSX, TARGET_FREEBSD, TARGET_OPENBSD, 
TARGET_SOLARIS.

Re: Overloads

[ArturG via Digitalmars-d-learn]

On Sunday, 26 June 2016 at 11:23:14 UTC, Márcio Martins wrote:

Consider this snippet:

struct X {
  int foo(Args...)(Args args) if (Args.length > 1) { return 
Args.length; }


  int foo() { return 0; }

  int foo(int y) { return 1; }

  alias Name = string;

  int field_;
}


void listMembers(T)(ref T x) {
  foreach (Member; __traits(derivedMembers, T)) {
pragma(msg, Member, " ", __traits(getOverloads, x, 
Member).length);
//pragma(msg, __traits(getProtection, __traits(getMember, 
x, Member))); // Error: argument string has no protection

  }
}

void main() {
  X x;
  listMembers(x);
  //auto fptr =  // Error: x.foo(Args...)(Args args) if 
(Args.length > 0) is not an lvalue

}

Output:
foo 0LU
Name 0LU
field_ 0LU
foo 0LU
Name 0LU
field_ 0LU


There seems to be a few problems here:
1. It seems like getOverloads is returning 0 for 'foo' - is 
this a bug? Was expecting a 3 or at least a 2 if the template 
would be ignored.
2. That alias breaks getProtection - is this bug? Seems like it 
should be public.


These two make it quite hard to iterate over and collect info 
about arbitrary aggregates.


I want to get a list of all *public* members, including 
pointers to all public member functions and their overloads, 
excluding template member functions. This is turning out to be 
hard due to these "unexpected behaviors".


Is there anything else I can do?


__traits(getOverloads, x, Member).length works if you place the 
template after a function of the overloads and then it returns 2.


it fails as soon as the first member of the overload set is any 
template, so i guess it must be a bug.

e.g.

struct Fails
{
void foo()(){}
void foo(int){}
}

struct Works
{
void foo(int){}
void foo()(){}
}

__traits(getOverloads, Fails, "foo").length.writeln; // 0
__traits(getOverloads, Works, "foo").length.writeln; // 1

Re: Cpp/D interface semantic

[Guillaume Chatelet via Digitalmars-d]

On Sunday, 26 June 2016 at 09:28:19 UTC, Johan Engelen wrote:
On Sunday, 26 June 2016 at 07:51:16 UTC, Guillaume Chatelet 
wrote:


This is fine in the case where E is a D interface because of 
reference semantics: it should be passed by pointer.


But, in the case where an extern(C++) function calls an 
extern(C++) type should it be value semantic - as it is in C++ 
- or reference semantic - as it is in D?


I think the semantics should be D, so e.g. reference semantics 
for an extern(C++) class.
(This is all over ddmd source: many front-end classes are 
extern(C++)).


A related PR:
https://github.com/dlang/dmd/pull/5875


Sounds good to me.

Johan I saw you created a few bugs for C++ name mangling. Can you 
assigne the one for Linux to me. I'm redesigning the algorithm 
and I need as many corner cases as possible.


Current test set is here: 
https://github.com/gchatelet/dmd/tree/new_cpp_mangling2/test/mangling

[Issue 15970] C++ mangling of templated arg type

[via Digitalmars-d-bugs]

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

Guillaume Chatelet  changed:

   What|Removed |Added

 CC||chatelet.guilla...@gmail.co
   ||m
   Assignee|nob...@puremagic.com|chatelet.guilla...@gmail.co
   ||m
 OS|All |Linux

--

Re: Call to Action: making Phobos @safe

[Smoke Adams via Digitalmars-d]

On Saturday, 25 June 2016 at 22:44:37 UTC, Walter Bright wrote:
Andrei identified a key blocker for D adoption is the 
incomplete implementation of @safe. I'm working on the compiler 
end. But Phobos has a lot of code that is pointlessly not 
@safe, making it frustrating to write @safe code that calls 
Phobos. Some are listed in Bugzilla, most are not.


[...]



How hard would it be to add a compiler switch, similar to -vgs 
that shows every non-safe function? This would not just help out 
with phobos.

Re: Saturating integer arithmetic

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 26 June 2016 at 13:59:03 UTC, Andrei Alexandrescu 
wrote:

On 6/26/16 9:47 AM, Manu via Digitalmars-d wrote:
Hi people. I've been working on this colour library when I 
have free

time (almost never!), and I want to work on blending/filtering
functions, but that work is kinda blocked by saturating 
arithmetic

logic.
I started working on a saturating integer library a few times, 
but
it's much a much bigger job than it appears, and I haven't had 
enough
time for it. (Efficient) implementation tends to be 
significantly
different for every int width and signed/unsigned. I see no 
use for an
inefficient implementation used by a colour library; images 
tend to be

millions of pixels, and inefficiency very quickly adds up.


See the recent thread "DbI checked integral". Saturation is a 
direct goal, and you should be able to optimize operations for 
each type by defining relatively small hooks.


No, saturated operations are typically SIMD instructions.

Re: Saturating integer arithmetic

[Andrei Alexandrescu via Digitalmars-d]

On 6/26/16 9:47 AM, Manu via Digitalmars-d wrote:

Hi people. I've been working on this colour library when I have free
time (almost never!), and I want to work on blending/filtering
functions, but that work is kinda blocked by saturating arithmetic
logic.
I started working on a saturating integer library a few times, but
it's much a much bigger job than it appears, and I haven't had enough
time for it. (Efficient) implementation tends to be significantly
different for every int width and signed/unsigned. I see no use for an
inefficient implementation used by a colour library; images tend to be
millions of pixels, and inefficiency very quickly adds up.


See the recent thread "DbI checked integral". Saturation is a direct 
goal, and you should be able to optimize operations for each type by 
defining relatively small hooks.



I wonder if anyone has an interest in the area and wants to have a go
at it? It's a pretty big job.
It should support scalars, packed vectors (ie, 4 bytes in an int), and
SIMD vectors (wider vectors using hardware simd ops). Each step can
gain considerable efficiency for the vector width. It's hard to write
a useful colour blending library without the full set of these
available.


What primitives would the vectors implement?


Andrei

Saturating integer arithmetic

[Manu via Digitalmars-d]

Hi people. I've been working on this colour library when I have free
time (almost never!), and I want to work on blending/filtering
functions, but that work is kinda blocked by saturating arithmetic
logic.
I started working on a saturating integer library a few times, but
it's much a much bigger job than it appears, and I haven't had enough
time for it. (Efficient) implementation tends to be significantly
different for every int width and signed/unsigned. I see no use for an
inefficient implementation used by a colour library; images tend to be
millions of pixels, and inefficiency very quickly adds up.

I wonder if anyone has an interest in the area and wants to have a go
at it? It's a pretty big job.
It should support scalars, packed vectors (ie, 4 bytes in an int), and
SIMD vectors (wider vectors using hardware simd ops). Each step can
gain considerable efficiency for the vector width. It's hard to write
a useful colour blending library without the full set of these
available.

[Issue 15607] [ICE] CTFE internal error: bad compare on accessing default-initialized static immutable array of array

[via Digitalmars-d-bugs]

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

--- Comment #9 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/9394bf6e4c017aa9f3008f8bbb3594c04ab5e292
fix
Issue 15607 - [ICE] CTFE internal error: bad compare on accessing
default-initialized static immutable array of array

https://github.com/dlang/dmd/commit/8e4947ff5a80fbf2b0b34b2025a75cd9774b252a
Merge pull request #5796 from WalterBright/fix15607

fix Issue 15607 - [ICE] CTFE internal error: bad compare on accessing
default-initialized static immutable array of array

--

Re: Call to Action: making Phobos @safe

[Robert burner Schadek via Digitalmars-d]

It would be awesome if you would create that process model in the 
wiki and at it to your action list 
http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List


So it does not get lost and people can find it.

Re: DbI checked integral

[Robert burner Schadek via Digitalmars-d]

On Saturday, 25 June 2016 at 21:32:00 UTC, Andrei Alexandrescu 
wrote:
So it stands to reason that if you want to design a checked 
integral types offering a variety of checking policies, one 
point in the design space that needs to be attainable is "no 
checks at all". Then the syntactic shell works the same as with 
any policy, and ideally there's no overhead at all.


There should be away to avoid all checks, true. But I think that 
problem is solved by alias Int = * . I think we have to take 
a step back and discuss what this type should actually be used 
for.
IMO it is a debug type and as such should have sensible default 
debug features

like. Default to NaN or throwing Exceptions.

One good design principle is pushing policy up and 
implementation down. A NaN is a very specific policy, which is 
appropriate for a Hook definition but would look out of place 
in the Checked shell.


See my above argument. If it is a debug type, and that is what I 
think it is,

it should have sensible default hooks.

Re: A comparison between Rust and D

[Jacob Carlborg via Digitalmars-d]

On 24/06/16 19:26, maik klein wrote:

https://maikklein.github.io/post/cmp-rust-d/

https://www.reddit.com/r/programming/comments/4po2j5/a_comparison_between_rust_and_d/


It's possible in D to collect multiple functions for one set of 
constraints using a template:


template Foo(T) if (is(T : int))
{
void a(T x) {}
void b(T y) {}
}

--
/Jacob Carlborg

Re: GTKD - CSS class color "flash" delay

[Mike Wey via Digitalmars-d-learn]

On 06/26/2016 12:10 AM, TheDGuy wrote:

On Saturday, 25 June 2016 at 21:57:35 UTC, TheDGuy wrote:

But i want to flash (e.g. change the CSS class) the buttons one by one
and not all at the sime time? How am i going to do that?


Okay, i tried it with a new private int-variable which contains the
current index of the for-loop, like this:

private void letButtonsFlash(){
foreach(Button btn;bArr){
btn.setSensitive(false);
}
for(int i = 0; i < level; i++){
index = i; //index is public
Button currentButton = bArr[rndButtonBlink[i]];
ListG list = currentButton.getStyleContext().listClasses();
string CSSClassName = to!string(cast(char*)list.next().data);
currentButton.getStyleContext().addClass(CSSClassName ~
"-flash");
Timeout t = new Timeout(_delay,1,false);
}

foreach(Button btn;bArr){
btn.setSensitive(true);
}
}
bool timeout_delay(){
Button currentButton = bArr[rndButtonBlink[index]];
ListG list = currentButton.getStyleContext().listClasses();
string CSSClassName = to!string(cast(char*)list.next().data);
currentButton.getStyleContext().removeClass(CSSClassName ~
"-flash");
return false;
}

But now the strange thing happens, that the first button lights up as
expected but the second button remains at its "flash color" and doesn't
go back to normal color, i don't understand why this happens? Any ideas?


You should probably increment the index in the timeout_delay function.

--
Mike Wey

Re: Slice expressions - exact evaluation order, dollar

[Timon Gehr via Digitalmars-d]

On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote:


 > Evaluation order should be strictly left-to-right. DMD and GDC
get it wrong
 > here.
 >

It is evaluated left-to-right. getBase() -> getLowerBound() ->
getUpperBound().


Ah, I see what you mean.  I think you may be using an old GDC version.
Before I used to cache the result of getBase().

Old codegen:

_base = *(getBase());
_lwr = getLowerBound(_base.length);
_upr = getUpperBound(_base.length);
r = {.length=(_upr - _lwr), .ptr=_base.ptr + _lwr * 4};

---


This seems to be what I'd expect. It's also what CTFE does.
CTFE and run time behaviour should be identical. (So either one of them 
needs to be fixed.)




Now when creating temporaries of references, the reference is stabilized
instead.

New codegen:

*(_ptr = getBase());
_lwr = getLowerBound(_ptr.length);
_upr = getUpperBound(_ptr.length);
r = {.length=(_upr - _lwr), .ptr=_ptr.ptr + _lwr * 4};
---

I suggest you fix LDC if it doesn't already do this. :-)



I'm not convinced this is a good idea. It makes 
(()=>base)()[lwr()..upr()] behave differently from base[lwr()..upr()].

[Issue 15762] Array casts involving const enums can be made @safe

[via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 15762] Array casts involving const enums can be made @safe

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/932be192e3b5039778daf03ea77253a8806f676a
fix Issue 15762 - Array casts involving const enums can be made @safe

https://github.com/dlang/dmd/commit/a56ce297d1cfd2ef295a80abc8106c5be5f9fd19
Merge pull request #5878 from WalterBright/fix15762

fix Issue 15762 - Array casts involving const enums can be made @safe

--

Overloads

[Márcio Martins via Digitalmars-d-learn]

Consider this snippet:

struct X {
  int foo(Args...)(Args args) if (Args.length > 1) { return 
Args.length; }


  int foo() { return 0; }

  int foo(int y) { return 1; }

  alias Name = string;

  int field_;
}


void listMembers(T)(ref T x) {
  foreach (Member; __traits(derivedMembers, T)) {
pragma(msg, Member, " ", __traits(getOverloads, x, 
Member).length);
//pragma(msg, __traits(getProtection, __traits(getMember, x, 
Member))); // Error: argument string has no protection

  }
}

void main() {
  X x;
  listMembers(x);
  //auto fptr =  // Error: x.foo(Args...)(Args args) if 
(Args.length > 0) is not an lvalue

}

Output:
foo 0LU
Name 0LU
field_ 0LU
foo 0LU
Name 0LU
field_ 0LU


There seems to be a few problems here:
1. It seems like getOverloads is returning 0 for 'foo' - is this 
a bug? Was expecting a 3 or at least a 2 if the template would be 
ignored.
2. That alias breaks getProtection - is this bug? Seems like it 
should be public.


These two make it quite hard to iterate over and collect info 
about arbitrary aggregates.


I want to get a list of all *public* members, including pointers 
to all public member functions and their overloads, excluding 
template member functions. This is turning out to be hard due to 
these "unexpected behaviors".


Is there anything else I can do?

Re: PowerNex - New release of my D kernel

[Wild via Digitalmars-d-announce]

On Sunday, 26 June 2016 at 07:43:37 UTC, Werner wrote:

Latest release shows this: http://imgur.com/QOPsqkc.png


Looks like you didn't give it enough RAM.
What command did you run?

Re: Beta release vibe.d 0.7.29-beta.2

[Sönke Ludwig via Digitalmars-d-announce]

Am 02.06.2016 um 10:27 schrieb Sönke Ludwig:

The release candidate is planned for the 6th, so please take a moment to
test this release. Instead of `dub upgrade --prerelease`, edit
dub.selections.json directly and put 0.7.29-beta.2 as the vibe-d version
(there is already an alpha version of 0.7.30 out, so the upgrade would
pick that instead).

Main changes over 0.7.28:

  - Drops support for DMD frontend 2.066.x and below and adds support up
to 2.071.0
  - Removes all deprecated functionality, as well as the libev driver
  - Contains considerable performance improvement for URLRouter
  - Contains a critical fix for the Json struct, which was prone to
dangling pointers due to wrong alignment on x64
  - Hopefully removes all instances of "Manually resuming taks that is
already scheduled" assertion failures


The first release candidate is now out!

All changes:
https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md

DUB package:
http://code.dlang.org/packages/vibe-d/0.7.29-rc.1

[Issue 5555] [AA] Built-in associative arrays in pure nothrow functions

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |FIXED

--- Comment #11 from Walter Bright  ---
(In reply to Denis Shelomovskij from comment #10)
> (In reply to bearophile_hugs from comment #9)
> > I suggest to not close this issue until they are also @nogc.
> 
> https://github.com/D-Programming-Language/druntime/pull/840

This was merged. Closing.

--

[Issue 6357] [AA] Almost all AA methods are not pure/nothrow/@safe

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6357
Issue 6357 depends on issue , which changed state.

Issue  Summary: [AA] Built-in associative arrays in pure nothrow functions
https://issues.dlang.org/show_bug.cgi?id=

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 14242] destruction of static arrays with elaborate destructor elements does not propagate attributes

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe
 CC||bugzi...@digitalmars.com

--

Re: Should % ever "overflow"?

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 26 June 2016 at 00:54:04 UTC, Guillaume Boucher wrote:
If division truncates towards negative infinity, the remainder 
will always be nonegative (in case of a positive divisor).


Or even better, use euclidean division, then the reminder always 
remains non-negative:


https://en.wikipedia.org/wiki/Euclidean_division

[Issue 16205] New: core.sys.windows.oaidl.VARIANT missing fields

[via Digitalmars-d-bugs]

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

  Issue ID: 16205
   Summary: core.sys.windows.oaidl.VARIANT missing fields
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: johnch_a...@hotmail.com

There are a couple of fields missing from the VARIANT structure defined in
core.sys.windows.oaidl.

These fields need to be inserted:

  LONGLONG* pllVal;
  ULONGLONG* pullVal;

See
https://msdn.microsoft.com/en-gb/library/windows/desktop/ms221627(v=vs.85).aspx

--

Re: Slice expressions - exact evaluation order, dollar

[kinke via Digitalmars-d]

On Sunday, 26 June 2016 at 08:08:58 UTC, Iain Buclaw wrote:
Now when creating temporaries of references, the reference is 
stabilized instead.


New codegen:

*(_ptr = getBase());
_lwr = getLowerBound(_ptr.length);
_upr = getUpperBound(_ptr.length);
r = {.length=(_upr - _lwr), .ptr=_ptr.ptr + _lwr * 4};
---

I suggest you fix LDC if it doesn't already do this. :-)


Thx for the replies - so my testcase works for GDC already? So 
since what GDC is doing is what I came up for independently for 
LDC (PR #1566), I'd say DMD needs to follow suit.

Re: Cpp/D interface semantic

[Johan Engelen via Digitalmars-d]

On Sunday, 26 June 2016 at 07:51:16 UTC, Guillaume Chatelet wrote:


This is fine in the case where E is a D interface because of 
reference semantics: it should be passed by pointer.


But, in the case where an extern(C++) function calls an 
extern(C++) type should it be value semantic - as it is in C++ 
- or reference semantic - as it is in D?


I think the semantics should be D, so e.g. reference semantics 
for an extern(C++) class.
(This is all over ddmd source: many front-end classes are 
extern(C++)).


A related PR:
https://github.com/dlang/dmd/pull/5875

Re: Call to Action: making Phobos @safe

[Andre Pany via Digitalmars-d]

On Saturday, 25 June 2016 at 22:44:37 UTC, Walter Bright wrote:
Andrei identified a key blocker for D adoption is the 
incomplete implementation of @safe. I'm working on the compiler 
end. But Phobos has a lot of code that is pointlessly not 
@safe, making it frustrating to write @safe code that calls 
Phobos. Some are listed in Bugzilla, most are not.


So here's what to do:

1


Could we have a wiki page for this call to action? It would be 
much easier if there is a list of the modules and their current 
state like: completed or who is working on this module.


In general the call to actions topics disappears too fast in a 
forum. Maybe it worths to add them to the contributions group in 
the wiki?


Kind regards
Andre

Re: Slice expressions - exact evaluation order, dollar

[Iain Buclaw via Digitalmars-d]

On 26 June 2016 at 09:36, Iain Buclaw  wrote:

> On 26 June 2016 at 03:30, Timon Gehr via Digitalmars-d
>  wrote:
> > On 17.06.2016 21:59, kinke wrote:
> >>
> >>
> >> Most interesting IMO though is the question when the slicee's pointer is
> >> to be loaded. This is only relevant if the base is an lvalue and may
> >> therefore be modified when evaluating the bound expressions. Should the
> >> returned slice be based on the slicee's buffer before or after
> >> evaluating the bounds expressions?
> >> This has been triggered by
> >> https://github.com/ldc-developers/ldc/issues/1433 as LDC loads the
> >> pointer before evaluating the bounds.
> >
> >
> > Evaluation order should be strictly left-to-right. DMD and GDC get it
> wrong
> > here.
> >
>
> It is evaluated left-to-right. getBase() -> getLowerBound() ->
> getUpperBound().
>

Ah, I see what you mean.  I think you may be using an old GDC version.
Before I used to cache the result of getBase().

Old codegen:

_base = *(getBase());
_lwr = getLowerBound(_base.length);
_upr = getUpperBound(_base.length);
r = {.length=(_upr - _lwr), .ptr=_base.ptr + _lwr * 4};

---
Now when creating temporaries of references, the reference is stabilized
instead.

New codegen:

*(_ptr = getBase());
_lwr = getLowerBound(_ptr.length);
_upr = getUpperBound(_ptr.length);
r = {.length=(_upr - _lwr), .ptr=_ptr.ptr + _lwr * 4};
---

I suggest you fix LDC if it doesn't already do this. :-)

Cpp/D interface semantic

[Guillaume Chatelet via Digitalmars-d]

This is currently part of the dmd test suite [1]:


extern (C++) interface E
{
int bar(int i, int j, int k);
}

extern (C++) int callE(E);

static assert (callE.mangleof == "_Z5callEP1E");


The last line checks that callE() will pass its argument by 
pointer.


This is fine in the case where E is a D interface because of 
reference semantics: it should be passed by pointer.


But, in the case where an extern(C++) function calls an 
extern(C++) type should it be value semantic - as it is in C++ - 
or reference semantic - as it is in D?


Thoughts?

--
1. 
https://github.com/dlang/dmd/blob/master/test/compilable/cppmangle.d#L102

Re: PowerNex - New release of my D kernel

[Werner via Digitalmars-d-announce]

Latest release shows this: http://imgur.com/QOPsqkc.png

Re: Slice expressions - exact evaluation order, dollar

[Iain Buclaw via Digitalmars-d]

On 26 June 2016 at 03:30, Timon Gehr via Digitalmars-d
 wrote:
> On 17.06.2016 21:59, kinke wrote:
>>
>>
>> Most interesting IMO though is the question when the slicee's pointer is
>> to be loaded. This is only relevant if the base is an lvalue and may
>> therefore be modified when evaluating the bound expressions. Should the
>> returned slice be based on the slicee's buffer before or after
>> evaluating the bounds expressions?
>> This has been triggered by
>> https://github.com/ldc-developers/ldc/issues/1433 as LDC loads the
>> pointer before evaluating the bounds.
>
>
> Evaluation order should be strictly left-to-right. DMD and GDC get it wrong
> here.
>

It is evaluated left-to-right. getBase() -> getLowerBound() -> getUpperBound().

Re: Project Highlight: The PowerNex Kernel

[Satoshi via Digitalmars-d-announce]

On Saturday, 25 June 2016 at 18:42:20 UTC, Wild wrote:

On Friday, 24 June 2016 at 15:09:41 UTC, Satoshi wrote:

On Friday, 24 June 2016 at 14:09:12 UTC, Mike Parker wrote:
Not that long ago, Dan Printzell announced his D OS Kernel, 
PowerNex [1], in this forum. It is now the subject of the 
first project highlight on the D Blog [2].


[1] https://github.com/Vild/PowerNex
[2] 
http://dlang.org/blog/2016/06/24/project-highlight-the-powernex-kernel/



Its funny how he took existing sources from my OS 
https://github.com/Rikarin/Trinix
rewrite it during stream session on Livecoding and get more 
popularity than my OS.


Do you want me to remove all the code that is influenced by 
your code in the kernel and rewrite from scratch?


Because I don't want my project to contain 
illegal/controversial code.


no

Re: Should % ever "overflow"?

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 26 June 2016 at 05:28:53 UTC, Shachar Shemesh wrote:

So, we can do it your way. This would mean:
1. Losing performance for every division and modulus that 
*might* be negative


I don't think the performance issue is relevant. It was relevant 
when it was left implementation defined in C, but it is no longer 
the case so it was defined to be consistent with signed integer 
division in C-99. The sane thing to do from a system programming 
point of view is to have strong typing and 3 versions:


1. "x % y" only defined on unsigned integers
2. rem(x,y) for reminder from truncated division
3. mod(x,y) for reminder from floored division

Unfortunately implictly casting ints to uints is a very bad idea 
when you want a reasonably safe type-system.

Re: Should % ever "overflow"?

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 26 June 2016 at 05:44:53 UTC, deadalnix wrote:
Except for mathematica, these are all irrelevant. The claim is 
that programming languages and CPU define % in some way, not 
that mathematician do it the same way.


Well, the CPU does not define it. It is just that C botchered it 
by leaving "%" implementation defined up til 1999, where they 
went with the truncated reminder and not the floored modulo 
operator. In system level programming you usually need the modulo 
 (reminder for floored division) and not the C-style reminder 
(reminder from truncated division):


https://en.wikipedia.org/wiki/Modulo_operation

Interestingly Simula, Ada, Fortran, Common Lisp and other high 
level languages provids both "rem(x,y)" and "mod(x,y)", which is 
the right thing to do.

dmd (>2.068) compiler error

[ted via Digitalmars-d]

Unsure of exactly how to communicate this one, so posting here.


Compilation of https://github.com/dcarp/asynchronous.
Using 'dub --verbose build' produces:
dmd -lib 
-of.dub/build/library-debug-linux.posix-x86_64-dmd_2071-7450FEAE5605F646044C35441C27D67E/libasynchronous.a
 -debug -g -w -version=CryptoSafe -
version=Have_asynchronous -version=Have_libasync -version=Have_memutils -Isrc/ 
-I../../../../.dub/packages/libasync-0.7.9/libasync/source/ -
I../../../../.dub/packages/memutils-0.4.6/memutils/source/ 
src/asynchronous/events.d src/asynchronous/futures.d 
src/asynchronous/libasync/events.d 
src/asynchronous/locks.d src/asynchronous/package.d 
src/asynchronous/protocols.d src/asynchronous/queues.d 
src/asynchronous/streams.d 
src/asynchronous/tasks.d src/asynchronous/transports.d src/asynchronous/types.d 
-vcolumns
Enhanced memory security is enabled.
Memory debugger enabled
../../../../.dub/packages/libasync-0.7.9/libasync/source/libasync/internals/socket_compat.d(57,16):
 Deprecation: module std.c.linux.socket is deprecated - 
Import the appropriate core.sys.posix.* modules instead
Using Linux EPOLL for events

(successful compile) So far, so good.

However, if I do not use dub to compile the code, and compile into individual 
object files, then for the following file:

/usr/bin/dmd -ofbuild/events.d.o -debug -g -w -version=CryptoSafe 
-version=Have_asynchronous -version=Have_libasync -version=Have_memutils -Isrc  
  -
I../../../../.dub/packages/memutils-0.4.6/memutils/source/ 
-I../../../../.dub/packages/libasync-0.7.9/libasync/source/ -c 
src/asynchronous/libasync/events.d



for any dmd >2.068 causes the following error:
dmd: glue.c:809: void FuncDeclaration_toObjFile(FuncDeclaration*, bool): 
Assertion `fd->semanticRun == PASSsemantic3done' failed.
Aborted

However, it works find for dmd.2.068.

Any ideas?

Re: Call to Action: making Phobos @safe

[Jonathan M Davis via Digitalmars-d]

On Sunday, June 26, 2016 06:29:05 Tourist via Digitalmars-d wrote:
> On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
> > On 6/25/2016 3:44 PM, Walter Bright wrote:
> >> 4. Add @safe to the unittest
> >
> > A unittest that is deliberately unsafe should be annotated with
> > @system. Meaning that any un-annotated unittest needs
> > corrective action one way or the other.
>
> So why not declare @safe module-wise, and only add @system
> annotations where needed?

In general, IMHO, mass applying attributes is a bad idea, because it makes
it harder to know which attributes apply where, which is a maintenance
problem. However, even worse than that, while there it _is_ possible to
apply @safe to the module as a whole and then selectively apply @trusted and
@system explicitly, there is no way to turn off all of the @safety
attributes so that attribute inference can be used. And other attributes
can't be undone at all. So, if you have templates in a module, mass applying
attributes is a disaster.

- Jonathan M Davis

Re: Call to Action: making Phobos @safe

[Tourist via Digitalmars-d]

On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:

On 6/25/2016 3:44 PM, Walter Bright wrote:

4. Add @safe to the unittest


A unittest that is deliberately unsafe should be annotated with 
@system. Meaning that any un-annotated unittest needs 
corrective action one way or the other.


So why not declare @safe module-wise, and only add @system 
annotations where needed?