Re: The Expressive C++17 Coding Challenge in D

[Walter Bright via Digitalmars-d-announce]

On 2/13/2018 3:35 PM, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread today and I thought 
this is an excellent opportunity to revive my blog and finally write an article 
showing why I like D so much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D features, but maybe 
it's helpful for beginners looking into D.


Very nice article, you write well!

Re: dxml 0.2.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Thursday, February 15, 2018 01:55:28 rikki cattermole via Digitalmars-d-
announce wrote:
> On 14/02/2018 5:13 PM, Jonathan M Davis wrote:
> > On Wednesday, February 14, 2018 14:09:21 rikki cattermole via
> > Digitalmars-d->
> > announce wrote:
> >> On 14/02/2018 2:02 PM, Adrian Matoga wrote:
> >>> On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole 
wrote:
>  See lines:
>  - Input!IR temp = input;
>  - input = temp;
> 
>  bool commentLine() {
> 
>   Input!IR temp = input;
> 
>  (...)
> 
>   if (!temp.empty) {
> 
>  (...)
> 
>   input = temp;
>   return true;
> 
>   } else
> 
>   return false;
> 
>   }
> >>>
> >>> `temp = input.save` is exactly what you want here, which means forward
> >>> range is required. Your example won't work for range objects with
> >>> reference semantics.
> >>
> >> Ah I must be thinking of ranges that support indexing.
> >
> > Random access ranges are also forward ranges and would require a call to
> > save here.
> >
> > - Jonathan M Davis
>
> Luckily in my code I can forget that ;)

LOL. That's actually part of what makes writing range-based libraries so
much harder to get right than simply using ranges in your program. When a
piece of code is used with only a few types of ranges (or even only one type
of range, as is often the case), then it's generally not very hard to write
code that works just fine, but as soon as you have to worry about arbitrary
ranges, you get all kinds of nonsense that you have to worry about in order
to make sure that the code works correctly for any range that's passed to
it. save is the classic example of something that a lot of range-based code
gets wrong, because for most ranges, it really doesn't matter, but for those
ranges where it does, a single missed call to save results in code that
doesn't work properly. To get it right, you basically have to call save
every time you pass a range to a range-based function that is not supposed
to consume the range, and folks rarely get that right. Certainly, pretty
much any range-based code that doesn't have unit tests which include
reference-type ranges is going to be wrong for reference-type ranges. Even
Phobos has had quite a few issues with that historically.

- Jonathan M Davis

Re: dxml 0.2.0 released

[rikki cattermole via Digitalmars-d-announce]

On 14/02/2018 5:13 PM, Jonathan M Davis wrote:

On Wednesday, February 14, 2018 14:09:21 rikki cattermole via Digitalmars-d-
announce wrote:

On 14/02/2018 2:02 PM, Adrian Matoga wrote:

On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole wrote:

See lines:
- Input!IR temp = input;
- input = temp;

bool commentLine() {
 Input!IR temp = input;

(...)
 if (!temp.empty) {
(...)
 input = temp;
 return true;
 } else
 return false;
 }


`temp = input.save` is exactly what you want here, which means forward
range is required. Your example won't work for range objects with
reference semantics.


Ah I must be thinking of ranges that support indexing.


Random access ranges are also forward ranges and would require a call to
save here.

- Jonathan M Davis



Luckily in my code I can forget that ;)

Re: The Expressive C++17 Coding Challenge in D

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 20:37:24 UTC, bachmeier wrote:

There's (almost) no such thing as bad publicity...


Programming languages and operating systems have a long history 
of hot advocacy...  not sure how it relates to adoption, but it 
affects perception.


E.g. vocal mac users gave the mac a certain (not so great) 
reputation in tech circles. I don't think that perception changed 
till iOs and mac mini.

Re: The Expressive C++17 Coding Challenge in D

[bachmeier via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 20:14:41 UTC, Ola Fosheim 
Grøstad wrote:

On Wednesday, 14 February 2018 at 19:40:12 UTC, Seb wrote:

https://www.reddit.com/r/programming/comments/7xih66/the_expressive_c17_coding_challenge_in_d


It is getting shot down…


That's implied when someone says it's posted on Reddit.

There's (almost) no such thing as bad publicity...

Re: The Expressive C++17 Coding Challenge in D

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 19:40:12 UTC, Seb wrote:

https://www.reddit.com/r/programming/comments/7xih66/the_expressive_c17_coding_challenge_in_d


It is getting shot down…

Re: The Expressive C++17 Coding Challenge in D

[Seb via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 18:55:23 UTC, bachmeier wrote:

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Someone posted a comment in our subreddit that you may want to 
check:

https://www.reddit.com/r/d_language/comments/7xi9n3/the_expressive_c17_coding_challenge_in_d/


Thanks a lot for the ping!
Someone posted it also to /r/programming - it's on the second 
place as of now:


https://www.reddit.com/r/programming/comments/7xih66/the_expressive_c17_coding_challenge_in_d

Re: The Expressive C++17 Coding Challenge in D

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 18:33:33 UTC, Jacob Carlborg 
wrote:

On 2018-02-14 19:00, Ola Fosheim Grøstad wrote:
For a fair comparison Swift should only use libraries that are 
available both on macOS and Linux.


Are any projects using Swift outside of the Mac eco system?
Would it be more fair if Swift was Mac only? (re Visual Basic)

Would you include React when evaluating Javascript and Angular4 
when evaluating TypeScript? Why should a standard library be 
evaluated differently from any other library?


That's more the issue.

If the standard library for one language ensure better interop 
between third party libraries, then it becomes significant, but 
if it is an independent feature then I see no difference between 
standard library and third party library.

Re: The Expressive C++17 Coding Challenge in D

[bachmeier via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Someone posted a comment in our subreddit that you may want to 
check:

https://www.reddit.com/r/d_language/comments/7xi9n3/the_expressive_c17_coding_challenge_in_d/

Re: The Expressive C++17 Coding Challenge in D

[Jacob Carlborg via Digitalmars-d-announce]

On 2018-02-14 19:00, Ola Fosheim Grøstad wrote:

For instance, Swift drags in all of Os-X on the default platform, so 
writing an audio/video loader would be relatively short in comparison to 
other languages. Would that be fair or instructive? Of course not. The 
Os-X libraries are quite massive.


For a fair comparison Swift should only use libraries that are available 
both on macOS and Linux.


--
/Jacob Carlborg

Re: The Expressive C++17 Coding Challenge in D

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 17:13:28 UTC, John Gabriele 
wrote:
But even then, I don't think you should discount or put off 
using std.csv as "cheating".


Yes and no.  The problem with all these exercises is that they 
say nothing about the language and a lot about some default 
library, which isn't particularly revealing.


For instance, Swift drags in all of Os-X on the default platform, 
so writing an audio/video loader would be relatively short in 
comparison to other languages. Would that be fair or instructive? 
Of course not. The Os-X libraries are quite massive.


Anyway, these kinds of exercises are only impressive for people 
looking for an alternative to scripting...


For general system programming you need to show off the language 
and not the esoteric features of the standard library. Basically 
show off how it can deal with a task it has not been designed 
for. Which is the typical use scenario.

Re: The Expressive C++17 Coding Challenge in D

[Seb via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 17:13:28 UTC, John Gabriele 
wrote:

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Great article! Thank you!


Thanks for the typos. Fixed them.

But even then, I don't think you should discount or put off 
using std.csv as "cheating". I'm guessing std.csv handles 
things like quoted elements containing commas.


Yes.

I realize that maybe you're being pedagogic and wanting to show 
off D's File byLine and splitter,


Yes.

but I think the first thing a reader will think when they see 
you rolling your own csv reader by hand is that something must 
be wrong with D or it's ecosystem if you're resorting to this, 
and they'll run for the hills (especially in an intro article, 
*and* one in which you point out that the goal is *expressive* 
code).


Understood. Fair point.
I changed the motivation of why std.csv isn't used and added a 
warning that one shouldn't roll one's own CSV parser.


I immediately assume it's either old/incorrect, the language is 
very low-level only, or else maybe the language's std lib must 
be impoverished.


Haha. This could be Rust's or C++'s new slogan ;-)

Re: The Expressive C++17 Coding Challenge in D

[John Gabriele via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Great article! Thank you!

Typo: "and finally format bundles" --> "and finally std.format 
bundles".


Another typo: "In the latter article I will also present a 
solution which only uses 12 lines, but it uses the built-in 
std.csv module and I think D doesn’t even need to cheat." should 
probably instead start "Later in this article I'll also 
present..." or "Further down I'll also present".


But even then, I don't think you should discount or put off using 
std.csv as "cheating". I'm guessing std.csv handles things like 
quoted elements containing commas. I realize that maybe you're 
being pedagogic and wanting to show off D's File byLine and 
splitter, but I think the first thing a reader will think when 
they see you rolling your own csv reader by hand is that 
something must be wrong with D or it's ecosystem if you're 
resorting to this, and they'll run for the hills (especially in 
an intro article, *and* one in which you point out that the goal 
is *expressive* code).


In fact, I'd go so far as to say that, when searching online for 
how to read in a csv file for a given language (see many examples 
at ), if the 
example involves splitting on commas, I immediately assume it's 
either old/incorrect, the language is very low-level only, or 
else maybe the language's std lib must be impoverished.

Re: dxml 0.2.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Wednesday, February 14, 2018 14:09:21 rikki cattermole via Digitalmars-d-
announce wrote:
> On 14/02/2018 2:02 PM, Adrian Matoga wrote:
> > On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole wrote:
> >> See lines:
> >> - Input!IR temp = input;
> >> - input = temp;
> >>
> >>bool commentLine() {
> >> Input!IR temp = input;
> >>
> >> (...)
> >> if (!temp.empty) {
> >> (...)
> >> input = temp;
> >> return true;
> >> } else
> >> return false;
> >> }
> >
> > `temp = input.save` is exactly what you want here, which means forward
> > range is required. Your example won't work for range objects with
> > reference semantics.
>
> Ah I must be thinking of ranges that support indexing.

Random access ranges are also forward ranges and would require a call to
save here.

- Jonathan M Davis

Re: The Expressive C++17 Coding Challenge in D

[Dukc via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 14:17:31 UTC, Seb wrote:

changed the text to:

...and D even supports native interoperability with C and most 
of C++.


Great!

Re: Mir Random v0.3.6 and v0.4.0

[9il via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 15:14:22 UTC, 9il wrote:

Docs: http://docs.algorithm.dlang.io/latest/index.html


http://docs.random.dlang.io/latest/index.html

Mir Random v0.3.6 and v0.4.0

[9il via Digitalmars-d-announce]

mir-random

Advanced Random Number Generators.
Mir Random can be used as betterC library or with 
default/different thread local random engines.


Mir Random v0.4.0
 1. default params from random variable constructors was removed
 2. convention functions for random variable construction were 
added

 3. `randomSlice` was added to `mir.random.algorithm`
 4. `field` API rework for complex numbers
 5. default engine `rne` was added to some algorithms

Mir Random v0.3.6
 Fixed Bugs:
  Wrong double generation with 32bit DMD.

Acknowledgements
  Nathan Sashihara
  Sebastian Wilzbach

Docs: http://docs.algorithm.dlang.io/latest/index.html
Try online: https://tour.dlang.org/tour/en/dub/mir-random
(the example can be simplified since v0.4.0)

Best Regards,
Ilya Yaroshenko

Re: The Expressive C++17 Coding Challenge in D

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 10:17:21 UTC, psychoticRabbit 
wrote:
I believe the programming langauges of the future, and the ones 
people should invest their time learning, are those that can be 
best understood in the least amount of time.


Yes, I would say so, unless they bring something new to the table 
like formal verification (proven correctness) or some kind of 
expert system geared towards a set of common domains (e.g. data 
flow).


This is because programs are getting larger and more complex, 
and to understand them at all, they have to be simple to 
understand.


Right, so which is an argument in favour of agent based systems. 
Kind of the direction that has happened on the server side with 
micro services.


C++ is not simple. It never has been. The so called 
'modernisation' of it is not helping me to change my mind about 
it ;-)


Right, because, even though C was simple, it isn't simple to 
debug, so C++ has all that + a wide variety of overlapping 
features. So C++ cannot become simple.


It's time to stop 'improving' C++ and redesign it from scratch 
- or move to D.


Well, yes, but then D needs to make a case for itself and do a 
reset so that the disadvantages in switching is offset by the 
advantages. Either that or some other language will squeeze in, 
which is ok too. I don't care who does it, could even be Rust if 
they add some features, but it should happen. Right.

Re: cblas, lapack, mir-blas, mir-lapack update

[jmh530 via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 14:24:25 UTC, 9il wrote:

[snip]


Great.

Re: The Expressive C++17 Coding Challenge in D

[Russel Winder via Digitalmars-d-announce]

On Wed, 2018-02-14 at 13:21 +, Seb via Digitalmars-d-announce
wrote:
> On Wednesday, 14 February 2018 at 09:42:47 UTC, Russel Winder 
> wrote:
> > Seb,
> > 
> > I believe this blog post would make a great article for 
> > Overload or CVu.
> 
> Cool idea, but I'm not so familiar with these. What can/should I 
> do to make this happen?
> We can also talk in private (seb [at] wilzba [dot] ch).

For the email list record, CVu and Overload are the ACCU journals.
Historically Overload has been a C++ language, tools, and techniques
vehicle put is now adding detailed technical articles on other
languages. CVu has anything else, including some technical stuff.

https://accu.org/index.php/journal

Seb and I have started a personal email exchange and I am getting the
editors of said journals involved.
 
-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

cblas, lapack, mir-blas, mir-lapack update

[9il via Digitalmars-d-announce]

cblas v2.0.1.
 - Fixed aliases for i?max.
 - API was marked as pure.

lapack v0.0.3
 - sysv_rook was added
 - API was marked as pure.

mir-blas v0.1.0
 - ger, scal, swap, asum, scal, copy, axpy wrappers for ndslice 
were added


mir-lapack v0.0.5
 - sysv_rook wrapper for ndslice was added

A lot of new API is coming to lubeck, mir-lapack, and 
mir-algorithm this month.


This work has been sponsored by Symmetry Investments and Kaleidic 
Associates.


https://github.com/kaleidicassociates
http://symmetryinvestments.com

Best regards,
Ilya Yaroshenko

Re: The Expressive C++17 Coding Challenge in D

[Seb via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 08:06:13 UTC, Mike Franklin 
wrote:

Aren’t you concered that Rust is faster in this benchmark?


Not at all. The challenge was to write expressive code and if 
performance really matters I can always opt to optimize the 
hot path of the program and don’t need to pay a > 4x code 
duplication cost upfront.


You've gotta address this, IMO.  What's the 
performance/expressiveness tradeoff like in D?


Mike


Good point. I tried to address this and changed the text to:


Not at all. The challenge was to write expressive code. When 
performance really matters D provides the same tools as C or 
C++ and D even supports native interoperability with C and most 
of C++.


In this example, however, I/O is the bottleneck and D provides 
a few convenience features like using locked file handles, s.t. 
accessing files is thread-safe by default, or supporting 
unicode input. However, it’s easy to opt out of such 
productivity features and for the interested readers I have 
attached a slightly optimized version at the end.

Re: dxml 0.2.0 released

[rikki cattermole via Digitalmars-d-announce]

On 14/02/2018 2:02 PM, Adrian Matoga wrote:

On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole wrote:

See lines:
- Input!IR temp = input;
- input = temp;

   bool commentLine() {
    Input!IR temp = input;

(...)
    if (!temp.empty) {
(...)
    input = temp;
    return true;
    } else
    return false;
}


`temp = input.save` is exactly what you want here, which means forward 
range is required. Your example won't work for range objects with 
reference semantics.


Ah I must be thinking of ranges that support indexing.

Re: dxml 0.2.0 released

[Adrian Matoga via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 10:57:26 UTC, rikki cattermole 
wrote:

See lines:
- Input!IR temp = input;
- input = temp;

   bool commentLine() {
Input!IR temp = input;

(...)
if (!temp.empty) {
(...)   
input = temp;
return true;
} else
return false;
}


`temp = input.save` is exactly what you want here, which means 
forward range is required. Your example won't work for range 
objects with reference semantics.

Re: The Expressive C++17 Coding Challenge in D

[Seb via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 09:42:47 UTC, Russel Winder 
wrote:

Seb,

I believe this blog post would make a great article for 
Overload or CVu.


Cool idea, but I'm not so familiar with these. What can/should I 
do to make this happen?

We can also talk in private (seb [at] wilzba [dot] ch).

Re: dxml 0.2.0 released

[rikki cattermole via Digitalmars-d-announce]

On 14/02/2018 10:32 AM, Jonathan M Davis wrote:

On Wednesday, February 14, 2018 10:14:44 Kagamin via Digitalmars-d-announce
wrote:

It looks like EntityRange requires forward range, is it ok for a
parser?


It's very difficult in general to write a parser that isn't at least a
forward range, because without that, you're stuck at only one character of
look ahead unless you play a lot of games with putting data from the input
range in a buffer so that you can keep it around to look at it again after
you've looked farther ahead.

Honestly, pure input ranges are borderline useless for a _lot_ of cases.
It's generally only the cases where you only care about operating on each
element individually irrespective of what's going on with other elements in
the range that pure input ranges are really useable, and parsing definitely
doesn't fall into that camp.

- Jonathan M Davis


See lines:
- Input!IR temp = input;
- input = temp;

   bool commentLine() {
Input!IR temp = input;

if (!temp.empty && temp.front.c == '/') {
temp.popFront;
if (!temp.empty && temp.front.c == '/')
temp.popFront;
else
return false;
} else
return false;

if (!temp.empty) {
size_t endOffset = temp.front.location.fileOffset;

while(temp.front.location.lineOffset != 0) {
endOffset = temp.front.location.fileOffset;
temp.popFront;

if (temp.empty) {
endOffset++;
break;
}
}

current.type = Token.Type.Comment_Line;
current.location = input.front.location;
current.location.length = endOffset - 
input.front.location.fileOffset;

input = temp;
return true;
} else
return false;
}

Re: The Expressive C++17 Coding Challenge in D

[Dukc via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much


I first looked into C++ and Rust examples, just quickly without 
thinking them deeply. I thought that wow, the problem is probably 
more complicated than it looks. Seems to need many functions to 
solve eleganty.


Then when I saw your example I, of course, concluded that the 
problem is as simple as it seems. I would really have excepted 
C++ or at least Rust to come close to D, perhaps even achieve the 
same LoC count with a bit of luck.


Excellent article all-in-all, because it shown so many D features 
in a compact AND realistic way. I think a good D programmer might 
well write programs in that style for everyday use, not just for 
show. If someone asks "what would then be an unrealistic program 
then" it would be one that excessively uses introspection.


One improvement proposal: in the "Other features" part, you 
mention full compatibility with c. I think you should add "and 
with most of c++" because it might be a killer feature for some 
potential users.

Re: dxml 0.2.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Wednesday, February 14, 2018 10:14:44 Kagamin via Digitalmars-d-announce 
wrote:
> It looks like EntityRange requires forward range, is it ok for a
> parser?

It's very difficult in general to write a parser that isn't at least a
forward range, because without that, you're stuck at only one character of
look ahead unless you play a lot of games with putting data from the input
range in a buffer so that you can keep it around to look at it again after
you've looked farther ahead.

Honestly, pure input ranges are borderline useless for a _lot_ of cases.
It's generally only the cases where you only care about operating on each
element individually irrespective of what's going on with other elements in
the range that pure input ranges are really useable, and parsing definitely
doesn't fall into that camp.

- Jonathan M Davis

Re: dxml 0.2.0 released

[Chris via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 22:13:36 UTC, H. S. Teoh wrote:



Ironically, the general advice I found online w.r.t XML 
vulnerabilities is "don't allow DTDs", "don't expand entities", 
"don't resolve externals", etc..  There also aren't many XML 
parsers out there that fully support all the features called 
for in the spec.  IOW, this basically amounts to "just use dxml 
and forget about everything else". :-D


Now of course, there *are* valid use cases for DTDs... but a 
naïve implementation of the spec is only going to end in tears.
 My current inclination is, just merge dxml into Phobos, then 
whoever dares implement DTD support can do so on top of dxml, 
and shoulder their own responsibility for vulnerabilities or 
whatever.  (I mean, seriously, just for the sake of being able 
to say "my XML is validated" we have to implement network 
access, local filesystem access, a security framework, and what 
amounts to a sandbox to control pathological behaviour like 
exponentially recursive entities?  And all of this, just to 
handle rare corner cases?  That's completely ridiculous.  It's 
an obvious design smell to me.  The only thing missing from 
this poisonous mix is Turing completeness, which would have 
made XML hackers' heaven.  Oh wait, on further googling, I see 
that XSLT *is* Turing complete.  Great, just great.   Now I 
know why I've always had this gut feeling that *something* is 
off about the whole XML mania.)



T


Thanks for the analysis. I'd say you're right. It makes no sense 
to keep dxml from becoming std.xml's successor only because it 
doesn't support DTDs. Also, as I said before, if we had DTD 
support in std.xml, people would complain about the lack of 
efficiency, and the discussion about interpreting the specs 
correctly, implementing them 100%, complaints about the lack of 
security would just never end.

Re: The Expressive C++17 Coding Challenge in D

[psychoticRabbit via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 09:50:31 UTC, Ola Fosheim 
Grøstad wrote:


If C++ isn't viewed as a competitor, why bother with repetitive 
complaining about C++?


Because it doesn't get enough criticism ;-)

I believe the programming langauges of the future, and the ones 
people should invest their time learning, are those that can be 
best understood in the least amount of time.


This is because programs are getting larger and more complex, and 
to understand them at all, they have to be simple to understand.


C++ is not simple. It never has been. The so called 
'modernisation' of it is not helping me to change my mind about 
it ;-)


And chances are, when you go to work in some C++ environment, 
you'll have to deal with lots of legacy style code - which you 
will be expected to understand as well.


It's time to stop 'improving' C++ and redesign it from scratch - 
or move to D.

Re: dxml 0.2.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Wednesday, February 14, 2018 10:03:45 Patrick Schluter via Digitalmars-d-
announce wrote:
> On Tuesday, 13 February 2018 at 22:00:59 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, February 13, 2018 21:18:12 Patrick Schluter via
> >
> > Digitalmars-d- announce wrote:
> >> [...]
> >
> > Well, if dxml just passes the entity references along unparsed
> > beyond validating that the entity reference itself contains
> > valid characters (e.g. it's not something like &.; or & by
> > itself), then dxml would still not be replacing the entity
> > references with anything. Any security or performance problems
> > associated with entity references would be left up to whatever
> > parser parsed the DTD section and then used dxml to parse the
> > rest of the XML and replaced the entity references in dxml's
> > parsing results with whatever they were.
> >
> > The big problem is how the entity references affect the
> > parsing. If start tags can be dropped in and affect the parsing
> > (and it's still not clear to me from the spec whether that's
> > legal - there is a section talking about being nested properly
> > which might indicate that that's not legal, but it's not very
> > specific or clear), and if it's legal to do something like use
> > an entity reference for a tag name - e.g. <>, then that's
> > a serious problem. And problems like that are the main reason
> > why I completely dropped any attempt to do anything with the
> > DTD section.
>
> Yikes! In any case, even if I had to implement a parser I would
> tend to not implement this "feature" as it sounds quite
> unreasonable. Only if a real need (i.e. one in the real world,
> not one that could be contrived out of the specs) arises would I
> then potentially implement the real deal.

Well, since folks other than me are going to use this parser, and it's even
potentially going to end up in D's standard library, it needs to at least be
good enough to not let through invalid XML or incorrectly interpret any XML.
It can potentially not support portions of the spec as long as it does so in
a clear and clean manner, but it's going to have to correctly handle
anything that it does handle.

For better or worse, I'm the sort of person who prefers to completely
implement a spec when I'm implementing one, but in this case, it wasn't
really reasonable. Fortunately however, from the perspective of implementing
something that's useful for me personally, the DTD section is completely
unnecessary. From that perspective, processing instructions and CDATA
sections are also unnecessary, since I'd never do anythnig with them, but I
don't think that it would be reasonable to skip those, so they're
implemented. And it's not like they're hard to implement support for, unlike
the DTD section.

- Jonathan M Davis

Re: dxml 0.2.0 released

[Kagamin via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 22:29:27 UTC, H. S. Teoh wrote:

- provide some way of hooking into non-default entities so that
  DTD-defined entities can be expanded by the DTD 
implementation.


The parser now returns raw text, entity replacement can be done 
by DTD processor without any modification of API. So it's good 
for experimental if there's incentive to maintain it, but it's 
purely PR problem: there's nothing wrong in having xml support in 
dub registry and std.xml in phobos, if phobos is ok with it, it 
can stay as is.
It looks like EntityRange requires forward range, is it ok for a 
parser?

Re: dxml 0.2.0 released

[Patrick Schluter via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 22:00:59 UTC, Jonathan M Davis 
wrote:
On Tuesday, February 13, 2018 21:18:12 Patrick Schluter via 
Digitalmars-d- announce wrote:

[...]


Well, if dxml just passes the entity references along unparsed 
beyond validating that the entity reference itself contains 
valid characters (e.g. it's not something like &.; or & by 
itself), then dxml would still not be replacing the entity 
references with anything. Any security or performance problems 
associated with entity references would be left up to whatever 
parser parsed the DTD section and then used dxml to parse the 
rest of the XML and replaced the entity references in dxml's 
parsing results with whatever they were.


The big problem is how the entity references affect the 
parsing. If start tags can be dropped in and affect the parsing 
(and it's still not clear to me from the spec whether that's 
legal - there is a section talking about being nested properly 
which might indicate that that's not legal, but it's not very 
specific or clear), and if it's legal to do something like use 
an entity reference for a tag name - e.g. <>, then that's 
a serious problem. And problems like that are the main reason 
why I completely dropped any attempt to do anything with the 
DTD section.


Yikes! In any case, even if I had to implement a parser I would 
tend to not implement this "feature" as it sounds quite 
unreasonable. Only if a real need (i.e. one in the real world, 
not one that could be contrived out of the specs) arises would I 
then potentially implement the real deal.

Re: The Expressive C++17 Coding Challenge in D

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 09:28:48 UTC, psychoticRabbit 
wrote:
yeah.. even the more modern C++ code still makes me want to 
stay clear of it...(perhaps even more so).


I just never get the same feeling when I look at D programs.


I get the same feeling from both languages, to be honest.  
Average library code for both languages are harder to read than I 
think should be the norm (granted Python libs can also be 
somewhat hard to read, but still much easier on average).  Both 
languages are easier to read when you spend time with them 
yourself, obviously.  Both languages are easier to read when the 
programmer has been conservative in his/her use of features.


This situation is what happens when you add features at a high 
rate in the early years and don't want to clean up because of 
backwards compatibility. C++ has been at it for longer and are 
adding more features at a higher rate than D... so C++ becomes 
harder and harder to master if you read other people's arbitrary 
code. That doesn't mean D shouldn't clean up... I'd say it is 
necessary to get ahead.


For both languages you can always stick to your own idioms and 
write cleaner code than you see on github, and blog posts tend to 
be feature-show-offs (surprisingly often written by people who 
don't write a lot of code in the language they are posting about) 
so I don't think blogs are the right measure. Look at large code 
bases that are in widespread use to get an idea of what happens 
over time in terms of maintainability.


Anyway, C++ at this point has slightly better lambdas than D and 
D will notice the competition if C++ ends up adding stackless 
coroutines (e.g. Python like generators). Not a big discrepancy 
in features at this point, but C++ is moving at a higher rate... 
and that should be a concern if C++ is viewed as a competitor.


If C++ isn't viewed as a competitor, why bother with repetitive 
complaining about C++?

Re: The Expressive C++17 Coding Challenge in D

[Martin Tschierschke via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Very nice read!!! Thank you!


One "typo?" Chapter 8)

same format function that would normally be called at 
compile-time

 s/compile/run/

It would be good to say a little more about the '!' ct-parameter

At fist when reading D code coming from ruby (after, 
php,...C++,C, Pascal...),
I thought, that the ! is like in Ruby just an way to distinguish 
between a function modifying the contend or not (compare gsub to 
gsub!) it took sometime before this important bit came clear to 
me.
So just something, like functions in D may have two parameter 
brackets:

One for compile-time and one for run-time parameters:
fun!(ctParam)(rtParam) ... short fun!(cParam)() ... fun!ctparam

Other point:

Showing some more alternative D solutions for the same problem, 
might be a little contest in this thread, just post your shorter 
and better solutions :-)

Re: The Expressive C++17 Coding Challenge in D

[Russel Winder via Digitalmars-d-announce]

Seb,

I believe this blog post would make a great article for Overload or
CVu.

On Tue, 2018-02-13 at 23:35 +, Seb via Digitalmars-d-announce
wrote:
> Someone revived the Expressive C++17 Coding Challenge thread 
> today and I thought this is an excellent opportunity to revive my 
> blog and finally write an article showing why I like D so much:
> 
> https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-i
> n-d
> 
> It's mostly targeted at beginners as I explain many basic D 
> features, but maybe it's helpful for beginners looking into D.
-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: The Expressive C++17 Coding Challenge in D

[psychoticRabbit via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 08:53:31 UTC, drug wrote:

14.02.2018 11:45, Ola Fosheim Grøstad пишет:

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to 
revive my blog and finally write an article showing why I 
like D so much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Sadly, he just picked the solution that used most C++17 
features and not one that was clean and compact... :-/


I guess the point was to create a C++17 tutorial, and not a 
coding contest as such.


It's sadly that using most C++17 features fails to provide 
clean and compact solution...


yeah.. even the more modern C++ code still makes me want to stay 
clear of it...(perhaps even more so).


I just never get the same feeling when I look at D programs.

Re: The Expressive C++17 Coding Challenge in D

[Arredondo via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Down in the 'Other cool D features' you have:


* Inline documentation
* Contracts
...
* Built-in documentation
* Contracts and invariants


Nice read!

Re: The Expressive C++17 Coding Challenge in D

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 08:53:31 UTC, drug wrote:
It's sadly that using most C++17 features fails to provide 
clean and compact solution...


I don't usually use iostream, but this "challenge" was a 
reasonable fit for it. If you look over the 4 submissions then 
the iostream one provides the best encapsulation of the problem:


http://coliru.stacked-crooked.com/a/4675a74c8124750f

C++ blogposts tend to choke on features... usually not good 
examples of maintainable code.

Re: The Expressive C++17 Coding Challenge in D

[drug via Digitalmars-d-announce]

14.02.2018 11:45, Ola Fosheim Grøstad пишет:

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread today and 
I thought this is an excellent opportunity to revive my blog and 
finally write an article showing why I like D so much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D features, 
but maybe it's helpful for beginners looking into D.


Sadly, he just picked the solution that used most C++17 features and not 
one that was clean and compact... :-/


I guess the point was to create a C++17 tutorial, and not a coding 
contest as such.


It's sadly that using most C++17 features fails to provide clean and 
compact solution...

Re: The Expressive C++17 Coding Challenge in D

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Sadly, he just picked the solution that used most C++17 features 
and not one that was clean and compact... :-/


I guess the point was to create a C++17 tutorial, and not a 
coding contest as such.

Re: The Expressive C++17 Coding Challenge in D

[Simen Kjærås via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Nice! Good overview of many of the good things in D.

Nitpicks:

I used the following rdmd script to generate a simple CSV file 
with 10 fields and 10m lines:


rdmd --eval='10.iota.map!(a=> "field".text(a)).join(",")
.repeat(10_00_000).joiner("\n").writeln' > input_big.csv


10_00_000 should probably be 10_000_000.


They are only view on the actual memory and you don’t copy the 
array, but just the view on (in D it’s called a slice).


Missing some words here: "only *a* view". "but just the view on" 
seems to be missing the second half of the sentence.



There's also a few typos: 'vauge' should be 'vague', 'it 
providers' should be 'it provides', 'shot yourself in the feet' 
should probably be 'shoot yourself in the foot'


Thanks for writing all this - it's a great intro to the language.

--
  Sien

Re: D compiler daily downloads at an all-time high

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

On 02/13/2018 01:15 PM, Dmitry Olshansky wrote:

On Monday, 12 February 2018 at 15:20:29 UTC, Martin Tschierschke wrote:

On Monday, 16 November 2015 at 15:20:51 UTC, Andrei

Congratulations to everybody who co

Andrei

Old post but new numbers!

http://erdani.com/d/downloads.daily.png

Would be nice to know what caused the recent spike to >8000?
Are there any other usage stats available? For dlang.org or 
code.dlang.org ?


Regards mt.


When I see spikes like that out of nowhere that it’s usually some 
automation kicking in. Could it be a new CI that we didn’t account for yet?


Secretly hope it’s a fresh wave of D users though ;)


A totally botched DoS attempt? ;) I'll assume no ;)

Re: The Expressive C++17 Coding Challenge in D

[Mike Franklin via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Nice work!  I was recently asked by my employer "why D?".  I 
think I need to show them this.



Aren’t you concered that Rust is faster in this benchmark?


Not at all. The challenge was to write expressive code and if 
performance really matters I can always opt to optimize the hot 
path of the program and don’t need to pay a > 4x code 
duplication cost upfront.


You've gotta address this, IMO.  What's the 
performance/expressiveness tradeoff like in D?


Mike