#dbugfix Issue 1983

[Mike Franklin via Digitalmars-d]

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

A PR addressing this issue 
(https://github.com/dlang/dmd/pull/2130), is the oldest PR in the 
DMD repository.  The issue also is almost a decade old.  I'd love 
to see it finally resolved.

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

On 2/7/2018 9:45 PM, Ralph Doncaster wrote:
> While the fix is a huge improvement, it doesn't match the code generated by 
the hex literals.  hexString!"deadbeef" stores the null-terminated string in the 
data section of the object file, while x"deadbeef" only stores 4 bytes in the 
data section.


  string s = x"deadbeef";

stores a null terminated string, too.

If you want only 4 bytes,

  __gshared immutable char[4] = hexString!"deadbeef";

just as you'd do for any string literal.

Re: missing HexString documentation

[Ralph Doncaster via Digitalmars-d]

On Thursday, 8 February 2018 at 01:53:43 UTC, Walter Bright wrote:

On 2/7/2018 11:29 AM, Ralph Doncaster wrote:
I just did a quick check, and with DMD v2.078.1, the hexString 
template increases code size by ~300 bytes vs the hex literal. 
So yet one more reason to prefer the hex literals.


Indeed it does, and that is the result of a poor implementation 
of hexString. I've figured out how to fix that, and hope to 
make a PR for it shortly.


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


While the fix is a huge improvement, it doesn't match the code 
generated by the hex literals.  hexString!"deadbeef" stores the 
null-terminated string in the data section of the object file, 
while x"deadbeef" only stores 4 bytes in the data section.

Re: missing HexString documentation

[Ralph Doncaster via Digitalmars-d]

On Thursday, 8 February 2018 at 01:27:46 UTC, Seb wrote:

On Thursday, 8 February 2018 at 00:55:28 UTC, Seb wrote:

On Wednesday, 7 February 2018 at 15:41:37 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven 
Schveighoffer wrote:

[...]


They are deprecated:

https://dlang.org/changelog/pending.html#hexstrings
https://dlang.org/deprecate.html#Hexstring%20literals

Hence, the grammar has been incompletely updated. As it's not 
an error to use them now, it should have stated that they are 
deprecated.


Anyhow, you can always go back in time:

https://docarchives.dlang.io/v2.078.0/spec/lex.html#HexString


PR: https://github.com/dlang/dlang.org/pull/2190


... and back online: http://dlang.org/spec/lex.html#hex_strings


I'm impressed.  I think I'll keep using D for at least a little 
while longer.  While it has it warts, I'm attracted to a language 
that has an intelligent group of people working to cauterize 
those warts.

Re: #dbugfix Issue 16189

[Kirr via Digitalmars-d]

On Wednesday, 7 February 2018 at 18:46:50 UTC, ketmar wrote:

...


Great brainstorming, guys! Hopefuly the gained understanding will 
lead to eventual fix.

Re: missing HexString documentation

[Ralph Doncaster via Digitalmars-d]

On Thursday, 8 February 2018 at 00:24:22 UTC, Walter Bright wrote:

On 2/7/2018 8:03 AM, Ralph Doncaster wrote:

As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.



When I tried it:

  import std.conv;
  void test() {
auto data = cast(ubyte[]) hexString!"deadbeef";
  }

with:

  dmd -c -betterC test2.d

it compiled without complaint. Are you doing something 
different? (This is why posting complete examples, not 
snippets, is better. That way I don't have to fill in the 
blanks with guesswork.)


I didn't think it would be that hard to guess I'm trying to make 
an executable.


ralphdoncaster@gl1u:~/code/d$ dmd -betterC hex.d
hex.o: In function 
`_D3std4conv__T10hexStrImplTAyaZQrFNaNbNfMQoZAa':

hex.d:(.text._D3std4conv__T10hexStrImplTAyaZQrFNaNbNfMQoZAa[_D3std4conv__T10hexStrImplTAyaZQrFNaNbNfMQoZAa]+0x2e):
 undefined reference to `_D11TypeInfo_Aa6__initZ'
hex.d:(.text._D3std4conv__T10hexStrImplTAyaZQrFNaNbNfMQoZAa[_D3std4conv__T10hexStrImplTAyaZQrFNaNbNfMQoZAa]+0x33):
 undefined reference to `_d_arraysetlengthiT'
hex.d:(.text._D3std4conv__T10hexStrImplTAyaZQrFNaNbNfMQoZAa[_D3std4conv__T10hexStrImplTAyaZQrFNaNbNfMQoZAa]+0x7c):
 undefined reference to `_D3std5ascii10isHexDigitFNaNbNiNfwZb'
hex.d:(.text._D3std4conv__T10hexStrImplTAyaZQrFNaNbNfMQoZAa[_D3std4conv__T10hexStrImplTAyaZQrFNaNbNfMQoZAa]+0x160):
 undefined reference to `_D11TypeInfo_Aa6__initZ'
hex.d:(.text._D3std4conv__T10hexStrImplTAyaZQrFNaNbNfMQoZAa[_D3std4conv__T10hexStrImplTAyaZQrFNaNbNfMQoZAa]+0x165):
 undefined reference to `_d_arraysetlengthiT'
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
ralphdoncaster@gl1u:~/code/d$ cat hex.d
import std.conv;

extern (C) int main() {
//auto data = cast(ubyte[]) x"deadbeef";
auto data = cast(ubyte[]) hexString!"deadbeef";
return cast(int) data[0];
}

While the string hex literal version works fine:
ralphdoncaster@gl1u:~/code/d$ dmd -betterC hex.d
ralphdoncaster@gl1u:~/code/d$ ./hex
ralphdoncaster@gl1u:~/code/d$ echo $?
222
ralphdoncaster@gl1u:~/code/d$ cat hex.d
//import std.conv;

extern (C) int main() {
auto data = cast(ubyte[]) x"deadbeef";
//auto data = cast(ubyte[]) hexString!"deadbeef";
return cast(int) data[0];
}

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

On 2/7/2018 6:39 PM, Adam D. Ruppe wrote:

On Thursday, 8 February 2018 at 01:55:19 UTC, Walter Bright wrote:

No, because their usage by druntime is nearly nonexistent.


Only because they're not supported!

Code like `0xsomething // octal something else` is found a whopping 200 times in 
druntime (granted btw all in the core.sys bindings).


Nearly all of that is in 3 files, and most are copy/pasta of the same groups 
lines for different systems.


I didn't find any uses of x"string" at all, or my grep-fu is wanting.

Re: Bye bye, fast compilation times

[Nick Sabalausky (Abscissa) via Digitalmars-d]

Yes. This has been a personal annoyance for many years. Even tried 
arguing some time back to get it fixed to no avail. Really hoping for 
better success this time.


On 02/06/2018 08:47 PM, jmh530 wrote:


Would it help to take the approach of mir, i.e. putting 
version(mir_test) before all the unittests?


That used to be a very common idiom. (And I agree with Jonathan M Davis: 
it's a STRONG sign the current design needs fixed). But newer versions 
of dub, intelligently, will only compile the files in the main project 
with -unittest, which solves the problem...*for dub users*. 
Unfortunately, this means that the idiom above has become less common 
and libraries have become less usable for anyone using a build tool 
*other* than dub. :(

Re: Quora: Why hasn't D started to replace C++?

[Laeeth Isharc via Digitalmars-d]

On Thursday, 8 February 2018 at 00:09:47 UTC, Ali wrote:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
Alexandrescu wrote:

https://www.quora.com/Why-hasnt-D-started-to-replace-C++

Andrei


my modest opinion about this

D currently is a small player, that have an attractive 
proposition for some


* it is like C++ (that is close to the power of C++) but simpler
* it have some unique advanced feature related to meta 
programming


D's best hope is to be a bigger player, it is unrealistic to 
replace c++

Any improvement made to D will help make it a bigger player

And while some D features can be better advertised
(like Design by Contract, DbC is a big deal, and few other 
languages are know to have it)


I think D need to constantly add features, the idea that D is 
big enough, or that it needs more idioms rather than features, 
is in my opinion wrong


D need to constantly add features, because all of it 
competitions are constantly adding features


As D add features, it may have a breakthrough, at some point


Maybe features help, but there's also just a natural process of 
maturation that we don't notice because it happens slowly.


In 2014 when I started using D it wasn't unusual for the 
compilers to segfault.  And since I didn't know D, or even modern 
compilers, their flags etc (beyond a bit of work in visual studio 
in the late 90s, I mostly learnt to program C on 8 bit CP/M, 
which was a bit different then),it was quite a confusing 
experience.  I couldn't have recommended D to somebody else then.


The documentation also was not very accessible to people who 
didn't think formally and were used to Python material.  I tried 
working with one chap, a trader who knew a bit of python and he 
was absolutely terrified of the D documentation.


The situation there is also rather better today.

Then again, how can I trust the compiler.  It means something 
that Liran at Weka said they haven't had any data corruption 
bugs, because data on they scale tends to find problems and bring 
them to the fore.


From what I have seen, big changes, much more than is generally 
appreciated are often not a consequence only of one big causal 
factor, but lots of little things aligned and coming together.


However if you want a big thing just consider growth in data set 
sizes and storage capacity and related that to trends in 
processor power and memory speed.


Guido says python is fast enough because you are bottlenecked on 
I/O and network.  But in my office I have a test infiniband 
network where the 40 Gbps switch cost about 600 quid (that's old 
technology now).  NVMe drives do pretty decent throughput.  Json 
parsing is not the cleverest thing one can do with data but how 
does that compare with the throughput from just a couple of nvme 
drives?


And according to the ACM a fundamental assumption that held true 
since the dawn of computing is in the process of being 
overturned.   With storage class memory and newer network 
technology (there's a road map to get to 1Tbps) the bottleneck 
from here isnt storage or network - it's CPU.


I guess that won't hurt the adoption of D.  Not tomorrow, but 
slowly over time.

Re: option -ignore_pure for temporary debugging (or how to wrap an unpure function inside a pure one)?

[Seb via Digitalmars-d]

On Thursday, 8 February 2018 at 03:29:54 UTC, Timothee Cour wrote:
while hacking into druntime and adding temporary debug 
information (eg with custom logging etc) I had a hard time 
making things compile because lots of functions are pure 
nothrow safe, resulting in compile errors when my custom 
debugging functions are not pure nothrow safe.



How about adding flags ` -ignore_pure` (and perhaps 
-ignore_safe -ignore_nothrow) to allow code to compile ignoring 
safe, pure, nothrow mismatches?


This would be meant for temporary debugging obviously, 
production code would not enable these flags.


my workaround for nothrow and safe attributes is to call via 
wrapNothrow!fun:


@trusted
nothrow auto wrapNothrow(alias fun, T...)(T a){
  import std.exception;
  try{
return fun(a);
  }
  catch(Exception t){
assert(0, t.msg);
  }
}

What would be a workaround to wrap a non-pure function?



This comes up every 2-3 months - we really need a better solution.

-> assumeNogc: 
https://forum.dlang.org/post/kvacxfalxqtoumatx...@forum.dlang.org



Other threads: 
https://forum.dlang.org/post/eiifgqvoimbtkgcwf...@forum.dlang.org


We really need better out-of-the-box solutions for this. There's 
debug, which already allows impure code in pure code.
It should be possible to use `debug` in same way for `@nogc`, 
`@safe` and `nothrow`.

Re: option -ignore_pure for temporary debugging (or how to wrap an unpure function inside a pure one)?

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 8 February 2018 at 03:29:54 UTC, Timothee Cour wrote:
How about adding flags ` -ignore_pure` (and perhaps 
-ignore_safe -ignore_nothrow) to allow code to compile ignoring 
safe, pure, nothrow mismatches?


We already have that for pure. Just write `debug your_function` 
and it will work.


void foo() {}

pure void main() {
debug foo();
}

Note you must use the -debug switch to dmd to compile such 
statements in, but they are exempt from the pure check.


Then for safe and nothrow, a @trusted wrapper that catches 
Exceptions and rethrows them as Errors will handle that, like you 
are basically already doing.


@nogc is the exception... I think you can cast. So this:

---
void foo() {}

@trusted nothrow @nogc void da(scope void delegate() a) {
auto hack = cast(void delegate() @nogc) a;
try
hack();
catch(Exception e)
assert(0, e.msg);
}

@safe nothrow @nogc pure void main() {
debug da({foo();});
}
---


cheats the system entirely.

Re: Quora: Why hasn't D started to replace C++?

[Laeeth Isharc via Digitalmars-d]

On Wednesday, 7 February 2018 at 21:02:11 UTC, data pulverizer 
wrote:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
Alexandrescu wrote:

https://www.quora.com/Why-hasnt-D-started-to-replace-C++

Andrei


The Betamax Problem

When you introduce something new, how do you know that it is 
going to be compelling enough for people to move from whatever 
it is they are doing and use your new thing?


It is not an easy question to answer but in the realm of 
programming languages it's a very tough question, because 
people are going to have to learn a whole new language, and its 
going to come with costs and potentially unquantifiable risks 
for any company that attempts to shift to that language. So 
whatever it is you are offering has to be tremendously 
compelling compared to what is already there.


A great deal of confusion in the world arises from failing to 
make distinctions between things that appear to be the same but 
really aren't when you look closely.


Also, in about 1870 odd there was a revolution in economic 
thought that took place more or less simultaneously in Vienna, 
Lausanne and Cambridge.  The Marginal Revolution had yet to be 
fully digested in the way people think about social phenomena.


My director of studies at Cambridge, Lord Eatwell, Labour 
spokesman in the House of Lords,  was known for his devotion to 
the work of Pierro Sraffa, a man known principally for a rather 
hostile book review of a book by Hayek and a rather slim book of 
his own, Production of Commodities by Means of Commodities, a 
book that tried to draw insights about the economy from a model 
with two goods, corn and gold.


And I think considering firms as homogeneous, with the same 
cultural values  and facing the same situation will be about as 
insightful as I think Sraffa's work ended up being - not very.


Life is risk.  It's risky to get out of bed in the morning, but 
it's also risky not to get out of bed.  And it's true that an 
agent acting on behalf of someone else - ie a manager who has no 
stake in the business - will often think about things first in 
terms of not taking a decision that might lead him to be blamed.  
But most firms are not large enterprises, and in the US small and 
medium sized firms over time create more than 100% of job growth, 
last I checked.  And a manager who is also at least to some 
extent a principal ie an owner in the business knows that to be 
conservative in a time of change is not necessarily prudent, and 
it may well also not be the profit maximising choice.


As someone who is both a manager and a part owner I disagree that 
a new technology choice needs to be overwhelmingly compelling to 
be considered.  And I don't get paid to make decisions about 
things that are easily quantifiable - what for you need me for if 
the numbers are straightforward?


The reality is that firms are very different, in a dynamic 
industry even within the same sector they are different.  And at 
any one time there are a bunch of people close to trying D or 
more.  You don't need to persuade everyone to grow.  You just 
need to persuade a few more people to tip over the margin.  And 
there are often plenty of safe ways to take risks.  You just need 
to make sure you have a plan B.  Listen to Manu's talk for a real 
example of what I mean.  And note that he said Finns are very 
conservative.


An important question is what problem set does D solve? It's 
very hard to sell a language to industry without convincingly 
answering that question. If you are selling them a 'better' 
language - that's a tougher sell. If you are selling a solution 
to a particular problem set - you stand better a chance.


But really who is selling D to anyone? We are very far from that 
stage right now.  Did someone sell D to Microsoft COM team, 
Remedy or to Weka? Nope.  People who had earned the authority to 
decide became aware of the language end decided to use it.  And 
they did so because for them it solved their particular problems 
better then anything else they could think of.


For a manager to consider D as the successor to C++, it doesn't 
just have to be a better language design than C++, it has to 
have the best language design of any compiled language and 
demonstrate the best performance.


Why?  Best in what way? Best for whom and for what kind of 
problems?


I completely disagree with that.   It needs just to be better in 
the situation then the conceivable alternatives.  And situations 
and challenges are really quite different between firms.


 Is the former really true?
Are various language features that have been inherited from 
C++/Java the best way forward? For instance does D have the 
best approach to object oriented programming, or templates? Or 
any important set of features you care to mention? Are there 
things that C++ does better than D? How straightforward is it 
to get great performance from D? Is how do you 'tune' your D 
code for high performance obvious or well documented

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

On 2/7/2018 6:39 PM, H. S. Teoh wrote:

and hope to make a PR forit shortly.

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


The bug report didn't explain what exactly in the implementation wasn't
done right. :-/


The PR does.

https://github.com/dlang/phobos/pull/6138



Another data point: instantiating 1 hex literals causes compilation
time to bloat to 10 seconds.  While I'm not saying we should expect user
code to have so many hex literals, the point is that that's unacceptably
slow for D, given our motto of fast-this and fast-that.


Try it with the new PR.

Re: option -ignore_pure for temporary debugging (or how to wrap an unpure function inside a pure one)?

[Timothee Cour via Digitalmars-d]

same question with how to wrap a gc function inside a nogc shell, if
not, allowing a flag -ignore_nogc that'd enable this (again, for
debugging purposes)

On Wed, Feb 7, 2018 at 7:29 PM, Timothee Cour  wrote:
> while hacking into druntime and adding temporary debug information (eg
> with custom logging etc) I had a hard time making things compile
> because lots of functions are pure nothrow safe, resulting in compile
> errors when my custom debugging functions are not pure nothrow safe.
>
>
> How about adding flags ` -ignore_pure` (and perhaps -ignore_safe
> -ignore_nothrow) to allow code to compile ignoring safe, pure, nothrow
> mismatches?
>
> This would be meant for temporary debugging obviously, production code
> would not enable these flags.
>
> my workaround for nothrow and safe attributes is to call via wrapNothrow!fun:
>
> @trusted
> nothrow auto wrapNothrow(alias fun, T...)(T a){
>   import std.exception;
>   try{
> return fun(a);
>   }
>   catch(Exception t){
> assert(0, t.msg);
>   }
> }
>
> What would be a workaround to wrap a non-pure function?

option -ignore_pure for temporary debugging (or how to wrap an unpure function inside a pure one)?

[Timothee Cour via Digitalmars-d]

while hacking into druntime and adding temporary debug information (eg
with custom logging etc) I had a hard time making things compile
because lots of functions are pure nothrow safe, resulting in compile
errors when my custom debugging functions are not pure nothrow safe.


How about adding flags ` -ignore_pure` (and perhaps -ignore_safe
-ignore_nothrow) to allow code to compile ignoring safe, pure, nothrow
mismatches?

This would be meant for temporary debugging obviously, production code
would not enable these flags.

my workaround for nothrow and safe attributes is to call via wrapNothrow!fun:

@trusted
nothrow auto wrapNothrow(alias fun, T...)(T a){
  import std.exception;
  try{
return fun(a);
  }
  catch(Exception t){
assert(0, t.msg);
  }
}

What would be a workaround to wrap a non-pure function?

Re: Annoyance with new integer promotion deprecations

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/06/2018 05:38 PM, Luís Marques wrote:


Yeah, it's annoying. For my MSP430 work (16-bit, lots of shorts and 
bytes) I created a generic type which works around this, so you would do:


byte c = a.nx + b;

where .nx means "non-extending" and converts/wraps the (u)byte/(u)short 
in my special type. The arithmetic operations are infectious, so you 
only need to apply it to one of the operands (and you can preserve it 
across statements by using "auto" instead of "byte").


Very cool. Would love to see this as a dub package.

Re: missing HexString documentation

[H. S. Teoh via Digitalmars-d]

On Wed, Feb 07, 2018 at 05:53:43PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/7/2018 11:29 AM, Ralph Doncaster wrote:
> > I just did a quick check, and with DMD v2.078.1, the hexString
> > template increases code size by ~300 bytes vs the hex literal. So
> > yet one more reason to prefer the hex literals.
> 
> Indeed it does, and that is the result of a poor implementation of
> hexString. I've figured out how to fix that, and hope to make a PR for
> it shortly.
> 
>   https://issues.dlang.org/show_bug.cgi?id=18397

The bug report didn't explain what exactly in the implementation wasn't
done right. :-/

Another data point: instantiating 1 hex literals causes compilation
time to bloat to 10 seconds.  While I'm not saying we should expect user
code to have so many hex literals, the point is that that's unacceptably
slow for D, given our motto of fast-this and fast-that.


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for 
Volkswagen.

Re: missing HexString documentation

[H. S. Teoh via Digitalmars-d]

On Thu, Feb 08, 2018 at 02:39:50AM +, Adam D. Ruppe via Digitalmars-d wrote:
> On Thursday, 8 February 2018 at 01:55:19 UTC, Walter Bright wrote:
> > No, because their usage by druntime is nearly nonexistent.
> 
> Only because they're not supported!
> 
> Code like `0xsomething // octal something else` is found a whopping
> 200 times in druntime (granted btw all in the core.sys bindings).

I'm guessing most of those occurrences are in interfacing with Posix (or
other OS) calls involving bitmasks, like umask().


> By contrast, the word "octal" only occurs 100 times through all of
> Phobos, and the octal template is used only 15 times, excluding its
> own unit tests.

Ironically, octal literals are probably most used in OS API calls like
umask(), so .octal really should be in druntime rather than Phobos!


T

-- 
What are you when you run out of Monet? Baroque.

Re: missing HexString documentation

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 8 February 2018 at 01:55:19 UTC, Walter Bright wrote:

No, because their usage by druntime is nearly nonexistent.


Only because they're not supported!

Code like `0xsomething // octal something else` is found a 
whopping 200 times in druntime (granted btw all in the core.sys 
bindings).


By contrast, the word "octal" only occurs 100 times through all 
of Phobos, and the octal template is used only 15 times, 
excluding its own unit tests.

Re: Bye bye, fast compilation times

[Walter Bright via Digitalmars-d]

On 2/7/2018 1:07 PM, Nathan S. wrote:

On Tuesday, 6 February 2018 at 22:29:07 UTC, Walter Bright wrote:

nobody uses regex for lexer in a compiler.


Some years ago I was surprised when I saw this in Clojure's source code. It 
appears to still be there today:


https://github.com/clojure/clojure/blob/1215ba346ffea3fe48def6ec70542e3300b6f9ed/src/jvm/clojure/lang/LispReader.java#L66-L73 



---
static Pattern symbolPat = 
Pattern.compile("[:]?([\\D&&[^/]].*/)?(/|[\\D&&[^/]][^/]*)");
//static Pattern varPat = 
Pattern.compile("([\\D&&[^:\\.]][^:\\.]*):([\\D&&[^:\\.]][^:\\.]*)");

//static Pattern intPat = Pattern.compile("[-+]?[0-9]+\\.?");
static Pattern intPat =
     Pattern.compile(
 
"([-+]?)(?:(0)|([1-9][0-9]*)|0[xX]([0-9A-Fa-f]+)|0([0-7]+)|([1-9][0-9]?)[rR]([0-9A-Za-z]+)|0[0-9]+)(N)?"); 


static Pattern ratioPat = Pattern.compile("([-+]?[0-9]+)/([0-9]+)");
static Pattern floatPat = 
Pattern.compile("([-+]?[0-9]+(\\.[0-9]*)?([eE][-+]?[0-9]+)?)(M)?");

---



Yes, I'm sure somebody does it. And now that regex has produced a match, you 
have to scan it again to turn it into a number, making for slow lexing. And if 
regex doesn't produce a match, you get a generic error message rather than 
something specific like "character 'A' is not allowed in a numeric literal".


(Generic error messages are one of the downsides of using tools like lex and 
yacc.)

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

On 2/7/2018 4:25 PM, H. S. Teoh wrote:

Should templates like octal and hexString be in druntime instead?


No, because their usage by druntime is nearly nonexistent.

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

On 2/7/2018 5:03 PM, Seb wrote:

On Thursday, 8 February 2018 at 00:24:22 UTC, Walter Bright wrote:

On 2/7/2018 8:03 AM, Ralph Doncaster wrote:

As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.



When I tried it:

  import std.conv;
  void test() {
    auto data = cast(ubyte[]) hexString!"deadbeef";
  }

with:

  dmd -c -betterC test2.d

it compiled without complaint. Are you doing something different? (This is why 
posting complete examples, not snippets, is better. That way I don't have to 
fill in the blanks with guesswork.)


https://run.dlang.io/is/TEJDZO and hit "Run".


I wish people would say "does not link" or "links with undefined symbols" or 
something more helpful than "does not work" leaving me to guess.



I also opened a Bugzilla issue, s.t. it doesn't get lost 
https://issues.dlang.org/show_bug.cgi?id=18395

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

On 2/7/2018 11:29 AM, Ralph Doncaster wrote:
I just did a quick check, and with DMD v2.078.1, the hexString template 
increases code size by ~300 bytes vs the hex literal. So yet one more reason to 
prefer the hex literals.


Indeed it does, and that is the result of a poor implementation of hexString. 
I've figured out how to fix that, and hope to make a PR for it shortly.


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

Re: missing HexString documentation

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 8 February 2018 at 00:24:22 UTC, Walter Bright wrote:

  dmd -c -betterC test2.d


Don't use -c with -betterC when doing tests. The majority of 
troubles we have are likely to be linker errors (undefined 
references to missing runtime) and that silences them.

Re: missing HexString documentation

[Seb via Digitalmars-d]

On Thursday, 8 February 2018 at 00:55:28 UTC, Seb wrote:

On Wednesday, 7 February 2018 at 15:41:37 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven 
Schveighoffer wrote:

[...]


They are deprecated:

https://dlang.org/changelog/pending.html#hexstrings
https://dlang.org/deprecate.html#Hexstring%20literals

Hence, the grammar has been incompletely updated. As it's not 
an error to use them now, it should have stated that they are 
deprecated.


Anyhow, you can always go back in time:

https://docarchives.dlang.io/v2.078.0/spec/lex.html#HexString


PR: https://github.com/dlang/dlang.org/pull/2190


... and back online: http://dlang.org/spec/lex.html#hex_strings

Re: missing HexString documentation

[Mike Franklin via Digitalmars-d]

On Thursday, 8 February 2018 at 00:25:21 UTC, H. S. Teoh wrote:


hexString is in Phobos, and druntime can't use Phobos.


Should templates like octal and hexString be in druntime 
instead?


IMO, no.  I think the interdependencies between the compiler, 
druntime, phobos, and even the packages contained within needs 
some remodeling.  I posted some of my initial thoughts here:  
https://forum.dlang.org/post/wvmgimzlwuwywxhhy...@forum.dlang.org


Mike

Re: missing HexString documentation

[Mike Franklin via Digitalmars-d]

On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven 
Schveighoffer wrote:


They are deprecated:

https://dlang.org/changelog/pending.html#hexstrings
https://dlang.org/deprecate.html#Hexstring%20literals


Wow, that's... a little superfluous.


I agree with the notion that the language should be an aggregate 
of primitives, and anything that can be composed of those 
primitives should be implemented in a library (unless a 
compelling reason is found to justify otherwise).  The 
deprecation of hex string literals has exposed flaws in the 
library implementation and the compiler's template 
implementation.  That doesn't mean deprecation was the wrong 
thing to do; it just brings the aforementioned flaws to the 
forefront, so let's not shoot the messenger.


Here's a few fundamental flaws I see in our library 
implementations.
* Some library implementations are not very cohesive, and have 
too many interdependencies.  This is what seems to prevent 
`HexString` from being used in -betterC.
* Some Phobos implementations would be quite useful in Druntime 
and in code that doesn't want to employ the runtime (e.g. 
libraries consumed by other languages, resource-constrained 
systems, and bare-metal programming), but alas, Druntime can't 
have a circular dependency on Phobos (nor should it).


This is a difficult problem, and I don't have any solutions; just 
ideas.  Maybe Phobos and Druntime should be divided into 3 
libraries:


1.  A library with no dependencies whatsoever, not even druntime, 
c runtime, or the C standard library.  Some stuff in 
`std.traits`, `std.conv`, and even `HexString` could go here.  
Let's call this library DLib.
2.  Druntime would only depend on DLib, but never publicly expose 
it.
3.  Phobos could depend on DLib or Druntime, but again, never 
publicly expose it.
4.  Phobos could be refactored by identifying packages that have 
too much coupling, and factoring out the dependencies into a 3rd, 
more cohesive library, imported by the previous two.


For extra credit:
2a. Move C/C++ standard library bindings to Deimos, and have the 
desktop OS ports import it privately.  There's no reason to 
impose this interface on bare-metal ports, and it's a superficial 
dependency anyway.
3a. Phobos shouldn't have any dependency on C/C++ language 
bindings.  DRuntime should expose an idiomatic D (and preferably 
@safe) interface for Phobos to use.


DLib could then be used in -betterC and other use cases where 
Druntime is more of a liability than an asset.


Mike

Re: missing HexString documentation

[Seb via Digitalmars-d]

On Thursday, 8 February 2018 at 00:24:22 UTC, Walter Bright wrote:

On 2/7/2018 8:03 AM, Ralph Doncaster wrote:

As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.



When I tried it:

  import std.conv;
  void test() {
auto data = cast(ubyte[]) hexString!"deadbeef";
  }

with:

  dmd -c -betterC test2.d

it compiled without complaint. Are you doing something 
different? (This is why posting complete examples, not 
snippets, is better. That way I don't have to fill in the 
blanks with guesswork.)


https://run.dlang.io/is/TEJDZO and hit "Run".

I also opened a Bugzilla issue, s.t. it doesn't get lost 
https://issues.dlang.org/show_bug.cgi?id=18395

Re: missing HexString documentation

[Seb via Digitalmars-d]

On Wednesday, 7 February 2018 at 15:41:37 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven 
Schveighoffer wrote:

On 2/7/18 9:59 AM, Ralph Doncaster wrote:

[...]


Good catch! Even the grammar says nothing about what it is, 
except it has HexString as a possible literal.


Can you file an issue? https://issues.dlang.org

-Steve


They are deprecated:

https://dlang.org/changelog/pending.html#hexstrings
https://dlang.org/deprecate.html#Hexstring%20literals

Hence, the grammar has been incompletely updated. As it's not 
an error to use them now, it should have stated that they are 
deprecated.


Anyhow, you can always go back in time:

https://docarchives.dlang.io/v2.078.0/spec/lex.html#HexString


PR: https://github.com/dlang/dlang.org/pull/2190

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

On 2/7/2018 4:08 PM, Mike Franklin wrote:

Don't search for "[betterC]".  Instead, use "betterC" (without the brackets).

https://issues.dlang.org/buglist.cgi?quicksearch=betterc&list_id=219390

We can't reliably rely on informal conventions.


I used the wrong URL. This is the right one (a keyword search, not a text 
search):

https://issues.dlang.org/buglist.cgi?keywords=betterC&list_id=219394&resolution=---

which lists 13 issues. Two of them were missing, and I annotated them with the 
keyword betterC, so it's 15.

Re: missing HexString documentation

[H. S. Teoh via Digitalmars-d]

On Wed, Feb 07, 2018 at 04:11:19PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/7/2018 12:13 PM, Adam D. Ruppe wrote:
> > even that minor hassle has hurt the use in practice, like in the
> > druntime examples.
> 
> hexString is in Phobos, and druntime can't use Phobos.

Should templates like octal and hexString be in druntime instead?


T

-- 
There are 10 kinds of people in the world: those who can count in binary, and 
those who can't.

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

On 2/7/2018 8:03 AM, Ralph Doncaster wrote:

As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.



When I tried it:

  import std.conv;
  void test() {
auto data = cast(ubyte[]) hexString!"deadbeef";
  }

with:

  dmd -c -betterC test2.d

it compiled without complaint. Are you doing something different? (This is why 
posting complete examples, not snippets, is better. That way I don't have to 
fill in the blanks with guesswork.)

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

On 2/7/2018 12:13 PM, Adam D. Ruppe wrote:

even that minor hassle has hurt the use in practice, like in the druntime 
examples.


hexString is in Phobos, and druntime can't use Phobos.

Re: missing HexString documentation

[Mike Franklin via Digitalmars-d]

On Wednesday, 7 February 2018 at 23:30:57 UTC, Walter Bright 
wrote:


Can you please provide a list of these issues, and file issues 
that aren't on bugzilla yet, and tag them with the betterC 
keyword?


I see only one:

https://issues.dlang.org/buglist.cgi?quicksearch=%5Bbetterc%5D&list_id=219382


Don't search for "[betterC]".  Instead, use "betterC" (without 
the brackets).


https://issues.dlang.org/buglist.cgi?quicksearch=betterc&list_id=219390

We can't reliably rely on informal conventions.

Mike

Re: Quora: Why hasn't D started to replace C++?

[Ali via Digitalmars-d]

On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu 
wrote:

https://www.quora.com/Why-hasnt-D-started-to-replace-C++

Andrei


my modest opinion about this

D currently is a small player, that have an attractive 
proposition for some


* it is like C++ (that is close to the power of C++) but simpler
* it have some unique advanced feature related to meta programming

D's best hope is to be a bigger player, it is unrealistic to 
replace c++

Any improvement made to D will help make it a bigger player

And while some D features can be better advertised
(like Design by Contract, DbC is a big deal, and few other 
languages are know to have it)


I think D need to constantly add features, the idea that D is big 
enough, or that it needs more idioms rather than features, is in 
my opinion wrong


D need to constantly add features, because all of it competitions 
are constantly adding features


As D add features, it may have a breakthrough, at some point

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

On 2/7/2018 8:05 AM, Adam D. Ruppe wrote:

That's just because -betterC is buggy and extremely incomplete


Can you please provide a list of these issues, and file issues that aren't on 
bugzilla yet, and tag them with the betterC keyword?


I see only one:

https://issues.dlang.org/buglist.cgi?quicksearch=%5Bbetterc%5D&list_id=219382

Re: Quora: Why hasn't D started to replace C++?

[John Gabriele via Digitalmars-d]

On Wednesday, 7 February 2018 at 21:02:11 UTC, data pulverizer 
wrote:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
Alexandrescu wrote:

https://www.quora.com/Why-hasnt-D-started-to-replace-C++

Andrei


The Betamax Problem


I don't think the analogy holds. With VHS and betamax, you just 
put in the tape and watch your movie. Most people didn't care 
very much what the name on the machine said --- both types of 
machines had the same buttons.


In contrast to that, programmers are very particular about the 
languages they use (which includes tooling, community, module 
repos, available books).


An important question is what problem set does D solve? It's 
very hard to sell a language to industry without convincingly 
answering that question. If you are selling them a 'better' 
language - that's a tougher sell. If you are selling a solution 
to a particular problem set - you stand better a chance.


My impression is that the object is not necessarily to sell D to 
industry, but rather to sell it to developers. Developers choose 
what they want to learn and use at home and in side projects. 
Then at work some tools here and there get written in it. Then 
some customer-facing projects. Before you know it, it's been 
"sold to industry".


I think, as of last year, D has upped its sales (to developers) 
game:


  * fully open-sourced dmd

  * GDC slated for inclusion into GCC

  * there's been talk of adding some markdown features to ddoc. 
Cosmetic, yes; sells D well to developers, emphatically yes.


I'm not sure how long dub has been around, but having an easy to 
use CPAN-alike (online module repo) is HUGE. Dub is great for 
sales. The better dub and the repo gets, the more attractive D 
gets.

Re: Bye bye, fast compilation times

[Bastiaan Veelo via Digitalmars-d]

On Wednesday, 7 February 2018 at 09:27:47 UTC, Stefan Koch wrote:
Another Thing that can be done is reviewing the code and 
alerting me to potential problems. i.e. Missing or 
indecipherable comments as well as spelling mistakes.
(with the correction please (just telling me something is 
wrong, will not help since I obliviously don't know how to 
spell it))


What is the preferred place for this? 
https://github.com/dlang/dmd/pull/7073 or do you want PRs against 
a fork of yours?

Re: Status status = __traits(compilesReportError, {string b=10; }) => status.msg=Error: cannot....

[Timothee Cour via Digitalmars-d]

understood, but that's responsibility of tester to make sure they're
not too flaky (eg using msg.canFind("FOO") (or, if regex weren't slow,
regex)



On Wed, Feb 7, 2018 at 1:13 PM, Nicholas Wilson via Digitalmars-d
 wrote:
> On Wednesday, 7 February 2018 at 20:29:44 UTC, Timothee Cour wrote:
>>
>> is there any way to get error from speculative execution (`__traits(
>> compiles, ...)`)? would be useful in tests; If not currently how hard
>> would that be to implement? eg:
>>
>> ```
>>
>> struct Status{bool ok; string msg;}
>>
>> Status status = __traits(compilesReportError, {string b=10;})
>> assert(!status.ok);
>> assert(status.msg==`main.d(15) Error: cannot implicitly convert
>> expression 10 of type int to string`);
>> ```
>
>
> Probably not very hard. Would make for some nice diagnostics,but very flakey
> tests. Compiler errors are frequently changed.

Re: Status status = __traits(compilesReportError, {string b=10; }) => status.msg=Error: cannot....

[Nicholas Wilson via Digitalmars-d]

On Wednesday, 7 February 2018 at 20:29:44 UTC, Timothee Cour 
wrote:
is there any way to get error from speculative execution 
(`__traits(
compiles, ...)`)? would be useful in tests; If not currently 
how hard

would that be to implement? eg:

```

struct Status{bool ok; string msg;}

Status status = __traits(compilesReportError, {string b=10;})
assert(!status.ok);
assert(status.msg==`main.d(15) Error: cannot implicitly convert
expression 10 of type int to string`);
```


Probably not very hard. Would make for some nice diagnostics,but 
very flakey tests. Compiler errors are frequently changed.

Re: Bye bye, fast compilation times

[Nathan S. via Digitalmars-d]

On Tuesday, 6 February 2018 at 22:29:07 UTC, Walter Bright wrote:

nobody uses regex for lexer in a compiler.


Some years ago I was surprised when I saw this in Clojure's 
source code. It appears to still be there today:


https://github.com/clojure/clojure/blob/1215ba346ffea3fe48def6ec70542e3300b6f9ed/src/jvm/clojure/lang/LispReader.java#L66-L73

---
static Pattern symbolPat = 
Pattern.compile("[:]?([\\D&&[^/]].*/)?(/|[\\D&&[^/]][^/]*)");
//static Pattern varPat = 
Pattern.compile("([\\D&&[^:\\.]][^:\\.]*):([\\D&&[^:\\.]][^:\\.]*)");

//static Pattern intPat = Pattern.compile("[-+]?[0-9]+\\.?");
static Pattern intPat =
Pattern.compile(

"([-+]?)(?:(0)|([1-9][0-9]*)|0[xX]([0-9A-Fa-f]+)|0([0-7]+)|([1-9][0-9]?)[rR]([0-9A-Za-z]+)|0[0-9]+)(N)?");
static Pattern ratioPat = 
Pattern.compile("([-+]?[0-9]+)/([0-9]+)");
static Pattern floatPat = 
Pattern.compile("([-+]?[0-9]+(\\.[0-9]*)?([eE][-+]?[0-9]+)?)(M)?");

---

Re: Quora: Why hasn't D started to replace C++?

[data pulverizer via Digitalmars-d]

On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu 
wrote:

https://www.quora.com/Why-hasnt-D-started-to-replace-C++

Andrei


The Betamax Problem

When you introduce something new, how do you know that it is 
going to be compelling enough for people to move from whatever it 
is they are doing and use your new thing?


It is not an easy question to answer but in the realm of 
programming languages it's a very tough question, because people 
are going to have to learn a whole new language, and its going to 
come with costs and potentially unquantifiable risks for any 
company that attempts to shift to that language. So whatever it 
is you are offering has to be tremendously compelling compared to 
what is already there.


An important question is what problem set does D solve? It's very 
hard to sell a language to industry without convincingly 
answering that question. If you are selling them a 'better' 
language - that's a tougher sell. If you are selling a solution 
to a particular problem set - you stand better a chance.


For a manager to consider D as the successor to C++, it doesn't 
just have to be a better language design than C++, it has to have 
the best language design of any compiled language and demonstrate 
the best performance. Is the former really true? Are various 
language features that have been inherited from C++/Java the best 
way forward? For instance does D have the best approach to object 
oriented programming, or templates? Or any important set of 
features you care to mention? Are there things that C++ does 
better than D? How straightforward is it to get great performance 
from D? Is how do you 'tune' your D code for high performance 
obvious or well documented?


If the answers to any of the above questions is a negative for D, 
that's a serious problem if what you want to do is replace C++, 
because C++ is already a solid well know language and the 
competition from new programming languages is extremely tough, 
and because its only going to get easier to create programming 
languages this competition will get tougher.


To finish the Betamax story, when CD came along, people dropped 
cassette tapes like hot potatoes and DVDs killed VHS stone dead. 
Does D represent a similar leap from C++?


I'm not saying that D is Betamax. I'm just giving food for 
thought.

Status status = __traits(compilesReportError, {string b=10;}) => status.msg=Error: cannot....

[Timothee Cour via Digitalmars-d]

is there any way to get error from speculative execution (`__traits(
compiles, ...)`)? would be useful in tests; If not currently how hard
would that be to implement? eg:

```

struct Status{bool ok; string msg;}

Status status = __traits(compilesReportError, {string b=10;})
assert(!status.ok);
assert(status.msg==`main.d(15) Error: cannot implicitly convert
expression 10 of type int to string`);
```

Re: missing HexString documentation

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 7 February 2018 at 18:59:38 UTC, Steven 
Schveighoffer wrote:
Not even close. Octal literals are a disaster, because putting 
a leading 0 should never change the base of a number.


I agree the leading 0 is terrible. But that's not the real 
question here: it is 0o100 vs import std.conv. Note it isn't the 
syntax - octal!100 is quite nice to me - but rather the 
requirement to import.


That is why it isn't used in druntime... and low level code 
interfacing with external OS or hardware APIs are the most common 
place for octal, and also where we can't use it. I fear hex will 
fall into the same pit.



This has its own problems (e.g. 0O)


That's why I specifically wrote `0o`. I wouldn't allow `0O`, just 
like D doesn't allow `1l`: "Error: lower case integer suffix 'l' 
is not allowed. Please use 'L' instead"


The difference for me isn't how the problem is solved, but that 
there was a problem for octals (error prone sinister errors) 
but there isn't/wasn't one for hex strings.


You and I are on the same side :) I also think they should stay 
(I just want to see them retyped as immutable(ubyte)[] instead of 
immutable(char)[], we always cast anyway).


I'd repurpose the library hexString to actually read in hex dump, 
stripping offsets, etc, off. Demonstrate that you can strip other 
stuff from the string with CTFE as an example of what we can do 
so people can customize that (that's a big advantage of the 
function over the literal btw, you can feed stuff through ctfe 
modifier functions before it is parsed. Can't do that with a 
literal!)


But also keep the x"" literal for the simple cases we already 
have.

Re: missing HexString documentation

[H. S. Teoh via Digitalmars-d]

On Wed, Feb 07, 2018 at 07:29:10PM +, Ralph Doncaster via Digitalmars-d 
wrote:
[...]
> I just did a quick check, and with DMD v2.078.1, the hexString
> template increases code size by ~300 bytes vs the hex literal.  So yet
> one more reason to prefer the hex literals.

Arguably, this is a QoI issue.  We seriously need to take a closer look
at the current implementation of templates and consider how to improve
it.  There is definitely plenty of room for improvement.


T

-- 
Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, 
binary trees... and bugs.

Re: missing HexString documentation

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 7 February 2018 at 19:38:35 UTC, Ali Çehreli wrote:
It sounds so natural. I forgot; what was the argument against 
it?


0o was denied basically just because we felt it wasn't necessary 
to have in the language at all; that it was rare enough and the 
library *can* do it, so the library *should* do it.


And at the time, I totally agreed! And in some cases, I still do 
- I think D programmers ought to know the technique so they can 
use it for their own niches.


Just in the years since, we see `0x40; // octal 0100` instead of 
`octal!100` since the cost of the library import is higher than 
the cost of converting by hand to hex or binary, which are still 
built into the language.

Re: missing HexString documentation

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 7 February 2018 at 17:36:56 UTC, Seb wrote:

Octal predates GitHub, hexString is new:


Yes, I know, I was there :)

Heck, in the hexString forum thread, I argued that people knowing 
this pattern is really useful because then they can do all kinds 
of custom literals like stripping hexdumps.


Back in the octal days, I was thinking we should replace several 
literals with the new pattern and do more user-defined stuff. 
Notice who is cited in this old article 
http://www.drdobbs.com/tools/user-defined-literals-in-the-d-programmi/229401068



But, in the years since, I've changed my mind... somewhat. The 
pattern is still good and it being customizable is awesome, but 
it is a minor hassle and even that minor hassle has hurt the use 
in practice, like in the druntime examples.


We can do user defined literals for base X if we need more. But 
since octal is used by operating system apis and that'd under 
phobos... the phobos solution isn't great. Hex strings I think 
are going to be basically the same in time. The library artifact 
will sit there, unused.

dmd -unittest=+foo.bar,+std,-std.stdio args... to specify unittests in select pkg/mod

[Timothee Cour via Digitalmars-d]

how about using same syntax (and reusing logic) as newly introduced`
-i=+foo.bar,+baz-baz.bad`:

`dmd -unittest=+foo.bar,+baz,-baz.bad rest_of_arguments`

which would only enable unittests as specified? It's flexible and
intuitive, and would solve a common woe with unittests (eg
https://forum.dlang.org/post/mailman.3165.1517968619.9493.digitalmar...@puremagic.com)

originally proposed here:
https://forum.dlang.org/post/mailman.3166.1517969180.9493.digitalmar...@puremagic.com

Re: missing HexString documentation

[Ali Çehreli via Digitalmars-d]

On 02/07/2018 09:01 AM, Adam D. Ruppe wrote:

> But for octal? It was a mistake. We should have just made it 0o.

It sounds so natural. I forgot; what was the argument against it?

Ali

Re: missing HexString documentation

[Ralph Doncaster via Digitalmars-d]

On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven 
Schveighoffer wrote:
Seems like the same code you would need to parse the first is 
reusable for the second, no? I don't see why this deprecation 
was necessary, and now we have more library/template baggage.


-Steve


For the same reason why octal literals have been deprecated 
years ago:


https://dlang.org/deprecate.html#Octal%20literals

The library solution works as well and it's one of the features 
that are rarely used and add up to the steep learning curve.


I, like Steve, disagree.
Coming from c/c++ (and some Java), this was really simple to 
understand:

x"deadbeef"
While this took a lot more time to understand:
hexString!"deadbeef"

For hexString, I had to understand that ! is for function 
template instantiation, and I also had to find out what library 
to import.

Re: missing HexString documentation

[Ralph Doncaster via Digitalmars-d]

On Wednesday, 7 February 2018 at 19:25:37 UTC, Ralph Doncaster 
wrote:

On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven 
Schveighoffer wrote:
Seems like the same code you would need to parse the first is 
reusable for the second, no? I don't see why this deprecation 
was necessary, and now we have more library/template baggage.


-Steve


For the same reason why octal literals have been deprecated 
years ago:


https://dlang.org/deprecate.html#Octal%20literals

The library solution works as well and it's one of the 
features that are rarely used and add up to the steep learning 
curve.


I, like Steve, disagree.
Coming from c/c++ (and some Java), this was really simple to 
understand:

x"deadbeef"
While this took a lot more time to understand:
hexString!"deadbeef"

For hexString, I had to understand that ! is for function 
template instantiation, and I also had to find out what library 
to import.


I just did a quick check, and with DMD v2.078.1, the hexString 
template increases code size by ~300 bytes vs the hex literal.  
So yet one more reason to prefer the hex literals.

Re: missing HexString documentation

[Steven Schveighoffer via Digitalmars-d]

On 2/7/18 12:01 PM, Adam D. Ruppe wrote:

On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:

For the same reason why octal literals have been deprecated years ago:

https://dlang.org/deprecate.html#Octal%20literals


Not even close. Octal literals are a disaster, because putting a leading 
0 should never change the base of a number. Basically, causing bugs 
everywhere for a small corner case in the real world.


The octal literal library solution is good, and it's fine to have 
something in the library for this, as octal values are extremely rare to 
need.


But in this case, there is no ambiguity. x"..." is not obvious syntax 
for anything else. Not only that, but the code to parse hex data into a 
string is still in there for "\x..." So we didn't even remove anything 
significant.


The library solution works as well and it's one of the features that 
are rarely used and add up to the steep learning curve.


How so? If you see a hex string literal, you look it up, and now your 
learning curve is over.


That's actually not the reason given. Octal literals had the stupid 
leading 0. We should have just made it 0o instead.


This has its own problems (e.g. 0O), but definitely would have solved 
the issue. However, octal numbers are way less common than strings of 
hexadecimal data bytes.


The difference for me isn't how the problem is solved, but that there 
was a problem for octals (error prone sinister errors) but there 
isn't/wasn't one for hex strings. Not only that, but the removal from 
the language doesn't really buy us any savings in the compiler. It's 
basically removing things for the sake of removing them.


Similarly, I think the mistake of hex strings is that they are typed 
char[] instead of ubyte[]. Otherwise... they work ok.


Yes, they would be better as ubyte[], but this problem is not the end of 
the world. I don't consider it the same level as thinking 012 is 12.


-Steve

Re: #dbugfix Issue 16189

[ketmar via Digitalmars-d]

Bastiaan Veelo wrote:


On Wednesday, 7 February 2018 at 11:37:19 UTC, Michael wrote:
Does it work with slightly varied examples like where a = -1, and is 
incremented etc.?


I played with it here https://run.dlang.io/is/15sr6c and every variation 
I tried worked (correctly). So the example seems to be pretty minimal. 
Maybe someone understanding assembly is able to see what is going on 
after pressing that nice [ASM] button?


there is a mix of loop strength reduction and data flow analysis. as inner 
loop contains array access and bounds checking, optimizer decided to turn 
`a` into actual index (i.e. multiply it by 16), and use subtraction in loop body.


so far so good, optimizer did a good job. but then we have `assert(a == 
-1);` after the loop. and that is where things goes off the road: optimizer 
knows that it has `a` in register, and it knows that `a` was pre-multiplied, 
so it decided to divide `a` to 16 to get the real value. but... it does 
this with `shr` instruction instead of `sar`! most of the time it works as 
expected, but in our case... oops, we lost a sign.


the fix should be fairly easy, but sorry, i can't get any sense from dmd 
backend. i see what it wrong due to my expirience with similar things, but 
that's all. here Walter (or some other backand guru) should step in.

Re: Quora: Why hasn't D started to replace C++?

[John Gabriele via Digitalmars-d]

On Friday, 2 February 2018 at 14:30:25 UTC, Russel Winder wrote:
On Thu, 2018-02-01 at 19:28 +, John Gabriele via 
Digitalmars-d wrote:
On Thursday, 1 February 2018 at 03:00:07 UTC, Walter Bright 
wrote:

> On 1/31/2018 5:58 PM, H. S. Teoh wrote:
> > cosmetic features.
> 
> I tough lesson I've learned is that cosmetics matter, a lot. 
> Sometimes much more than substance. There's no getting away 
> from it.


I agree but only if s/Markdown/AsciiDoctor/g

This is one reason I recommend markdown for docs. Cosmetics is 
what markdown does best. People *like* looking at it and 
editing it. It's like typing an email or a forum comment.


Other reasons I recommend it are:

   * everyone already knows it (it's at github, stackoverflow, 
and

reddit),

   * it's fairly easy to write (as easy as possible while still
looking good),

   * there's an open spec (CommonMark), and

   * writing new language-specific markup formats appears to be
something that's not done anymore. There's javadoc, texinfo,
doxygen, docbook, groff --- all very ... *mature* technologies.
In modern projects: Rust uses markdown, Python uses reST, Git
uses asciidoc --- all general-purpose non- language-specific
lightweight markup formats.

The only reason I can think of for *not* using markdown for 
project docs is if your project is another competing 
lightweight markup format.


Markdown was created to write a few HTML pages. AsciiDoc (and 
thus AsciiDoctor) was invented to be a front end to the 
DocBook/XML toolchain.


Thus Markdown is for a few small very simple webpages, 
AsciiDoctor is for creating any form of document from a page to 
a book. They are similar where Markdown has functionality, but 
AsciiDoctor has so much more, and most people end up finding 
they want all the extras. XeLaTeX and Sphinx/ReStructuredText 
are the competition for AsciiDoctor. Markdown is lacking in 
functionality people will find they need to use.


Note that markdown is a small sharp tool in your toolbox: for 
writing easily readable (in plain text) docs, easily converted to 
html. For more than that, tools like [Pandoc](http://pandoc.org):


  * convert markdown to html but also to a bunch of other formats 
as well, and


  * support extra markdown functionality like tables, definition 
lists, footnotes, and citations. Don't know how if handles making 
an index.


Also, note that it's not uncommon to write a short script that 
stitches together a handful of markdown docs into a website or 
other larger composite doc. I even wrote one myself: 
. 
There may be others listed at 
.

Re: Quora: Why hasn't D started to replace C++?

[John Gabriele via Digitalmars-d]

On Friday, 2 February 2018 at 14:25:53 UTC, Russel Winder wrote:
On Thu, 2018-02-01 at 19:41 +, John Gabriele via 
Digitalmars-d wrote:



[…]
It's trivial to put multiple markdown files together into a 
large doc, if that's desired. Just put a bunch of .md files 
together into the same directory and run your markdown 
processor on them. They can link to each other in the [normal 
way](./other-file.html#normal-way).


Auto generation of contents pages, and indexes? Tables? Nested 
lists? The CommonMark crib sheet says nothing. AsciiDoctor has 
all of them, though I prefer XeLaTeX.


CommonMark is the less featureful common denominator markdown. 
For myself, to get TOC's and tables I use 
[Pandoc](http://pandoc.org/).


But I see your point. For larger complete documents like books, 
you want tools that can handle all the things that books require.


But, afaik, we're talking about 2 specific needs here:

 1. documenting code in a way that gets extracted and rendered 
into html

 2. dlang.org doc webpages

with a secret 3rd need: you want contributors to be willing to 
write and update these.


Markdown provides a simple, practical, modern, and 
commonly-known way to get docs written fast and by anyone who 
wants to pop in and improve them. There's no easier way to 
write plain text docs that look as good.


AsciiDoctor.


Everyone already knows and uses Markdown. It's so common that it 
gets used in plain text forums like this one, sometimes without 
folks even knowing they're using it. For short plain text docs 
that may be converted to html, markdown has won and is the 
easiest on-ramp for some writer who has a few minutes and is 
willing to write some doc-comments for a function (or a confusing 
passage in the docs) that they just stumbled over.


Sorry, can't recall if I already mentioned this, but D suffers 
from a perception that it's "old", or "the language that tried 
and failed to replace C++". Something simple like markdown for 
its docs sends a clear message that D is modern and knows when 
to pivot to new and better ways after the old ways are not 
serving it anymore.


Markdown is so last decade. Ditto AsciiDoctor. XeLateX so last 
millenium. The question is choosing the right tool for the job, 
not pandering to hipster fashionistas. Clearly one reviews new 
ways and moves to them if that provides a better way forward, 
but the goal is more important that the technology.


I wouldn't say markdown is last decade (not sure if you're 
joking). More like it's simply become part of the background at 
this point since it's so commonly used.


But I agree about not pandering to fashion. The goal is to make 
it as easy as possible to document your code and have tools 
render it as html for users to make use of, as well as making it 
easy as possible for potential contributors to jump in and make 
edits/improvements. I think markdown is the best way to acheive 
that goal.


There are the autogenerated reference pages. JavaDoc, Doxygen, 
all have their upside and downside. D has DDOC, is it fit for 
purpose? Should it be replaced (by Doxygen) or evolved? Maybe 
Markdown fits here, but without table support you end up 
hacking stuff. cf. vast tracts of early JavaDoc stuff.


Pandoc extends CommonMark and has tables, definiton lists, and a 
couple of other things worth imitating. Regarding tables, it 
supports three styles (again, the default easy-on-the-eyes style, 
plus a couple others --- see their docs). See 
.





Incidentally, choosing an established standard like markdown 
is a good way to short-circuit bikeshedding about "it what 
ways should ddoc be updated to include some markdown 
features?". Just pick standard CommonMark markdown and you're 
done.


s/Markdown/AsciiDoctor/g


AsciiDoctor appears to be tuned for writing long docs like books. 
Markdown beats it on looks, convenience, and popularity --- 
exactly the things you want to attract folks to writing more 
comment docs and web pages.


One last note and I'll (try to!) stop: it's difficult enough 
to get good writers to help with docs. Much more so when 
they've got to first learn your own language-specific markup 
(which is only useful with your project).


This is a good and strong point, that has been raised in many 
other places I frequent. One group changed from their custom 
DocBook/XML to Sphinx because someone did stuff rather than 
talking about it. AsciiDoctor would clearly have been a better 
solution, evolution using the DocBook toolchain, but they went 
for the revolution because people put effort into it to make 
the decision happen.


The core point is how are you going to get pull requests from 
people to update and evolve the documentation. An esoteric, 
indeed unique, markup language is clearly the wrong choice.


I don't understand your comment there. I group DDoc, Docbook XML, 
DDoc, Texinfo, groff, etc. all in the same esoteric unique markup 
languages camp. If I wanted to m

Re: missing HexString documentation

[Seb via Digitalmars-d]

On Wednesday, 7 February 2018 at 17:01:54 UTC, Adam D. Ruppe 
wrote:
The octal library solution is brilliant. The genius who wrote 
that code is clearly god-like and we should all fall to our 
knees and worship his superior intellect. That pattern DOES 
have uses.


Octal predates GitHub, hexString is new:

https://github.com/dlang/phobos/pull/3133

Re: missing HexString documentation

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 7 February 2018 at 16:51:02 UTC, Seb wrote:
For the same reason why octal literals have been deprecated 
years ago:


https://dlang.org/deprecate.html#Octal%20literals

The library solution works as well and it's one of the features 
that are rarely used and add up to the steep learning curve.


That's actually not the reason given. Octal literals had the 
stupid leading 0. We should have just made it 0o instead.


The library solution does not work just as well, since it doesn't 
work at all in some places. Behold:


http://dpldocs.info/experimental-docs/source/core.sys.posix.fcntl.d.html#L123

   version (X86)
{
enum O_CREAT= 0x40; // octal 0100
enum O_EXCL = 0x80; // octal 0200
enum O_NOCTTY   = 0x100;// octal 0400
enum O_TRUNC= 0x200;// octal01000


That's from druntime. The comments being there indicate the hex 
is not obvious in this context; the octal would be more 
illustrative. But the lack of use of std.conv shows it wasn't 
applicable where the literal was (since this is druntime, phobos 
isn't available).



The octal library solution is brilliant. The genius who wrote 
that code is clearly god-like and we should all fall to our knees 
and worship his superior intellect. That pattern DOES have uses.


But for octal? It was a mistake. We should have just made it 0o.


Similarly, I think the mistake of hex strings is that they are 
typed char[] instead of ubyte[]. Otherwise... they work ok. And 
when learning, you don't need to know every bit. You'd just 
ignore it unless you hit upon the niche where it matters. (that's 
the way I learned basically all of D. my early D code is 
virtually identical to my C code, a bit later, similar to old 
style Java code. only after being in it for a while did i go nuts 
mastering the language.)

Re: missing HexString documentation

[Seb via Digitalmars-d]

On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven 
Schveighoffer wrote:

On 2/7/18 10:41 AM, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven 
Schveighoffer wrote:

On 2/7/18 9:59 AM, Ralph Doncaster wrote:

It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals

 From reading forum posts I managed to figure out that 
HexStrings are prefixed with an x.  i.e. x"deadbeef"




Good catch! Even the grammar says nothing about what it is, 
except it has HexString as a possible literal.


Can you file an issue? https://issues.dlang.org



They are deprecated:

https://dlang.org/changelog/pending.html#hexstrings
https://dlang.org/deprecate.html#Hexstring%20literals


Wow, that's... a little superfluous.

So we support this:

"\xde\xad\xbe\xef"

but not this?

x"deadbeef"

Seems like the same code you would need to parse the first is 
reusable for the second, no? I don't see why this deprecation 
was necessary, and now we have more library/template baggage.


-Steve


For the same reason why octal literals have been deprecated years 
ago:


https://dlang.org/deprecate.html#Octal%20literals

The library solution works as well and it's one of the features 
that are rarely used and add up to the steep learning curve.

Re: How hard would it be to get DMD to generate SIMD code for all x86 targets?

[Stefan Koch via Digitalmars-d]

On Wednesday, 7 February 2018 at 16:22:13 UTC, solidstate1991 
wrote:
It would be also great if 32 bit and 64 bit long vector loading 
could be supported, so I don't have to write separate functions 
for that. Had to delete a lot of code I wrote in Assembly after 
I made a big mistake thanks to its much poorer readability 
compared to much more modern languages.


If it's not a hard task, I might do it by myself.


enabling it should not be too hard actually.
Debugging it is another matter.

How hard would it be to get DMD to generate SIMD code for all x86 targets?

[solidstate1991 via Digitalmars-d]

It would be also great if 32 bit and 64 bit long vector loading 
could be supported, so I don't have to write separate functions 
for that. Had to delete a lot of code I wrote in Assembly after I 
made a big mistake thanks to its much poorer readability compared 
to much more modern languages.


If it's not a hard task, I might do it by myself.

Re: Thread safe reference counting

[Kagamin via Digitalmars-d]

On Wednesday, 7 February 2018 at 14:09:51 UTC, Atila Neves wrote:

auto ptr = new shared RefCounted!(...);


If you rely only on postblit, then you can't concurrently read 
and write to refcounted shared storage without additional mutex 
lock, so it should be at least a non-copyable container (similar 
to what rust does).

Re: missing HexString documentation

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 7 February 2018 at 16:03:17 UTC, Ralph Doncaster 
wrote:

As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.


That's just because -betterC is buggy and extremely incomplete 
(this is why I'm so annoyed that it is getting advertised, it is 
nowhere near ready for use). there's no reason why it shouldn't 
work once those bugs get fixed.

Re: missing HexString documentation

[Steven Schveighoffer via Digitalmars-d]

On 2/7/18 10:41 AM, Seb wrote:

On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven Schveighoffer wrote:

On 2/7/18 9:59 AM, Ralph Doncaster wrote:

It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals

 From reading forum posts I managed to figure out that HexStrings are 
prefixed with an x.  i.e. x"deadbeef"




Good catch! Even the grammar says nothing about what it is, except it 
has HexString as a possible literal.


Can you file an issue? https://issues.dlang.org



They are deprecated:

https://dlang.org/changelog/pending.html#hexstrings
https://dlang.org/deprecate.html#Hexstring%20literals


Wow, that's... a little superfluous.

So we support this:

"\xde\xad\xbe\xef"

but not this?

x"deadbeef"

Seems like the same code you would need to parse the first is reusable 
for the second, no? I don't see why this deprecation was necessary, and 
now we have more library/template baggage.


-Steve

Re: missing HexString documentation

[Ralph Doncaster via Digitalmars-d]

On Wednesday, 7 February 2018 at 15:54:05 UTC, Ralph Doncaster 
wrote:
Doesn't that go against the idea of -betterC, or will std.conv 
work with -betterC.


p.s. contrary to what the deprecation notice says, hex strings 
are very often used in crypto/hashing test cases.  Most hash 
specs have example hash strings to verify implementation code.


As expected,
auto data = cast(ubyte[]) x"deadbeef";
works with -betterC, but
auto data = cast(ubyte[]) hexString!"deadbeef";
does not.

Re: Annoyance with new integer promotion deprecations

[Stefan Koch via Digitalmars-d]

On Tuesday, 6 February 2018 at 20:23:02 UTC, Walter Bright wrote:
[...] DFA is a complex thing. This is why DFA is done on the 
vastly simplified and canonicalized intermediate code, not the 
ASTs.


Doing DFA for VRP means doing it on the ASTs.

I know what you're asking for sounds simple enough. But it 
ain't.


What you're saying is true.
There is a way though to have the cake and eat it.
If IR keeps a backwards-transform to the AST, (whereby I mean the 
semantically-augmented tree closest to the actual AST).


It is possible to transfer insight gained further in the 
processing to earlier constructs.

Making it possible to extend VRP.

This might negativity impact compile-times, and it (maybe) won't 
be simple to implement.

Re: missing HexString documentation

[Ralph Doncaster via Digitalmars-d]

On Wednesday, 7 February 2018 at 15:41:37 UTC, Seb wrote:
On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven 
Schveighoffer wrote:

On 2/7/18 9:59 AM, Ralph Doncaster wrote:

It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals

 From reading forum posts I managed to figure out that 
HexStrings are prefixed with an x.  i.e. x"deadbeef"




Good catch! Even the grammar says nothing about what it is, 
except it has HexString as a possible literal.


Can you file an issue? https://issues.dlang.org

-Steve


They are deprecated:

https://dlang.org/changelog/pending.html#hexstrings
https://dlang.org/deprecate.html#Hexstring%20literals

Hence, the grammar has been incompletely updated. As it's not 
an error to use them now, it should have stated that they are 
deprecated.


Anyhow, you can always go back in time:

https://docarchives.dlang.io/v2.078.0/spec/lex.html#HexString


Doesn't that go against the idea of -betterC, or will std.conv 
work with -betterC.


p.s. contrary to what the deprecation notice says, hex strings 
are very often used in crypto/hashing test cases.  Most hash 
specs have example hash strings to verify implementation code.

Re: missing HexString documentation

[Seb via Digitalmars-d]

On Wednesday, 7 February 2018 at 15:25:05 UTC, Steven 
Schveighoffer wrote:

On 2/7/18 9:59 AM, Ralph Doncaster wrote:

It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals

 From reading forum posts I managed to figure out that 
HexStrings are prefixed with an x.  i.e. x"deadbeef"




Good catch! Even the grammar says nothing about what it is, 
except it has HexString as a possible literal.


Can you file an issue? https://issues.dlang.org

-Steve


They are deprecated:

https://dlang.org/changelog/pending.html#hexstrings
https://dlang.org/deprecate.html#Hexstring%20literals

Hence, the grammar has been incompletely updated. As it's not an 
error to use them now, it should have stated that they are 
deprecated.


Anyhow, you can always go back in time:

https://docarchives.dlang.io/v2.078.0/spec/lex.html#HexString

Re: Annoyance with new integer promotion deprecations

[Luís Marques via Digitalmars-d]

On Wednesday, 7 February 2018 at 11:30:02 UTC, Dominikus Dittes 
Scherkl wrote:

Very cool! Much better than implementing new types.
Just


auto opBinary(string op, U)(NX!U rhs)
{
static if(rhs.value.sizeof > value.sizeof)
return mixin("rhs " ~ op ~  " value");


That won't do anything good for operators that are NOT 
commutative

(like -, ^^, <<, >>, %, /, ...)
Seems you don't use other things than +, *, &, | and ^, do you?


Ahah! That "fix" was only a temporary workaround for a unittest. 
In my actual code the rhs is always a T, not a NX!U, so it didn't 
matter. I forgot to remove that kludge before I copy pasted it 
here :-)

Re: missing HexString documentation

[Steven Schveighoffer via Digitalmars-d]

On 2/7/18 9:59 AM, Ralph Doncaster wrote:

It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals

 From reading forum posts I managed to figure out that HexStrings are 
prefixed with an x.  i.e. x"deadbeef"




Good catch! Even the grammar says nothing about what it is, except it 
has HexString as a possible literal.


Can you file an issue? https://issues.dlang.org

-Steve

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

[Ralph Doncaster via Digitalmars-d]

On Wednesday, 7 February 2018 at 15:10:36 UTC, Ralph Doncaster 
wrote:
On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson 
wrote:

For OpenCL I develop and maintain DCompute:
http://code.dlang.org/packages/dcompute
https://github.com/libmir/dcompute

It has a much beautified interface to OpenCL (and is mostly 
consistent with its CUDA interface). You can also write 
kernels directly in D, however this requires that LDC is built 
against my fork of LLVM: https://github.com/thewilsonator/llvm


It's still in dev but should be usable. Please let me know if 
you have issues using it.


I saw your library before, but it looked like it is ONLY for 
native D on GPUs.  I looked at it again, and don't see any 
documentation or example showing that it works with standard 
OpenCL kernels written in C.


p.s. since you seem to be a green team guy, you might not know 
that llvm optimization sucks on AMD.  I use -legacy when building 
my kernels to get the good old compiler.

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

[Ralph Doncaster via Digitalmars-d]

On Wednesday, 7 February 2018 at 08:05:46 UTC, Nicholas Wilson 
wrote:
On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster 
wrote:
I, like you, may end up jumping off the ship though.  I've 
done a bit of work with golang before, so maybe I'll take 
another look at it.  The opencl bindings aren't much better, 
but there are ready-made sha3 libs I can use instead of 
porting from C.


For crypto there is also Botan: 
http://code.dlang.org/packages/botan

https://github.com/etcimon/botan


That looks more promising.  Strange that it doesn't show up when 
searching for sha or sha3.

https://code.dlang.org/search?q=sha3


For OpenCL I develop and maintain DCompute:
http://code.dlang.org/packages/dcompute
https://github.com/libmir/dcompute

It has a much beautified interface to OpenCL (and is mostly 
consistent with its CUDA interface). You can also write kernels 
directly in D, however this requires that LDC is built against 
my fork of LLVM: https://github.com/thewilsonator/llvm


It's still in dev but should be usable. Please let me know if 
you have issues using it.


I saw your library before, but it looked like it is ONLY for 
native D on GPUs.  I looked at it again, and don't see any 
documentation or example showing that it works with standard 
OpenCL kernels written in C.

Re: Annoyance with new integer promotion deprecations

[Steven Schveighoffer via Digitalmars-d]

On 2/6/18 8:06 PM, Luís Marques wrote:

On Wednesday, 7 February 2018 at 00:24:26 UTC, H. S. Teoh wrote:
I really like your .nx idea!  It neatly sidesteps the nonsensical 
mandatory casts and on top of that documents intent (the .nx being a 
telltale sign of truncation -- much better than arbitrary implicit 
rules).  I think I'll adopt it in some form in my code, to make 
dealing with narrow ints saner.  I don't know what your .nx type does, 
but for my purposes I'll probably just have a thin wrapper around 
byte/ubyte/etc. with overloaded arithmetic operators that perform the 
requisite casts.


Yeah, it's just a thin wrapper. I implemented just enough to cover my 
use cases but just in case it's useful to you or someone else, here goes 
my implementation...


private struct NX(T)
{

...


I think this would be a good Phobos addition. std.typecons?

-Steve

missing HexString documentation

[Ralph Doncaster via Digitalmars-d]

It is mentioned in the literals section, but not documented:
https://dlang.org/spec/lex.html#string_literals

From reading forum posts I managed to figure out that HexStrings 
are prefixed with an x.  i.e. x"deadbeef"

Re: inout(shared) as a thing?

[Steven Schveighoffer via Digitalmars-d]

On 2/7/18 5:19 AM, Nicholas Wilson wrote:
I was reading 
https://github.com/rikkimax/stdc-signatures/blob/master/stdc/graphic/image.d#L54 
as part of 
https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md and it 
struck me that the duplication of `IFoo` and `ISharedFoo` might be made 
redundant `with inout(shared)` as `inout` (->`inout(const)`? so that one 
can write `inout(shared,const)`. obviously no need to deprecate plain 
inout) is to mutable/const/immutable.


I think this would work for "declarations" like 
interfaces/signatures/contraints, I'm not so sure about implementations 
as the acquisition of ownership needs to occur to take place in order to 
avoid data races.


Maybe inout(shared=(T t){...}) where (T t){...} is a lamda (or some 
other builtin) that ensures that t (or this) is owned by by the 
executing thread. could also have inout(shared=synchronized), 
inout(shared=synchronized(a)) where a is a variable in scope (e.g. 
parameter, member,...), inout(shared=atomic) or some wrapper that 
atomically loads t or this. Just throwing out ideas.


I don't think this would work on the return value of functions.

Thoughts? Worthy of a DIP?


I'm thinking it doesn't work.

Not because it wouldn't be sound from the standpoint of the type system, 
but because there is no "possibly shared" type constructor similar to 
const. If you are inside an inout(shared) function, how do you properly 
deal with the data? At the moment it's custom based on what your overall 
structure looks like. Sure, there are atomics for small shared data 
types, and at that level, you could conservatively just atomically load 
and store data. But what about shared aggregates? Those require locking 
at the right places, and there is no compiler-defined way to do it -- 
you have to write it yourself. There's just no way to do a "maybe 
shared" implementation for it.


-Steve

Re: website articles 404

[Seb via Digitalmars-d]

On Wednesday, 7 February 2018 at 14:31:33 UTC, Ralph Doncaster 
wrote:
None of the forum group descriptions seem to apply to 
discussions about the dlang.org web site, so I'm posting this 
in general.
Selecting "Articles" from the "Documentation" tab gives a 404 
error.

https://dlang.org/articles.html


Sorry, we were cleaning up some old dust and the URL is now: 
http://dlang.org/articles

I fixed the redirects right now with this PR:

https://github.com/dlang/dlang.org/pull/2187

(should be deployed in a few minutes)

Re: #dbugfix Issue 16189

[Seb via Digitalmars-d]

On Wednesday, 7 February 2018 at 13:50:06 UTC, Bastiaan Veelo 
wrote:

On Wednesday, 7 February 2018 at 11:37:19 UTC, Michael wrote:
Does it work with slightly varied examples like where a = -1, 
and is incremented etc.?


I played with it here https://run.dlang.io/is/15sr6c and every 
variation I tried worked (correctly). So the example seems to 
be pretty minimal. Maybe someone understanding assembly is able 
to see what is going on after pressing that nice [ASM] button?


You don't need to understand assembler to grasp what's going on. 
A printf does a good job too:


printf("%d\n", a); // 1908874352

It's even more fun, reduce the size of the static array to 8:

ubyte[8][1] data; // works

However, with 7 it fails again:

ubyte[7][1] data;

If you look at the assembly you will see that the compiler didn't 
even include the assert calls for even static arrays:


https://run.dlang.io/is/Qkt1nA (-O)
https://run.dlang.io/is/7UfmXJ (-O [8])
https://run.dlang.io/is/QrtNeI (normal)


Here's an annotated excerpt from the normal build:

---
dec qword ptr -010h[RBP]
xor EDX,EDX; a--
mov -8[RBP],DL
testDL,DL  ; if (b)
je  L5C
jmp short   L18; goto loop
L5C:cmp qword ptr -010h[RBP],0h
je  L78; assert(a == -1)
mov DL,0Ah
lea RSI,_TMP0@PC32[RIP]
lea RDI,_TMP0@PC32[RIP]
call  __assert@PLT32
L78:xor EAX,EAX
---


The same looks slightly different with -O.
Here with printf and a different value to be compared with a 
because it's easier to read:


---
main:
pushRBP
mov RBP,RSP
sub RSP,010h
lea RAX,-010h[RBP]
xor ECX,ECX
mov [RAX],RCX
mov 8[RAX],CL
lea RSI,-010h[RBP]
lea RDI,-010h[RBP]
movsd
movsb
		mov	RSI,01C71C71C71C71C70h  ; 2 function argument 
(value of a)
		lea	RDI,FLAT:.rodata[00h][RIP]  ; "%d" (1st function 
argument)

xor EAX,EAX ; set eax to 0
call  printf@PLT32  ; printf("%d", a)
mov EDX,0Ch
		lea	RSI,_TMP0@PC32[RIP] ; load function arguments 
(in reverse order)

lea RDI,_TMP0@PC32[RIP]
		call	  __assert@PLT32; values load, let's call 
assert

add [RAX],AL
.text.main  ends
end


So the optimizer seems to be confused and wrongly precomputes a.
Note that if you change something, a will be correctly statically 
set in the printf too:


---
mov RSI,0h; look ma - a is now -1
lea RDI,FLAT:.rodata[00h][RIP]
xor EAX,EAX   ; set eax to 0
call  printf@PLT32
---

website articles 404

[Ralph Doncaster via Digitalmars-d]

None of the forum group descriptions seem to apply to discussions 
about the dlang.org web site, so I'm posting this in general.
Selecting "Articles" from the "Documentation" tab gives a 404 
error.

https://dlang.org/articles.html

Re: zortech - symantec - digital mars

[Ali via Digitalmars-d]

On Tuesday, 6 February 2018 at 03:07:02 UTC, rikki cattermole 
wrote:

On 05/02/2018 5:07 PM, Ali wrote:

On Saturday, 3 February 2018 at 15:47:59 UTC, Ali wrote:

Some people had the impression that D started as a closed 
source project( https://news.ycombinator.com/item?id=16270937 )

I believe this proves this perception wrong


The comment is correct, dmd was indeed closed source for a good 
number of years.


I believe it was Brad (from my hazy memory) who when joined got 
it opened up (and had the bug tracker installed too).


yes, but, it seem it was closed source for pragmatic reasons, 
reusing the symantec C++ back-end assets, not because it was 
started as a closed source commercial language


like say eiffel

Re: #dbugfix Issue 16189

[Mike Parker via Digitalmars-d]

On Wednesday, 7 February 2018 at 08:51:01 UTC, Kirr wrote:

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

I'll appreciate any help with this bug.


Noted!

Re: Thread safe reference counting

[Atila Neves via Digitalmars-d]

On Wednesday, 7 February 2018 at 07:58:42 UTC, Kagamin wrote:

On Tuesday, 6 February 2018 at 10:01:28 UTC, Nathan S. wrote:
You might also want to look at Atila Neves's automem package. 
It uses atomic increment/decrement when the type being 
reference-counted is `shared`.


https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/


That RefCounted only counts on stack, it can't be put in shared 
storage.


There are some bugs with shared at the moment in dmd (I 
introduced a bug fixing a different bug and now I'm trying to 
figure out what the best way out of this mess is), so what I'm 
saying might not compile right now but should:


auto ptr = new shared RefCounted!(...);

Atila

Re: #dbugfix Issue 16189

[Bastiaan Veelo via Digitalmars-d]

On Wednesday, 7 February 2018 at 11:37:19 UTC, Michael wrote:
Does it work with slightly varied examples like where a = -1, 
and is incremented etc.?


I played with it here https://run.dlang.io/is/15sr6c and every 
variation I tried worked (correctly). So the example seems to be 
pretty minimal. Maybe someone understanding assembly is able to 
see what is going on after pressing that nice [ASM] button?

Re: #dbugfix Issue 16189

[Michael via Digitalmars-d]

On Wednesday, 7 February 2018 at 08:51:01 UTC, Kirr wrote:

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

This is a P1 critical DMD bug, silently generating wrong code. 
Reported one and a half year ago, but exists in DMD compilers 
going back to DMD 2.050 (possibly more, but this is as far back 
as I tried).


The repro is essentially C, it involves nothing but array, 
struct and loop. No templates, CTFE, no phobos, no any fancy 
features.


I can fully understand that may be this bug is hard to fix, 
that there's not enough manpower, that there are other more 
pressing issues, that no one can be expected to work on 
something they are not interested in, etc. And may I'm the only 
one affected? (it's a mystery to me). But this bug is a 
phychological obstacle to my use of D (or rather DMD, because 
LDC seems OK). May be it's just my expectation that is too high.


I'm not ready to give up arrays, structs or loops. I 
experimentally worked around this once I found it, by 
re-wording the loop. But I've no idea how to make sure this bug 
won't hit me somewhere else. I guess I can live without 
optimizer (or without DMD). In any case, I think that 
miscompiling a simplest C-like loop does not send the right 
message to a newcomer.


I'll appreciate any help with this bug.


Yeah that's... really bad. I suppose the saving grace is that 
it's only a serious issue with the use of the optimiser, which I 
don't tend to use on DMD, but this should really be prioritised. 
I guess the fact that it's not a regression might make fixing it 
harder, but it doesn't really matter.


Does it work with slightly varied examples like where a = -1, and 
is incremented etc.?

Re: Annoyance with new integer promotion deprecations

[Dominikus Dittes Scherkl via Digitalmars-d]

On Wednesday, 7 February 2018 at 01:06:42 UTC, Luís Marques wrote:

On Wednesday, 7 February 2018 at 00:24:26 UTC, H. S. Teoh wrote:
I really like your .nx idea!  It neatly sidesteps the 
nonsensical mandatory casts and on top of that documents 
intent (the .nx being a telltale sign of truncation -- much 
better than arbitrary implicit rules).

[...]
Yeah, it's just a thin wrapper. I implemented just enough to 
cover my use cases but just in case it's useful to you or 
someone else, here goes my implementation...


Very cool! Much better than implementing new types.
Just


auto opBinary(string op, U)(NX!U rhs)
{
static if(rhs.value.sizeof > value.sizeof)
return mixin("rhs " ~ op ~  " value");


That won't do anything good for operators that are NOT commutative
(like -, ^^, <<, >>, %, /, ...)
Seems you don't use other things than +, *, &, | and ^, do you?

Re: Bye bye, fast compilation times

[Nicholas Wilson via Digitalmars-d]

On Wednesday, 7 February 2018 at 02:05:46 UTC, Timothee Cour 
wrote:
how about using same syntax (and reusing logic) as newly 
introduced:

` -i=+foo.bar,+baz-baz.bad`

`dmd -unittest=+foo.bar,+baz,-baz.bad rest_of_arguments`

which would only enable unittests as specified? It's flexible 
and intuitive


I like it! That only leaves a question of defaults.

inout(shared) as a thing?

[Nicholas Wilson via Digitalmars-d]

I was reading 
https://github.com/rikkimax/stdc-signatures/blob/master/stdc/graphic/image.d#L54 as part of https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md and it struck me that the duplication of `IFoo` and `ISharedFoo` might be made redundant `with inout(shared)` as `inout` (->`inout(const)`? so that one can write `inout(shared,const)`. obviously no need to deprecate plain inout) is to mutable/const/immutable.


I think this would work for "declarations" like 
interfaces/signatures/contraints, I'm not so sure about 
implementations as the acquisition of ownership needs to occur to 
take place in order to avoid data races.


Maybe inout(shared=(T t){...}) where (T t){...} is a lamda (or 
some other builtin) that ensures that t (or this) is owned by by 
the executing thread. could also have inout(shared=synchronized), 
inout(shared=synchronized(a)) where a is a variable in scope 
(e.g. parameter, member,...), inout(shared=atomic) or some 
wrapper that atomically loads t or this. Just throwing out ideas.


I don't think this would work on the return value of functions.

Thoughts? Worthy of a DIP?

Nic

Re: Bye bye, fast compilation times

[Stefan Koch via Digitalmars-d]

On Tuesday, 6 February 2018 at 18:56:44 UTC, H. S. Teoh wrote:


We seriously need to get newCTFE finished and merged.  Stefan 
is very busy with other stuff ATM; I wonder if a few of us can 
continue his work and get newCTFE into a mergeable state.  
Given how much D's "compile-time" features are advertised, and 
D's new (ick) slogan of being fast or whatever, it's high time 
we actually delivered on our promises by actually making CTFE 
more usable.



There are some good news for you.
I've recently allocated a few more resources to newCTFE again.

I have to stress that it is not enough to get newCTFE feature 
complete.

It is also vital make performance-related pass through the code.
newCTFE currently still at a Proof-Of-Concept quality level.

That said, newCTFE is designed with performance and JIT in mind.
It can achieve a 10-30x speed-up when implemented properly.

One thing that I really need in druntime is a cross-platform way 
to allocate executable memory-pages, this can be done by someone 
else.


Another Thing that can be done is reviewing the code and alerting 
me to potential problems. i.e. Missing or indecipherable comments 
as well as spelling mistakes.
(with the correction please (just telling me something is wrong, 
will not help since I obliviously don't know how to spell it))

Re: Bye bye, fast compilation times

[Stefan Koch via Digitalmars-d]

On Tuesday, 6 February 2018 at 18:56:44 UTC, H. S. Teoh wrote:


We seriously need to get newCTFE finished and merged.  Stefan 
is very busy with other stuff ATM; I wonder if a few of us can 
continue his work and get newCTFE into a mergeable state.  
Given how much D's "compile-time" features are advertised, and 
D's new (ick) slogan of being fast or whatever, it's high time 
we actually delivered on our promises by actually making CTFE 
more usable.



There are some good news for you.
I've recently allocated a few more resources to newCTFE again.

I have to stress that it is not enough to get newCTFE feature 
complete.

It is also vital make performance-related pass through the code.
newCTFE currently still at a Proof-Of-Concept quality level.

That said, newCTFE is designed with performance and JIT in mind.
It can achieve a 10-30x speed-up when implemented properly.

One thing that I really need in druntime is a cross-platform way 
to allocate executable memory-pages, this can be done by someone 
else.


Another Thing that can be done is reviewing the code and alerting 
me to potential problems. i.e. Missing or indecipherable comments 
as well as spelling mistakes.
(with the correction please (just telling me something is wrong, 
will not help since I obliviously don't know how to spell it))

#dbugfix Issue 16189

[Kirr via Digitalmars-d]

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

This is a P1 critical DMD bug, silently generating wrong code. 
Reported one and a half year ago, but exists in DMD compilers 
going back to DMD 2.050 (possibly more, but this is as far back 
as I tried).


The repro is essentially C, it involves nothing but array, struct 
and loop. No templates, CTFE, no phobos, no any fancy features.


I can fully understand that may be this bug is hard to fix, that 
there's not enough manpower, that there are other more pressing 
issues, that no one can be expected to work on something they are 
not interested in, etc. And may I'm the only one affected? (it's 
a mystery to me). But this bug is a phychological obstacle to my 
use of D (or rather DMD, because LDC seems OK). May be it's just 
my expectation that is too high.


I'm not ready to give up arrays, structs or loops. I 
experimentally worked around this once I found it, by re-wording 
the loop. But I've no idea how to make sure this bug won't hit me 
somewhere else. I guess I can live without optimizer (or without 
DMD). In any case, I think that miscompiling a simplest C-like 
loop does not send the right message to a newcomer.


I'll appreciate any help with this bug.

Re: Bye bye, fast compilation times

[Seb via Digitalmars-d]

On Wednesday, 7 February 2018 at 01:20:04 UTC, H. S. Teoh wrote:
On Mon, Feb 05, 2018 at 01:27:57PM -0800, H. S. Teoh via 
Digitalmars-d wrote:

[...]

[...]

I don't want this thread to turn into ragging on std.regex, so 
here's the next instalment of this saga.


[...]


Already done. There's `version(StdUnittest)` since a few days:

https://github.com/dlang/phobos/pull/5927
https://github.com/dlang/phobos/pull/6107

Re: My choice to pick Go over D ( and Rust ), mostly non-technical

[Nicholas Wilson via Digitalmars-d]

On Tuesday, 6 February 2018 at 20:25:22 UTC, Ralph Doncaster 
wrote:
Thanks for the detailed post.  I'm an old C/C++ guy (got 
started with C++ back in the cfront days), and have been 
kicking the tires on D recently.  The poor state of libraries 
is something that may push me away from D as well.  In my case, 
need opencl and crypto libs.  The opencl package in dub is a 
crude wrapper around the original C API.  I couldn't find any 
sha lib, so I've started porting a reference sha3 
implementation from C.


I, like you, may end up jumping off the ship though.  I've done 
a bit of work with golang before, so maybe I'll take another 
look at it.  The opencl bindings aren't much better, but there 
are ready-made sha3 libs I can use instead of porting from C.


For crypto there is also Botan: 
http://code.dlang.org/packages/botan

https://github.com/etcimon/botan

For OpenCL I develop and maintain DCompute:
http://code.dlang.org/packages/dcompute
https://github.com/libmir/dcompute

It has a much beautified interface to OpenCL (and is mostly 
consistent with its CUDA interface). You can also write kernels 
directly in D, however this requires that LDC is built against my 
fork of LLVM: https://github.com/thewilsonator/llvm


It's still in dev but should be usable. Please let me know if you 
have issues using it.

Re: Thread safe reference counting

[Kagamin via Digitalmars-d]

On Tuesday, 6 February 2018 at 10:01:28 UTC, Nathan S. wrote:
You might also want to look at Atila Neves's automem package. 
It uses atomic increment/decrement when the type being 
reference-counted is `shared`.


https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/


That RefCounted only counts on stack, it can't be put in shared 
storage.