Re: dxml 0.2.0 released

[Aravinda VK via Digitalmars-d-announce]

On Monday, 12 February 2018 at 05:36:51 UTC, Jonathan M Davis 
wrote:

dxml 0.2.0 has now been released.

I really wasn't planning on releasing anything this quickly 
after announcing dxml, but when I went to start working on DOM 
support, it turned out to be surprisingly quick and easy to 
implement. So, dxml now has basic DOM support.


As part of that, it became clear that dxml.parser.stax should 
be renamed to dxml.parser, since it's really the only parser 
(DOM support involves just providing a way to hold the results 
of the parser, not any actual parsing, and that's clear from 
the API rather than being an implementation detail), and it 
makes for a shorter import path. So, I figured that I should do 
a release sooner rather than later to reduce how many folks the 
rename ends up affecting.


For this release, dxml.parser.stax is now an empty, deprecated, 
module that publicly imports dxml.parser, but it will be 
removed in 0.3.0, whenever that is released. So, the few folks 
who grabbed the initial release won't end up with immediate 
code breakage if they upgrade.


One nice side effect of how I implemented DOM support is that 
it's trivial to get the DOM for a portion of an XML document 
rather than the entire thing, since it will produce a DOMEntity 
from any point in an EntityRange.


Documentation: http://jmdavisprog.com/docs/dxml/0.2.0/
Github: https://github.com/jmdavis/dxml/tree/v0.2.0
Dub: http://code.dlang.org/packages/dxml

- Jonathan M Davis


Awesome. Just tried it now as below and it works. Thanks for this 
library


import std.stdio;

import dxml.dom;

struct Record
{
string name;
string email;
}


Record[] parseRecords(string xml)
{
Record[] records;
auto d = parseDOM!simpleXML(xml);
auto root = d.children[0];

foreach(record; root.children)
{
auto rec = Record();
foreach(ele; record.children)
{
if (ele.name == "name")
rec.name = ele.children[0].text;
if (ele.name == "email")
rec.email = ele.children[0].text;
}
records ~= rec;
}

return records;
}

void main()
{
auto xml = "\n" ~
"\n" ~
"N1\n" ~
"E1\n" ~
"\n" ~
"\n" ~
"N2\n" ~
"E2\n" ~
"\n" ~
"\n" ~
"E3\n" ~
"N3\n" ~
"\n" ~
"\n" ~
"";
auto records = parseRecords(xml);
writeln(records);
}

Re: Vanquish Forever These Bugs That Blasted Your Kingdom

[Cym13 via Digitalmars-d-announce]

On Monday, 12 February 2018 at 04:30:38 UTC, psychoticRabbit 
wrote:

On Sunday, 11 February 2018 at 15:18:20 UTC, Cym13 wrote:


On the other hand, if my bank shoots itself in the foot it's 
with my money... We must definitely have ways to do it but it 
must be explicit and restricted to where it's useful. There is 
no need for -boundscheck=off in D. It is always possible to 
disable boundschecking locally, and that's a good thing.


When was the last time a bank lost customers money due not 
checking bounds?


It's far, far more likely you'll lose your money due to their 
dodgy lending practices (as many have already experienced).


As someone who's job is to audit banking and governmental systems 
for security vulnerabilities, I can assure you it's a real issue. 
Not the most common one, okay, but that doesn't make it any less 
dangerous.

rmdirRecurse - on NFS file system

[Vino via Digitalmars-d-learn]

Hi All,

   Request your help, the below code works find on normal File 
system, bu if the file system is a NFS file system the below 
code, is not working


if Step = dryrun( Display Only) : Works for both NFS and normal 
file system.
if Step = run (Delete folder) : Does not work on NFS file system 
but works on normal file system.

No error message.

auto coAgedDirClean (string FFs, string Step, int AgeSize) {
auto cAges = AgeSize
auto dFiles = Array!(Tuple!(string, SysTime))(dirEntries(FFs, 
SpanMode.shallow).filter!(a => a.isDir && !globMatch(a.baseName, 
"*DND*") && a.timeCreated < cAges).map!(a => tuple(a.name, 
a.timeCreated)));
if (Step == "run") { dFiles.each!(f => f[0].rmdirRecurse); } 
return dFiles;

}

From,
Vino.B

Re: Adjacent item in a array

[Vino via Digitalmars-d-learn]

On Saturday, 3 February 2018 at 22:58:04 UTC, Vino wrote:

On Saturday, 3 February 2018 at 19:28:01 UTC, Seb wrote:

On Saturday, 3 February 2018 at 19:13:05 UTC, Vino wrote:

[...]


2.079 [1, 2] will ship with slide:

---
auto arr = ["T1", "T2", "T3", "T4", "T5"];
arr.slide(2).each!writeln;
---

[...]


Hi Seb;

  Thank you very much.

From,
Vino.B


Hi Seb,

 Was going through the change log of version v2.079, and it has 
most of the function that I require, so hope the release date of 
v2.079 would be 1st/March, correct me if i am wrong.


From,
Vino.B

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/11/2018 09:01 PM, Jonathan M Davis wrote:

On Sunday, February 11, 2018 20:30:19 Nick Sabalausky  via Digitalmars-d
wrote:

The langauge-based package managers just simply need to keep
"buildsystem" OUT of the package manager's scope. That's all. THAT is
why system-level packages can be built with whatever tool: because the
one thing the system package managers actually do get right is NOT
rolling their own mandatory buildsystem.


I'm not sure that it's entirely a bad thing that dub includes a build system
in it, since it's the ease of use of its build system that is part of why
it's so worth using. It's just that its simplicity is also part of why it
doesn't work well once you get out of the basic situation of "here's a group
of D files that need to be compiled together as a library or application."


You're right, of course. I guess I wasn't clear about this, and frankly 
I even lost sight of it, but if it HAD been easy and clear to just say 
"hey, dub, I'm bringing along my own buildsystem and opting out of 
yours, ok? thanks dude" and that was that, no muss, no fuss, no 
"tricking" dub into doing what I need, I would've been fine with that.


The problem is that, in my experience, dub's assumptions about it doing 
your build for you tend to be so deeply ingrained into the way it and 
its configuration format all work, that I just don't see attempts to 
separate them out as likely work out all that well. If even at all.


Heck, at this point I feel like most of my attempts to get dub to do 
anything I have in mind have wound up being less "what is the directive 
to do that?" and more "How to I nudge, persuade, or outright trick dub 
into doing what I need?" Even if I just have a compiler switch I want to 
use, or not use, I can't *just use it*. Best case scenario, dub will 
brand my library with a big ugly warning when anyone uses it. More 
likely, I have to go translate it into dub-speak (if I'm LUCKY), or, all 
too frequently, I find myself flailing around, trying to find just the 
right combination of settings to *coax* dub's behavior.


This is a completely *typical* dub experience for me, and frankly, one 
of the more *pleasant* ones:

https://github.com/atilaneves/unit-threaded/issues/106

Did you know dub behaves *differently* if your test configuration is 
named "unittest" verses when it has a different name? I didn't. 
Principle of most surprise, I guess.


THIS is me using dub. Flawless illustration:
https://www.youtube.com/watch?v=QvcFRgJwE2k=0m12s


The problem with that approach though (and part of why I think dub doesn't
do that) is that if dub really is set up with the idea that you use whatever
build system you want, then you have the issue of whether the system doing
the build has all of the necessary software to do the build.  Dub doesn't
completely avoid that as-is, since you can depend on certain libraries being
on the system,

> [...]But if dub itself were designed with the idea that you could
> use cmake, scons, make, or whatever build system anyone felt like putting
> together, then there's a fairly high chance when you go to pull in a 
package

> from dub that it's going to require stuff to build that you don't have on
> your system, and since you frequently end up pulling in packages 
recursively


That's why the way it *should* work is: If your build has a dependency 
(another .d lib, a C lib, cmake, rake, scons, whatever), you make a dub 
package for it if there isn't already one. Problem solved.


But once again, dub's assumption that *everything* is a set of *.d files 
for it to complile gets in the way here too.



So, dub's solution of targeting a single build system side steps that issue
to a great extent - not entirely, but enough that it doesn't tend to be a
problem. And on some level, that's a good thing,


No, all it does it create problems and prevent workarouds, as described 
above. If a package needs, ex, scons, to build, it should be simple to 
create a dummy dub package for scons that (best case) offers to install 
scons for you, maybe even a local non-system-wide installation, or at 
the very least, tells the user, "hey, scons not detected, it's a 
dependncy of this package, so you need to install it."


After all, managing dependencies are what package managers are all 
about, and dub isn't handling it very well when it comes to tool 
dependencies (as opposed to "a library of .d files to be linked in" 
dependencies, which is really all it's designed for).




So, I don't know what the right solution is.


The right solution is to give up on dub, as it's too far down the wrong 
design road, and have a package manager that's designed from the ground 
up to be a package manager (not a simplified buildsystem that happens to 
also include dependency-handling features). As a package manager, 
*anything* the package needs, a D library, a C library, an external 
tool, even a compiler version and the package manager itself...is just 
another dependency for the 

Re: opUnary with ++ and -- on a struct that has a dynamic array

[rumbu via Digitalmars-d-learn]

On Monday, 12 February 2018 at 03:13:43 UTC, aliak wrote:

Hi,

Is there a way to get post increment and pre increment working 
properly in this scenario?


import std.stdio;

struct A {
int[] a;
this(int a) { this.a = [a]; }
auto opUnary(string op)(){
return A(mixin(op ~ "this.a[0]"));
}
}

void main() {
auto a = A(0);
int b = 0;
writeln(a++, ":", b++); // 1, 0 <-- wrong post increment 
result

writeln(++a, ":", ++b); // 2, 2
}


writeln(a++) translates to:

A copy = a;
a.opUnary!"++";
writeln(copy);

copy.a[] and a.a[] are the same reference, you increment 
a.a[0]/copy.a[0] in opUnary


to make this work you will need a postblit constructor:

struct A
{
   
   this(this)
   {
 a = a.dup; //make a copy a;
   }
}

In fact, you'll find exactly the same scenario in docs: 
https://dlang.org/spec/struct.html#struct-postblit




If I switch the order of the mixin expression (i.e. "this.a[0]" 
~ op) then the pre increment does not work.


Any tips?

Cheers
- Ali

[Issue 18425] New: std.process environment["VAR"] = "NAME" does not always take effect

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18425
   Summary: std.process environment["VAR"] = "NAME" does not
always take effect
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: johnnymar...@gmail.com

Mike Franklin had a heck of a time dealing with an apparent bug in
`std.process` where setting an environment variable in windows doesn't appear
to take effect.  By "take effect" I mean, a child process did not receive the
new value set by the parent process using `environemnt["VAR"] = "VALUE";`.

phobos uses the `SetEnvironmentVariableW` function for all windows
platforms/runtimes, however, Mike only started having success once he started
using `putenv` for `version(Win32)`.

PR for reference: https://github.com/dlang/dmd/pull/7845

--

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

[Ali via Digitalmars-d]

On Monday, 12 February 2018 at 04:59:10 UTC, psychoticRabbit 
wrote:
On Sunday, 11 February 2018 at 23:00:40 UTC, Walter Bright 
wrote:
Even little ones like char16_t, char32_t, and being able to 
separate digits with single quotes, and larger ones like 
static if and ranges.


D's support for ranges is probably the single most important 
reason why I choose to use D. (lot's of other very good reasons 
too, but not as important as ranges).


When I look at other languages now, the first thing I want to 
know is, does it have integral support for ranges??


"ranges .. improve safety when compared with iterators because 
they never allow invalid pairs of iterators."


http://www.informit.com/articles/printerfriendly/1407357


C++ is expected to add ranges based on this library
https://github.com/ericniebler/range-v3

Re: inout question

[ketmar via Digitalmars-d-learn]

Norm wrote:


Hi,

I'm new to D so can someone explain to me what is happening here?


void func(const char* s, char** e) {
 import core.stdc.stdlib;
 auto result = strtod(s, e);
}

Error: function core.stdc.stdlib.strtod (scope inout(char)* nptr, scope 
inout(char)** endptr) is not callable using argument types (const(char*), 
char**)


there is a difference between `const char* s`, and `const(char)* s`.
the former means that both `s` and `*s` cannot change, the latter means 
that `s` can be changed, but `*s` cannot. i.e. the first form means that 
you cannot do pointer arithmetic with `s`, while with second form you can 
(only *contents* are const, not the pointer itself).


that is, `strtod` wants const *contents*, but not pointer. `const(char)* s`.

dxml 0.2.0 released

[Jonathan M Davis via Digitalmars-d-announce]

dxml 0.2.0 has now been released.

I really wasn't planning on releasing anything this quickly after announcing
dxml, but when I went to start working on DOM support, it turned out to be
surprisingly quick and easy to implement. So, dxml now has basic DOM
support.

As part of that, it became clear that dxml.parser.stax should be renamed to
dxml.parser, since it's really the only parser (DOM support involves just
providing a way to hold the results of the parser, not any actual parsing,
and that's clear from the API rather than being an implementation detail),
and it makes for a shorter import path. So, I figured that I should do a
release sooner rather than later to reduce how many folks the rename ends up
affecting.

For this release, dxml.parser.stax is now an empty, deprecated, module that
publicly imports dxml.parser, but it will be removed in 0.3.0, whenever that
is released. So, the few folks who grabbed the initial release won't end up
with immediate code breakage if they upgrade.

One nice side effect of how I implemented DOM support is that it's trivial
to get the DOM for a portion of an XML document rather than the entire
thing, since it will produce a DOMEntity from any point in an EntityRange.

Documentation: http://jmdavisprog.com/docs/dxml/0.2.0/
Github: https://github.com/jmdavis/dxml/tree/v0.2.0
Dub: http://code.dlang.org/packages/dxml

- Jonathan M Davis

inout question

[Norm via Digitalmars-d-learn]

Hi,

I'm new to D so can someone explain to me what is happening here?


void func(const char* s, char** e) {
import core.stdc.stdlib;
auto result = strtod(s, e);
}

Error: function core.stdc.stdlib.strtod (scope inout(char)* nptr, 
scope inout(char)** endptr) is not callable using argument types 
(const(char*), char**)


I've found I have to use the following:

void func(inout (char)* s, inout(char)** e)


I thought inout was supposed to take const or non-const variants, 
so expected the original const char* s to work.


Thanks,
Norm

Re: Which language futures make D overcompicated?

[Pjotr Prins via Digitalmars-d]

On Monday, 12 February 2018 at 02:31:38 UTC, Jonathan M Davis 
wrote:
On Sunday, February 11, 2018 19:01:09 Jonathan M Davis via 
Digitalmars-d wrote:
As with too much around here, a big part of the issue is 
ultimately man power. Even if we could all agree on exactly 
how D's build and package management situation should be 
solved, actually get the work done is a huge problem.


On that note, I feel that I really should thank Sonke and those 
few that have helped him write dub. As much as I think that 
some aspects of dub need to be redesigned, at least they 
actually went and did something and managed to get it to take 
off enough that there are quite a few D libraries available 
using dub. So, while the solution may not be what we want, at 
least we have a solution.


Absolutely. Dub gets criticism because it is used which is an 
indicator of a successful piece of work. Kudos for anyone who 
pulls that off. Now we just find it is hard to do this well.


As someone involved with software distribution and deployment in 
production systems, my suggestion is to limit the scope of the 
package manager. Best have to do it little, but do it well and 
make most of existing solutions. The goal should really be 
package discovery and making it easy for beginners (autotools and 
configure does not do today, though C gets away with it). 
Thereafter comes a point you have to hand over the deployment 
issue. I strongly suggest not to make it complicated and not to 
try to create a homogeneous development system for all targets. 
I'll write up how I manage my development and deployment some 
time later this year, it may or may not be a good example ;)

Re: immutable postblit unusable?

[Cauterite via Digitalmars-d]

issue opened here:
https://issues.dlang.org/show_bug.cgi?id=18417

thanks Jon

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

[psychoticRabbit via Digitalmars-d]

On Sunday, 11 February 2018 at 23:00:40 UTC, Walter Bright wrote:
Even little ones like char16_t, char32_t, and being able to 
separate digits with single quotes, and larger ones like static 
if and ranges.


D's support for ranges is probably the single most important 
reason why I choose to use D. (lot's of other very good reasons 
too, but not as important as ranges).


When I look at other languages now, the first thing I want to 
know is, does it have integral support for ranges??


"ranges .. improve safety when compared with iterators because 
they never allow invalid pairs of iterators."


http://www.informit.com/articles/printerfriendly/1407357

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/11/2018 08:27 PM, Walter Bright wrote:

On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) wrote:
That's the same exact reason most languages don't have most of the 
nice things in D, like separators for numeric literals: Because 
they're not strictly necessary. But if D had never been willing to 
improve the state of the art by not being afraid of "not stricktly 
necessary" features, very few of us would have ever had reson to come 
onboard with D in the first place. And yes, I know D's not at that 
point any more. And that's one of my biggest dissapointments with D.


D is already a very large language. There's got to be a point where some 
pruning makes for a better language. Adding more and more lightweight 
features for 0.1% use cases when we neglect heavyweight features for 30% 
use cases is not where we should be shooting our arrows.


Know what is a heavyweight problem worth our while? Having dmd be able 
to directly read C .h files, so the poor user does not have to manually 
translate them.


We've already got a huge chunk of that problem solved. The Digital Mars 
C/C++ front end is now Boost licensed. It can be used. It's already been 
converted to D! The preprocessor in it is a bit dated and a bit too 
specific to Windows - but we've got Warp now!


Replace the preprocessor in dmc++ with Warp, slice off the back end, and 
make it a module that dmd can import.


Wouldn't it be nice to support:

     import stdio.h;    // Look, Ma! C headers!

There are some intractable issues, and it may be impossible to get 100% 
to "it just works", but looking past that it might be a huge win for us.


And, let's not forget working on ref counting.


Definitely all very cool stuff, no argument here. But for smaller things 
it would still be nice to hear something closer to:


"That's a reasonable point and a would be a nice touch, and it doesn't 
impact other things. Andrei and I, naturally, can't dedicate any of our 
resources to it because we have more crutial priorities on our plates, 
but we wouldn't necessarily veto a quality implementation."


instead of:

"It's not one of the big-picture items for D therefore it doesn't belong 
in D"


Though I do realize that's not likely to happen. It's not as if I'm 
saying "hey, go do this". All I'm really saying is "I like this idea, 
I'm in favor of it, and it's worth being open to." Not much more than that.

[Issue 4936] Better error when type inference fails due to incorrect template parameter type

[d-bugmail--- via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--- Comment #6 from Seb  ---
Argh sorry - I was too busy working myself through old issues. Thanks for the
reminder.

-> REOPENED

--

[Issue 18312] string concatenation with -betterC fails with linker errors

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/2a671e0bbfa37427f73494ecca79144e659e0122
fix Issue 18312 - string concatenation with -betterC fails with linker errors

https://github.com/dlang/dmd/commit/2bb137a0f7a856a9331d44b3b4df5aa47b865816
Merge pull request #7868 from WalterBright/fix18312

fix Issue 18312 - string concatenation with -betterC fails with linke…

--

[Issue 18312] string concatenation with -betterC fails with linker errors

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 15086] import doesn't verify module declaration

[d-bugmail--- via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #3 from Andrei Alexandrescu  ---
(In reply to Timothee Cour from comment #2)
> just ran into this again, this is a serious hole in the D module system.
> 
> Here was the example i was gonna report:
> 
> 
> ```dmd -I. main.d
> main
> bar // BUG! was imported as foo.bar (inconsistent)
> foo.bar2
> asdf.wrong // BUG! was imported as foo.bar (inconsistent)
> ```
> 
> ```pragma(msg, __MODULE__);
> import foo.bar;
> import foo.bar2;
> import foo.bar3;
> void main(){}
> 
> cat foo/bar.d
> pragma(msg, __MODULE__);
> cat foo/bar2.d
> 
> cat foo/bar2.d
> module foo.bar2;
> pragma(msg, __MODULE__);
> 
> cat foo/bar3.d
> module asdf.wrong;
> pragma(msg, __MODULE__);
> ```
> 
> 
> 
> LINKS:
> https://github.com/dlang/dmd/pull/7778 Bug fix: dmd allows importing modules
> with wrong name #7778

Can you please reorganize the examples? It is difficult to understand which
files have which content. Thanks!

--

[Issue 14964] __traits(isAlias, foo)

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #7 from Mike Parker  ---
(In reply to Walter Bright from comment #6)
> 
> > __traits(getAllMembers, funcs)
> 
> Perhaps a better solution is to have getAllMembers ignore aliases, as
> aliases are members only for the purpose of symbol lookup.

That's fine, too. Anything that allows filtering out the aliases from the
actual symbols during reflection to avoid redundancy.

--

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Walter Bright via Digitalmars-d]

On 2/11/2018 6:26 PM, Elie Morisse wrote:

Wow, you converted DMC++'s front-end to D?


Yes, it's just frustrating for me to work on C++ code anymore. :-)

To chime in on that, Calypso i.e the LDC+Clang equivalent of what you described 
isn't dead (it just revived a few weeks ago from a long slumber) and it should 
be possible to make a smaller codegen-less version for DMD that only depends on 
a few Clang and LLVM support libraries. Another possibility..


Good ideas! Some things to consider:

1. I'd like this to be pluggable, so that different compilers can be used 
without being disruptive to dmd.


2. DMC++ is not only a C compiler, but a C++ compiler. The C++ compiler, though, 
is stuck on C++98 and is unlikely to see much improvement on that.


3. BetterC is called BetterC and not BetterC++ because D's C++ interop is more 
fragile than the C interop. I felt it better to nail the C end first.


4. It certainly would be nice to be able to insert C++ headers, too, but I'd 
expect more problems (!).


5. C is stuck at C99. Being a fixed target makes it more tractable. Supporting 
C++ means constant revisions and high support costs.


6. Using DMC++ as a front end would add somewhat less than a megabyte (half?) to 
the binary size of dmd. I have no idea what Calypso or other solutions would 
add. If they are large, they may only make sense as a separate executable as a 
filter.

opUnary with ++ and -- on a struct that has a dynamic array

[aliak via Digitalmars-d-learn]

Hi,

Is there a way to get post increment and pre increment working 
properly in this scenario?


import std.stdio;

struct A {
int[] a;
this(int a) { this.a = [a]; }
auto opUnary(string op)(){
return A(mixin(op ~ "this.a[0]"));
}
}

void main() {
auto a = A(0);
int b = 0;
writeln(a++, ":", b++); // 1, 0 <-- wrong post increment 
result

writeln(++a, ":", ++b); // 2, 2
}

If I switch the order of the mixin expression (i.e. "this.a[0]" ~ 
op) then the pre increment does not work.


Any tips?

Cheers
- Ali

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/10/2018 07:35 AM, Timon Gehr wrote:


TL;DR: Parametrically polymorphic functions have /runtime/ type 
parameters. inout can be interpreted as a dependent function of type 
"{type y | y.among(x, const(x), immutable(x)) } delegate(type x)" and an 
inout function can be thought of as a function that takes inout as an 
argument and produces the function as the return value. This formulation 
is more powerful than what the inout syntax can capture, and this is 
what causes problems with type safety. In particular, 'inout' does not 
support proper lexical scoping.


TS;NM: https://gist.github.com/tgehr/769ac267d76b74109a195334ddae01c3 
(Some version of this was originally intended to go to the D blog, but I 
wanted to wait until inout has an obviously type safe definition. It 
also highlights other inout issues than just type unsafety and shows how 
all of them might be fixed in principle by adding polymorphism.)


---

I'll first explain parametric polymorphism, and then what the inout 
problem is.




Ahh, thanks. I'm still not *completely* 100%, but those explanations 
definitely helped a lot. Very insightful.


Side questions:

- Does this mean that fixing the issues with inout (even if done via 
some replacement of inout) would necessarily involve some runtime 
processing in at least certain cases?


- Though I realize this may contradict the definition of "parametric 
polymorphism" as you've described (and also ignoring the matter of 
virtual functions): Would it be theoretically possible to have 
parametric polymorphism that's *implemented* entirely via compile-time 
mechanisms such as templates? Or does our template system as D has it 
already represent the fundamental limits of such an approach?


Incidentally, I've felt for a long while it would've been really nice if 
D had first-class types (for both runtime and compile time). I think a 
system like that, if done right, could have gone a long way to 
alleviating all the awkwardness and asymmetries of reflection and type 
handling in D. It's also why I can understand people coming from certain 
dynamic languages who may find our metaprogramming combersome.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Walter Bright via Digitalmars-d]

On 2/11/2018 5:43 PM, timotheecour wrote:
It doesn't leave anything in Ddoc either, so that's not a viable workaround if 
that comment is intended to be a DDoc.


You're right that this will never be intrepreted as a Ddoc comment. But I infer 
that this resolves the non-Ddoc case?


As for Ddoc comments, your proposed syntax does not contain a trigger for Ddoc, 
and Ddoc already allows for multiple forms of escapes. It's hard to see where it 
would be useful for Ddoc - keep in mind that Ddoc has its own syntax and triggers.

Re: Which language futures make D overcompicated?

[Jonathan M Davis via Digitalmars-d]

On Sunday, February 11, 2018 19:01:09 Jonathan M Davis via Digitalmars-d 
wrote:
> As with too much around here, a big part of the issue is ultimately man
> power. Even if we could all agree on exactly how D's build and package
> management situation should be solved, actually get the work done is a
> huge problem.

On that note, I feel that I really should thank Sonke and those few that
have helped him write dub. As much as I think that some aspects of dub need
to be redesigned, at least they actually went and did something and managed
to get it to take off enough that there are quite a few D libraries
available using dub. So, while the solution may not be what we want, at
least we have a solution.

And even if someone else does come along and put in the time and effort like
the dub folks did but comes up with a solution that we like better, the new
solution will undoubtedly benefit from seeing what has and hasn't worked for
us with dub.

And maybe dub itself will be reworked to be where we want things to do be,
but either way, it requires more manpower, and at least right now, we have
_something_, even if it's far from perfect.

- Jonathan M Davis

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Elie Morisse via Digitalmars-d]

On Monday, 12 February 2018 at 01:27:19 UTC, Walter Bright wrote:

On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) wrote:
Know what is a heavyweight problem worth our while? Having dmd 
be able to directly read C .h files, so the poor user does not 
have to manually translate them.


We've already got a huge chunk of that problem solved. The 
Digital Mars C/C++ front end is now Boost licensed. It can be 
used. It's already been converted to D! The preprocessor in it 
is a bit dated and a bit too specific to Windows - but we've 
got Warp now!


Replace the preprocessor in dmc++ with Warp, slice off the back 
end, and make it a module that dmd can import.


Wouldn't it be nice to support:

import stdio.h;// Look, Ma! C headers!

There are some intractable issues, and it may be impossible to 
get 100% to "it just works", but looking past that it might be 
a huge win for us.


Wow, you converted DMC++'s front-end to D?

To chime in on that, Calypso i.e the LDC+Clang equivalent of what 
you described isn't dead (it just revived a few weeks ago from a 
long slumber) and it should be possible to make a smaller 
codegen-less version for DMD that only depends on a few Clang and 
LLVM support libraries. Another possibility..

[Issue 18422] String members and parameters cannot be mixed in, even during CTFE

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #7 from Andrei Alexandrescu  ---
(In reply to Adam D. Ruppe from comment #6)
> Why doesn't:
> 
> enum Data[] d = getModule!("mypack.mymod").data;
> 
> 
> work? Where getModule is a small template that just returns the populated
> Module object with the CT data.

Cool variant, thanks.

--

opCast cannot implicitly convert a.opCast of type X to Y

[aliak via Digitalmars-d-learn]

From spec: Cast expression: "cast ( Type ) UnaryExpression" 
converts UnaryExpresssion to Type.


And https://dlang.org/spec/operatoroverloading.html#cast makes no 
mention of the return type of opCast. One could think that the 
return type of opCast would be the return type. But it seems it 
must be the same as the template parameter of opCast else you get 
a compile error that seems like it can be much better.


---

import std.stdio;

struct B(T) {
T t;
}

struct A(T) {
T t;
auto opCast(U)() {
return B!U(cast(U)t);
}
}

void main() {
auto a = A!int(3);
auto b = cast(float)a; // error
}

Error: cannot implicitly convert expression a.opCast() of type 
B!float to float


Is this deliberate?

The use case I have is making an optional type that you can cast 
to a different type:


auto opCast(U)() const {
static if (isOptional!U)
{
alias V = OptionalTarget!U;
return empty ? no!V : some!V(cast(V)front); // it's a 
range so "front" is the raw value

}
else
{
return empty ? no!U : some!U(cast(U)front);
}
}

It would allow for scenarios like:

Optional!int a = 3;
auto b = cast(float)a;
// b == some!float


Cheers
- Ali

Re: Which language futures make D overcompicated?

[Jonathan M Davis via Digitalmars-d]

On Sunday, February 11, 2018 20:30:19 Nick Sabalausky  via Digitalmars-d 
wrote:
> The langauge-based package managers just simply need to keep
> "buildsystem" OUT of the package manager's scope. That's all. THAT is
> why system-level packages can be built with whatever tool: because the
> one thing the system package managers actually do get right is NOT
> rolling their own mandatory buildsystem.

I'm not sure that it's entirely a bad thing that dub includes a build system
in it, since it's the ease of use of its build system that is part of why
it's so worth using. It's just that its simplicity is also part of why it
doesn't work well once you get out of the basic situation of "here's a group
of D files that need to be compiled together as a library or application."

So, I do agree that in principle, we would be much better off if dub weren't
so tightly coupled with its build system. If dub were defined in a way that
allowed packages to use whatever build system they wanted so long as they
provided the build artifacts in a standard way to the package manager so
that they could be linked into other dub projects, we'd have something a lot
more flexible. And if done right, I think that it would be much better.
dub's default build system could still be used, but it wouldn't be forced.

The problem with that approach though (and part of why I think dub doesn't
do that) is that if dub really is set up with the idea that you use whatever
build system you want, then you have the issue of whether the system doing
the build has all of the necessary software to do the build. Dub doesn't
completely avoid that as-is, since you can depend on certain libraries being
on the system, and you can't write scripts to be run as part of the build
which could then require who-knows-what on the system (they're just
difficult to get to work with dub in a number of cases because of how much
dub assumes). But if dub itself were designed with the idea that you could
use cmake, scons, make, or whatever build system anyone felt like putting
together, then there's a fairly high chance when you go to pull in a package
from dub that it's going to require stuff to build that you don't have on
your system, and since you frequently end up pulling in packages recursively
such that you could be using dub packages that you've never even heard of,
it could become difficult to ensure that you have everything you need to
build everything in the dub package chain.

So, dub's solution of targeting a single build system side steps that issue
to a great extent - not entirely, but enough that it doesn't tend to be a
problem. And on some level, that's a good thing, but it comes at a definite
cost when you actually need something fancier.

So, I don't know what the right solution is. I'd like to see dub do better
interacting with arbitrary build systems, and if that can be done well, I
think that dub would be much better, but it's a hard problem. Ultimately
though, dub seems to have been designed to solve the common case while not
really making the general case very tractable (maybe not impossible, but
definitely difficult), but its place as the way the way to pull in 3rd party
libraries in D means that it arguably needs to be doing more than just solve
the common case, or 3rd party libraries that don't work with the common case
become intractable, which is definitely not good.

We would probably be better off if someone could come up with an alternate
package manager that was at least compatible enough with dub to use
libraries that use dub so that it could both work with dub and compete with
it and maybe ultimatelly get things right, but package and build management
is one of those hard problems that no one wants to work on, and plenty of
folks like to complain about.

As with too much around here, a big part of the issue is ultimately man
power. Even if we could all agree on exactly how D's build and package
management situation should be solved, actually get the work done is a huge
problem.

- Jonathan M Davis

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[timotheecour via Digitalmars-d]

On Monday, 12 February 2018 at 01:27:19 UTC, Walter Bright wrote:
Know what is a heavyweight problem worth our while? Having dmd 
be able to directly read C .h files, so the poor user does not 
have to manually translate them.


read directly C++ header files instead of C .h files is what we 
should aim for. https://github.com/Syniurge/Calypso/ is actually 
already doing just that and already works in many situations (eg 
opencv).


Replace the preprocessor in dmc++ with Warp, slice off the back 
end, and make it a module that dmd can import.


Wouldn't it be nice to support:

import stdio.h;// Look, Ma! C headers!

There are some intractable issues, and it may be impossible to 
get 100% to "it just works", but looking past that it might be 
a huge win for us.


llvm+clang is a much better approach, guaranteeing compatibility 
with not just C but also and especially C++ (including current 
and future C++ standards). Calypso already understands C++ 
templates, C++ exceptions, can return C++ classes by value (not 
just by reference), without the restrictions imposed on 
extern(C++) classes/structs.


```
modmap (C++) "opencv2.hpp";
import (C++) cv.Mat;
// can now use C++ templates, functions, macros etc in D code.
```

There are of course a number of issues left to be ironed out, but 
it's a much more promising direction than restricting ourselves 
to C (as done with `cgo` for go). That's where we should focus 
our efforts as far as interop is concerned.

Re: Which language futures make D overcompicated?

[Adam D. Ruppe via Digitalmars-d]

On Monday, 12 February 2018 at 01:45:42 UTC, Nick Sabalausky 
(Abscissa) wrote:
But if you're putting out a D lib, you can't do that because 
people expect a lib to be part of a package system (for good 
reason).


Yeah, this drives me nuts too. Most "bugs" I hear are just dub 
being weird (like mine I put as "Sourcelibrary" and it works fine 
if you use one... but if it is included by some other lib as some 
other build, it now conflicts. What I wish it did was just 
realize the package is already a dependency and reuse it! But it 
doesn't seem to work that way.)


And dub's search is kinda bad and the index is just flat-out 
awful, which does more harm than good. People do the 
code.dlang.org search, something doesn't come up, so they assume 
it isn't there even when it is.


I've considered doing a new package website with a new search, 
using dub's official stuff just as a backend api, coupled with 
docs available online. I think I can fix a bunch of those 
frontend problems with it. But I just a lot of higher priority 
stuff to do (like actually writing my libs!) so I haven't gotten 
around to it.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/11/2018 06:47 AM, rikki cattermole wrote:


Dub can do everything that you have described.


No it can't. Not if you value your time and sanity.

You are fully free to run cmake if you wish before the build. Will it 
result in binaries that are decent? Probably not for most use cases.




I *have* taken exactly that approach. It caused me literally years of 
unending greif, even single-handedly turned me away from doing much in D 
for a long while, and ultimately just proved intractable. Abandoning dub 
*entirely* is actually *easier* than trying to use it *only* as a 
package manager. But if you're putting out a D lib, you can't do that 
because people expect a lib to be part of a package system (for good 
reason).

[Issue 18422] String members and parameters cannot be mixed in, even during CTFE

[d-bugmail--- via Digitalmars-d-bugs]

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

Adam D. Ruppe  changed:

   What|Removed |Added

 CC||destructiona...@gmail.com

--- Comment #6 from Adam D. Ruppe  ---
Why doesn't:

enum Data[] d = getModule!("mypack.mymod").data;


work? Where getModule is a small template that just returns the populated
Module object with the CT data.

--

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[timotheecour via Digitalmars-d]

On Monday, 12 February 2018 at 01:39:31 UTC, Walter Bright wrote:

Easy:

mixin template comment(string s) { }

mixin comment!q"EOS
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls like 
https://gcc.gnu.org/onlinedocs/libstdc++/faq.html

EOS";

It doesn't leave anything in the object file, either.


It doesn't leave anything in Ddoc either, so that's not a viable 
workaround if that comment is intended to be a DDoc.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Walter Bright via Digitalmars-d]

On 2/8/2018 7:06 PM, Timothee Cour wrote:

/"EOC
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
EOS"/


Easy:

mixin template comment(string s) { }

mixin comment!q"EOS
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
EOS";

It doesn't leave anything in the object file, either.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/11/2018 06:18 AM, Russel Winder wrote:


Clearly though there is a problem with Dub as a build system for many
of it's users – or rather people who try and reject.



The problem isn't just "dub as a buildsystem". The other equally big 
problem here is that "dub as a package manager" pretty much forces "dub 
as a buildsystem" for library authors. Yes, *officially* it doesn't, but 
realistically, yea it does. And I don't see how dub can fix in any sane 
way without a major, fundamental redesign.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/11/2018 01:54 AM, Pjotr Prins wrote:
Dub is getting some flak here. This is unsurprising because it is really 
hard to write a good package manager and build system. I use a lot of 
languages and not one has a satisfactory package manager. Mostly they 
try to do too much and get in the way or they do too little and people 
complain (I prefer the second option). And when there are 100+ 
dependencies, like with Go and Node, it just becomes impossible to say 
anything about the state of the system (security, anyone?).


Package management is mostly dependency management. This I handle with 
GNU Guix (and Nix) package managers. They are great at that.


Ugh, system-level package managers. That's the #1 reason I keep hopping 
around distros, never finding one I like:


They're all completely fucking non-standard. Every fucking distro has 
it's own damn package manager (and then there's mac and win and the 
mobiles), and on top of that, most of those system managers are almost 
completely worthless *when* you need something other then "the latest 
version" let alone multiple versions (because "newer is always better" 
is software's #1 sacred cow). Those are *exactly* the reasons why 
programming langauges have NEEDED to start rolling their own damn 
package managers, because relying on the goddamn system managers for 
libs is a complete fucking non-starter.


(Hmm, Can you tell I'm not happy with system package managers? ;) )

The langauge-based package managers just simply need to keep 
"buildsystem" OUT of the package manager's scope. That's all. THAT is 
why system-level packages can be built with whatever tool: because the 
one thing the system package managers actually do get right is NOT 
rolling their own mandatory buildsystem.


One of the things on my master list of "project's I'll probably never 
get around to" is a CLI front-end to unify all this fractured 
apt/pacman/yum crap.


This also 
leaves people to choose any old build system. Inside GNU Guix the build 
system is consistent, which is really nice. I'll write a blog some time 
this year.


What you really want is to be able to discover packages (i.e., a website 
such as Dub provides), pull them into your tree (which is just a path 
and can be handled by git submodules, though I don't like those much 
either),


Agreed.

and when you distribute: add them to Guix or Nix and provide 
those packages with build system and as binary deployments to others. 


And fracture the hell out of your user-base, forcing even Linux alone to 
be treated as 100 different fucking incompatable operating systems for 
which each package only supports one or two? Ugh, god no. Spare me. Even 
dub, for all it's shortcomings at LEAST has absolutely no trouble 
treating nearly all of Linux as ONE unified target.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Walter Bright via Digitalmars-d]

On 2/11/2018 5:05 PM, Nick Sabalausky (Abscissa) wrote:
That's the same exact reason most languages don't have most of the nice things 
in D, like separators for numeric literals: Because they're not strictly 
necessary. But if D had never been willing to improve the state of the art by 
not being afraid of "not stricktly necessary" features, very few of us would 
have ever had reson to come onboard with D in the first place. And yes, I know 
D's not at that point any more. And that's one of my biggest dissapointments 
with D.


D is already a very large language. There's got to be a point where some pruning 
makes for a better language. Adding more and more lightweight features for 0.1% 
use cases when we neglect heavyweight features for 30% use cases is not where we 
should be shooting our arrows.


Know what is a heavyweight problem worth our while? Having dmd be able to 
directly read C .h files, so the poor user does not have to manually translate them.


We've already got a huge chunk of that problem solved. The Digital Mars C/C++ 
front end is now Boost licensed. It can be used. It's already been converted to 
D! The preprocessor in it is a bit dated and a bit too specific to Windows - but 
we've got Warp now!


Replace the preprocessor in dmc++ with Warp, slice off the back end, and make it 
a module that dmd can import.


Wouldn't it be nice to support:

import stdio.h;// Look, Ma! C headers!

There are some intractable issues, and it may be impossible to get 100% to "it 
just works", but looking past that it might be a huge win for us.


And, let's not forget working on ref counting.

[Issue 4936] Better error when type inference fails due to incorrect template parameter type

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from Jesse Phillips  ---
Seb, this is specifically about the error message poorly directing the user to
provide a SortedRange. This was more confusing to me since I hit the issue
after the library change, rather than when initially writing the code.

As I don't know exact changes to improve the error message I'll leave it
closed, but it is a larger issue using templates and type inference which could
be improved.

--

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/10/2018 06:03 PM, Walter Bright wrote:


There isn't any commenting scheme that won't trip you up with certain 
characters 


That's exactly the whole point of heredocs ever existing in the first 
place, its exactly the problem they're created for.


in the comments. I don't see a compelling case for adding 
another kind of comment.




That's the same exact reason most languages don't have most of the nice 
things in D, like separators for numeric literals: Because they're not 
strictly necessary. But if D had never been willing to improve the state 
of the art by not being afraid of "not stricktly necessary" features, 
very few of us would have ever had reson to come onboard with D in the 
first place. And yes, I know D's not at that point any more. And that's 
one of my biggest dissapointments with D.


Vladimir's suggestion to use %2B instead of + seems to resolve this 
adequately.


Only for URLs. "URLs" was just one example of a language that can leas 
to trouble.

Re: -cov LOC is inadequate for 1 liner branching; need a metric based on branching

[Walter Bright via Digitalmars-d]

On 2/11/2018 3:01 PM, Timothee Cour wrote:

It's about `line coverage` vs `branch coverage` (see exact definition
in linked article),


Ok, I see now, thanks for your patience and the clarification.



that difference is very large in practice.


Only if one cares about the percentage metric. Pragmatically, I'm much more 
interested in exactly what was not covered rather than the percentage, and any 
good QA department should be focused on that rather than the percent metric.


BTW, when I wrote the -cov implementation, I threw in the % metric just for fun 
.



What's more, code instrumentation to enable branch coverage is not
more complex to implement compared to line coverage (I would even
venture it's less complex and less costly).


I'm not convinced of that, as you've still got the:

   if (a) b;

problem. Furthermore, in the first link they alluded to the thrown exception 
problem, with some gobbledy-gook answer on how they dealt with it (they punted). 
Sequence point coverage doesn't have that problem.


Next, in the python linked example, they found it necessary to add a bunch of 
pragma's to give needed information to the branch counter. I have a hard time 
seeing anyone using that unless they're forced to by management. The idea with 
dmd's coverage is you type -cov and you get a coverage report. Done.


The coverage report is a simple text file that is both readable by itself and 
trivially parse-able with a program for those who really want a GUI presentation 
of the results, or who want to integrate it with github (as has been done for 
us, yay!).


(Back in the olden daze, a coverage analyzer was a separate product that came 
with a 200 page manual. Who bought it? Managers. Who used it? Nobody. You'd see 
the manual on programmers' shelves, still in its shrink wrap.)


---

I'm actually glad to see people complain about -cov and want to improve it. It 
shows it is successful - people are using it! As Bjarne Stroustrup once said, 
there are two kinds of products - ones people complain about, and ones people 
don't use.

Re: Linking multiple libraries

[Basile B. via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 01:38:41 UTC, b2.temp wrote:
On Sunday, 26 November 2017 at 11:15:58 UTC, Jacob Carlborg 
wrote:

On 2017-11-25 23:31, Mike Parker wrote:

For "ld" on macOS the order does not matter. For "ld" on Linux 
the order does matter, but, if necessary, the following flags 
can be used to link libraries in any order: "--start-group" 
and "--end-group". Those flag will cause the linker to search 
the libraries repeatedly to resolve undefined symbols.


These flags should be  passed to ld by DMD i think


The flags could be put before and after this loop:
https://github.com/dlang/dmd/blob/master/src/dmd/link.d#L602

Re: Bye bye, fast compilation times

[Bastiaan Veelo via Digitalmars-d]

On Wednesday, 7 February 2018 at 09:27:47 UTC, Stefan Koch wrote:
One thing that I really need in druntime is a cross-platform 
way to allocate executable memory-pages, this can be done by 
someone else.
Is this on someone's agenda? It probably needs an enhancement 
request at the very least, I don't think it's there yet [1].


Another Thing that can be done is reviewing the code and 
alerting me to potential problems. i.e. Missing or 
indecipherable comments as well as spelling mistakes.

I had a go at this [2].

[1] 
https://issues.dlang.org/buglist.cgi?bug_severity=enhancement_status=NEW_status=ASSIGNED_status=REOPENED=druntime_id=219522=D_format=advanced

[2] https://github.com/UplinkCoder/dmd/pull/3

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

[Walter Bright via Digitalmars-d]

On 2/11/2018 2:16 AM, Russel Winder wrote:

Confirmatory evidence is that Rust does the same thing.


D has an outsized influence that extends way beyond just D users :-)

Consider all the D features that somehow were "completely independently" 
discovered years later by C++!


Even little ones like char16_t, char32_t, and being able to separate digits with 
single quotes, and larger ones like static if and ranges.

Re: -cov LOC is inadequate for 1 liner branching; need a metric based on branching

[Timothee Cour via Digitalmars-d]

> -cov coverage percentage is the line coverage, not the sequence point 
> coverage [...]
> makes it fuzzy in proportion to how many lines contain multiple sequence 
> points

Based on your comment I'm pretty sure you're still not getting my
point, so apologies if I was unclear and let me try to explain better:

it's not about `line coverage` vs `sequence point coverage`, as that
difference is not very large (indeed, just 'fuzzy').

It's about `line coverage` vs `branch coverage` (see exact definition
in linked article), that difference is very large in practice.

here's my example, but more concretely explained:
```
void main(int a){
if(a>0){
  statement1(); // line 3
  statement2(); // line 4
...
  statement100(); // line 102
} else{
  statement101(); // line 104
}
}
unittest{ fun(1); }
```
* line coverage is around 99%.
* sequence point coverage is also 99% (and would be close to that if
some lines had multiple statements)
* branch coverage is 50%.

This is not an artificial example, this is the common case.

What's more, code instrumentation to enable branch coverage is not
more complex to implement compared to line coverage (I would even
venture it's less complex and less costly).



On Sun, Feb 11, 2018 at 2:32 PM, Walter Bright via Digitalmars-d
 wrote:
> On 2/11/2018 1:55 PM, Timothee Cour wrote:
>>
>> I think you're missing my main point: it's explained here
>>
>> https://www.ncover.com/support/docs/extras/code-coverage/understanding-branch-coverage
>> but the gist is that line based coverage is over-counting:
>> ```
>> if(A)
>>// 100 lines of code
>> else
>>// 1 line of code
>> ```
>> gives a line coverage of ~ 99% vs a branch coverage of ~50%
>> (assuming `else` branch never covered in unittests)
>>
>> What matters as far as bugs are concerned is that 50% of cases are
>> covered. Increasing the size of the `if(A)` branch increases line
>> coverage (which is irrelevant) but not branch coverage.
>
>
> I understand that point. The -cov coverage percentage is the line coverage,
> not the sequence point coverage. (Hence it will never be greater than 100%,
> and it will never underestimate the coverage. It would be more accurately
> termed an "upper bound" on the coverage.)
>
> And yes, that makes it fuzzy in proportion to how many lines contain
> multiple sequence points. Eliminating that fuzziness does require a vast
> increase in the complexity of the -cov implementation.

Re: Bye bye, fast compilation times

[aliak via Digitalmars-d]

On Sunday, 11 February 2018 at 16:35:35 UTC, Adam D. Ruppe wrote:
The isemail function isn't about validating email addresses. It 
is just about recognizing something that looks like one. just 
like isurl doesn't actually try to fetch the site to see if it 
is broken, it just sees if it looks like one as a first step.


*valid email format... (is better? :) )

When someone says isurl checks if a string is a valid url, I 
don't think the general assumption is that it makes a network 
call to check if it is a resolvable url. (could be mistaken of 
course, but not to me at least). Isurl checks that the format is 
correct. Same for isemail. The isemail API and the docs all use 
the term valid as well.


Plus, to further see how hard it is to validate an email, these 
are apparently all erroneous results (granted wikipedia could be 
wrong as well):


import std.net.isemail, std.stdio;

void main() {
isEmail("john.smith(comment)@example.com").valid.writeln; // 
is valid, prints false
isEmail("user@[2001:DB8::1]").valid.writeln; // is valid, 
prints false
isEmail(`" "@example.org`).valid.writeln; // not valid, 
prints true

isEmail(`"very.unusu...@.unusual.com"@example.com`).valid.writeln; // not valid, prints true

}

Re: -cov LOC is inadequate for 1 liner branching; need a metric based on branching

[Walter Bright via Digitalmars-d]

On 2/11/2018 1:55 PM, Timothee Cour wrote:

I think you're missing my main point: it's explained here
https://www.ncover.com/support/docs/extras/code-coverage/understanding-branch-coverage
but the gist is that line based coverage is over-counting:
```
if(A)
   // 100 lines of code
else
   // 1 line of code
```
gives a line coverage of ~ 99% vs a branch coverage of ~50%
(assuming `else` branch never covered in unittests)

What matters as far as bugs are concerned is that 50% of cases are
covered. Increasing the size of the `if(A)` branch increases line
coverage (which is irrelevant) but not branch coverage.


I understand that point. The -cov coverage percentage is the line coverage, not 
the sequence point coverage. (Hence it will never be greater than 100%, and it 
will never underestimate the coverage. It would be more accurately termed an 
"upper bound" on the coverage.)


And yes, that makes it fuzzy in proportion to how many lines contain multiple 
sequence points. Eliminating that fuzziness does require a vast increase in the 
complexity of the -cov implementation.

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

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 11 February 2018 at 15:07:00 UTC, German Diago wrote:
If it is not implementable (it is complex, I agree), why there 
are 3 major compilers?


At least 4: Intel, Microsoft, GCC and Clang. Then you have EDG 
and IBM, probably more.

Re: -cov LOC is inadequate for 1 liner branching; need a metric based on branching

[Timothee Cour via Digitalmars-d]

I think you're missing my main point: it's explained here
https://www.ncover.com/support/docs/extras/code-coverage/understanding-branch-coverage
but the gist is that line based coverage is over-counting:
```
if(A)
  // 100 lines of code
else
  // 1 line of code
```
gives a line coverage of ~ 99% vs a branch coverage of ~50%
(assuming `else` branch never covered in unittests)

What matters as far as bugs are concerned is that 50% of cases are
covered. Increasing the size of the `if(A)` branch increases line
coverage (which is irrelevant) but not branch coverage.


On Sun, Feb 11, 2018 at 1:32 PM, Walter Bright via Digitalmars-d
 wrote:
> On 2/5/2018 11:32 AM, Timothee Cour wrote:
>>
>> just filed https://issues.dlang.org/show_bug.cgi?id=18377:
>>
>> `dmd -cov -run main.d` shows 100% coverage; this is misleading since a
>> branch is not taken:
>>
>> ```
>> void main(){
>>int a;
>>if(false) a+=10;
>> }
>> ```
>
>
> Consider how -cov works today:
>
>   2|  x = 3; y = 4;
>   1|  ++x;
>
> The first line has a count of 2, because there are two statements and each
> contributes one increment to the line.
>
>   1|  x = 3; // reference count
>   2|  if (true && false) c;
>   3|  if (true && true) c;
>   1|  if (false && b) c;
>
> The sequence points are each counted separately. So, by comparing with the
> 'reference count', you can see which sequence points are executed. Also, if
> one finds that unattractive, the code can be organized like:
>
>   1|  if (true &&
>   1|  false)
>   0| c;
>
> and the separate counts will be revealed instead of aggregated.
>
> I agree that this is not ideal, however:
>
> 1. it works
> 2. it is simple and robust
> 3. the display to the user is simple
> 4. it's easy to aggregate multiple runs together with simple text processing
> code
> 5. one can 'fix' it with a stylistic change in the formatting of the source
> code
>
> Any further improvement would be a large increase in complexity of the
> implementation, and I don't know of reasonable way to present this to the
> user in a textual format.
>
> Is it worth it? I don't think so. Like builtin unittests, the big win with
> -cov is it is *trivial* to use, which encourages its adoption. It's a 99%
> solution, with 99% of the benefits, with 1% of the implementation effort. We
> should be expending effort elsewhere than putting an additional 99% effort
> to squeeze out that last 1% of benefit.

Re: missing HexString documentation

[Walter Bright via Digitalmars-d]

On 2/11/2018 6:09 AM, Steven Schveighoffer wrote:

On 2/8/18 3:49 PM, Walter Bright wrote:
That would be a language change proposal or bug report. By all means, please 
do so.


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


Good!


I also notice that hex strings are not simply equivalent to strings with \x in 
them -- the latter is more constrained, as it must be a pair of hex digits per 
\x. hex strings allow spaces between them.


The idea was to be able to cut text from things like hex dumps, which 
include whitespace formatting.




I wouldn't call invoking CTFE "no overhead"


It is no overhead in the generated code.


I tested it out, and generating a hex string of about 600 bytes took 3x as long 
as using builtin hex strings.


That's only a potential issue if you've got a very, very large number of hex 
strings. And if you do, those strings can be put in a separate module and 
compiled separately.




Again, this is about the compile time penalty.


Ok.


Well, nobody asked :) Besides, it's still not "fixed", as it has the same poor 
performance as the previous version. And the new version has broken existing code.


It didn't break code that used x"deadbeef", it broke code that used the broken 
hexString.



What the update shows is that you have to jump through incredible hoops to get 
the compiler not to include your compile-time only generation code in the 
resulting binary.


With a language that supports both templates and separate compilation, this will 
always be an issue.


The solution here is not "incredible", it is just not obvious.



And nothing has changed here, it's still a library function, as it was before.


What's changed is it works now with -betterC, and it doesn't produce bloat in 
the executable.



But if you already have the compiler feature, I don't see why 
we should remove it because a slower library version exists.


It was not an arbitrary and capricious decision, and the rationale behind it was 
presented here multiple times. If you are not convinced, that's cool, but the 
"why" should be pretty clear.



In fact, it's a motivating factor to make 
CTFE code compile faster as it takes away arguments of adding more things to the 
compiler.


I agree that speeding up CTFE will make it more useful.

Re: -cov LOC is inadequate for 1 liner branching; need a metric based on branching

[Walter Bright via Digitalmars-d]

On 2/5/2018 11:32 AM, Timothee Cour wrote:

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

`dmd -cov -run main.d` shows 100% coverage; this is misleading since a
branch is not taken:

```
void main(){
   int a;
   if(false) a+=10;
}
```


Consider how -cov works today:

  2|  x = 3; y = 4;
  1|  ++x;

The first line has a count of 2, because there are two statements and each 
contributes one increment to the line.


  1|  x = 3; // reference count
  2|  if (true && false) c;
  3|  if (true && true) c;
  1|  if (false && b) c;

The sequence points are each counted separately. So, by comparing with the 
'reference count', you can see which sequence points are executed. Also, if one 
finds that unattractive, the code can be organized like:


  1|  if (true &&
  1|  false)
  0| c;

and the separate counts will be revealed instead of aggregated.

I agree that this is not ideal, however:

1. it works
2. it is simple and robust
3. the display to the user is simple
4. it's easy to aggregate multiple runs together with simple text processing 
code
5. one can 'fix' it with a stylistic change in the formatting of the source code

Any further improvement would be a large increase in complexity of the 
implementation, and I don't know of reasonable way to present this to the user 
in a textual format.


Is it worth it? I don't think so. Like builtin unittests, the big win with -cov 
is it is *trivial* to use, which encourages its adoption. It's a 99% solution, 
with 99% of the benefits, with 1% of the implementation effort. We should be 
expending effort elsewhere than putting an additional 99% effort to squeeze out 
that last 1% of benefit.

Re: Workaround for https://issues.dlang.org/show_bug.cgi?id=18422?

[Meta via Digitalmars-d]

On Sunday, 11 February 2018 at 15:34:07 UTC, Andrei Alexandrescu 
wrote:
I'm trying to sketch a simple compile-time reflection system, 
and https://issues.dlang.org/show_bug.cgi?id=18422 is a blocker 
of the entire approach. My intent is to have a struct Module, 
which can be initialized with a module name; then:


struct Module
{
private string name;
Data[] data(); // all data declarations
Function[] functions();
Struct[] structs();
Class[] classes();
Union[] unions();
Enum[] enums();
}

Then each of those types carries the appropriate information. 
Notably, there are no templates involved, although all code is 
evaluated during compilation. Non-data information (types, 
qualifiers etc) is carried as strings. This allows for simple 
arrays to convey heterogeneous information such as "all 
functions in this module", even though their signatures are 
different.


This makes for a simple and easy to use system for 
introspecting things during compilation. Clearly in order to do 
that some of these compile-time strings must be mixed in, which 
is why https://issues.dlang.org/show_bug.cgi?id=18422 is so 
problematic.


Until we discuss a fix, are there any workarounds?


Thanks,

Andrei


If you need a workaround that doesn't have a struct or function 
templated on `name`, then no, I don't think there is. The problem 
is that there are two different kinds of compile time:


https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time

Re: D-dll support: testers needed round 2

[Amorphorious via Digitalmars-d]

On Saturday, 10 February 2018 at 12:34:03 UTC, Benjamin Thaut 
wrote:
On Saturday, 10 February 2018 at 02:24:58 UTC, rikki cattermole 
wrote:

On 09/02/2018 8:34 PM, Benjamin Thaut wrote:

-import switch makes me a little concerned, what exactly is it 
changing that makes it required?


Thank you Rikki for derailing this topic with the first post. 
As you might noticed, the title says "testers needed" not 
"concerns needed". And if you absolutly have to voice your 
concerns at least do it in a usefull way. Give a propper reason 
for your concerns, ideally a technical one. Not just "I'm 
concerned about x".


Did you Read DIP 45 in its current state? Did you watch my 
DConf Talk about Dll support? Did you understand how the shared 
library menchanism works on windows? If you did then the 
details behind the -import switch should be very self 
explanatory. If you didn't -import is needed for the compiler 
to know when to dllimport a symbol. If you need more detail you 
will have to wait until I updated DIP 45. With the little time 
I have at the moment I can't re-explain the full details of the 
implemenation to everyone in person, that would be very bad use 
of my time.


So if you want to help, download the binary distribution and 
give it a try. Try to find a corner case with dlls that my 
implementation doesn't cover. That would be useful.


Kind Regards
Benjamin Thaut


lol, come on man!!! WTF?!?!?! You know D is filled with people 
who have to whine about "breaking changes" It's always either to 
whine than work.


I might give this a try if I ever get back in to D programming... 
as of now D is to screwed up for me to invest any more time. 
Great concept, poor implementation. Too much of a hodge podge of 
things without really thinking the consequences through.  It's 
not necessary bad but when you couple it with all the lame 
tooling and IDE's that offer no real efficiency it becomes an 
issue. Easier just to use a modern well equipped compiler with 
good documentation and good IDE's and good libraries.


It's kinda like someone invented a great car engine but forgot to 
put AC in it, manual windows, etc. Some people will love it just 
because of the engine... others are more balanced in there 
analysis and realize the engine isn't car and rather ride in 
style at the cost of a few HP than suffering in the heat just to 
get to their destination 0.53 min faster. Unfortunately D seems 
to be made up of people who only care about the engine.

Re: Caesar Cipher

[Mario via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 18:55:44 UTC, Seb wrote:

On Sunday, 11 February 2018 at 18:50:25 UTC, Mario wrote:

On Sunday, 11 February 2018 at 18:31:35 UTC, Seb wrote:

On Sunday, 11 February 2018 at 18:01:20 UTC, Mario wrote:
Hello there! I know deep Java, JavaScript, PHP, etc. but as 
you all probably know, that's high-level and most of them 
only use the heap memory.


[...]



If you want to cheap, have a look at 
https://github.com/dlang-tour/core/issues/227


Thank you for that, but actually it's using stuff that didn't 
appear yet (I understand how it works but I'd like to know why 
XD)


Wel, the DLang Tour grew organically and its typically hard for 
an experienced D user to realize what has been introduced and 
what not, so we are really grateful for any feedback you have


-> https://github.com/dlang-tour/english/issues

And of course, you can always press on "edit" and improve it 
directly ;-)


Sure! Also, I'm from Spain so I'd like to contribute translating 
the "Learn" site (I think it might be useful for new members, 
even if most of the community knows English :P).

Re: Caesar Cipher

[Mario via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 18:55:14 UTC, Cym13 wrote:

On Sunday, 11 February 2018 at 18:50:25 UTC, Mario wrote:

On Sunday, 11 February 2018 at 18:31:35 UTC, Seb wrote:

On Sunday, 11 February 2018 at 18:01:20 UTC, Mario wrote:
Hello there! I know deep Java, JavaScript, PHP, etc. but as 
you all probably know, that's high-level and most of them 
only use the heap memory.


[...]



If you want to cheap, have a look at 
https://github.com/dlang-tour/core/issues/227


Thank you for that, but actually it's using stuff that didn't 
appear yet (I understand how it works but I'd like to know why 
XD)


I think the less advanced way (in term of features) would be 
using a foreach loop (which haven't been introduced either yet).


But yeah, the example isn't well choosen, and that's why an 
issue was oppened for it ;)


Yeah, if it's similar to Js will be a good choice (sure it ain't 
the best in D, but I will try it)

Re: [Help] programm execution leads to infinity background loop after... what reason?

[Cym13 via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 17:28:25 UTC, Eld0r wrote:
changed my design from extending thread to just using 
taskPool.parallel.
seems like my implementation left to many open threads in 
background and forcing the operation system to cut them off.


thought start() and join() allowed me to use start() again on 
the same thread object in next loop.
But there is some leakage... are they not 'self-closig' after 
finnishing run() ?


works now
but you are welcome to leave a statement.


For a statement... I'm glad you found your way! However nobody 
can debug a program they can't read so please always post a small 
working example in order for others to understand your issue and 
be able to reproduce it ;)

[Issue 18424] New: Add DUB man pages to the released archive

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18424
   Summary: Add DUB man pages to the released archive
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

DUB now provides man pages:

https://github.com/dlang/dub/pull/1342

It's probably a good idea to ship them with the release archives.
See also:

https://github.com/dlang/dub/issues/855

--

[Issue 18422] String members and parameters cannot be mixed in, even during CTFE

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from Andrei Alexandrescu  ---
Refer to https://github.com/andralex/introspect/blob/master/introspect.d. It
defines Module as a template taking the module name as a string, and the data
declarations work out nicely. I'll continue digging in that direction see where
it goes.

--

Re: -cov LOC is inadequate for 1 liner branching; need a metric based on branching

[timotheecour via Digitalmars-d]

On Monday, 5 February 2018 at 19:32:37 UTC, Timothee Cour wrote:

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


@wilzbach
It probably makes sense to have a look at how other languages 
are dealing with this. Seems to be a common problem


some links:
* 
https://www.ncover.com/support/docs/extras/code-coverage/understanding-branch-coverage => "Why do we need the Branch Coverage metric?"
* http://coverage.readthedocs.io/en/coverage-4.4.2/branch.html => 
"coverage run --branch myprog.py"

[Issue 18422] String members and parameters cannot be mixed in, even during CTFE

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Andrei Alexandrescu  ---
(In reply to ag0aep6g from comment #3)
> (In reply to Andrei Alexandrescu from comment #2)
> > Happy to oblige!
> > 
> > struct Data
> > {
> > string name;
> > string type;
> > string qualifier;
> > string[] attributes;
> > }
> > 
> > Then the module can give you all top-level data declarations:
> > 
> > enum Data[] d = Module("mypack.mymod").data;
> > ...
> 
> Eh? Previously it was "function declarations", now it's "data declarations".
> And you've not given an implementation of either.

Somebody's in a testy mood :o). It was quicker to exemplify with data. Will
follow up with a working sample.

--

Re: typedef behavior

[Alex via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 15:18:11 UTC, Simen Kjærås wrote:


Basically, Typedef looks like this:

struct Typedef(T) {
T _payload;
// Forward method calls, member access, etc, to _payload.
}

If T looks like this:

struct T {
static int[3] arr;
void foo() { arr[0]++; }
}

How is Typedef supposed to wrap T.foo in such a way that it 
uses a different arr depending on whether it's called from the 
Typedef or from T?


--
  Simen


In the same way as it is handled by this:

/// --- code --- ///

void main(){}

static assert(T.arr.ptr != S.arr.ptr);

struct T {
static int[3] arr;
void foo() { arr[0]++; }
}

struct S {
static int[3] arr;
void foo() { arr[0]++; }
}

/// --- code ends --- ///

I understand that Typedef should be kept simple. But if it 
defines a type which is recognized as another type in respect to 
the underlying one, then I should be able to rely on independence 
of everything, like I would copy/paste the implementation. Or do 
I misinterpret something?

[Issue 18422] String members and parameters cannot be mixed in, even during CTFE

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from ag0ae...@gmail.com ---
(In reply to Andrei Alexandrescu from comment #2)
> Happy to oblige!
> 
> struct Data
> {
> string name;
> string type;
> string qualifier;
> string[] attributes;
> }
> 
> Then the module can give you all top-level data declarations:
> 
> enum Data[] d = Module("mypack.mymod").data;
> ...

Eh? Previously it was "function declarations", now it's "data declarations".
And you've not given an implementation of either.

--

Re: Caesar Cipher

[Era Scarecrow via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 18:01:20 UTC, Mario wrote:

char[] encrypt(char[] input, char shift)
{
auto result = input.dup;
result[] += shift;
return result;
}


What's wrong? I mean, I know that z is being converted into a 
symbol, but how should I fix this?


 If you take Z (25) and add 10, you get 35. You need to have it 
identify and fix the problem, namely removing 26 from the result.


 Assuming anything can be part of the input (and not just 
letters), we instead do the following:


auto result = input.dup;
foreach(ref ch; result) {
if (ch >= 'A' && ch <= 'Z')
ch = ((ch+shift-'A') % 26) + 'A';
}

 Alternatively if you do where every character is defined for 
switching (and those not changing are the same) it could just be 
a replacement & lookup.

Re: Caesar Cipher

[DanielG via Digitalmars-d-learn]

Here's a newbie-friendly solution: https://run.dlang.io/is/4hi7wH

Re: Caesar Cipher

[Seb via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 18:50:25 UTC, Mario wrote:

On Sunday, 11 February 2018 at 18:31:35 UTC, Seb wrote:

On Sunday, 11 February 2018 at 18:01:20 UTC, Mario wrote:
Hello there! I know deep Java, JavaScript, PHP, etc. but as 
you all probably know, that's high-level and most of them 
only use the heap memory.


[...]



If you want to cheap, have a look at 
https://github.com/dlang-tour/core/issues/227


Thank you for that, but actually it's using stuff that didn't 
appear yet (I understand how it works but I'd like to know why 
XD)


Wel, the DLang Tour grew organically and its typically hard for 
an experienced D user to realize what has been introduced and 
what not, so we are really grateful for any feedback you have


-> https://github.com/dlang-tour/english/issues

And of course, you can always press on "edit" and improve it 
directly ;-)

Re: Caesar Cipher

[Cym13 via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 18:50:25 UTC, Mario wrote:

On Sunday, 11 February 2018 at 18:31:35 UTC, Seb wrote:

On Sunday, 11 February 2018 at 18:01:20 UTC, Mario wrote:
Hello there! I know deep Java, JavaScript, PHP, etc. but as 
you all probably know, that's high-level and most of them 
only use the heap memory.


[...]



If you want to cheap, have a look at 
https://github.com/dlang-tour/core/issues/227


Thank you for that, but actually it's using stuff that didn't 
appear yet (I understand how it works but I'd like to know why 
XD)


I think the less advanced way (in term of features) would be 
using a foreach loop (which haven't been introduced either yet).


But yeah, the example isn't well choosen, and that's why an issue 
was oppened for it ;)

Re: Caesar Cipher

[Mario via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 18:28:08 UTC, Cym13 wrote:

On Sunday, 11 February 2018 at 18:01:20 UTC, Mario wrote:
Hello there! I know deep Java, JavaScript, PHP, etc. but as 
you all probably know, that's high-level and most of them only 
use the heap memory.


So I'm new to the wonderful world of low-level and the 
stack-heap. I started a week ago learning D (which by the 
moment is being easy for me) but I'm facing a big problem: I 
don't know how to do the exercise of 
https://tour.dlang.org/tour/en/basics/arrays . I really have 
been looking on forums and Google but I found this in Java 
https://stackoverflow.com/questions/10023818/shift-character-in-alphabet which is actually not the best due to Java uses other ways.


My code is something like this:

char[] encrypt(char[] input, char shift)
{
auto result = input.dup;
result[] += shift;
return result;
}


What's wrong? I mean, I know that z is being converted into a 
symbol, but how should I fix this?

Thanks on forward.


Your mistake has little to do with D, and more with Ceasar 
(which is unfortunate IMHO): this cipher is usually defined 
only on the 26 letters of the alphabet and seeing the result of 
the assert at the end of the code it's the case here. So while 
you're working on a full byte (256 values) you should restrict 
yourself to the 26 lowercase ascii alpha characters.


Give it a try :)


Got it, I'll give it a try with an if. Will post later the result 
so more people can get a solution with the most basic stuff.

Re: Caesar Cipher

[Mario via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 18:31:35 UTC, Seb wrote:

On Sunday, 11 February 2018 at 18:01:20 UTC, Mario wrote:
Hello there! I know deep Java, JavaScript, PHP, etc. but as 
you all probably know, that's high-level and most of them only 
use the heap memory.


[...]



If you want to cheap, have a look at 
https://github.com/dlang-tour/core/issues/227


Thank you for that, but actually it's using stuff that didn't 
appear yet (I understand how it works but I'd like to know why XD)

Re: Nightlies not being built so so how do I build dmd-master locally instead?

[Seb via Digitalmars-d]

On Sunday, 11 February 2018 at 18:23:58 UTC, Nordlöw wrote:
https://nightlies.dlang.org/ has not been built since 
2018-02-01. What's wrong?


Fixed: https://github.com/dlang/dlang.org/pull/2200

Can I build dmd master with ldc (need compilation speed) 
myself? If so what's the preferred script?


https://github.com/CyberShadow/Digger is the easiest way.

[Issue 18422] String members and parameters cannot be mixed in, even during CTFE

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Andrei Alexandrescu  ---
Happy to oblige!

struct Data
{
string name;
string type;
string qualifier;
string[] attributes;
}

Then the module can give you all top-level data declarations:

enum Data[] d = Module("mypack.mymod").data;
...

Indeed it is odd there'd be functions that only run during compilation. Need to
think of that.

--

Re: Workaround for https://issues.dlang.org/show_bug.cgi?id=18422?

[John Colvin via Digitalmars-d]

On Sunday, 11 February 2018 at 15:34:07 UTC, Andrei Alexandrescu 
wrote:
I'm trying to sketch a simple compile-time reflection system, 
and https://issues.dlang.org/show_bug.cgi?id=18422 is a blocker 
of the entire approach. My intent is to have a struct Module, 
which can be initialized with a module name; then:


struct Module
{
private string name;
Data[] data(); // all data declarations
Function[] functions();
Struct[] structs();
Class[] classes();
Union[] unions();
Enum[] enums();
}

Then each of those types carries the appropriate information. 
Notably, there are no templates involved, although all code is 
evaluated during compilation. Non-data information (types, 
qualifiers etc) is carried as strings. This allows for simple 
arrays to convey heterogeneous information such as "all 
functions in this module", even though their signatures are 
different.


This makes for a simple and easy to use system for 
introspecting things during compilation. Clearly in order to do 
that some of these compile-time strings must be mixed in, which 
is why https://issues.dlang.org/show_bug.cgi?id=18422 is so 
problematic.


Until we discuss a fix, are there any workarounds?


Thanks,

Andrei


I'm not 100% sure I follow what you need, but maybe one of these 
two will help:


`interface FunctionBase` and `class Function(string name) : 
FunctionBase`.


or

Use a templated constructor `this(string name)()`, so the fields 
are filled during ctfe using "template-time" information. This 
way the type stays the same.

Re: Caesar Cipher

[Seb via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 18:01:20 UTC, Mario wrote:
Hello there! I know deep Java, JavaScript, PHP, etc. but as you 
all probably know, that's high-level and most of them only use 
the heap memory.


[...]



If you want to cheap, have a look at 
https://github.com/dlang-tour/core/issues/227

[Issue 18422] String members and parameters cannot be mixed in, even during CTFE

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
(In reply to Andrei Alexandrescu from comment #0)
> In this case the cure is simple - make Module a template parameterized on
> the module name/alias. But the matter gets a lot more problematic when
> trying to represent e.g. "all function declarations in this module".

If you have a better example, why not show it? How would you implement "all
function declarations in this module" with/without the proposed feature?

Also, this needs to be a full-blown DIP, no? The restriction that all functions
must be compilable for run time is in the spec and widely accepted (as far as
I'm aware). If you want to lift it, you'll have to go into much more detail
than you did here.

--

Re: Workaround for https://issues.dlang.org/show_bug.cgi?id=18422?

[Adam D. Ruppe via Digitalmars-d]

On Sunday, 11 February 2018 at 15:34:07 UTC, Andrei Alexandrescu 
wrote:
My intent is to have a struct Module, which can be initialized 
with a module name; then:


The way I do this is to define the data structures kinda like you 
did, but then have a ctfe/template factory function to return it.


struct Module {
   string name;
   Data[] data;
  // etc
}

Module getModule(string name)() {
  Module mod;
  // populate here using template arg
  mod.name = name;
  mod.data = [__traits(allMembers, mixin(name))];
  // etc
  // return the simple struct
  return mod;
}


Then you can enum it individually:

enum x = getModule!"std.typecons";

and also runtime initialize it and put in an array:

Module[] allModules;

static this() {
   allModules ~= getModule!(__MODULE__);
}




This runtime data, compile time factory pattern I think solves 
everything you want without language changes. Is there anything 
about it you don't like?

Re: Caesar Cipher

[Cym13 via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 18:01:20 UTC, Mario wrote:
Hello there! I know deep Java, JavaScript, PHP, etc. but as you 
all probably know, that's high-level and most of them only use 
the heap memory.


So I'm new to the wonderful world of low-level and the 
stack-heap. I started a week ago learning D (which by the 
moment is being easy for me) but I'm facing a big problem: I 
don't know how to do the exercise of 
https://tour.dlang.org/tour/en/basics/arrays . I really have 
been looking on forums and Google but I found this in Java 
https://stackoverflow.com/questions/10023818/shift-character-in-alphabet which is actually not the best due to Java uses other ways.


My code is something like this:

char[] encrypt(char[] input, char shift)
{
auto result = input.dup;
result[] += shift;
return result;
}


What's wrong? I mean, I know that z is being converted into a 
symbol, but how should I fix this?

Thanks on forward.


Your mistake has little to do with D, and more with Ceasar (which 
is unfortunate IMHO): this cipher is usually defined only on the 
26 letters of the alphabet and seeing the result of the assert at 
the end of the code it's the case here. So while you're working 
on a full byte (256 values) you should restrict yourself to the 
26 lowercase ascii alpha characters.


Give it a try :)

Nightlies not being built so so how do I build dmd-master locally instead?

[Nordlöw via Digitalmars-d]

https://nightlies.dlang.org/ has not been built since 2018-02-01. 
What's wrong?


Can I build dmd master with ldc (need compilation speed) myself? 
If so what's the preferred script?

Caesar Cipher

[Mario via Digitalmars-d-learn]

Hello there! I know deep Java, JavaScript, PHP, etc. but as you 
all probably know, that's high-level and most of them only use 
the heap memory.


So I'm new to the wonderful world of low-level and the 
stack-heap. I started a week ago learning D (which by the moment 
is being easy for me) but I'm facing a big problem: I don't know 
how to do the exercise of 
https://tour.dlang.org/tour/en/basics/arrays . I really have been 
looking on forums and Google but I found this in Java 
https://stackoverflow.com/questions/10023818/shift-character-in-alphabet which is actually not the best due to Java uses other ways.


My code is something like this:

char[] encrypt(char[] input, char shift)
{
auto result = input.dup;
result[] += shift;
return result;
}


What's wrong? I mean, I know that z is being converted into a 
symbol, but how should I fix this?

Thanks on forward.

[Issue 11555] std.algorithm.reverse should return the just-reversed range

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/3acaa9d53ac9d89e2f403ee13f865765f79149cd
Fix Issue 11555 - std.algorithm.reverse should return the just-reversed range

https://github.com/dlang/phobos/commit/2645dba46c4bb71c66868b6e12af1634af8f053a
Merge pull request #6162 from wilzbach/fix-11555

Fix Issue 11555 - std.algorithm.reverse should return the just-reversed range
merged-on-behalf-of: Andrei Alexandrescu 

--

Re: Workaround for https://issues.dlang.org/show_bug.cgi?id=18422?

[Seb via Digitalmars-d]

On Sunday, 11 February 2018 at 15:34:07 UTC, Andrei Alexandrescu 
wrote:
I'm trying to sketch a simple compile-time reflection system, 
and https://issues.dlang.org/show_bug.cgi?id=18422 is a blocker 
of the entire approach. My intent is to have a struct Module, 
which can be initialized with a module name; then:


struct Module
{
private string name;
Data[] data(); // all data declarations
Function[] functions();
Struct[] structs();
Class[] classes();
Union[] unions();
Enum[] enums();
}

Then each of those types carries the appropriate information. 
Notably, there are no templates involved, although all code is 
evaluated during compilation. Non-data information (types, 
qualifiers etc) is carried as strings. This allows for simple 
arrays to convey heterogeneous information such as "all 
functions in this module", even though their signatures are 
different.


This makes for a simple and easy to use system for 
introspecting things during compilation. Clearly in order to do 
that some of these compile-time strings must be mixed in, which 
is why https://issues.dlang.org/show_bug.cgi?id=18422 is so 
problematic.


Until we discuss a fix, are there any workarounds?


Thanks,

Andrei


Here's a workaround:

---
auto moduleSys(string name)()
{
static struct Module
{
auto allMembers()
{
import std.range : only;
assert(__ctfe);
mixin("static import " ~ name ~ ";");
return only(mixin("__traits(allMembers, " ~ name ~ 
")"));

}
}
return Module();
}

unittest
{
enum x = moduleSys!"std.typecons".allMembers;
pragma(msg, x);
}
---


https://run.dlang.io/is/t8KPfq

Re: [Help] programm execution leads to infinity background loop after... what reason?

[Eld0r via Digitalmars-d-learn]

changed my design from extending thread to just using 
taskPool.parallel.
seems like my implementation left to many open threads in 
background and forcing the operation system to cut them off.


thought start() and join() allowed me to use start() again on the 
same thread object in next loop.
But there is some leakage... are they not 'self-closig' after 
finnishing run() ?


works now
but you are welcome to leave a statement.

Re: Bye bye, fast compilation times

[Adam D. Ruppe via Digitalmars-d]

On Sunday, 11 February 2018 at 16:26:19 UTC, aliak wrote:
If anyone wants to do email validation this should be read 
first:


The isemail function isn't about validating email addresses. It 
is just about recognizing something that looks like one. just 
like isurl doesn't actually try to fetch the site to see if it is 
broken, it just sees if it looks like one as a first step.

Re: Bye bye, fast compilation times

[aliak via Digitalmars-d]

On Friday, 9 February 2018 at 14:19:56 UTC, bauss wrote:
Generally the best way to validate an email is just to check if 
there is a value before @ and a value after.


The real way to validate an email is to check if the email 
exists on a SMTP server, BUT some SMTP servers will not provide 
such information (Such as gmail I think?) and thus you can't 
really rely on that either.


+1.

If anyone wants to do email validation this should be read first:

https://hackernoon.com/the-100-correct-way-to-validate-email-addresses-7c4818f24643

Re: Bye bye, fast compilation times

[Nathan S. via Digitalmars-d]

On Wednesday, 7 February 2018 at 08:21:01 UTC, Seb wrote:

There's `version(StdUnittest)` since a few days


And I've just submitted a pull request that adds 
`version(StdUnittest)` to every unittest in the standard library.


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

[Issue 11555] std.algorithm.reverse should return the just-reversed range

[d-bugmail--- via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #8 from Seb  ---
> Let's just have it return the reversed range, it helps with composition.

Easy enough: https://github.com/dlang/phobos/pull/6162

--

[Issue 11555] std.algorithm.reverse should return the just-reversed range

[d-bugmail--- via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

   Keywords||preapproved

--- Comment #7 from Andrei Alexandrescu  ---
Retro changes the type and has a different charter. I think the current
placement is fine because reverse works on bidir ranges, not just arrays. Name
is in keeping with C++ and other languages.

Let's just have it return the reversed range, it helps with composition.

--

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

[Andrei Alexandrescu via Digitalmars-d]

I'm trying to sketch a simple compile-time reflection system, and 
https://issues.dlang.org/show_bug.cgi?id=18422 is a blocker of the 
entire approach. My intent is to have a struct Module, which can be 
initialized with a module name; then:


struct Module
{
private string name;
Data[] data(); // all data declarations
Function[] functions();
Struct[] structs();
Class[] classes();
Union[] unions();
Enum[] enums();
}

Then each of those types carries the appropriate information. Notably, 
there are no templates involved, although all code is evaluated during 
compilation. Non-data information (types, qualifiers etc) is carried as 
strings. This allows for simple arrays to convey heterogeneous 
information such as "all functions in this module", even though their 
signatures are different.


This makes for a simple and easy to use system for introspecting things 
during compilation. Clearly in order to do that some of these 
compile-time strings must be mixed in, which is why 
https://issues.dlang.org/show_bug.cgi?id=18422 is so problematic.


Until we discuss a fix, are there any workarounds?


Thanks,

Andrei

[Issue 18423] rdmd incorrectly assumes that the D compiler outputs dependency info to stdout

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from Joseph Rushton Wakeling  ---
For context, this issue was observed while trying to update rdmd's integration
tests to use gdmd:
https://github.com/dlang/tools/pull/307#issuecomment-363564781

--

Re: A betterC base

[Andrei Alexandrescu via Digitalmars-d]

On 2/10/18 4:41 PM, Walter Bright wrote:

On 2/10/2018 7:14 AM, Dmitry Olshansky wrote:

RC is a form of GC.


Pedantically, yes. But common usage regards the two as disjoint, and 
it's inconvenient to treat RC as a subset of GC when discussing 
tradeoffs between the two. Nobody bothers with s/GC/GC excluding RC/.


"Tracing GC" is the common way of referring to GC techniques outside of 
reference counting. -- Andrei

[Issue 18422] New: String members and parameters cannot be mixed in, even during CTFE

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18422
   Summary: String members and parameters cannot be mixed in, even
during CTFE
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

This limits what can be done with CTFE and forces a variety of compile-time
data structures and functions to be complicated templates without necessity.

Consider a simple module introspection structure:

struct Module
{
string name;
string[] allMembers()
{
assert(__ctfe);
mixin("immutable result = [ __traits(allMembers, " ~ name ~ ") ];");
return result;
}
}

unittest
{
enum x = Module("std.typecons").allMembers;
}

The error is "value of this is not known at compile time". But it can, because
this is itself a compile-time value.

Passing the string as a parameter doesn't help either:

struct Module
{
string[] allMembers(string name)
{
assert(__ctfe, "Can only be invoked during compilation");
mixin("immutable result = [ __traits(allMembers, " ~ name ~ ") ];");
return result;
}
}

unittest
{
enum x = Module().allMembers("std.typecons");
}

Here the error is "variable name cannot be read at compile time". Again that
should work because the code is being evaluated during compilation.

In this case the cure is simple - make Module a template parameterized on the
module name/alias. But the matter gets a lot more problematic when trying to
represent e.g. "all function declarations in this module".

--

[Issue 18423] New: rdmd incorrectly assumes that the D compiler outputs dependency info to stdout

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18423
   Summary: rdmd incorrectly assumes that the D compiler outputs
dependency info to stdout
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: joseph.wakel...@webdrake.net

When `rdmd` invokes the D compiler to generate dependencies information, it
makes a hardcoded assumption that this information gets written by the compiler
to `stdout`.  However, this assumption is not valid for all D compilers.  In
particular, compiler frontend messages are written out to a configurable
`stdmsg`: https://github.com/dlang/dmd/commit/dc8421f

... and this configurability is used by GDC to output such messages to `stderr`
(reflecting GCC policy that `stdout` is reserved for `-pipe` output; see:
https://github.com/dlang/tools/pull/297#issuecomment-363342259).

This means not only that `rdmd` will not work with more recent GDC releases,
but that `rdmd`'s assumptions about `stdout` are not valid in general (given
the configurable `stdmsg` in the DMD frontend).

The gory details


The `getDependencies` function inside `rdmd.d` invokes the D compiler via the
`run` command, passing in options (the `depsGetter` variable) and the name of a
file to which to write the compiler output (`depsFilename`):

```
immutable depsExitCode = run(depsGetter, depsFilename);
```

Internally, `run` takes this and uses `spawnProcess` to invoke the D compiler:

```
private int run(string[] args, string output = null, bool replace = false)
{
...

File outputFile;
if (output.ptr)
outputFile = File(output, "wb");
else
outputFile = stdout;
auto process = spawnProcess(args, stdin, outputFile);
return process.wait();
}
```

In other words, `run` opens a file whose name is given by `depsFilename`, and
uses it to replace `stdout` for the spawned process.  The contents of this file
are then read using the nested `readDepsFile()` function defined internally
inside `getDependencies`.

In consequence, if the information parsed by `readDepsFile` is not written to
`stdout` by the D compiler, it will not get written into `outputFile`, and
therefore not be available to parse.

--

Re: Vanquish Forever These Bugs That Blasted Your Kingdom

[Patrick Schluter via Digitalmars-d-announce]

On Sunday, 11 February 2018 at 15:11:55 UTC, psychoticRabbit 
wrote:
On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky 
wrote:
Other languages like Rust or C# (or Java) have bounds check. 
Plus we probably lose it in release mode, which is the mode 
where lurking bugs are discovered usually days after 
development ;) Some of these languages would prevent it on the 
VM level/compiler level, leaving no way to shoot yourself in 
the foot.




We all really need to get away from this idea that *we* should 
stop *others* from shooting themselves in the foot. People are 
free to do it, if they want. Who has the right to take that 
choice away from me?


So let's NOT be like those other languages that just want to 
control what you do.


-boundscheck=off

D rocks!


That explains why there are so much SJW types in the Rust world 
:-)

Re: Vanquish Forever These Bugs That Blasted Your Kingdom

[Cym13 via Digitalmars-d-announce]

On Sunday, 11 February 2018 at 15:11:55 UTC, psychoticRabbit 
wrote:
On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky 
wrote:
Other languages like Rust or C# (or Java) have bounds check. 
Plus we probably lose it in release mode, which is the mode 
where lurking bugs are discovered usually days after 
development ;) Some of these languages would prevent it on the 
VM level/compiler level, leaving no way to shoot yourself in 
the foot.




We all really need to get away from this idea that *we* should 
stop *others* from shooting themselves in the foot. People are 
free to do it, if they want. Who has the right to take that 
choice away from me?


So let's NOT be like those other languages that just want to 
control what you do.


-boundscheck=off

D rocks!


On the other hand, if my bank shoots itself in the foot it's with 
my money... We must definitely have ways to do it but it must be 
explicit and restricted to where it's useful. There is no need 
for -boundscheck=off in D. It is always possible to disable 
boundschecking locally, and that's a good thing.

Re: typedef behavior

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

On Sunday, 11 February 2018 at 01:32:52 UTC, Alex wrote:

On Saturday, 10 February 2018 at 02:55:26 UTC, Alex wrote:

bug filed

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


Basically, Typedef looks like this:

struct Typedef(T) {
T _payload;
// Forward method calls, member access, etc, to _payload.
}

If T looks like this:

struct T {
static int[3] arr;
void foo() { arr[0]++; }
}

How is Typedef supposed to wrap T.foo in such a way that it uses 
a different arr depending on whether it's called from the Typedef 
or from T?


--
  Simen

Re: Vanquish Forever These Bugs That Blasted Your Kingdom

[psychoticRabbit via Digitalmars-d-announce]

On Wednesday, 7 February 2018 at 20:30:54 UTC, Dmitry Olshansky 
wrote:
Other languages like Rust or C# (or Java) have bounds check. 
Plus we probably lose it in release mode, which is the mode 
where lurking bugs are discovered usually days after 
development ;) Some of these languages would prevent it on the 
VM level/compiler level, leaving no way to shoot yourself in 
the foot.




We all really need to get away from this idea that *we* should 
stop *others* from shooting themselves in the foot. People are 
free to do it, if they want. Who has the right to take that 
choice away from me?


So let's NOT be like those other languages that just want to 
control what you do.


-boundscheck=off

D rocks!

Re: unable to fork: Cannot allocate memory / core.checkedint / gtkd

[number via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 13:17:13 UTC, number wrote:

unable to fork: Cannot allocate memory

if i comment-out the line..
writeln(GdkKeysyms.GDK_Escape);

then it compiles/links/runs fine.

[...]

I actually want to close the application if escape key is 
pressed with

if (eventKey.keyval == GdkKeysyms.GDK_Escape) ...



Some gtkd demo used core.stdc.stdlib.exit to quit the application.
I use widget.destroy now, seems to work fine.

About the compilation error with writeln(), its not a problem 
anymore for me right now. Don't know if this is a [known] issue 
or what the cause is.

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

[German Diago via Digitalmars-d]

On Sunday, 11 February 2018 at 14:33:33 UTC, psychoticRabbit 
wrote:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
Alexandrescu wrote:

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

Andrei


Why indeed!

"I am appalled at the monstrous messes that computer scientists 
can produce under the name of ‘improvements’. It is to efforts 
such as C++ that I here refer. These artifacts are filled with 
frills and features but lack coherence, simplicity, 
understandability and implementability. If computer scientists 
could see that art is at the root of the best science, such 
ugly creatures could never take birth."


If it is not implementable (it is complex, I agree), why there 
are 3 major compilers? I think the future should go towards 
simplification a bit more for the idiomatic code. But there are 
features you cannot ignore in low-level languages: asm embedding, 
bit control, reference vs value, due to register efficiency and 
others. So I do not think it is such a *super bad* choice. In 
day-to-day life you need these things.

Re: dxml 0.1.0 released

[Cym13 via Digitalmars-d-announce]

On Friday, 9 February 2018 at 21:15:33 UTC, Jonathan M Davis 
wrote:

[...]
Of note, dxml does not support the DTD section beyond what is 
required to parse past it

[...]
- Jonathan M Davis


Fun fact, since the most common security vulnerability associated 
with XML (XEE [1]) is based on exploiting the fact that most 
libraries parse in-line DTDs by default, this makes dxml immune 
to such attacks. Given how often this vulnerability is found in 
the wild it sounds like a very good thing to me :D


[1]: 
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing

Re: Fixed size array initialization

[rumbu via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 14:06:32 UTC, rjframe wrote:

On Sat, 10 Feb 2018 10:55:30 +, rumbu wrote:

If you separate initialization to a static this, you'll get a 
compile error:


```
immutable uint256[78] pow10_256;

static this() {
// Error: mismatched array lengths, 78 and 2
pow10_256 = [
uint256(1UL),
uint256(10UL)
];
}
```


Yes, this was in fact the idea of 
https://github.com/dlang/phobos/pull/4936

Didn't like it, sorry.



Or if you know that no element should be the object's init 
value, you could do a static foreach to validate that at 
compile-time.


Nice idea too, but this will significantly increase compilation 
time.




You could also generate the elements at compile-time (this 
could use some improvement, and should be generalized so a 
single function can generate fillers for your other arrays as 
well):


```
immutable uint256[78] pow10_256;

static this() {
// Uncomment this to view the generated code. Helpful for 
debugging.

//pragma(msg, GenPow10_256Initializer);
mixin(GenPow10_256Initializer);
}

static string GenPow10_256Initializer() {
import std.range : repeat;
import std.conv : text;

string code = "pow10_256 = [\n";
foreach(i; 0..78) {
code ~= `uint256("1` ~ '0'.repeat(i).text ~ `")` ~ 
",\n";

}
code = code[0..$-2]; // Remove trailing comma.
code ~= "\n];";
return code;
}
```


As I said in my previous comments, this was the initial approach 
for all the arrays there (I'm a very lazy person, believe me) but 
the compiler complained with a nice "Out of memory" error, that's 
why I ended writing the array elements by hand.

[Help] programm execution leads to infinity background loop after... what reason?

[Eld0r via Digitalmars-d-learn]

I write a code calculating speed & position vectors as steps 
parallel & synced.
each 24 calcultion steps the new positions are written with 
std.json.

This all works fine.

(dmd2 @ Visual Studio 2017 CE 15.5.4, Visual D 0.46.0)

Now when I increase the anmount of steps...
the process lost its... track? - it just does something.
There is no error or debugging message and no hint.

I can write three json, the forth failed.
Now for the best thing of my discovery:
when I switch from x64 to x86 I can write 7 files.

?

so I begin debugging on last successfull writeln()
maybe there are some stupid values in the fourth string.

stepping through with debugger shows that creating a new tag in 
an object contains the last successfull line (in std.json). the 
asignment to aa[] in jsonvalue failed. but not just failed: the 
debugger just dissapears resulting in this infinity 'background 
loop ?' again.


-> Source not available
The debugger information of this module contain no 
sourceinformations.


?

I thought maybe the parameter string is buggy so I just removed 
this last asignment.
But the same happened again. Now I got even more files. I debugg 
again...
And I found: the jump off point change. Debugging now left my 
sourcecode while calling a function returning a new jsonvalue. I 
don't see why, it jumps out on function definition. So I think it 
must happen while allocating new memory for the jsonvalue.


?

switching back to x64:
As expected, now I got half of the files. (keeping the last json 
tag removed)

BUT
It again lost track on annother line of code.
without any influence of json. in step 117 (without export).
this time while creating the parallel calculation:
  foreach (ref w; taskPool.parallel(worktupels, 1)){...}
  --> in parallelism.d @line 3686: int opApply(scope NoIndexDg dg)


So...

Please help me ¯\_(ツ)_/¯

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

[psychoticRabbit via Digitalmars-d]

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

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

Andrei


Why indeed!

"I am appalled at the monstrous messes that computer scientists 
can produce under the name of ‘improvements’. It is to efforts 
such as C++ that I here refer. These artifacts are filled with 
frills and features but lack coherence, simplicity, 
understandability and implementability. If computer scientists 
could see that art is at the root of the best science, such ugly 
creatures could never take birth."


"Since C is low level and object orientation is an inherently 
high level concept the result is conceptually incoherent."


[ R.P.Mody - C in Education and Software Engineering - 1991 ]