Re: opDispatch with string mixin does not work as I would expect.

[Nicholas Wilson via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 06:32:43 UTC, German Diago wrote:

Hello everyone,

I am trying to forward some member functions from a struct as a 
Catch-all function, so I did something like this:


struct A {
struct HeaderData {
  align(1):
  char [21] id;
  ubyte field1;
  ubyte field2;
}

Nullable!(HeaderData) headerData;


auto opDispatch(string name)() {
  readHeader();
  static foreach (member; __traits(allMembers, 
HeaderData)) {

 static if (name == member) {
 return mixin("headerData." ~ name);
 }
  }
  }

The mixin line does not work. I want to generate the access to 
the field. How could I achieve that?


That looks like it should work. Perhaps you need to change
`static if (name == member)` to
`static if (name == member.stringof)`

Alternatively you could do something like

auto opDispatch(string name)() 
if(hasMember!(HeaderData,name){

  readHeader();
  return mixin("headerData." ~ name);
}

Re: opDispatch with string mixin does not work as I would expect.

[Boris-Barboris via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 06:32:43 UTC, German Diago wrote:
The mixin line does not work. I want to generate the access to 
the field. How could I achieve that?



struct Outer
{
struct Inner
{
int a;
float b;
}
Inner i;

auto opDispatch(string name)()
{
return __traits(getMember, i, name);
}
}

opDispatch with string mixin does not work as I would expect.

[German Diago via Digitalmars-d-learn]

Hello everyone,

I am trying to forward some member functions from a struct as a 
Catch-all function, so I did something like this:


struct A {
struct HeaderData {
  align(1):
  char [21] id;
  ubyte field1;
  ubyte field2;
}

Nullable!(HeaderData) headerData;


auto opDispatch(string name)() {
  readHeader();
  static foreach (member; __traits(allMembers, 
HeaderData)) {

 static if (name == member) {
 return mixin("headerData." ~ name);
 }
  }
  }

The mixin line does not work. I want to generate the access to 
the field. How could I achieve that?

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

[Jonathan M Davis via Digitalmars-d]

On Friday, February 09, 2018 19:50:48 Walter Bright via Digitalmars-d wrote:
> On 2/9/2018 1:48 PM, Jonathan M Davis wrote:
> > If I were
> > doing all of my personal projects n C++, I don't know how many would be
> > unit tested.
>
> I know how many. Zero.

If I were writing something like std.datetime in C++, I'd go to the trouble
of writing unit tests, and I've written unit testing frameworks for C++
before for work. So, I don't think that it would necessarily be zero, but
it's certainly true that I'd be a lot less willing to go to the effort, and
I almost certainly wouldn't bother for smaller projects.

- Jonathan M Davis

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

[Walter Bright via Digitalmars-d]

On 2/9/2018 1:48 PM, Jonathan M Davis wrote:

If I were
doing all of my personal projects n C++, I don't know how many would be unit
tested.


I know how many. Zero.

[Issue 6138] Using dirEntries and chdir() can have unwanted results

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

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

--- Comment #7 from Timothee Cour  ---
just hit that bug again, but differently:
```
chdir(foo);
auto files=dirEntries(dirSrc, "*.d",
SpanMode.depth).filter!(a=>a.isFile).map!(a=>dir.buildPath(a.name)).array;
```
crashed similarly

--

Re: typedef behavior

[Alex via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 02:08:50 UTC, Alex wrote:
Inside of the struct E I define more then one static array. 
Namely, one for each Typedef I plan to instantiate. The 
Typedefs have to be known at compile time, so the amount of 
them has to be known by me :)
Then, during the initialization, I work only with one of the 
arrays of E, depending on the Typedef I use.
During the work inside of E, the object will have to check, 
which array was initialized and cooperate with this array, as 
this is the only possibility.


Hmm... No. As the arrays are shared all of them will be 
initialized for every Typedef and the last point (decision during 
the work inside of a single Typedef) can not be achieved. So... 
there has to be another indirection, which will be filled during 
(possibly static) initialization.

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

[Nick Sabalausky via Digitalmars-d]

On Friday, 9 February 2018 at 22:38:23 UTC, H. S. Teoh wrote:


Proposal: unittests should only be compiled if the module it's 
found in is being compiled (i.e., among the modules listed on 
the command-line), even with -unittest.


if I'm using a 3rd party library, why should I care to run 
*their* unittests?  I'm only interested in testing my own code.


What do you think?



Currently being discussed in another thread, but that's an 
emphatic "YES, definitely". I proposed that awhile back and there 
was a bunch of hemming and hawing and ultimately nothing, but I 
really hope something will come of it this time.

Re: Run-time initialised static variables

[dekevin via Digitalmars-d-learn]

On Tuesday, 6 February 2018 at 23:03:07 UTC, dekevin wrote:

Hello everyone,
I just ran into the problem, that I need a static variable, 
where the initialisation code for that variable is only 
accessible during run-time (since part of the initialisation 
code will be dynamically linked).


Is there a way to do this in D?

To be a bit more concrete, this is where I have the problem 
(where ℚ uses GMP, which is dynamically linked):


struct ℚInf {
   ℚ qval;
   immutable static ℚInf zero = ℚInf(0,1);
   this(long num, long den) {
qval = ℚ(num,den); //this initialisation requires 
dynamically linked code

}
}


In case anyone is curios, thanks to tgehr i was able to resolve 
the issue.

For static variables:
struct ℚInf {
ℚ qval;
static ℚInf zero = void;
static this() {
zero = ℚInf(0,1);
}
 }

For immutable static variables (a bit hacky since it sidesteps 
the type system):

struct ℚInf {
ℚ qval;
immutable static ℚInf zero = void;
static this() @trusted {
import std.conv: emplace;
emplace!ℚInf(cast(ℚInf*),ℚInf(0,1));
}
 }

Re: A betterC base

[Seb via Digitalmars-d]

On Friday, 9 February 2018 at 19:50:50 UTC, jmh530 wrote:

On Friday, 9 February 2018 at 19:28:40 UTC, Seb wrote:


Yes, that's the intended goal.
However, to convince everyone involved and to be able to 
experiment with this in the wild for a bit, we went with 
std.experimental first.


If drawbacks get discovered, it's a lot easier to retreat.


Cool.

Do you know if compilation speed improves if using selective 
imports? E.g.

import std.experimental.scripting : writeln;
vs.
import std.experimental.scripting;

I suppose that's a general question wrt public imports, but in 
this case there is probably more to parse than in other smaller 
projects.


AFACIT selective imports have no impact on the compilation speed 
at the moment.
It's quite likely that future versions of the compiler will take 
selective imports into account, but at the moment DMD reads the 
world of everything and only stops at templated 
structs/functions/classes etc.


See also:

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

[Issue 13255] static and selective imports should be done lazily

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

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

Seb  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18414

--

[Issue 18414] New: More lazy symbol resolvement

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

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

  Issue ID: 18414
   Summary: More lazy symbol resolvement
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

tl;dr: imports could reduce a lot of their overhead if the compiler would
resolve symbols only when required.

foo.d
---
struct Foo
{
   import mybigfilewithlotsofctfe;
}
struct Bar;
---

test.d

void main()
{
   import foo;
   Bar b;
}
---

Ideally the compiler wouldn't even look at Foo and thus not open
`mybigfilewithlotsofctfe`. 
Note that this is already done if `struct Foo` is a template.

--

[Issue 13255] static and selective imports should be done lazily

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
Summary|static imports should be|static and selective
   |done lazily |imports should be done
   ||lazily

--

Re: D-dll support: testers needed round 2

[rikki cattermole via Digitalmars-d]

On 09/02/2018 8:34 PM, Benjamin Thaut wrote:
My work on dll support for D continues. There is another iteration I 
need help testing with.


Getting started tutorial: 
http://stuff.benjamin-thaut.de/D/getting_started.html
The DIP can again found be here: 
https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md
The DIP is not up to date. The tutorial is more recent. If the DIP and 
the tutorial contradict each other trust the tutorial. Its still useful 
to read the dip for context, especially as how to use "export" in code.


This time around the shared version of phobos should have all required 
symbols exported. This means when you link against the shared version of 
phobos and find a linker error, please report that here. Ideally with a 
reduced repro case.


A binary distribution is provided, see the tutorial for details.


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

Re: Which language futures make D overcompicated?

[Nick Sabalausky via Digitalmars-d]

On Saturday, 10 February 2018 at 01:24:55 UTC, Timon Gehr wrote:
The fundamental issue is that D's type system has no parametric 
polymorphism,


Pardon my ignorance, but isn't that what D's templated functions 
do? This sounds interesting but unclear exactly what you mean 
here and how it relates to inout and its problems.

Re: typedef behavior

[Alex via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 01:23:20 UTC, Ali Çehreli wrote:

>
> Yup. They are shared by two Typedef instantiations with
different cookies.
>
> So...
> The question is two-fold:
> Would it help to alter the init value of the Typedef?
> If yes, how to alter it?
> If no, is this a bug?

I think this is a limitation of Typedef.

I can't see a way out (at least one that can support any type 
E). It should be possible if you can modify E but I can't work 
something out now.


Ali


Ah... From your hint I arrived at the following:

Inside of the struct E I define more then one static array. 
Namely, one for each Typedef I plan to instantiate. The Typedefs 
have to be known at compile time, so the amount of them has to be 
known by me :)
Then, during the initialization, I work only with one of the 
arrays of E, depending on the Typedef I use.
During the work inside of E, the object will have to check, which 
array was initialized and cooperate with this array, as this is 
the only possibility.


As a workaround this will work, I think... Thanks!

Nevertheless, I would file a bug later on... all ideas are 
appreciated in the meanwhile.

[Issue 18361] Ddoc: support ability to opt out of automatic keyword highlighting in text

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

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

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

   What|Removed |Added

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

--

[Issue 18361] Ddoc: support ability to opt out of automatic keyword highlighting in text

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

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

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

https://github.com/dlang/dmd/commit/9b439afcb10fa81c76cc1a544133f387079fe289
Fix issue 18361: [ddoc] redirect automatically highlighted text in replaceable
macros.

Basically, this is to give the user the ability to opt out of automatic
keyword highlighting in doc text, in the cases where a proliferation of
`_`s would be needed to suppress this behaviour.

The default behaviour is not changed; the default ddoc theme will still
redirect the new macros to the old DDOC_PSYMBOL, DDOC_KEYWORD,
DDOC_PARAM.

https://github.com/dlang/dmd/commit/ab77b875a64b27db17584fe5a7a2678dc1cecadb
Merge pull request #7834 from quickfur/ddoc_autohilite

Fix issue 18361: [ddoc] redirect automatically highlighted text in re…
merged-on-behalf-of: unknown

--

[Issue 8166] retro() of splitter() too

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

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

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Seb  ---
Argh from https://github.com/dlang/phobos/pull/6150


> Making splitter a bidirectional range fundamentally broken - at least if the 
> delimiter has more than one element. Think about something like


If someone ever runs into this problem, you can of course always apply retro
before:


[1, 2, 3].retro.splitter("this is a message")

--

Re: Which language futures make D overcompicated?

[Timon Gehr via Digitalmars-d]

On 09.02.2018 19:31, H. S. Teoh wrote:

On Fri, Feb 09, 2018 at 05:56:38PM +, Dukc via Digitalmars-d wrote:

On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:

Which language futures by your opinion make D harder?

Not many! D is a fairly complex languague, but just about everything
feels like to be here for a good reason. That includes many oft-hated
things: inout, auto ref, goto, BetterC...

TBH, I'm not a fan of inout. Not because of how most people feel, that
we shouldn't have it; IMO it doesn't go*far enough*.


Actually, it goes way too far. :o)

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



For example,
there's currently no way to express conveying the constness of a
delegate argument's parameter to the return value, which would have been
useful in some places in generic code.




The fundamental issue is that D's type system has no parametric 
polymorphism, and 'inout' is an approximation to some special case of 
it, but it is not so clear which special case. It actually differs based 
on context. (IIRC the meaning of 'inout' has subtly changed in the past 
to fix bugs caused by some typing rules assuming one thing when others 
assumed another, and one of them was randomly given precedence.)

Re: typedef behavior

[Ali Çehreli via Digitalmars-d-learn]

On 02/09/2018 05:14 PM, Alex wrote:

>> > struct E
>> > {
>> >  size_t i;
>> >  static T[] tarr;
>>
>> To save time to others, note that 'tarr' is a static member that ends
>> up being shared by two Typedef instantiations.
>
> Yup. They are shared by two Typedef instantiations with different 
cookies.

>
> So...
> The question is two-fold:
> Would it help to alter the init value of the Typedef?
> If yes, how to alter it?
> If no, is this a bug?

I think this is a limitation of Typedef.

I can't see a way out (at least one that can support any type E). It 
should be possible if you can modify E but I can't work something out now.


Ali

Re: Which language futures make D overcompicated?

[Timon Gehr via Digitalmars-d]

On 09.02.2018 19:34, Seb wrote:

On Friday, 9 February 2018 at 18:21:55 UTC, Bo wrote:
Here are a few more "basics" that are unneeded or confusing. Lets not 
even talk about the more advanced features like inout, ...


/-/

* auto: Static typed language yet we fall back on the compiler to 
figure out what is being assigned. Can just as well have a interpreter 
language. It only encourages lazy writing and has a penalty on the 
compilation.


There's almost zero/no penalty on the compilation cost.


On top of that, the penalty is _negative_. If there is no type 
specified, there is no overhead to check that it matches the type of the 
initializer. I can find zero ways in which the above criticism of "auto" 
makes any sense.

Re: typedef behavior

[Alex via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 01:01:39 UTC, Ali Çehreli wrote:

On 02/09/2018 03:45 PM, Alex wrote:
> A question about Typedef usage:
> Say, I have the following circumstances
>
> /// --- code --- ///
>
> import std.typecons;
>
> void main()
> {
>  MyEA ea;
>  MyEB eb;
>  ea.tarr.length = 5;
>  static assert(!is(MyEA == MyEB));
>  static assert(!is(MyEA == E));
>  static assert(!is(MyEB == E));
>  assert(ea.tarr.length == eb.tarr.length); // line 11
>  assert(ea.tarr.length != eb.tarr.length); // line 12

You must have meant

 assert(ea.tarr.ptr != eb.tarr.ptr); // line 12

Indeed, .ptr are unexpectedly the same.



Yes... this is a more precise comparison :)


> }
>
> struct T
> {
>  size_t i;
> }
>
> struct E
> {
>  size_t i;
>  static T[] tarr;

To save time to others, note that 'tarr' is a static member 
that ends up being shared by two Typedef instantiations.


Yup. They are shared by two Typedef instantiations with different 
cookies.


So...
The question is two-fold:
Would it help to alter the init value of the Typedef?
If yes, how to alter it?
If no, is this a bug?



> }
>
> alias MyEA = Typedef!(E, E.init, "A"); // line 26
> alias MyEB = Typedef!(E, E.init, "B"); // line 27
>
> /// --- code ends --- ///
>
> Line 12 yields an assertion error, while line 11 does not.
> This tells me, that despite the fact the types MyEA and MyEB
are
> different they still share the static array, which would
contradict the
> definition of static.
>
> I suppose, the tricky thing is to tweak the init property of
the
> typedefs in lines 26/27 to avoid this clash. How to manage
this?

Ali

Re: typedef behavior

[Ali Çehreli via Digitalmars-d-learn]

On 02/09/2018 03:45 PM, Alex wrote:
> A question about Typedef usage:
> Say, I have the following circumstances
>
> /// --- code --- ///
>
> import std.typecons;
>
> void main()
> {
>  MyEA ea;
>  MyEB eb;
>  ea.tarr.length = 5;
>  static assert(!is(MyEA == MyEB));
>  static assert(!is(MyEA == E));
>  static assert(!is(MyEB == E));
>  assert(ea.tarr.length == eb.tarr.length); // line 11
>  assert(ea.tarr.length != eb.tarr.length); // line 12

You must have meant

 assert(ea.tarr.ptr != eb.tarr.ptr); // line 12

Indeed, .ptr are unexpectedly the same.

> }
>
> struct T
> {
>  size_t i;
> }
>
> struct E
> {
>  size_t i;
>  static T[] tarr;

To save time to others, note that 'tarr' is a static member that ends up 
being shared by two Typedef instantiations.


> }
>
> alias MyEA = Typedef!(E, E.init, "A"); // line 26
> alias MyEB = Typedef!(E, E.init, "B"); // line 27
>
> /// --- code ends --- ///
>
> Line 12 yields an assertion error, while line 11 does not.
> This tells me, that despite the fact the types MyEA and MyEB are
> different they still share the static array, which would contradict the
> definition of static.
>
> I suppose, the tricky thing is to tweak the init property of the
> typedefs in lines 26/27 to avoid this clash. How to manage this?

Ali

[Issue 18403] [REG2.078.2] Access violation when dmd tries to print highlighted code

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

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

--- Comment #3 from Jonathan Marler  ---
Thanks for looking into this.  I noticed this as well a little while ago when I
was trying out dmd-nightly.

--

[Issue 18403] [REG2.078.2] Access violation when dmd tries to print highlighted code

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

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

Jonathan Marler  changed:

   What|Removed |Added

 CC||johnnymar...@gmail.com

--

[Issue 18086] BigInt DivMod

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

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

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #3 from Seb  ---
Works fine for me: 

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

(setting this to RESOLVED FIXED as the PR has been merged)

Are you sure you are using nightly?

--

[Issue 14680] Investigate the use of .di files for Phobos

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

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Andrei Alexandrescu  ---
Yah, also a bunch of functions won't be available for CTFE.

--

[Issue 18413] New: Document how to setup/run DMD test suite on WINDOWS

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

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

  Issue ID: 18413
   Summary: Document how to setup/run DMD test suite on WINDOWS
   Product: D
   Version: D2
  Hardware: x86
   URL: https://wiki.dlang.org/Building_under_Windows
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: johnnymar...@gmail.com

Running the DMD test suite on windows seems to be very rare and documentation
appears to be non-existent.  The following page
(https://wiki.dlang.org/Building_under_Windows) would be a good place to hold
such documentation.

I think the big issue with it is how to install Make/BASH.  I've tried a few
times to get these installed but failed, however, I think I may have been using
a version that was too old.  I'd ask that someone who has successfully gotten
the test suite to run on windows share the steps they used on the wiki page.

--

Re: Somewhat OT: defining algebras in D

[Amorphorious via Digitalmars-d]

On Friday, 9 February 2018 at 17:10:11 UTC, Simen Kjærås wrote:

On Friday, 9 February 2018 at 15:45:11 UTC, Amorphorious wrote:
On Friday, 9 February 2018 at 02:40:06 UTC, Nick Sabalausky 
(Abscissa) wrote:
Well, that's the difference between a formal library package 
release vs sharing a working proof of concept jotted down to 
pass time ;)


Yes, but he can go back an add some friendly text at some 
point... He knows most about it so it is much easier and 
shouldn't take more than a few mins.


Indeed I can, and I have:

https://gist.github.com/Biotronic/833680b37d4afe774c8562fd21554c6b

Doing so after a long, tiring day at work for something I just 
did to pass the time, though - not worth it when I wanted a 
shower and some sleep. Luckily, today was just as boring, so I 
cleaned up the syntax a bit, added more sensible error 
messages, and even made it do the right thing by default when 
you leave out a rule:


alias complex = Algebra!(
float,
"1,i",
"i" * "i".op = -1);
alias dual = Algebra!(
float,
"1,e",
"e" * "e".op = 0);
alias splitComplex = Algebra!(
float,
"1,j",
"j" * "j".op = 1
);
alias quaternion = Algebra!(
float,
"1,i,j,k",
"i,j,k" * "i,j,k".op = -1,
"i,j,k" * "j,k,i".op = "k,i,j".antiCommutative
);

--
  Simen


Lol, thanks, but that wasn't much. What I was thinking is a sort 
of paragraph of text at the top that sorta describes the overall 
conceptualization/overview. One still has to understand how all 
the pieces fit and the only way to learn that is by learning the 
pieces. And English equivalent of D code isn't really all that 
useful because anyone that knows D can understand the D code.


E.g.,

// Create a canonical list of rules from compound rules.
template Canonicalize(string units, Rules...)

is not really all that useful

rather, which I'm making up some type of overview:

"Creates algebraic structures[Algebra!(base type, 
relators/varables, relations...)]  using composition 
rules(relations) to define the structure. To define an algebra 
type, say, the quaternions of base type float,


 alias quaternion = Algebra!(
 float,
 "1,i,j,k",
 "i,j,k" * "i,j,k".op = -1,
 "i,j,k" * "j,k,i".op = "k,i,j".antiCommutative
 );

which can be used a type:

quaternion(a,b,c,d) q;  // Defines the quaternion q = a + bi + cj 
+ dk.


--

the main bulk of defining an algebra as the relations. Each 
relation consists of  a string expressions sk involving the 
realtors expressing the relation equation as


f(s1,..,fn).op = s0

where f is an algebraic function and s0 is a the special 
relator(whatever). relators can be used as a csl.


e.g., for quats,

"i,j,k" * "i,j,k".op = -1

says that i*i = -1, j*j = -1, k*k = -1. Each of the rules could 
have been specified individually:


"i" * "i".op = -1
"j" * "j".op = -1
"k" * "k".op = -1

One can append a string expression using "property syntax":

"i,j,k" * "j,k,i".op = "k,i,j".antiCommutative

.antiCommutative states that the relator is anti commutative. 
Other properties are:




 (no others?)

Once and algebra is established it can then act as any complex 
type and used as a functioning algebra.

"

etc.

The idea here is that to write a few paragraphs of English text 
so that one can read from the start to finish and understanding 
the general idea of what is going on without having to read 
through the entire code(which is much longer) and try to put the 
pieces together. The code I presented is what gleaned from what 
you are trying to accomplish and my knowledge of abstract 
algebra(which most don't have).


What's important is that the average person shouldn't have to 
learn your code to know how to use it. It is not important of the 
details(of which I haven't looked at) but just how to use them. 
While you give examples, which is good, the only problem is one 
can't necessarily glean from those examples how to create their 
own algebras. e.g., what about the GL(n,Z)? Is it possible?



 alias GLnZ = Algebra!(
 Matrix!(n,Z),
 "e_i_j" = 1,
 );

Obviously I doubt this would work, but it would be cool if it 
did, but the only way I could know is if I learned your code and 
tried to figure out how to massage it to work, if it could.. and 
that may take up more time than it would be to do my own 
implementation which I would understand better.


Hence adding clarifications to the code then help one make better 
decisions:


e.g.,

"Base Type must be a D primitive".

(again, the only way one can know if your code supports a general 
type is to learn the code, which may require one to learn all the 
code).



I'm not saying you have to do this, of course... just saying it 
would be more more helpful. I'm not sure how general your code is 
but if one could basically make arbitrary algebraic types, it 
would be very cool indeed and probably be 

typedef behavior

[Alex via Digitalmars-d-learn]

A question about Typedef usage:
Say, I have the following circumstances

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

import std.typecons;

void main()
{
MyEA ea;
MyEB eb;
ea.tarr.length = 5;
static assert(!is(MyEA == MyEB));
static assert(!is(MyEA == E));
static assert(!is(MyEB == E));
assert(ea.tarr.length == eb.tarr.length); // line 11
assert(ea.tarr.length != eb.tarr.length); // line 12
}

struct T
{
size_t i;
}

struct E
{
size_t i;
static T[] tarr;
}

alias MyEA = Typedef!(E, E.init, "A"); // line 26
alias MyEB = Typedef!(E, E.init, "B"); // line 27

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

Line 12 yields an assertion error, while line 11 does not.
This tells me, that despite the fact the types MyEA and MyEB are 
different they still share the static array, which would 
contradict the definition of static.


I suppose, the tricky thing is to tweak the init property of the 
typedefs in lines 26/27 to avoid this clash. How to manage this?

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 06:03 PM, H. S. Teoh wrote:

On Fri, Feb 09, 2018 at 05:13:51PM -0500, Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:

On 02/09/2018 02:01 PM, H. S. Teoh wrote:

Currently, my vibe.d project has a subdirectory containing an empty
dummy dub project, the sole purpose of which is to declare vibe.d
dependencies so that `dub build` in that subdirectory will fetch and
build vibe.d and whatever else it may depend on, and build it into a
linkable state.  Once that's done, I leave dub aside and use SCons
to actually build and link my program with the libraries built by
dub.  This resulted in an instant improvement in my build times by
(at least) half, as well as free me from needless network lookups
when I'm actually coding locally and don't *need* to be upgrading
dependent libraries.


I'm kind of envious of that approach, and REALLY tempted to adopt it
myself, but there are some unfortunate probelms with it (which are
incidentally the exact same reasons I eventually conformed and
begrudgingly strated using dub as my main build tool, as much as I
dislike doing so):

1. From a compiler command-line perspective, trying to incorporate
vibe.d in a project that isn't built with dub proved in my experience
to be a royal pain. And then upgrading to newer versions of vibe.d had
a tendency to break it in non-obvious ways.


The biggest up-front cost is to generate that initial list of import
paths and libraries needed to get the thing to build.  It's not *hard*,
but does require parsing the last few (very long) lines of dub output
(IIRC you need -v to see it).  But since that list changes from time to
time, I'm actually tempted to write a script to parse the dub output and
generate the import/library list automatically.  Then it will become
painless to build things this way. :-D


Yea, *that's* the stuff that gave me trouble. It was also the motivation 
for my "dub describe --data=..." PR, but afterwords I felt like that 
still wasn't quite as good as I wanted, and dub's internal code just 
didn't seem designed to handle that sort of thing anyway (though maybe 
that's improved now?).



Yeah, more and more, it's giving me the impression of being a walled
garden.  You either have to buy into it wholesale, or you're left out in
the cold. :-(  It wouldn't have been such a bad proposal if said walled
garden had nice things going for it... but given dub's limitations, it
feels almost like a prison sentence.


Definitly. A big part of the problem was, at least in the early days, 
the author was very clear that it expressly wasn't intended to cover the 
needs of 100% of packages, just like 99% or whatever. On top of that, 
certain design considerations which were *intended* to avoid 
fragmentation within the dub package ecosystem had the unintended 
consequence of forcing a divide between "dub packages which have the 
luxury of playing by dub's rules" and "non-dub packages which *don't* 
have that luxury". I think that's ultimately what led to the probelms we 
have with dub, and I think solving them properly requires undoing years 
fundamental dub design was that built directly upon those early 
philosophies.

[Issue 18403] [REG2.078.2] Access violation when dmd tries to print highlighted code

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

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

--- Comment #2 from ag0ae...@gmail.com ---
Investigated further. This seems to be a case of dmd miscompiling itself.

The access violation happens in `dmd.tokens.Token.isKeyword` when it accesses
`keywords`. This is because of issue 18412.

Pull request to work around that issue:
https://github.com/dlang/dmd/pull/7859

--

[Issue 18403] [REG2.078.2] Access violation when dmd tries to print highlighted code

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

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||pull

--

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 05:55 PM, H. S. Teoh wrote:


When I found D, I had already been chafing for *years* under the hell
that C++ development was, but could not stand the thought of moving to
Java, because it was just (1) too verbose, and (2) not powerful enough
to express what I want. (That was in the days before Java generics...
though even with generics, I doubt I would've been convinced. It's just
... not quite "there" in terms of expressive power.)



After beginning mainly with various BASICs, I started learning about 
game development which, at the time, meant C (and "C++ as a 
C-with-classes"). So I was pretty deeply into C/C++ stockholm-syndromne 
for a good long while, just 'cause I didn't know any better.


Then a crop of new (at the time) features of C++ started perplexing me, 
but I still didn't know much better. At that point, I was in college at 
the height of the Java craze, so when I inevitably tried Java (v2), it 
was eye-opening: Ruined me on much of C++ almost instantly, and 
simultaneously ruined me on Java itself due to chafing at everything it 
deliberately couldn't do. Nearly ruined me on programming until a search 
for a happy-middle language led me to a very early D (not long after 
templates IIRC, but WELL before v1.0), and I was like "Yes! *This* is 
what I wanted!" :)


Nothing else ever lived up since. (C#, and later Nemerle, came close, 
but no proverbial cigar.)

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 05:49 PM, H. S. Teoh wrote:

On Fri, Feb 09, 2018 at 05:49:31PM -0500, Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:


Really? That's not been my perception.

 From what I've seen, anything that requires the user to mixin a
string, is pretty much automatically granted the black mark of death -
no one will touch it.


Well no, the mixin is not exposed to the user.

But I do see it used quite a lot inside libraries, specifically Phobos.
Well, "quite a lot" is not a fair statement; perhaps I should better say
"more often than it probably should be".  While a mixin-based hack
certainly gains brownie points for cleverness, in the long term it
incurs a maintainability cost, and sometimes a hefty one.  If the mixin
is of significant length, it can be a nightmare to debug / fix / extend.
(And I say that because, yes, to my shame I've also done that in my own
code.)



Ahh, I see. I wonder if the immediate "reach for string mixins" reaction 
is larely, perhaps subconciously, due to impedance of all the asymetric 
mess that dealing with types can otherwise be?

Re: Which language futures make D overcompicated?

[Jonathan M Davis via Digitalmars-d]

On Friday, February 09, 2018 14:49:42 H. S. Teoh via Digitalmars-d wrote:
> On Fri, Feb 09, 2018 at 05:49:31PM -0500, Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
> > On 02/09/2018 05:20 PM, H. S. Teoh wrote:
> > > Sadly, these days it seems almost every other day somebody else
> > > stumbles into a problem to which string mixins seem to be the
> > > default answer.
> >
> > Really? That's not been my perception.
> >
> > From what I've seen, anything that requires the user to mixin a
> > string, is pretty much automatically granted the black mark of death -
> > no one will touch it.
>
> Well no, the mixin is not exposed to the user.
>
> But I do see it used quite a lot inside libraries, specifically Phobos.
> Well, "quite a lot" is not a fair statement; perhaps I should better say
> "more often than it probably should be".

Really? I don't recall seeing the often in Phobos at all. Certainly, some
stuff is best-suited to string mixins (and in the case of overloaded
operators the design calls for using string mixins in order to reduce the
number of declarations you have), but I don't recall seeing them often or
ever having the impression that they were used when they shouldn't be. But I
haven't thought about it a lot either. Personally, I just use them when they
seem most appropriate, and they usually aren't needed much unless I'm doing
something on the crazier side, which isn't often.

- Jonathan M Davis

[Issue 18412] New: [REG2.077.0] immutable array in library becomes null when referenced in static constructor

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

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

  Issue ID: 18412
   Summary: [REG2.077.0] immutable array in library becomes null
when referenced in static constructor
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Keywords: wrong-code
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Spin-off from issue 18403.

m1.d:

import m2: f;
void main() { f(); }


m2.d:

static this()
{
auto k = keywords;
}

immutable int[] keywords = [42];

void f()
{
assert(keywords.ptr !is null); /* fails; should pass */
}


Compile and run (Windows via Wine, DMD32 D Compiler v2.077.0):

dmd -lib m2.d
dmd m1.d m2.lib
./m1.exe


Works with 2.076.1. Works on Linux. Works when the array is mutable. Works when
the array is declared before the static constructor.

--

Re: Which language futures make D overcompicated?

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 09, 2018 at 05:13:51PM -0500, Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
> On 02/09/2018 02:01 PM, H. S. Teoh wrote:
> > Currently, my vibe.d project has a subdirectory containing an empty
> > dummy dub project, the sole purpose of which is to declare vibe.d
> > dependencies so that `dub build` in that subdirectory will fetch and
> > build vibe.d and whatever else it may depend on, and build it into a
> > linkable state.  Once that's done, I leave dub aside and use SCons
> > to actually build and link my program with the libraries built by
> > dub.  This resulted in an instant improvement in my build times by
> > (at least) half, as well as free me from needless network lookups
> > when I'm actually coding locally and don't *need* to be upgrading
> > dependent libraries.
> 
> I'm kind of envious of that approach, and REALLY tempted to adopt it
> myself, but there are some unfortunate probelms with it (which are
> incidentally the exact same reasons I eventually conformed and
> begrudgingly strated using dub as my main build tool, as much as I
> dislike doing so):
> 
> 1. From a compiler command-line perspective, trying to incorporate
> vibe.d in a project that isn't built with dub proved in my experience
> to be a royal pain. And then upgrading to newer versions of vibe.d had
> a tendency to break it in non-obvious ways.

Really?  I haven't had too much trouble with it.  I've been updating
vibe.d from git master occasionally, and the worst that has happened is
that I need to run `dub build --force` to force rebuild of all dependent
libraries, and/or parse dub's output to update the list of libraries /
import paths in my build script.  Sometimes updating Phobos will break
the build because of changes in template symbols and what-not, but so
far `dub build --force` has been the escape ticket.

The biggest up-front cost is to generate that initial list of import
paths and libraries needed to get the thing to build.  It's not *hard*,
but does require parsing the last few (very long) lines of dub output
(IIRC you need -v to see it).  But since that list changes from time to
time, I'm actually tempted to write a script to parse the dub output and
generate the import/library list automatically.  Then it will become
painless to build things this way. :-D


> 2. If you want your project (especially if it's a lib) to participate
> in the the dub package repository ecosystem, you pretty much have to
> support dub as a build tool. Otherwise, anyone who DOES use dub as a
> build tool will have major trouble trying to use your lib.
> 
> So even as a package manager, dub is viral. And the unfortunate
> consequence of that is that it completely divides D package ecosystem
> in two.

Yeah, more and more, it's giving me the impression of being a walled
garden.  You either have to buy into it wholesale, or you're left out in
the cold. :-(  It wouldn't have been such a bad proposal if said walled
garden had nice things going for it... but given dub's limitations, it
feels almost like a prison sentence.


T

-- 
Two wrongs don't make a right; but three rights do make a left...

Re: Which language futures make D overcompicated?

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 09, 2018 at 05:41:28PM -0500, Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
> On 02/09/2018 04:27 PM, Jonathan M Davis wrote:
> > 
> > I have to agree with all of this. I've never found D as a whole to
> > be overly complicated. C++ wins _that_ contest hands down. And I've
> > found languages like Java to be overly simple (e.g. one of my
> > professors in college said that Java didn't become a real language
> > until they added generics, because that actually added some
> > complexity to it). IMHO, any language that's really worth using
> > isn't going to be simple.

/// ditto :-)


[...]
> Any task has an inherent level of complexity. That complexity can be
> either be in the language, or in the user code. Your choice.
> 
> And then there's C++ which manages to CREATE extra needless complexity
> on both sides, thereby falsely convincing entire generations of
> programmers that langauge complexity is inherently bad. No, it's
> *unnecessary* complexity that's bad.

And this in the name of backward compatibility with C, with which it is
not strictly backward-compatible. :-D


> > I originally ended up finding D, because I wanted a language with
> > some of the safety features that Java had but without losing all of
> > the power of C++. C++ had too many problems that resulted in bugs,
> > and Java had stripped out too many features in comparison.
> 
> *Exactly* what led me to D, too. :)

/// ditto :-)

When I found D, I had already been chafing for *years* under the hell
that C++ development was, but could not stand the thought of moving to
Java, because it was just (1) too verbose, and (2) not powerful enough
to express what I want. (That was in the days before Java generics...
though even with generics, I doubt I would've been convinced. It's just
... not quite "there" in terms of expressive power.)

D does have its warts, yeah, but I'm sticking with it for now because it
represents the closest thing to what I consider an ideal programming
language.


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in 
common: they don't depend on the language. -- Luca De Vitis

Re: Which language futures make D overcompicated?

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 9 February 2018 at 20:49:24 UTC, Meta wrote:
was a complicated language, 99 of them would say no. If you ask 
100 Python programmers, 99 would probably say yes.


Yes, but objectively speaking I'd say modern Python is more 
complicated than C++ and D.


What Python got right is that you don't have to deal with the 
complicated stuff unless you are hellbent on dealing with it. 
Python affords a very smooth incremental learning curve, but it 
is still a long learning curve...

Re: Which language futures make D overcompicated?

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 09, 2018 at 05:49:31PM -0500, Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
> On 02/09/2018 05:20 PM, H. S. Teoh wrote:
> > 
> > Sadly, these days it seems almost every other day somebody else
> > stumbles into a problem to which string mixins seem to be the
> > default answer.
> > 
> 
> Really? That's not been my perception.
> 
> From what I've seen, anything that requires the user to mixin a
> string, is pretty much automatically granted the black mark of death -
> no one will touch it.

Well no, the mixin is not exposed to the user.

But I do see it used quite a lot inside libraries, specifically Phobos.
Well, "quite a lot" is not a fair statement; perhaps I should better say
"more often than it probably should be".  While a mixin-based hack
certainly gains brownie points for cleverness, in the long term it
incurs a maintainability cost, and sometimes a hefty one.  If the mixin
is of significant length, it can be a nightmare to debug / fix / extend.
(And I say that because, yes, to my shame I've also done that in my own
code.)


T

-- 
To provoke is to call someone stupid; to argue is to call each other stupid.

Re: Which language futures make D overcompicated?

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 09, 2018 at 10:22:01PM +, rumbu via Digitalmars-d wrote:
[...]
> Personally, I don't use dub. If I need some library, I download and
> add it to my library import path. The only way that dub will convince
> me will be a right click context menu on my VS project entitled
> "Manage DUB packages".  It's an productivity issue: I just press F5 to
> debug my project, why should I go to the command line and type
> manually what I want?
[...]

Your last sentence boggled my mind.  Doesn't VS have the ability for you
to define a macro bound to some hotkey that will automatically go into
the command-line and "type" whatever it is you need to type?

If it doesn't, then all I can say is, no wonder I hate using IDEs.


T

-- 
Skill without imagination is craftsmanship and gives us many useful objects 
such as wickerwork picnic baskets.  Imagination without skill gives us modern 
art. -- Tom Stoppard

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

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 09, 2018 at 01:39:22PM -0800, Walter Bright via Digitalmars-d wrote:
> On 2/9/2018 6:01 AM, Atila Neves wrote:
> > Unit tests are a great idea, right? Try convincing a group of 10
> > programmers who have never written one and don't know anyone else
> > who has. I have; I failed.
> 
> Unit tests are one of the great success stories of D. I believe it was
> a success because it was so simple to add unit tests to the code, and
> to run those tests.

Yeah, it is so simple you feel ashamed for not writing them.  Which in
turn generates a positive feedback loop where your unittests uncovers
bugs early (rather than 2 months later when your customer's box blows
up), so you feel motivated to write more tests, and your code quality
continues improving.


> D's unit testing system didn't even need to be very good. It just had
> to be *easy*. And that changed everything.

Speaking of unittests... currently we have a problem:

import std.regex;
void main() {}

Compiling with -unittest:

real0m1.137s
user0m0.994s
sys 0m0.141s

Compiling without -unittest:

real0m0.528s
user0m0.458s
sys 0m0.069s

The problem: compiling with -unittest causes Phobos unittests to be
instantiated, even if the user isn't compiling Phobos directly.

Proposal: unittests should only be compiled if the module it's found in
is being compiled (i.e., among the modules listed on the command-line),
even with -unittest.

This won't break anything, because as long as user projects compile all
of their modules explicitly, -unittest will still work as before. I'd
guess practically all user projects will do this. (There may be a few
exceptions, e.g., if a module contains only templates, but IIRC even
then you still have to list the module on the command-line, otherwise
some templates won't instantiate correctly.)

It will improve compilation times and reduce executable bloat --
unittests from external libraries that are only linked, not compiled,
won't be included.  It also makes more sense -- if I'm using a 3rd
party library, why should I care to run *their* unittests?  I'm only
interested in testing my own code.

What do you think?


T

-- 
People demand freedom of speech to make up for the freedom of thought which 
they avoid. -- Soren Aabye Kierkegaard (1813-1855)

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 05:20 PM, H. S. Teoh wrote:


Sadly,
these days it seems almost every other day somebody else stumbles into a
problem to which string mixins seem to be the default answer.



Really? That's not been my perception.

From what I've seen, anything that requires the user to mixin a string, 
is pretty much automatically granted the black mark of death - no one 
will touch it.

Re: Which language futures make D overcompicated?

[Ralph Doncaster via Digitalmars-d]

On Friday, 9 February 2018 at 21:05:10 UTC, H. S. Teoh wrote:
On Fri, Feb 09, 2018 at 08:49:24PM +, Meta via 
Digitalmars-d wrote: [...]
I think the perception of D being complicated is more from 
programmers coming from Python/Ruby/JS (and to a lesser 
extent, Haskell/Scheme/Java). D is quite different if you're 
coming from a "VM" or "scripting" language because it exposes 
you to a lot of new concepts such as static typing, value 
types, templates, monomorphization, immutability, memory 
layout, linking and compilation, compile-time vs. runtime, 
etc. It's not that these programmers are less skilled or less 
knowledgeable; it's that if they've never used a language that 
has forced them to consider these concepts, then it looks to 
them like D is a massive step up in complexity compared to the 
language that they're used to.


I think if you asked 100 C++ programmers whether they thought 
D was a complicated language, 99 of them would say no. If you 
ask 100 Python programmers, 99 would probably say yes.


Thanks for this very insightful post.

Before reading this, I couldn't understand why people thought D 
was complex... I come from a strong C/C++ background, so to me 
D is like a breath of fresh air in terms of understandability, 
flexibility, and verbosity level. "Complex" certainly isn't 
what I'd think of when I think about D.  But I suppose if 
someone is coming primarily from a Python background, D could 
certainly be considered quite a step up in perceived complexity!


I've done lots of C++ (though more in the earlier years), and I 
have to disagree.  I'd agree C++11 is more complicated than D, 
but D is still complicated.  I think I've programmed in enough 
languages (from asm, Perl, Java,...) and in large enough projects 
to have a good idea of what languages can be like.


I'll probably continue to stick it out and play with D for 
personal projects because of the things I like and find 
interesting, but professionally it's a no-go (pardon the pun).


Frankly, I think it is doomed to be a niche-use language.  While 
many more things were done right compared to C++, too many things 
were done wrong and there doesn't seem to be interest in breaking 
backward compatibility to excise them from D.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 04:27 PM, Jonathan M Davis wrote:


I have to agree with all of this. I've never found D as a whole to be overly
complicated. C++ wins _that_ contest hands down. And I've found languages
like Java to be overly simple (e.g. one of my professors in college said
that Java didn't become a real language until they added generics, because
that actually added some complexity to it). IMHO, any language that's really
worth using isn't going to be simple.



*nod, nod*

Any task has an inherent level of complexity. That complexity can be 
either be in the language, or in the user code. Your choice.


And then there's C++ which manages to CREATE extra needless complexity 
on both sides, thereby falsely convincing entire generations of 
programmers that langauge complexity is inherently bad. No, it's 
*unnecessary* complexity that's bad.




I originally ended up finding D, because I wanted
a language with some of the safety features that Java had but without losing
all of the power of C++. C++ had too many problems that resulted in bugs,
and Java had stripped out too many features in comparison.


*Exactly* what led me to D, too. :)

Re: Error in template instantiation from D-Cookbook example

[ShadoLight via Digitalmars-d-learn]

On Friday, 9 February 2018 at 21:39:22 UTC, Adam D. Ruppe wrote:

On Friday, 9 February 2018 at 21:31:29 UTC, ShadoLight wrote:

[1] https://run.dlang.io/is/dyElXg


There's missing quotes in there:

Line 14:
code ~= "push(call!"~piece~"(pop(), pop()));\n";

Should be:

code ~= "push(call!\""~piece~"\"(pop(), pop()));\n";

[snip]

On Friday, 9 February 2018 at 21:58:51 UTC, Meta wrote:

On Friday, 9 February 2018 at 21:31:29 UTC, ShadoLight wrote:

[snip]
The problem becomes apparent once you uncomment one of these 
and paste the offending string ("5 5 + 3 - 2 * 1 + 3 /") in.

[snip]

push(call!+(pop(), pop()));

[snip]
So it takes a string as its sole template argument. The problem 
is that the code in convertToD forgot to add the quotes around 
the operators that are supposed to be passed as strings to call.

[snip]

Indeed, that makes sense! Thanks to you both!

Adam, you are right - it was indeed incorrectly mangled... it is 
shown as...

code ~= "push(call!'"~piece~"'(pop(), pop()));\n";

So the escaped quotes \" were mangled as '. I simply removed them 
since I assumed they were typos in the doc, similar to the other 
ones I had fixed. My bad.


Man, I cannot believe how quickly you guys answered. Thanks again!

Re: Which language futures make D overcompicated?

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 09, 2018 at 01:36:50PM -0800, Manu wrote:
>On 9 February 2018 at 11:19, H. S. Teoh via Digitalmars-d
><[1]digitalmars-d@puremagic.com> wrote:
> 
>  >    3. string mixins always used in place of some sort of more
>  >sanitary     macro system
>  [...]
> 
>  That gave me a double-take.  "Sanitary" and "macro" in the same
>  sentence?!  That's just ... I know what you *mean*, but the
>  thought is just, wow. :-D
> 
>I feel like the keyword there was MORE sanitary.
>Writing functions that assemble code into a string is definitely
>not the best way... you lose syntax highlighting, code
>completion/suggestion, refactoring, etc, in any meaningful way.

AFAIK, the original intent was that string mixins would only rarely be
used... At least, that's the impression I got from reading TDPL.  Sadly,
these days it seems almost every other day somebody else stumbles into a
problem to which string mixins seem to be the default answer.


>The less your meta requires you resort to strings, the better...
>and that folds back into my #1 point; storage class separate from
>the type system is the greatest complexity on meta; almost always
>leads to text mixins, because there's no machinery for storage
>classes (or attributes). Can not alias, compound, aggregate...
>anything.
[...]

Truth be told, while I do greatly enjoy D's powerful metaprogramming
features, I also can't help noticing that in some areas it's a little
rough around the edges, and has seemingly-arbitrary asymmetries that
leads to ugliness in generic code. The whole storage class thing is one
example.  As well as historical asymmetries in attributes. Or the
convoluted paraphrases required to do meta coding with attributes. The
functionality is there, but it just needs lots of hoop-jumping,
asymmetric workarounds, and, sadly, string mixins in some cases.

One of the most powerful innovations in D, IMO, is how CTFE allows you
to do compile-time computations *without needing to switch to a special
sub-syntax*.  You just write the code as if it were runtime code, and it
Just Works(tm). This symmetry is what makes it so compelling.  While C++
does offer constexpr, the last time I checked it comes with a number of
syntactic and semantic asymmetries that produce friction and makes it a
little less desirable to work with.

Similarly, compile-time parameters sharing (most of) the runtime
parameter syntax is another winning move that increases symmetry,
reduces friction, and thereby makes it more compelling to work with.

Continuing in the same vein, the syntax required to work directly with
AST entities (as opposed to runtime entities in CTFE) is still a source
of friction. If I want to, say, generate different declarations
depending on what I find in an AliasSeq aka "type tuple", I have to
resort to writing a recursive template instead of just looping over the
sequence.  This is asymmetric, generates friction, and makes it less
pleasant to work with.

In this case, `static foreach` lets you continue using loop syntax, and
is a step in the right direction.  But still, things are still rough
around the edges (e.g., generating unique identifiers to prevent
collision errors, etc.). For example, implementing .map or .joiner over
AliasSeq's would require a lot of ugly paraphrases with recursive
templates, or (shudder) string mixins.

Ideally, compile-time entities should be put on the same level as
runtime entities, so that, for example, you can assign types, storage
classes, function attributes, or indeed AliasSeq's, into compile-time
variables, manipulate them with runtime-like syntax, etc..  This would
remove the unnecessary asymmetries between compile-time / runtime
constructs, reducing friction and thus making it more compelling to work
with.  We may not be able to attain to this ideal given the current
state of things or for historical reasons, but it should be at least a
goal we aim for, rather than introduce more asymmetries to the language.


T

-- 
Fact is stranger than fiction.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 04:58 PM, rumbu wrote:


It's not about how nice is a solution, it's about how easy is for 
someone to find out about a language feature and use it. D has a library 
solution for everything that is missing from the core language instead 
to include in the language well proven patterns.  That's why is 
complicated: one must learn about fibers, ask himself why in the world 
he must use std.concurrency to obtain a list of numbers and so on. Even 
the cluttered ((){ will scare a potential learner.




I agree with this. Though I understand why it ended, I miss the days 
when D was more open to language enhancements. Library solutions are 
often possible, and better then nothing, but by necessity they're also 
frequently sub-optimal (design-wise) as well. One of the most common 
offenders is that all that ((){ *is* visual clutter compared to other 
langauges' takes on equivalent ideas.

Re: dxml 0.1.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Friday, February 09, 2018 13:47:52 H. S. Teoh via Digitalmars-d-announce 
wrote:
> As for DTDs, perhaps it might be enough to make normalize() configurable
> with some way to specify additional entities that may be defined in the
> DTD?  Once that's possible, I'd say it's Good Enough(tm), since the user
> will have the tools to build DTD support from what they're given.  Of
> course, "standard" DTD support can be added later, built on the current
> StAX parser.

As I understand it (though IMHO, the spec isn't clear enough, and I'd have
to go over it with a fine-tooth comb to make sure that I got it right), as
soon as you start dealing with entity references, you can pretty much just
drop whole sections of XML into your document, fundamentally, changing the
document. So, I don't think that it's possible to deal with the entity
references after the fact. They're basically macros that have to be expanded
while you're parsing, which is part of why they're so disgusting IMHO - even
without getting into any of the document validation stuff.

Though honestly, the part about the DTD section that I find truly offensive
is that the document itself is defining what constitutes valid input. Since
when does it make any sense for the _input_ for a program to tell the
program what constitutes valid input? That's for the program to decide. And
considering how much more complicated the parser has to be to properly deal
with the DTD makes its inclusion in the spec seem absolutely insane to me.

And none of that mess is necessary for simple, sane XML documents that are
just providing data.

I _might_ add a DTD parser later, but if I do, it will almost certainly be
its own separate parser. However, given how much of my life I would then be
wasting on something that I consider to be of essentially zero value (if not
negative value), I don't see myself doing it without someone paying me to.
IMHO, the only reason that it makes any sense to fully support the DTD
section is for those poor folks who have to deal with XML documents where
someone else decided to use those features, and they don't have any choice.
I would hope that few programmers would actually _want_ to be using those
features.

> I would support it if you proposed dxml to be added to Phobos.

I've thought about it, but I'd like to complete the writers and the DOM
parser first as well as see it get at least somewhat battle-tested. Right
now, it's just been used in a couple of my personal projects, which did
affect some of my design choices (for the better, I think), but since no one
else has done anything with it, there may be something that it needs that
I've completely missed. The API is simple enough that I _think_ that it's
good as-is and that improvements are largely a question of adding helper
functions, but the library does need more widespread use and feedback.

- Jonathan M Davis

[Issue 18086] BigInt DivMod

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

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

Paul D. Anderson  changed:

   What|Removed |Added

 CC||paul.d.ander...@comcast.net

--- Comment #2 from Paul D. Anderson  ---
I get an access error when calling this function using v2.078.1-master-419f135.

Looking at the code, it seems like the function was never made public, hence
the error.

Is this an oversight or am I mistaken?

Paul

--

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 01:13 PM, Russel Winder wrote:

On Fri, 2018-02-09 at 16:10 +, Seb via Digitalmars-d wrote:



[…]

Dub is not dead, it just has limited resources.


So , if the D community want Dub to work as a build system as well as a
package manager, extend the resources by corralling the grumblers and
support them into fixing code and creating pull requests.

Whilst grumbles on the email list are not turned into evolution of Dub,
the D ecosystem does progress.


[…]




Been there, done that, put enormous work into it, a TON of arguing to 
little avail, found the code architecture difficult to work with, and 
ultimately my merged PRs barely made a dent at solving my issues. Gave 
up. I'm convinced the problems with dub are fundamental and often 
philosophical.


After my experience tring to improve dub, I'm 100% convinced what we 
need is a package manager designed from the ground up to NOT be anything 
but a package manager.

Re: Which language futures make D overcompicated?

[rumbu via Digitalmars-d]

On Friday, 9 February 2018 at 15:53:47 UTC, Russel Winder wrote:
On Fri, 2018-02-09 at 14:04 +, rumbu via Digitalmars-d 
wrote:



[…]
1. Keeps data in the %APPDATA%/Roaming folder. Connecting my 
computer to the company network means that AD will sync 
zillions of files on the company profile server. This issue is 
4 years old: https://github.com/dlang/dub/issues/229


Have you put forward a pull request to fix it, and tests 
obviously.


4 year old issues just mean no-one cares about it enough to do 
something.


4 year old pull requests is time to fork the project with a new 
team of developers.



2. It's painfully slow.
3. As a library provider, you have a lot to learn about
configuration file format (2 formats).


Neither of which are really acceptable. :-(


I wrote a massive decimal library. 90% of reported problems were 
not about the library itself, but about the fact that does not 
compile with dub, does not run with dub, dub doesn't recognize 
package.d and so on. I invested a lot of time in providing a 
clear documentation 
(http://rumbu13.github.io/decimal/doc/decimal.html). Guess what's 
the last issue? Documentation is not visible in the dub registry 
:)




4. Not integrated in Visual Studio. I know, I am a lazy and 
convenient Windows user and the small black window called cmd 
scares the sh*t out of me.


Isn't that a "create a VS plugin" problem?


Personally, I don't use dub. If I need some library, I download 
and add it to my library import path. The only way that dub will 
convince me will be a right click context menu on my VS project 
entitled "Manage DUB packages". It's an productivity issue: I 
just press F5 to debug my project, why should I go to the command 
line and type manually what I want?

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 02:01 PM, H. S. Teoh wrote:


Currently, my vibe.d project has a subdirectory containing an empty
dummy dub project, the sole purpose of which is to declare vibe.d
dependencies so that `dub build` in that subdirectory will fetch and
build vibe.d and whatever else it may depend on, and build it into a
linkable state.  Once that's done, I leave dub aside and use SCons to
actually build and link my program with the libraries built by dub.
This resulted in an instant improvement in my build times by (at least)
half, as well as free me from needless network lookups when I'm actually
coding locally and don't *need* to be upgrading dependent libraries.



I'm kind of envious of that approach, and REALLY tempted to adopt it 
myself, but there are some unfortunate probelms with it (which are 
incidentally the exact same reasons I eventually conformed and 
begrudgingly strated using dub as my main build tool, as much as I 
dislike doing so):


1. From a compiler command-line perspective, trying to incorporate 
vibe.d in a project that isn't built with dub proved in my experience to 
be a royal pain. And then upgrading to newer versions of vibe.d had a 
tendency to break it in non-obvious ways.


2. If you want your project (especially if it's a lib) to participate in 
the the dub package repository ecosystem, you pretty much have to 
support dub as a build tool. Otherwise, anyone who DOES use dub as a 
build tool will have major trouble trying to use your lib.


So even as a package manager, dub is viral. And the unfortunate 
consequence of that is that it completely divides D package ecosystem in 
two.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 10:55 AM, Russel Winder wrote:


Of course whilst people just moan nothing changes. It strikes me as
time to actively evolve Dub or replace it.



A replacement package manager[1] has been on my pet project wish list 
for awhile, but so are a ton of other things and there's not much of me 
to go around. :(


[1] Hopefully backwards compatable with dub packages as much as 
possible, though I don't know how realistic that is given dub's enormous 
complexity.

Re: dxml 0.1.0 released

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

On Fri, Feb 09, 2018 at 02:15:33PM -0700, Jonathan M Davis via 
Digitalmars-d-announce wrote:
> I have multiple projects that need an XML parser, and
> std_experimental_xml is clearly going nowhere, with the guy who wrote
> it having disappeared into the ether, so I decided to break down and
> write one. I've kind of wanted to for years, but I didn't want to
> spend the time on it. However, sometime last year I finally decided
> that I had to, and it's been what I've been working on in my free time
> for a while now. And it's finally reached the point when it makes
> sense to release it - hence this post.

Hooray!  Finally, a glimmer of hope for XML parsing in D!


> Currently, dxml contains only a range-based StAX / pull parser and related
> helper functions, but the plan is to add a DOM parser as well as two writers
> - one which is the writer equivalent of a StaX parser, and one which is
> DOM-based. However, in theory, the StAX parser is complete and quite useable
> as-is - though I expect that I'll be adding more helper functions to make it
> easier to use, and if you find that you're doing a particular operation with
> it frequently and that that operation is overly verbose, please point it out
> so that maybe a helper function can be added to improve that use case - e.g.
> I'm thinking of adding a function similar to std.getopt.getopt for handling
> attributes, because I personally find that dealing with those is more
> verbose than I'd like. Obviously, some stuff is just going to do better with
> a DOM parser, but thus far, I've found that a StAX parser has suited my
> needs quite well. I have no plans to add a SAX parser, since as far as I can
> tell, SAX parsers are just plain worse than StAX parsers, and the StAX
> approach is quite well-suited to ranges.
> 
> Of note, dxml does not support the DTD section beyond what is required to
> parse past it, since supporting it would make it impossible for the parser
> to return slices of the original input beyond the case where strings are
> used (and it would be forced to allocate strings in some cases, whereas dxml
> does _very_ minimal heap allocation right now), and parsing the DTD section
> signicantly increases the complexity of the parser in order to support
> something that I honestly don't think should ever have been part of the XML
> standard and is unnecessary for many, many XML documents. So, if you're
> dealing with XML documents that contain entity references that are declared
> in the DTD section and then used outside of the DTD section, then dxml will
> not support them, but it will work just fine if a DTD section is there so
> long as it doesn't declare any entity references that are then referenced in
> the document proper.
> 
> Hopefully, the documentation is clear enough, but obviously, I'm not
> the best judge of that. So, have at it.
> 
> Documentation: http://jmdavisprog.com/docs/dxml/0.1.0/
> Github: https://github.com/jmdavis/dxml
> Dub: http://code.dlang.org/packages/dxml
[...]

Wonderful!  The docs are beautiful, I must say.  Good job on that.
Though a simple example of basic usage in the module header would be
very nice.

Glanced over the docs.  It's a pretty nice and clean API, and IMO,
worthy of consideration to be included into Phobos.  IMO, the lack of
SAX / DOM parsing is not a big deal, since it's not hard to build one
given StAX primitives.

Being range-based is very nice, but I'd say your choice to slice the
input, defer expensive/allocating operations to normalize() is a big
winning point.  This approach is fundamental to high performance, in the
principle of not doing any operation that isn't strictly necessary until
it's actually asked for.  If nothing else, this is a good design pattern
that I plan to st^Wcopy in my own code. :-P

As for DTDs, perhaps it might be enough to make normalize() configurable
with some way to specify additional entities that may be defined in the
DTD?  Once that's possible, I'd say it's Good Enough(tm), since the user
will have the tools to build DTD support from what they're given.  Of
course, "standard" DTD support can be added later, built on the current
StAX parser.

I would support it if you proposed dxml to be added to Phobos.


T

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

Re: Which language futures make D overcompicated?

[rumbu via Digitalmars-d]

On Friday, 9 February 2018 at 16:35:47 UTC, Seb wrote:

On Friday, 9 February 2018 at 15:06:49 UTC, rumbu wrote:


All understood, but just to get your mind set better, I would 
have two quick follow-up questions if you don't mind.


On Friday, 9 February 2018 at 15:06:49 UTC, rumbu wrote:

rough C# translation:

async void spawnedFunc()
{
int i = await receive();
}


OK, but that's because Phobos has no eventloop.
With Vibe.d it looks like this:


```d
auto val = async({
 return 32;
}).getResult;
```

Is this really so different or what exactly do you miss from 
the language?



C#:

IEnumerable Fibonacci(int limit)
{
   int a = 1, b = 1;
   while (a < limit)
   {
 yield return a;  //syntactic sugar
 var t = a;
 a = b;
 b = t + b;
   }
}


So your point is that std.concurrency.Generator isn't so nice? 
Not advertised?
Or do you simply want to have a keyword that wraps a function 
into generator like function* in ES6?


---
auto fib = (int limit){
import std.concurrency;
return new Generator!int((){
int a = 1, b = 1;
while (a < limit)
{
a.yield; //syntactic sugar
auto t = a;
a = b;
b = t + b;
}
});
};
---

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



It's not about how nice is a solution, it's about how easy is for 
someone to find out about a language feature and use it. D has a 
library solution for everything that is missing from the core 
language instead to include in the language well proven patterns. 
 That's why is complicated: one must learn about fibers, ask 
himself why in the world he must use std.concurrency to obtain a 
list of numbers and so on. Even the cluttered ((){ will scare a 
potential learner.


This is the documentation for C#:
You use a *yield return* statement to return each element one at 
a time.

You can use a *yield break* statement to end the iteration.

Now, as an exercise, please explain for a newbie in two sentences 
the Generator class, the yield function and why should we need 
concurrency and fibers stuff for this.


Modern languages are evolving over time, D had a good start 
inspiring himself from popular language features (at that time I 
suppose it was Java), now it's stalling trying to win an 
impossible bet on C/C++ compatibility instead of evolving in its 
own way. Features are dropped from the language and moved to 
library solutions. Library solutions often result in 
incomprehensible compiler error messages, and that's normal, the 
compiler has not enough information to provide a decent error 
message.


Is the concept of range a first class citizen in D? If yes, the 
language must provide the necessary syntax for repetitive 
patterns linked to ranges and hide behind the scene the details. 
Are the fibers the de facto way to deal with concurrency in D? If 
yes, the language must provide the necessary syntax to write 
fiber-oriented code. This will not stop anyone to write his 
state-of-the-art-hand-made range or fiber solution, but it will 
help the potential learner to understand immediately how to deal 
with ranges or fibers.


A similar remark I have for traits: a lot of emphasis is put on 
compile time reflection, but to use it, you need to import 8200 
lines of code from std.traits.

Re: Error in template instantiation from D-Cookbook example

[Meta via Digitalmars-d-learn]

On Friday, 9 February 2018 at 21:31:29 UTC, ShadoLight wrote:

writeln(parse(code));   // to aid with debugging
writeln(convertToD(parse(code)));   // debugging aid
..to..
writeln(parse(code)[]); // to aid with debugging
writeln(convertToD(parse(code))[]); // debugging aid


The problem becomes apparent once you uncomment one of these and 
paste the offending string ("5 5 + 3 - 2 * 1 + 3 /") in. 
`writeln(convertToD(parse("5 5 + 3 - 2 * 1 + 3 /"))[]);` prints 
the following:


push(5);
push(5);
push(call!+(pop(), pop()));
push(3);
push(call!-(pop(), pop()));
push(2);
push(call!*(pop(), pop()));
push(1);
push(call!+(pop(), pop()));
push(3);
push(call!/(pop(), pop()));

If you look at the definition of call:

int call(string op)(int a, int b) {
return mixin("b"~op~"a");
}

So it takes a string as its sole template argument. The problem 
is that the code in convertToD forgot to add the quotes around 
the operators that are supposed to be passed as strings to call. 
If you modify line 14 from the example you pasted to add these 
quotes to the mixin string, it works:


code ~= "push(call!"~piece~"(pop(), pop()));\n";

becomes

code ~= "push(call!\""~piece~"\"(pop(), pop()));\n";

Running the modified code, it prints:

push(5);
push(5);
push(call!"+"(pop(), pop()));
push(3);
push(call!"-"(pop(), pop()));
push(2);
push(call!"*"(pop(), pop()));
push(1);
push(call!"+"(pop(), pop()));
push(3);
push(call!"/"(pop(), pop()));

And `runDslCode!"5 5 + 3 - 2 * 1 + 3 /"();` prints `[5]`.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 08:51 AM, Atila Neves wrote:

On Friday, 9 February 2018 at 13:34:01 UTC, tetyys wrote:


Why do people hate dub? I think it's a great package manager and build 
tool


Great package manager? Yes.

Great build tool? No.


I used to feel the same way, but honestly, at this point, I have to 
conclude dub sucks as a package manager too just *because* it's such a 
rediculous pain to opt-out of all it's weak points, like using it as a 
build tool. Particularly if you're a library author.

Re: Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/09/2018 08:53 AM, Seb wrote:

On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:


I'm missing too the yield return and await syntax in D every time.


What's wrong with the library solution from std.concurrency?



I can't speak for await, as I left C# for D long before it was introduced.

But as far as yield return (ie, C#'s coroutines): The problem with the 
std.concurrency version is that it introduces the overhead of fibers and 
context-switching. Sometimes that's ok (network/file i/o), sometimes 
it's not (parsing). (You *can* switch to foreach/apply to do it, but 
then you lose the ability to offer a range-based interface...unless you 
re-introduce fibers.)


But the C# version, OTOH, lacks this fiber overhead entirely: 
Internally, it works the same way as C's protothreads 
, but with far nicer syntax.



- no dedicated syntax sugar for ranges;


What do you expect here?
(also it's not entirely true - foreach already supports ranges)



For input ranges (maybe even forward ranges), a stackless corountine 
approach like C#.


But even for all-out random-access, defining them is quite boiler-plate 
heavy (by D standards anyway) and could really use some sugar. Exactly 
what that sugar would be like, I don't know, but it could definitely use 
some.



- no dedicated syntax sugar for coroutines;


What syntax sugar that can't be done by a library do you expect?



Doing it without the overhead of fibers. This requires either a C-style 
preprocesser (yuck, and note string mixins aren't sufficient here) or 
lowering. (I guess if we had AST macros, maybe we could do this lowering 
in the library, but we don't.)

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

[Walter Bright via Digitalmars-d]

On 2/9/2018 6:49 AM, Jonathan M Davis wrote:

The amazing thing is when a programmer tries to argue that having unit tests
makes your code worse - not that they take too long to write or that they
don't want to bother with them or any that - that they somehow make the code
worse.


It's not amazing at all :-)

The reasons people give to not try something new are hardly ever the actual 
reasons. People will make up on the spot reasons that they think you want to 
hear or that sound good. Their actual reasons they keep to themselves because 
they don't sound good.


If you talk with someone enough you'll eventually figure out their actual 
reasons.

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

[Jonathan M Davis via Digitalmars-d]

On Friday, February 09, 2018 13:39:22 Walter Bright via Digitalmars-d wrote:
> On 2/9/2018 6:01 AM, Atila Neves wrote:
> > Unit tests are a great idea, right? Try convincing a group of 10
> > programmers who have never written one and don't know anyone else who
> > has. I have; I failed.
> Unit tests are one of the great success stories of D. I believe it was a
> success because it was so simple to add unit tests to the code, and to
> run those tests.
>
> D's unit testing system didn't even need to be very good. It just had to
> be *easy*. And that changed everything.

Yeah. git did the same thing for me for source control. Before, I almost
never did anything with source control with my personal projects, because it
was too much of a pain to set up; you basically had to set up a server to
talk to (even if it was on the same machine), whereas with git, it's just

git init .

and you have a repository. Now, all my source code goes in a git repo unless
it's just a quick test that I'm going to throw away when I'm done. And the
fact that places like github and bitbucket make it so easy to create repos
online means that a lot of my stuff is online too, whereas if I had to use
something like SVN, I'd probably have next to nothing in source control.

And the way that D handles unit tests has had the same effect. If I were
doing all of my personal projects n C++, I don't know how many would be unit
tested. Anything really serious would be, but the extra effort of setting
something up to be able to have unit tests is enough that anything simple
would probably never have any tests, because it would be too much effort for
me to bother. Having unit tests built-in is definitely a game changer.

- Jonathan M Davis

Re: Error in template instantiation from D-Cookbook example

[Adam D. Ruppe via Digitalmars-d-learn]

On Friday, 9 February 2018 at 21:31:29 UTC, ShadoLight wrote:

[1] https://run.dlang.io/is/dyElXg


There's missing quotes in there:

Line 14:
code ~= "push(call!"~piece~"(pop(), pop()));\n";

Should be:

code ~= "push(call!\""~piece~"\"(pop(), pop()));\n";


That might have been an error in the original book. A lot of 
quotes and semicolons got mangled in the process of copying them 
from the actual compilable examples into the MS Word manuscript..


But to explain why this is wrong just consider the code generated:

push(call!+(pop(), pop()));


When the operator is pasted in without quotes, you get the above. 
And + isn't a valid template arg. But "+" is.

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

[Walter Bright via Digitalmars-d]

On 2/9/2018 6:01 AM, Atila Neves wrote:
Unit tests are a great idea, right? Try convincing a group of 10 programmers who 
have never written one and don't know anyone else who has. I have; I failed.


Unit tests are one of the great success stories of D. I believe it was a success 
because it was so simple to add unit tests to the code, and to run those tests.


D's unit testing system didn't even need to be very good. It just had to be 
*easy*. And that changed everything.

Re: Which language futures make D overcompicated?

[Manu via Digitalmars-d]

On 9 February 2018 at 11:19, H. S. Teoh via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

>
> >3. string mixins always used in place of some sort of more sanitary
> >macro system
> [...]
>
> That gave me a double-take.  "Sanitary" and "macro" in the same
> sentence?!  That's just ... I know what you *mean*, but the thought is
> just, wow. :-D
>

I feel like the keyword there was MORE sanitary.
Writing functions that assemble code into a string is definitely not the
best way... you lose syntax highlighting, code completion/suggestion,
refactoring, etc, in any meaningful way.
The less your meta requires you resort to strings, the better... and that
folds back into my #1 point; storage class separate from the type system is
the greatest complexity on meta; almost always leads to text mixins,
because there's no machinery for storage classes (or attributes). Can not
alias, compound, aggregate... anything.

Error in template instantiation from D-Cookbook example

[ShadoLight via Digitalmars-d-learn]

Hi,

Trying to improve my CT-fu, I looked at a DSL example (chapter 9) 
in Adam's D-Cookbook. Although I am sure Adam's original examples 
would have worked, there were some errors in the example code in 
the book.


The example also contains some code to allow you to test the 
functions at RT, which had an error i.e. I had to change this...


writeln(parse(code));   // to aid with debugging
writeln(convertToD(parse(code)));   // debugging aid
..to..
writeln(parse(code)[]); // to aid with debugging
writeln(convertToD(parse(code))[]); // debugging aid

..to match the actual function arguments. So that worked fine.

However I could not get the CT version to work with the current 
version of DMD i.e. this [1]...


[1] https://run.dlang.io/is/dyElXg

...fails with:
onlineapp.d-mixin-36(38): Error: template argument expected 
following !
onlineapp.d(48): Error: template instance onlineapp.runDslCode!"5 
5 + 3 - 2 * 1 + 3 /" error instantiating.


I find the error message a bit lacking as to the real cause - I 
really cannot see where the "template argument expected following 
!" error is. It all looks correct to me.


In addition the RT version is working correctly (after fixing the 
above bug), so that is not helping in identifying the error - 
particularly since it is failing in the only CT specific function 
not used/called at RT. So I am not sure how to debug this.


Can somebody please put me out of my misery here?

Thx!

Re: A betterC base

[Walter Bright via Digitalmars-d]

On 2/9/2018 6:11 AM, Atila Neves wrote:

It's easy enough to create std package like this:

module std;
public import std.algorithm;
//...


Yes, but I suspect that'll be a large negative for compile speed for smallish 
programs.

Re: Which language futures make D overcompicated?

[Jonathan M Davis via Digitalmars-d]

On Friday, February 09, 2018 20:49:24 Meta via Digitalmars-d wrote:
> On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
> > I like D, but sometimes it's look like for me too complicated.
> > Go have a lot of fans even it not simple, but primitive. But
> > some D futures make it very hard to learning.
> >
> > Small list by me:
> > 1. mixins
> > 2. inout
> > 3. too many attributes like: @safe @system @nogc etc
> >
> > Which language futures by your opinion make D harder?
>
> I can't say that I've ever really found D complicated. I think
> the main reason for that is because my first language was C++,
> and there's really nowhere to go but up from there (I was
> experienced with a few other languages as well like Java, Scheme,
> Basic, etc. but none I would regard as complex).
>
> I think the perception of D being complicated is more from
> programmers coming from Python/Ruby/JS (and to a lesser extent,
> Haskell/Scheme/Java). D is quite different if you're coming from
> a "VM" or "scripting" language because it exposes you to a lot of
> new concepts such as static typing, value types, templates,
> monomorphization, immutability, memory layout, linking and
> compilation, compile-time vs. runtime, etc. It's not that these
> programmers are less skilled or less knowledgeable; it's that if
> they've never used a language that has forced them to consider
> these concepts, then it looks to them like D is a massive step up
> in complexity compared to the language that they're used to.
>
> I think if you asked 100 C++ programmers whether they thought D
> was a complicated language, 99 of them would say no. If you ask
> 100 Python programmers, 99 would probably say yes.

I have to agree with all of this. I've never found D as a whole to be overly
complicated. C++ wins _that_ contest hands down. And I've found languages
like Java to be overly simple (e.g. one of my professors in college said
that Java didn't become a real language until they added generics, because
that actually added some complexity to it). IMHO, any language that's really
worth using isn't going to be simple.

Now, that's not to say that I think that every feature in D should be there
(e.g. I'd rather that template specializations not exist, because template
constraints make them completely unnecessary and ultimately an unnecessary
complication), and there have certainly been mistakes made along the way
(e.g. auto-decoding was a mistake, and @property never went anywhere like it
was supposed to, leaving it there kind of like an appendix). But I wouldn't
really say that D is overly complicated, just that it could be better.

But I also come from a C++ background, which significantly colors my view of
things. I suspect that I'd have a very different viewpoint if I'd started
with something like Java, python, or Go, since those languages are all far
simpler. But then again, maybe I'd still end up finding D's level of power
and complexity refreshing. I originally ended up finding D, because I wanted
a language with some of the safety features that Java had but without losing
all of the power of C++. C++ had too many problems that resulted in bugs,
and Java had stripped out too many features in comparison. Fortunately, D
has proven to provide a good balance in that respect - not perfect, but by
far the best I've encountered.

- Jonathan M Davis

Re: A betterC base

[Walter Bright via Digitalmars-d]

On 2/9/2018 1:14 AM, meppl wrote:
let's say python is supposed to offer slow execution. So, python doesn't prove 
reference counting is fast (even if it is possible in theory). D on the other 
hand provides binaries who are expected to execute fast.


I believe it has been shown (sorry, no reference) that GC is faster in aggregate 
time, and RC is perceived faster because it doesn't have pauses.


This makes GC better for batch jobs, and RC better for interactive code.

Of course, the issue can get more complex. GC uses 3x the memory of RC, and so 
you can get extra slowdowns from swapping and cache misses.

dxml 0.1.0 released

[Jonathan M Davis via Digitalmars-d-announce]

I have multiple projects that need an XML parser, and std_experimental_xml
is clearly going nowhere, with the guy who wrote it having disappeared into
the ether, so I decided to break down and write one. I've kind of wanted to
for years, but I didn't want to spend the time on it. However, sometime last
year I finally decided that I had to, and it's been what I've been working
on in my free time for a while now. And it's finally reached the point when
it makes sense to release it - hence this post.

Currently, dxml contains only a range-based StAX / pull parser and related
helper functions, but the plan is to add a DOM parser as well as two writers
- one which is the writer equivalent of a StaX parser, and one which is
DOM-based. However, in theory, the StAX parser is complete and quite useable
as-is - though I expect that I'll be adding more helper functions to make it
easier to use, and if you find that you're doing a particular operation with
it frequently and that that operation is overly verbose, please point it out
so that maybe a helper function can be added to improve that use case - e.g.
I'm thinking of adding a function similar to std.getopt.getopt for handling
attributes, because I personally find that dealing with those is more
verbose than I'd like. Obviously, some stuff is just going to do better with
a DOM parser, but thus far, I've found that a StAX parser has suited my
needs quite well. I have no plans to add a SAX parser, since as far as I can
tell, SAX parsers are just plain worse than StAX parsers, and the StAX
approach is quite well-suited to ranges.

Of note, dxml does not support the DTD section beyond what is required to
parse past it, since supporting it would make it impossible for the parser
to return slices of the original input beyond the case where strings are
used (and it would be forced to allocate strings in some cases, whereas dxml
does _very_ minimal heap allocation right now), and parsing the DTD section
signicantly increases the complexity of the parser in order to support
something that I honestly don't think should ever have been part of the XML
standard and is unnecessary for many, many XML documents. So, if you're
dealing with XML documents that contain entity references that are declared
in the DTD section and then used outside of the DTD section, then dxml will
not support them, but it will work just fine if a DTD section is there so
long as it doesn't declare any entity references that are then referenced in
the document proper.

Hopefully, the documentation is clear enough, but obviously, I'm not the
best judge of that. So, have at it.

Documentation: http://jmdavisprog.com/docs/dxml/0.1.0/
Github: https://github.com/jmdavis/dxml
Dub: http://code.dlang.org/packages/dxml

- Jonathan M Davis

Re: Which language futures make D overcompicated?

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 09, 2018 at 08:49:24PM +, Meta via Digitalmars-d wrote:
[...]
> I think the perception of D being complicated is more from programmers
> coming from Python/Ruby/JS (and to a lesser extent,
> Haskell/Scheme/Java). D is quite different if you're coming from a
> "VM" or "scripting" language because it exposes you to a lot of new
> concepts such as static typing, value types, templates,
> monomorphization, immutability, memory layout, linking and
> compilation, compile-time vs. runtime, etc. It's not that these
> programmers are less skilled or less knowledgeable; it's that if
> they've never used a language that has forced them to consider these
> concepts, then it looks to them like D is a massive step up in
> complexity compared to the language that they're used to.
> 
> I think if you asked 100 C++ programmers whether they thought D was a
> complicated language, 99 of them would say no. If you ask 100 Python
> programmers, 99 would probably say yes.

Thanks for this very insightful post.

Before reading this, I couldn't understand why people thought D was
complex... I come from a strong C/C++ background, so to me D is like a
breath of fresh air in terms of understandability, flexibility, and
verbosity level. "Complex" certainly isn't what I'd think of when I
think about D.  But I suppose if someone is coming primarily from a
Python background, D could certainly be considered quite a step up in
perceived complexity!


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see 
through walls. It was called the "window".

Re: Which language futures make D overcompicated?

[John Gabriele via Digitalmars-d]

On Friday, 9 February 2018 at 19:08:36 UTC, John Gabriele wrote:


Would it make sense to split out dub's build functionality from 
its package management? Separate sharp tools for separate jobs.


I've only heard of Atila's reggae today. Is reggae commonly 
used among D users? Are there any show stoppers to using it in 
place of dub for building dub-managed projects?


Ah. I see that I should probably first look into Meson and SCons 
as well as Reggae.

Re: Which language futures make D overcompicated?

[Meta via Digitalmars-d]

On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
I like D, but sometimes it's look like for me too complicated. 
Go have a lot of fans even it not simple, but primitive. But 
some D futures make it very hard to learning.


Small list by me:
1. mixins
2. inout
3. too many attributes like: @safe @system @nogc etc

Which language futures by your opinion make D harder?


I can't say that I've ever really found D complicated. I think 
the main reason for that is because my first language was C++, 
and there's really nowhere to go but up from there (I was 
experienced with a few other languages as well like Java, Scheme, 
Basic, etc. but none I would regard as complex).


I think the perception of D being complicated is more from 
programmers coming from Python/Ruby/JS (and to a lesser extent, 
Haskell/Scheme/Java). D is quite different if you're coming from 
a "VM" or "scripting" language because it exposes you to a lot of 
new concepts such as static typing, value types, templates, 
monomorphization, immutability, memory layout, linking and 
compilation, compile-time vs. runtime, etc. It's not that these 
programmers are less skilled or less knowledgeable; it's that if 
they've never used a language that has forced them to consider 
these concepts, then it looks to them like D is a massive step up 
in complexity compared to the language that they're used to.


I think if you asked 100 C++ programmers whether they thought D 
was a complicated language, 99 of them would say no. If you ask 
100 Python programmers, 99 would probably say yes.

Re: A betterC base

[Rubn via Digitalmars-d]

On Friday, 9 February 2018 at 02:09:57 UTC, Jonathan M Davis 
wrote:
On Thursday, February 08, 2018 23:57:45 Rubn via Digitalmars-d 
wrote:
On Thursday, 8 February 2018 at 18:06:38 UTC, Walter Bright 
wrote:

> I.e. it isn't an issue of us D guys being dumb about the GC.

So you could say it's a design flaw of D, attempting to use a 
GC where it isn't suited?


You could say that, but many of us would not agree. Just 
because certain classes of GCs cannot be used with D does not 
mean that the fact that D has a GC built-in is not beneficial 
and ultimately a good design decision. Plenty of folks have 
been able to write very efficient code that uses D's GC. 
Obviously, there are use cases where it's better to avoid the 
GC, but for your average D program, the GC has been a fantastic 
asset.


- Jonathan M Davis


I didn't say that a GC isn't beneficial, the problem is if you 
are going to be using the GC there are plenty of other languages 
that implement it better. The language is designed around the GC. 
Anytime I try and use an associative array, my program crashes 
because of the GC. The workaround I need to do is just make every 
associative array static. Maybe if phobos could be built into a 
shared library it wouldn't be as big of a problem. But that's not 
the case, before someone goes around crying that Phobos CAN be 
built into a shared library, remember platform matters!


You can write efficient code with Java, and that has an entire VM 
running between the cpu and the language. Efficiency isn't the 
issue. Writing code that is both GC and non-GC code is extremely 
difficult to do correctly. That it just isn't worth it at the end 
of the day, it complicates everything, and that is the design 
flaw. Having to use a complicated inefficient GC is just a side 
effect of the greater issue.

D-dll support: testers needed round 2

[Benjamin Thaut via Digitalmars-d]

My work on dll support for D continues. There is another 
iteration I need help testing with.


Getting started tutorial: 
http://stuff.benjamin-thaut.de/D/getting_started.html
The DIP can again found be here: 
https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md
The DIP is not up to date. The tutorial is more recent. If the 
DIP and the tutorial contradict each other trust the tutorial. 
Its still useful to read the dip for context, especially as how 
to use "export" in code.


This time around the shared version of phobos should have all 
required symbols exported. This means when you link against the 
shared version of phobos and find a linker error, please report 
that here. Ideally with a reduced repro case.


A binary distribution is provided, see the tutorial for details.

[Issue 14543] std.algorithm.searching.until does not handle range sentinels nicely

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
Agreed. Any idea how we can fix this without breaking code? Do we need to
introduce a special enum?

OpenRight {
 yes,
 no,
 full
}

--

[Issue 14680] Investigate the use of .di files for Phobos

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from Seb  ---
Tried it here: https://github.com/dlang/phobos/pull/6123

tl;dr: it's not worth it and brings a lot of troubles with it. We simple should
make the imports faster.
I'm incled to close this as WONTFIX as the investigation is over.

OTOH just stripping out the unittest would result in a small improvement -
though probably not measurable in comparison to other, more worthwhile tricks
at the compiler-level.

--

[Issue 8166] retro() of splitter() too

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from Seb  ---
PR - let's do this: https://github.com/dlang/phobos/pull/6150

--

Re: Elegant way to use dynamic bindings

[Dennis via Digitalmars-d-learn]

On Friday, 9 February 2018 at 18:14:06 UTC, Mike Wey wrote:
You may need to pass `/s` to implib so it will add the 
underscore to the symbol in the import library. If it's 
actually needed depends on what the dll uses.


That did it, now both dynamic loading and dynamic linking work. 
:) Thanks both of you.


I'd still like to find a nice way to generate the boilerplate 
code for dynamic loading, if I come up with something I'll post 
it here.

Re: Which language futures make D overcompicated?

[Patrick Schluter via Digitalmars-d]

On Friday, 9 February 2018 at 18:44:08 UTC, Meta wrote:

On Friday, 9 February 2018 at 18:21:55 UTC, Bo wrote:
* scope() .. just call it "defer" just as every other language 
now does. It only confuses people who come from other 
languages. Its now almost a standard. By using scope people 
have have no clue that D has a defer. Took even me a while to 
know that D had a defer system in place.


The funny thing is that D had this feature long before any 
other language that I can think of (of course Lisp has probably 
had 6 different implementations of it since 1972). They're the 
ones that need to get with the program ;-)
And defer is so vague. Defer to when? scope is obvious. Of 
course, one has to know what a scope is in the first place.

Re: Which language futures make D overcompicated?

[Jonathan M Davis via Digitalmars-d]

On Friday, February 09, 2018 15:48:42 Andrea Fontana via Digitalmars-d 
wrote:
> On Friday, 9 February 2018 at 15:35:38 UTC, Mike Parker wrote:
> > On Friday, 9 February 2018 at 15:27:18 UTC, Andrea Fontana
> >
> > wrote:
> >>> If you need to take the address of a constant, use immutable
> >>> or const (doesn't really matter, but I prefer immutable). If
> >>> you don't need the address, use enum.
> >>
> >> Why not static immutable?
> >
> > For global scope? static has no effect there as far as I know.
> > Looking at the ASM output on run.dlang.io, I see no difference
> > between the two:
> >
> > static immutable foo = 10;
> > immutable bar = 20;
> >
> > LAT group
> > ;File = onlineapp.d
> >
> > public  immutable(int) onlineapp.foo
> > public  immutable(int) onlineapp.bar
> >
> > ...
> >
> > mov EDI,0Ah
> >
> > call  @safe void
> >
> > std.stdio.writeln!(immutable(int)).writeln(immutable(int))@PLT32
> >
> > mov EDI,014h
> > call  @safe void
> >
> > std.stdio.writeln!(immutable(int)).writeln(immutable(int))@PLT32
>
> If I'm right on classes/structs static immutable != immutable. So
> if you need to replace enum in those cases too, static immutable
> works fine everywhere. Right?

static immutable works fine everywhere, but it's pointless to have the
static at the module level. It's a no-op there. But for most types, enum is
better, because it doesn't result in there being an object in the binary,
whereas static immutable would. The cases where you'd want to avoid enums
are when you really want there to be an address (e.g. for arrays other than
strings, you don't want to use enums, because for them, a new dynamic array
gets alloced every time you use the enum), but something like int, an enum
is definitely better.

- Jonathan M Davis

Re: Which language futures make D overcompicated?

[Jonathan M Davis via Digitalmars-d]

On Friday, February 09, 2018 15:33:30 Andrea Fontana via Digitalmars-d 
wrote:
> On Friday, 9 February 2018 at 15:05:05 UTC, Jonathan M Davis
>
> wrote:
> > [...]
> > The reality of the matter is that shared is _supposed_ to
> > result in a bunch of compilation errors when you try to do
> > stuff to it. You're supposed to either use atomics to mutate a
> > shared object or protect it with a mutex and temporarily cast
> > away shared so that you can actually do stuff with it. You're
> > really not supposed to do much with a shared object while it's
> > shared, and a lot of folks don't understand that.
> > [...]
> > - Jonathan M Davis
>
> Time to write an article/tutorial about this! Did I miss it?

No. The only article that I've actually written is the "Introduction to
std.datetime" that's on the main site and really should be rewritten now
that std.date is long gone. I've been intending to write more but haven't
gotten around to it (in part due to a lack of time and in part, because I
wanted to get my own website up so that I had a place to put articles, and I
only got that up finally this morning even though I've been intending to do
it for ages). I'll probably do a write-up on shared at some point precisely
because we need one, but I don't know when.

- Jonathan M Davis

Re: A betterC base

[jmh530 via Digitalmars-d]

On Friday, 9 February 2018 at 19:28:40 UTC, Seb wrote:


Yes, that's the intended goal.
However, to convince everyone involved and to be able to 
experiment with this in the wild for a bit, we went with 
std.experimental first.


If drawbacks get discovered, it's a lot easier to retreat.


Cool.

Do you know if compilation speed improves if using selective 
imports? E.g.

import std.experimental.scripting : writeln;
vs.
import std.experimental.scripting;

I suppose that's a general question wrt public imports, but in 
this case there is probably more to parse than in other smaller 
projects.

[Issue 18404] Allow selective printing of -vgc output

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

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

Eyal  changed:

   What|Removed |Added

 CC||e...@weka.io

--- Comment #1 from Eyal  ---
That's a great idea.

If there was:

* a way to white-list a specific piece of code to avoid -vgc, e.g: explicit @gc
are filtered from -vgc, or maybe via -vimplicit_gc (that excludes @gc code)

* a way to make -vimplicit_gc outputs compilation errors

Then we could explicitly white-list specific GC code instead of black-listing
GC almost *everywhere*.

--

[Issue 16521] Wrong code generation with switch + static foreach

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #11 from Seb  ---
FWIW this works with static foreach


---
void main ()
{
sformat(0, uint.max);
}

void sformat (Args...) (int index, Args args)
{
JT: switch (index)
{
static foreach (idx, unused; args)
{
case idx:
assert(unused == args[idx], "Borken compiler");
break JT;
}

default:
assert(0);
}
}
---

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

--

Re: Which language futures make D overcompicated?

[H. S. Teoh via Digitalmars-d]

On 8 February 2018 at 23:54, Suliman via Digitalmars-d
<[1]digitalmars-d@puremagic.com> wrote:
> 
>  I like D, but sometimes it's look like for me too complicated. Go
>  have a lot of fans even it not simple, but primitive. But some D
>  futures make it very hard to learning.
> 
>  Small list by me:
>  1. mixins
>  2. inout
>  3. too many attributes like: @safe @system @nogc etc

But none of these features are *necessary* to start coding in D. They
are optional extras that are nice once you're comfortable with the
language.  I got by fine for *years* without even using a single mixin,
or knowing what 'inout' does, or use any attributes.

It's like human language, there's a set of core words ("basic features")
that you have to know to hold a conversation, but there's a vast
vocabulary of more specialized words ("advanced features") to draw from
when you need to be more precise or in special situations. You don't
need to know the *entire* language to be functional in it. E.g., there's
a vast body of scientific vocabulary that 90% of the general population
(of native English speakers) has no idea about.  Yet they can live and
function in society just fine.  But that vocabulary is there when you
*do* need it.

It would be a worthless language if it's extremely easy to learn but can
only attain to the complexity level of baby-talk.  Turing machines
technically can compute the same thing as D can, and they are about as
simple as it can possibly get while still being Turing-complete.  But do
you really want to write non-trivial program in Turing machine?
Probably not.


On Fri, Feb 09, 2018 at 11:13:13AM -0800, Manu via Digitalmars-d wrote:
[...]
>2. Wrong defaults for attributes

Unfortunately, this is a historical accident that's not easy to fix.
Short of doing a D3 iteration, but I don't see that happening anytime
soon.


>3. string mixins always used in place of some sort of more sanitary
>macro system
[...]

That gave me a double-take.  "Sanitary" and "macro" in the same
sentence?!  That's just ... I know what you *mean*, but the thought is
just, wow. :-D


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying

Re: A betterC base

[Seb via Digitalmars-d]

On Friday, 9 February 2018 at 17:41:45 UTC, jmh530 wrote:

On Friday, 9 February 2018 at 16:54:35 UTC, Seb wrote:



FYI: and for the lazy ones, there will hopefully be 
std.experimental.scripting soon:


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


Why not make this a package.d file for std?


Yes, that's the intended goal.
However, to convince everyone involved and to be able to 
experiment with this in the wild for a bit, we went with 
std.experimental first.


If drawbacks get discovered, it's a lot easier to retreat.

Re: Which language futures make D overcompicated?

[Mark via Digitalmars-d]

On Friday, 9 February 2018 at 18:34:33 UTC, Seb wrote:

On Friday, 9 February 2018 at 18:21:55 UTC, Bo wrote:
Here are a few more "basics" that are unneeded or confusing. 
Lets not even talk about the more advanced features like 
inout, ...


/-/

* auto: Static typed language yet we fall back on the compiler 
to figure out what is being assigned. Can just as well have a 
interpreter language. It only encourages lazy writing and has 
a penalty on the compilation.


There's almost zero/no penalty on the compilation cost.
What's wrong with letting the compiler help you?
If you don't like auto, simply don't use it :O


auto is prevalent in Phobos, especially in the form of Voldemort 
types. Speaking of which, Voldemort types are an awful idea. 
Often when I use Phobos, what happens is:


1. I write something like:

import somemodule : foo, bar;
bar(foo(x)); // assume a variable x is defined beforehand

2. I get a weird, long compilation error.
3. After a lot of head scratching I realize that the problem is 
that foo(x) doesn't satisfy bar's signature constraints.
4. I go look at the signature of foo and it tells me nothing 
useful because it returns a Voldemort type.
5. I go look at the documentation of foo. Usually it is 
frustratingly terse. Can't figure out what foo promises about its 
return type (is it a forward range? If my parameter type was a 
bidirectional range, do I get a bidirectional range back?)
6. I go to the implementation of foo and look at the definition 
of its return type.


So Voldemort types make you dependent on the documentation 
capabilities of the library author. If the documentation is 
bad/outdated and you don't have the source code, well, good luck 
with that.

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

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 9 February 2018 at 14:49:27 UTC, Jonathan M Davis 
wrote:
On Friday, February 09, 2018 14:01:02 Atila Neves via 
Digitalmars-d wrote:
Unit tests are a great idea, right? Try convincing a group of 
10 programmers who have never written one and don't know 
anyone else who has. I have; I failed.


The amazing thing is when a programmer tries to argue that 
having unit tests makes your code worse - not that they take 
too long to write or that they don't want to bother with them 
or any that - that they somehow make the code worse.


- Jonathan M Davis


Actually, it can make lazy programmers write worse code if they 
write code to satisfy the tests instead of writing code according 
to the spec...

Re: Which language futures make D overcompicated?

[Manu via Digitalmars-d]

On 8 February 2018 at 23:54, Suliman via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> I like D, but sometimes it's look like for me too complicated. Go have a
> lot of fans even it not simple, but primitive. But some D futures make it
> very hard to learning.
>
> Small list by me:
> 1. mixins
> 2. inout
> 3. too many attributes like: @safe @system @nogc etc
>
> Which language futures by your opinion make D harder?
>

1. Storage class as a concept separate to the type; in my experience
responsible for almost all complexity and special casing in my generic code
2. Wrong defaults for attributes
3. string mixins always used in place of some sort of more sanitary macro
system

Re: Which language futures make D overcompicated?

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 09, 2018 at 06:20:32PM +, Atila Neves via Digitalmars-d wrote:
[...]
> I'm perfectly happy with dub-the-package-manager.
> 
> As for dub-the-build-system, I already did something about it: I wrote
> reggae. Nearly all of the problems I've had with using dub to build
> have disappeared by just using reggae instead. There's still a few
> things that aren't great (`dub describe` needs some love, probably
> because I'm the only one parsing the output), and sometimes I run into
> issues that only happen using reggae, but overall, it's been a good
> choice. For starters, I'd much rather have all our code build in 6min
> as it does now than over an hour as it was before.

I've only recently started using dub, and yeah, it *may* be great as a
package manager, but as a build tool, I found it extremely frustrating,
slow, and not easily reconfigurable.  So much so that after struggling
with it for about a week or so, I threw my hands up and went back to
SCons as my go-to build system of choice.

Currently, my vibe.d project has a subdirectory containing an empty
dummy dub project, the sole purpose of which is to declare vibe.d
dependencies so that `dub build` in that subdirectory will fetch and
build vibe.d and whatever else it may depend on, and build it into a
linkable state.  Once that's done, I leave dub aside and use SCons to
actually build and link my program with the libraries built by dub.
This resulted in an instant improvement in my build times by (at least)
half, as well as free me from needless network lookups when I'm actually
coding locally and don't *need* to be upgrading dependent libraries.

This setup currently serves its purpose well enough.  But, glancing at
reggae, it seems to be a flexible and interesting idea that might just
suit my needs.  So I'm going to put it on my list of things to try out.


> There are assumptions in the codebase that make solving some of the
> issues so hard as to practically be impossible, and:
> 
> 1. I don't get paid to work on dub (I have a hard time supporting all my
> open source projects as it is!)
> 2. There are tons of things I want to do in/for D that I'm more interested
> in
> 3. As mentioned above, it's easier for me to just use reggae
[...]

Yeah, if I'm already so disinclined to use dub (or insert any other
disliked software of your choice), then imagine how much motivation I
have to actually invest my limited time and energy into it, as opposed
to doing something else that is more interesting and more immediately
relevant to my needs.

If somebody *paid* me to work on dub, then perhaps I will.  But right
now, my level of motivation and interest in doing so is pretty low, and
is on the losing side of the competition against the myriad other
projects that I could be working on.


T

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making 
time go faster!

Re: Which language futures make D overcompicated?

[John Gabriele via Digitalmars-d]

On Friday, 9 February 2018 at 18:40:25 UTC, Seb wrote:

On Friday, 9 February 2018 at 18:13:08 UTC, Russel Winder wrote:

On Fri, 2018-02-09 at 16:10 +, Seb via Digitalmars-d wrote:



[…]

Dub is not dead, it just has limited resources.


So , if the D community want Dub to work as a build system as 
well as a package manager, extend the resources by corralling 
the grumblers and support them into fixing code and creating 
pull requests.



I already but my limited resources into real and _merged_ pull 
requests for actual bugs at dlang/dub
Please if you have ideas to motivate the grumblers to do so as 
well, act!


Would it make sense to split out dub's build functionality from 
its package management? Separate sharp tools for separate jobs.


I've only heard of Atila's reggae today. Is reggae commonly used 
among D users? Are there any show stoppers to using it in place 
of dub for building dub-managed projects?

[Issue 18411] New: Split up std.internal.regex.tests.d into multiple files or runs

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

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

  Issue ID: 18411
   Summary: Split up std.internal.regex.tests.d into multiple
files or runs
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

tl;dr: auto-tester only uses 2GB of memory, but the tests from std.regex often
require more and thus lead to spurious failures.

https://github.com/braddr/d-tester/issues/66
https://github.com/braddr/d-tester/issues/69

In lack of being able to make DMD consume less memory easily, imho the best
solution for now is to splitup the tests.d file.

Existing work:
- https://github.com/dlang/phobos/pull/6061

--

Re: Debugging on Windows

[Benjamin Thaut via Digitalmars-d-learn]

On Thursday, 8 February 2018 at 21:09:33 UTC, JN wrote:

Hi,

is there any way to debug binaries on Windows? I'd at least 
like to know which line of code made it crash. If it's D code, 
I get a call trace usually, but if it's a call to a C library, 
I get a crash and that's it. I am using VSCode and I'd prefer 
to debug in it if possible, but using other IDEs is a 
possibility for me if that will help.


The best option most likely is to get the Visual Studio Community 
Edition and then Install the VisualD extension for Visual Studio. 
This will give you a very good debugging experience with a 
bulitin D expression evaulator and the usual features the very 
good Visual Studio debugger comes with.


Kind Regards
Benjamin Thaut

Re: Which language futures make D overcompicated?

[Meta via Digitalmars-d]

On Friday, 9 February 2018 at 17:31:47 UTC, Adam D. Ruppe wrote:

On Friday, 9 February 2018 at 16:44:32 UTC, Seb wrote:
Forget inout, it's seldomly used and there have even attempts 
to remove it from the language.


inout rox. I think this is more of a documentation 
discoverability problem. We should be having people read the 
spec, which is written toward compiler authors [!], when they 
want to just know how to use it.


Here's the basic rules of thumb:

If you don't need to change a variable:

1) use immutable when declaring a new variable

immutable myvar = "never gonna change";

2) if you are returning a member variable or function argument, 
use inout on both


class myclass {
   Object member;
   inout(Object) getMember() inout {
   return member;
   }
}

inout(char)* identity(inout(char)* s) {
   return s;
}


My main issue with inout is the following:

struct Option(T)
{
bool isNull;
T payload;

this(inout(T) val) inout
{
payload = val;
}

bool opEquals(inout(T) val) inout
{
return !this.isNull && (this.get() == val);
}

inout(T) get() inout
{
return payload;
}
}

struct InoutHeaven
{
int n;
}

void main()
{
immutable Option!InoutHeaven v1 = InoutHeaven(1);
assert(v1 == InoutHeaven(1));
}

Everything is fine until InoutHeaven defines a custom opEquals:

struct InoutHell
{
int n;

bool opEquals(InoutHell other)
{
return n == other.n;
}
}

void main()
{
immutable Option!InoutHell v1 = InoutHell(1);
//Welcome to Inout Hell >:^)
//Error: mutable method onlineapp.InoutHell.opEquals is not 
callable using a inout object

assert(v1 == InoutHell(1));
}

The really frustrating thing is that as far as I know, there's 
nothing you can do if you don't have control over the wrapped 
type. If you can't add your own inout or const opEquals method, 
you're screwed.


I might be wrong about this though, as I think Steven has 
debunked this on at least one occasion. However, I can't remember 
what his solution was, if there was one.

Re: Which language futures make D overcompicated?

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 09, 2018 at 06:44:08PM +, Meta via Digitalmars-d wrote:
> On Friday, 9 February 2018 at 18:21:55 UTC, Bo wrote:
> > * scope() .. just call it "defer" just as every other language now
> > does.  It only confuses people who come from other languages. Its
> > now almost a standard. By using scope people have have no clue that
> > D has a defer.  Took even me a while to know that D had a defer
> > system in place.
> 
> The funny thing is that D had this feature long before any other
> language that I can think of (of course Lisp has probably had 6
> different implementations of it since 1972). They're the ones that
> need to get with the program ;-)

+1000!  (and by 1000! I mean factorial(1000) :-P)


T

-- 
In theory, software is implemented according to the design that has been 
carefully worked out beforehand. In practice, design documents are written 
after the fact to describe the sorry mess that has gone on before.

Re: Which language futures make D overcompicated?

[Seb via Digitalmars-d]

On Friday, 9 February 2018 at 18:13:08 UTC, Russel Winder wrote:

On Fri, 2018-02-09 at 16:10 +, Seb via Digitalmars-d wrote:



[…]

Dub is not dead, it just has limited resources.


So , if the D community want Dub to work as a build system as 
well as a package manager, extend the resources by corralling 
the grumblers and support them into fixing code and creating 
pull requests.



I already but my limited resources into real and _merged_ pull 
requests for actual bugs at dlang/dub
Please if you have ideas to motivate the grumblers to do so as 
well, act!



Whilst grumbles on the email list are not turned into evolution 
of Dub, the D ecosystem does progress.


Yes, we are making  progress. With more people contributing, 
things would go a lot faster though ...


An example, remember how code.dlang.org looked in 2016?

https://web.archive.org/web/20160129060825/http://code.dlang.org/

(apart from the design - compare the number of packages with the 
number it has today)

Re: Which language futures make D overcompicated?

[Meta via Digitalmars-d]

On Friday, 9 February 2018 at 18:21:55 UTC, Bo wrote:
* scope() .. just call it "defer" just as every other language 
now does. It only confuses people who come from other 
languages. Its now almost a standard. By using scope people 
have have no clue that D has a defer. Took even me a while to 
know that D had a defer system in place.


The funny thing is that D had this feature long before any other 
language that I can think of (of course Lisp has probably had 6 
different implementations of it since 1972). They're the ones 
that need to get with the program ;-)

Re: Which language futures make D overcompicated?

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 09, 2018 at 05:56:38PM +, Dukc via Digitalmars-d wrote:
> On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
> > Which language futures by your opinion make D harder?
> 
> Not many! D is a fairly complex languague, but just about everything
> feels like to be here for a good reason. That includes many oft-hated
> things: inout, auto ref, goto, BetterC...

TBH, I'm not a fan of inout. Not because of how most people feel, that
we shouldn't have it; IMO it doesn't go *far enough*.  For example,
there's currently no way to express conveying the constness of a
delegate argument's parameter to the return value, which would have been
useful in some places in generic code.


> What I would like to remove, is auto-decoding (popular opinion, I
> know)

I would totally back up killing auto-decoding. With fire. And extreme
prejudice. :-P

Unfortunately, that would also cause massive breakage of existing code,
and worse yet, in some cases it will cause *silent* breakage, which is
the worst of its kind.  So barring some kind of workable (probably very
long) deprecation cycle, I just don't see it going away anytime in the
foreseeable future.


> and the heavy syntax when handling types: __traits, is expression,
> typeof and std.meta templates should be invokable in a more UFCS-like
> manner (But still avoiding context-dependant parsing, perhaps with a
> keyword before an expression used as a type in a declaration).

AFAIK, __traits was never intended to be used directly in user code. The
intention was to expose a raw interface into compiler internals, and
then write nicer wrappers in Phobos that provide a more user-friendly
API to users.

As for is-expressions, I think either Walter or Andrei (possibly both)
have acknowledged that the syntax is a mess.  But too much code already
depends on the current syntax, and changing that now will be far too
disruptive.

As for UFCS-style template parameters, I would totally support that!!
I've felt the need for it on more than one occasion.  Perhaps somebody
could write up a DIP for a `.!` operator (tentative syntax) to
complement the current `!` operator.  So you could write things like:

AliasSeq!(1, 2, 3).!staticMap!(MyPredicate).!staticSort


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom