Re: Maybe D is right about GC after all !

[Mengu via Digitalmars-d]

On Friday, 29 December 2017 at 00:26:04 UTC, codephantom wrote:
On Thursday, 28 December 2017 at 08:53:25 UTC, Russel Winder 
wrote:

[...]


I disagree.

[...]


syntax is not weird at all. it is ML-ish.

Re: Compiler bug?

[Daniel Kozak via Digitalmars-d]

But maybe you can propose cjange from ref R r to auto ref R r

https://dlang.org/spec/template.html#auto-ref-parameters

On Fri, Dec 29, 2017 at 8:50 AM, Daniel Kozak  wrote:

> No it is not a bug, because
>  uint formattedRead(alias fmt, R, S...)(ref R r, auto ref S args)
> could not match (there is a ref R r) so in your first example you dont
> have lvalue but rvalue
>
>
> On Fri, Dec 29, 2017 at 8:30 AM, IM via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> The following code:
>>
>>   int guess;
>>   readln().formattedRead!"%d"(guess);
>>
>> produces the following compiler error:
>>
>> Error: template std.format.formattedRead cannot deduce function from
>> argument types !("%s")(string, int), candidates are:
>> /usr/include/dmd/phobos/std/format.d(635):
>> std.format.formattedRead(alias fmt, R, S...)(ref R r, auto ref S args) if
>> (isSomeString!(typeof(fmt)))
>> /usr/include/dmd/phobos/std/format.d(644):
>> std.format.formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt, auto
>> ref S args)
>>
>> That is odd! I expected this to match:
>>
>>   uint formattedRead(alias fmt, R, S...)(ref R r, auto ref S args)
>>
>> However, the following works!!!
>>
>>   int guess;
>>   string line = readln();
>>   line.formattedRead!"%d"(guess);
>>
>>
>> This definitely looks like a bug, but I want to confirm first before
>> filing one.
>>
>>
>

What do you want to see for a mature DLang?

[IM via Digitalmars-d]

I will start:

   -- Better compiler errors, better compiler errors, better 
compiler errors.



I really wish that the compiler errors could receive some 
refinement. Mostly it feels like some error text just being 
thrown at me. It needs to be better formatted, more helpful, with 
suggestions about how to fix (if possible).


To illustrate my point:

- See the compile errors I've just encountered with DMD: 
https://cdn.pbrd.co/images/H0q609l.png


- Now compare that with an error produced by rustc:
https://cdn.pbrd.co/images/H0q6bLi.png


Simple things like these make a big difference. D Lang has been 
around for a long while now, and hence signs of its maturity has 
to show everywhere, especially in the compiler, as well as the 
package manager.

Re: Compiler bug?

[Daniel Kozak via Digitalmars-d]

No it is not a bug, because
 uint formattedRead(alias fmt, R, S...)(ref R r, auto ref S args)
could not match (there is a ref R r) so in your first example you dont have
lvalue but rvalue


On Fri, Dec 29, 2017 at 8:30 AM, IM via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> The following code:
>
>   int guess;
>   readln().formattedRead!"%d"(guess);
>
> produces the following compiler error:
>
> Error: template std.format.formattedRead cannot deduce function from
> argument types !("%s")(string, int), candidates are:
> /usr/include/dmd/phobos/std/format.d(635):
> std.format.formattedRead(alias fmt, R, S...)(ref R r, auto ref S args) if
> (isSomeString!(typeof(fmt)))
> /usr/include/dmd/phobos/std/format.d(644):
> std.format.formattedRead(R, Char, S...)(ref R r, const(Char)[] fmt, auto
> ref S args)
>
> That is odd! I expected this to match:
>
>   uint formattedRead(alias fmt, R, S...)(ref R r, auto ref S args)
>
> However, the following works!!!
>
>   int guess;
>   string line = readln();
>   line.formattedRead!"%d"(guess);
>
>
> This definitely looks like a bug, but I want to confirm first before
> filing one.
>
>

Compiler bug?

[IM via Digitalmars-d]

The following code:

  int guess;
  readln().formattedRead!"%d"(guess);

produces the following compiler error:

Error: template std.format.formattedRead cannot deduce function 
from argument types !("%s")(string, int), candidates are:
/usr/include/dmd/phobos/std/format.d(635):
std.format.formattedRead(alias fmt, R, S...)(ref R r, auto ref S 
args) if (isSomeString!(typeof(fmt)))
/usr/include/dmd/phobos/std/format.d(644):
std.format.formattedRead(R, Char, S...)(ref R r, const(Char)[] 
fmt, auto ref S args)


That is odd! I expected this to match:

  uint formattedRead(alias fmt, R, S...)(ref R r, auto ref S args)

However, the following works!!!

  int guess;
  string line = readln();
  line.formattedRead!"%d"(guess);


This definitely looks like a bug, but I want to confirm first 
before filing one.

[Issue 16042] Identifier on template arguments should consider eponymous member lookup

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

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

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

   What|Removed |Added

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

--

[Issue 16042] Identifier on template arguments should consider eponymous member lookup

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

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

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

https://github.com/dlang/dmd/commit/b2a5fb82d6506291b8a0c72c1e24dc2befb75226
Fix Issue 16042 - Identifier on template arguments should consider eponymous
member lookup

https://github.com/dlang/dmd/commit/5470151e344655df97b2edd3a283e2ea79a6aa75
Merge pull request #7404 from JinShil/fix_16042

Fix Issue 16042 - Identifier on template arguments should consider eponymous
member lookup

--

[Issue 16042] Identifier on template arguments should consider eponymous member lookup

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7404

--

[Issue 18099] betterC check throw statements error!

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

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

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

https://github.com/dlang/dmd/commit/42ea3732608bc4d877fb0139a00ade9ba9379dd8
fix Issue 18099 - betterC check throw statements error!

https://github.com/dlang/dmd/commit/0a87e133da7fedc0622a26b40705b82d8127bb25
Merge pull request #7539 from WalterBright/fix18099

fix Issue 18099 - betterC check throw statements error!
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 18099] betterC check throw statements error!

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

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

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

   What|Removed |Added

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

--

Re: Maybe D is right about GC after all !

[codephantom via Digitalmars-d]

On Thursday, 28 December 2017 at 10:54:08 UTC, Russel Winder 
wrote:


If you want to believe that fine. Clearly you are missing the 
point I am making, which clearly must be my fault for bad 
expression. Also clear it is not worth progressing this debate.


You are asking Walter to 'quantify' something that simply does 
not need to be quantified. This is the problem with the 
scientific method.


Not everything needs to be, or can be, or should be, quantified.

Some things just make sense, and it is obvious, and it can be 
left at that.


Like not having to annotate functions with func, or fn.

Not having to use := when you mean =

etc..
etc

Re: Maybe D is right about GC after all !

[codephantom via Digitalmars-d]

On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder 
wrote:


However, in the end, the GStreamer core people know C, C++ a 
bit, D not at all. I suspect even if the choice had been Rust 
or D, Rust would have been chosen because it has no GC and D is 
a GC language.


That is a little misleading. It was always the intention of Rust 
designers to allow userd to tie into a garbage collector - like 
spidermonkey.


It was never designed to be a language that can't make use of GC.

D has gc by default instead. But it's flexible enough to use 
RAII, and you can customise GC a lot


So Gstreamer people could have easily worked with D, and I don't 
believe D's GC implementation would have been a show stopper for 
them.

Re: Maybe D is right about GC after all !

[codephantom via Digitalmars-d]

On Thursday, 28 December 2017 at 10:57:55 UTC, Russel Winder 
wrote:


Not sure which country this is an observation on, but again all 
countries are different so a global opinion is not possible. 
The problem in the UK is the shift from wholly government 
funded tertiary education, to partially government, partially 
personal funded tertiary education. The cynical would see this 
as a way of stopping poor people getting an education.




It's odd, that humans are still willing to restrict their 
potential through the limitations of 'money' - money being a 
creation of humans, not a restriction nature imposed on us. I 
just don't get it.


The D project is a nice example of people just working together 
to achieve something that all can benefit from.

Re: Maybe D is right about GC after all !

[codephantom via Digitalmars-d]

On Thursday, 28 December 2017 at 08:53:25 UTC, Russel Winder 
wrote:
On Thu, 2017-12-28 at 03:34 +, codephantom via 
Digitalmars-d wrote:



[…]
I tried Go. I didn't like it. Syntax changes were not I looked 
at Rust, but never tried it, as I found the syntax to pretty 
awful - and it reminded my too much of C++.


The syntax is fine, and it is so unlike C++, it is easy to get 
into. I am using Rust as my primary language for all GStreamer 
stuff now.




I disagree.

Here is some Rust code...

use std::io::stdin;
fn someFunction(vec: Vec) {}
let  mut vec = Vec::new();
let mut age: i32 = 1;
etc...
etc.

The syntax is just weird, in my opinion.. it's like some martian 
language...


Clearly, applied psychology was not front of mind when designing 
that syntax ;-)
(and I believe the syntax was pretty controverial anyway, and 
underwent constant changes...but they still managed to get it 
wrong .. in my opinion).


But gee.. I can do things in D so easily and quickly compare 
to C, and I don't feel like I giving up much for that 
convenience. Compare that to running dotnet ... g...you 
sit there just waiting for the program to load.


C# and F# also have a lot going for them, I suspect you used it 
is the wrong context and so got a bad feel. The same is true 
for Java. Kotlin, Groovy, I guess which are great in a 
JVM-centred context.


No. I didn't mean C# per se. What I mean is 'dotnet' (the attempt 
my MSFT to port C# to other platforms.) I have to sit and wait 
several seconds sometimes before the dotnet runtime loads itself 
and starts doing the job I asked it to do. Once it runs it's not 
'too' bad, but still noticably slower than a native compiled 
language. I do like C#, so I'm not against that, but making 
people wait for things to load like this is just pathetic..it 
needs to get better... or in the dumpster it goes.

[Issue 12901] `in`/`out` contracts on struct constructor must require function body

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

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

--- Comment #4 from hst...@quickfur.ath.cx ---
Arguably, the original fix was invalid: it doesn't stop you from writing:


struct S
{
int a;
this(int n) in { a = n; } body {} // or do {}
}


The problem really is allowing assignment to struct members from inside a
contract, which is abuse of the contract feature.  Perhaps the solution should
be to enforce purity on the contract, or, less intrusively, make the contract
body const (i.e., `this` is const inside the contract body).

--

Re: BitArray shift left/right confusion.

[Bastiaan Veelo via Digitalmars-d-learn]

On Wednesday, 27 December 2017 at 20:45:49 UTC, Biotronic wrote:

BitArray is apparently a mess.

Thanks for your confirmation, digging and reporting issues
https://issues.dlang.org/show_bug.cgi?id=18133 and
https://issues.dlang.org/show_bug.cgi?id=18134

(Turns out we both live in the same country).

[Issue 12901] `in`/`out` contracts on struct constructor must require function body

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||hst...@quickfur.ath.cx
 Resolution|FIXED   |---

--- Comment #3 from hst...@quickfur.ath.cx ---
Broken by https://github.com/dlang/dmd/pull/7527

--

Re: how to localize console and GUI apps in Windows

[zabruk70 via Digitalmars-d-learn]

you can just set console CP to UTF-8:

https://github.com/CyberShadow/ae/blob/master/sys/console.d

Re: D needs to publicize its speed of compilation

[Iain Buclaw via Digitalmars-d]

On 28 December 2017 at 22:58, Walter Bright via Digitalmars-d
 wrote:
> On 12/28/2017 5:22 AM, Atila Neves wrote:
>>
>> On Thursday, 28 December 2017 at 07:21:28 UTC, Walter Bright wrote:
>>>
>>> On 12/27/2017 1:23 PM, Atila Neves wrote:

 However, my experience has been that D has fast builds from scratch, but
 is really really slow for incremental builds.
>>>
>>> You can do fast incremental builds with D by not putting all the files on
>>> the command line. Just put one.
>>
>>
>> I don't build the compiler command-line myself, nor do I want to. Even
>> then, recompiling one file isn't useful to me, what is is to recompile
>> what's needed and run the tests. Emacs/flycheck already highlights
>> compilation errors in just one file.
>
>
> I don't understand. C++ compiles files one at a time. You can do the same in
> D. How can this model be useful in C++ but not with D?
>

D modules are like C++ headers.  Change one, and you need to recompile
everything that imports it.

Re: D downloads

[Walter Bright via Digitalmars-d]

On 12/24/2017 7:33 AM, Laeeth Isharc wrote:
(The first person to receive 
Bitcoin was Hal Finney, a prominent member of both the extropians and 
cypherpunks lists).
Hal was in the dorm room next to mine when I was a freshman. He was one of the 
smartest people I've ever known, by a wide margin. Also one of the nicest.


I've always suspected Hal of being Satoshi :-) A grand joke like that is 
something he'd do.

[Issue 6549] Implement contracts without implementation.

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

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

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

   What|Removed |Added

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

--

[Issue 6549] Implement contracts without implementation.

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

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

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

https://github.com/dlang/dmd/commit/c7d0672b7faa21ead0edd8924c2a719aca94fc21
fix issue 6549 - Implement contracts without implementation

https://github.com/dlang/dmd/commit/d511b9579559d7f3109a7a6aef05b80786612f49
Merge pull request #7527 from ibuclaw/issue6549

fix issue 6549 - Implement contracts without implementation

--

[Issue 12344] .di generation doesn't include contracts in interfaces

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

https://issues.dlang.org/show_bug.cgi?id=12344
Issue 12344 depends on issue 6549, which changed state.

Issue 6549 Summary: Implement contracts without implementation.
https://issues.dlang.org/show_bug.cgi?id=6549

   What|Removed |Added

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

--

Re: D needs to publicize its speed of compilation

[Walter Bright via Digitalmars-d]

On 12/28/2017 5:22 AM, Atila Neves wrote:

On Thursday, 28 December 2017 at 07:21:28 UTC, Walter Bright wrote:

On 12/27/2017 1:23 PM, Atila Neves wrote:
However, my experience has been that D has fast builds from scratch, but is 
really really slow for incremental builds.
You can do fast incremental builds with D by not putting all the files on the 
command line. Just put one.


I don't build the compiler command-line myself, nor do I want to. Even then, 
recompiling one file isn't useful to me, what is is to recompile what's needed 
and run the tests. Emacs/flycheck already highlights compilation errors in just 
one file.


I don't understand. C++ compiles files one at a time. You can do the same in D. 
How can this model be useful in C++ but not with D?

Re: Maybe D is right about GC after all !

[Walter Bright via Digitalmars-d]

On 12/28/2017 2:54 AM, Russel Winder wrote:

Clearly you are missing the point I
am making, which clearly must be my fault for bad expression.


Whether it's your fault or mine, I apparently have no idea what you mean by the 
phrase "psychology based design".




Also clear it is not worth progressing this debate.


Not necessarily true. I have always been interested in human factors design, 
going back to my experience designing airplane parts and talking with the 
cockpit design engineers.


A fun example is the warning horns in the cockpit. One was added, I think for 
stall warning. It turned out to be remarkably effective. So they added horns for 
other emergencies, each with a distinct sound so the pilot could distinguish them.


But it turned out, in a high stress situation, the pilot would get confused 
associating the sound with what just went wrong, and would take the wrong 
corrective action. Boeing then had the brilliant (and obvious in hindsight, as 
these things so often are) of replacing the horn sounds with words. So the stall 
warning horn becomes "stall, stall" (I forgot the exact words for it). Problem 
solved!


With programming language design, I'm pretty interested in why programmers make 
the mistakes they do, and if the propensity for making those mistakes can be 
blunted by altering the design of the language. There's a lot of that in D. (I 
enjoy reading articles about what static checkers do, and articles that collect 
statistics on types of bugs.)

Re: Maybe D is right about GC after all !

[Russel Winder via Digitalmars-d]

On Thu, 2017-12-28 at 16:43 +, John Gabriele via Digitalmars-d
wrote:
> On Thursday, 28 December 2017 at 15:57:18 UTC, Paulo Pinto wrote:
> > On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder 
> > wrote:
> > > 
[…]
> > Not only GStreamer, Rust is on its way to become an offical 
> > GNOME language, and who knows, eventually take over Vala's role.

I think Vala is rapidly becoming a failed experiment. A great idea to
embody the GNOME object model via a programming language with a code
generator to C, but traction outside a core group has failed.

> I haven't followed Gnome+Rust news. What suggests Rust may be on 
> its way to become an official Gnome language?

There is an increasing dissatisfaction with C for GNOME object model
working due to lack of RAII and buffer overruns, at least in the small
area of GNOME stuff I know.

> I'd think that people looking to write apps for Gnome would be 
> more inclined to use a *higher*-level language, like D (see GtkD) 
> or Python (see PyGObject) rather than a lower-level one like Rust 
> where there's a need to deal with borrowing and lifetimes.

Python works fine but people are increasingly against a non-native
language, that distributed as source with perceived lack of compile
type checking. Only one of the complaints has any real validity, and
that is very real.

> Another possible contender I'd forgotten about: 
> [Kotlin/Native](https://github.com/JetBrains/kotlin-native). I 
> see they have some sample code for using GTK: 
> .

Last time I looked at the Kotlin/Native GTK+ binding it was literally
calls to the C API, which is worse than using C because with Kotlin you
expect a higher level binding – which C++, D, and Rust all provide.

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


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

Re: Don't expect class destructors to be called at all by the GC

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, December 28, 2017 10:37:09 H. S. Teoh via Digitalmars-d-learn 
wrote:
> On Sun, Dec 24, 2017 at 02:07:26PM -0700, Jonathan M Davis via
> Digitalmars-d-learn wrote: [...]
>
> > Regardless, even if it were the case that it were guaranteed that all
> > finalizers were run when the program exited, it would still be
> > terrible practice to rely on it. It's trivial to end up in a situation
> > where no collection is run for quite some time (e.g. just don't do
> > much memory allocation for a while), which would leave any resources
> > that needed to be freed by a finalizer unfreed for quite a while even
> > though they weren't needed anymore. So practically speaking, it
> > doesn't really matter where the finalizers are guaranteed to run.
> > Relying on them to be run rather than forcing them to be run via
> > destroy or using some other helper function is just going to cause
> > problems, so it's just plain bad practice to rely on finalizers to be
> > run to release resources. That's just life with GC's in general, not
> > just D's. It's why C# has the while dispose/IDisposable thing, and why
> > D code should either be using destroy to deal with freeing resources
> > for a class or using structs on the stack for resources that need to
> > be freed. Or alternate memory strategies can be used via
> > std.experimental.allocator. The GC works great for lots of stuff but
> > not for system resources. Honestly, in some ways, we'd be better off
> > if D didn't even have finalizers.
>
> [...]
>
> This makes me wonder if a better approach to memory management is to use
> refcounting by default, and fallback to the GC to collect cycles.
>
> In my current project, I'll probably end up having to use
> RefCounted!Database just so I can have deterministic releasing of
> database handles without needing to worry about dangling references that
> may still be lingering around. (Currently, I'm just calling .destroy
> directly on the handle when I'm done with it, but there's a slim
> possibility that there might be dangling references left somewhere. So
> that needs to be addressed at some point.)

The GC works perfectly well for most things. You just have to be aware of
its downsides - and that includes being aware of what's going to happen if
you try and use it to manage system resources. For that, ref-counting is
almost certainly going to be better (though there are probably cases where
it doesn't matter, because it's not really a problem if the resources aren't
freed before the program exits).

In any case, for a lot of the cases where dispose/IDisposable would be used
in C#, ref-counting is almost certainly what the code should be doing
(either that or scope statements if what's being done is localized and not
common enough to create a type to use with RAII). That's probably on the
list of things that needs to be written up somewhere as being among best
practices for D. There are probably too many things like that that are
sitting in the heads of a lot of folks but not necessarily well communicated
to others - though this particular issue may have been discussed in the
recent GC articles. I don't know. I still need to read them.

- Jonathan M Davis

Re: Maybe D is right about GC after all !

[Dan Partelly via Digitalmars-d]

On Thursday, 28 December 2017 at 20:03:06 UTC, Joakim wrote:
The canonical example is how Apple doesn't compete on 
feature/spec checklists but on an integrated experience that 
just works better.  That may be tougher to market for tech 
users, but it is increasingly what people want, even many 
programmers.


Spot on.

Even markets which are occupied by tech users, like BSD/Linux 
servers goes into this direction. Systemd is a prime example. It 
allows modern functionality and integration which in today's 
world is a must. And it still not provies enough. Devices are 
hotplugged all the time, they go in different power states, they 
respond asynch to system wide, net wide, and soon, world wide 
events ... the user mode paradigm of Unix is woefully inadequate 
and unprepared for this world. It needs serious adjustments. 
(arguably  even kernels on free unix like OSes are unprepared, no 
modern LPC comparable to what can be found in NT derived kernels 
for example)


Yet the users do not seen it this way. A big part of Linux users 
went so far as to make life threats towards systemd engineers. 
They hate any attempt to modernization and integration. They do 
prefer the autoexec.bat like init systems spawning fragile 
scaffoldings of scripts. Too much choice begets fragmentation, 
both from a technical point of view and a social one. 
Fragmentation begets tribes, and tribes kill each other.


Likewise, in a company , it is in my opinion better to keep the 
languages used across the board as limited as possible, instead 
of an everlasting search for best tool for each of the problem 
you face. Just see if you can solve it with the tools you already 
have, don't try to build a scaffolding of techs you barely 
unde5rstand and control because the are the "best"

Re: Maybe D is right about GC after all !

[Joakim via Digitalmars-d]

On Wednesday, 27 December 2017 at 18:13:41 UTC, Russel Winder 
wrote:
The challenger has to offer something that the community value. 
Rust offers memory safety over C. D offers "better C++". This 
is the wrong message to achieve traction. D must offer 
something that C++ does not offer.


If you're a better version of one of the market leaders, that's 
good enough.  If you were just a better Erlang, that'd be a 
marketing problem!


But as of 2017-03-30 I have no hidden agenda, i.e. I retired. 
:-) This mjeans I am just doing what I want, which currently is 
organising ACCU conference, organising DevoxxUK conferences and 
programming DVB-T and DAB clients. D has failed to get traction 
at ACCU, has no chance at all at DevoxxUK, and has lost to Rust 
in DVB-T and DAB applications.


So D is invisible in the places you frequent, but has anybody 
written an entire storage system in Rust?


https://www.theregister.co.uk/2017/12/22/a_dive_into_wekaios_parallel_file_system_tech/

My point is that D and Rust are both currently lower-traction 
languages, so it's expected that you don't find them in many 
places.  Rust is certainly doing better right now, because it is 
focused on the niche of memory safety, but that means Gerald 
almost certainly isn't going to use it for his Gtk-based tiling 
terminal emulator:


https://dlang.org/blog/2017/08/11/on-tilix-and-d-an-interview-with-gerald-nunn/

D and Rust are going after different markets, but D is trying to 
stay more general-purpose, which Rust has abandoned so far 
(though their upcoming GC may be a step towards more general use).


On Wednesday, 27 December 2017 at 18:41:41 UTC, Laeeth Isharc 
wrote:
That's really the whole point about D.  It's an era where 
people start out assuming that using the right tool for the job 
means that one tool can't do two different kinds of job well.  
But, as Walter has said elsewhere I think, in some cases that's 
because the tools people are used to using are limited, whereas 
in fact there's no need for that - just use one tool that's 
good at both.
 It's going to be a struggle to recognise such a tool if you 
start with the presumption it cannot exist.


This reminded me of a current theme in tech, the tension between 
modularity and integration.  Here's an example quote from a 
couple months ago:


"But the long arc of history shows how hard it is to succeed in 
vertical integration after you build on horizontal foundations. 
Generations of managers graduated from the modular school of 
thought, specializing rather than generalizing. Now they are 
facing an integrated experiential world where progress depends on 
wrapping the mind around very broad systems problems."

http://www.asymco.com/2017/10/04/orthogonal-pivots/

The canonical example is how Apple doesn't compete on 
feature/spec checklists but on an integrated experience that just 
works better.  That may be tougher to market for tech users, but 
it is increasingly what people want, even many programmers.

Re: how to localize console and GUI apps in Windows

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

On Thu, Dec 28, 2017 at 05:56:32PM +, Andrei via Digitalmars-d-learn wrote:
> There is one everlasting problem writing Cyrillic programs in Windows:
> Microsoft consequently invented two much different code pages for
> Russia and other Cyrillic-alphabet countries: first was MSDOS-866 (and
> alike), second Windows-1251. Nowadays MS Windows uses first code page
> for console programs, second for GUI applications, and there always
> are many workarounds to get proper translation between them. Mostly a
> programmer should write program sources either in one code page for
> console and other for GUI, or use .NET, which basically uses UTF8 in
> sources and makes seamless translation depending on back end.
> 
> In D language which uses only UTF8 for string encoding I cannot write
> neither MS866 code page program texts, nor Windows-1251 - both cases
> end in a compiler error like "Invalid trailing code unit" or "Outside
> Unicode code space". And writing Cyrillic strings in UTF8 format is
> fatal for both console and GUI Windows targets.
> 
> My question is: is there any standard means to translate Cyrillic or
> any other localized UTF8 strings for console and GUI output in D
> libraries. If so - where I can get more information and good example.
> Google would not help.
[...]

The string / wstring / dstring types in D are intended to be Unicode
strings.  If you need to use other encodings, you really should be using
ubyte[] or const(ubyte)[] or immutable(ubyte)[], instead of string.

One approach is to use UTF-8 in your code, and only translate to one of
the code pages when you need to produce output.  I wrote a small module
for translating to/from KOI8-R when dealing with Russian text; you might
find it helpful:

---
/**
 * Module to convert between UTF and KOI8-R
 */
module koi8r;

import std.string;
import std.range;

static immutable ubyte[0x450 - 0x410] utf2koi8r = [
225, 226, 247, 231, 228, 229, 246, 250, // АБВГДЕЖЗ
233, 234, 235, 236, 237, 238, 239, 240, // ИЙКЛМНОП
242, 243, 244, 245, 230, 232, 227, 254, // РСТУФХЦЧ
251, 253, 255, 249, 248, 252, 224, 241, // ШЩЪЫЬЭЮЯ
193, 194, 215, 199, 196, 197, 214, 218, // абвгдежз
201, 202, 203, 204, 205, 206, 207, 208, // ийклмноп
210, 211, 212, 213, 198, 200, 195, 222, // рстуфхцч
219, 221, 223, 217, 216, 220, 192, 209  // шщъыьэюя
];

/**
 * Translates a range of UTF characters into KOI8-R characters.
 * Returns: Range of KOI8-R characters (as ubyte).
 */
auto toKOI8r(R)(R range)
if (isInputRange!R && is(ElementType!R : dchar))
{
static struct Result
{
R _range;

@property bool empty() { return _range.empty; }

@property ubyte front()
{
dchar ch = _range.front;

// ASCII
if (ch < 128)
return cast(ubyte)ch;

// Primary alphabetic range
if (ch >= 0x410 && ch < 0x450)
return utf2koi8r[ch - 0x410];

// Special case: Ё and ё are outside the usual range.
if (ch == 0x401) return 179;
if (ch == 0x451) return 163;

throw new Exception(
"Encoding error: unable to convert '%c' to KOI8-R".format(ch));
}

void popFront() { _range.popFront(); }

static if (isForwardRange!R)
{
@property Result save()
{
Result copy;
copy._range = _range.save;
return copy;
}
}
}
return Result(range);
}

unittest
{
import std.string;
import std.algorithm : equal;

assert("юабцдефгхийклмнопярстужвьызшэщчъ".toKOI8r.equal(iota(192, 224)));
assert("ЮАБЦДЕФГХИЙКЛМНОПЯРСТУЖВЬЫЗШЭЩЧЪ".toKOI8r.equal(iota(224, 256)));
}

unittest
{
auto r = "abc абв".toKOI8r;
static assert(isForwardRange!(typeof(r)));
import std.algorithm.comparison : equal;
assert(r.equal(['a', 'b', 'c', ' ', 193, 194, 215]));
}

static dchar[0x100 - 0xC0] koi8r2utf = [
'ю', 'а', 'б', 'ц', 'д', 'е', 'ф', 'г', // 192-199
'х', 'и', 'й', 'к', 'л', 'м', 'н', 'о', // 200-207
'п', 'я', 'р', 'с', 'т', 'у', 'ж', 'в', // 208-215
'ь', 'ы', 'з', 'ш', 'э', 'щ', 'ч', 'ъ', // 216-223
'Ю', 'А', 'Б', 'Ц', 'Д', 'Е', 'Ф', 'Г', // 224-231
'Х', 'И', 'Й', 'К', 'Л', 'М', 'Н', 'О', // 232-239
'П', 'Я', 'Р', 'С', 'Т', 'У', 'Ж', 'В', // 240-247
'Ь', 'Ы', 'З', 'Ш', 'Э', 'Щ', 'Ч', 'Ъ'  // 248-255
];

/**
 * Translates a range of KOI8-R characters to UTF.
 * Returns: Range of UTF characters (as dchar).
 */
auto fromKOI8r(R)(R range)
if (isInputRange!R && is(ElementType!R : ubyte))
{
static struct Result
{
R _range;
@property bool empty() { return _range.empty; }
@property dchar front()
{
ubyte b = _range.front;
if (b < 128) return b;
if (b >= 192)
return koi8r2utf[b - 

[Issue 17985] Implement -stdin for rdmd

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

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

--- Comment #6 from greenify  ---
Fair enough. BTW rdmd doesn't add imports by defaults - only `rdmd --eval
` does.

--

Re: Don't expect class destructors to be called at all by the GC

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

On Sun, Dec 24, 2017 at 02:07:26PM -0700, Jonathan M Davis via 
Digitalmars-d-learn wrote:
[...]
> Regardless, even if it were the case that it were guaranteed that all
> finalizers were run when the program exited, it would still be
> terrible practice to rely on it. It's trivial to end up in a situation
> where no collection is run for quite some time (e.g. just don't do
> much memory allocation for a while), which would leave any resources
> that needed to be freed by a finalizer unfreed for quite a while even
> though they weren't needed anymore. So practically speaking, it
> doesn't really matter where the finalizers are guaranteed to run.
> Relying on them to be run rather than forcing them to be run via
> destroy or using some other helper function is just going to cause
> problems, so it's just plain bad practice to rely on finalizers to be
> run to release resources. That's just life with GC's in general, not
> just D's. It's why C# has the while dispose/IDisposable thing, and why
> D code should either be using destroy to deal with freeing resources
> for a class or using structs on the stack for resources that need to
> be freed. Or alternate memory strategies can be used via
> std.experimental.allocator. The GC works great for lots of stuff but
> not for system resources. Honestly, in some ways, we'd be better off
> if D didn't even have finalizers.
[...]

This makes me wonder if a better approach to memory management is to use
refcounting by default, and fallback to the GC to collect cycles.

In my current project, I'll probably end up having to use
RefCounted!Database just so I can have deterministic releasing of
database handles without needing to worry about dangling references that
may still be lingering around. (Currently, I'm just calling .destroy
directly on the handle when I'm done with it, but there's a slim
possibility that there might be dangling references left somewhere. So
that needs to be addressed at some point.)


T

-- 
"I suspect the best way to deal with procrastination is to put off the 
procrastination itself until later. I've been meaning to try this, but haven't 
gotten around to it yet. " -- swr

[Issue 17985] Implement -stdin for rdmd

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

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

--- Comment #5 from hst...@quickfur.ath.cx ---
One advantage `echo ... | rdmd -` has over `echo ... | dmd --run -` is that
rdmd inserts a bunch of standard imports into the code, so that you don't have
to keep typing `import std.stdio; ...` in every echo command.

So yes, this is still a valid ER.

--

Re: D build and SCons [was Answers needed from those using D for Web Development, Web APIs and Services]

[H. S. Teoh via Digitalmars-d]

On Sun, Dec 24, 2017 at 12:09:56PM +, Russel Winder wrote:
> On Fri, 2017-12-22 at 10:39 -0800, H. S. Teoh via Digitalmars-d wrote:
[...]
> > In the long term, I think an approach similar to tup will have to be
> > adopted. O(n) dependency scanning just doesn't cut it anymore for
> > code the size of today's large software projects. And with dynamic
> > dependencies (e.g. CTFE-dependent imports) that are bound to happen
> > in D code with heavy metaprogramming, there's really no sane way to
> > manage dependencies explicitly; you really need to just instrument
> > the compiler and record all input files it reads the way tup does.
> > I shouldn't be needing to write custom scanners just to accomodate
> > CTFE-generated imports that may change again after a few more
> > commits. It's SSOT (single source of truth) all over again: the
> > compiler is the ultimate authority that determines which file
> > depends on what, and having to repeat this information in your build
> > script (or independently derive it via scanners) introduces
> > fragility / incompleteness into your build system.
> 
> Again unless we do something nothing will change.
> 
> I am not sure you can get away from some element of O(n) behaviour if
> a build system is to detect what is to be rebuilt in a compile then
> link system. Obviously there are ways of minimising cf. Tup and Ninja
> vs.  Make and to some extent SCons. Tup still has a form of scan it is
> just very fast due to the use of the file system tools it uses.
> 
> So if SCons is to be abandoned for D builds let's agree that and got
> on with the tool that SCons and Dub are not.

OK, I may have worded things poorly here.  What I meant was that with
"traditional" build systems like make or SCons, whenever you needed to
rebuild the source tree, the tool has to scan the *entire* source tree
in order to discover what needs to be rebuilt. I.e., it's O(N) where N
is the size of the source tree.  Whereas with tup, it uses the Linux
kernel's inotify mechanism to learn about which file(s) being monitored
have been changed since the last invocation, so that it can scan the
changed files in O(n) time where n is the number of changed files, and
in the usual case, n is much smaller than N. It's still linear in terms
of the size of the change, but sublinear in terms of the size of the
entire source tree.

I think it should be obvious that an approach whose complexity is
proportional to the size of the changeset is preferable to an approach
whose complexity is proportional to the size of the entire source tree,
esp.  given the large sizes of today's typical software projects.  If I
modify 1 file in a project of 10,000 source files, rebuilding should not
be orders of magnitude slower than if I modify 1 file in a project of
100 files.

In this sense, while SCons is far superior to make in terms of usability
and reliability, its core algorithm is still inferior to tools like tup.
Now, I've not actually used tup myself other than a cursory glance at
how it works, so there may be other areas in which it's inferior to
SCons.  But the important thing is that it gets us away from the O(N) of
traditional build systems that requires scanning the entire source tree,
to the O(n) that's proportional to the size of the changeset. The former
approach is clearly not scalable. We ought to be able to update the
dependency graph in proportion to how many nodes have changed; it should
not require rebuilding the entire graph every time you invoke the build.


> […]
> > One thing I found annoying with dub was the sheer amount of time it
> > spent at startup to scan all dependencies and packages and possibly
> > downloading a whole bunch of stuff. The network latency really kills
> > the compile-test-debug cycle time.  I know there's a switch to
> > suppress this behaviour, but the initial dependency scanning is
> > still pretty slow even in spite of that.  When a 1-line change
> > requires waiting 15-20 seconds just to recompile, that really breaks
> > my workflow.
> 
> I have been dithering with replacing the use of Dub itself, with a
> SCons tool to replace Dub and work directly with the repository. Dub's
> build structure really isn't useful for anything other than using Dub
> as a built system.
> 
> Having two modes: update each time vs. only update when the developer
> requires it is important. Unless a version glob is used, checking
> dependencies should never take long.

Preferably, checking dependencies ought not to be done at all unless the
developer calls for it. Network access is slow, and I find it
intolerable when it's not even necessary in the first place.  Why should
it need to access the network just because I changed 1 line of code and
need to rebuild?


> > Plus, sometimes I *don't* want anything updated -- when debugging a
> > program, the last thing I want is for dub or the build script or
> > whatever to decide to link in a slightly different version of a
> > library, and suddenly I'm no 

how to localize console and GUI apps in Windows

[Andrei via Digitalmars-d-learn]

There is one everlasting problem writing Cyrillic programs in 
Windows: Microsoft consequently invented two much different code 
pages for Russia and other Cyrillic-alphabet countries: first was 
MSDOS-866 (and alike), second Windows-1251. Nowadays MS Windows 
uses first code page for console programs, second for GUI 
applications, and there always are many workarounds to get proper 
translation between them. Mostly a programmer should write 
program sources either in one code page for console and other for 
GUI, or use .NET, which basically uses UTF8 in sources and makes 
seamless translation depending on back end.


In D language which uses only UTF8 for string encoding I cannot 
write neither MS866 code page program texts, nor Windows-1251 - 
both cases end in a compiler error like "Invalid trailing code 
unit" or "Outside Unicode code space". And writing Cyrillic 
strings in UTF8 format is fatal for both console and GUI Windows 
targets.


My question is: is there any standard means to translate Cyrillic 
or any other localized UTF8 strings for console and GUI output in 
D libraries. If so - where I can get more information and good 
example. Google would not help.


Thanks.

Re: How do I set a class member value by its name in a string?

[Marc via Digitalmars-d-learn]

Always helpful. Thank you very much guys.

Re: Maybe D is right about GC after all !

[John Gabriele via Digitalmars-d]

On Thursday, 28 December 2017 at 15:57:18 UTC, Paulo Pinto wrote:
On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder 
wrote:
On Wed, 2017-12-27 at 18:41 +, Laeeth Isharc via 
Digitalmars-d wrote:



[…]
However the GStreamer folk are backing Rust (for memory safety 
issues noted earlier) so even though D has a GStreamer binding 
(thanks to Mike and GtkD) I more or less have to use Rust 
because it is the official binding. Comparing and contrasting 
D and Rust is interesting for me. Both have many pluses and 
many minuses. However, in the end, the GStreamer core people 
know C, C++ a bit, D not at all. I suspect even if the choice 
had been Rust or D, Rust would have been chosen because it has 
no GC and D is a GC language.


Not only GStreamer, Rust is on its way to become an offical 
GNOME language, and who knows, eventually take over Vala's role.


I haven't followed Gnome+Rust news. What suggests Rust may be on 
its way to become an official Gnome language?


I'd think that people looking to write apps for Gnome would be 
more inclined to use a *higher*-level language, like D (see GtkD) 
or Python (see PyGObject) rather than a lower-level one like Rust 
where there's a need to deal with borrowing and lifetimes.


Another possible contender I'd forgotten about: 
[Kotlin/Native](https://github.com/JetBrains/kotlin-native). I 
see they have some sample code for using GTK: 
.

Re: Article: Finding memory bugs in D code with AddressSanitizer

[Johan Engelen via Digitalmars-d-announce]

On Monday, 25 December 2017 at 17:03:37 UTC, Johan Engelen wrote:
I've been writing this article since August, and finally found 
some time to finish it:


http://johanengelen.github.io/ldc/2017/12/25/LDC-and-AddressSanitizer.html


Is it a good fit with /r/programming ?

-Johan

Re: Please do not use 'auto' return types without thoroughly describing the interface

[Mark via Digitalmars-d]

On Wednesday, 27 December 2017 at 16:36:59 UTC, H. S. Teoh wrote:
On Tue, Dec 26, 2017 at 11:28:56AM +, Mark via 
Digitalmars-d wrote:

On Monday, 25 December 2017 at 22:48:39 UTC, H. S. Teoh wrote:
> [...]

Maybe we can document the interface of the return type using 
signature constraints? For instance, for the function:


auto map(Range)(Range r) if (isInputRange!(Unqual!Range));

we'd add the following to its constraints:

isInputRange!(ReturnType!(map!R))

However, this does not compile at the moment. I'm not sure why.


I'm not sure why either, but signature constraints are intended 
to be used for constraining the range of incoming template 
arguments that the template will accept. It's not intended to 
establish a contract on what the template is going to produce 
when instantiated with those arguments, though this could well 
be an enhancement request. Perhaps this should be filed in 
bugzilla so that it won't get forgotten.


T


I guess we could introduce "static in" and "static out" contracts 
analogous to the existing "in" and "out" contracts, except these 
would be run at compile-time. But this doesn't seem strictly 
necessary - the compiler can figure out on its own which 
constraints depend only on the function's (compile-time) 
parameters and which constraints also depend on its return type.

Re: D Ebooks On Sale For $5 Each

[Martin Tschierschke via Digitalmars-d-announce]

On Wednesday, 20 December 2017 at 13:52:06 UTC, Mike Parker wrote:

On Wednesday, 20 December 2017 at 13:40:29 UTC, Kyle wrote:

Your book and Adam's are both excellent and this looks like a 
prime opportunity to try out Kai's.


Thanks! Absolutely, pick up Kai's book. I wish it had been 
around when I wrote Chapter 10 in mine.


Yes, a big "THANK YOU!" to all authors.

The good thing with the digital books from Packt is, that you can 
use a .pdf on your desktop computer  and an .epub or .kindle on 
your ebook reader in parallel and additional or you can read the 
purchased books on-line. I was not aware of this feature before I 
got my first one.

Re: D needs to publicize its speed of compilation

[H. S. Teoh via Digitalmars-d]

On Thu, Dec 28, 2017 at 01:22:13PM +, Atila Neves via Digitalmars-d wrote:
> On Thursday, 28 December 2017 at 07:21:28 UTC, Walter Bright wrote:
> > On 12/27/2017 1:23 PM, Atila Neves wrote:
> > > However, my experience has been that D has fast builds from
> > > scratch, but is really really slow for incremental builds.
> > You can do fast incremental builds with D by not putting all the
> > files on the command line. Just put one.
> 
> I don't build the compiler command-line myself, nor do I want to. Even
> then, recompiling one file isn't useful to me, what is is to recompile
> what's needed and run the tests.
[...]

Isn't that what a build system is for?


T

-- 
GEEK = Gatherer of Extremely Enlightening Knowledge

Re: Maybe D is right about GC after all !

[Paulo Pinto via Digitalmars-d]

On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder 
wrote:
On Wed, 2017-12-27 at 18:41 +, Laeeth Isharc via 
Digitalmars-d wrote:



[…]
However the GStreamer folk are backing Rust (for memory safety 
issues noted earlier) so even though D has a GStreamer binding 
(thanks to Mike and GtkD) I more or less have to use Rust 
because it is the official binding. Comparing and contrasting D 
and Rust is interesting for me. Both have many pluses and many 
minuses. However, in the end, the GStreamer core people know C, 
C++ a bit, D not at all. I suspect even if the choice had been 
Rust or D, Rust would have been chosen because it has no GC and 
D is a GC language.


Not only GStreamer, Rust is on its way to become an offical GNOME 
language, and who knows, eventually take over Vala's role.

[Issue 18138] non-shared method overload not accessible through interface

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

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

Re: D Videos

[Dave Jones via Digitalmars-d]

On Thursday, 28 December 2017 at 14:17:08 UTC, Mike Franklin 
wrote:

On Thursday, 28 December 2017 at 14:11:57 UTC, Dave Jones wrote:
Just an idea, i think it'd be a good idea to have a page on 
dlang with links to all the various D related talks / videos. 
Quite often i watch them as i find them in the newsgroup, but 
it'd be good to have them all in one place.


https://wiki.dlang.org/Videos

Mike


Thanks, didnt consider that it might be in the wiki.

Re: Getting error in dmd testsuite

[Thomas Mader via Digitalmars-d-learn]

On Sunday, 27 August 2017 at 14:04:18 UTC, Joakim wrote:
That module tests linking with C++ files, looks like you have 
some symbols that don't match up.  That's weird, because those 
normally work with gcc.  For each of them, use the readelf 
command from binutils to compare the symbols generated and see 
how they differ.  For example,


readelf -sW 
/tmp/nix-build-ldc-1.3.0.drv-0/build/dmd-testsuite/runnable/cppb.cpp.o |grep foo15372


Then run the same command on the D side, ie for cppa_0.o, and 
compare the symbols.


File a bug on the ldc github if you can't figure it out:

https://github.com/ldc-developers/ldc/issues


gcc does not create the symbol at all on NixOS. I already created 
an issue for NixOS: https://github.com/NixOS/nixpkgs/issues/28896


I am not supposed to ask here but maybe someone knows about 
problems with gcc?

Re: druntime memory unittest fails

[Thomas Mader via Digitalmars-d-learn]

On Thursday, 28 December 2017 at 10:25:01 UTC, Seb wrote:
On Thursday, 28 December 2017 at 10:23:38 UTC, Thomas Mader 
wrote:

Hello,

on NixOS the druntime memory unittest fails at 'assert(z is 
null);' 
(https://github.com/dlang/druntime/blob/v2.075.1/src/core/memory.d#L899)


Does anyone have a clue how that can happen?

Thomas


Use master: https://github.com/dlang/druntime/pull/1991


Perfect, thanks.
I already tested building with 2.078.0-beta1 but don't remember 
if I reactivated the test or not.

Nevertheless I will just wait for the final release.

Re: D as a betterC a game changer ?

[Dan Partelly via Digitalmars-d]

On Thursday, 28 December 2017 at 11:56:24 UTC, Russel Winder 
wrote:
And is the way every programmer learns their non-first 
language. All newly learned programming languages are merged 
into a person's "head language" which is based on their first 
language but then evolves as new languages, especially of new 
computational mode, are learned.


One of the reasons I asked Walter to provide an insight into what 
he wants D to become, why betterC, GC or lack-thereof dilemma , 
and future evolution is to minimize a bit the biases I have.


What I learned the most in the last days is what other people 
than the creator of D think of D (valuable too), and that is hard 
to get a straight answer from the people developing D language on 
my predicament with seeing it with multiple personalities.


Also, no matter hope great D is, I practically live in a D-less 
void. No one cares about it around me and no one I know cares to 
learn it. This is another social aspect. As I learn it
and learn how the creator sees the language I could try to change 
this in my immediate surrounding if it worth. It would be up to 
me once I am convinced to seduce people I work with to consider 
it and learning it.

Re: How do I set a class member value by its name in a string?

[Mengu via Digitalmars-d-learn]

On Wednesday, 27 December 2017 at 23:47:14 UTC, Biotronic wrote:

[...]


much, much better. thanks biotronic.

[Issue 18138] non-shared method overload not accessible through interface

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

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

--- Comment #2 from Remi Thebault  ---
yes, but the ITest interface has a non-shared method, which is overloaded in
IAtomicTest (IAtomicTest extends ITest), so the non-shared method should be
visible too.

--

Re: D Videos

[Seb via Digitalmars-d]

On Thursday, 28 December 2017 at 14:11:57 UTC, Dave Jones wrote:
Just an idea, i think it'd be a good idea to have a page on 
dlang with links to all the various D related talks / videos. 
Quite often i watch them as i find them in the newsgroup, but 
it'd be good to have them all in one place.


https://wiki.dlang.org/Videos

Please feel free to add anything missing.

Re: D Videos

[Mike Franklin via Digitalmars-d]

On Thursday, 28 December 2017 at 14:11:57 UTC, Dave Jones wrote:
Just an idea, i think it'd be a good idea to have a page on 
dlang with links to all the various D related talks / videos. 
Quite often i watch them as i find them in the newsgroup, but 
it'd be good to have them all in one place.


https://wiki.dlang.org/Videos

Mike

D Videos

[Dave Jones via Digitalmars-d]

Just an idea, i think it'd be a good idea to have a page on dlang 
with links to all the various D related talks / videos. Quite 
often i watch them as i find them in the newsgroup, but it'd be 
good to have them all in one place.

Re: An unfortunate quirk of DMD32 converting floating-point to string

[Ivan Kazmenko via Digitalmars-d]

On Tuesday, 26 December 2017 at 23:58:43 UTC, Walter Bright wrote:

On 12/26/2017 3:41 PM, Ivan Kazmenko wrote:
While exploring quirks of floating-point values, as well as 
C/C++/D convenience with them, I stumbled on, in essence, the 
following (DMD32 on Windows):


The issue is really with the DMC++ C runtime library, as that 
is what Phobos relies on for floating point formatting.


In the issue tracker: 
https://issues.dlang.org/show_bug.cgi?id=18139

[Issue 18139] dmd32: bad conversion of floating-point to string

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

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

--- Comment #1 from Ivan Kazmenko  ---
Walter Bright had the following to say about the issue:

> The issue is really with the DMC++ C runtime library, as that is what Phobos 
> relies on for floating point formatting.

Still, the issue seems to belong to druntime by the tracker classification.
(Or Phobos if the fix would decouple it from snprintf.)

--

[Issue 18139] New: dmd32: bad conversion of floating-point to string

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

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

  Issue ID: 18139
   Summary: dmd32: bad conversion of floating-point to string
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: ga...@mail.ru

While exploring quirks of floating-point values, as well as C/C++/D convenience
with them, I stumbled on, in essence, the following (DMD32 on Windows):

void main ()
{
import std.stdio : writefln;
double x = 128.0;// same for real or float
writefln ("%.20a", x);   // 0x1.p+7, right
writefln ("%.20f", x);   // 127.9000, wrong
}

1. The internal representation is fine: the exponent (before shift) is 7, and
the mantissa is all-zeroes (except the "1." part which is not stored).

2. Formatting to a decimal representation goes off in a bad way, giving the
wrong third significant digit.

3. The trail of 9s is the same ~20 decimal digits for every floating-point
type, which suggests that they are all converted to 80-bit real before
formatting.  This obscures their difference in width, which is bad from at
least the learning standpoint.

Point 2 is sad.  One would expect at least the exact powers of two to be stored
exactly.  And indeed they are.  But trying to demonstrate it gives the wrong
impression that they are not.  This adds unnecessary confusion to the already
complex subject of how floating-point values work, and learning the subject
with D becomes much harder.

On the competition front, this already seems to be settled: at least with MinGW
GCC, both C printf and C++ cout correctly display powers of two - and perhaps
any small integers exactly stored as floating-point data, for that matter.

With DMD64, the issue vanishes.  This strongly suggests that 32-bit druntime is
the culprit.  And indeed, the Phobos "formatValue ... if
(is(FloatingPointTypeOf!T) && ...)" for floating-point calls snprintf from
druntime, after which I couldn't easily track it to the source code.  Should
this be so?  And regardless, perhaps snprintf (or Phobos or whatever will do
the dirty work) can adapt a more modern approach so that integers in
floating-point don't get corrupted when converted to string representation? 
Perhaps even without sacrificing much speed.  The most obvious way seems to
just make multiplications by 10, comparisons and subtractions in a loop, and is
likely slow but at least correct for integers.

Original forum thread:
https://forum.dlang.org/post/yzqpwkoycreifdzah...@forum.dlang.org

--

Re: D needs to publicize its speed of compilation

[Seb via Digitalmars-d]

On Thursday, 28 December 2017 at 13:20:34 UTC, Atila Neves wrote:

On Thursday, 28 December 2017 at 07:05:25 UTC, Joakim wrote:

On Sunday, 24 December 2017 at 22:55:12 UTC, aberba wrote:

On Friday, 22 December 2017 at 10:06:18 UTC, Joakim wrote:


What do you plan to do about it?


I have an idea or two. I just need time/mental energy to do 
this.


Atila


Are you aware of this great work: 
https://github.com/dlang/dmd/pull/7239?

Re: D needs to publicize its speed of compilation

[Atila Neves via Digitalmars-d]

On Thursday, 28 December 2017 at 07:21:28 UTC, Walter Bright 
wrote:

On 12/27/2017 1:23 PM, Atila Neves wrote:
However, my experience has been that D has fast builds from 
scratch, but is really really slow for incremental builds.
You can do fast incremental builds with D by not putting all 
the files on the command line. Just put one.


I don't build the compiler command-line myself, nor do I want to. 
Even then, recompiling one file isn't useful to me, what is is to 
recompile what's needed and run the tests. Emacs/flycheck already 
highlights compilation errors in just one file.


Atila

Re: D needs to publicize its speed of compilation

[Atila Neves via Digitalmars-d]

On Thursday, 28 December 2017 at 07:05:25 UTC, Joakim wrote:

On Sunday, 24 December 2017 at 22:55:12 UTC, aberba wrote:

On Friday, 22 December 2017 at 10:06:18 UTC, Joakim wrote:


What do you plan to do about it?


I have an idea or two. I just need time/mental energy to do this.

Atila

[Issue 18138] non-shared method overload not accessible through interface

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

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
`i` isn't shared, but the method of the interface requires sharedness. Thus,
the error is legit, imho.
Am I missing something?

--

Re: D as a betterC a game changer ?

[Russel Winder via Digitalmars-d]

On Thu, 2017-12-28 at 01:09 +, codephantom via Digitalmars-d wrote:
> 
[…]
> Well, you're doing what most people do, when they hear about a 
> new programming language - i.e. start comparing it to others 
> there is a psychological basis for that phenomena - it's human.
[…]

And is the way every programmer learns their non-first language. All
newly learned programming languages are merged into a person's "head
language" which is based on their first language but then evolves as
new languages, especially of new computational mode, are learned.

See Marian Petre and others work over the last 30 years for scientific
evidence of this.

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


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

Re: Maybe D is right about GC after all !

[Adrian via Digitalmars-d]

On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote:

"C, Python, Go, and the Generalized Greenspun Law"

http://esr.ibiblio.org/?p=7804


Aaaa... if only D had no GC!
But then there is no such thing as perfection in this world.

Re: Maybe D is right about GC after all !

[Russel Winder via Digitalmars-d]

On Wed, 2017-12-27 at 18:41 +, Laeeth Isharc via Digitalmars-d
wrote:
> 
[…]
> That's an extremely odd way to conceive of D, IMO, like 
> conceiving of a banana as being like an apple, only it tastes 
> like a banana and has a different shape.

Not really. When you write a function and give it a name, you extend
the working programming language for the application by the label and
it's abstraction. 
 
> If a general purpose programming language is to be conceived of 
> as a domain specific language, what's the difference between a 
> true domain specific language and a regular programming language?

There isn't one. As you write a program in the base language you extend
the working language by the abstractions, functions, classes, etc. that
you give names to. The application creates it's own working language
based on the base general purpose language.

Further the programmer has their own head language which is based on
the base programming language but with influence of all previously
learned languages. So a person who first learned Fortran and then D has
a different head language to a person who has learned C then D. These
two people appreciate the use of D in different ways so the starting
point for writing any program using D is different.

Marian Petre has spent 30 or so years experimenting on the head
language and programming expertise, as have others.

[…]
> 
> I don't think I suggested that tribalism in the everyday sense of 
> the word is favourable to the adoption of a language.  But that 
> aside, C is quite a big example, and I don't see that it has no 
> relevance to the present, even though conditions are of course 
> different.  Was Python adopted because of a big marketing budget? 
>   If so, I didn't know that - who paid for it?  How about R?

Python hit the scene in an interesting way and gained a small
following. That tribe then grew fairly organically without, at least
initially, any formal corporate backing. Even today Python development
is not directly backed by the corporations, but there is significant
indirect support now. You are right, Python is an example, post C, of a
language that grew without marketing budget.

R grew as a domain specific language for statistics. Whilst R could
grow, from what I have seen (so not experimental data), people switch
to Python for it's generality rather than continue with R. My personal
sample is biased as it was hedge funds needing R → Python training, and
hedge funds and others needing Matlab→ Python training.

> I think you also need to consider consequences of beliefs if you 
> are wrong and the choices available in circumstances (unless you 
> can figure out how to create new choices).  You write as if 
> adoption is flatlining.  It isn't - it's growing at a healthy 
> pace, as best I can see.  Human perception doesn't deal very well 
> with compound growth.  It's disappointing for a long time, and 
> all of a sudden it's surprising.

:-)

This is not a point we can argue with philosophy, we must await actual
data in the future.

> It's by far best at this point to get across successful stories 
> about the adoption of D to people who are already receptive to 
> them because they have some problems that D might help with than 
> to try to get people to listen to you who have no interest in 
> listening.  Persuasion works when people are ready to move 
> towards you.  You can't compel that.

Agreed. However I'd say you don't need to have them want to move to
you, though that helps, just that they want to move away from where
they are now.

Having constructive ripostes for negative criticism rather than just
getting defensive also helps. No excuses, that is guaranteed to lose
support. 

I like D and am using it for some Gtk stuff. However the GStreamer folk
are backing Rust (for memory safety issues noted earlier) so even
though D has a GStreamer binding (thanks to Mike and GtkD) I more or
less have to use Rust because it is the official binding. Comparing and
contrasting D and Rust is interesting for me. Both have many pluses and
many minuses. However, in the end, the GStreamer core people know C,
C++ a bit, D not at all. I suspect even if the choice had been Rust or
D, Rust would have been chosen because it has no GC and D is a GC
language.

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


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

[Issue 18138] New: non-shared method overload not accessible through interface

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

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

  Issue ID: 18138
   Summary: non-shared method overload not accessible through
interface
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: remi.theba...@gmail.com

Consider the following program and error.
The compiler should not complain.

If ITest is merged with IAtomicTest, the error is gone.
At run-time, methods are correctly dispatched.


interface ITest {
void method();
}

interface IAtomicTest : ITest {
shared void method();
}

class AtomicTest : IAtomicTest {
int member;
override final shared void method() {
import core.atomic : atomicOp;
import std.stdio : writeln;
auto m = atomicOp!"+="(member, 1);
writeln("atomic: ", m);
}
override final void method() {
import std.stdio : writeln;
member += 1;
writeln("non-atomic: ", member);
}
}

void main()
{
auto ao = new shared(AtomicTest);
auto o = new AtomicTest;
ao.method();// fine
o.method(); // fine

auto ai = cast(shared(IAtomicTest))ao;
auto i = cast(IAtomicTest)o;
ai.method();// fine
(cast(ITest)i).method();  // fine
i.method(); // Error: shared method app.IAtomicTest.method is not
callable using a non-shared object
}

--

Re: Maybe D is right about GC after all !

[Russel Winder via Digitalmars-d]

On Wed, 2017-12-27 at 01:23 +, codephantom via Digitalmars-d wrote:
> […]
> 
> But the design of graduate studies really needs to be radically 
> transformed, as they simply try to pack far too much in...leaving 
> students without any time to reflect on what they're doing, or 
> why they're doing it.

In which country? All countries have different education systems: you
cannot apply a criticism of one globally.
 
> In addition, we live in 'the age of distractions and 
> mulitasking', so students really learn very little these days 
> from doing a degree..(particulary those packed with too much 
> stuff).

And the evidence is? I know the USA government department are no longer
allowed to use words and concepts such as science-based and evidence-
based, but the rest of the world still works on needing evidence to
back up an opinion.

> I think this is why (at least in Australia), there is a 
> significant trend towards studying degrees part-time - the 
> cognitive load of full-time degrees not longer support the way 
> people want to (or just happen to) live these days.

Or they just do not have the money to study full-time?

> Until univerties stop trying to be money making machines, and get 
> back to teaching people how to learn about useful things, then 
> not much will change.

Not sure which country this is an observation on, but again all
countries are different so a global opinion is not possible. The
problem in the UK is the shift from wholly government funded tertiary
education, to partially government, partially personal funded tertiary
education. The cynical would see this as a way of stopping poor people
getting an education. 

> Anyway, too see how useful it is, to combine psychology and 
> programming language/library design, here is a great paper:
> 
> https://synesthesiam.com/assets/hansen2012_architectures.pdf
> 
> btw. One of the things I like most about D, has to do with 
> 'chunking comprehension' - and in comparison to C or C++, D is 
> the winner for sure.
> 
-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


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

Re: Maybe D is right about GC after all !

[Russel Winder via Digitalmars-d]

On Wed, 2017-12-27 at 16:44 +, Laeeth Isharc via Digitalmars-d
wrote:
> 
[…]
> That's like saying the way George Soros trades is not based on 
> psychology because he doesn't refer to the literature in making 
> and articulating his decision-making process.  Instead people 
> write papers about how he thinks, because it's not yet in the 
> literature!
> 
> If published knowledge were what was most important or valuable 
> then anyone intelligent with an interest in a subject would be 
> part of a war of all against all, because how is it possible to 
> have an edge?  But I don't think human expertise can be described 
> in that manner.  Karl Polanyi's work is quite interesting:
> 
> https://en.wikipedia.org/wiki/Tacit_knowledge
> 

I think you are missing the point, but to continue this here is to go
way off topic for this thread and indeed this email list, so maybe we
should start a thread elsewhere to continue this.

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


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

Re: Maybe D is right about GC after all !

[Russel Winder via Digitalmars-d]

On Wed, 2017-12-27 at 20:49 -0800, Walter Bright via Digitalmars-d
wrote:
> On 12/27/2017 8:29 AM, Russel Winder wrote:
> > This does not support the original claim that the design of D by
> > you is
> > based on psychology. It may be based on your perception of other
> > programmers needs, which is fine per se, but that is not
> > psychology-
> > based design.
> 
> All programming language design is based on human factors, i.e.
> psychology. If 
> it was purely computer science based, it would be in binary.

If you want to believe that fine. Clearly you are missing the point I
am making, which clearly must be my fault for bad expression. Also
clear it is not worth progressing this debate.

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


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

Re: float.max + 1.0 does not overflow

[Dave Jones via Digitalmars-d-learn]

On Wednesday, 27 December 2017 at 14:14:42 UTC, Benjamin Thaut 
wrote:

On Wednesday, 27 December 2017 at 13:40:28 UTC, rumbu wrote:

Is that normal?
It computes the difference between float.max and the next 
smaller reprensentable number in floating point. The difference 
printed by the program is:

20282409603651670423947251286016.0

As you might notice this is siginificantly bigger then 1.0. 
Floating point operations work like this: They perform the 
operation and then round to the nearest representable number in 
floating point. So adding 1.0 to float.max and then rounding to 
the nearest representable number will just give you back 
float.max. If you however add float.max and float.max the next 
nearest reprensentable number is float.inf.


The float with the lower exponent would have to be shifted to 
match the higher which means 1.0 would be shifted something like 
156 bits to the right before the addition can be done. If you 
shift right more bits than are in the mantissa then it get 
rounded to zero. Hence once the two values are lined up to do the 
actual op it becomes float.max + 0.0.


That said i suspect the OP was expecting the FPU unit to catch 
that in theory it should overflow. Not that the actual op would 
overflow but that the FPU would be checking the values on input. 
Maybe.

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #12 from Basile B.  ---
Before closing, would it be possible to gag the error if the LHS evaluates to
false ?

--

Re: DLang Tour : Functions as arguments

[Seb via Digitalmars-d-learn]

On Thursday, 28 December 2017 at 10:20:59 UTC, Basile B. wrote:

On Thursday, 28 December 2017 at 01:37:16 UTC, Tony wrote:

On this page:
https://tour.dlang.org/tour/en/basics/delegates

there is:

void doSomething(int function(int, int) doer) {
// call passed function
doer(5,5);
}

doSomething(add); // use global function `add` here
  // add must have 2 int parameters



I can't get it to compile unless it is:

doSomething();


Thanks for reporting this. This will be corrected soon:

https://github.com/dlang-tour/english/pull/220

If you find more issues, please rather use this bug dedicated 
tracker


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


Or simply click on the edit button yourself. Thanks for reporting 
and thanks @Basile for fixing it!

druntime memory unittest fails

[Thomas Mader via Digitalmars-d-learn]

Hello,

on NixOS the druntime memory unittest fails at 'assert(z is 
null);' 
(https://github.com/dlang/druntime/blob/v2.075.1/src/core/memory.d#L899)


Does anyone have a clue how that can happen?

Thomas

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #11 from Rainer Schuetze  ---
Short circuiting is only performed for "static if", which also works for your
test case.

The string comparison used to be converted to a runtime call, so it could not
be evaluated further (but with soe special support in CTFE). It is now a
template that can be const folded and reports the error.

--

Re: druntime memory unittest fails

[Seb via Digitalmars-d-learn]

On Thursday, 28 December 2017 at 10:23:38 UTC, Thomas Mader wrote:

Hello,

on NixOS the druntime memory unittest fails at 'assert(z is 
null);' 
(https://github.com/dlang/druntime/blob/v2.075.1/src/core/memory.d#L899)


Does anyone have a clue how that can happen?

Thomas


Use master: https://github.com/dlang/druntime/pull/1991

Re: DLang Tour : Functions as arguments

[Basile B. via Digitalmars-d-learn]

On Thursday, 28 December 2017 at 01:37:16 UTC, Tony wrote:

On this page:
https://tour.dlang.org/tour/en/basics/delegates

there is:

void doSomething(int function(int, int) doer) {
// call passed function
doer(5,5);
}

doSomething(add); // use global function `add` here
  // add must have 2 int parameters



I can't get it to compile unless it is:

doSomething();


Thanks for reporting this. This will be corrected soon:

https://github.com/dlang-tour/english/pull/220

If you find more issues, please rather use this bug dedicated 
tracker


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

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #10 from Basile B.  ---
(In reply to Rainer Schuetze from comment #9)
> > Sorry, did you miss my previous answer ? Use the code from the first 
> > message.
> > The regression is obvious.
> 
> I noticed and it is consistent with what I tried to say before: the reduced
> test case 

Damn, the reduced test case is wrong. Don't comment it

> fails because it checks "test()" for length 6, but then tries to
> access "test()"[$-7].
> 
> I think the problem actually existed before (as in my variation), but is now
> also visible in array comparisons a bit earlier.

Okay let's fix the test case:

```
int test()
{
if (test.stringof.length > 6 &&
test.stringof[$-7..$] == "1234567") {}
return 0;
}

enum a = test();
```

this compiles with 2.077.1, not with 2.078-beta.1.
the "&&" RHS is clearly here to prevent the bound error and the LHS should only
be evaluated once the RHS evaluates to "true". Unless the semantic for && is
different in CTFE mode, which i don't believe to be desirable, there's a
problem

The regression is that (a && b) behaves like ((a) & (b)) for some reason.

--

[Issue 18030] Segmentation fault with __traits(getProtection) on template function.

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

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #2 from greenify  ---
@dmdreport123: thanks a lot for creating the GitHub repository and Travis
integration, but the reduced test case is a lot better. This is just to avoid
unnecessary work in the future.

--

Re: tooling/help for rewriting C projects with betterC

[Jacob Carlborg via Digitalmars-d]

On 2017-12-27 21:48, yawniek wrote:
is there any tooling or tutorials on how one would approach a (partial) 
rewrite for bigger C projects that use e.g. cmake ?


is there a way parts of it could be automated (if so which parts) ?

this might help D a lot if people that want to learn/rewrite a library 
would get support and appropriate tooling.
also best practices and help on how C patterns can be transformed to 
(safe!) d code.


There's DStep [1], but that will only translate the headers to D 
modules. If you try it, please build it yourself from master. The 
binaries are very old.


[1] https://github.com/jacob-carlborg/dstep

--
/Jacob Carlborg

Re: SDL_Quit after GC shutdown?

[Mike Parker via Digitalmars-d]

On Thursday, 28 December 2017 at 06:34:00 UTC, Ivan Trombley 
wrote:
I believe that I should call SDL_Quit before my program 
terminates. However, some objects may be holding on to SDL 
resources and freeing these resources (particularly truetype 
resources) causes crashiness if SDL_Quit is called before. Is 
there a way to have SDL_Quit (and TTF_Quit) called after the GC 
has completed shutting down on program exit?


No. GC cleanup happens after static destructors are run.



If not then it could make things very complex and messy to keep 
track of these resources.


You really, really, really shouldn't be depending on class 
destructors to free resources like that. There is no guarantee a 
class destructor will ever be called and they are 
non-deterministic, so you can never ensure they will be called in 
a non-problematic sequence.


There are a number of alternatives here. The one I recommend is 
to use structs to wrap your SDL resources. It's what I settled on 
long ago and works well for me. Yes, you will have to take a 
couple of extra steps to cover all your bases if you don't want 
to manually release things, but it's possible to keep it simple 
and avoid messiness.

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #9 from Rainer Schuetze  ---
> Sorry, did you miss my previous answer ? Use the code from the first message.
> The regression is obvious.

I noticed and it is consistent with what I tried to say before: the reduced
test case fails because it checks "test()" for length 6, but then tries to
access "test()"[$-7].

I think the problem actually existed before (as in my variation), but is now
also visible in array comparisons a bit earlier.

--

Re: Maybe D is right about GC after all !

[Russel Winder via Digitalmars-d]

On Thu, 2017-12-28 at 03:34 +, codephantom via Digitalmars-d wrote:
> 
[…]
> I tried Go. I didn't like it. Syntax changes were not necessary, 
> and I got the feeling that the philosophy of Go, is that 
> programmers are incompetent and need training wheels. It wasn't 
> for me.

The core of go is lightweight processes and message passing/channels.
This makes it an excellent language and one of the reasons it has taken
off. (D has heavyweight processes and message passing which is great,
but isn't the same as Go.) A core principle for Go is that Google
interns can't break stuff in Google code. Add that to being a GC
focused extension of C and voila Go. It is a good language if you get
into it: a small language with a few annoying quirks, but a simple way
of working with objects and types, a small well constructed core
library, and a quasi-infinite, flexible secondary library, that allows
anyone to contribute at any time.

Plus the implicit pressure of being from Google, with JetBrains IDE
supports, and you get a very successful language, that has ended up
being a niche language: The Web. As opposed to being a general purpose
systems programming language.

> I looked at Rust, but never tried it, as I found the syntax to 
> pretty awful - and it reminded my too much of C++.

The syntax is fine, and it is so unlike C++, it is easy to get into. I
am using Rust as my primary language for all GStreamer stuff now.

> I looked at D, it looked nice. Syntax was familiar, and very C 
> like (which is the best kind of syntax IMHO). I decided to try 
> it.. and I just found it easy to work with...despite some bugs, 
> which you kinda of have to accept for now..but it's getting a lot 
> better.
> 
> Most importantly for me, is that it works on FreeBSD, otherwise 
> I'll lose interest immediately. I still use C though, as C is 
> still 'the' primary language on x..BSD, and will remains so for 
> the forseeable future.

Which is a tragedy. Why use portable assembler in 2017 when there are
actual high level languages such as Go, Rust, D, available for
everything except the very lowest level work.

> But gee.. I can do things in D so easily and quickly compare to 
> C, and I don't feel like I giving up much for that convenience. 
> Compare that to running dotnet ... g...you sit there just 
> waiting for the program to load.

C# and F# also have a lot going for them, I suspect you used it is the
wrong context and so got a bad feel. The same is true for Java. Kotlin,
Groovy, I guess which are great in a JVM-centred context.

> So everyone comes to a new language with their own requirements.

But mostly their own prejudices. Everyone brings their baggage.

> Work out what your's are... or just play with it.. and enjoy what 
> it has to offer.
> 
-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


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

Re: Maybe D is right about GC after all !

[Russel Winder via Digitalmars-d]

On Wed, 2017-12-27 at 14:36 -0800, Walter Bright via Digitalmars-d
wrote:
> […]
> 
> I found this out by asking the sales guys what feature of ZTC++ was
> closing the 
> deal - X, Y, Z, all the features I held dear. They'd say nope.
> Customers wanted 
> to use C++ for Win16, ZTC++ supported that, sold!
> […]

Give the punters what they want, even if it is not what they need or
should want. ;-)

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


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

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #8 from Basile B.  ---
(In reply to Rainer Schuetze from comment #7)
> > Rainer, not sure what you're saying. 
> > Is it invalid code in the test case, or a compiler problem?
> 
> I'm not 100% sure. At runtime the code will always produce a RangeError, but
> the check before it causes it to never be executed. Should it still be a
> compile error?
> 
> Allowing the condition could make writing generic code simpler, but might
> also trigger the "unreachable code" warning later. 
> 
> To change it, dmd.constfold must not produce errors (unconditionally), but
> keep the expressions that *might* cause an error at runtime or CTFE. Array
> indexing and divide by zero are probably affected, too.

Sorry, did you miss my previous answer ? Use the code from the first message.
The regression is obvious.

--

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #7 from Rainer Schuetze  ---
> Rainer, not sure what you're saying. 
> Is it invalid code in the test case, or a compiler problem?

I'm not 100% sure. At runtime the code will always produce a RangeError, but
the check before it causes it to never be executed. Should it still be a
compile error?

Allowing the condition could make writing generic code simpler, but might also
trigger the "unreachable code" warning later. 

To change it, dmd.constfold must not produce errors (unconditionally), but keep
the expressions that *might* cause an error at runtime or CTFE. Array indexing
and divide by zero are probably affected, too.

--

Re: Is this an okay representation of a dynamically sized Matrix, to be used for HMM matrices m = (A,B)

[Nicholas Wilson via Digitalmars-d-learn]

On Thursday, 28 December 2017 at 01:34:10 UTC, Enjoys Math wrote:



Code:

module matrix;

import std.array;


struct Matrix(E)
{
private:
   E[][];

   this() {
   }

   void deleteRow(int i)
   {
  E = E[0..i] ~ E[i..$];
   }

   void deleteColumn(int j)
   {
  for (int i=0; i < E.length; i++)
  {
 E[i] = E[i][0..j] ~ E[i][j..$];
  }
   }

   void insertRow(int i, E[] row)
   {
  if (E.length != 0)
 assert(E[0].length == row.length);
  E.insertInPlace(i, row);
   }

   void insertColumn(int j, E[] col)
   {
  for (int i=0; i < E.length; i++)
  {
 E[i].insertInPlace(j, col[i]);
  }
   }

   int numRows() { return E.length; }

   int numColumns() {
  if (E.length == 0)
 return 0;
  return E[0].length;
   }

}


Is there a more efficient way of doing this, knowing that I'll 
be inserting columns / rows every time we need to create a new 
hidden state so this matrix will be huge, for a good model.  By 
huge we'll probably use the full capacity of a long[] in D.  
I've already tried doing this in MQL5 and we exceeded easily 
the max array capacity.


Full capacity of a long[] (or any array) is the entire 
addressable memory, which is 4GB for 32bit. You will not exceed 
the 64bit address space.


Do you know the width of the matrix ahead of time? I assume they 
are all the same given the implementation of numColumns.


Have you looked at mir (https://github.com/libmir/mir-algorithm) 
for ndslice?


by deleting rows, can you get away with just zeroing them?

[Issue 18137] nothrow attribute is not written for some member functions to the JSON file

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

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

[Issue 18137] nothrow attribute is not written for some member functions to the JSON file

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

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

ZombineDev  changed:

   What|Removed |Added

Summary|Member function attributes  |nothrow attribute is not
   |are not written to the JSON |written for some member
   |file|functions to the JSON file

--

[Issue 18137] New: Member function attributes are not written to the JSON file

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

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

  Issue ID: 18137
   Summary: Member function attributes are not written to the JSON
file
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: petar.p.ki...@gmail.com

Created attachment 1672
  --> https://issues.dlang.org/attachment.cgi?id=1672=edit
Diff between the json generated by DMD v2.072.2 and DMD v2.077.1

When migrating dlang.org's dpl-docs from DMD v2.072.2 to DMD v2.077.1 in
https://github.com/dlang/dlang.org/pull/1926 I noticed that sometimes some
function attributes are not written to the JSON doc metadata file. I have
attached the diff between the two JSON files as seen on CyberShadow's
DAutoTest. For the most part, the upgrade was a clear improvement (e.g.
core.stdc.string.strchr), but I noticed that some member functions in druntime
were missing their nothrow attribute, for example core.memory.GC.malloc,
core.thread.Thread.start, core.thread.Fiber.this, etc.).

--