Re: DConf 2017 Berlin - bicycles

[Adrian Matoga via Digitalmars-d]

On Wednesday, 19 April 2017 at 20:13:52 UTC, Walter Bright wrote:

On 4/19/2017 11:22 AM, Adrian Matoga wrote:
I'm arriving at Berlin Ostbahnhof on Wednesday evening and 
will be heading to
Britz Hotel, but last year I learnt that the best way to get 
around the city is
on a bicycle. Can you recommend a place (preferably near the 
station) where I
could rent a not-so-small bike for 4 days for a reasonable 
price?

Thanks!



I personally found that the transit system in Berlin was 
excellent. You can buy a 3 day pass from the ticket machines, 
it's under "Tourist Fahrkarte" if I remember correctly.


It is! In many discussions about public transport, Berlin is 
mentioned as an example that should be followed, and I must agree 
with that after a few rides I had.

Re: DConf 2017 Berlin - bicycles

[Adrian Matoga via Digitalmars-d]

On Wednesday, 19 April 2017 at 19:03:40 UTC, Fool wrote:

No personal experience, but

 http://www.yaambike.de/

sounds like an option.


Looks good, thanks.

Re: DMD VS2017 Support

[Mike Parker via Digitalmars-d]

On Thursday, 20 April 2017 at 04:58:55 UTC, Mike Parker wrote:


You can install the MS Build Tools 2015. DMD will work with 
that. You have two options to do so -- download the installer 
at the link below or run the VS 2017 installer and select it in 
the "Individual Components" tab. I'm on my MacBook now and 
can't recall exactly, but it may be listed as some thing like 
"Platform toolset v140". With both options, you have the added 
benefit that you can choose to use either the 2015 or 2017 
build tools when compiling C & C++ projects in VS 2017  (and, I 
assume, Visual D).


https://www.microsoft.com/en-us/download/details.aspx?id=48159


I should add that Mike's suggestion to edit sc.ini should do the 
trick, but I find it convenient to have both toolsets installed.

Re: Compare boost::hana to D

[Adrian Matoga via Digitalmars-d]

On Wednesday, 19 April 2017 at 19:22:11 UTC, Ali Çehreli wrote:


Thank you. Has this been on Reddit yet?


I haven't posted it there, I don't have an account.


Two typos:

1) A missing underscore made me believe C++ gained a new 
keyword (make). :)


auto events = make event_system("foo"_s, "bar"_s, "baz"_s});


Uhh, that underscore isn't the only problem in this line. ;)
Fixed both, thank you!

Re: DMD VS2017 Support

[Mike Parker via Digitalmars-d]

On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:
I cannot even fix it myself because DMD is looking for 
"bin\link.exe". But with VS2017 the path would actually be 
something like "\bin\HostX64\x64".


You can install the MS Build Tools 2015. DMD will work with that. 
You have two options to do so -- download the installer at the 
link below or run the VS 2017 installer and select it in the 
"Individual Components" tab. I'm on my MacBook now and can't 
recall exactly, but it may be listed as some thing like "Platform 
toolset v140". With both options, you have the added benefit that 
you can choose to use either the 2015 or 2017 build tools when 
compiling C & C++ projects in VS 2017  (and, I assume, Visual D).


https://www.microsoft.com/en-us/download/details.aspx?id=48159

Re: [OT] PC sales down

[rikki cattermole via Digitalmars-d]

On 20/04/2017 5:09 AM, Joakim wrote:

I don't know why you get so worked up about this.  Yes, the new entrant
won't have features the old computers had.  I was using virtual desktops
on UNIX workstations regularly decades ago, but Microsoft didn't add
that to the OS till Windows 10 a couple years ago.  So what?  Most
people got by just fine.


The API to support multi-desktops has been in Windows for a very long 
time (Windows 2k[0]), it just wasn't exposed in stock Windows.

But if you knew where to look, they certainly did offer it[1]!

[0] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682124(v=vs.85).aspx

[1] https://technet.microsoft.com/en-us/sysinternals/cc817881

Re: DPaste is down

[ANtlord via Digitalmars-d]

There is screenshot of http://dpaste.dzfl.pl 
http://screencloud.net/v/rCE6i

[OT] PC sales down

[Joakim via Digitalmars-d]

On Wednesday, 19 April 2017 at 17:47:50 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 04/13/2017 06:16 PM, Joakim wrote:
 From a certain point of view, you could say PC sales are only 
down 25%
from their peak, that's not dead yet.  But the chart I linked 
shows
their share of personal computing devices, including mobile, 
has dropped
from 78% to a little less than 14% over the last decade.  I'd 
call that

dying.


In other words: It can only be considered "dying" if you 
conveniently ignore certain facts, and instead look only at a 
stat that doesn't show the full picture.


On the contrary, my point is "the full picture" shows sales as a 
share of computing devices dying, whereas only looking at the PC 
market alone is misleading. The mobile tidal wave has taken away 
sales that would have been PCs instead, likely more than 25% if 
we extrapolate out the former PC sales growth rate, rather than 
just compare to the peak.


Just as the underpowered PC once disrupted the market for 
minicomputers and UNIX workstations, mobile is doing the same to 
the PC.  Whereas people used to check their email, browse the 
web, and ogle facebook on their PCs before, they just use a 
mobile device for those former PC-only activities now.


And now that the mobile market is so much bigger than PCs, 
they're finally going after what remains of the PC market: those 
who want to get work done on a bigger screen which supports 
viewing multiple windows at once.  This isn't going to happen 
overnight, as it will take years to roll out Android 7.0 Nougat 
with built-in multi-window, get all the needed productivity 
software ported over (though the S8 announcement notes that 
versions of Office and Photoshop are already done), and keep 
iterating and improving on the mobile multi-window experience.


But just as the PC once disrupted the computing market, mobile 
has already disrupted the PC market.  Mobile taking most of the 
rest of the PC market's sales with these multiwindow moves is 
inevitable.  Sure, there will always be a few who run powerful 
desktops, just as I'm sure there's someone out there running a 
UNIX workstation, but you never run into those people anymore 
because they're such a small niche.


I don't know why you get so worked up about this.  Yes, the new 
entrant won't have features the old computers had.  I was using 
virtual desktops on UNIX workstations regularly decades ago, but 
Microsoft didn't add that to the OS till Windows 10 a couple 
years ago.  So what?  Most people got by just fine.

DPaste is down

[ANtlord via Digitalmars-d]

Hello! I don't know where I should to talk about this. 
http://dpaste.dzfl.pl is down for three days. Any of sample from 
documentation can't be ran. Is this service  provided dlang 
faundation? If not sorry for this attention.


http://screencloud.net/v/buvXp

GC: Understanding potential sources of false pointers

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

According to :

"Registers, the stack, and any other memory locations added through the 
GC.addRange function are always scanned conservatively."


1. Can that be safely assumed to be a canonical list of all possible 
sources of false pointers?


2. What about memory allocated through language constructs such as 
"new", append ("~"/"~="), closures, or any others I may be forgetting? 
Is this memory always/never/sometimes set to NO_SCAN? (I assume not 
"always", as that would be silly.) If "sometimes", what are the conditions?


A couple specific examples:

3. Are there any situations where a (for example) int[] or long[] that 
is stored on the GC heap could lead to false pointers?


4. Same question as #3, but if it's an array of structs, and the struct 
type contains no members that are statically-typed as pointers.

Windows X64 Calling conventions

[Tofu Ninja via Digitalmars-d-learn]

I am trying to learn the calling conventions in DMD, I am sure I 
will have more than one question about them so as I come across 
them I will ask them in this thread. I am mainly reading the MSDN 
docs on the x64 calls and looking at disassemblies to confirm 
what I learn.



While I was looking at a call of the form void foo(float), I get 
the following disassembly:


movss   xmm0,dword ptr [_TMP0]
sub rsp,20h
movdrcx,xmm0
callvoid main.foo(float)
add rsp,20h


My question is, why is it passed twice, both in xmm0 and rcx? The 
MSDN docs say floating point are passed in xmm registers, why is 
it also copied in into rcx? Is it necessary for anything? If it 
was skipped would anything break?



Thanks

Re: Exact arithmetic with quadratic irrationals

[H. S. Teoh via Digitalmars-d]

On Thu, Apr 20, 2017 at 02:01:20AM +0200, Timon Gehr via Digitalmars-d wrote:
[...]
> Yes, there is in fact a beautifully simple way to do better. :)
> 
> Assume we want to compute some power of x. With a single
> multiplication, we obtain x². Multiplying x² by itself, we obtain x⁴.
> Repeating this a few times, we get:
> 
> x, x², x⁴, x⁸, x¹⁶, x³², etc.
> 
> In general, we only need n operations to compute x^(2ⁿ).
> 
> To compute xʸ, it basically suffices to express y as a sum of powers
> of two (i.e., we write it in binary).
> 
> For example, 22 = 16 + 4 + 2, and x²² = x¹⁶·x⁴·x².
> 
> My last post includes an implementation of this algorithm. ;)

Ahh, so *that's* what it's all about. I figured that's what I was
missing. :-D  Thanks, I'll include this in QRat soon.


> In particular, this leads to multiple ways to compute the n-th
> Fibonacci number using O(log n) basic operations. (One way is to use
> your QRat type, but we can also use the matrix (1 1; 1 0).)

True, though I'm still jealous that with transcendental functions like
with floating-point, one could ostensibly compute that in O(1).


> > Another module I'm thinking about is an extension of QRat that
> > allows you to mix different radicals in the same expression. For
> > example, (√3+√5)/√7 and so forth. ...
> > 
> 
> That would certainly be nice. Note that QRat is basically already
> there for different quadratic radicals, the only reason it does not
> work already is that we cannot use a QRat as the base field instead of
> ℚ (because ℚ is hardcoded).

Oh?  I didn't try it myself, but if QRat itself passes isArithmeticType,
I'd venture to say QRat!(n, QRat!m) ought to work... There are some
hidden assumptions about properties of the rationals, though, but I
surmise none that couldn't be replaced by prerequisites about the
relative linear dependence of the mixed radicals over Q.

What I had in mind, though, was a more direct approach that perhaps may
reduce the total number of operations, since if the code is aware that
multiple radicals are involved, it could potentially factor out some
commonalities to minimize recomputations.

Also, the current implementation of QRat fixes the radical at
compile-time; I wanted to see if I could dynamically handle arbitrary
radicals at runtime. It would have to be restricted by only allowing
operations between two QRats of the same extension, of course, but if
the code could handle arbitrary extensions dynamically, then that
restriction could be lifted and we could (potentially, anyway) support
arbitrary combinations of expressions involving radicals. That would be
far more useful than QRat, for some of the things I'd like to use it
for.


> This is the relevant concept from algebra:
> https://en.wikipedia.org/wiki/Splitting_field
> 
> 
> All your conjectures are true, except the last one. (Galois theory is
> not an obstacle, because here, we only need to consider splitting
> fields of particularly simple polynomials that are solvable in
> radicals.)

That's nice to know. But I suppose Galois theory *would* become an
obstacle if I wanted to implement, for example, Q(x) for an arbitrary
algebraic x?


> You can even mix radicals of different degrees.

Yes, I've thought about that before. So it should be possible to
represent Q(r1,r2,...rn) using deg(r1)*deg(r2)*...*deg(rn)+1
coefficients?


> To get the formula for multiplicative inverses, one possible algorithm is:
> https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm#Polynomial_extended_Euclidean_algorithm
[...]

Thanks, will look into this at some point. :-)


T

-- 
Some ideas are so stupid that only intellectuals could believe them. -- George 
Orwell

[Issue 17329] File.remove() has problems with long filenames (>128 bytes)

[via Digitalmars-d-bugs]

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

--- Comment #4 from Rainer Koschnick  ---
I tried it with the path as you can see up there!

--

Re: The DConf Experience

[Andrei Alexandrescu via Digitalmars-d-announce]

On 4/19/17 11:26 AM, Joakim wrote:


Nice post.  What's the occupancy like for the event so far? Seemed 
pretty full last year, wondering how many more can sign up this year.


There are still available seats. -- Andrei

Re: Exact arithmetic with quadratic irrationals

[Timon Gehr via Digitalmars-d]

On 20.04.2017 02:01, Timon Gehr wrote:


My last post includes an implementation of this algorithm. ;)


But in that implementation I used the parameter 'a' instead of the 
variable 'x' as a result of being tired, which makes it slightly more 
confusing than necessary even though it is correct. More readable version:


auto pow(T,S)(T a,S n){
T r=T(ℕ(1),ℕ(0));
for(auto x=a;n;n>>=1,x*=x)
if(n&1) r*=x;
return r;
}

Re: Exact arithmetic with quadratic irrationals

[Timon Gehr via Digitalmars-d]

On 20.04.2017 02:01, Timon Gehr wrote:


To get the formula for multiplicative inverses, one possible algorithm is:
https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm#Polynomial_extended_Euclidean_algorithm




Better reference: 
https://en.wikipedia.org/wiki/Polynomial_greatest_common_divisor#Arithmetic_of_algebraic_extensions

[Issue 17329] File.remove() has problems with long filenames (>128 bytes)

[via Digitalmars-d-bugs]

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

--- Comment #3 from b2.t...@gmx.com ---
I meant fully qualified filename !

\\?\D:\_Development_\D\cbc\...

--

Re: DMD VS2017 Support

[Meta via Digitalmars-d]

On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:
I cannot even fix it myself because DMD is looking for 
"bin\link.exe". But with VS2017 the path would actually be 
something like "\bin\HostX64\x64".


Please ignore Mike's answer. Visual D is maintained by Rainers 
Schuetze and is hosted here[1] on github. From the readme:


For more information on installation, a quick tour of Visual D 
with some screen shots and feedback, please visit the project 
home for Visual D at 
http://rainers.github.io/visuald/visuald/StartPage.html.


There's a forum dedicated to IDE discussions 
(http://forum.dlang.org/group/digitalmars.D.ide), where you can 
leave your comments and suggestions. Bug reports can be filed to 
the D bugzilla database for Component VisualD.


Have fun, Rainer Schuetze

1. https://github.com/dlang/visuald

Re: Exact arithmetic with quadratic irrationals

[Timon Gehr via Digitalmars-d]

On 19.04.2017 23:39, H. S. Teoh via Digitalmars-d wrote:

On Wed, Apr 19, 2017 at 10:47:04PM +0200, Timon Gehr via Digitalmars-d wrote:

On 19.04.2017 21:32, H. S. Teoh via Digitalmars-d wrote:

I alluded to this in D.learn some time ago, and finally decided to
take the dip and actually write the code. So here it is: exact
arithmetic with numbers of the form (a+b√r)/c where a, b, c are
integers, c!=0, and r is a (fixed) square-free integer.

Code:   https://github.com/quickfur/qrat

...


Nice. :)

Some suggestions:

- You might want to support ^^ (it is useful for examples like the one
below).


I would, except that I doubt it would perform any better than an actual
recursive or iterative algorithm for computing Fibonacci sequences,
because I don't know of any simple way to exponentiate a quadratic
rational using only integer arithmetic other than repeated
multiplication.  (For all I know, it may perform even worse, because
multiplying n quadratic rationals involves a lot more than just summing
n+1 integers as in an iterative implementation of Fibonacci.)

Hmm, come to think of it, I *could* expand the numerator using the
binomial theorem, treating (a+b√r) as a binomial (a+bx) where x=√r, and
folding even powers into the integral part (since x^2 = r, so x^(2k) =
r^k). The denominator could be exponentiated using plain ole integer
exponentiation.  Then it's just a matter of summing coefficients.

But it still seems to be about the same amount of work as (or more than)
summing n+1 integers in an iterative implementation of Fibonacci.  Am I
missing something?
...


Yes, there is in fact a beautifully simple way to do better. :)

Assume we want to compute some power of x. With a single multiplication, 
we obtain x². Multiplying x² by itself, we obtain x⁴. Repeating this a 
few times, we get:


x, x², x⁴, x⁸, x¹⁶, x³², etc.

In general, we only need n operations to compute x^(2ⁿ).

To compute xʸ, it basically suffices to express y as a sum of powers of 
two (i.e., we write it in binary).


For example, 22 = 16 + 4 + 2, and x²² = x¹⁶·x⁴·x².

My last post includes an implementation of this algorithm. ;)

In particular, this leads to multiple ways to compute the n-th Fibonacci 
number using O(log n) basic operations. (One way is to use your QRat 
type, but we can also use the matrix (1 1; 1 0).)



...

Another module I'm thinking about is an extension of QRat that allows
you to mix different radicals in the same expression. For example,
(√3+√5)/√7 and so forth. ...



That would certainly be nice. Note that QRat is basically already there 
for different quadratic radicals, the only reason it does not work 
already is that we cannot use a QRat as the base field instead of ℚ 
(because ℚ is hardcoded).



This is the relevant concept from algebra:
https://en.wikipedia.org/wiki/Splitting_field


All your conjectures are true, except the last one. (Galois theory is 
not an obstacle, because here, we only need to consider splitting fields 
of particularly simple polynomials that are solvable in radicals.) You 
can even mix radicals of different degrees.



To get the formula for multiplicative inverses, one possible algorithm is:
https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm#Polynomial_extended_Euclidean_algorithm

[Issue 17334] New: Template constraints do short circuit semantic analysis for && and ||, but not for ?:

[via Digitalmars-d-bugs]

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

  Issue ID: 17334
   Summary: Template constraints do short circuit semantic
analysis for && and ||, but not for ?:
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

It should do it for ?: too.

Spelunking the code, 'constraint' is the field of interest:

  https://github.com/dlang/dmd/blob/master/src/ddmd/dtemplate.d#L497

and it gets semantically analyzed here:

  https://github.com/dlang/dmd/blob/master/src/ddmd/dtemplate.d#L892

But before that it sets SCOPEcondition here:

  https://github.com/dlang/dmd/blob/master/src/ddmd/dtemplate.d#L887

and looking in expression.d for SCOPEcondition:

  https://github.com/dlang/dmd/blob/master/src/ddmd/expression.d#L15212
  https://github.com/dlang/dmd/blob/master/src/ddmd/expression.d#L15212

and there's the short circuit conditional semantic analysis of constraints.
But it's not there for ?:

--

Re: Exact arithmetic with quadratic irrationals

[H. S. Teoh via Digitalmars-d]

On Wed, Apr 19, 2017 at 10:47:04PM +0200, Timon Gehr via Digitalmars-d wrote:
> On 19.04.2017 21:32, H. S. Teoh via Digitalmars-d wrote:
> > I alluded to this in D.learn some time ago, and finally decided to
> > take the dip and actually write the code. So here it is: exact
> > arithmetic with numbers of the form (a+b√r)/c where a, b, c are
> > integers, c!=0, and r is a (fixed) square-free integer.
> > 
> > Code:   https://github.com/quickfur/qrat
> > 
> > ...
> 
> Nice. :)
> 
> Some suggestions:
> 
> - You might want to support ^^ (it is useful for examples like the one
> below).

I would, except that I doubt it would perform any better than an actual
recursive or iterative algorithm for computing Fibonacci sequences,
because I don't know of any simple way to exponentiate a quadratic
rational using only integer arithmetic other than repeated
multiplication.  (For all I know, it may perform even worse, because
multiplying n quadratic rationals involves a lot more than just summing
n+1 integers as in an iterative implementation of Fibonacci.)

Hmm, come to think of it, I *could* expand the numerator using the
binomial theorem, treating (a+b√r) as a binomial (a+bx) where x=√r, and
folding even powers into the integral part (since x^2 = r, so x^(2k) =
r^k). The denominator could be exponentiated using plain ole integer
exponentiation.  Then it's just a matter of summing coefficients.

But it still seems to be about the same amount of work as (or more than)
summing n+1 integers in an iterative implementation of Fibonacci.  Am I
missing something?


> - constructor parameter _b should have a default value of 0.

Good point, done.


> - formatting should special case b==-1 like it special cases b==1.

Done, good catch!


>   (also: as you are using Unicode anyway, you could also use · instead
>   of *.  Another cute thing to do is to add a vinculum.)

Well, I would, but it gets a bit too fancy for my tastes and may not
render well on all displays. But I'll put it on my list of things to
consider.

Another module I'm thinking about is an extension of QRat that allows
you to mix different radicals in the same expression. For example,
(√3+√5)/√7 and so forth.  I have discovered algorithms that, given n
distinct radicals, allow a closed-form expression with 2^n coefficients
(+1 denominator), closed under field operations.  The only trouble in
this case is that reciprocating such things will be very slow, as will
comparisons, and both have a high chance of overflow (so BigInt is
probably a necessity).  And 2^n+1 coefficients for n radicals quickly
gets expensive space-wise as n increases.

Yesterday I also discovered an algorithm for expressing the reciprocal
of numbers of the form:

(a + b∛r + c∛r^2)/d

in the same form. I.e., for rewriting:

d/(a + b∛r + c∛r^2)

in the first form.  Which means it's possible to implement a QRat-like
representation for cubic rationals.  (The actual computation is rather
expensive, as it involves quite a lot of multiplications, squaring, and
cubing. But it's *possible*.)  I'm still trying to verify the
correctness of the formula I obtained, since while checking a concrete
example last night I discovered a possible error.

If this works out, I might consider 4th roots as well -- though I'm
expecting that might be near the limit of the usefulness of these
representations, since the complexity becomes so great that symbolic
manipulation like in Mathematica may turn out to be more feasible after
all.  But it may be of some theoretical interest whether such
representations are possible, even if they are ultimately impractical. A
particularly interesting question is whether such representations exist
for *all* algebraic numbers (of bounded degree).

Currently I have a conjecture that given a rational extension of n
radicals of degree k, field closure can be achieved with a
representation of k^n+1 coefficients. But it's still too early to say
whether algorithms exist for inverting radicals of degree k for large k
-- I have a creeping suspicion that perhaps somewhere around k=5 or k=6
the unsolvability of the general quintic may raise its ugly head and
prevent further progress.


T

-- 
INTEL = Only half of "intelligence".

Re: Forwarding calls to objects of another type

[Johan Fjeldtvedt via Digitalmars-d-learn]

On Tuesday, 11 April 2017 at 02:01:19 UTC, Nicholas Wilson wrote:

On Monday, 10 April 2017 at 21:27:34 UTC, Basile B. wrote:
2) This is about the reduce templates. As I've commented, I 
can't use a template lambda with reduce, but I can use a 
lambda taking ints as arguments. Why is this? The error 
message I get when using the template lambda is:


"template instance reduce!((a, b) => a + b) cannot use local 
'__lambda1' as parameter to non-global template reduce(alias 
fun)()"


No idea for this.


The use of the global identity template will fix this:

see 
https://blog.thecybershadow.net/2015/04/28/the-amazing-template-that-does-nothing/


Thanks, that did work. I think I understand the point about UFCS 
lookup rules, but it still seems strange (it was at least 
surprising) that I couldn't use the template (a, b) => a + b in 
place of (int a, int b) => a + b.

Re: DMD VS2017 Support

[Mike B Johnson via Digitalmars-d]

On Wednesday, 19 April 2017 at 20:47:51 UTC, Jolly James wrote:
I cannot even fix it myself because DMD is looking for 
"bin\link.exe". But with VS2017 the path would actually be 
something like "\bin\HostX64\x64".


Edit your sc.ini in the dmd\windows\bin dir or use junctions to 
map directories.


DMD's config system is ancient and they refuse to update it 
because once you set it up and don't change your system you don't 
have to do much else. It's sort of like a rite of passage, I 
guess to weed out the losers.

Re: Forwarding calls to objects of another type

[Johan Fjeldtvedt via Digitalmars-d-learn]

On Monday, 10 April 2017 at 21:27:34 UTC, Basile B. wrote:
On Monday, 10 April 2017 at 21:04:10 UTC, Johan Fjeldtvedt 
wrote:

[...]


One way:

[...]


Thanks for the reply. The traits way of doing it seems to be what 
I want. :)



[...]


[...]

Re: DMD VS2017 Support

[Jolly James via Digitalmars-d]

I cannot even fix it myself because DMD is looking for 
"bin\link.exe". But with VS2017 the path would actually be 
something like "\bin\HostX64\x64".

Re: Exact arithmetic with quadratic irrationals

[Timon Gehr via Digitalmars-d]

On 19.04.2017 21:32, H. S. Teoh via Digitalmars-d wrote:

I alluded to this in D.learn some time ago, and finally decided to take
the dip and actually write the code. So here it is: exact arithmetic
with numbers of the form (a+b√r)/c where a, b, c are integers, c!=0, and
r is a (fixed) square-free integer.

Code:   https://github.com/quickfur/qrat

...


Nice. :)

Some suggestions:

- You might want to support ^^ (it is useful for examples like the one 
below).


- constructor parameter _b should have a default value of 0.

- formatting should special case b==-1 like it special cases b==1.
  (also: as you are using Unicode anyway, you could also use · instead 
of *. Another cute thing to do is to add a vinculum.)



Example application: Computing large Fibonacci numbers efficiently:

import qrat;
import std.bigint;
alias ℕ=BigInt;
enum φ=(1+surd!(5,ℕ))/2,ψ=(1-surd!(5,ℕ))/2;

auto pow(T,S)(T a,S n){
T r=T(ℕ(1),ℕ(0));
for(auto x=a;n;n>>=1,a*=a)
if(n&1) r*=a;
return r;
}

auto fib(long n){
return (pow(φ,n)-pow(ψ,n))/surd!(5,ℕ);
}
void main(){
import std.stdio;
foreach(i;0..40) writeln(fib(i));
writeln(fib(10));
}

Re: The lost Group

[Vladimir Panteleev via Digitalmars-d]

On Wednesday, 19 April 2017 at 20:07:48 UTC, Jolly James wrote:
https://forum.dlang.org/group/D does not appear in the forum's 
index or sidebar.


There are groups on the DigitalMars news server that are obsolete 
and no longer used, or not related to D. They are accessible only 
by their URL.


There is a list here:

https://github.com/CyberShadow/DFeed/blob/b726602d3e04dc66fffea9959f5dd79300d6b2ff/config/gengroups.d#L81-L111

Re: Interpolated strings

[Walter Bright via Digitalmars-d]

I forgot to mention - the pros and cons of whether the string interpolation is 
compile time or run time is a critical decision.

Re: The lost Group

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 19 April 2017 at 20:07:48 UTC, Jolly James wrote:
https://forum.dlang.org/group/D does not appear in the forum's 
index or sidebar.


It is obsolete and should not be used for any new stuff anymore. 
That content now goes in "General" instead.

Re: Exact arithmetic with quadratic irrationals

[H. S. Teoh via Digitalmars-d]

On Wed, Apr 19, 2017 at 07:54:02PM +, Stanislav Blinov via Digitalmars-d 
wrote:
> Awesome! Congrats and thanks for sharing.
> 
> On Wednesday, 19 April 2017 at 19:32:14 UTC, H. S. Teoh wrote:
> 
> > Haha, it seems that the only roadblocks were related to the
> > implementation quality of std.numeric.gcd... nothing that a few
> > relatively-simple PRs couldn't fix.  So overall, D is still awesome.
> 
> There's another one, which is more about dmd: dmd does not inline gcd,
> which, when arguments are const, turns gcd into a double function call
> :D

If I weren't such a sucker for the bleeDing edge with dmd (I actually
compile even my serious projects with git HEAD dmd, except when
performance matters), I'd be standardizing on ldc or gdc, which have far
superior optimizers.

I consistently find that my CPU-intensive projects perform at least
20-30% worse on dmd than gdc (and I presume ldc), sometimes even as bad
as 40-50%, due to dmd's inliner giving up far too easily. I don't know
if this has been fixed yet, but the last time I checked, if you wrote
this:

int func(int x, int y) {
if (x<0)
return y;
return x;
}

instead of:

int func(int x, int y) {
if (x<0)
return y;
else
return x;
}

then the dmd inliner would not inline the function.

Because of sensitivities like this, the inliner gives up far too early
in the process, thus the optimizer misses out on further optimization
opportunities that would have opened up, had the function been inlined.

The last time I checked, I also found that dmd was rather weak at loop
optimizations (and loops are very important in performance as we all
know) compared to gdc. Again, the same domino effect (or rather, the
missing thereof) applies: by failing to, for example, hoist a constant
expression out of the loop, further optimization opportunities are
missed, whereas gdc, after hoisting the expression out, would discover
that the loop can be reduced further, perhaps via a strength reduction,
and then unrolled, and then inlined inside the caller, then vectorized,
etc.. This chain of optimizations were missed because of one missed
optimization early in the process. Hence the suboptimal resulting code.


T

-- 
If blunt statements had a point, they wouldn't be blunt...

Re: DConf 2017 Berlin - bicycles

[Walter Bright via Digitalmars-d]

On 4/19/2017 11:22 AM, Adrian Matoga wrote:

I'm arriving at Berlin Ostbahnhof on Wednesday evening and will be heading to
Britz Hotel, but last year I learnt that the best way to get around the city is
on a bicycle. Can you recommend a place (preferably near the station) where I
could rent a not-so-small bike for 4 days for a reasonable price?
Thanks!



I personally found that the transit system in Berlin was excellent. You can buy 
a 3 day pass from the ticket machines, it's under "Tourist Fahrkarte" if I 
remember correctly.

Re: Interpolated strings

[Walter Bright via Digitalmars-d]

On 4/19/2017 5:04 AM, Jonas Drewsen wrote:

On Tuesday, 18 April 2017 at 08:42:38 UTC, Walter Bright wrote:

On 4/15/2017 1:04 PM, Jonas Drewsen wrote:

[...]


Thanks for doing the work to make a sample implementation, too. I don't know
if this will make it into D, but Jonas is a fine example of a champion.


Thanks for the feedback. Nice to know that it is not immediately off the table
at least :)



I can't promise anything. But it does need a lot of work. A survey of how it is 
done in other languages is helpful to see what they find useful and to see what 
has been overlooked. A quick look by me shows a lot of variety.


D's lambda syntax came about after such a survey, and we cherry-picked the best 
characteristics of the lot. The result was a nice home run for D.


The n.g. discussion also brought up a couple of existing library solutions. 
Those need to be evaluated as well and compared with any language solution.

Re: Interpolated strings

[H. S. Teoh via Digitalmars-d]

On Wed, Apr 19, 2017 at 06:38:13PM +, Patrick Schluter via Digitalmars-d 
wrote:
[...]
> As a string interpolation sceptic I have to admit that I found one
> application of that concept that is probably much better than the
> current C derived format strings: Internationalisation.
> 
> dates["en"] = "The date is %2$02d-%1$02d-%3$04d";
> dates["fr"] = "La date est %1$02d-%2$02d-%3$04d";
> 
> writeln(format(dates[lan], day, month, year));
> 
> with interpolation we have
> 
> dates["en"] = $"The date is {month:%02d}-{day:02d}-{year:04d}";
> dates["fr"] = $"La date est {day:%02d}/{month:%02d}/{year:04d}";
> 
> which is a little bit easier to read than positional format specifiers,

Somebody proposed some years ago to add named parameter support to
format strings (if not to D itself). So ostensibly, instead of writing
the nastiness like the above "La date est %1$02d...", you'd be able to
write something like:

 dates["en"] = "The date is %{month}02d-%{day}02d-%{year}04d";
 dates["fr"] = "La date est %{day}02d-%{month}02d-%{year}04d";

 writefln(dates[lan], [ "day": day, "month": month, "year": year]);


> which have the added backdraw (at least in C, I don't know for D) that
> they are an none or ALL thing. When you need them, you have to put
> them an all format specifiers.

I think std.format.format actually allows you to mix positional and
non-positional specifiers in the same format string. But the semantics
have some tricky bits, though, so I wouldn't recommend doing it.


> This said, the interpolation has in that case a big drawback, i.e.
> that they "export" the variable names outside of the scope they are
> defined in. That's a thing that is often required for I10N, that the
> strings are defined in a separate file or module and selectively
> imported (at runtime).

With named parameter support in format strings, we wouldn't have this
problem, since you could name the parameters however you want regardless
of actual variable names. You could even perform arbitrary computations
on the variables before passing it to format, e.g.:

writefln("The date is %{year}04d-%{month}02d-%{day}02d", [
"year": yearsSinceEpoch + 1970,
"month": zeroBasedMonth + 1,
"day": zeroBasedDay + 1
]);

This way, implementation details like zero-based counting, years since
the Unix Epoch, etc., are kept within the code where it belongs, not in
the i18n strings.

I'd argue that interpolated strings have a disadvantage here, because
you wouldn't want to expose the computation `yearsSinceEpoch + 1970` to
the l10n translators, who may inadvertently modify the expression to
something wrong. Plus, allowing arbitrary (Turing-complete!) expressions
inside l10n strings is just a security exploit waiting to happen.


T

-- 
Bare foot: (n.) A device for locating thumb tacks on the floor.

The lost Group

[Jolly James via Digitalmars-d]

https://forum.dlang.org/group/D does not appear in the forum's 
index or sidebar.

DMD VS2017 Support

[Jolly James via Digitalmars-d]

DMD does not support VS2017. Therefore I cannot link x64 
applications. DMD installer only offers to install VS2013 (what I 
am absolutely not going to do, as that would be a real shame with 
the disk space it consumes).


Any plans for supporting VS2017?

Re: Exact arithmetic with quadratic irrationals

[Stanislav Blinov via Digitalmars-d]

Awesome! Congrats and thanks for sharing.

On Wednesday, 19 April 2017 at 19:32:14 UTC, H. S. Teoh wrote:

Haha, it seems that the only roadblocks were related to the 
implementation quality of std.numeric.gcd... nothing that a few 
relatively-simple PRs couldn't fix.  So overall, D is still 
awesome.


There's another one, which is more about dmd: dmd does not inline 
gcd, which, when arguments are const, turns gcd into a double 
function call :D

Exact arithmetic with quadratic irrationals

[H. S. Teoh via Digitalmars-d]

I alluded to this in D.learn some time ago, and finally decided to take
the dip and actually write the code. So here it is: exact arithmetic
with numbers of the form (a+b√r)/c where a, b, c are integers, c!=0, and
r is a (fixed) square-free integer.

Code:   https://github.com/quickfur/qrat

I wrote this code in just a little over a day, a testament to D's
productivity-increasing features, among which include:

1) Built-in unittests: I couldn't have had the confidence that my code
was correct if I hadn't been able to verify it using unittests, that
also ensured that there would be no regressions, *and* also provided
nice ddoc'd examples for the user. This is a killer combo, IMO.

2) Sane(r) operator overloading: even though there's still a certain
amount of boilerplate, operator overloading in D is far saner than in
C++, thanks to:

a) Templated opUnary / opBinary / opOpAssign with the operator
as a string template argument that can be used in mixins. This
saved me quite a bit of copy-pasta that would have otherwise
been necessary, e.g., in a C++ implementation.

b) Unification of <, <=, >, >= under opCmp, and !=, == under
opEquals. Again, tons of copy-pasta were avoided where they
would have been necessary in C++.

c) opBinaryRight, an underrated genius design decision, that
allowed easy support of expressions of the form `1 + q` without
C++ hacks like friend functions and what-not.

3) Sane template syntax, that, combined with opBinaryRight and the other
overloading features, made expressions like this possible, and
readable(!):

// So clear, so readable!
auto goldenRatio = (1 + surd!5)/2;

// This would have been a mess in C++ syntax due to template
// clashing visually with operator <.
assert((10 + surd!5)/20 < (surd!5 - 1)/2);

4) Code coverage built into the compiler with -cov, that caught at least
one bug in a piece of code that my unittests missed. Now with 100% code
coverage, I feel far more confident that there are no nasty bugs left!

5) Pay-as-you-go template methods: I deliberately turned all QRat
methods into template functions, because of (a) template attribute
inference (see below), and (b) reducing template bloat from
instantiating methods that are never used in user code.

6) Template attribute inference: this allowed me, *after the fact*, to
slap 'pure nothrow @safe @nogc' onto my module ddoc'd unittest, and
instantly get compiler feedback on where exactly I'd inadvertently broke
purity / nothrowness / safety / etc., where I didn't intend.  And it was
very gratifying, once I'd isolated those bits of code, to have the
confidence that the compiler has verified that the core operations
(unary / binary operators, comparisons, etc.) were all pure nothrow
@safe @nogc, and thus widely usable.  If I'd had to wrangle with
explicitly writing attributes, I would've been greatly hampered in
productivity (not to mention frustrated and distracted from focusing on
the actual algorithms rather than the fussy nitty-gritties of the
language).  Attribute inference is definitely the way of the future, and
I support Walter in pushing it as far as it can possibly go. And
statically-verified guarantees too.  That's another win for D.

Having said that, though, there were a few roadblocks:

1) std.numeric.gcd doesn't support BigInt. This in itself wouldn't have
been overly horrible, if it weren't for the fact that:

a) The algorithm in std.numeric.gcd actually *does* work for
BigInt, but BigInt support wasn't implemented because there are
ostensibly better-performing BigInt GCD algorithms out there --
but they are too complex to implement so nobody has done it yet.
An unfortunate example of letting the perfect being the enemy of
the good, that's been plaguing D for a while now.

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

b) There are no sig constraints in std.numeric.gcd even though
it doesn't support BigInts (or, for that matter, custom
numerical types). This means that once you import std.numeric,
you can't even provide your own overloads of gcd to handle
BigInt or whatever other types you wish to handle, without
running into overload conflicts. Not without unnecessarily
convoluted schemes of static imports, symbol aliasing, and all
the rest of that churn.

c) The only thing that's really standing in the way of BigInt in
std.numeric.gcd is an ill-advised (IMO) way to test if a numeric
type has sign, by assuming that that's equivalent to having a
.min property.  That really only works for built-in types, which
again screams "missing sig constraints!", and basically fails
for everything else.

2) std.numeric.gcd isn't variadic, so I had to roll my own. Not a
biggie, but it was still annoying and wasted my time 

Re: Cap'n Proto for D v0.1.2

[Thomas Brix Larsen via Digitalmars-d-announce]

On Wednesday, 19 April 2017 at 18:24:46 UTC, Jay Norwood wrote:

[...]

Ok, thanks. I took a look at several capnproto implementations 
just now, and didn't see any tests for a mmap 'feature'.  The 
roadmap doc below indicates it doesn't exist, and perhaps there 
are some details yet to be resolved to make it 'friendly' for a 
mmap.


But reading using random access *is* a feature of Cap'n Proto. So 
when reading a memory mapped Cap'n Proto file, getters will be 
faster if you use it in a non-sequential way.


The format of Cap'n Proto doesn't currently support *writing* to 
a memory mapped file.

Re: Compare boost::hana to D

[Joakim via Digitalmars-d]

On Wednesday, 19 April 2017 at 18:30:49 UTC, Adrian Matoga wrote:
On Wednesday, 19 April 2017 at 18:26:20 UTC, Sebastiaan Koppe 
wrote:
On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga 
wrote:

[2] https://epi.github.io/2017/03/18/less_fun.html


Great article!


Thanks! I should mention I've also got somewhat positive 
feedback from Louis [1].


[1] https://twitter.com/LouisDionne/status/843227582803849216


Interesting exchange.

Your tweet announcing that post 
(https://twitter.com/C012294/status/843216981566349312) doesn't 
show up for me in twitter's hashtag search:


https://twitter.com/hashtag/dlang

Can't say I'm surprised that they're incompetent at searching 
their own tweets though.

Compile Error

[MihailProg via Digitalmars-d]

I use Visual Studio 2015 with the latest versions of D installed, 
and when i try to compile a simple hello world code i get this 
error:


-- Build started: Project: LearningD, Configuration: Debug 
Win32 --

Building Win32\Debug\LearningD.exe...
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

"Win32\Debug\LearningD.obj,Win32\Debug\LearningD.exe,Win32\Debug\LearningD.map,user32.lib+"
kernel32.lib/NOMAP/CO/NOI/DELEXE
LINK : fatal error LNK1181: cannot open input file 
'Win32\Debug\LearningD.obj,Win32\Debug\LearningD.exe,Win32\Debug\LearningD.map,user32.lib+'

Building Win32\Debug\LearningD.exe failed!
Details saved as 
"file://C:\Users\crack\documents\visual%20studio%202015\Projects\LearningD\LearningD\Win32\Debug\LearningD.buildlog.html"
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped 
==



Also the code i try to compile is:

import std.stdio;

int main(string[] argv)
{
writeln("Hello D-World!");
return 0;
}

Re: Optilink bugs(or DMD)

[Temtaime via Digitalmars-d]

On Wednesday, 19 April 2017 at 15:15:21 UTC, Nierjerson wrote:

On Wednesday, 19 April 2017 at 04:25:40 UTC, Stefan Koch wrote:

On Wednesday, 19 April 2017 at 03:52:54 UTC, Nierjerson wrote:
Major optilink bugs, blocker. Code is long but demonstrates 
the issue. Compiles with ldc.


[...]


There are two instances of void ForegroundColor(cSolidColor 
rhs)


Well, that could be a problem with the code, but it does 
compile with LDC so LDC then has an issue or dmd/optilink has 
the issue. Something is wrong. But, I guess removing the 
duplicates should at least allow dmd to compile the code.


DMD compiles the code too. The code doesn't link.
Optlink forbids duplicates, but ldc uses msvc link and it allows 
them(as i remember, it shows a warning).

Re: Compare boost::hana to D

[Ali Çehreli via Digitalmars-d]

On 04/19/2017 12:12 PM, Adrian Matoga wrote:

On Wednesday, 19 April 2017 at 18:57:19 UTC, David Gileadi wrote:

On 4/19/17 11:30 AM, Adrian Matoga wrote:

On Wednesday, 19 April 2017 at 18:26:20 UTC, Sebastiaan Koppe wrote:

On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga wrote:

[2] https://epi.github.io/2017/03/18/less_fun.html




Minor nit in the article--in the following paragraph "runtime" should
probably be replaced with "compile time":

"Note the enum in place where C++ version used auto. The type is also
inferred automatically, but using enum forces index to be computed at
runtime and only then it can be used in static assert."


Fixed, thanks a lot!
It seems impossible to spot all mistakes without someone else's eyes
even if I read it a thousand times... :|


(I saw that too. :) And one more.)

Thank you. Has this been on Reddit yet?

Two typos:

1) A missing underscore made me believe C++ gained a new keyword (make). :)

auto events = make event_system("foo"_s, "bar"_s, "baz"_s});

2) Replace runtime with compile-time?

"but using enum forces index to be computed at runtime"

Ali

Re: Compare boost::hana to D

[Adrian Matoga via Digitalmars-d]

On Wednesday, 19 April 2017 at 18:57:19 UTC, David Gileadi wrote:

On 4/19/17 11:30 AM, Adrian Matoga wrote:
On Wednesday, 19 April 2017 at 18:26:20 UTC, Sebastiaan Koppe 
wrote:
On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga 
wrote:

[2] https://epi.github.io/2017/03/18/less_fun.html




Minor nit in the article--in the following paragraph "runtime" 
should probably be replaced with "compile time":


"Note the enum in place where C++ version used auto. The type 
is also inferred automatically, but using enum forces index to 
be computed at runtime and only then it can be used in static 
assert."


Fixed, thanks a lot!
It seems impossible to spot all mistakes without someone else's 
eyes even if I read it a thousand times... :|

Re: Can we disallow appending integer to string?

[Stanislav Blinov via Digitalmars-d-learn]

On Wednesday, 19 April 2017 at 18:40:23 UTC, H. S. Teoh wrote:

A few extra keystrokes to type cast(int) or cast(char) ain't 
gonna kill nobody. In fact, it might even save a few people by 
preventing certain kinds of bugs.


Yup. Not to mention one could have

@property
auto numeric(Flag!"unsigned" unsigned = No.unsigned, C)(C c) 
if(isSomeChar!C)

{
return cast(IntOfSize!(C.sizeof, unsigned))c;
}

auto v = 'a'.numeric;

...or even have an equivalent as a built-in property of character 
types...

Re: DConf 2017 Berlin - bicycles

[Fool via Digitalmars-d]

No personal experience, but

 http://www.yaambike.de/

sounds like an option.

Re: Compare boost::hana to D

[David Gileadi via Digitalmars-d]

On 4/19/17 11:30 AM, Adrian Matoga wrote:

On Wednesday, 19 April 2017 at 18:26:20 UTC, Sebastiaan Koppe wrote:

On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga wrote:

[2] https://epi.github.io/2017/03/18/less_fun.html


Great article!


Thanks! I should mention I've also got somewhat positive feedback from 
Louis [1].


[1] https://twitter.com/LouisDionne/status/843227582803849216


Minor nit in the article--in the following paragraph "runtime" should 
probably be replaced with "compile time":


"Note the enum in place where C++ version used auto. The type is also 
inferred automatically, but using enum forces index to be computed at 
runtime and only then it can be used in static assert."

Re: Can we disallow appending integer to string?

[H. S. Teoh via Digitalmars-d-learn]

On Wed, Apr 19, 2017 at 05:56:18PM +, Stanislav Blinov via 
Digitalmars-d-learn wrote:
> On Wednesday, 19 April 2017 at 17:34:01 UTC, Jonathan M Davis wrote:
> > Personally, I think that we should have taken the stricter approach
> > and not had integral types implicit convert to character types, but
> > from what I recall, Walter feels pretty strongly about the
> > conversion rules being the way that they are.
> 
> Yep, me too. Generally, I don't think that an implicit conversion (T :
> U) should be allowed if T.init is not equivalent to U.init.

Me three.

Implicit conversion of int to char/dchar/etc. is a horrible, horrible
idea that leads to hard-to-find bugs. The whole point of having a
separate type for char vs. ubyte, unlike in C where char pretty much
means byte/ubyte, is so that we can keep their distinctions straight,
not to continue to confuse them in the typical C manner by having their
distinction blurred by implicit casts.

Personally, I would rather have arithmetic on char (wchar, dchar)
produce results of the same type, so that no implicit conversions are
necessary.  It seems to totally make sense to me to have to explicitly
ask for a character's numerical value -- it documents code intent, which
often also helps the programmer clear his head and avoid mistakes that
would otherwise inevitably creep in. A few extra keystrokes to type
cast(int) or cast(char) ain't gonna kill nobody. In fact, it might even
save a few people by preventing certain kinds of bugs.


T

-- 
Gone Chopin. Bach in a minuet.

[Issue 10001] string formatting with underscores

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Interpolated strings

[Patrick Schluter via Digitalmars-d]

On Wednesday, 19 April 2017 at 13:04:08 UTC, Jonathan Marler 
wrote:

On Wednesday, 19 April 2017 at 12:03:47 UTC, Stefan Koch wrote:
On Wednesday, 19 April 2017 at 11:59:51 UTC, Jonas Drewsen 
wrote:



I can think of 3 reasons.

1. Requires GC.

NOTE: I believe that most applcations should use GC memory, 
that being said, library code has to be nogc wherever it can if 
it wants to be used by nogc apps, so this solution is unusable 
in alot of library code.


2. It's verbose.  Jonas provided a good example of why and he 
makes a good point that your example only has 1 formatted 
argument and this problem gets much worse with multiple.


3. The biggest reason I wouldn't use this solution because it 
uses string composition.  String composition wastes memory and 
memory management cycles.  And when I say "waste" what I mean 
is, the use is unnecessary.  In general composition is a 
powerful tool because it allows you to easily overload and 
abstract and add new functionality, however, it requires 
runtime overhead.  This is the reason that the 
toString(delegate) was created to replace the composable 
toString paradigm.  It's also the reason that string formatting 
exists at all.


To summarize:

// requires GC, too verbose, uses string composition which 
wastes heap resources

writeln("The date is " ~ format("%04d", year));

// efficient, but format string and args can get out of sync.
writefln("the date is %04d", year);

//
writefln($"the date is {year:04d}");

If string interpolation gets reduced to the 2nd case, then it 
will have the same efficiency and solve a problem.  Whether 
that problem justifies the change is up for debate, but I think 
it *might be*.


As a string interpolation sceptic I have to admit that I found 
one application of that concept that is probably much better than 
the current C derived format strings: Internationalisation.


dates["en"] = "The date is %2$02d-%1$02d-%3$04d";
dates["fr"] = "La date est %1$02d-%2$02d-%3$04d";

writeln(format(dates[lan], day, month, year));

with interpolation we have

dates["en"] = $"The date is 
{month:%02d}-{day:02d}-{year:04d}";
dates["fr"] = $"La date est 
{day:%02d}/{month:%02d}/{year:04d}";


which is a little bit easier to read than positional format 
specifiers, which have the added backdraw (at least in C, I don't 
know for D) that they are an none or ALL thing. When you need 
them, you have to put them an all format specifiers.
This said, the interpolation has in that case a big drawback, 
i.e. that they "export" the variable names outside of the scope 
they are defined in. That's a thing that is often required for 
I10N, that the strings are defined in a separate file or module 
and selectively imported (at runtime).

[Issue 10001] string formatting with underscores

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/5de9af20ad07ebe485394309867073baa53b627b
Merge pull request #5303 from burner/origin/formatunderscore

fix Issue 10001 - std.format insert underscores into numbers
merged-on-behalf-of: unknown

--

Re: Interpolated strings

[H. S. Teoh via Digitalmars-d]

On Tue, Apr 18, 2017 at 05:30:31PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
> Reminds me of a story from the 1980s. Microsoft's MASM stood for
> "Macro Assembler". Inevitably, Microsoft programmers invented a pile
> of macros that sort of turned asm programming into a pseudo-high-level
> language. This was shipped with every copy of MASM.
> 
> A friend of mine who worked at MS was once given the task of fixing a
> bug in 50K of MASM code written in this macro language. The author of
> it had long since moved on. Every coder assigned to this task failed.
> My friend got it fixed in a couple hours. He was asked by his
> astonished manager how he'd managed to do it:
> 
> "I assembled the code into an object file. Then I disassembled it with
> Zortech's OBJ2ASM, figured out how to fix it, then submitted the
> disassembled code as the new source code."

+1, Classic!


T

-- 
VI = Visual Irritation

multiple `alias this` suggestion

[Carl Sturtivant via Digitalmars-d]

Currently only one `alias this` declaration is permitted, and the 
documentation https://dlang.org/spec/class.html#AliasThis says 
the following.


"Multiple AliasThis are allowed. For implicit conversions and 
forwarded lookups, all AliasThis declarations are attempted; if 
more than one AliasThis is eligible, the ambiguity is disallowed 
by raising an error. Note: Multiple AliasThis is currently 
unimplemented."


However the effect of multiple `alias this` declarations can be 
approximated in existing D using only single `alias this`, e.g. 
in the following three members each with `alias this` are 
simulated.


//
struct member1
{
int n1, n2, n3;
}

struct member2
{
int n2, n3;
member1 member;
alias member this;
}

struct member3
{
int n3;
member2 member;
alias member this;
}

struct top
{
member3 member;
alias member this;

this(int i, int j, int k)
{
n1 = i; n2 = j; n3 = k;
}
}


void main()
{
auto x = top(1,2,3);
member3 m3 = x.member;
member2 m2 = m3.member;
member1 m1 = m2.member;

import std.stdio;
writefln("%s %s %s", m1.n1, m1.n2, m1.n3);
writefln("%s %s %s", m2.n1, m2.n2, m2.n3);
writefln("%s %s %s", m3.n1, m3.n2, m3.n3);
writefln("%s %s %s", x.n1, x.n2, x.n3);
}
//

Which outputs the following as expected from chaining the effects 
of `alias this`.


1 0 0
1 2 0
1 2 3
1 2 3

Note that this construction provides a natural hierarchy for name 
lookup, unlike the statement above taken from the documentation.


Imagine the existing single `alias this` is extended to provide 
such a heierarchy of lookups. For example,


struct top
{
mem3 m3;
mem2 m2;
mem1 m1;
alias m3, m2, m1 this;
// ...
}

could be interpreted to mean search for a name in m3 if not found 
in top, and in m2 if not found in m3 and in m1 if not found in 
m2. I don't back the syntax, just the notion.


Maybe that's not all that's expected from "multiple alias this" 
but it would be a clean step forward. Issues?

Re: Compare boost::hana to D

[Adrian Matoga via Digitalmars-d]

On Wednesday, 19 April 2017 at 18:26:20 UTC, Sebastiaan Koppe 
wrote:
On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga 
wrote:

[2] https://epi.github.io/2017/03/18/less_fun.html


Great article!


Thanks! I should mention I've also got somewhat positive feedback 
from Louis [1].


[1] https://twitter.com/LouisDionne/status/843227582803849216

Re: Compare boost::hana to D

[Sebastiaan Koppe via Digitalmars-d]

On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga wrote:

[2] https://epi.github.io/2017/03/18/less_fun.html


Great article!

Re: Cap'n Proto for D v0.1.2

[Jay Norwood via Digitalmars-d-announce]

On Wednesday, 19 April 2017 at 16:52:14 UTC, Thomas Brix Larsen 
wrote:
Take a look at FileDescriptor[1]. It is a class I've added to 
support read/write using File from std.stdio. You can create a 
similar streamer using std.mmfile. I believe that this would be 
enough for memory mapped reading.


[1]: 
https://github.com/ThomasBrixLarsen/capnproto-dlang/blob/master/source/capnproto/FileDescriptor.d


Ok, thanks. I took a look at several capnproto implementations 
just now, and didn't see any tests for a mmap 'feature'.  The 
roadmap doc below indicates it doesn't exist, and perhaps there 
are some details yet to be resolved to make it 'friendly' for a 
mmap.


https://capnproto.org/roadmap.html

mmap-friendly mutable storage format: Define a standard storage 
format that is friendly to mmap-based use while allowing 
modification. (With the current serialization format, mmap is 
only useful for read-only structures.) Possibly based on the ORM 
interface, updates only possible at the granularity of a whole 
ORM entry.



In java the MappedByteBuffer can be used with a RandomAccessFile 
channel, and then the accesses of the loaded map can be random, 
without requiring sequential accesses of the whole mapped file. 
So java nio already has some higher level classes in place that 
would make it easier to develop a first implementation of the 
mmap features.

DConf 2017 Berlin - bicycles

[Adrian Matoga via Digitalmars-d]

I'm arriving at Berlin Ostbahnhof on Wednesday evening and will 
be heading to Britz Hotel, but last year I learnt that the best 
way to get around the city is on a bicycle. Can you recommend a 
place (preferably near the station) where I could rent a 
not-so-small bike for 4 days for a reasonable price?

Thanks!

Re: Compare boost::hana to D

[Adrian Matoga via Digitalmars-d]

On Wednesday, 19 April 2017 at 08:19:52 UTC, Ali Çehreli wrote:
I'm brushing up on my C++ to prepare for my C++Now 2017 
presentation[1]. boost::hana is an impressive library that 
overlaps with many D features:


  
http://www.boost.org/doc/libs/1_64_0_b2/libs/hana/doc/html/index.html


Have you used boost::hana? What are your thoughts on it?

And please share your ideas for the presentation. There has 
been threads here about C++ closing the gap. Does D still bring 
competitive advantage or is it becoming irrelevant? (Obviously, 
some think its irrelevant already.) I'm trying to collect 
opinions... :)


Thank you,
Ali

[1] 
http://cppnow.org/2017-conference/announcements/2017/04/09/d-keynote.html


I was at C++ Meeting 2016 in Berlin, where Louis Dionne talked 
about hana in his keynote [1]. I've summarized my feelings in a 
blog post [2]. In short, you can do the same tricks in D, but 
frequently there's an idiomatic way to express the same thing 
just as concisely without them.
And of course, feel free to use any part of my post in your talk. 
:)


[1] https://www.youtube.com/watch?v=X_p9X5RzBJE
[2] https://epi.github.io/2017/03/18/less_fun.html

Re: Stuck with DMD, and Unit-Threaded

[Atila Neves via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 07:07:16 UTC, Russel Winder wrote:
On Mon, 2017-04-17 at 22:56 +, Atila Neves via 
Digitalmars-d-learn wrote:



[…]

https://github.com/russel/ApproxGC/pull/2

Unfortunately the auto generated integration test main file 
doesn't quite work (feel free to file a bug on unit-threaded) 
so in that PR I disabled auto-generating it and force added my 
edited version.


What I did there in dub.sdl is my current go-to solution for 
also running integration tests with unit-threaded.




Thanks for that, much appreciated. I am hesitant to commit the 
pull request for now in case get_ut_main gets fixed fairly 
quickly. For the moment I am progressing with the SCons build 
since I got it working.


I wouldn't hold my breath - the fix is annoying and non-trivial. 
Basically I special cased "source" since it's the default for dub 
packages but "test-source" gums up the works and I'd have to look 
at it properly.


The real joy is that I have Unit-Threaded working. It's 
extensions of the unittest D language feature make testing D 
codes far more fun than the basic feature. Thanks for putting 
in the effort.


I'm happy the work is appreciated :)

Atila

Re: Interpolated strings

[Meta via Digitalmars-d]

On Wednesday, 19 April 2017 at 15:07:55 UTC, Jonas Drewsen wrote:
I'm talking about building format strings just yet... I'm just 
working with the suggestion that Walter brought up with 
converting the interpolated string into something that can be 
fed into format e.g.:


$"The date is {%04d year} and {user} just logged into {here}"

is rewritten by the compiler to:

"The date is %04d and %s just logged into %s", year, user, here

which can be fed into for example format(). Not sure I like the 
need to call format to get the resulting string, but just 
working with the idea here.


I also think it would loose a lot of value to only allow 
strings as you suggest (e.g. %dateString).


If we had language-level tuple literals you could desugar the 
expression into:


("The date is %04d and %s just logged into %s", year, user, here)

And let a user do whatever they want with it.

Even now it can be done with an AliasSeq, but not with the 
automatic insertion of format arguments, of course.


alias fs = AliasSeq!("The date is %04d and %s just logged into 
%s", 1992, "Alan", "10.1.0.123");


writeln(format(fs)); //Prints "The date is 1992 and Alan just 
logged into 10.1.0.123"

Re: Can we disallow appending integer to string?

[Stanislav Blinov via Digitalmars-d-learn]

On Wednesday, 19 April 2017 at 17:34:01 UTC, Jonathan M Davis 
wrote:


Personally, I think that we should have taken the stricter 
approach and not had integral types implicit convert to 
character types, but from what I recall, Walter feels pretty 
strongly about the conversion rules being the way that they are.


Yep, me too. Generally, I don't think that an implicit conversion 
(T : U) should be allowed if T.init is not equivalent to U.init.

Re: Interpolated strings

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/17/2017 03:41 PM, Jonas Drewsen wrote:

On Monday, 17 April 2017 at 19:12:37 UTC, Martin Tschierschke wrote:

defining a new method exho! (derived from echo + mixin...:-)

  auto exho(string x)(){
 return mixin("writeln("~interp!x~")");}

You can just write:

   exho!"The number ${num} doubled is ${num * 2}!"


It requires 'num' to be available to the exho function definition so
will not
work in the general case.


Also, it only works if you're just sending the string to writeln. It 
doesn't help the general case :(

Re: What are we going to do about mobile? [OT]

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 04/13/2017 06:16 PM, Joakim wrote:

 From a certain point of view, you could say PC sales are only down 25%
from their peak, that's not dead yet.  But the chart I linked shows
their share of personal computing devices, including mobile, has dropped
from 78% to a little less than 14% over the last decade.  I'd call that
dying.


In other words: It can only be considered "dying" if you conveniently 
ignore certain facts, and instead look only at a stat that doesn't show 
the full picture.

Re: Can we disallow appending integer to string?

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, April 19, 2017 14:50:38 Stanislav Blinov via Digitalmars-d-
learn wrote:
> On Wednesday, 19 April 2017 at 14:36:13 UTC, Nick Treleaven wrote:
> > This bug is fixed as the code no longer segfaults but throws
> > instead:
> > https://issues.dlang.org/show_bug.cgi?id=5995
> >
> > void main(){
> >
> > string ret;
> > int i = -1;
> > ret ~= i;
> >
> > }
> >
> > Why is it legal to append an integer?
>
> Because integrals implicitly convert to characters of same width
> (byte -> char, short -> wchar, int -> dchar).

Yeah, which reduces the number of casts required when doing arithmetic on
characters and thus reduces bugs there, and I believe that that's the main
reason the implicit conversion from an integral type to a character type
exists. So, having the implicit conversion fixes one set of bugs, and
disallowing it fixes another. We have similar problems with bool.

Personally, I think that we should have taken the stricter approach and not
had integral types implicit convert to character types, but from what I
recall, Walter feels pretty strongly about the conversion rules being the
way that they are.

- Jonathan M Davis

Re: Compare boost::hana to D

[Ali Çehreli via Digitalmars-d]

On 04/19/2017 03:58 AM, Laeeth Isharc wrote:

> Hope you're well.

I'm doing very well. Hoping to see you at DConf. :)

Here's another reminder to all: The registration deadline is this Sunday!

> On the other hand I was reading some object oriented C++ code of 20k
> lines split between 200 files.  I just about read C++ so ceteris non
> paribus.  But the fragmentation and artificial abstraction makes it much
> harder to see what's going on and it's scarier to change it.

That's a good point that comes up regularly. I wonder why C++ code seems 
to use OOP more than e.g. D does? Is it the reverberation of that old 
"everything is an object" style? Otherwise, it's quite possible to do 
compile-time polymorphism in C++ as well.


> However dub isn't worse than cmake

OT: I've used CMake in an unrelated project. I had failed to learn how 
to write a custom rule in it. It was super easy to make comman targets 
like an executable or library, but not custom stuff that we had needed. 
Anyway... There are smarter people who can use it. :)


> Some concrete examples that are true and essentially real might be a
> nice counterpart to the "quicksort in two lines" language evangelism
> that Andrei rightly complains about.

OT: Is there something new in Haskell that makes Sieve of Eratosthenes 
easier than the following entertaining paper shows?


  https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf

> Maybe you have some from Weka.

Yes, Weka is a great user of D. They take full advantage of the 
compile-time features of D for profit. :)


OT: Unfortunately, I'm not with Weka anymore. :/ Now I know that it 
takes way more focus to work through the 10 hour and the 1 day 
differences. Their weekends are Friday and Saturday, so by the time I 
started my Thursday morning, Israel was already off to their weekends.


> D is a pretty good language for getting stuff done quickly in
> for a prototype that can be cleaned up quickly. That's a point
> Andy Smith made, and that Liran made in his talk also.

Joakim is right when saying "it is hard to market without people either 
trying the language or user testimonials". I'm dealing with the same 
issue at my current job: Despite my attempts, there may be separate 
non-D languages for prototyping and actual implementation.


Ali

Re: Interpolated strings

[jmh530 via Digitalmars-d]

On Wednesday, 19 April 2017 at 16:19:09 UTC, Ola Fosheim Grøstad 
wrote:


Yup. And actually also "while" and "for". More minimal 
languages just have: block, conditional and 
jump-to-start-of-block.


This reminds me of Rust's mid-level IR for some reason. For 
instance, according to one of the Rust blog posts goto completely 
replaces loop, break, and continue.


Does it make sense to think of MIR as AST macros that only the 
compiler has access to?

Re: Cap'n Proto for D v0.1.2

[Thomas Brix Larsen via Digitalmars-d-announce]

On Wednesday, 19 April 2017 at 16:34:02 UTC, Jay Norwood wrote:

[...]

This info from stackoverflow also seems to imply that 
MappedByteBuffer would be required for some of the capnproto 
features.  So, could you explain a little more about what are 
the capabilities of the current d library implementation, with 
just the ByteBuffer implemented from the java nio code?  
Thanks, Jay


[...]


The port of ByteBuffer just wraps a slice when reading in D.

Take a look at FileDescriptor[1]. It is a class I've added to 
support read/write using File from std.stdio. You can create a 
similar streamer using std.mmfile. I believe that this would be 
enough for memory mapped reading.


[1]: 
https://github.com/ThomasBrixLarsen/capnproto-dlang/blob/master/source/capnproto/FileDescriptor.d

Re: Cap'n Proto for D v0.1.2

[Jay Norwood via Digitalmars-d-announce]

On Tuesday, 18 April 2017 at 18:09:54 UTC, Thomas Brix Larsen 
wrote:
"Cap’n Proto is an insanely fast data interchange format and 
capability-based RPC system. Think JSON, except binary. Or 
think Protocol Buffers, except faster."


The features below, from the capnproto.org description, interest 
me.  However a MappedByteBuffer would be used for the mmap 
feature in java.


https://capnproto.org/

mmap: Read a large Cap’n Proto file by memory-mapping it. The OS 
won’t even read in the parts that you don’t access.


Inter-language communication: Calling C++ code from, say, Java or 
Python tends to be painful or slow. With Cap’n Proto, the two 
languages can easily operate on the same in-memory data structure.


Inter-process communication: Multiple processes running on the 
same machine can share a Cap’n Proto message via shared memory. 
No need to pipe data through the kernel. Calling another process 
can be just as fast and easy as calling another thread.


This info from stackoverflow also seems to imply that 
MappedByteBuffer would be required for some of the capnproto 
features.  So, could you explain a little more about what are the 
capabilities of the current d library implementation, with just 
the ByteBuffer implemented from the java nio code?  Thanks, Jay


http://stackoverflow.com/questions/29361058/read-proto-partly-instead-of-full-parsing-in-java

'If you are willing to consider using a different protocol 
framework, Cap'n Proto is extremely similar in design to 
Protobufs but features in the ability to read only the part of 
the message you care about. Cap'n Proto incurs no overhead for 
the fields you don't examine, other than obviously the bandwidth 
and memory to receive the raw message bytes. If you are reading 
from a file, and you use memory mapping (MappedByteBuffer in 
Java), then only the parts of the message you actually use will 
be read from disk.'

Re: Interpolated strings

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 19 April 2017 at 09:49:16 UTC, Jacob Carlborg wrote:

On 2017-04-19 08:51, Ola Fosheim Grøstad wrote:

If you want AST-macros in D you should also argue for 
redefining the
core language, and turn everything that is unnecessary and 
that can be

done as lowering into macros (e.g. "for each").


If D had AST macros from the beginning, then yes, "foreach" 
could have been implemented as a macro.


Yup. And actually also "while" and "for". More minimal languages 
just have: block, conditional and jump-to-start-of-block.

[Issue 17330] [REG 2.072] BigInt's constructor used to be pure

[via Digitalmars-d-bugs]

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

--- Comment #1 from Jack Stouffer  ---
https://github.com/dlang/phobos/pull/5340

--

Re: The app hanging after reach 1750MB of RAM

[Stanislav Blinov via Digitalmars-d-learn]

On Wednesday, 19 April 2017 at 07:28:32 UTC, Suliman wrote:

1. You're measuring it wrong. Array length is already measured 
in terms of type size.


So should I do:
cargpspoints.length * cargpspoints[0].sizeof ?


No. .sizeof is the statically known size of a type, it can't take 
into account dynamically allocated memory.
cargpspoint.length * cargpspoints[0].sizeof will tell you the 
estimate size of the array, in bytes.
But each of the elements also has strings - dynamic arrays that 
are allocated elsewhere, their length is not included in that 
calculation.
So you could iterate over the array and sum up lengths of all 
strings to get an estimate.
Even then, that's just that: an estimate. Actual amount of memory 
allocated for a dynamic array T[] *may* be greater than length * 
T.sizeof. The only way to know that is to query the allocator 
used (in this case, GC).

Re: The app hanging after reach 1750MB of RAM

[Suliman via Digitalmars-d-learn]

On Wednesday, 19 April 2017 at 15:18:32 UTC, crimaniak wrote:

On Tuesday, 18 April 2017 at 11:43:24 UTC, Suliman wrote:
I am writing app that extract data from DB to array of 
structures.


void getSingleTrackInfo()
{

foreach(item; getTablesGPSSensorList)
{
ResultRange result = mysqlconnection.query(sqlquery);
auto MySQLPointsLonLat = result.array;
Is ResultRange closing query when exhausted? Did you try to 
call .close() on it after work?


Yes I tried:

ResultRange result = mysqlconnection.query(sqlquery);
auto MySQLPointsLonLat = result.array;
result.close();

Did not help :(

Re: Immovable types

[Stanislav Blinov via Digitalmars-d]

On Wednesday, 19 April 2017 at 14:45:59 UTC, Meta wrote:
On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov 
wrote:
Non-copyable and immovable types will have to be explicitly 
initialized, as if they had @disable this(), as they can't 
even be initialized with .init:


It's an interesting idea but I can't even begin to fathom how 
much code this would break. So much D code relies on every type 
having a valid .init.


It should not break any existing code, unless it is using the 
syntax @disable this(typeof(this)), which, at the moment, is 
nonsensical, though not invalid.


Nor does it make .init invalid. Non-copyable immovables simply 
won't be able to explicitly initialize from it (it's an rvalue). 
We'll still be able to e.g. compare against .init, etc:


struct Immovable
{
int value = 42;

this(int v) { value = v; }

@disable this(this);
@disable this(Immovable);
}

assert(Immovable.init.value == 42);

Immovable i = 42;
assert(i == Immovable.init);

Re: The DConf Experience

[Joakim via Digitalmars-d-announce]

On Wednesday, 19 April 2017 at 13:03:23 UTC, Mike Parker wrote:
The registration deadline for DConf 2017 is just around the 
corner (this Sunday). As a fun way to remind you, a handful of 
past attendees have shared some anecdotes of their experiences.


I've personally attended two conferences and watched (portions 
of) two on livestream + IRC. If you've never been and haven't 
yet registered, I can't emphasize strongly enough how much more 
fun and rewarding it is to be there in person. If you've got 
the time and the means, just do it!


Blog:
http://dlang.org/blog/2017/04/19/the-dconf-experience/

Reddit:
https://www.reddit.com/r/d_language/


Nice post.  What's the occupancy like for the event so far?  
Seemed pretty full last year, wondering how many more can sign up 
this year.

[Issue 17330] [REG 2.072] BigInt's constructor used to be pure

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com
   Assignee|nob...@puremagic.com|j...@jackstouffer.com

--

Re: Optilink bugs(or DMD)

[Nierjerson via Digitalmars-d]

On Wednesday, 19 April 2017 at 04:25:40 UTC, Stefan Koch wrote:

On Wednesday, 19 April 2017 at 03:52:54 UTC, Nierjerson wrote:
Major optilink bugs, blocker. Code is long but demonstrates 
the issue. Compiles with ldc.


[...]


There are two instances of void ForegroundColor(cSolidColor rhs)


Well, that could be a problem with the code, but it does compile 
with LDC so LDC then has an issue or dmd/optilink has the issue. 
Something is wrong. But, I guess removing the duplicates should 
at least allow dmd to compile the code.

Re: The app hanging after reach 1750MB of RAM

[crimaniak via Digitalmars-d-learn]

On Tuesday, 18 April 2017 at 11:43:24 UTC, Suliman wrote:
I am writing app that extract data from DB to array of 
structures.


void getSingleTrackInfo()
{

foreach(item; getTablesGPSSensorList)
{
ResultRange result = mysqlconnection.query(sqlquery);
auto MySQLPointsLonLat = result.array;
Is ResultRange closing query when exhausted? Did you try to call 
.close() on it after work?

Re: Interpolated strings

[Jonas Drewsen via Digitalmars-d]

On Wednesday, 19 April 2017 at 14:02:43 UTC, Stefan Koch wrote:
On Wednesday, 19 April 2017 at 12:10:33 UTC, Jonas Drewsen 
wrote:

On Wednesday, 19 April 2017 at 12:03:47 UTC, Stefan Koch wrote:
On Wednesday, 19 April 2017 at 11:59:51 UTC, Jonas Drewsen 
wrote:



What about supporting an optional prefix inside the {} like:

int year = 2017;
format($"The date is {%04d year}");

so if there is a % immediately following the { then the 
chars until next whitespace is format specifier. You can of 
course leave out the format specifier and it will default to 
%s.

I really don't see how string interpolation is better then
` "The date is " ~ format("%04d", year)); `


As mentioned before it is only because it is such a common 
pattern that it justifies the change. Seems like many other 
languages reached that conclusion as well.
Also take a look at a more realistic example with some more 
formatting and it will be more obvious (at least to me it is 
:) )


"The date is " ~ format("%04d", year)) ~ " and " ~ user ~ " 
just logged into " ~ here;


$"The date is {%04d year} and {user} just logged into {here}"


I see.
So you want to build format strings as well.
This is going to be nasty, and likely to complex for a robust 
implementation.

Here is what I would support:

String interpolation literals can only be used with strings.
And they need to start with some prefix which is not an 
operator.


I"The date is %dateString and the time is %timeString"


I'm talking about building format strings just yet... I'm just 
working with the suggestion that Walter brought up with 
converting the interpolated string into something that can be fed 
into format e.g.:


$"The date is {%04d year} and {user} just logged into {here}"

is rewritten by the compiler to:

"The date is %04d and %s just logged into %s", year, user, here

which can be fed into for example format(). Not sure I like the 
need to call format to get the resulting string, but just working 
with the idea here.


I also think it would loose a lot of value to only allow strings 
as you suggest (e.g. %dateString).

Re: Can we disallow appending integer to string?

[Stanislav Blinov via Digitalmars-d-learn]

On Wednesday, 19 April 2017 at 14:36:13 UTC, Nick Treleaven wrote:
This bug is fixed as the code no longer segfaults but throws 
instead:

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

void main(){
string ret;
int i = -1;
ret ~= i;
}

Why is it legal to append an integer?


Because integrals implicitly convert to characters of same width 
(byte -> char, short -> wchar, int -> dchar).

Re: Immovable types

[Meta via Digitalmars-d]

On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov 
wrote:
Non-copyable and immovable types will have to be explicitly 
initialized, as if they had @disable this(), as they can't even 
be initialized with .init:


It's an interesting idea but I can't even begin to fathom how 
much code this would break. So much D code relies on every type 
having a valid .init.

Can we disallow appending integer to string?

[Nick Treleaven via Digitalmars-d-learn]

This bug is fixed as the code no longer segfaults but throws 
instead:

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

void main(){
string ret;
int i = -1;
ret ~= i;
}

Why is it legal to append an integer?

[Issue 17333] Disallow concat of string with integer enum

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--

Re: Interpolated strings

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 19 April 2017 at 12:03:47 UTC, Stefan Koch wrote:

I really don't see how string interpolation is better then
` "The date is " ~ format("%04d", year)); `


That code is hideous, not hard to beat on every level... 
inefficient, hard to read.


The built in thing could potentially optimize it a little too - 
maybe have it be syntax sugar over a range.

[Issue 17333] Disallow concat of string with integer enum

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

Summary|Disallow CT concat of   |Disallow concat of string
   |string with integer |with integer enum

--

[Issue 17333] New: Disallow CT concat of string with integer

[via Digitalmars-d-bugs]

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

  Issue ID: 17333
   Summary: Disallow CT concat of string with integer
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: n...@geany.org

int n = 2;
//enum int n = 2;
string s = "" ~ n;

The above with dmd v2.074.0 produces:
ctforeachn.d(18): Error: incompatible types for (("") ~ (n)): 'string' and
'int'

However, using enum for n instead, the code compiles. It should produce the
same error.

--

Re: The DConf Experience

[Mike Parker via Digitalmars-d-announce]

On Wednesday, 19 April 2017 at 13:03:23 UTC, Mike Parker wrote:
The registration deadline for DConf 2017 is just around the 
corner (this Sunday). As a fun way to remind you, a handful of 
past attendees have shared some anecdotes of their experiences.


I've personally attended two conferences and watched (portions 
of) two on livestream + IRC. If you've never been and haven't 
yet registered, I can't emphasize strongly enough how much more 
fun and rewarding it is to be there in person. If you've got 
the time and the means, just do it!


Blog:
http://dlang.org/blog/2017/04/19/the-dconf-experience/

Reddit:
https://www.reddit.com/r/d_language/


And also:

https://www.reddit.com/r/programming/comments/66adnz/the_dconf_experience/

Re: Interpolated strings

[Stefan Koch via Digitalmars-d]

On Wednesday, 19 April 2017 at 12:10:33 UTC, Jonas Drewsen wrote:

On Wednesday, 19 April 2017 at 12:03:47 UTC, Stefan Koch wrote:
On Wednesday, 19 April 2017 at 11:59:51 UTC, Jonas Drewsen 
wrote:



What about supporting an optional prefix inside the {} like:

int year = 2017;
format($"The date is {%04d year}");

so if there is a % immediately following the { then the chars 
until next whitespace is format specifier. You can of course 
leave out the format specifier and it will default to %s.

I really don't see how string interpolation is better then
` "The date is " ~ format("%04d", year)); `


As mentioned before it is only because it is such a common 
pattern that it justifies the change. Seems like many other 
languages reached that conclusion as well.
Also take a look at a more realistic example with some more 
formatting and it will be more obvious (at least to me it is :) 
)


"The date is " ~ format("%04d", year)) ~ " and " ~ user ~ " 
just logged into " ~ here;


$"The date is {%04d year} and {user} just logged into {here}"


I see.
So you want to build format strings as well.
This is going to be nasty, and likely to complex for a robust 
implementation.

Here is what I would support:

String interpolation literals can only be used with strings.
And they need to start with some prefix which is not an operator.

I"The date is %dateString and the time is %timeString"

Re: Immovable types

[Stanislav Blinov via Digitalmars-d]

On Wednesday, 19 April 2017 at 08:52:45 UTC, kinke wrote:
On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov 
wrote:

But it is always assumed that a value can be moved.


It's not just assumed, it's a key requirement for structs in D, 
as the compiler can move stuff automatically this way (making a 
bitcopy and then eliding the postblit ctor for the new instance 
and the destructor for the moved-from instance).


That is quite a different concept to C++, where a (non-elided) 
special move ctor is required, moved-from instances need to be 
reset so that their (non-elided) destructor doesn't free 
moved-from resources etc.


That's not quite correct. Copy elision in C++ also elides copy 
and move ctors and dtor.
Move ctors aren't a requirement, they *can* be defined to 
override default move semantics, or deleted to disable move 
construction.
That is concerning optimizations performed by the compiler. 
Library move(), both in C++ and in D, cannot elide the 
destructor, as the value already exists.
But move() in C++ and D is indeed different. In C++ it's just a 
cast, and it is up to the programmer to redefine the semantics if 
needed, or disable it. In D, we're not allowed to do either. I'm 
only proposing to relax the restriction in terms of disabling 
move, not introduce move ctors into D.

Re: DIP 1006 - Preliminary Review Round 1

[Mike Parker via Digitalmars-d]

On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote:



All review-related feedback on and discussion of the DIP should 
occur in this thread. The review period will end at 11:59 PM ET 
on April 26 (3:59 AM GMT), or when I make a post declaring it 
complete.



Reminder: There's one week remaining.

The DConf Experience

[Mike Parker via Digitalmars-d-announce]

The registration deadline for DConf 2017 is just around the 
corner (this Sunday). As a fun way to remind you, a handful of 
past attendees have shared some anecdotes of their experiences.


I've personally attended two conferences and watched (portions 
of) two on livestream + IRC. If you've never been and haven't yet 
registered, I can't emphasize strongly enough how much more fun 
and rewarding it is to be there in person. If you've got the time 
and the means, just do it!


Blog:
http://dlang.org/blog/2017/04/19/the-dconf-experience/

Reddit:
https://www.reddit.com/r/d_language/

Re: Interpolated strings

[Jonathan Marler via Digitalmars-d]

On Wednesday, 19 April 2017 at 12:03:47 UTC, Stefan Koch wrote:
On Wednesday, 19 April 2017 at 11:59:51 UTC, Jonas Drewsen 
wrote:



What about supporting an optional prefix inside the {} like:

int year = 2017;
format($"The date is {%04d year}");

so if there is a % immediately following the { then the chars 
until next whitespace is format specifier. You can of course 
leave out the format specifier and it will default to %s.

I really don't see how string interpolation is better then
` "The date is " ~ format("%04d", year)); `


I can think of 3 reasons.

1. Requires GC.

NOTE: I believe that most applcations should use GC memory, that 
being said, library code has to be nogc wherever it can if it 
wants to be used by nogc apps, so this solution is unusable in 
alot of library code.


2. It's verbose.  Jonas provided a good example of why and he 
makes a good point that your example only has 1 formatted 
argument and this problem gets much worse with multiple.


3. The biggest reason I wouldn't use this solution because it 
uses string composition.  String composition wastes memory and 
memory management cycles.  And when I say "waste" what I mean is, 
the use is unnecessary.  In general composition is a powerful 
tool because it allows you to easily overload and abstract and 
add new functionality, however, it requires runtime overhead.  
This is the reason that the toString(delegate) was created to 
replace the composable toString paradigm.  It's also the reason 
that string formatting exists at all.


To summarize:

// requires GC, too verbose, uses string composition which wastes 
heap resources

writeln("The date is " ~ format("%04d", year));

// efficient, but format string and args can get out of sync.
writefln("the date is %04d", year);

//
writefln($"the date is {year:04d}");

If string interpolation gets reduced to the 2nd case, then it 
will have the same efficiency and solve a problem.  Whether that 
problem justifies the change is up for debate, but I think it 
*might be*.

Re: Compare boost::hana to D

[Nicholas Wilson via Digitalmars-d]

On Wednesday, 19 April 2017 at 11:58:07 UTC, Kagamin wrote:
On Wednesday, 19 April 2017 at 09:01:25 UTC, Sebastiaan Koppe 
wrote:
Haven't used C++ for a while actually. And seeing it after 
some time, makes me tremble convulsively.

// basic_string INSERTERS AND EXTRACTORS
[...]
:)


Ah yes C++ standard implementations. It took me a good 30s to 
find what function was being declared (operator >>). Used to have 
nightmares of those flying past at high speed  when getting 
template errors.

Re: Interpolated strings

[Jonas Drewsen via Digitalmars-d]

On Wednesday, 19 April 2017 at 12:03:47 UTC, Stefan Koch wrote:
On Wednesday, 19 April 2017 at 11:59:51 UTC, Jonas Drewsen 
wrote:



What about supporting an optional prefix inside the {} like:

int year = 2017;
format($"The date is {%04d year}");

so if there is a % immediately following the { then the chars 
until next whitespace is format specifier. You can of course 
leave out the format specifier and it will default to %s.

I really don't see how string interpolation is better then
` "The date is " ~ format("%04d", year)); `


As mentioned before it is only because it is such a common 
pattern that it justifies the change. Seems like many other 
languages reached that conclusion as well.
Also take a look at a more realistic example with some more 
formatting and it will be more obvious (at least to me it is :) )


"The date is " ~ format("%04d", year)) ~ " and " ~ user ~ " just 
logged into " ~ here;


$"The date is {%04d year} and {user} just logged into {here}"

Re: Interpolated strings

[Jonas Drewsen via Digitalmars-d]

On Tuesday, 18 April 2017 at 08:42:38 UTC, Walter Bright wrote:

On 4/15/2017 1:04 PM, Jonas Drewsen wrote:

[...]


Thanks for doing the work to make a sample implementation, too. 
I don't know if this will make it into D, but Jonas is a fine 
example of a champion.


Thanks for the feedback. Nice to know that it is not immediately 
off the table at least :)

Re: Interpolated strings

[Stefan Koch via Digitalmars-d]

On Wednesday, 19 April 2017 at 11:59:51 UTC, Jonas Drewsen wrote:


What about supporting an optional prefix inside the {} like:

int year = 2017;
format($"The date is {%04d year}");

so if there is a % immediately following the { then the chars 
until next whitespace is format specifier. You can of course 
leave out the format specifier and it will default to %s.

I really don't see how string interpolation is better then
` "The date is " ~ format("%04d", year)); `

Re: Interpolated strings

[Jonas Drewsen via Digitalmars-d]

On Wednesday, 19 April 2017 at 00:08:19 UTC, Walter Bright wrote:

On 4/18/2017 2:56 PM, Jonathan Marler wrote:
Have you thought about supporting format specifiers as well?  
I looked at the C#
version and it looks like they can specify them using a colon 
like this:


$"{a} in hex is {a:x}"


There are additional problems, such as:

$"{a} in %s {b}"

and positional parameters:

$"{a} in {0}"

Of course, the easiest solution is to just disallow that stuff.


What about supporting an optional prefix inside the {} like:

int year = 2017;
format($"The date is {%04d year}");

so if there is a % immediately following the { then the chars 
until next whitespace is format specifier. You can of course 
leave out the format specifier and it will default to %s.

Re: Compare boost::hana to D

[Kagamin via Digitalmars-d]

On Wednesday, 19 April 2017 at 09:01:25 UTC, Sebastiaan Koppe 
wrote:
Haven't used C++ for a while actually. And seeing it after some 
time, makes me tremble convulsively.


_STD_BEGIN
// basic_string INSERTERS AND EXTRACTORS
template inline
basic_istream<_Elem, _Traits>& operator>>(
basic_istream<_Elem, _Traits>&& _Istr,
basic_string<_Elem, _Traits, _Alloc>& _Str)
{   // extract a string
typedef ctype<_Elem> _Ctype;
typedef basic_istream<_Elem, _Traits> _Myis;
typedef basic_string<_Elem, _Traits, _Alloc> _Mystr;
typedef typename _Mystr::size_type _Mysizt;

ios_base::iostate _State = ios_base::goodbit;
bool _Changed = false;
const typename _Myis::sentry _Ok(_Istr);

if (_Ok)
{   // state okay, extract characters
const _Ctype& _Ctype_fac = _USE(_Istr.getloc(), _Ctype);
_Str.erase();

_TRY_IO_BEGIN
_Mysizt _Size = 0 < _Istr.width()
&& (_Mysizt)_Istr.width() < _Str.max_size()
? (_Mysizt)_Istr.width() : _Str.max_size();
typename _Traits::int_type _Meta = _Istr.rdbuf()->sgetc();

for (; 0 < _Size; --_Size, _Meta = 
_Istr.rdbuf()->snextc())

if(_Traits::eq_int_type(_Traits::eof(), _Meta))
{   // end of file, quit
_State |= ios_base::eofbit;
break;
}
else if (_Ctype_fac.is(_Ctype::space,
_Traits::to_char_type(_Meta)))
break;  // whitespace, quit
else
{   // add character to string
_Str.append(1, _Traits::to_char_type(_Meta));
_Changed = true;
}
_CATCH_IO_(_Istr)
}

_Istr.width(0);
if (!_Changed)
_State |= ios_base::failbit;
_Istr.setstate(_State);
return (_Istr);
}

:)

Re: Compare boost::hana to D

[Joakim via Digitalmars-d]

On Wednesday, 19 April 2017 at 10:58:06 UTC, Laeeth Isharc wrote:
One last thing.  D is a pretty good language for getting stuff 
done quickly in for a prototype that can be cleaned up quickly. 
That's a point Andy Smith made, and that Liran made in his talk 
also.  I am having to deal with that increasingly now.  I would 
certainly much rather turn a D prototype written by a trader 
into production than a python one - lets not speak of Matlab! 
This aspect is mentioned on website but should be hammered home 
- it's a practical language for getting started stuff done fast

 without leaving a mess.


This is a point that keeps coming up, but it is hard to market 
without people either trying the language or user testimonials.  
Would you be able to write up a blog post about this, perhaps 
along with your D collaborators to fish out some concrete 
examples from your collective experience, maybe for the D blog?


We tend to focus more on the technical side for the D blog, would 
be nice to have a post from this development perspective.

Re: Compare boost::hana to D

[Laeeth Isharc via Digitalmars-d]

On Wednesday, 19 April 2017 at 08:19:52 UTC, Ali Çehreli wrote:
I'm brushing up on my C++ to prepare for my C++Now 2017 
presentation[1]. boost::hana is an impressive library that 
overlaps with many D features:


  
http://www.boost.org/doc/libs/1_64_0_b2/libs/hana/doc/html/index.html


Have you used boost::hana? What are your thoughts on it?

And please share your ideas for the presentation. There has 
been threads here about C++ closing the gap. Does D still bring 
competitive advantage or is it becoming irrelevant? (Obviously, 
some think its irrelevant already.) I'm trying to collect 
opinions... :)


Thank you,
Ali

[1] 
http://cppnow.org/2017-conference/announcements/2017/04/09/d-keynote.html


Hi Ali.

Hope you're well.

I think not enough has been written on D's plasticity - Andrei 
and Walter talk about it in passing a couple of times.  But I 
have the impression that it's maybe quite important for merits of 
D's real world commercial value. Compare using refactoring  tools 
with not really needing them to same extent.


Something related to that.  I can go back and read my D code from 
early 2014 when I was learning D and it's all perfectly clear to 
me.  My python code not so much.  And two of the people working 
with me on D side have no professional experience in finance, but 
it didn't take long for them to get up to speed on my project 
which is maybe 120k SLOC plus some wrapping code.  I didn't have 
time or bandwidth to write comments or tests yet it was quite 
feasible to understand code without them.


On the other hand I was reading some object oriented C++ code of 
20k lines split between 200 files.  I just about read C++ so 
ceteris non paribus.  But the fragmentation and artificial 
abstraction makes it much harder to see what's going on and it's 
scarier to change it.  Plus template errors in C++! And that 20k 
lines is maybe 6k lines in 10 files in D.


I haven't always been super happy about using dub on Windows and 
like Manu said there is an energy gap introducing Windows 
colleagues to D.  Bad enough from C++, let alone C#.  However dub 
isn't worse than cmake - porting some windows C++ code to build 
on linux.


The keynote by the embedded device guy at last years c++ conf was 
spot on - if you're arguing you're losing.  Why should I use D? 
Well probably you shouldn't if you don't want to.  In fact in 
these cases you definitely shouldn't, whether you want to or not. 
 However some people find its brought them some benefits and here 
are some if the commonalities.


Some concrete examples that are true and essentially real might 
be a nice counterpart to the "quicksort in two lines" language 
evangelism that Andrei rightly complains about.


Maybe you have some from Weka.  Please ask Atila Neves if some 
finance examples might be helpful.  (Eg excel-d, which I started 
and Stefan and Atila finished).


One last thing.  D is a pretty good language for getting stuff 
done quickly in for a prototype that can be cleaned up quickly. 
That's a point Andy Smith made, and that Liran made in his talk 
also.  I am having to deal with that increasingly now.  I would 
certainly much rather turn a D prototype written by a trader into 
production than a python one - lets not speak of Matlab! This 
aspect is mentioned on website but should be hammered home - it's 
a practical language for getting started stuff done fast  without 
leaving a mess.

Re: Interpolated strings

[Nick Treleaven via Digitalmars-d]

On Wednesday, 19 April 2017 at 00:08:19 UTC, Walter Bright wrote:

There are additional problems, such as:

$"{a} in %s {b}"


% should be escaped: "%s in %%s %s". There would be no use for a 
single % otherwise.



and positional parameters:

$"{a} in {0}"


That would be literal 0: `"%s in %s", a, 0`. Could be disallowed 
but maybe not important.


Presumably braces would be escaped $"\{ \}" -> "{ }". Also having 
no {code} block in an interpolated string should be an error.


I like the simplicity of the lowering but it doesn't have much 
advantage over text(a, " in ", b), you still have to import a 
function. I suppose the advantage is readability for longer 
strings.


Also, there are compile-time tricks to make formatting more 
efficient with a compile time format string - e.g. format!"%s in 
%s"(true, null). Here format can know the length of the resulting 
string. With your lowering format can't receive the format string 
as a compile-time argument.

Re: Cap'n Proto for D v0.1.2

[Jacob Carlborg via Digitalmars-d-announce]

On 2017-04-18 23:08, Dmitry Olshansky wrote:


Risking a flamewar but what's wrong with Java?


I don't like any language that force me to write in a particular style 
or paradigm. Because all problems cannot be solved (or not in a good 
way) in the same way. That said, my D code is quite heavily influenced 
by Java.


--
/Jacob Carlborg