[Issue 14835] Statement is not reachable doesn't play along generic code

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #8 from Walter Bright  ---
It seems the problem lies here:

https://github.com/dlang/dmd/blob/master/src/statement.d#L453

if (s.condition.isBool(true))
{
if (s.ifbody)
result |= s.ifbody.blockExit(func, mustNotThrow);
else
result |= BEfallthru;
}
else if (s.condition.isBool(false))
{
if (s.elsebody)
result |= s.elsebody.blockExit(func, mustNotThrow);
else
result |= BEfallthru;
}
else

Having it set BEfallthru as if both ifbody and elsebody could execute should
work, but I wonder about its affect on existing code.

--

Re: Article: Increasing the performance of D math code

[Walter Bright via Digitalmars-d-announce]

On 10/11/2016 7:01 AM, Johan Engelen wrote:

I wrote a piece on LDC's fastmath stuff that Mir uses for high-performance D
math code:

https://johanengelen.github.io/ldc/2016/10/11/Math-performance-LDC.html


Articles like this are great! Keep 'em coming.

Re: How to do "inheritance" in D structs

[lobo via Digitalmars-d-learn]

On Wednesday, 12 October 2016 at 02:18:47 UTC, TheFlyingFiddle 
wrote:

On Wednesday, 12 October 2016 at 01:22:04 UTC, lobo wrote:

Hi,

I'm coming from C++ and wondered if the pattern below has an 
equivalent in D using structs. I could just use classes and 
leave it up to the caller to use scoped! as well but I'm not 
sure how that will play out when others start using my lib.


Thanks,
lobo


module A;

class Base1 {
int ival = 42;
}
class Base2 {
int ival = 84;
}

module B;

class S(ABase) : ABase {
string sval = "hello";
}

module C;

import A;
import B;

void main() {
auto s= scoped!(S!Base1); // scoped!(S!Base2)
}


You could use "alias this" to simulate that type of inheritence.

module A;
struct Base1
{
int ival = 42;
}

module B;

struct Base2
{
int ival = 84;
}

module C;
import A, B;

struct S(Base) if(is(Base == struct))
{
Base base;
alias base this;
string sval = "Hello ";
}

void foo(ref ABase base)
{
base.ival = 32;
}

void main()
{
S!Base1 a;
S!Base2 b;
writeln(a.sval, a.ival);
writeln(b.sval, b.ival);
foo(a);
writeln(a.sval, a.ival);
}


This approach works nicely although it feels clumsy but that's 
probably just because I'm so used to C++. It also handles private 
members as I'd expect, i.e. they're not accessible outside module 
scope through the alias struct instance, but there is no 
protected. Protected appears to behave the same way as private.


I think I can live with that because I usually try to avoid 
protected anyway.


Thanks,
lobo

Re: How to do "inheritance" in D structs

[TheFlyingFiddle via Digitalmars-d-learn]

On Wednesday, 12 October 2016 at 02:18:47 UTC, TheFlyingFiddle 
wrote:

void foo(ref ABase base)
{
base.ival = 32;
}

This should be:
void foo(ref Base1 base)
{
base.ival = 32;
}

Re: How to do "inheritance" in D structs

[TheFlyingFiddle via Digitalmars-d-learn]

On Wednesday, 12 October 2016 at 01:22:04 UTC, lobo wrote:

Hi,

I'm coming from C++ and wondered if the pattern below has an 
equivalent in D using structs. I could just use classes and 
leave it up to the caller to use scoped! as well but I'm not 
sure how that will play out when others start using my lib.


Thanks,
lobo


module A;

class Base1 {
int ival = 42;
}
class Base2 {
int ival = 84;
}

module B;

class S(ABase) : ABase {
string sval = "hello";
}

module C;

import A;
import B;

void main() {
auto s= scoped!(S!Base1); // scoped!(S!Base2)
}


You could use "alias this" to simulate that type of inheritence.

module A;
struct Base1
{
int ival = 42;
}

module B;

struct Base2
{
int ival = 84;
}

module C;
import A, B;

struct S(Base) if(is(Base == struct))
{
Base base;
alias base this;
string sval = "Hello ";
}

void foo(ref ABase base)
{
base.ival = 32;
}

void main()
{
S!Base1 a;
S!Base2 b;
writeln(a.sval, a.ival);
writeln(b.sval, b.ival);
foo(a);
writeln(a.sval, a.ival);
}

How to do "inheritance" in D structs

[lobo via Digitalmars-d-learn]

Hi,

I'm coming from C++ and wondered if the pattern below has an 
equivalent in D using structs. I could just use classes and leave 
it up to the caller to use scoped! as well but I'm not sure how 
that will play out when others start using my lib.


Thanks,
lobo


module A;

class Base1 {
int ival = 42;
}
class Base2 {
int ival = 84;
}

module B;

class S(ABase) : ABase {
string sval = "hello";
}

module C;

import A;
import B;

void main() {
auto s= scoped!(S!Base1); // scoped!(S!Base2)
}

Re: Communication between 2 Socket listener on 2 different port with one program and server.

[Jonathan Marler via Digitalmars-d]

On Tuesday, 11 October 2016 at 16:59:56 UTC, vino wrote:

Hi All,

  Need your help, on the below request.

Requirement:
Server:
2 socket listening to 2 different ports with one main program
Socket1 Port1 (Used for receiving user request(user data))
Socket2 Port2 (Used for system request(system data))

User request arrives via Socket1:Port1 needs to be sent 
Socket2:Port2
Once the request arrives then the request has to be sent to the 
Manger(another server) via Socket2:Port2


I was able to program to run multiple socket and send request 
to Socket1:Port1 but not able to send the same request to 
Socket2:Port2 tried both options sendTo and receiveFrom but no 
luck.


Note: the user request should to directly reach the 
Manger(another server) it should is always follow the data 
communication layer which is Socket2:Port2 as the
server Manger will connect via Socket2:Port2(only) to receive 
data.



void main () {
auto ext  = new Thread().start();
auto int  = new Thread().start();
}

void ext () {
ushort extport  = 1120;
Socket ext;
char[1024] buf;
Address mainserver = new InternetAddress("server1", 1121);
ext = new TcpSocket();
ext.bind(1120);
ext.listen(1);
ext.accpet();
ext.receive(buf[]);
writeln(buf[0..1024]);
ext.sendTo(buf[0..1024], SocketFlags.NONE, mainserver);


There's quite a few things wrong with this, I'm guessing you 
don't have much experience with socket programming, but that's 
ok, everyone's gotta start somewhere. You should read some 
articles on socket programming, but I'll give you a few 
corrections for your example.


void ext () {
ushort extport  = 1120;


Address mainserver = new InternetAddress("server1", 1121);
ext = new TcpSocket();
ext.bind(1120);
ext.listen(1);


Not sure why you are using "server1" here, the listen address 
acts as a "filter" on where you accept connections from.  You 
probably want to allow connections from any ip address in which 
case you would want to pass the "any" address.  You probably want 
to create this socket more like this:


auto listenAddress = new 
InternetAddress(InternetAddress.ADDR_ANY, 1121);
Socket listenSocket = new Socket(listenAddress.family, 
SocketType.STREAM, ProtocolType.TCP);

listenSocket.bind(listenAddress);
listenSocket.listen(8); // lookup "listen" function to understand 
what the "backlog" argument is


Another common address to use is the LOOPBACK address, which 
means you only accept connections from the local machine (not 
from any remote machine)



ext.accpet();


Here you've missed the fact that ext.accept actually returns the 
socket you can call send/receive on.  Here's what you should have 
done:


Socket dataSocket = listenSocket.accpet();

You can't actually send/receive data on the listen socket.  You 
will have 1 listen socket that's listening for connections.  
Every time you get a connection, the accept function will return 
a new socket that you can send/receive data with for that 
connection.



ext.receive(buf[]);


If you call "receive" on the data socket, you are now blocking 
the listen socket from accepting more connections.  That may be 
ok for your application, but for some applications, they will 
start a new thread to handle the data socket, and put the listen 
socket accept into a loop, something like this:


while(true) {
Socket dataSocket = listenSocket.accept();
// now pass the data socket to a new thread and call receive 
on that thread
// in the meantime, call accept again for any new connections 
that may come in

}

// The dataSocket thread can then call receive, and print the 
contents to the console like you had in your example.

void dataSocketThread()
{
ubyte[1024] buf;
auto received = dataSocket.receive(buf);
writeln(buf[0..received]);
}

// Now if you want to send this data to the other listen socket, 
you'll need to create a new socket, call connect, then you can 
call send


Socket newDataSocket = new Socket(...).
newDataSocket.Connect(...)
newDataSocket.send(buf[0..received]);
newDataSocket.shtudown(SD_BOTH);
newDataSocket.close();

You cannot call "sendto" on a data socket.  sendto is for UDP 
sockets, which you are not using in this case.  For more 
information, lookup a tutorial on writing a UDP echo 
client/server.


Some more notes, if you don't to start a new thread every time 
you accept a new connection, you can use asynchronous IO.  You 
can start by learning the "select" function and work your way up 
to more complex apis.  Each OS has their own underlying 
mechanisms for async io, but there are also libraries you can use 
like libev, libevent, libuv.


There's alot to learn about socket programming, this is just the 
beginning.  I tried to throw together a fair bit of information 
in a little amount of time, hopefully you'll be able to take this 
information and build on it.  Good luck.

Re: Any relation?

[Israel via Digitalmars-d]

On Tuesday, 11 October 2016 at 18:13:53 UTC, Andrei Alexandrescu 
wrote:

http://indianautosblog.com/2016/10/most-powerful-suzuki-swift-produces-350-hp-25
 -- Andrei


Obviously the ECU is programmed in D.

oh wait...

What influenced D? - goals, ideas, concepts, language features?

[A D dev via Digitalmars-d]

Hi list,

I'm liking D as I keep using it (still new to it), and interested 
in how it evolved, hence this question.


I have seen the Wikipedia article about D:

https://en.wikipedia.org/wiki/D_(programming_language)

which mentions language influences (right sidebar). I've also 
read some other articles on dlang sites, but thought of posting 
this question, to hear interesting stuff from people who know 
more about this.


Thanks to all who reply.

Re: Any relation?

[Ali Çehreli via Digitalmars-d]

On 10/11/2016 12:53 PM, Dennis Ritchie wrote:

On Tuesday, 11 October 2016 at 19:43:07 UTC, cym13 wrote:

On Tuesday, 11 October 2016 at 18:58:09 UTC, Dennis Ritchie wrote:

On Tuesday, 11 October 2016 at 18:13:53 UTC, Andrei Alexandrescu wrote:

http://indianautosblog.com/2016/10/most-powerful-suzuki-swift-produces-350-hp-25
-- Andrei


Yes, definitely.
http://dlanguage-z.com/about.html


Hmm... care to explain? It might sound somewhat obvious but this is
written in Japanese.


Here's how you can explain the connection D and this car:
http://imgur.com/cG0IWOp


I can also find the words "system", "main", and "garage" [sic]. ;)

Ali

Determining if a class has a template function

[Straivers via Digitalmars-d-learn]

I have a class T with a templated function foo(string name)(int, 
int, float) that will be mixed in via template, and I want to 
determine if that class has mixed it in such that foo(name = 
"bar"). How could I go about this? Thanks.


eg:

mixin template A(string name, Args...) {
void foo(string fooName)(Args args)
if (fooName == name) {}
}

template hasFoo(string name, A) {
enum hasFoo = ???
}

class B {
mixin A!("mash", int, int, string);
}

Re: passing static arrays to each! with a ref param [Re: Why can't static arrays be sorted?]

[Jon Degenhardt via Digitalmars-d-learn]

On Tuesday, 11 October 2016 at 19:46:31 UTC, Jon Degenhardt wrote:

On Tuesday, 11 October 2016 at 18:18:41 UTC, ag0aep6g wrote:

On 10/11/2016 06:24 AM, Jon Degenhardt wrote:
The example I gave uses ref parameters. On the surface it 
would seem
reasonable to that passing a static array by ref would allow 
it to be

modified, without having to slice it first.


Your ref parameters are only for the per-element operations. 
You're not passing the array as a whole by reference. And you 
can't, because `each` itself takes the whole range by copy.


So, the by-ref increments themselves do work, but they're 
applied to a copy of your original static array.


I see. Thanks for the explanation. I wasn't thinking it through 
properly. Also, I guess I had assumed that the intent was that 
each! be able to modify the elements, and therefore the whole 
array it would be pass by reference, but didn't consider it 
properly.


Another perspective where the current behavior could be confusing 
is that it is somewhat natural to assume that 'each' is the 
functional equivalent of foreach, and that they can be used 
interchangeably. However, for static arrays they cannot be.

Re: Any relation?

[Dennis Ritchie via Digitalmars-d]

On Tuesday, 11 October 2016 at 19:43:07 UTC, cym13 wrote:
On Tuesday, 11 October 2016 at 18:58:09 UTC, Dennis Ritchie 
wrote:
On Tuesday, 11 October 2016 at 18:13:53 UTC, Andrei 
Alexandrescu wrote:

http://indianautosblog.com/2016/10/most-powerful-suzuki-swift-produces-350-hp-25
 -- Andrei


Yes, definitely.
http://dlanguage-z.com/about.html


Hmm... care to explain? It might sound somewhat obvious but 
this is written in Japanese.


Here's how you can explain the connection D and this car:
http://imgur.com/cG0IWOp

Re: passing static arrays to each! with a ref param [Re: Why can't static arrays be sorted?]

[Jon Degenhardt via Digitalmars-d-learn]

On Tuesday, 11 October 2016 at 18:18:41 UTC, ag0aep6g wrote:

On 10/11/2016 06:24 AM, Jon Degenhardt wrote:
The example I gave uses ref parameters. On the surface it 
would seem
reasonable to that passing a static array by ref would allow 
it to be

modified, without having to slice it first.


Your ref parameters are only for the per-element operations. 
You're not passing the array as a whole by reference. And you 
can't, because `each` itself takes the whole range by copy.


So, the by-ref increments themselves do work, but they're 
applied to a copy of your original static array.


I see. Thanks for the explanation. I wasn't thinking it through 
properly. Also, I guess I had assumed that the intent was that 
each! be able to modify the elements, and therefore the whole 
array it would be pass by reference, but didn't consider it 
properly.


I'm not going to make any suggestions about whether the behavior 
should be changed. At some point when I get a bit of time I'll 
try to submit a documentation change to make the current behavior 
clearer.


--Jon

Re: Any relation?

[cym13 via Digitalmars-d]

On Tuesday, 11 October 2016 at 18:58:09 UTC, Dennis Ritchie wrote:
On Tuesday, 11 October 2016 at 18:13:53 UTC, Andrei 
Alexandrescu wrote:

http://indianautosblog.com/2016/10/most-powerful-suzuki-swift-produces-350-hp-25
 -- Andrei


Yes, definitely.
http://dlanguage-z.com/about.html


Hmm... care to explain? It might sound somewhat obvious but this 
is written in Japanese.

Re: Working with ranges: mismatched function return type inference

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, October 11, 2016 10:42:42 Ali Çehreli via Digitalmars-d-learn 
wrote:
> Those interfaces already exist in Phobos: :)
>
>https://dlang.org/phobos/std_range_interfaces.html
>
> auto foo(int[] ints) {
>import std.range;
>if (ints.length > 10) {
>return
> cast(RandomAccessFinite!int)inputRangeObject(chain(ints[0..5], ints[8..$]));
> } else {
>return cast(RandomAccessFinite!int)inputRangeObject(ints);
>}
> }
>
> void main() {
>  import std.stdio;
>  import std.range;
>  import std.algorithm;
>  writeln(foo([1, 2, 3]));
>  writeln(foo(iota(20).array));
> }

And in this case, if you were considering doing that, you might as well just
concatenate the dynamic arrays rather than chaining them, because using
interfaces means allocating on the heap just like you would with
concatenating.

About the only time that using interfaces is the right solution with ranges
is when you're dealing with virtual functions (which can't be templatized),
and even then, it's not necessarily the best choice. Here, IMHO, it makes no
sense at all.

- Jonathan M Davis

[Issue 16608] 'static foreach', nested function template, 'static if', anySatisfy: Only the first iteration seems to work

[via Digitalmars-d-bugs]

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

Ali Cehreli  changed:

   What|Removed |Added

Summary|'static foreach', local |'static foreach', nested
   |function template, 'static  |function template, 'static
   |if', anySatisfy: Only the   |if', anySatisfy: Only the
   |first iteration seems to|first iteration seems to
   |work|work

--

[Issue 16608] 'static foreach', local function template, 'static if', anySatisfy: Only the first iteration seems to work

[via Digitalmars-d-bugs]

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

--- Comment #1 from Ali Cehreli  ---
Johan Engelen notes that the problem is because the local function is generated
only for the first iteration:

http://ldc.acomirei.ru/#compilers:!((compiler:ldc,options:%27-release+-O3+-boundscheck%3Doff+-mtriple%3Dx86_64-pc-windows%27,sourcez:JYWwDg9gTgLgBAZxgEwHQgKYwIYG4BQ%2BAbhMMnCNsAHYAUAlHAN74CQAZtBtgMYAWcWglxwAggBtg2BAGUMARwCEtAETYVAGjgqARivqMWcYyeMB6M3AAqfDHDBQIO8RhBxgCODD7Z43j3DsAK7UPDDAENTunjzY4i7kkeIAnoHQ2ur4pqY6EBDicDyRyMDhkUIwUDQA5nAAHvQMzFnZrQ7Y1ZS0IAjVWipF4NhV1LWa9f1w2NTk4wj0BK2tUFhBUFF1cAC8W4iLSwC%2BhEtwFtZ8AUUzpRFRARh1YBhhGOQwEHA6dpVBdpxQXls2j07hgGCgvluLVaSEhPHc7EE02SMkhCHYyWUVxKZWo/T0BmaJ1M7U62G6vX6yQwnn%2B2i0832rSOJww4gQdiMxOMpK6PT62gAcgB5NIAuYLaHZI5sI4HIA)),filterAsm:(commentOnly:!t,directives:!t,labels:!t),version:3

--

[Issue 16608] 'static foreach', local function template, 'static if', anySatisfy: Only the first iteration seems to work

[via Digitalmars-d-bugs]

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

Ali Cehreli  changed:

   What|Removed |Added

   Priority|P1  |P3

--

[Issue 16608] New: 'static foreach', local function template, 'static if', anySatisfy: Only the first iteration seems to work

[via Digitalmars-d-bugs]

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

  Issue ID: 16608
   Summary: 'static foreach', local function template, 'static
if', anySatisfy: Only the first iteration seems to
work
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: acehr...@yahoo.com

import std.meta;

void main() {
foreach (s; AliasSeq!("a", "b")) {

// The problem is that this function is called only for the "a"
iteration
bool condition(string x)() {
pragma(msg, "comparing ", x, " and ", s);
return x == s;
}

// This condition is expected to be true for the "b" iteration
static if (anySatisfy!(condition, AliasSeq!("b"))) {
pragma(msg, "yes for ", s);
}
else {
pragma(msg, "NO for ", s);
}
}
}

However, the condition() is called only for "a" and we get "NO" for the "b"
iteration as well:

comparing b and a
NO for a
NO for b   <-- Why didn't we get "comparing b and b" before this?

Ali

--

Re: Working with ranges: mismatched function return type inference

[orip via Digitalmars-d-learn]

On Tuesday, 11 October 2016 at 18:09:26 UTC, ag0aep6g wrote:

You've got some options:
Wow, thanks everyone, great information! I think I understand my 
options now.

Re: Any relation?

[Dennis Ritchie via Digitalmars-d]

On Tuesday, 11 October 2016 at 18:13:53 UTC, Andrei Alexandrescu 
wrote:

http://indianautosblog.com/2016/10/most-powerful-suzuki-swift-produces-350-hp-25
 -- Andrei


Yes, definitely.
http://dlanguage-z.com/about.html

Re: Article: Increasing the performance of D math code

[cym13 via Digitalmars-d-announce]

On Tuesday, 11 October 2016 at 18:01:47 UTC, Johan Engelen wrote:

On Tuesday, 11 October 2016 at 17:29:47 UTC, Ali Çehreli wrote:

On 10/11/2016 07:01 AM, Johan Engelen wrote:
> I wrote a piece on LDC's fastmath stuff that Mir uses for
> high-performance D math code:
>
> 
https://johanengelen.github.io/ldc/2016/10/11/Math-performance-LDC.html

>
> cheers,
>   Johan

Kind of off topic and hopefully constructive critism: You have 
sentence that starts with "I’m afraid it won’t be a nice 
read..." on Reddit. No matter how correct, there is no need to 
use negative marketing for your work. :) How about something 
more positive like "I'm sure you'll enjoy this more if you're 
familiar with...". ;)


Something to keep in mind next time!


I agree, be it only because I feel that even people with only 
vague knowledge of assembly and SIMD can benefit from this 
article. That was a nice read, thank you :)

Re: Any relation?

[Martin Krejcirik via Digitalmars-d]

On Tuesday, 11 October 2016 at 18:13:53 UTC, Andrei Alexandrescu 
wrote:

http://indianautosblog.com/2016/10/most-powerful-suzuki-swift-produces-350-hp-25
 -- Andrei


There is no Kenji Hara in the team, so I would say no :)

Re: Any relation?

[Ali Çehreli via Digitalmars-d]

On 10/11/2016 11:13 AM, Andrei Alexandrescu wrote:

http://indianautosblog.com/2016/10/most-powerful-suzuki-swift-produces-350-hp-25
-- Andrei


I think so:

- D-Language: check

- Most powerful: check

- Japan: check

- squeeze out [...] power: check

- not street-legal: check (similar to D being a gun at a knife fight ;) )

And this changes the programming language car analogy for D. Now we know 
how to answer that question. :)


Ali

Re: passing static arrays to each! with a ref param [Re: Why can't static arrays be sorted?]

[ag0aep6g via Digitalmars-d-learn]

On 10/11/2016 06:24 AM, Jon Degenhardt wrote:

The example I gave uses ref parameters. On the surface it would seem
reasonable to that passing a static array by ref would allow it to be
modified, without having to slice it first.


Your ref parameters are only for the per-element operations. You're not 
passing the array as a whole by reference. And you can't, because `each` 
itself takes the whole range by copy.


So, the by-ref increments themselves do work, but they're applied to a 
copy of your original static array.


Question is, should `each`

1) take all inputs (ranges, arrays, other foreachables) by reference, or
2) take some inputs (like static arrays) by reference, or
3) take all inputs by value (current behavior)?

#1 would break code. Would probably need some deprecating and name 
shuffling to be acceptable. Would also need to make sure that this is 
actually the most desirable behavior.


#2 would probably create surprising corner cases. I don't think we can 
tell for sure if a range needs to be passed by reference in order to see 
updates to its elements. I'd be against this.


#3 may be a little surprising in how it doesn't affect value types (like 
static arrays). However, before switching to #1, you'd need to make sure 
that that one doesn't have worse corner cases. I don't see any deal 
breakers, but that doesn't mean they're not there ;)


You also have to see if changing to #1 is worth the effort. It would be 
an effort not only for the implementer, but also for the users who have 
to update all their code.

Any relation?

[Andrei Alexandrescu via Digitalmars-d]

http://indianautosblog.com/2016/10/most-powerful-suzuki-swift-produces-350-hp-25 
-- Andrei

Re: Auto-gen list of D compiler versions: Improvements

[Johan Engelen via Digitalmars-d-announce]

On Tuesday, 11 October 2016 at 17:21:42 UTC, Nick Sabalausky 
wrote:
The automatically-updated list of D compiler versions available 
on Travis-CI (and which front-end/back-end version they each 
use) has had a few small improvements lately:


http://semitwist.com/travis-d-compilers


Perhaps another nice addition is to list the "aliases" and what 
they currently point to:

dmd -->  dmd v2.071.2
dmd-beta --> ...
ldc --> ...
ldc-beta --> ...
gdc --> ...

-Johan

Re: Working with ranges: mismatched function return type inference

[ag0aep6g via Digitalmars-d-learn]

On 10/11/2016 09:55 AM, orip wrote:

auto foo(int[] ints) {
  import std.range;
  if (ints.length > 10) {
return chain(ints[0..5], ints[8..$]);
  } else {
//return ints; // Error: mismatched function return type inference
of int[] and Result
return chain(ints[0..0], ints[0..$]); // This workaround compiles
  }
}

Is there a compatible return type that can be used, or some other
workaround?


You've got some options:

1) OOP with std.range.interfaces. Ali already showed how this work. 
Comes at the cost of extra allocations and indirections.


2) std.range.choose wraps two different range types and uses forwards to 
one of them based on a condition. Should be cheap. But you need 
restructure your code a little:



auto foo(int[] ints) {
  import std.range: chain, choose;
  return choose(ints.length > 10,
chain(ints[0..5], ints[8..$]),
ints);
}


3) The workaround you already discovered: making a seemingly pointless 
call to `chain` to get the types to match. Possibly the most efficient 
solution. Looks a little odd.

Re: Article: Increasing the performance of D math code

[Johan Engelen via Digitalmars-d-announce]

On Tuesday, 11 October 2016 at 17:29:47 UTC, Ali Çehreli wrote:

On 10/11/2016 07:01 AM, Johan Engelen wrote:
> I wrote a piece on LDC's fastmath stuff that Mir uses for
> high-performance D math code:
>
> 
https://johanengelen.github.io/ldc/2016/10/11/Math-performance-LDC.html

>
> cheers,
>   Johan

Kind of off topic and hopefully constructive critism: You have 
sentence that starts with "I’m afraid it won’t be a nice 
read..." on Reddit. No matter how correct, there is no need to 
use negative marketing for your work. :) How about something 
more positive like "I'm sure you'll enjoy this more if you're 
familiar with...". ;)


Something to keep in mind next time!

Re: Working with ranges: mismatched function return type inference

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, October 11, 2016 07:55:36 orip via Digitalmars-d-learn wrote:
> I get "Error: mismatched function return type inference" errors
> with choosing the return type for functions that work on ranges
> using, e.g, std.algorithm or std.range functions, but have
> different behavior based on runtime values. The return type is
> always a range with the same underlying type.
>
> Here's an example:
>
> auto foo(int[] ints) {
>import std.range;
>if (ints.length > 10) {
>  return chain(ints[0..5], ints[8..$]);
>} else {
>  //return ints; // Error: mismatched function return type
> inference of int[] and Result
>  return chain(ints[0..0], ints[0..$]); // This workaround
> compiles
>}
> }
>
> Is there a compatible return type that can be used, or some other
> workaround?
> I couldn't find one when searching for the error or looking at
> the phobos source code.
>
> Thanks! orip

You're workaround is basically doing what you need to do. A function can
only return one type. The fact that both return statements are returning
ranges over the same kind of elements is irrelevant. They have to be
_exactly_ the same type. So, either you need to convert the range for the
first return statement into int[] so that it matches the second (e.g. by
calling array on the result or just using ~), or you need to call chain on
two int[]s for the second return statement so that it matches the first.

The second option (which your workaround does) is better if you don't intend
to convert the result to an array, since it avoids allocating an array, but
if you're just going to convert the result to int[] anyway, the first option
would be better.

Regardless, you can't have a function returning different types from
different return statements - even with auto. The compiler needs to know
exactly what the return type is whether you type it or not; auto just
infers it for you rather than requiring you to type it out.

- Jonathan M Davis

Re: Working with ranges: mismatched function return type inference

[Ali Çehreli via Digitalmars-d-learn]

On 10/11/2016 10:28 AM, TheFlyingFiddle wrote:

On Tuesday, 11 October 2016 at 15:46:20 UTC, orip wrote:

On Tuesday, 11 October 2016 at 13:06:37 UTC, pineapple wrote:

Rewrite `return chain(ints[0..5], ints[8..$]);` as `return ints[0..5]
~ ints[8..$];`

The `chain` function doesn't return an array, it returns a
lazily-evaluated sequence of an entirely different type from `int[]`.


Of course it does! I would like the function to return an "input range
of int", no matter which one specifically. Is this possible?


It is, but you will have to use an interface / class to achieve this
behavior (or use some sort of polymorphic struct). Something like this
will do the trick:

import std.range;
import std.stdio;

interface IInputRange(T)
{
bool empty();
T front();
void popFront();
}

final class InputRange(Range) if(isInputRange!Range)
: IInputRange!(ElementType!Range)
{
Range r;
this(Range r)
{
this.r = r;
}

bool empty() { return r.empty; }
ElementType!Range front() { return r.front; }
void popFront() { r.popFront; }
}

auto inputRange(Range)(Range r)
{
return new InputRange!Range(r);
}

IInputRange!int foo(int[] ints)
{
import std.range;
if(ints.length > 10) {
return inputRange(chain(ints[0 .. 5], ints[8 .. $]));
} else {
return inputRange(ints);
}
}

void main()
{
auto ir  = foo([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]);
auto ir2 = foo([0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]);
writeln(ir);
writeln(ir2);
}





Those interfaces already exist in Phobos: :)

  https://dlang.org/phobos/std_range_interfaces.html

auto foo(int[] ints) {
  import std.range;
  if (ints.length > 10) {
  return 
cast(RandomAccessFinite!int)inputRangeObject(chain(ints[0..5], ints[8..$]));

  } else {
  return cast(RandomAccessFinite!int)inputRangeObject(ints);
  }
}

void main() {
import std.stdio;
import std.range;
import std.algorithm;
writeln(foo([1, 2, 3]));
writeln(foo(iota(20).array));
}

Ali

Re: Article: Increasing the performance of D math code

[Ali Çehreli via Digitalmars-d-announce]

On 10/11/2016 07:01 AM, Johan Engelen wrote:
> I wrote a piece on LDC's fastmath stuff that Mir uses for
> high-performance D math code:
>
> https://johanengelen.github.io/ldc/2016/10/11/Math-performance-LDC.html
>
> cheers,
>   Johan

Kind of off topic and hopefully constructive critism: You have sentence 
that starts with "I’m afraid it won’t be a nice read..." on Reddit. No 
matter how correct, there is no need to use negative marketing for your 
work. :) How about something more positive like "I'm sure you'll enjoy 
this more if you're familiar with...". ;)


Ali

Re: Working with ranges: mismatched function return type inference

[TheFlyingFiddle via Digitalmars-d-learn]

On Tuesday, 11 October 2016 at 15:46:20 UTC, orip wrote:

On Tuesday, 11 October 2016 at 13:06:37 UTC, pineapple wrote:
Rewrite `return chain(ints[0..5], ints[8..$]);` as `return 
ints[0..5] ~ ints[8..$];`


The `chain` function doesn't return an array, it returns a 
lazily-evaluated sequence of an entirely different type from 
`int[]`.


Of course it does! I would like the function to return an 
"input range of int", no matter which one specifically. Is this 
possible?


It is, but you will have to use an interface / class to achieve 
this behavior (or use some sort of polymorphic struct). Something 
like this will do the trick:


import std.range;
import std.stdio;

interface IInputRange(T)
{
bool empty();
T front();
void popFront();
}

final class InputRange(Range) if(isInputRange!Range)
: IInputRange!(ElementType!Range)
{
Range r;
this(Range r)
{
this.r = r;
}

bool empty() { return r.empty; }
ElementType!Range front() { return r.front; }
void popFront() { r.popFront; }
}

auto inputRange(Range)(Range r)
{
return new InputRange!Range(r);
}

IInputRange!int foo(int[] ints)
{
import std.range;
if(ints.length > 10) {
return inputRange(chain(ints[0 .. 5], ints[8 .. $]));
} else {
return inputRange(ints);
}
}

void main()
{
auto ir  = foo([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]);
auto ir2 = foo([0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]);
writeln(ir);
writeln(ir2);
}

Auto-gen list of D compiler versions: Improvements

[Nick Sabalausky via Digitalmars-d-announce]

The automatically-updated list of D compiler versions available on 
Travis-CI (and which front-end/back-end version they each use) has had a 
few small improvements lately:


http://semitwist.com/travis-d-compilers

- Now includes beta versions available for DMD (starting at v2.072.0) 
and LDC (starting at v1.1.0). GDC betas will automatically be supported 
if/when the "gdc-beta" label becomes available on travis.


- Fixed: Incorrectly parses LLVM version for LDC v1.0.0 and up

- Added links going directly to DMD/LDC/GDC sections. (No longer have to 
scroll through DMD entries to find LDC/GDC.)


- On-hover row highlighting.

As before, the list is currently set to automatically update once daily 
(although I can adjust that if need be. I just don't want to put an 
undue burden on travis by checking too often.)

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 16:13:45 UTC, Andrei Alexandrescu 
wrote:

On 10/11/16 11:15 AM, Stefan Koch wrote:

I will now run this problem through STOKE.
Let's see what it comes up with :)


http://stoke.stanford.edu you mean? That would be cool. Keep us 
posted! -- Andrei


Yep I mean that one.
It will take a while to work out the right cost-functions.
I'll do a PR as soon as this bears fruit.

Communication between 2 Socket listener on 2 different port with one program and server.

[vino via Digitalmars-d]

Hi All,

  Need your help, on the below request.

Requirement:
Server:
2 socket listening to 2 different ports with one main program
Socket1 Port1 (Used for receiving user request(user data))
Socket2 Port2 (Used for system request(system data))

User request arrives via Socket1:Port1 needs to be sent 
Socket2:Port2
Once the request arrives then the request has to be sent to the 
Manger(another server) via Socket2:Port2


I was able to program to run multiple socket and send request to 
Socket1:Port1 but not able to send the same request to 
Socket2:Port2 tried both options sendTo and receiveFrom but no 
luck.


Note: the user request should to directly reach the 
Manger(another server) it should is always follow the data 
communication layer which is Socket2:Port2 as the
server Manger will connect via Socket2:Port2(only) to receive 
data.



void main () {
auto ext  = new Thread().start();
auto int  = new Thread().start();
}

void ext () {
ushort extport  = 1120;
Socket ext;
char[1024] buf;
Address mainserver = new InternetAddress("server1", 1121);
ext = new TcpSocket();
ext.bind(1120);
ext.listen(1);
ext.accpet();
ext.receive(buf[]);
writeln(buf[0..1024]);
ext.sendTo(buf[0..1024], SocketFlags.NONE, mainserver);
}

void int () {
ushort intport  = 1121;
Socket int;
char[1024] buf;
Address mainserver = new InternetAddress("server1", 1120);
Address manager = new InternetAddress("server1", 1120);
int = new TcpSocket();
int.bind(1120);
int.listen(1);
int.accpet();
int.receive(buf[0..1024], SocketFlags.NONE, mainserver);
writeln(buf[0..1024]);
int.sendTo(buf[0..1024], SocketFlags.NONE, manager);
}


From,
Vino.B

Re: dmd -o- option meaning changed recently? Now not creating OBJ but also not creating EXE

[A D dev via Digitalmars-d-learn]

On Monday, 3 October 2016 at 09:06:32 UTC, Dicebot wrote:

Purpose is to skip code generation and only do syntax/semantic 
validation. Very helpful when testing compiler because:


a) it takes less time speeding up overall test suite
b) doesn't require runtime static library to succeed, thus 
simplifying setup


Thanks, Dicebot. Only saw your message now, sorry.

Re: Can you shrink it further?

[Andrei Alexandrescu via Digitalmars-d]

On 10/11/16 11:15 AM, Stefan Koch wrote:

I will now run this problem through STOKE.
Let's see what it comes up with :)


http://stoke.stanford.edu you mean? That would be cool. Keep us posted! 
-- Andrei

Re: scone 1.2.0

[vladdeSV via Digitalmars-d-announce]

On Tuesday, 11 October 2016 at 06:22:24 UTC, Suliman wrote:

Could you add example of progress bar?


Yes, will get one up in the next coming days

Re: Working with ranges: mismatched function return type inference

[drug via Digitalmars-d-learn]

11.10.2016 18:46, orip пишет:

On Tuesday, 11 October 2016 at 13:06:37 UTC, pineapple wrote:

Rewrite `return chain(ints[0..5], ints[8..$]);` as `return ints[0..5]
~ ints[8..$];`

The `chain` function doesn't return an array, it returns a
lazily-evaluated sequence of an entirely different type from `int[]`.


Of course it does! I would like the function to return an "input range
of int", no matter which one specifically. Is this possible?
it doesn't. Using runtime argument you can't choose compile time 
parameter - returned type. So it's impossible. Almost - b/c you can use 
Algebraic. Again you can do the following:


```D
return chain(ints[0..5], ints[8..$]).array; // it returns int[]
```

Re: Working with ranges: mismatched function return type inference

[orip via Digitalmars-d-learn]

On Tuesday, 11 October 2016 at 13:06:37 UTC, pineapple wrote:
Rewrite `return chain(ints[0..5], ints[8..$]);` as `return 
ints[0..5] ~ ints[8..$];`


The `chain` function doesn't return an array, it returns a 
lazily-evaluated sequence of an entirely different type from 
`int[]`.


Of course it does! I would like the function to return an "input 
range of int", no matter which one specifically. Is this possible?

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 15:08:34 UTC, Andrei Alexandrescu 
wrote:

On 10/10/2016 11:00 PM, Stefan Koch wrote:


[...]


Looked at this, still seems to generate a jump forward with 
ldc. Also, why do you leave a fallthrough path? Progress needs 
to be made on all paths, otherwise we have infinite loops.


I forgot that the fall-trough did no longer end in Lend;
That forward jump to Lend is a very common and therefore 
predicted branch.



I will now run this problem through STOKE.
Let's see what it comes up with :)

Re: Article: Increasing the performance of D math code

[Andrei Alexandrescu via Digitalmars-d-announce]

On 10/11/2016 11:06 AM, Ilya Yaroshenko wrote:

On Tuesday, 11 October 2016 at 14:01:54 UTC, Johan Engelen wrote:

I wrote a piece on LDC's fastmath stuff that Mir uses for
high-performance D math code:

https://johanengelen.github.io/ldc/2016/10/11/Math-performance-LDC.html

cheers,
  Johan


Awesome! Thank you for the post! Twitted
https://twitter.com/libmir/status/785858654717239296


https://www.reddit.com/r/programming/comments/56yheb/increasing_the_performance_of_d_math_code/

Andrei

Re: Can you shrink it further?

[David Nadlinger via Digitalmars-d]

On Tuesday, 11 October 2016 at 15:08:34 UTC, Andrei Alexandrescu 
wrote:

Looked at this, still seems to generate a jump forward with ldc.


ldc.intrinsics.llvm_expect might help to influence basic block 
layout.


 — David

Re: Article: Increasing the performance of D math code

[Ilya Yaroshenko via Digitalmars-d-announce]

On Tuesday, 11 October 2016 at 14:01:54 UTC, Johan Engelen wrote:
I wrote a piece on LDC's fastmath stuff that Mir uses for 
high-performance D math code:


https://johanengelen.github.io/ldc/2016/10/11/Math-performance-LDC.html

cheers,
  Johan


Awesome! Thank you for the post! Twitted 
https://twitter.com/libmir/status/785858654717239296

Re: Can you shrink it further?

[Andrei Alexandrescu via Digitalmars-d]

On 10/10/2016 11:00 PM, Stefan Koch wrote:


void popFront3(ref char[] s) @trusted pure nothrow {
   immutable c = s[0];
   uint char_length = 1;
   if (c < 127)
   {
   Lend :
 s = s.ptr[char_length .. s.length];
   } else {
 if ((c & b01100_) == 0b1000_)
 {
   //just skip one in case this is not the beginning of a code-point
char
   goto Lend;
 }
 if (c < 192)
 {
   char_length = 2;
   goto Lend;
 }
 if (c < 240)
 {
   char_length = 3;
   goto Lend;
 }
 if (c < 248)
 {
   char_length = 4;
   goto Lend;
 }
   }
 }


Looked at this, still seems to generate a jump forward with ldc. Also, 
why do you leave a fallthrough path? Progress needs to be made on all 
paths, otherwise we have infinite loops.



Andrei

Re: Can you shrink it further?

[Andrei Alexandrescu via Digitalmars-d]

On 10/11/2016 10:49 AM, Matthias Bentrup wrote:


void popFrontAsmIntel(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  if (c < 0x80) {
s = s[1 .. $];
  } else {
uint l = void;
asm pure nothrow @nogc {
  mov EAX, 1;
  mov BL, 0xf8-1;
  sub BL, c;
  cmp BL, 0xf8-0xc0;
  adc EAX, 0;
  cmp BL, 0xf8-0xe0;
  adc EAX, 0;
  cmp BL, 0xf8-0xf0;
  adc EAX, 0;
  mov l, EAX;
}
s = s[l <= $ ? l : $ .. $];
  }
}


Did you take a look at the codegen on http://ldc.acomirei.ru? It's huge. 
-- Andrei

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 14:49:28 UTC, Matthias Bentrup 
wrote:


This is the result I'd like to get, but I can't find a way to 
write it without inline assembly :(


void popFrontAsmIntel(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  if (c < 0x80) {
s = s[1 .. $];
  } else {
uint l = void;
asm pure nothrow @nogc {
  mov EAX, 1;
  mov BL, 0xf8-1;
  sub BL, c;
  cmp BL, 0xf8-0xc0;
  adc EAX, 0;
  cmp BL, 0xf8-0xe0;
  adc EAX, 0;
  cmp BL, 0xf8-0xf0;
  adc EAX, 0;
  mov l, EAX;
}
s = s[l <= $ ? l : $ .. $];
  }
}


This takes 180us.
Baseline takes 124us.

Re: Can you shrink it further?

[Andrei Alexandrescu via Digitalmars-d]

On 10/11/2016 05:45 AM, Temtaime wrote:

void popFront7(ref char[] s) @trusted pure nothrow
{
  import core.bitop;
  auto v = 7 - bsr(~s[0] | 1);
  s = s[v > 6 ? 1 : (v ? (v > s.length ? s.length : v) : 1)..$];
}

Please check this.


Thanks. This does a lot of work on the frequent path c < 0x80:

pure nothrow @trusted void example.popFront7(ref char[]):
movq8(%rdi), %rax
movzbl  (%rax), %ecx
xorq$254, %rcx
orq $1, %rcx
bsrq%rcx, %rcx
notl%ecx
addl$8, %ecx
cmpl$6, %ecx
jg  .LBB0_2
testl   %ecx, %ecx
je  .LBB0_2
movslq  %ecx, %rdx
movq(%rdi), %rcx
cmpq%rcx, %rdx
cmovaq  %rcx, %rdx
jmp .LBB0_3
.LBB0_2:
movq(%rdi), %rcx
movl$1, %edx
.LBB0_3:
addq%rdx, %rax
subq%rdx, %rcx
movq%rcx, (%rdi)
movq%rax, 8(%rdi)
retq

So I changed it to:

void popFront7(ref char[] s) @trusted pure nothrow
{
  immutable c = s[0];
  if (c < 0x80) {
s = s.ptr[1 .. s.length];
  } else {
import core.bitop;
uint v = 7 - bsr(~c | (c > 0xfd) << 6u);
s = s.ptr[v > s.length ? s.length : v .. s.length];
  }
}

That's about as large as the baseline.


Andrei

cpuid v0.3.0: Better C, Virtual Machines, AVX2 & AVX512, GDC

[Ilya Yaroshenko via Digitalmars-d-announce]

(Mir) cpuid v0.3.0 was released.

https://github.com/libmir/cpuid

## New
 - Basic leaf 7 CPUID information was added. It includes AVX2 
flag, AVX512 family flags and others.


 - Initial support for virtual machines was added.

 - `virtualVendor`, `virtualVendorIndex` was added.

 - `cpuid` is compatible with betterC compilation mode.

 - `extern(C) cpuid_init();` must be called instead of shared 
static module constructor.


 - No module information is generated when cpuid is compiled with 
LDC. LDC does not support `betterC` flag for now, however it is 
only compiler which produce binary code, that can be linked as 
common C library without DRuntime.


 - GDC support was added and tested.

 - CPUID instruction is optimized when compiled using GDC and 
when compiled for 64-bit Posix systems using LDC.


## API Changes
 - `brand`, `vendor` was moved to x86 module. `brand` API was 
changed.

 - `ss` -> `self_snoop`
 - `tm` -> `therm_monitor`
 - `tm2` -> `therm_monitor2`
 - `virtual` flag was added, `isVirtual` function was removed.

## Bugs fixed
- CPUID crashes on Microsoft VM  
https://github.com/libmir/cpuid/issues/11

Re: Can you shrink it further?

[Matthias Bentrup via Digitalmars-d]

On Tuesday, 11 October 2016 at 14:24:56 UTC, Andrei Alexandrescu 
wrote:

On 10/11/2016 03:30 AM, Matthias Bentrup wrote:

A branch-free version:

void popFront4(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  uint char_length = 1 + (c >= 192) + (c >= 240) + (c >= 248);
  s = s.ptr[char_length .. s.length];
}

Theoretically the char_length could be computed with three sub 
and addc

instructions, but no compiler is smart enough to detect that.


Interesting. 0x80 should be special-cased and you forgot to 
check the bounds. So:


void popFront4(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  if (c < 0x80) {
s = s.ptr[1 .. s.length];
  } else {
uint l = 1 + (c >= 192) + (c >= 240) + (c >= 248);
s = s.ptr[l <= s.length ? l : s.length .. s.length];
  }
}

This generated 27 instructions, i.e. same as the baseline. See:

http://ldc.acomirei.ru/#compilers:!((compiler:ldc,options:'-release+-O3+-boundscheck%3Doff',sourcez:G4ewlgJgBADiMDEBOIB2AXAjACiQUwDMoBjACwEMkBtAXSgGcBKKAAXSQFd709oYP8UVCHSkUAdygBvAFBQoYALaKO6cgCMANnhJQAvAyoAGGgG45CotmJQAPFCMAPABxHms%2BfPr6GAOhjsVJhQvr5%2B2qgA5qJmFgC%2BUHia9DoenkpwSOgkIPi%2B6mDo8OaeUBxgGAo%2BAOwcUAC0UOr0SNgAfjYAPlCYHIwl6YqZ2dwQvuSakbmFpIoD8mBWYFAAfFAAbH1VBpjzDD70/oGKFdhgADTheFGizKFXN6Sx8nEyrzKgkLDwyGjoAEy4QgkCjUOjcJDMNicbi8WACHTCUQSaQWJQqNRaHQ2AwQ4zPSxQax2BwuNwWNLyAD0VICSAU3i4cKKUHIn2gHFQXLwxDw9HolAAnk0QJyIN4yDyANYVSK%2BCxedgHdhHajBe4Q3wRaJPAaveRJFKE4l6AxOAgERgUhVQGlNFplVAQQgVOEEXIOG0Q5VIVVBEJhTXamJ6iyGvDW0oZXLZYi5PD5QrwKAALntSD25FUICginozRqDXT7WI/RtiyJ2DzBfs/2Y3Sr%2Be8a3WjCtpUpnhpAElUMAJl8AKoAFQQ9WcNvk1e8Oz2%2BsGwwY6DGEymSBmcy9StxKrpVBOqEbzUuQeuOrugZVwd18TeMiAA)),filterAsm:(commentOnly:!t,directives:!t,labels:!t),version:3

But it doesn't seem to check for all errors.


Andrei


This is the result I'd like to get, but I can't find a way to 
write it without inline assembly :(


void popFrontAsmIntel(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  if (c < 0x80) {
s = s[1 .. $];
  } else {
uint l = void;
asm pure nothrow @nogc {
  mov EAX, 1;
  mov BL, 0xf8-1;
  sub BL, c;
  cmp BL, 0xf8-0xc0;
  adc EAX, 0;
  cmp BL, 0xf8-0xe0;
  adc EAX, 0;
  cmp BL, 0xf8-0xf0;
  adc EAX, 0;
  mov l, EAX;
}
s = s[l <= $ ? l : $ .. $];
  }
}

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 14:24:56 UTC, Andrei Alexandrescu 
wrote:

On 10/11/2016 03:30 AM, Matthias Bentrup wrote:

A branch-free version:

void popFront4(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  uint char_length = 1 + (c >= 192) + (c >= 240) + (c >= 248);
  s = s.ptr[char_length .. s.length];
}



void popFront4(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  if (c < 0x80) {
s = s.ptr[1 .. s.length];
  } else {
uint l = 1 + (c >= 192) + (c >= 240) + (c >= 248);
s = s.ptr[l <= s.length ? l : s.length .. s.length];
  }
}

This generated 27 instructions, i.e. same as the baseline. See:

http://ldc.acomirei.ru/#compilers:!((compiler:ldc,options:'-release+-O3+-boundscheck%3Doff',sourcez:G4ewlgJgBADiMDEBOIB2AXAjACiQUwDMoBjACwEMkBtAXSgGcBKKAAXSQFd709oYP8UVCHSkUAdygBvAFBQoYALaKO6cgCMANnhJQAvAyoAGGgG45CotmJQAPFCMAPABxHms%2BfPr6GAOhjsVJhQvr5%2B2qgA5qJmFgC%2BUHia9DoenkpwSOgkIPi%2B6mDo8OaeUBxgGAo%2BAOwcUAC0UOr0SNgAfjYAPlCYHIwl6YqZ2dwQvuSakbmFpIoD8mBWYFAAfFAAbH1VBpjzDD70/oGKFdhgADTheFGizKFXN6Sx8nEyrzKgkLDwyGjoAEy4QgkCjUOjcJDMNicbi8WACHTCUQSaQWJQqNRaHQ2AwQ4zPSxQax2BwuNwWNLyAD0VICSAU3i4cKKUHIn2gHFQXLwxDw9HolAAnk0QJyIN4yDyANYVSK%2BCxedgHdhHajBe4Q3wRaJPAaveRJFKE4l6AxOAgERgUhVQGlNFplVAQQgVOEEXIOG0Q5VIVVBEJhTXamJ6iyGvDW0oZXLZYi5PD5QrwKAALntSD25FUICginozRqDXT7WI/RtiyJ2DzBfs/2Y3Sr%2Be8a3WjCtpUpnhpAElUMAJl8AKoAFQQ9WcNvk1e8Oz2%2BsGwwY6DGEymSBmcy9StxKrpVBOqEbzUuQeuOrugZVwd18TeMiAA)),filterAsm:(commentOnly:!t,directives:!t,labels:!t),version:3

But it doesn't seem to check for all errors.


Andrei


It's much slower.
Because of the flag-storing instructions.

Re: Can you shrink it further?

[Andrei Alexandrescu via Digitalmars-d]

On 10/11/2016 03:30 AM, Matthias Bentrup wrote:

A branch-free version:

void popFront4(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  uint char_length = 1 + (c >= 192) + (c >= 240) + (c >= 248);
  s = s.ptr[char_length .. s.length];
}

Theoretically the char_length could be computed with three sub and addc
instructions, but no compiler is smart enough to detect that.


Interesting. 0x80 should be special-cased and you forgot to check the 
bounds. So:


void popFront4(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  if (c < 0x80) {
s = s.ptr[1 .. s.length];
  } else {
uint l = 1 + (c >= 192) + (c >= 240) + (c >= 248);
s = s.ptr[l <= s.length ? l : s.length .. s.length];
  }
}

This generated 27 instructions, i.e. same as the baseline. See:

http://ldc.acomirei.ru/#compilers:!((compiler:ldc,options:'-release+-O3+-boundscheck%3Doff',sourcez:G4ewlgJgBADiMDEBOIB2AXAjACiQUwDMoBjACwEMkBtAXSgGcBKKAAXSQFd709oYP8UVCHSkUAdygBvAFBQoYALaKO6cgCMANnhJQAvAyoAGGgG45CotmJQAPFCMAPABxHms%2BfPr6GAOhjsVJhQvr5%2B2qgA5qJmFgC%2BUHia9DoenkpwSOgkIPi%2B6mDo8OaeUBxgGAo%2BAOwcUAC0UOr0SNgAfjYAPlCYHIwl6YqZ2dwQvuSakbmFpIoD8mBWYFAAfFAAbH1VBpjzDD70/oGKFdhgADTheFGizKFXN6Sx8nEyrzKgkLDwyGjoAEy4QgkCjUOjcJDMNicbi8WACHTCUQSaQWJQqNRaHQ2AwQ4zPSxQax2BwuNwWNLyAD0VICSAU3i4cKKUHIn2gHFQXLwxDw9HolAAnk0QJyIN4yDyANYVSK%2BCxedgHdhHajBe4Q3wRaJPAaveRJFKE4l6AxOAgERgUhVQGlNFplVAQQgVOEEXIOG0Q5VIVVBEJhTXamJ6iyGvDW0oZXLZYi5PD5QrwKAALntSD25FUICginozRqDXT7WI/RtiyJ2DzBfs/2Y3Sr%2Be8a3WjCtpUpnhpAElUMAJl8AKoAFQQ9WcNvk1e8Oz2%2BsGwwY6DGEymSBmcy9StxKrpVBOqEbzUuQeuOrugZVwd18TeMiAA)),filterAsm:(commentOnly:!t,directives:!t,labels:!t),version:3

But it doesn't seem to check for all errors.


Andrei

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 14:16:54 UTC, Andrei Alexandrescu 
wrote:

On 10/11/2016 04:57 AM, Stefan Koch wrote:

Yours runs with 790 us best time.
bsr is a real timetaker :)


What inputs did you test it on?


https://github.com/minimaxir/big-list-of-naughty-strings/blob/master/blns.txt


Here's what I think would be a good set of requirements:

* The ASCII case should be short and fast: a comparison and a 
branch, followed by return. This would improve a very common 
case and address the main issue with autodecoding.

Already done
* For the multibyte case, the main requirement is the code must 
be small. This is because it gets inlined all over the place 
and seldom used.


* For the multibyte case, the fewer bytes in the encoding the 
less work. This is because more frequent multi-byte characters 
have generally lower codes.
That is why I had the branches, generally only the first one is 
taken
Currently front() - the other time spender in autodecoding - 
issues a function call on the multibyte case. That makes the 
code of front() itself small, at the cost of more expensive 
multibyte handling.
I think at some point we have to cache the length of the last 
decoded char,

Otherwise we are throwing work away.

However that will only work within a RangeWrapper-Struct

[your code here]

[jessie via Digitalmars-d]

judr jpg

Re: Trait hasIndexing

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, October 11, 2016 10:08:02 Nordlöw via Digitalmars-d-learn wrote:
> I can't find any traits `hasIndexing!R` corresponding to
> `std.range.primitives.hasSlicing!R`
>
> that is `true` iff `R` has `opIndex[size_t]` defined. Is there
> one?
>
> If not what should I use instead?

The traits in std.range are specifically for ranges, and isRandomAccessRange
already covers indexing, which is why there isn't a separate trait for
indexing in there. There certainly _could_ be one in std.traits, but there
isn't at present.

- Jonathan M Davis

Re: Can you shrink it further?

[Andrei Alexandrescu via Digitalmars-d]

On 10/11/2016 04:57 AM, Stefan Koch wrote:

Yours runs with 790 us best time.
bsr is a real timetaker :)


What inputs did you test it on?

Here's what I think would be a good set of requirements:

* The ASCII case should be short and fast: a comparison and a branch, 
followed by return. This would improve a very common case and address 
the main issue with autodecoding.


* For the multibyte case, the main requirement is the code must be 
small. This is because it gets inlined all over the place and seldom used.


* For the multibyte case, the fewer bytes in the encoding the less work. 
This is because more frequent multi-byte characters have generally lower 
codes.


Currently front() - the other time spender in autodecoding - issues a 
function call on the multibyte case. That makes the code of front() 
itself small, at the cost of more expensive multibyte handling.



Andrei

[Issue 16423] ModuleInfo missing when linking to static lib with classes

[via Digitalmars-d-bugs]

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

--- Comment #9 from Ketmar Dark  ---
(In reply to Steven Schveighoffer from comment #8)
> But there may be code out there which expects Object.factory to work, and in
> some cases, it will not.

and there is. some of my UI parsers *depends* on the fact that class list and
factory are there. i did that exactly to avoid manual registering of UI
classes, which is highly error-prone.

that is, some features are not removed 'cause there *may* be the code that
depends on those. now there *is* the code that depends on full module/class
infos and factory. this alone should rule "let's remove object.factory" out.
let's see if real code has more weight than imaginary code. ;-)

--

Re: Can you shrink it further?

[Ethan Watson via Digitalmars-d]

On Tuesday, 11 October 2016 at 10:01:41 UTC, Stefan Koch wrote:

On Tuesday, 11 October 2016 at 09:45:11 UTC, Temtaime wrote:


Sorry this was also a type in the code.

void popFront7(ref char[] s) @trusted pure nothrow
{
  import core.bitop;
  auto v = 7 - bsr(~s[0] | 1);
  s = s[v > 6 ? 1 : (v ? (v > s.length ? s.length : v) : 
1)..$];

}

Please check this.


162 us


The branching, it hurts my eyes!

Something like the following should give correct (assuming I 
haven't written bad logic) branchless results with 
architecture-optimised max calls. Note that the minus/plus 1 
operation on the third line will ensure with the sign 
multiplication that values of 7 will map to 1, whereas for all 
other values it's an extra operation. But the advantage is that 
you're not sticking three branches in close proximity to each 
other, so you will never get a branch predictor fail. (Of note, 
any performance test for these functions should test with data 
designed to fail the branching code I quoted, keeping in mind 
that desktop Intel processors have a four-state branch predictor. 
I've not performance tested it myself, but this will certainly 
run faster on the AMD Jaguar processors than a version with 
branching checks.)


int v = 7 - bsr( ~s[0] | 1 );
int sign = ( (v - 7) >> 31 );
v = ( v - 1 ) * sign + 1;
str = str[ min( v, s.length ) .. $ ];

Re: Current State of the GC?

[Guillaume Piolat via Digitalmars-d-learn]

On Monday, 10 October 2016 at 21:12:42 UTC, Martin Lundgren wrote:
So what's been happening in memory management land lately? Bad 
GC seems like one of the Dlangs weak points, so showing 
improvements here could definitely bring more people in.


It's not that the D GC is bad per se, but rather than having a GC 
there requires understanding of what it does and why. It is like 
a knowledge debt that has to be paid back sooner or later.


Once you've paid this cost in understanding (how to be 
deterministic, how to recognize GC errors, how to keep the heap 
small, how to maintain traceability and why) the GC becomes some 
kind of helpful friend, if only a bit creepy.


BTW the GC has seen some improvement with regards to preciseness.

Re: DStatsD - A fast, memory efficent, vibe.d compatible client for etsy's statsd.

[Robert burner Schadek via Digitalmars-d-announce]

the backend/view for it:

https://github.com/kamon-io/docker-grafana-graphite

Re: DStatsD - A fast, memory efficent, vibe.d compatible client for etsy's statsd.

[Robert burner Schadek via Digitalmars-d-announce]

On Tuesday, 11 October 2016 at 12:47:55 UTC, Atila Neves wrote:
I didn't even know that this existed, and I have a feeling that 
soon I'll wonder how I lived without it. Awesome!


I had the exact same feeling

[Issue 16423] ModuleInfo missing when linking to static lib with classes

[via Digitalmars-d-bugs]

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

--- Comment #8 from Steven Schveighoffer  ---
Whether we need it or not, it's currently a feature of the runtime. Do we not
care about existing code anymore?

I'm totally in favor of deprecating Object.factory, and also in favor of your
update to std.encoding that makes this issue moot for phobos at least. But
there may be code out there which expects Object.factory to work, and in some
cases, it will not.

Note, that in the example I give, including the module info does little to
increase the binary size. The ClassInfo is already present in the binary, and
therefore pulls in everything else the class may use.

Not only that, but building with the -lib switch does not work, but building
without does. This kind of inconsistency is not good for D, regardless of the
utility of the Object.factory feature. It makes no sense that the compiler is
"stupider" about trimming fat when it has full code access than the linker.

--

Re: DStatsD - A fast, memory efficent, vibe.d compatible client for etsy's statsd.

[Joakim via Digitalmars-d-announce]

On Tuesday, 11 October 2016 at 13:22:48 UTC, Dicebot wrote:

On 10/11/2016 04:13 PM, Joakim wrote:
On Monday, 10 October 2016 at 08:47:54 UTC, Robert burner 
Schadek wrote:

[...]


Never heard about this either, I ignore node.js stuff.  I was 
just reading this interesting post on tracing/profiling a 
couple days ago: is it efficient enough to find some of these 
tail latency issues?


Stats aggregation usually has nothing to do with fine tuned 
performance profiling - it is application defined way to 
monitor relevant metrics of runtime behavior. For example, one 
can aggregate metrics for web app request processing latencies 
to monitor if those stay within expected margin - but if issue 
is spotted, it won't help much in debugging _why_ it has 
happened.


Sure, it's not meant for tracing but monitoring, but if it is 
efficient enough you could repurpose it to specifically 
instrument for certain slow paths you're seeing.  The question 
is: how efficient is it?

Re: color lib

[Andrea Fontana via Digitalmars-d]

On Tuesday, 11 October 2016 at 12:14:37 UTC, Manu wrote:

Oh dear... thanks for digging that up.
I didn't know the web had a standard for alpha. Certainly 
0xAARRGGBB
has been used in windows code for as long as I've been 
programming...

but now there's a competing #RRGGBBAA version...
How to resolve this? I guess, go with the web? I should probably
change it to the CSS4 way.


My idea is still to use a template:
colorFromString!"rgba" or colorFromString!"argb" (please notice 
that AFAIK, the second most used way is actually "abgr" rather 
than "argb" - because of byte-order)


And I think it's a good idea to set template argument to some 
default.


MS is not sure about this, anyway.

Read carefully this:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms534427(v=vs.85).aspx

VS:

https://msdn.microsoft.com/en-us/library/ee505694(v=winembedded.60).aspx

VS:

https://msdn.microsoft.com/it-it/library/windows/desktop/dd183449(v=vs.85).aspx


OpenGL use rgba (and abgr?) directX argb:
https://www.opengl.org/wiki/Image_Format
https://www.opengl.org/wiki/Direct3D_Compatibility

Andrea

Re: DStatsD - A fast, memory efficent, vibe.d compatible client for etsy's statsd.

[Dicebot via Digitalmars-d-announce]

On 10/11/2016 04:13 PM, Joakim wrote:
> On Monday, 10 October 2016 at 08:47:54 UTC, Robert burner Schadek wrote:
>> http://code.dlang.org/packages/dstatsd
>>
>> StatsD allows to collect statistics about any application by using
>> counters, gauges and more through UDP.
>>
>> Usage:
>>
>> auto s = new StatsD("127.0.0.1", 1234, ""); // connect to statsd server
>>
>> s(Counter("Foo")); // increment counter "Foo"
>> s.inc("Bar"); // increment counter "Foo"
>>
>> s(Counter("Args"), // send stats to Args, H, and timeA
>>   Counter("H", someIntValue),  // in one UDP message
>>   Timer("timeA", someTimeInMS)
>> );
>>
>> {
>>   auto a = ScopeTimer("args", s); // automatic time collection
>> }
> 
> Never heard about this either, I ignore node.js stuff.  I was just
> reading this interesting post on tracing/profiling a couple days ago: is
> it efficient enough to find some of these tail latency issues?

Stats aggregation usually has nothing to do with fine tuned performance
profiling - it is application defined way to monitor relevant metrics of
runtime behavior. For example, one can aggregate metrics for web app
request processing latencies to monitor if those stay within expected
margin - but if issue is spotted, it won't help much in debugging _why_
it has happened.



signature.asc
Description: OpenPGP digital signature

Re: LDC 1.1.0-beta3 has been released!

[Kai Nacke via Digitalmars-d-announce]

On Tuesday, 11 October 2016 at 09:16:36 UTC, Johan Engelen wrote:

On Tuesday, 11 October 2016 at 07:29:00 UTC, Sönke Ludwig wrote:

Whoops, that's my bad :(
(I editted a little and clicked the "save draft" button which 
turned it into a draft again, I think)


:-) Unintentionally I did the same with the beta2 release.

Regards,
Kai

Re: DStatsD - A fast, memory efficent, vibe.d compatible client for etsy's statsd.

[Joakim via Digitalmars-d-announce]

On Monday, 10 October 2016 at 08:47:54 UTC, Robert burner Schadek 
wrote:

http://code.dlang.org/packages/dstatsd

StatsD allows to collect statistics about any application by 
using counters, gauges and more through UDP.


Usage:

auto s = new StatsD("127.0.0.1", 1234, ""); // connect to 
statsd server


s(Counter("Foo")); // increment counter "Foo"
s.inc("Bar"); // increment counter "Foo"

s(Counter("Args"), // send stats to Args, H, and timeA
  Counter("H", someIntValue),  // in one UDP message
  Timer("timeA", someTimeInMS)
);

{
  auto a = ScopeTimer("args", s); // automatic time collection
}


Never heard about this either, I ignore node.js stuff.  I was 
just reading this interesting post on tracing/profiling a couple 
days ago: is it efficient enough to find some of these tail 
latency issues?


http://danluu.com/perf-tracing/

Given even Dtrace doesn't always work, Statsd is not going to 
work for all of those either, but I wonder if it will work 
sometimes.


Btw, pretty damning of HN/reddit that neither has that tracing 
link, which is why I don't read those stupid sites.

Re: Working with ranges: mismatched function return type inference

[pineapple via Digitalmars-d-learn]

On Tuesday, 11 October 2016 at 07:55:36 UTC, orip wrote:
I get "Error: mismatched function return type inference" errors 
with choosing the return type for functions that work on ranges 
using, e.g, std.algorithm or std.range functions, but have 
different behavior based on runtime values. The return type is 
always a range with the same underlying type.


Here's an example:

auto foo(int[] ints) {
  import std.range;
  if (ints.length > 10) {
return chain(ints[0..5], ints[8..$]);
  } else {
//return ints; // Error: mismatched function return type 
inference of int[] and Result
return chain(ints[0..0], ints[0..$]); // This workaround 
compiles

  }
}

Is there a compatible return type that can be used, or some 
other workaround?
I couldn't find one when searching for the error or looking at 
the phobos source code.


Thanks! orip


Rewrite `return chain(ints[0..5], ints[8..$]);` as `return 
ints[0..5] ~ ints[8..$];`


The `chain` function doesn't return an array, it returns a 
lazily-evaluated sequence of an entirely different type from 
`int[]`.

Re: DStatsD - A fast, memory efficent, vibe.d compatible client for etsy's statsd.

[Atila Neves via Digitalmars-d-announce]

On Monday, 10 October 2016 at 08:47:54 UTC, Robert burner Schadek 
wrote:

http://code.dlang.org/packages/dstatsd

StatsD allows to collect statistics about any application by 
using counters, gauges and more through UDP.


Usage:

auto s = new StatsD("127.0.0.1", 1234, ""); // connect to 
statsd server


s(Counter("Foo")); // increment counter "Foo"
s.inc("Bar"); // increment counter "Foo"

s(Counter("Args"), // send stats to Args, H, and timeA
  Counter("H", someIntValue),  // in one UDP message
  Timer("timeA", someTimeInMS)
);

{
  auto a = ScopeTimer("args", s); // automatic time collection
}


I didn't even know that this existed, and I have a feeling that 
soon I'll wonder how I lived without it. Awesome!


Atila

Re: color lib

[Manu via Digitalmars-d]

On 11 October 2016 at 18:10, Andrea Fontana via Digitalmars-d
 wrote:
> On Monday, 10 October 2016 at 23:26:53 UTC, Manu wrote:
>>
>> I'm not sure why it matters what format the colour you have is...
>> Strings are in the form #RRGGBB, or #AARRGGBB. That is all.
>> It's the standard I've seen used everywhere ever, including the web,
>> which is a pretty good precedent :P
>
>
> If the web is a good precedent (CSS4 specs):
> "The first 6 digits are interpreted identically to the 6-digit notation. The
> last pair of digits, interpreted as a hexadecimal number, specifies the
> alpha channel of the color, where 00 represents a fully transparent color
> and ff represent a fully opaque color."
>
> https://drafts.csswg.org/css-color/#hex-notation
>
> CSS3 doesn't support hex string with alpha but they suggest you to use
> rgba() function. I think argb() doesn't exists instead.
> https://www.w3.org/TR/2011/REC-css3-color-20110607/#rgba-color
>
> Chrome 52 supports it:
> https://googlechrome.github.io/samples/css-alpha-channel/
>
> Android instead:
> https://developer.android.com/reference/android/graphics/Color.html#parseColor(java.lang.String)
> "Parse the color string, and return the corresponding color-int. If the
> string cannot be parsed, throws an IllegalArgumentException exception.
> Supported formats are: #RRGGBB #AARRGGBB [...]"
>
> Please notice that on PNG file format rgba is quite common (also on bmp with
> semi-official apha support)
> PNG: http://www.libpng.org/pub/png/book/chapter08.html

Oh dear... thanks for digging that up.
I didn't know the web had a standard for alpha. Certainly 0xAARRGGBB
has been used in windows code for as long as I've been programming...
but now there's a competing #RRGGBBAA version...
How to resolve this? I guess, go with the web? I should probably
change it to the CSS4 way.

Re: Trait hasIndexing

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 11 October 2016 at 10:08:02 UTC, Nordlöw wrote:
I can't find any traits `hasIndexing!R` corresponding to 
`std.range.primitives.hasSlicing!R`


My definition of `hasIndexing` so far:

https://github.com/nordlow/phobos-next/blob/master/src/typecons_ex.d#L83

Trait hasIndexing

[Nordlöw via Digitalmars-d-learn]

I can't find any traits `hasIndexing!R` corresponding to 
`std.range.primitives.hasSlicing!R`


that is `true` iff `R` has `opIndex[size_t]` defined. Is there 
one?


If not what should I use instead?

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 09:45:11 UTC, Temtaime wrote:


Sorry this was also a type in the code.

void popFront7(ref char[] s) @trusted pure nothrow
{
  import core.bitop;
  auto v = 7 - bsr(~s[0] | 1);
  s = s[v > 6 ? 1 : (v ? (v > s.length ? s.length : v) : 1)..$];
}

Please check this.


162 us

Re: Can you shrink it further?

[Temtaime via Digitalmars-d]

On Tuesday, 11 October 2016 at 09:13:10 UTC, Stefan Koch wrote:

On Tuesday, 11 October 2016 at 08:57:46 UTC, Stefan Koch wrote:

On Tuesday, 11 October 2016 at 08:44:04 UTC, Temtaime wrote:


void popFront1(ref char[] s) @trusted pure nothrow
{
  import core.bitop, std.algorithm;
  auto v = bsr(~s[0] | 1);
  s = s[clamp(v, 1, v > 6 ? 1 : $)..$];
}

Seems to be less if i'm not wrong.



Yours runs with 790 us best time.
bsr is a real timetaker :)


CORRECTION this is not bsr's fault.
It's most likely clamp.
I am compiling with dmd and dmd is not as good in optimizing 
when templates are in the mix.


Sorry this was also a type in the code.

void popFront7(ref char[] s) @trusted pure nothrow
{
  import core.bitop;
  auto v = 7 - bsr(~s[0] | 1);
  s = s[v > 6 ? 1 : (v ? (v > s.length ? s.length : v) : 1)..$];
}

Please check this.

Re: LDC 1.1.0-beta3 has been released!

[Johan Engelen via Digitalmars-d-announce]

On Tuesday, 11 October 2016 at 07:29:00 UTC, Sönke Ludwig wrote:


Just noticed that the release binaries are missing from 
https://github.com/ldc-developers/ldc/releases/tag/v1.1.0-beta3


This means that the beta currently cannot be tested with 
TravisCI (wanted to test a DUB related regression fix).


Whoops, that's my bad :(
(I editted a little and clicked the "save draft" button which 
turned it into a draft again, I think)


Thanks for letting us know!
Fixed it.

I also updated LATEST_BETA, so `ldc-beta` on Travis should now 
automatically use 1.1.0-beta3.


-Johan

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 08:57:46 UTC, Stefan Koch wrote:

On Tuesday, 11 October 2016 at 08:44:04 UTC, Temtaime wrote:


void popFront1(ref char[] s) @trusted pure nothrow
{
  import core.bitop, std.algorithm;
  auto v = bsr(~s[0] | 1);
  s = s[clamp(v, 1, v > 6 ? 1 : $)..$];
}

Seems to be less if i'm not wrong.



Yours runs with 790 us best time.
bsr is a real timetaker :)


CORRECTION this is not bsr's fault.
It's most likely clamp.
I am compiling with dmd and dmd is not as good in optimizing when 
templates are in the mix.

[Issue 16513] Speed up TemplateInstance.findExistingInstance, hash by mangling

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

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

--

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 08:44:04 UTC, Temtaime wrote:


void popFront1(ref char[] s) @trusted pure nothrow
{
  import core.bitop, std.algorithm;
  auto v = bsr(~s[0] | 1);
  s = s[clamp(v, 1, v > 6 ? 1 : $)..$];
}

Seems to be less if i'm not wrong.



Yours runs with 790 us best time.
bsr is a real timetaker :)

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 08:17:52 UTC, Stefan Koch wrote:


Also the code produces conditional set instructions which have 
a higher latency.

And worse throughput.


On my arguably a bit dated laptop:
popFront3 performs 109 us best time
and popFront4 performs with 265 us best time

Testcode :
void main()
{
import std.datetime : StopWatch;
import std.stdio;
foreach(_;0 .. 255) {
char[] test1 = (import("blns.txt")).dup;
StopWatch sw;
sw.start;
while(test1.length) popFront(test1);
sw.stop;
writeln("pf1 took ", sw.peek.usecs, "us");
sw.reset();
}
}

blns.txt is taken from
https://github.com/minimaxir/big-list-of-naughty-strings/blob/master/blns.txt

Re: Can you shrink it further?

[Temtaime via Digitalmars-d]

On Tuesday, 11 October 2016 at 08:17:52 UTC, Stefan Koch wrote:

On Tuesday, 11 October 2016 at 08:03:40 UTC, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 07:30:26 UTC, Matthias Bentrup 
wrote:


A branch-free version:

void popFront4(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  uint char_length = 1 + (c >= 192) + (c >= 240) + (c >= 248);
  s = s.ptr[char_length .. s.length];
}

Theoretically the char_length could be computed with three 
sub and addc instructions, but no compiler is smart enough to 
detect that.


You still need to special case c < 128
as well as the follow chars.

also smaller c's are more common the bigger ones making the 
branching version faster on average.


Also the code produces conditional set instructions which have 
a higher latency.

And worse throughput.


void popFront1(ref char[] s) @trusted pure nothrow
{
  import core.bitop, std.algorithm;
  auto v = bsr(~s[0] | 1);
  s = s[clamp(v, 1, v > 6 ? 1 : $)..$];
}

Seems to be less if i'm not wrong.

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 08:03:40 UTC, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 07:30:26 UTC, Matthias Bentrup 
wrote:


A branch-free version:

void popFront4(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  uint char_length = 1 + (c >= 192) + (c >= 240) + (c >= 248);
  s = s.ptr[char_length .. s.length];
}

Theoretically the char_length could be computed with three sub 
and addc instructions, but no compiler is smart enough to 
detect that.


You still need to special case c < 128
as well as the follow chars.

also smaller c's are more common the bigger ones making the 
branching version faster on average.


Also the code produces conditional set instructions which have a 
higher latency.

And worse throughput.

Re: color lib

[Andrea Fontana via Digitalmars-d]

On Monday, 10 October 2016 at 23:26:53 UTC, Manu wrote:
I'm not sure why it matters what format the colour you have 
is...

Strings are in the form #RRGGBB, or #AARRGGBB. That is all.
It's the standard I've seen used everywhere ever, including the 
web,

which is a pretty good precedent :P


If the web is a good precedent (CSS4 specs):
"The first 6 digits are interpreted identically to the 6-digit 
notation. The last pair of digits, interpreted as a hexadecimal 
number, specifies the alpha channel of the color, where 00 
represents a fully transparent color and ff represent a fully 
opaque color."


https://drafts.csswg.org/css-color/#hex-notation

CSS3 doesn't support hex string with alpha but they suggest you 
to use rgba() function. I think argb() doesn't exists instead.

https://www.w3.org/TR/2011/REC-css3-color-20110607/#rgba-color

Chrome 52 supports it:
https://googlechrome.github.io/samples/css-alpha-channel/

Android instead:
https://developer.android.com/reference/android/graphics/Color.html#parseColor(java.lang.String)
"Parse the color string, and return the corresponding color-int. 
If the string cannot be parsed, throws an 
IllegalArgumentException exception. Supported formats are: 
#RRGGBB #AARRGGBB [...]"


Please notice that on PNG file format rgba is quite common (also 
on bmp with semi-official apha support)

PNG: http://www.libpng.org/pub/png/book/chapter08.html

[Issue 16607] New: [REG2.072b1] "forward reference" error with structs nested in struct templates

[via Digitalmars-d-bugs]

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

  Issue ID: 16607
   Summary: [REG2.072b1] "forward reference" error with structs
nested in struct templates
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: rejects-valid
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

 test.d 
struct A(T)
{
T t;

struct C
{
}
}

struct B
{
A!(typeof(this))* a;
}


Compiler output:

test.d(5): Error: struct test.A!(B).A.C has forward references
test.d(12): Error: template instance test.A!(B) error instantiating

Introduced in https://github.com/D-Programming-Language/dmd/pull/5500

--

Re: Can you shrink it further?

[Stefan Koch via Digitalmars-d]

On Tuesday, 11 October 2016 at 07:30:26 UTC, Matthias Bentrup 
wrote:


A branch-free version:

void popFront4(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  uint char_length = 1 + (c >= 192) + (c >= 240) + (c >= 248);
  s = s.ptr[char_length .. s.length];
}

Theoretically the char_length could be computed with three sub 
and addc instructions, but no compiler is smart enough to 
detect that.


You still need to special case c < 128
as well as the follow chars.

also smaller c's are more common the bigger ones making the 
branching version faster on average.

Working with ranges: mismatched function return type inference

[orip via Digitalmars-d-learn]

I get "Error: mismatched function return type inference" errors 
with choosing the return type for functions that work on ranges 
using, e.g, std.algorithm or std.range functions, but have 
different behavior based on runtime values. The return type is 
always a range with the same underlying type.


Here's an example:

auto foo(int[] ints) {
  import std.range;
  if (ints.length > 10) {
return chain(ints[0..5], ints[8..$]);
  } else {
//return ints; // Error: mismatched function return type 
inference of int[] and Result
return chain(ints[0..0], ints[0..$]); // This workaround 
compiles

  }
}

Is there a compatible return type that can be used, or some other 
workaround?
I couldn't find one when searching for the error or looking at 
the phobos source code.


Thanks! orip

Re: Can you shrink it further?

[Matthias Bentrup via Digitalmars-d]

On Tuesday, 11 October 2016 at 04:05:47 UTC, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 03:58:59 UTC, Andrei 
Alexandrescu wrote:

On 10/10/16 11:00 PM, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei 
Alexandrescu wrote:

[...]


If you want to skip a byte it's easy to do as well.

void popFront3(ref char[] s) @trusted pure nothrow {
   immutable c = s[0];
   uint char_length = 1;
   if (c < 127)
   {
   Lend :
 s = s.ptr[char_length .. s.length];
   } else {
 if ((c & b01100_) == 0b1000_)
 {
   //just skip one in case this is not the beginning of a 
code-point

char
   goto Lend;
 }
 if (c < 192)
 {
   char_length = 2;
   goto Lend;
 }
 if (c < 240)
 {
   char_length = 3;
   goto Lend;
 }
 if (c < 248)
 {
   char_length = 4;
   goto Lend;
 }
   }
 }



Affirmative. That's identical to the code in "[ ... ]" :o). 
Generated code still does a jmp forward though. -- Andrei


It was not identical.
((c & b01100_) == 0b1000_))
Can be true in all of the 3 following cases.
If we do not do a jmp to return here, we cannot guarantee that 
we will not skip over the next valid char.

Thereby corrupting already corrupt strings even more.

For best performance we need to leave the gotos in there.


A branch-free version:

void popFront4(ref char[] s) @trusted pure nothrow {
  immutable c = s[0];
  uint char_length = 1 + (c >= 192) + (c >= 240) + (c >= 248);
  s = s.ptr[char_length .. s.length];
}

Theoretically the char_length could be computed with three sub 
and addc instructions, but no compiler is smart enough to detect 
that.

Re: LDC 1.1.0-beta3 has been released!

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

Am 09.10.2016 um 14:32 schrieb Kai Nacke:

Hi everyone,

LDC 1.1.0-beta3, the LLVM-based D compiler, is available for download!
This BETA release is based on the 2.071.2 frontend and standard library
and supports LLVM 3.5-3.9.

We provide binaries for Linux, OX X, FreeBSD, Win32 & Win64, Linux/ARM
(armv7hf), now bundled with DUB. :-)

As usual, you can find links to the changelog and the binary packages
over at digitalmars.D.ldc:
http://forum.dlang.org/post/nbbocctpmaofpdxqm...@forum.dlang.org

Regards,
Kai



Just noticed that the release binaries are missing from 
https://github.com/ldc-developers/ldc/releases/tag/v1.1.0-beta3


This means that the beta currently cannot be tested with TravisCI 
(wanted to test a DUB related regression fix).

Re: weighted round robin

[vino via Digitalmars-d-learn]

On Monday, 10 October 2016 at 09:18:16 UTC, Marc Schütz wrote:

On Saturday, 8 October 2016 at 22:48:53 UTC, vino wrote:

Hi,

 Can some one guide me on how to implement the weighted round 
robin, below is what i tried or any other better ways to do it


Main Requirement : Incoming socket connection has to be sent 
to 3 servers in the weighted round robin fashion.


Prog:1
import std.stdio;
import std.range;
import std.range.primitives;

void main()
{
auto a = [1,2,3]; // E.g :Server Array
auto b = [1,2,3,4,5]; // E.g: Socket Array
auto r = roundRobin(a, b);
writeln(r);
}
OUTPUT : [1, 1, 2, 2, 3, 3, 4, 5]
Requirement : [1, 1, 2, 2, 3, 3,1,4,2,5]


auto r = roundRobin(a.cycle, b.cycle);

Beware though that this yields an infinite range. If you just 
need one round, you can use:


import std.algorithm.comparison : max;
writeln(r.take(max(a.length, b.length)));


Hi Marc,

 Thank you, I have made a small update as the Server Array is 
fixed length and the Socket array would be dynamic so made the 
below changes as now it is working as expected

Prog:1
import std.stdio;
import std.range;
import std.range.primitives;
import std.algorithm.comparison : max;

void main()
{
 auto a = [1,2,3];   // E.g :Server Array
 auto b = [1,2,3,4,5,6,7,8,9,10,11,12];  // E.g: 
Socket Array

 auto r = roundRobin(a.cycle, b.cycle);
 writeln(r.take(max(a.length, b.length * 2)));
 }

From,
Vino.B

Re: scone 1.2.0

[Suliman via Digitalmars-d-announce]

On Monday, 10 October 2016 at 19:50:53 UTC, vladdeSV wrote:
scone, Simple CONsole Engine, version 1.2.0 has just been 
released!

https://github.com/vladdeSV/scone/releases/tag/v1.2.0

This version includes a restructure of the whole project 
(should not affect applications), and the addition of a 
progress bar to the current UI library + bug fix.


Feedback is always appreciated!


Could you add example of progress bar?

Re: ptrdiff_t of class.tupleof entry

[Satoshi via Digitalmars-d-learn]

On Monday, 10 October 2016 at 18:21:10 UTC, Jonathan M Davis 
wrote:
On Monday, October 10, 2016 17:57:15 Satoshi via 
Digitalmars-d-learn wrote:

[...]


You can use the offsetof property of a member variable to find 
out the offset between its address and the address of the 
beginning of the class or struct that it's a member of.


- Jonathan M Davis




Thanks a lot!

Re: Code signing to help with Windows virus false positives

[Thomas Mader via Digitalmars-d]

On Tuesday, 11 October 2016 at 01:37:55 UTC, Martin Nowak wrote:

On Saturday, 20 August 2016 at 13:45:11 UTC, Basile B. wrote:

"to MSI using innosetup" ?

There's a misunderstanding here. Inno setup doesn't compile to 
MS installer, it's a complete independant solution.


Whatever makes more sense. From my very limited understanding 
.msi installers are natively understood installers in Windows, 
and the weapon of choice for robust and more professional 
installers.
If innosetup is just another NSIS like tool, it might not solve 
all our problems.


We're fairly clueless here and could really use help here.

Just signing the NSIS installers could work for now, any 
support for this hypothesis.
I tried to submit the latest release as sample to Microsoft but 
their file upload had a size limit smaller than the binary.


I worked with NSIS and InnoSetup. InnoSetup is much cleaner and 
easier.
At work we switched from NSIS to InnoSetup and we create MSI 
packages from NSIS and InnoSetup packages IIRC.
I think it's better to go with InnoSetup because it might be more 
easy and probably more powerful than building MSI directly. But I 
don't have any experience with building an MSI installer and the 
feature set of MSI.

We are also signing the installer and all exe and DLLs inside.

Re: Batch operations

[Nicholas Wilson via Digitalmars-d]

On Tuesday, 11 October 2016 at 03:20:54 UTC, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 03:05:12 UTC, Nicholas Wilson 
wrote:
Splitting this from the colour 
thread(https://forum.dlang.org/thread/mailman.961.1475765646.2994.digitalmar...@puremagic.com?page=1).


[...]


This will bloat like hell.
The best way would be to provide special Range-Definitions for 
those.

Such as
T[4] Front4 ()
or popFront4


It will be possible to have an overload for ranges that have 
slicing, that copies in chunks.