Re: What are we going to do about mobile?

[Jethro via Digitalmars-d]

On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:
I have been saying for some time now that mobile is going to go 
after the desktop next 
(http://forum.dlang.org/thread/rionbqmtrwyenmhmm...@forum.dlang.org), Samsung just announced it, for a flagship device that will ship tens of millions:


[...]


The D community should start a D based operation system for the 
android and possibly iphone devices. Since D can compile in to 
many different languages, the OS could be platform agnostic.


All someone would have to do is create some example code that D 
can come to a binary and be used to boot in to some android 
device and someone will start working developing something bigger 
and better.

Re: Proposal: Exceptions and @nogc

[Walter Bright via Digitalmars-d]

On 4/6/2017 6:00 AM, Shachar Shemesh wrote:

The preallocated exceptions in weka were created as a work around for exceptions
requiring GC. If we can throw without invoking the GC, we'll probably be fine
with tossing them.

Shachar


That's what I thought. Thanks for the confirmation.

Re: dmd Backend converted to Boost License

[Kyle via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Excellent, good work.

Re: Creating Tuple or AliasSeq

[Graham Fawcett via Digitalmars-d-learn]

On Friday, 7 April 2017 at 10:26:24 UTC, ANtlord wrote:

On Friday, 7 April 2017 at 07:46:40 UTC, Ali Çehreli wrote:

[...]


I can't understand. Documentation of cartesianProduct points 
out about finite arrays. At least one of arrays must be a 
inifinte array. As far as I know finite arrays is `int[3]` and 
infinite is `int[]` 
(https://dlang.org/library/std/range/primitives/is_infinite.html). Am I right?


If I am then I can't understand why DMD return error about 
finite ranges compiling following code.


struct Hay {
int a;
@disable this(this);
@disable this();
this(int a){
this.a = a;
}

}
Hay[] params = [ Hay(1), Hay(23) ];
auto products = cartesianProduct(params, params);

Error text:


[...]


I noticed that removing disabling default constructors helps. 
Does that mean an array contains objects of a struct with 
disabled default constructor is finite?


No, int[] is a finite array. isInfinite is meant to test for 
ranges which are statically defined to *never* be empty, no 
matter how many times you consume them. See std.range.repeat(T) 
for an example of such a range.

Re: Running out of memory ctfe 16GB

[Alexander Breckel via Digitalmars-d]

On Thursday, 6 April 2017 at 20:49:00 UTC, Nierjerson wrote:
I am running out of memory trying to generate CTFE code. It is 
quite large generation but just repetitive loop acting on an 
array item.


Surely 16GB should be enough to compile such a thing? I am 
using 64-bit dmd. It climes to about 12GB then eventually drops 
down to around 1GB and then back up to 16GB and then quits.


I cannot generate the array in parts and stick them all 
together because they are all interdependent(but not much, 
nothing that should actually cost memory).


Seems that dmd not freeing up memory for speed is gonna start 
causing problems with complex template generation.


Is there any way to fix this? A special switch that will enable 
the compiler to reduce memory consumption(free unused stuff) or 
use the swap file?


https://github.com/IllusionSoftware/COM2D/

At the very least have something to give feedback on how to 
reduce memory consumption. Leaving things up in the air for 
programmers to stumble upon after a lot of work is not good.


On the "Error: Out of Memory" at least report some statistics 
on functions and lines and how much memory they have used and 
how many times they have been called.


Some years ago I managed to force DMD to collect memory during 
CTFE by loading the malloc replacement of Boehm GC using 
LD_PRELOAD on Linux. It sounds totally crazy, but it worked...


Check the last part called "Simplified leak detection under 
Linux" of this link:


https://www.hboehm.info/gc/leak.html

You can ignore the leak detection aspect and just build and 
preload libgc.so. It will (very conservatively) collect memory if 
a malloc fails. Lets hope DMD drops old references during CTFE...


Please report back if this still works.

Re: dmd Backend converted to Boost License

[David Nadlinger via Digitalmars-d-announce]

On Friday, 7 April 2017 at 22:57:39 UTC, Walter Bright wrote:
Thanks for pointing that out, I didn't know that. I just 
assumed LDC would have gone with a clang-style inline assembler 
(does clang even have inline asm?).


LDC supports both DMD-style asm {} blocks as well as LLVM's 
native inline assembly format, which is very similar to GCC's, 
with explicit clobber specifications and explicit parameter 
passing (https://wiki.dlang.org/LDC_inline_assembly_expressions). 
The latter is useful on non-x86 platforms as well as to allow 
more optimizations of functions using inline asm such as inlining 
(although inlining in particular can also be enabled for 
DMD-style asm blocks using a pragma).


There are also inline IR expressions for the few situations where 
you don't want to drop down all the way to inline assembly but 
still need to crack open the hood and control the emitted LLVM 
IR: https://wiki.dlang.org/LDC_inline_IR. For example, we use it 
to implement some target-independent SIMD intrinsics in the 
library.


 — David

Re: Using template mixin, with or without mixin ?

[Ali Çehreli via Digitalmars-d-learn]

On 04/07/2017 04:47 PM, biocyberman wrote:

I want to use mixin to generate function in-place. In template
declaration, I can see 'mixin' keyword is optional. Is it true? What is
the difference and when I must use one way over another?

This is my program:

// This works with and without 'mixin' attribute.
mixin template funcgen(T, U){

  T func1(string pr2){
writeln("Func1: ", pr2);
  }
  U func2(string pr3){
writeln("Func2: ", pr3);
  }

}

int main(string[] args){

  mixin funcgen!(void, void);
  func1("func1");
  func2("func2");
  return 0;

}


The difference is that you can't use funcgen as a regular template:

funcgen!(void, void);

Error: template instance funcgen!(void, void) mixin templates are not 
regular templates


I think it's good practice to use 'mixin template' if it's intended to 
be so.


Ali

Using template mixin, with or without mixin ?

[biocyberman via Digitalmars-d-learn]

I want to use mixin to generate function in-place. In template 
declaration, I can see 'mixin' keyword is optional. Is it true? 
What is the difference and when I must use one way over another?


This is my program:

// This works with and without 'mixin' attribute.
mixin template funcgen(T, U){

  T func1(string pr2){
writeln("Func1: ", pr2);
  }
  U func2(string pr3){
writeln("Func2: ", pr3);
  }

}

int main(string[] args){

  mixin funcgen!(void, void);
  func1("func1");
  func2("func2");
  return 0;

}

[Issue 17304] [SPEC] Anonymous symbols, show or ignore in demangler?

[via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #1 from Iain Buclaw  ---
> This seems to also be the case in the compiler also, as it doesn't should the 
> internal symbol when compiling with `-v'.

As it doesn't *show* the internal symbol when compiling with `-v'.

--

[Issue 17304] New: [SPEC] Anonymous symbols, show or ignore in demangler?

[via Digitalmars-d-bugs]

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

  Issue ID: 17304
   Summary: [SPEC] Anonymous symbols, show or ignore in demangler?
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

Reduced-ish test:
---
template map(fun...) if (fun.length >= 1)
{
auto map(Range)(Range r)
{
return r;
}
}

unittest
{
import std.algorithm.mutation, std.string;
auto foo(string[] args)
{
return args.map!strip;
}
}
---

Emits the function:

_D9iteration29__T3mapS189iteration005stripZ13__T3mapTAAyaZ3mapFNaNbNiNfAAyaZAAya

Which falls under the following rule twice in the mangling ABI:

SymbolName:
0 // anonymous symbols


Current behaviour when the GNU binutils D demangler sees the 005, by mostly
fluke, strtol() returns the number 5, which means the two anonymous symbols are
skipped.

This seems to also be the case in the compiler also, as it doesn't should the
internal symbol when compiling with `-v'.

However, should this be assumed the correct way to handle this symbol?  If so
I'll make it explicit.

Otherwise the alternative would be to demangle the symbol as
`iteration.__anonymous.__anonymous.strip'.

--

Re: What are we going to do about mobile?

[aberba via Digitalmars-d]

On Friday, 7 April 2017 at 14:47:03 UTC, Marco Leise wrote:

Am Thu, 06 Apr 2017 05:24:07 +
schrieb Joakim :

[...]
That's what I meant by embedded programming. Not those 1mb RAM 
boards. Smart devices/IoT (home automation, smart cards, 
industrial machines, etc.) using more capable boards. What 
remains is hardware interface part in form of reusable libs. 
We're already there.


[...]

+1


[...]

Re: dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

Now #1 on r/programming subreddit!

Re: dmd Backend converted to Boost License

[ketmar via Digitalmars-d-announce]

Jack Stouffer wrote:


On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to relicense 
it. Thank you, Symantec!


Something that just popped into my head:

You've said that you've avoided ever looking at other compiler's code to 
avoid legal trouble. Is that problem gone now?


nope. GPL programmers can safely look into BSDL code, for example, 'cause 
it is ok to put GPL alongside of BSDL. but BSDL programmers can't "just 
take" GPL code.


that is, it is prolly nobody will sue Walter for "copying GPL code", but it 
is better to be safe than sorry.


this is how i see the things, of course, it's not the authoritative answer.

Re: dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

On 4/7/2017 3:57 PM, Jack Stouffer wrote:

You've said that you've avoided ever looking at other compiler's code to avoid
legal trouble. Is that problem gone now?


No, unless the other compiler is Boost as well.

Re: dmd Backend converted to Boost License

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

On Fri, Apr 07, 2017 at 10:38:36PM +0100, rikki cattermole via 
Digitalmars-d-announce wrote:
> On 07/04/2017 10:03 PM, WhatMeWorry wrote:
[...]
> > I've been coding in D for years now but was unaware of this issue.
> > Could someone give this licensing neophyte an explanation and some
> > history?
> 
> So dmd's backend came directly from dmc. This makes sense as this is
> the time of Digital Mars creation (Walter has been working with this
> code base pretty much since before I was born).
> Because of how history went, it was owned by Symantic yet Digital Mars
> still developed it.
> 
> So its usage within dmd caused problems, i.e. with packaging and
> distributing because it required explicit permission from Digital Mars
> so that Symantic wouldn't get sued.
> 
> Maybe Walter can clarify but this is what I have gathered over the
> years.

There's also the aspect, AIUI, that Walter has refrained from looking at
/ contributing to the code for any other compiler backend, in order to
avoid legal complications arising from possible "tainting" from the dmd
backend code. E.g., if he were to submit a patch to the gcc backend,
Symantec could in theory come back and sue the gcc guys claiming that
their code is based on the dmc backend and so they have to pay
royalties.  Or if he were to read the code for gcc's backend, Symantec
could in theory accuse him of incorporating GPL code into the dmc
backend (since he's still working on the backend every now and then),
which is incompatible with the license.

Of course, IANAL so this relicensing may not necessarily imply that
Walter is now free to read / work on other compiler backends. Nor does
he necessarily want to do so anyway.

But regardless, this is a major step forward at least in the aspect of
finally putting to rest the "D is non-free" FUD that's been spreading
around over the years.


T

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

Re: dmd Backend converted to Boost License

[Jack Stouffer via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Something that just popped into my head:

You've said that you've avoided ever looking at other compiler's 
code to avoid legal trouble. Is that problem gone now?

Re: dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

On 4/7/2017 3:22 PM, David Nadlinger wrote:

Just to clarify for people not usually frequenting these circles: LDC does
support DMD-style inline assembly, but we use a different implementation.



Thanks for pointing that out, I didn't know that. I just assumed LDC would have 
gone with a clang-style inline assembler (does clang even have inline asm?).

Re: D support for the Meson build system

[aberba via Digitalmars-d-announce]

On Sunday, 21 August 2016 at 19:08:59 UTC, Matthias Klumpp wrote:

Hi!
Last week I was at this year's GUADEC conference and listened 
to a very interesting talk on the Meson build system[2] which 
is designed for very fast builds and as a much more modern 
replacement for Automake with a simple syntax.
In the past few days I added support for D (all three major 
compilers) to the Meson build system, with some great results-


[...]


Seems like good news for us developing Linux apps.

Re: Is DMD breaking BigInt?

[Meta via Digitalmars-d-learn]

On Friday, 7 April 2017 at 17:06:31 UTC, Russel Winder wrote:
Simple Dub build of a Factorial example using Unit-Threaded for 
testing. Works fine with ldc2 breaks with dmd. This is on 
Debian Sid fully up to date.


|> ldc2 --version
LDC - the LLVM D compiler (1.1.1):
  based on DMD v2.071.2 and LLVM 3.9.1
  built with LDC - the LLVM D compiler (1.1.0)
  Default target: x86_64-pc-linux-gnu
  Host CPU: broadwell
  http://dlang.org - http://wiki.dlang.org/LDC

|> dmd --version
DMD64 D Compiler v2.073.2

|> dub test --compiler=ldc2
Package factorial (configuration "unittest") defines no import 
paths, use {"importPaths": [...]} or the default package 
directory structure to fix this.

Running custom 'unittest' configuration.
Performing "unittest" build using ldc2 for x86_64.
unit-threaded 0.7.11: target for configuration "library" is up 
to date.

factorial ~master: building configuration "unittest"...
Running pre-build commands...
Building package unit-threaded in 
/home/users/russel/.dub/packages/unit-threaded-0.7.11/unit-threaded/

Performing "$DFLAGS" build using dmd for x86_64.
unit-threaded 0.7.11: building configuration "gen_ut_main"...
Linking...
Running 
../../../../.dub/packages/unit-threaded-0.7.11/unit-threaded/gen_ut_main -f ut_main.d
To force a rebuild of up-to-date targets, run again with 
--force.

Running ./factorial-test

Automatically generated file ut_main.d
Running unit tests from dirs ["."]
factorial.Check the base case for all algorithms.:
factorial.Check the property for all algorithms.:
factorial.Traditional example-based testing.:

Time taken: 34 ms, 363 μs, and 2 hnsecs
3 test(s) run, 0 failed.

OK!

|> dub test
Package factorial (configuration "unittest") defines no import 
paths, use {"importPaths": [...]} or the default package 
directory structure to fix this.

Running custom 'unittest' configuration.
Performing "unittest" build using dmd for x86_64.
unit-threaded 0.7.11: target for configuration "library" is up 
to date.

factorial ~master: building configuration "unittest"...
Running pre-build commands...
Building package unit-threaded in 
/home/users/russel/.dub/packages/unit-threaded-0.7.11/unit-threaded/

Performing "$DFLAGS" build using dmd for x86_64.
unit-threaded 0.7.11: building configuration "gen_ut_main"...
Linking...
Running 
../../../../.dub/packages/unit-threaded-0.7.11/unit-threaded/gen_ut_main -f ut_main.d
factorial.d(71,15): Error: template std.bigint.BigInt.__ctor 
cannot deduce function from argument types !()(string) 
immutable, candidates are:
/usr/include/dmd/phobos/std/bigint.d(64,5):
std.bigint.BigInt.__ctor(Range)(Range s) if 
(isBidirectionalRange!Range && isSomeChar!(ElementType!Range) 
&& !isInfinite!Range)
/usr/include/dmd/phobos/std/bigint.d(146,5):
std.bigint.BigInt.__ctor(T)(T x) if (isIntegral!T)
/usr/include/dmd/phobos/std/bigint.d(162,5):
std.bigint.BigInt.__ctor(T)(T x) if (is(Unqual!T == BigInt))

dmd failed with exit code 1.


If anyone has any useful intelligence as to what happening and 
how I

can workaround it, I'd be a grateful bunny.


Do you have the -dip1000 switch enabled?

Re: dmd Backend converted to Boost License

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 7 April 2017 at 22:02:31 UTC, Walter Bright wrote:

I'll defer to Martin Nowak on what to do about that.

It would help for those who need this for specific versions to 
let Martin know which ones.


Great, thanks -- I'll follow up with Martin on slack.

Re: dmd Backend converted to Boost License

[Paolo Invernizzi via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Congrats! That's a big win, and you deserve all the merits!

Enjoy the moment!

---
Paolo

Re: dmd Backend converted to Boost License

[David Nadlinger via Digitalmars-d-announce]

On Friday, 7 April 2017 at 21:49:22 UTC, Walter Bright wrote:
Note that this also resolves the long-standing legal issue with 
D's inline assembler being backend licensed, and so not 
portable to gdc/ldc.


Just to clarify for people not usually frequenting these circles: 
LDC does support DMD-style inline assembly, but we use a 
different implementation.


 — David

Re: dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

On 4/7/2017 2:54 PM, Joseph Rushton Wakeling wrote:

My question should have been more specific: will we see the patch changing the
license in the source code applied to existing stable release branches?

I'd really appreciate it if we could get such a patch applied at least to the
current stable release.  Obviously the code's real license is now officially
Boost by your decision, but it's nice to have the source clearly match up to 
this.


I'll defer to Martin Nowak on what to do about that.

It would help for those who need this for specific versions to let Martin know 
which ones.

Re: dmd Backend converted to Boost License

[ketmar via Digitalmars-d-announce]

Walter Bright wrote:

Note that this also resolves the long-standing legal issue with D's 
inline assembler being backend licensed, and so not portable to gdc/ldc.


yay!

[Issue 17302] [SPEC] QualifiedName mangling does not match compiler.

[via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #1 from Iain Buclaw  ---
And fixing 12352 would be the cause of this bug.

--

Re: dmd Backend converted to Boost License

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:35:00 UTC, Walter Bright wrote:

It applies to all of it!


Cool :-)

My question should have been more specific: will we see the patch 
changing the license in the source code applied to existing 
stable release branches?


I'd really appreciate it if we could get such a patch applied at 
least to the current stable release.  Obviously the code's real 
license is now officially Boost by your decision, but it's nice 
to have the source clearly match up to this.

Re: dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

On 4/7/2017 1:28 PM, Ulrich Küttler wrote:

With all those forks of dmd now well underway, can I please reserve the name
'dork'? ;)


HAHAHAHAHHAHAHAHAHAHAH!

(Hey, I'm feeling pretty good today!)

[Issue 17303] type error in the href url under the link Systems Programming

[via Digitalmars-d-bugs]

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

--- Comment #1 from a.louan...@gmail.com ---
I have forgotten to add there is same issue on the image link.

href value for Systems Programming link should system-programming instead of
systems-programming

--

[Issue 17303] New: type error in the href url under the link Systems Programming

[via Digitalmars-d-bugs]

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

  Issue ID: 17303
   Summary: type error in the href url under the link Systems
Programming
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: trivial
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: a.louan...@gmail.com

When I click on Systems Programming on the right navigation it does not take me
to Systems Programming part.

Go to https://dlang.org/areas-of-d-usage.html#system-programming,
Then to right navigation. 

The underlying href value for Systems Programming link should
system-programming instead of system_programming

--

Re: dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

On 4/7/2017 12:02 PM, Radu wrote:

Also, big up for the whole community as there is a big positive vibe around the
news and nobody is complaining about basic stuff missing line website, docs,
infrastructure etc.


Yes, it's the most positive response to us I've ever seen on HN, by far.

Re: dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

Note that this also resolves the long-standing legal issue with D's inline 
assembler being backend licensed, and so not portable to gdc/ldc.

Re: dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

On 4/7/2017 2:04 PM, Jesse Phillips wrote:

MIT almost equal though.


I suspect that the reason MIT came up with their own license is so they could 
call it the "MIT License". Branding, ya know.

Re: Running out of memory ctfe 16GB

[ketmar via Digitalmars-d]

Jethro wrote:


On Friday, 7 April 2017 at 21:02:33 UTC, ketmar wrote:

Nierjerson wrote:


How to implement trick is this and are you 100% sure it works?

e.g.,

char[] x;

x.length = 65536;
x.length = 0;


this won't work. the moment you did `.length = 0;`, you are returned to 
point zero.


what you have to do is to maintain "shadow length" yourself, like this:

x.length = 65536;
size_t xpos = 0;

void put (const(char)[] s...) {
foreach (immutable char ch; s) {
if (xpos == x.length) x.length += 65536; // or anything
x[xpos++] = ch;
}
}


thanks, I'll try it... seems like it is basically appender though?


yeah. but the key here is to not use any fancy data structures, it is 
important. the more intermediaries you have, the less control over copying 
is left for you. also, no slice assigns too -- it is dangerous, as it can 
easy go out of control.

Re: Running out of memory ctfe 16GB

[Jethro via Digitalmars-d]

On Friday, 7 April 2017 at 21:02:33 UTC, ketmar wrote:

Nierjerson wrote:


How to implement trick is this and are you 100% sure it works?

e.g.,

char[] x;

x.length = 65536;
x.length = 0;


this won't work. the moment you did `.length = 0;`, you are 
returned to point zero.


what you have to do is to maintain "shadow length" yourself, 
like this:


x.length = 65536;
size_t xpos = 0;

void put (const(char)[] s...) {
foreach (immutable char ch; s) {
if (xpos == x.length) x.length += 65536; // or anything
x[xpos++] = ch;
}
}


thanks, I'll try it... seems like it is basically appender though?

[Issue 17302] New: [SPEC] QualifiedName mangling does not match compiler.

[via Digitalmars-d-bugs]

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

  Issue ID: 17302
   Summary: [SPEC] QualifiedName mangling does not match compiler.
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

I think I saw this somewhere, but couldn't find the bug report.

Nested functions have their parent's parameters encoded into the mangle symbol.

---
void foo()
{
void bar() { }
pragma(msg, bar.mangleof);
}
---
_D4test3fooFZ3barMFNaNbNiNfZv


Where 'FZ' is inserted between 3foo and 3bar.

This is contrary to the spec (removed irrelevant bits that match template and
internal symbols):

---
MangledName:
_D QualifiedName M Type

QualifiedName:
SymbolName
SymbolName QualifiedName

SymbolName:
LName

LName:
Number Name
---


>From the spec, I can only infer that the symbol should be:

_D4test3foo3barMFNaNbNiNfZv

Otherwise a special rule needs to be added to handle functions in SymbolName as
well as TemplateInstanceName.  But that will just cause grammar ambiguities
with LName.


SymbolName:
FunctionName
LName

FunctionName:
Number Name Type

LName:
Number Name


Well... there's *already* a grammar ambiguity as #14591 is somewhat related.

--

Re: dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

On 4/7/2017 1:02 PM, Jack Stouffer wrote:

AFAIK the reasons it was chosen were

1. It's as close to public domain as you can get in international law


Yes.


2. It's on all of the "Accepted OSS Licenses" lists that major corps have
because of Boost itself being used in those companies. If your license isn't on
the list, your project isn't being used.


Yup. We figured every corporation that uses C++ has accepted Boost, so this 
would be a no-brainer for them to accept D's license.

Re: dmd Backend converted to Boost License

[rikki cattermole via Digitalmars-d-announce]

On 07/04/2017 4:14 PM, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to relicense
it. Thank you, Symantec!


Hip hip hooray!
I'm gonna go get some cake in a cup!

Re: dmd Backend converted to Boost License

[rikki cattermole via Digitalmars-d-announce]

On 07/04/2017 10:03 PM, WhatMeWorry wrote:

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to
relicense it. Thank you, Symantec!


I've been coding in D for years now but was unaware of this issue. Could
someone give this licensing neophyte an explanation and some history?


So dmd's backend came directly from dmc. This makes sense as this is the 
time of Digital Mars creation (Walter has been working with this code 
base pretty much since before I was born).
Because of how history went, it was owned by Symantic yet Digital Mars 
still developed it.


So its usage within dmd caused problems, i.e. with packaging and 
distributing because it required explicit permission from Digital Mars 
so that Symantic wouldn't get sued.


Maybe Walter can clarify but this is what I have gathered over the years.

[Issue 11131] variables without linkage shouldn't have a mangling (.mangleof)

[via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #1 from Iain Buclaw  ---
This is still the case.

--

Re: dmd Backend converted to Boost License

[Johannes Pfau via Digitalmars-d-announce]

Am Fri, 7 Apr 2017 08:14:40 -0700
schrieb Walter Bright :

> https://github.com/dlang/dmd/pull/6680
> 
> Yes, this is for real! Symantec has given their permission to
> relicense it. Thank you, Symantec!

Great news! Maybe someone could notify http://phoronix.com . They've
blogged about D before and reach quite some linux users and developers.


-- Johannes

Re: Function names and lambdas

[Ali Çehreli via Digitalmars-d-learn]

On 04/07/2017 11:19 AM, Yuxuan Shui wrote:
> On Thursday, 6 April 2017 at 18:45:26 UTC, Ali Çehreli wrote:
>> On 04/06/2017 11:37 AM, Russel Winder via Digitalmars-d-learn wrote:
>>> [...]
>>
>> I think it's just a design choice. C implicitly converts the name of
>> the function to a pointer to that function. D requires the explicit &
>> operator:
>>
>> alias Func = int function(int);
>>
>> int foo(int i) {
>> return i;
>> }
>>
>> void main() {
>> Func[] funcs = [  ];
>> }
>>
>> Close to what you mentioned, name of the function can be used as an
>> alias template parameter:
>>
>> void bar(alias func)() {
>> func(42);
>> }
>>
>> int foo(int i) {
>> return i;
>> }
>>
>> void main() {
>> bar!foo();
>> }
>>
>> Ali
>
> Main reason is probably UFCS.

Main reason for D not supporting the name-to-pointer mapping? I don't 
think so because as far as I know this has been the case since very 
early on but UFCS came very much later.


Ali

Re: dmd Backend converted to Boost License

[Jesse Phillips via Digitalmars-d-announce]

On Friday, 7 April 2017 at 19:37:14 UTC, Jonathan M Davis wrote:
On Friday, April 07, 2017 08:14:40 Walter Bright via 
Digitalmars-d-announce wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Well, this is certainly great news.

Does this make dmd the only compiler that's fully 
boost-licensed? Usually, licenses like the GPL or BSD license 
get used. I don't get the impression that the boost license is 
all that common - at least not for actual programs as opposed 
to libraries. From what I've seen, the fact that we use it so 
heavily in the D community is abnormal, though it's as 
hassle-free as you can get with an open source license, which 
is great.


- Jonathan M Davis


I was thinking the same thing. Its probably the most permissive 
compiler out there now. MIT almost equal though.

Re: dmd Backend converted to Boost License

[WhatMeWorry via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


I've been coding in D for years now but was unaware of this 
issue. Could someone give this licensing neophyte an explanation 
and some history?


Thanks.

Re: Running out of memory ctfe 16GB

[ketmar via Digitalmars-d]

Nierjerson wrote:


How to implement trick is this and are you 100% sure it works?

e.g.,

char[] x;

x.length = 65536;
x.length = 0;


this won't work. the moment you did `.length = 0;`, you are returned to 
point zero.


what you have to do is to maintain "shadow length" yourself, like this:

x.length = 65536;
size_t xpos = 0;

void put (const(char)[] s...) {
foreach (immutable char ch; s) {
if (xpos == x.length) x.length += 65536; // or anything
x[xpos++] = ch;
}
}

Re: Running out of memory ctfe 16GB

[Nierjerson via Digitalmars-d]

On Thursday, 6 April 2017 at 22:42:28 UTC, ketmar wrote:

H. S. Teoh wrote:

On Fri, Apr 07, 2017 at 01:16:20AM +0300, ketmar via 
Digitalmars-d wrote:

Dmitry Olshansky wrote:


[...]
or use `char[]` buffer instead, manually increasing it's size 
by some
step.  assigning to such array won't do any copies, so 
growing the
array by 32kb (or even several mb) steps will reduce memory 
footprint

for string builders considerably.


Are you sure?  AFAIK, the current CTFE engine will copy values 
every
time they are assigned, regardless of whether they are 
technically

"mutable" or not.


i'm sure: i'm using this trick alot. without that, CTFE won't 
be able to correctly work with arrays at all, 'cause assigning 
to mutable array element should be visible with all other 
slices of that array.


sure, CTFE can technically allocate "hidden array object" and 
re-assign it each time, but it actually has a concept of "owned 
by CTFE" objects, and if the array was created in CTFE, it 
becomes owned by CTFE, and copies will be made only on array 
resize.


How to implement trick is this and are you 100% sure it works?

e.g.,

char[] x;

x.length = 65536;
x.length = 0;

?

If if what you say is correct it should solve my memory problem. 
I do a lot of string appending and memory usage seems to grows 
exponentially.

Re: Self-modifying code! The real kind!

[Era Scarecrow via Digitalmars-d]

On Friday, 7 April 2017 at 20:43:52 UTC, Stefan Koch wrote:

On Thursday, 6 April 2017 at 05:36:52 UTC, Swoorup Joshi wrote:
Self-modifying might be the answer to all sorts of performance 
problems due to branching.


No it's not! You are throwing away your i-cache AND mess up the 
branch prediction.


 From the opening statement it looks and sounds more like loading 
and unloading DLL files... rather than self-modifying code.


 Self modifying code isn't really that practical anymore, the 
best example working is compressed executables (UPX and similar), 
but those only expand optimized code from a compressed cache and 
then changes the block to executable, it doesn't really modify 
the code at all.


 Perhaps an actual use case for self-modifying code would be to 
give you a quick & dirty compile for a function, and then work on 
optimizing it, then switch the calls appropriately to the new 
function once it's optimized, which is more useful to for say JIT 
circumstances and emulation, and less in statically known source 
code.

Re: Self-modifying code! The real kind!

[Jethro via Digitalmars-d]

On Friday, 7 April 2017 at 18:54:10 UTC, H. S. Teoh wrote:
On Thu, Apr 06, 2017 at 05:36:52AM +, Swoorup Joshi via 
Digitalmars-d wrote:
Self-modifying might be the answer to all sorts of performance 
problems due to branching. Only problem is security I guess. 
Don't they disable writes to code segment anyway?

[...]

I don't think the OP was talking about self-modifying code in 
that sense.  I think he was talking about a program that 
modifies its own *source code*, which is a different thing than 
a program that modifies its own machine code while that machine 
code is running.



T


Yeah, that's what I mean. Basically D's meta programming 
accomplishes the same effect for the most part but it is somewhat 
limited. Mainly since one can't write to files for "security" 
reasons(I'd like to know of any real world security issues that 
this has caused!).

Re: Self-modifying code! The real kind!

[Stefan Koch via Digitalmars-d]

On Thursday, 6 April 2017 at 05:36:52 UTC, Swoorup Joshi wrote:
Self-modifying might be the answer to all sorts of performance 
problems due to branching.


No it's not! You are throwing away your i-cache AND mess up the 
branch prediction.

Re: Is DMD breaking BigInt?

[David Nadlinger via Digitalmars-d-learn]

On Friday, 7 April 2017 at 17:06:31 UTC, Russel Winder wrote:
If anyone has any useful intelligence as to what happening and 
how I

can workaround it, I'd be a grateful bunny.


You might want to check with LDC from Git master first to see 
whether it is in fact a 2.073-related problem. — David

Re: dmd Backend converted to Boost License

[Ulrich Küttler via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


This is brilliant! Fantastic!

With all those forks of dmd now well underway, can I please 
reserve the name 'dork'? ;)

Re: Is DMD breaking BigInt?

[Jack Stouffer via Digitalmars-d-learn]

On Friday, 7 April 2017 at 17:06:31 UTC, Russel Winder wrote:
Simple Dub build of a Factorial example using Unit-Threaded for 
testing. Works fine with ldc2 breaks with dmd.


Can you post the code your using?

Re: dmd Backend converted to Boost License

[Jonathan M Davis via Digitalmars-d-announce]

On Friday, April 07, 2017 20:02:52 Jack Stouffer via Digitalmars-d-announce 
wrote:
> On Friday, 7 April 2017 at 19:37:14 UTC, Jonathan M Davis wrote:
> > From what I've seen, the fact that we use it so heavily in the
> > D community is abnormal
>
> AFAIK the reasons it was chosen were
>
> 1. It's as close to public domain as you can get in international
> law
> 2. It's on all of the "Accepted OSS Licenses" lists that major
> corps have because of Boost itself being used in those companies.
> If your license isn't on the list, your project isn't being used.

Oh, I'm quite familiar with why Walter chose the boost license, and I agree
with that choice (I use it for all of my projects). My point was that it
doesn't seem to be a very common choice outside of the D community (at least
from what I've seen).

- Jonathan M Davis

Re: dmd Backend converted to Boost License

[bluecat via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Very good news and a solid accomplishment for being on top of 
Hacker News (as of writing this). It's very good when dlang is 
discussed on the site along with the other trendy languages. It 
certainly deserves to be within common programming discourse.  
Also, congratulations on this big accomplishment!

Re: dmd Backend converted to Boost License

[Jack Stouffer via Digitalmars-d-announce]

On Friday, 7 April 2017 at 19:37:14 UTC, Jonathan M Davis wrote:
From what I've seen, the fact that we use it so heavily in the 
D community is abnormal


AFAIK the reasons it was chosen were

1. It's as close to public domain as you can get in international 
law
2. It's on all of the "Accepted OSS Licenses" lists that major 
corps have because of Boost itself being used in those companies. 
If your license isn't on the list, your project isn't being used.

Re: dmd Backend converted to Boost License

[Jonathan M Davis via Digitalmars-d-announce]

On Friday, April 07, 2017 08:14:40 Walter Bright via Digitalmars-d-announce 
wrote:
> https://github.com/dlang/dmd/pull/6680
>
> Yes, this is for real! Symantec has given their permission to relicense
> it. Thank you, Symantec!

Well, this is certainly great news.

Does this make dmd the only compiler that's fully boost-licensed? Usually,
licenses like the GPL or BSD license get used. I don't get the impression
that the boost license is all that common - at least not for actual
programs as opposed to libraries. From what I've seen, the fact that we use
it so heavily in the D community is abnormal, though it's as hassle-free as
you can get with an open source license, which is great.

- Jonathan M Davis

Re: dmd Backend converted to Boost License

[Sameer Pradhan via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


That is really good news!
One less shackle preventing users from adopting :D (and if I am 
not mistaken, directly contributing to DMD)


I was just discussing it with Steve at our Boston D Meetup last 
week and he explained how it was "techincally" free, but needed 
your explicit blessing for each case—which was guaranteed. 
Strange how things work in this world many times—especially where 
software is involved.


--
Sameer

Re: dmd Backend converted to Boost License

[Radu via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Glorious day for D and Dlangers.

Congrats Walter for the tenacity and thanks Symantec for coming 
to senses:)


Also, big up for the whole community as there is a big positive 
vibe around the news and nobody is complaining about basic stuff 
missing line website, docs, infrastructure etc.


Cheers!

Re: Self-modifying code! The real kind!

[H. S. Teoh via Digitalmars-d]

On Thu, Apr 06, 2017 at 05:36:52AM +, Swoorup Joshi via Digitalmars-d wrote:
> Self-modifying might be the answer to all sorts of performance
> problems due to branching. Only problem is security I guess. Don't
> they disable writes to code segment anyway?
[...]

I don't think the OP was talking about self-modifying code in that
sense.  I think he was talking about a program that modifies its own
*source code*, which is a different thing than a program that modifies
its own machine code while that machine code is running.


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit 
forever.

Re: dmd Backend converted to Boost License

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

On Fri, Apr 07, 2017 at 08:14:40AM -0700, Walter Bright via 
Digitalmars-d-announce wrote:
> https://github.com/dlang/dmd/pull/6680
> 
> Yes, this is for real! Symantec has given their permission to
> relicense it.  Thank you, Symantec!

Hooray!!  Finally!!!

Never thought I'd see this day, but here it is!

Yes, and now it's time to push for dmd to get into Debian and the rest
of the FOSS ecosystem.


T

-- 
To err is human; to forgive is not our policy. -- Samuel Adler

Re: dmd Backend converted to Boost License

[David Oftedal via Digitalmars-d-announce]

Wow, congratulations, and a big thank you to those who made it 
happen.

Re: Function names and lambdas

[Yuxuan Shui via Digitalmars-d-learn]

On Thursday, 6 April 2017 at 18:45:26 UTC, Ali Çehreli wrote:
On 04/06/2017 11:37 AM, Russel Winder via Digitalmars-d-learn 
wrote:

[...]


I think it's just a design choice. C implicitly converts the 
name of the function to a pointer to that function. D requires 
the explicit & operator:


alias Func = int function(int);

int foo(int i) {
return i;
}

void main() {
Func[] funcs = [  ];
}

Close to what you mentioned, name of the function can be used 
as an alias template parameter:


void bar(alias func)() {
func(42);
}

int foo(int i) {
return i;
}

void main() {
bar!foo();
}

Ali


Main reason is probably UFCS.

Re: dmd Backend converted to Boost License

[Russel Winder via Digitalmars-d-announce]

On Fri, 2017-04-07 at 18:51 +0100, Russel Winder wrote:
> […]
> So now the campaign begins to get DMD formally packaged by Debian and
> Fedora.
> 
> Having DMD packaged as well as LDC and GDC will be a great thing for
> marketing of D.

We also need GDC in Fedora.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: GDC and shared libraries

[Russel Winder via Digitalmars-d]

On Fri, 2017-04-07 at 19:36 +0200, Johannes Pfau via Digitalmars-d
wrote:
> 
[…]
> Unfortunately the GCC version (5.3.1) doesn't say much. According to
> the GDC changelog shared library support was finished September last
> year. This is frontend version >= 2.067, though we never released
> 2.067
> (there was never a stable 2.067 revision). 2.068.2 releases should
> have
> full shared library support and of course the current master
> gdc-6/5/4.9/4.8 branches have full support as well.

I'll just have to try stuff with various GDC compilers I can get my
hands on. Debian has 6.3.1, but sadly Fedora does not package GDC so I
have no access to 7.0.1. I guess I'll have to get a MacOS machine out
to try MacPorts.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: [OT] Python formatting [was ISO C++ 17 changes]

[Russel Winder via Digitalmars-d]

On Fri, 2017-04-07 at 14:05 +, Jack Stouffer via Digitalmars-d
wrote:
> On Friday, 7 April 2017 at 09:01:37 UTC, Russel Winder wrote:
> > Why three? There is the format function and now f-strings, that 
> > makes two.
> 
> 1. the format function
> 2. the new format strings
> 3. the old "" % syntax

Well 3 doesn't count, it is deprecated. ;-)

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: dmd Backend converted to Boost License

[Russel Winder via Digitalmars-d-announce]

On Fri, 2017-04-07 at 08:14 -0700, Walter Bright via Digitalmars-d-
announce wrote:
> https://github.com/dlang/dmd/pull/6680
> 
> Yes, this is for real! Symantec has given their permission to
> relicense it. 
> Thank you, Symantec!

So now the campaign begins to get DMD formally packaged by Debian and
Fedora.

Having DMD packaged as well as LDC and GDC will be a great thing for
marketing of D.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

On 4/7/2017 9:10 AM, Andrei Alexandrescu wrote:

On 04/07/2017 12:01 PM, Jack Stouffer wrote:

Reddit:
https://www.reddit.com/r/programming/comments/6419py/the_official_d_compiler_is_now_free_as_in_freedom/


Thanks, someone also put it on hackernews - found it by browsing for "new"
threads. -- Andrei



It's the number one story on hackernews at the moment:

  https://news.ycombinator.com/news

Usually D does better on reddit than hackernews, but today it is doing way 
better on hackernews. 150 points!

Re: dmd Backend converted to Boost License

[Joakim via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


That was nice of Symantec to finally grant your request.  Will 
this mean more work put into the backend?  Regardless, good to 
stop the FUD about the backend licensing.

Re: GDC and shared libraries

[Johannes Pfau via Digitalmars-d]

Am Fri, 07 Apr 2017 17:29:46 +0100
schrieb Russel Winder via Digitalmars-d :

> At GDC 5.3.1 there was no support for shared libraries, or, at least,
> so I believe and encoded in the SCons tests. Is there a version of GDC
> from which shared libraries are supported?
> 

Unfortunately the GCC version (5.3.1) doesn't say much. According to
the GDC changelog shared library support was finished September last
year. This is frontend version >= 2.067, though we never released 2.067
(there was never a stable 2.067 revision). 2.068.2 releases should have
full shared library support and of course the current master
gdc-6/5/4.9/4.8 branches have full support as well.


-- Johannes

Re: dmd Backend converted to Boost License

[deadalnix via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


<3

Is DMD breaking BigInt?

[Russel Winder via Digitalmars-d-learn]

Simple Dub build of a Factorial example using Unit-Threaded for
testing. Works fine with ldc2 breaks with dmd. This is on Debian Sid
fully up to date. 

|> ldc2 --version
LDC - the LLVM D compiler (1.1.1):
  based on DMD v2.071.2 and LLVM 3.9.1
  built with LDC - the LLVM D compiler (1.1.0)
  Default target: x86_64-pc-linux-gnu
  Host CPU: broadwell
  http://dlang.org - http://wiki.dlang.org/LDC

|> dmd --version
DMD64 D Compiler v2.073.2

|> dub test --compiler=ldc2
Package factorial (configuration "unittest") defines no import paths, use 
{"importPaths": [...]} or the default package directory structure to fix this.
Running custom 'unittest' configuration.
Performing "unittest" build using ldc2 for x86_64.
unit-threaded 0.7.11: target for configuration "library" is up to date.
factorial ~master: building configuration "unittest"...
Running pre-build commands...
Building package unit-threaded in 
/home/users/russel/.dub/packages/unit-threaded-0.7.11/unit-threaded/
Performing "$DFLAGS" build using dmd for x86_64.
unit-threaded 0.7.11: building configuration "gen_ut_main"...
Linking...
Running 
../../../../.dub/packages/unit-threaded-0.7.11/unit-threaded/gen_ut_main -f 
ut_main.d
To force a rebuild of up-to-date targets, run again with --force.
Running ./factorial-test 

Automatically generated file ut_main.d
Running unit tests from dirs ["."]
factorial.Check the base case for all algorithms.:
factorial.Check the property for all algorithms.:
factorial.Traditional example-based testing.:

Time taken: 34 ms, 363 μs, and 2 hnsecs
3 test(s) run, 0 failed.

OK!

|> dub test
Package factorial (configuration "unittest") defines no import paths, use 
{"importPaths": [...]} or the default package directory structure to fix this.
Running custom 'unittest' configuration.
Performing "unittest" build using dmd for x86_64.
unit-threaded 0.7.11: target for configuration "library" is up to date.
factorial ~master: building configuration "unittest"...
Running pre-build commands...
Building package unit-threaded in 
/home/users/russel/.dub/packages/unit-threaded-0.7.11/unit-threaded/
Performing "$DFLAGS" build using dmd for x86_64.
unit-threaded 0.7.11: building configuration "gen_ut_main"...
Linking...
Running 
../../../../.dub/packages/unit-threaded-0.7.11/unit-threaded/gen_ut_main -f 
ut_main.d
factorial.d(71,15): Error: template std.bigint.BigInt.__ctor cannot deduce 
function from argument types !()(string) immutable, candidates are:
/usr/include/dmd/phobos/std/bigint.d(64,5):
std.bigint.BigInt.__ctor(Range)(Range s) if (isBidirectionalRange!Range && 
isSomeChar!(ElementType!Range) && !isInfinite!Range)
/usr/include/dmd/phobos/std/bigint.d(146,5):
std.bigint.BigInt.__ctor(T)(T x) if (isIntegral!T)
/usr/include/dmd/phobos/std/bigint.d(162,5):
std.bigint.BigInt.__ctor(T)(T x) if (is(Unqual!T == BigInt))
dmd failed with exit code 1.


If anyone has any useful intelligence as to what happening and how I
can workaround it, I'd be a grateful bunny.
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: dmd Backend converted to Boost License

[Jon Degenhardt via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Congrats, this is a great result!

Re: Exceptions in @nogc code

[deadalnix via Digitalmars-d]

On Thursday, 6 April 2017 at 16:56:10 UTC, Olivier FAURE wrote:
I'm not saying you're wrong, but there's a different between 
saying "You should flesh out your idea" and "We're not going to 
respond formally before you submit a DIP".


Yes that's essentially my problem here.

Re: Exceptions in @nogc code

[deadalnix via Digitalmars-d]

On Thursday, 6 April 2017 at 22:11:55 UTC, Walter Bright wrote:

On 4/6/2017 2:18 PM, H. S. Teoh via Digitalmars-d wrote:
You were asking for a link to deadalnix's original discussion, 
and
that's the link I found (somebody else also posted a link to 
the same

discussion).


Only deadalnix can confirm that's what he's talking about.


Yes this: 
https://forum.dlang.org/thread/kpgilxyyrrluxpepe...@forum.dlang.org
Also this: 
https://forum.dlang.org/post/kluaojijixhwigouj...@forum.dlang.org


I also produced a fairly detailed spec of how lifetime can be 
tracked in the lifetime ML. This address scope and do not require 
owned by itself. Considering the compiler infer what it calls 
"unique" already, it could solve the @nogc Exception problem to 
some extent without the owned part. Because it is in a ML, I 
cannot post a link.

GDC and shared libraries

[Russel Winder via Digitalmars-d]

At GDC 5.3.1 there was no support for shared libraries, or, at least,
so I believe and encoded in the SCons tests. Is there a version of GDC
from which shared libraries are supported?

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: dmd Backend converted to Boost License

[bachmeier via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Great news! By 2027, we should no longer hear objections to D 
based on the backend license.

Re: Walter and Andrei and community relationship management

[Dibyendu Majumdar via Digitalmars-d]

On Thursday, 6 April 2017 at 07:24:28 UTC, Nick B wrote:
But, it seems that while Walter and Andrei are prepared to put 
a proposal out on the newsgroup, and then discuss it with the 
community, and then LATER, if its any good,

state they will formally document it into a DIP.

For the community, it seems different rules apply. In-depth 
news-groups discussions for new proposals are firstly 
encouraged and then later discouraged, with the ultimate
response that the proposal MUST be in the form of a 
time-consuming DIP, to be considered, even if it will 
ultimately wastes everyone time, and cause resentment in the 
community.


Hi,

I am only familiar with the Lua world from a language design 
point of view - in that world, only the Lua core team decide what 
features can go into the language. In fact they don't even accept 
code contributions - everything is coded by the core team - even 
when they accept an idea.


I don't think a language can be designed by a committee. My 
impression is that Walter is very decent about replying to 
criticisms, even though there is no need in my view for him to do 
so.


I would in fact urge the D team to make it explicit that D 
language design rests solely Walter and Andrei - and while others 
can make suggestions as to what should go in, only Walter and 
Andrei decide what actually goes in.


Regards
Dibyendu

Re: dmd Backend converted to Boost License

[Basile B. via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Good news. Question:

Does this apply from now or can the previous DMD releases also be 
considered as 100% Boost licensed ?

Re: dmd Backend converted to Boost License

[ketmar via Digitalmars-d-announce]

Walter Bright wrote:


https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to relicense 
it. Thank you, Symantec!


i don't even know what to say... thank you! i didn't even hoped that this 
will happen. what a glorious day today.

Re: dmd Backend converted to Boost License

[Andrei Alexandrescu via Digitalmars-d-announce]

On 04/07/2017 12:01 PM, Jack Stouffer wrote:

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to
relicense it. Thank you, Symantec!


Reddit:
https://www.reddit.com/r/programming/comments/6419py/the_official_d_compiler_is_now_free_as_in_freedom/


Thanks, someone also put it on hackernews - found it by browsing for 
"new" threads. -- Andrei

[Issue 17297] Object.~this not being @nogc is severely limiting @nogc applicability

[via Digitalmars-d-bugs]

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

Marco Leise  changed:

   What|Removed |Added

 CC||marco.le...@gmx.de

--- Comment #2 from Marco Leise  ---
A previous bug report about rt_finalize and @nogc is issue 15246. It takes a
look from a different angle, but boils down to the same fundamental issues.
Points 1/ (OOP nature) and 2/ (non-inheritance of ~this) from my previous
commentator are also discussed there and I gave an example of an "OOP nature"
case that I would like to cross post here for illustration purposes...

Quote:

If we did in fact have virtual destructors like C++, the general rule with
inheritance applies: The derived thing must be usable everywhere the base class
is used. That disallows the removal of attributes on virtual function
overrides:

class C {
   ~this() @safe
}

class D {
   override ~this(); // @system
}

void foo(C c) @safe 
{
   // Destroying D is unsafe, but we can't statically check,
   // because for all we know it is at least a C.
   destroy(c);
}

void main()
{
   foo(new D);
}

--

Re: dmd Backend converted to Boost License

[Jack Stouffer via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Reddit: 
https://www.reddit.com/r/programming/comments/6419py/the_official_d_compiler_is_now_free_as_in_freedom/

Re: dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

On 4/7/2017 8:25 AM, Joseph Rushton Wakeling wrote:

Question: will this 'fix' be backported to existing stable releases?  Or will it
just apply going forward?

I ask because it could make a difference to what is legally possible to package
for e.g. Linux distros, etc.


It applies to all of it!

Re: dmd Backend converted to Boost License

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Question: will this 'fix' be backported to existing stable 
releases?  Or will it just apply going forward?


I ask because it could make a difference to what is legally 
possible to package for e.g. Linux distros, etc.

Re: dmd Backend converted to Boost License

[Jack Stouffer via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


A great step forward for the language!

A huge thank you to everyone who made this happen.

Re: dmd Backend converted to Boost License

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 7 April 2017 at 15:14:40 UTC, Walter Bright wrote:

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to 
relicense it. Thank you, Symantec!


Congratulations Walter!  This is marvellous news :-)

dmd Backend converted to Boost License

[Walter Bright via Digitalmars-d-announce]

https://github.com/dlang/dmd/pull/6680

Yes, this is for real! Symantec has given their permission to relicense it. 
Thank you, Symantec!

Re: What are we going to do about mobile?

[Marco Leise via Digitalmars-d]

Am Thu, 06 Apr 2017 05:24:07 +
schrieb Joakim :

> D is currently built and optimized for that dying PC platform.

As long as the world still needs headless machines running
web sites, simulations, cloud services, ...;
as long as we still need to edit office documents, run
multimedia software to edit photos and video, play AAA video
games the "PC master race" way;
I'm confident that we have a way to go until all the
notebooks, PCs and Macs disappear. :)

I'd say we just have /more/ fully capable computers around us
nowadays. I'd probably roughly split it into
- web/cloud server machines, often running VMs
- scientific computation clusters
- desktops (including notebooks)
- smart phones
- embedded devices running Linux/Android (TVs, receivers,
  refrigerators, photo boxes, etc...)

When targeting smart phones you have to comply to every
manufacturer's frameworks and security measures. On the other
hand you can directly sell software and services.

The embedded device I know best is my TV receiver, which boots
into Linux and then starts a statically compiled executable
that handles GUI rendering, remote control input and
communication with the hardware. If you knew the protocols you
could replace it with something written in Dlang.

These devices are not as prominent as phones, but the
barrier of entry is relatively low for many applications once
you have bindings to a couple of frequently needed C libraries
such as freetype, ffmpeg or opencv.

> What needs to be done?  Same as anything else, we need people to 
> try it out and pitch in, like this guy who's now trying ldc out 
> on an embedded device with an old ARMv5 core:
>
>[…]
>
> I realize D is never going to have a polished devkit for mobile 
> unless a company steps up and charges for that work.  But we can 
> do a lot better than the complacency from the community we have 
> now.

As you can use mostly the same compiler targets for embedded
as for phones, your best bet to stabilize the ldc targets are
probably the embedded developers, because they can see the
immediate benefit for their projects and their knowledge about
the underlying hardware can help track down bugs.

-- 
Marco

Re: [OT] Python formatting [was ISO C++ 17 changes]

[Jack Stouffer via Digitalmars-d]

On Friday, 7 April 2017 at 09:01:37 UTC, Russel Winder wrote:
Why three? There is the format function and now f-strings, that 
makes two.


1. the format function
2. the new format strings
3. the old "" % syntax

Re: Design to interfaces or Design to introspections

[Marco Leise via Digitalmars-d]

Am Fri, 07 Apr 2017 11:51:10 +
schrieb سليمان السهمي (Soulaïman Sahmi)
:

> […]
> 
> Then I stumbled upon DIP84, which reminded me of the other GoF' 
> principle "Program to an interface, not an implementation".
> And I started wondering why would I ever write code like this:
> 
>  auto someAlgorithm(SomeInterface obj) { /* ... */ }
> 
> When I can do this:
> 
>  auto someAlgorithm(I)(I obj) if(isSomeInterface!I) { /* ... 
> /* }
> 
> or more generically:
> 
>  auto someAlgorithm(I)(I obj)
>  if(satisfiesInterface!(I, SomeInterface, SomeOtherInterface 
> /*... etc */)
>  { /* body ... /* }
> 
> This would be a modern design to introspection? that goes with
> the modern design by introspection.
> […]
> 
> What do you think.

Running the same algorithm on class and struct instances is a
much desired feature, especially where programmers tend to
fall into two camps where one mostly uses classes and the
other mostly uses structs.
But reasons for using one over the other slip into the concept
of one-function-to-rule-them-all as well. And there is more to
consider:

- Interfaces variables hold references to the data, while for
  structs you have to explicitly add "ref" to the argument or
  else the algorithm will work on a (shallow) copy.
- Wrapping structs in interfaces and using interfaces
  exclusively results in only on instance of the algorithm
  ending up in the executable instead of one per each class
  and struct type, which helps with things like executable
  size, instruction cache hits and debug symbol size and
  readability.
- Some forms of licensing break when using templates in the
  public API of libraries. Two examples:
  A proprietary software company sells programming libraries.
  They need to keep their source code private to prevent theft,
  but if their API used templates they'd have to provide
  sources for them and any templates used inside of them.
  On the other hand a GPL licensed open source library - to be
  usable in a proprietary project - must ensure that none of
  its code gets compiled into the target application. Again
  templates would break that.

Then there are other general considerations in favor of
interfaces or templates.

- Template methods are not virtual functions that you can
  override in a child class.
- Calling virtual methods on interfaces is slower (on some
  architectures more than others)[1] and there is no static
  introspection to decide some code paths at compile time.
  (Devirtualization is a hot topic.)
- Templates increase complexity for the compiler and runtime.
  There have been a few subtle issues in the past, for example
  symbol name length explosion[2] and object files containing
  old code in separate compilation scenarios[3].

[1] 
http://eli.thegreenplace.net/2013/12/05/the-cost-of-dynamic-virtual-calls-vs-static-crtp-dispatch-in-c
[2] http://forum.dlang.org/post/efissyhagontcungo...@forum.dlang.org
[3] https://issues.dlang.org/show_bug.cgi?id=9922

-- 
Marco

Re: Function names and lambdas

[Russel Winder via Digitalmars-d-learn]

On Thu, 2017-04-06 at 11:45 -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> 
[…]
> I think it's just a design choice. C implicitly converts the name of
> the 
> function to a pointer to that function. D requires the explicit &
> operator:

One of the dangers of being a bit like and a replacement for another
language is that often people carry ideas over incorrectly, as I have
here.

> alias Func = int function(int);
> 
> int foo(int i) {
>  return i;
> }
> 
> void main() {
>  Func[] funcs = [  ];
> }

I just did:

immutable funcs = [tuple(, "foo")];

as I don't need the name of the type, but I do need a string form of
the name of the function.

> Close to what you mentioned, name of the function can be used as an 
> alias template parameter:
> 
> void bar(alias func)() {
>  func(42);
> }
> 
> int foo(int i) {
>  return i;
> }
> 
> void main() {
>  bar!foo();
> }

Good to know but for situation here the  was what was needed.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: is char[] faster than string?

[Anonymouse via Digitalmars-d-learn]

On Wednesday, 5 April 2017 at 22:05:07 UTC, H. S. Teoh wrote:
If you are doing lots of concatenation and produce a single big 
string at the end, take a look at std.array.appender.


Though if you're concerned about performance, you really should 
run a profiler. Last I heard, appender may not be that much 
faster than using ~=, but I could be wrong.


If my understanding serves, and it's very likely that it doesn't, 
then it works precisely as normally appending does but keeps 
track of array capacity on its own, so the GC doesn't have to do 
(expensive?) queries upon every append.


But when it comes to optimization, my advice is, profile, 
profile, profile.


This. valgrind --tool=callgrind, ddemangle and QCachegrind are 
your best friends.

Design to interfaces or Design to introspections

[via Digitalmars-d]

Back at dconf 2015, Andrei introduced design-by-introspection in 
his talk "Generic programing must go", he showed that not only 
classes have "class explosion" problems but so do templates.
The basic idea behind design by introspection the way I 
understand it is similar to the one  behind design patterns. One 
of the Gang of Four' two principles is "Favor object composition 
over class inheritance." i.e. inheritance must go, as Andrei 
would say.


Then I stumbled upon DIP84, which reminded me of the other GoF' 
principle "Program to an interface, not an implementation".

And I started wondering why would I ever write code like this:

auto someAlgorithm(SomeInterface obj) { /* ... */ }

When I can do this:

auto someAlgorithm(I)(I obj) if(isSomeInterface!I) { /* ... 
/* }


or more generically:

auto someAlgorithm(I)(I obj)
if(satisfiesInterface!(I, SomeInterface, SomeOtherInterface 
/*... etc */)

{ /* body ... /* }

This would be a modern design to introspection? that goes with 
the modern design by introspection.
While this approach has more code over the classic one, It has 
the advantage of working "natively" for both classes and structs 
(without dirty tricks like std.experimental.typecons.wrap does 
for structs), and would in the end save you a lot of code 
duplication, chaos and death if used along with 
design-by-introspection.


What do you think.

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

[via Digitalmars-d-bugs]

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

Alex Goltman  changed:

   What|Removed |Added

 CC||alex.golt...@gmail.com

--- Comment #9 from Alex Goltman  ---
looks like a duplicate of my issue
https://issues.dlang.org/show_bug.cgi?id=17218

--

Re: Creating Tuple or AliasSeq

[ANtlord via Digitalmars-d-learn]

On Friday, 7 April 2017 at 07:46:40 UTC, Ali Çehreli wrote:


Here is a solution:

auto objectFactory(ObjectType, Args...)(Args args) {
import std.algorithm : cartesianProduct, map;
import std.array : array;

return cartesianProduct(args).map!(a => 
ObjectType(a.expand)).array;

}

struct Pair {
int number;
string name;
}

import std.stdio;

void main() {
auto pairKit = objectFactory!(Pair)([1, 2], ["qwe", "asd"]);
auto pairSet = pairKit;
writeln(pairSet);
}

Ali


I can't understand. Documentation of cartesianProduct points out 
about finite arrays. At least one of arrays must be a inifinte 
array. As far as I know finite arrays is `int[3]` and infinite is 
`int[]` 
(https://dlang.org/library/std/range/primitives/is_infinite.html). Am I right?


If I am then I can't understand why DMD return error about finite 
ranges compiling following code.


struct Hay {
int a;
@disable this(this);
@disable this();
this(int a){
this.a = a;
}

}
Hay[] params = [ Hay(1), Hay(23) ];
auto products = cartesianProduct(params, params);

Error text:

static assert  "cartesianProduct involving finite ranges must 
have at least one finite forward range"


I noticed that removing disabling default constructors helps. 
Does that mean an array contains objects of a struct with 
disabled default constructor is finite?

Re: Visual D 0.44 released - VC project integration and Concord debugger extension

[tetyys via Digitalmars-d-announce]

On Friday, 7 April 2017 at 07:59:46 UTC, Rainer Schuetze wrote:



On 12.03.2017 13:09, Rainer Schuetze wrote:

preliminary support for VS 2017 (no VC project integration yet)


VC project integration is now also available in VS 2017. Check 
out


https://github.com/dlang/visuald/releases/download/v0.44.2/VisualD-v0.44.2.exe

which also includes some bug fixes.


awesome, nice to have fast support for new visual studio version

Re: What are we going to do about mobile?

[rikki cattermole via Digitalmars-d]

On 07/04/2017 10:34 AM, Joakim wrote:

On Thursday, 6 April 2017 at 05:32:41 UTC, rikki cattermole wrote:

IMO there is two things that need to be done to get D for mobile:

1: ldc needs to natively target and distribute binaries for Android
(MIPS, ARM, at least).


I'm not sure what you mean by "natively target."  Do you mean that the
shipping ldc compiler should come with Android/ARM target support built
in?  That can be done, but it's useless without a stdlib cross-compiled
for the target and ldc doesn't provide the cross-compiler
scripts/toolchain with its releases that would allow you to easily start
cross-compiling, even though the compiler itself is capable.  Instead, I
provide a cross-compiler for linux/x64 that comes with a cross-compiled
stdlib for Android/ARM, and link to instructions on how to use it with
the Android NDK toolchain.


So basically druntime, Phobos all good to go basically be able to do 
ldc2 test.d and get a valid (yet to be apk'd) executable. But the point 
was to have it all officially supported and ready to go with clear 
instructions on how to use it.



If you mean a native ldc compiler, that's already been done and provided
in the link above, ie a native ldc that you can run _on_ your Android
device.  That's what I use, since my development hardware is an
Android/ARM tablet (I have not used an x86 or x64 device in more than a
year, instead renting out an x64 vps recently to build the cross-compiler).

As for Android/MIPS, nobody uses it, just like Android/x86 now that
Intel has pulled out of the mobile market.  No point.


Ok, my knowledge is more out of date then ;)


2: extern(JNI) seriously, its a pain to work with Java over JNI
otherwise. It would be worse then not having extern(Obj-C).


I don't think it's that bad, but sure, we could always make it easier.


After working on djvm, there is no way I'd want to not have it. It's 
just too hard to do it library only.

Re: What are we going to do about mobile?

[Joakim via Digitalmars-d]

On Thursday, 6 April 2017 at 05:32:41 UTC, rikki cattermole wrote:
IMO there is two things that need to be done to get D for 
mobile:


1: ldc needs to natively target and distribute binaries for 
Android (MIPS, ARM, at least).


I'm not sure what you mean by "natively target."  Do you mean 
that the shipping ldc compiler should come with Android/ARM 
target support built in?  That can be done, but it's useless 
without a stdlib cross-compiled for the target and ldc doesn't 
provide the cross-compiler scripts/toolchain with its releases 
that would allow you to easily start cross-compiling, even though 
the compiler itself is capable.  Instead, I provide a 
cross-compiler for linux/x64 that comes with a cross-compiled 
stdlib for Android/ARM, and link to instructions on how to use it 
with the Android NDK toolchain.


If you mean a native ldc compiler, that's already been done and 
provided in the link above, ie a native ldc that you can run _on_ 
your Android device.  That's what I use, since my development 
hardware is an Android/ARM tablet (I have not used an x86 or x64 
device in more than a year, instead renting out an x64 vps 
recently to build the cross-compiler).


As for Android/MIPS, nobody uses it, just like Android/x86 now 
that Intel has pulled out of the mobile market.  No point.


2: extern(JNI) seriously, its a pain to work with Java over JNI 
otherwise. It would be worse then not having extern(Obj-C).


I don't think it's that bad, but sure, we could always make it 
easier.


On Thursday, 6 April 2017 at 09:39:05 UTC, kinke wrote:
More than anything else, we need the community to try building 
mobile libraries and apps, because compiler support is largely 
done.


What LDC would primarily need is a CI platform supporting ARM 
(and ideally AArch64) in order to make it a true first-class 
target. We don't know of a free CI platform, so ARM isn't 
tested automatically, and it's currently mostly up to poor you 
to check for regressions. ;(


Circle seems to have some Android support, though I don't know if 
it's free, as Petar says:


https://circleci.com/docs/1.0/android/

I haven't been too inclined to look at this, as I've never messed 
with these CI services and it's not a big deal to run the tests 
myself occasionally.  We should add CI for Android at some point 
though, just one of the handful of tasks that it'd be nice if the 
community would chip in with.


On Thursday, 6 April 2017 at 11:59:42 UTC, aberba wrote:

On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:

That means this tidal wave of mobile swamping PCs is only 
going to get worse:

That remains to be seen.


Notice the decline in PC sales since mobile took off on its 
hockey stick curve?  Now that they're even offering desktop-style 
multiwindow on mobile, what makes you think it doesn't get worse? 
 I've predicted a collapse.  Even Microsoft is selling the S8, a 
flagship Android device (!), because they want to get their 
office suite on Android:


https://www.thurrott.com/mobile/android/108140/microsoft-offering-customized-samsung-galaxy-s8-preorder

Even Microsoft has announced that they're taking another shot 
at ARM, ie Windows is coming to ARM again, this time with x86 
emulation for old Win32 apps:


http://www.theverge.com/2016/12/7/13866936/microsoft-windows-10-arm-desktop-apps-support-qualcomm
ARM is *rising*, that's true. But there is no factual evidence 
in their decision (that you seem to know) backing your point.


Did you bother to read the article?  The head of Windows, Terry 
Myerson, specifically says, "Customers are asking for devices 
with better battery life, with cellular connectivity. That's why 
we've invested in this, and we're pretty excited to be announcing 
it this week.”  I'm not sure what other "factual evidence" you're 
looking for.


Microsoft, Apple, Google, ... all invest in projects they end 
up abandoning.


Are you suggesting that they will abandon Android or the iPhone 
or just their desktop-on-mobile efforts?  It is true that 
multiwindow UIs on mobile is a nascent effort, and like anything 
new may not go anywhere, but I wouldn't bet against it.  In fact, 
this entire thread argues that D should bet on it.


More than anything else, we need the community to try building 
mobile libraries and apps, because compiler support is largely 
done.  We need to integrate mobile into our plans, rather than 
it just being a sideline.

IoT, Cloud


IoT has not gone anywhere, while D already supports cloud.

The latter may seem far-fetched given D has not done that well 
in desktop GUI apps, but mobile is still a new market and D 
could do well.  D is uniquely well-suited to mobile, because 
it's nicer than Java or Obj-C while more efficient than the 
former, and it could make it easier to go cross-platform.


Vadim has done some nice work building DLangUI on Android, 
including a Tetris app that I spent half an hour playing on my 
phone:
Any unpolished GUI toolkit (even when polished) 

[Issue 17301] New: Unhelpful error message on template and non-template struct defined in separate modules

[via Digitalmars-d-bugs]

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

  Issue ID: 17301
   Summary: Unhelpful error message on template and non-template
struct defined in separate modules
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: mrsmit...@yandex.ru

module moduleA;
import moduleB;

void main() {
HashMap!(int) map;
}
struct HashMap {}


module moduleB;
struct HashMap(Key) {}

moduleA.d(6): Error: template instance HashMap!int HashMap is not a template
declaration, it is a struct



But, when defined in one module:

void main() {
HashMap!(int) map;
}

struct HashMap {}
struct HashMap(Key) {}

hashmap.d(6): Error: struct hashmap.HashMap(Key) conflicts with struct
hashmap.HashMap at hashmap.d(5)

--

Re: Function names and lambdas

[Russel Winder via Digitalmars-d-learn]

On Thu, 2017-04-06 at 18:45 +, Adam D. Ruppe via Digitalmars-d-
learn wrote:
> On Thursday, 6 April 2017 at 18:37:51 UTC, Russel Winder wrote:
> > I am used to a function name being a reference to the function 
> > body, cf. lots of other languages. However D rejects:
> > 
> > iterative
> 
> Try
> 
> 
> 
> 
> 
> The compiler would probably optimize out a trivial thing anyway, 
> but  should work too in most cases.

No don't I look like a real idiot. Of course I should have known that.
:-)

It works exactly as required.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: Testing D codes

[Kagamin via Digitalmars-d-learn]

On Thursday, 6 April 2017 at 13:49:11 UTC, Russel Winder wrote:
Is there any need for the unittest block in the application 
created to run the integration tests?


If you don't care to call each and all of them by hand. Test 
frameworks are handy for extensive testing, builtin unittests 
work best for the most basic stuff.