Re: two points

[Nick Sabalausky via Digitalmars-d-announce]

On 02/09/2017 01:08 AM, Joakim wrote:

I agree that "coercion," or more accurately the tyranny of the default,
is the dominant factor in language popularity even today, but you're
reaching when you apply that to web frameworks too.


Fair enough. It was just another example trying to make the point that 
"if you want to do X, then you have little choice but use Y" is, as you 
say, the dominant factor in language popularity. I can grant that the 
web framework examples are weaker examples.



D's problem on the client is that the popular platforms are still very
much tied to certain favored languages:

iOS - ObjC and Swift
Android non-game apps - Java
Android games - C/C++
Windows - C# or C++
Web - Javascript

Three of the four major client platforms all allow other languages (with
the fourth starting to with WebAssembly), but you're often fighting the
tide if you choose a non-default language so most don't bother.


That's a good way of explaining it, I like that.


We can make the dev experience more pleasant on those platforms, as I
believe has happened now that we support the MS toolchain on Windows,
but D is unlikely to become popular without a killer app that
demonstrates its suitability.  That's not coercion, but something we can
actually control.


I hope you're right, but I worry that even "killer app example" may not 
be enough, and that the lack of one may turn out to be just another red 
herring excuse for "why aren't using D". After all, I think vibe's 
approach to server development comes very close to "killer app" yet, far 
as I've seen, it doesn't appear to have proven a major win for D so far.


Then again, having D in the "my secret weapon" category has certain 
benefits, too, so I guess I can't be TOO sour ;)



On Thursday, 9 February 2017 at 00:30:53 UTC, Mike wrote:

I think the D leadership are too busy addressing broader issues with
the language at the moment, so this specific case is just not a high
priority.  Also, if it's not a priority to the them, then anyone that
does attempt to work on it will just suffer an eternity in pull
request purgatory.

So, I would not recommend it as a project for anyone until the D
leadership decides to get involved.


I think this misunderstands how open source works: the whole point is
that you don't need anybody's permission to go do this. Walter and
Andrei, or any other OSS core team, are much more likely to approve
something if you have an implementation that works well.  Look at Ilya
and what happened after he showed them Mir.



You're right, in theory. But Mike is unfortunately very right about the 
whole "suffer an eternity in pull request purgatory."


I fixed an issue where "///"-style doc comments resulted in excessive 
paragraph breaks...must've been over a year ago. Simple fix for a 
nagging bug. The fix worked. Caused no problems. No controversy. And to 
this day, just went completely ignored despite my periodic nagging about 
it. Eventually got tired wasting my time babysitting the constant need 
for rebasing and manual merge fixes just for something that proved 
guaranteed to be ignored. And any PRs I have managed to get through were 
all uphill battles the whole way.


We have far too high a threshold for letting things actually happen. It 
didn't used to be that way, and that was a key reason why D became as 
good as it's gotten in the first place.


So I'm not surprised people familiar with D go to lengths to avoid 
putting the effort into PRs that are much more major than my 
comparatively trivial PRs: It's proven to come with a depressingly high 
likelihood of turning out to be a complete waste of time.


At the risk of sounding hyperbolic, I think this is D's next biggest 
problem after the lack of any "If you want to do X, your only real 
choice is D". Though I admit I might be a little biased on this 
particular point though.

Re: Questionnaire

[Chris Wright via Digitalmars-d-announce]

On Wed, 08 Feb 2017 18:27:57 +, Ilya Yaroshenko wrote:
> 1. Why your company uses D?

You might have specified that this questionnaire is only for people who 
use D at work.

I use D for small utilities to help in development. For instance, I used 
vibe.d to compare performance with other frameworks when I had performance 
concerns.

> 2. Does your company uses C/C++, Java, Scala, Go, Rust?

We use Java, Kotlin, and some C/C++.

> 3. If yes, what the reasons to do not use D instead?

On the client side, we're building for Android. Some of it is native, and 
it would not be a natural fit to use D (minor modifications in Android 
platform code that's written in C/C++).

We use Swagger and Thrift for service definitions. Thrift supports D; 
Swagger does not.

We use AWS. There is no AWS client library for D and it would not be cost-
effective to implement one.

If we want people to learn a new programming language for the JVM, they 
probably know Java already, and the rest of the ecosystem is identical. 
With D, the ecosystem is entirely difficult.

Java has NullPointerException, while D has a segmentation fault. It's easy 
to catch NPE and harder to handle a segmentation fault, even if you are 
just trying to log and exit.

The "die on error" trend has me worried that it will be difficult to run 
services with reasonable uptime, and the people saying that we shouldn't 
even try to log anything in the face of an error worry me even more. I 
can't run systems in production if I'm not allowed to log errors. The 
runtime doesn't even promise to make an effort to let me catch an Error.

> 2. Have you use one of the following Mir projects in production:

No.

> 4. Have you use one of the following Tamedia projects in your
> production:

I've never even heard of them before. Have they ever thought of going into 
advertising?

> 5. What D misses to be commercially successful languages?

The backing of a large organization. The example of Go shows me that a 
language can become successful despite its technical attributes with the 
backing of a large organization.

Re: Beta D 2.073.1-b1

[Meta via Digitalmars-d-announce]

On Thursday, 9 February 2017 at 00:31:17 UTC, Martin Nowak wrote:

First beta for the 2.073.1 point release.

This version resolves a few regressions and bugs in the 2.073.0 
release.


http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.073.1.html


Please report any bugs at https://issues.dlang.org

-Martin


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

[Issue 17162] New: std.algorithm.startsWith fails to compile with -dip1000 switch

[via Digitalmars-d-bugs]

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

  Issue ID: 17162
   Summary: std.algorithm.startsWith fails to compile with
-dip1000 switch
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: monkeywork...@hotmail.com

import std.algorithm;

mixin template Property(alias member)
if (member.stringof.startsWith('_'))
{
import std.format: format;
import std.range: dropOne;

enum mixStrGet = `
@property typeof(member) %s()
{
return member;
}
`.format(member.stringof.dropOne());

mixin(mixStrGet);
}

struct Test
{
int _n;

mixin Property!_n;
}


Compiler switches:

-dip1000 -main


Error message:

dip100bug.d(4): Error: template std.algorithm.searching.startsWith cannot
deduce function from argument types !()(string, char), candidates are:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\searching.d(3944):   
std.algorithm.searching.startsWith(alias pred = "a == b", Range,
Needles...)(Range doesThisStart, Needles withOneOfThese) if (isInputRange!Range
&& Needles.length > 1 && is(typeof(.startsWith!pred(doesThisStart,
withOneOfThese[0])) : bool) && is(typeof(.startsWith!pred(doesThisStart,
withOneOfThese[1..__dollar])) : uint))
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\searching.d(4017):   
std.algorithm.searching.startsWith(alias pred = "a == b", R1, R2)(R1
doesThisStart, R2 withThis) if (isInputRange!R1 && isInputRange!R2 &&
is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) : bool))
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\searching.d(4086):   
std.algorithm.searching.startsWith(alias pred = "a == b", R, E)(R
doesThisStart, E withThis) if (isInputRange!R &&
is(typeof(binaryFun!pred(doesThisStart.front, withThis)) : bool))
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\searching.d(4096):   
std.algorithm.searching.startsWith(alias pred, R)(R doesThisStart) if
(isInputRange!R && ifTestable!(typeof(doesThisStart.front), unaryFun!pred))
dip100bug.d(23):while looking for match for Property!(_n)

--

two points

[Joakim via Digitalmars-d-announce]

I'm not going to fill out the questionnaire because I'm not at a 
company and have not tried Mir, but two points about what Nick 
and Mike wrote.


On Wednesday, 8 February 2017 at 20:40:48 UTC, Nick Sabalausky 
wrote:
Coercion (and perceived coercion[1] for that matter) makes 
technologies popular far more than any other factor. The 
computing sector is NOT a meritocracy, not by a longshot. That 
right there is D's #1 biggest marketing flaw, period. If you 
nail that coercion part, it doesn't matter HOW badly you do on 
any other technical or marketing aspect. Been proven time and 
time again. And if you DON'T have that coercion, you face an 
uphill battle no matter how good you do on technical and 
marketing fronts. Also been proven time and time again.


I agree that "coercion," or more accurately the tyranny of the 
default, is the dominant factor in language popularity even 
today, but you're reaching when you apply that to web frameworks 
too.  As you admit, rails didn't become as big as it might have 
because there were quickly many other web frameworks, ie 
languages and frameworks on the server are very competitive and 
that market is very fragmented, though PHP is likely the biggest.


D's problem on the client is that the popular platforms are still 
very much tied to certain favored languages:


iOS - ObjC and Swift
Android non-game apps - Java
Android games - C/C++
Windows - C# or C++
Web - Javascript

Three of the four major client platforms all allow other 
languages (with the fourth starting to with WebAssembly), but 
you're often fighting the tide if you choose a non-default 
language so most don't bother.


We can make the dev experience more pleasant on those platforms, 
as I believe has happened now that we support the MS toolchain on 
Windows, but D is unlikely to become popular without a killer app 
that demonstrates its suitability.  That's not coercion, but 
something we can actually control.


On Thursday, 9 February 2017 at 00:30:53 UTC, Mike wrote:
I think the D leadership are too busy addressing broader issues 
with the language at the moment, so this specific case is just 
not a high priority.  Also, if it's not a priority to the them, 
then anyone that does attempt to work on it will just suffer an 
eternity in pull request purgatory.


So, I would not recommend it as a project for anyone until the 
D leadership decides to get involved.


I think this misunderstands how open source works: the whole 
point is that you don't need anybody's permission to go do this.  
Walter and Andrei, or any other OSS core team, are much more 
likely to approve something if you have an implementation that 
works well.  Look at Ilya and what happened after he showed them 
Mir.


Now, you may not want to go do this on your own if you believe 
it's a lot of effort, could use a design the core team may not 
approve, and don't want to maintain or develop your own fork 
indefinitely, but that's a lot of "if"s.  I doubt it would be a 
lot of effort to strip D down like this, but I have not looked 
into it.

Re: Workaround for DIP 1005

[Jonathan M Davis via Digitalmars-d]

On Friday, February 03, 2017 14:43:01 Dominikus Dittes Scherkl via 
Digitalmars-d wrote:
> Any thoughts?

This is really cool, but I have a couple of concerns about this and how it
seems deficient in comparison to DIP 1005. I mentioned it in Andrei's PR for
this, but no one has responded to my comment.

This first problem is UFCS. While this technique works great for parameters
or on types you want to list in the template constraint, I don't see how it
can work with UFCS. So, if you have something like

auto func(alias pred, R)(R range)
if(isInputRange!R &&
   is(typeof(pred(range.front)) == bool))
{...}

you can do

auto func(alias pred, R)(R range)
if(from!"std.range.primitives".isInputRange!R &&
   is(typeof(pred(range.front)) == bool))
{...}

but you can't import std.range.primitives.front to make dynamic arrays work,
whereas with DIP 1005, you can just add the import to the function
declaration, and it will work without having to tie the import to a specific
symbol.

And while in many cases, you can just forgo UFCS - e.g.

auto func(P)(P param)
if(is(typeof(from!"std.algorithm".find(param)) == param))
{...}

that not only doesn't work with the range primitives, but it's bad practice
to use UFCS in the function body and not the template constraint (since the
semantics may not be the same), meaning that not using UFCS in the template
constraint means not using it in the function body for anything that's in
the template constraint (which many folks won't like and others won't
understand, resulting in subtle bugs), and any case where you want a
function to work with types that define a function as a member function as
well as with types that use a free function, you need to use UFCS and thus
cannot choose to not use it in the template constraint.

So, unless there's something that I don't understand about this technique
(which is definitely possible), it seems like it does not work with UFCS and
thus makes it considerably worse than 1005 for a lot of templated code, much
as it would work great for code that doesn't need UFCS.

The other problem is how much more verbose it is. With DIP 1005, you can do

with(import std.datetime)
auto foo(SysTime st1, SysTime st2, Duration d);

The import is only listed once, whereas with this technique, you have to
list it for each symbol. e.g.

auto foo(from!"std.datetime".SysTime st1,
 from!"std.datetime".SysTime st2,
 from!"std.datetime".Duration d);

The result is much more verbose, and if you have several symbols that need
imports between the return type, parameters, and template constraint, you
quickly end up with a lot of extra text in the middle of your function
signatures just because you want to tie the imports to the functions that
use them. With DIP 1005, the imports are next to the function but separate
where they avoid the need for repeating imports and don't get mixed into the
middle of the function signature.

So, while the proposed technique is really cool and clever in what it lets
us do without actually altering the language, it seems like it's quite a bit
worse than DIP 1005. As such, I'm inclined to argue that we should favor DIP
1005 over this proposal, as cool as it is.

- Jonathan M Davis

Re: GSoC Project Idea's Part 2

[Seb via Digitalmars-d]

On Friday, 3 February 2017 at 04:12:10 UTC, Craig Dillabaugh 
wrote:


So new project ideas are welcome, and feel free to post any 
ideas you have here for comment.


A couple of random ideas:

Compilation cache and parallel compilation
--

For bigger projects with more than 200k LoC (e.g. Weka) the 
compilation time gets quite noticeable.
One idea to speed up the compilation of a new run of DMD is to 
reuse a dump of the AST of the previous build.
In this spirit, Rust has quite recently introduced incremental 
compilation: 
https://blog.rust-lang.org/2016/09/08/incremental.html
Moreover, DMD runs single-threaded and there isn't a good way to 
parallelize a project than to split it into multiple sub packages.


High-level shared library implementation


Existing work: https://github.com/dlang/druntime/pull/617

betterC
---

Better support for C-style libraries with light or no runtime.

Revive old DIPs
---

There are many DIPs that contain awesome ideas and just wait for 
someone to champion them.


https://wiki.dlang.org/DIPs

A couple of interesting DIPS:

- RC objects: https://wiki.dlang.org/DIP77
- Tuples: https://wiki.dlang.org/DIP32
- Assert diagnostics: https://wiki.dlang.org/DIP83
- Named parameters: https://wiki.dlang.org/DIP88 (see also: 
https://github.com/dlang/DIPs/pull/22)

- Negation of attributes: https://wiki.dlang.org/DIP79
- Multiple alias this: https://wiki.dlang.org/DIP66
- Static inheritance: https://wiki.dlang.org/DIP84

Vibe.d
--

Probably the flagship library in the D universe.

- Load balancer with support for seemless recompile (vibedist)
- Add support for HTTP/2 
(https://github.com/rejectedsoftware/vibe.d/pull/1160)

- http.rest: Add automatic documentation generation
- http.rest: Provide new REST generator 
(https://github.com/rejectedsoftware/vibe.d/issues/1040)

- Asynchronous file I/O
- Add support for the Stream Control Transmission Protocol (SCTP) 
and Google's QUIC

Re: Codecov and CyberShadow failure

[Joakim via Digitalmars-d]

On Wednesday, 8 February 2017 at 17:30:53 UTC, RazvanN wrote:
I've noticed a couple of days ago that the 2 components 
mentioned in $title aren't working when making PRs. I don't 
have any experience with this, so what is there to be done?


RazvanN


CyberShadow is Vladimir Panteleev's nickname:

https://github.com/cybershadow

DAutoTest is his automated documentation tester that isn't 
working.

Re: Questionnaire

[Dsby via Digitalmars-d-announce]

On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:

1. Why your company uses  D?

  a. D is the best
  b. We like D
  c. I like D and my company allowed me to use D
  d. My head like D
  e. Because marketing reasons
  f. Because my company can be more efficient with D for some 
tasks then with any other system language



a,d

2. Does your company uses C/C++, Java, Scala, Go, Rust?


We use the C++ alaso.  we have C++ for writeing the Client by Qt.


3. If yes, what the reasons to do not use D instead?


No reasons to use D instead.


2. Have you use one of the following Mir projects in production:

  a. https://github.com/libmir/mir
  b. https://github.com/libmir/mir-algorithm
  c. https://github.com/libmir/mir-cpuid
  d. https://github.com/libmir/mir-random
  e. https://github.com/libmir/dcv - D Computer Vision Library
  f. std.experimental.ndslice


No.
3. If Yes, can Mir community use your company's logo in a 
section "Used by" or similar.


4. Have you use one of the following Tamedia projects in your 
production:


  a. https://github.com/tamediadigital/asdf
  b. https://github.com/tamediadigital/je
  c. https://github.com/tamediadigital/lincount


a, we use the asdf in hunt.


5. What D misses to be commercially successful languages?


Not has  distinct orientation。 and update slow。

6. Why many topnotch system projects use C programming language 
nowadays?



The GC。 and if not GC , D only has a little.

Re: code.dlang.org internal server error

[puming via Digitalmars-d]

On Wednesday, 8 February 2017 at 14:11:48 UTC, Sönke Ludwig wrote:

Am 08.02.2017 um 14:29 schrieb singingbush:

[...]


Yes, we need to prioritize this somehow. Having a fallback 
mirror, coupled with dependency upgrade checks that run 
asynchronously would get rid of these issues. It would be great 
if somebody could find the time to tackle one or the other. I 
personally have an very limited time budget for open source at 
the moment and I need to focus that on vibe.d for a bit.


BTW, the server is running again (it ran out of disk space 
again and I need to configure a proactive alert for that).


I have a VPS slot in Hong Kong for personal use, with 1GB memory, 
30GB disk and 300GB monthly bandwidth. Is that OK for a mirror 
site?

Re: Boston D Meetup 2/17: `shared` Experiences

[Steven Schveighoffer via Digitalmars-d-announce]

On 1/30/17 4:48 PM, Steven Schveighoffer wrote:

Attention fellow Boston D enthusiasts: I have set up a meetup for
February, and Michael Coulombe will give a presentation on his
experiences with shared.

As before, this will be at the Capital One Cafe in the back bay (across
from Prudential center).

Hope to see you all there!

https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/237324049/


FYI, this has been postponed, we are supposed to get 8-12 inches of snow 
lasting all day tomorrow.


I have rescheduled for next Friday, 2/17, which is the only day I could 
book.


-Steve

Re: Questionnaire

[Moritz Maxeiner via Digitalmars-d-announce]

On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:

1. Why your company uses  D?

  a. D is the best
  b. We like D
  c. I like D and my company allowed me to use D
  d. My head like D
  e. Because marketing reasons
  f. Because my company can be more efficient with D for some 
tasks then with any other system language


I use D only privately so far.



2. Does your company uses C/C++, Java, Scala, Go, Rust?


I've seen C, C++, and Java being used.



3. If yes, what the reasons to do not use D instead?


Nobody ever heard of the language (this holds true pretty much in 
every discussion I have on the topic)




2. Have you use one of the following Mir projects in production:

  a. https://github.com/libmir/mir
  b. https://github.com/libmir/mir-algorithm
  c. https://github.com/libmir/mir-cpuid
  d. https://github.com/libmir/mir-random
  e. https://github.com/libmir/dcv - D Computer Vision Library
  f. std.experimental.ndslice



No.

3. If Yes, can Mir community use your company's logo in a 
section "Used by" or similar.




N/A

4. Have you use one of the following Tamedia projects in your 
production:


  a. https://github.com/tamediadigital/asdf
  b. https://github.com/tamediadigital/je
  c. https://github.com/tamediadigital/lincount



I've used asdf for configuration files[1][2], it works very well 
for shortening development time.



5. What D misses to be commercially successful languages?


My two cents:
- "Name" backing by a well-known (i.e. internationally famous) 
corporation/foundation

- Viral marketing ("spread the D")
- Fix or removal of all the little things that may make someone 
go "ugh, wtf?". I'm looking at you, `shared`, and your missing 
memory barriers[5], or you, `std.parallelism.taskPool`, and your 
non-daemon "daemon" threads[6]. Privately I can work around them 
since it's my own time, but I don't expect many people in big 
companies (see first point) with a deadline to want to put up 
with that.

- Tooling, though that's been getting better
- Phobos without GC (where possible)
- std.experimental.allocator -> std.allocator and promote it as 
*the* memory management interface for D. Seriously. With it I can 
even allocate and pass delegates to C in an intuitive way (see 
[3] and [4]).




6. Why many topnotch system projects use C programming language 
nowadays?


Don't know if the premise holds, but if it does I'd wager it's 
because people who *do* write topnotch (system) software can do 
so in *any* (system) language that's asked of them - since in the 
end the topnotch comes from the person writing the code, not the 
language ("ignorance (of a language) can be remedied, stupid is 
forever") - and C has the de facto corporate monopoly of being 
asked to write in.



[1] https://git.ucworks.org/UCWorks/dagobar/tree/master
[2] https://git.ucworks.org/UCWorks/tunneled/tree/master
[3] 
https://git.ucworks.org/UCWorks/dagobar/blob/master/source/libuv.d#L125
[4] 
https://git.ucworks.org/UCWorks/dagobar/blob/master/source/libuv.d#L159

[5] https://dlang.org/faq.html#shared_guarantees
[6] https://issues.dlang.org/show_bug.cgi?id=16324

[Issue 17161] New: [REG 2.072.2] Massive Regex Slowdown

[via Digitalmars-d-bugs]

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

  Issue ID: 17161
   Summary: [REG 2.072.2] Massive Regex Slowdown
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

Created attachment 1636
  --> https://issues.dlang.org/attachment.cgi?id=1636=edit
The sample code

8x slower.

Not noticeable on smaller files. The input file to reproduce is too large to
post here. You can generate it by running the python code here:
https://benchmarksgame.alioth.debian.org/u64q/program.php?test=fasta=python3=3

$ python3 fasta.py 500 > input500.txt

# 2.072.2
$ /Users/Jack/digger/result/bin/dmd -O -inline -release -boundscheck=off slow.d
$ cat input500.txt | time ./slow
./slow  2.19s user 0.09s system 97% cpu 2.330 total


# 2.073.0
$ dmd -O -inline -release -boundscheck=off slow.d
$ cat input500.txt | time ./slow
./slow  18.23s user 0.16s system 98% cpu 18.616 total

--

Beta D 2.073.1-b1

[Martin Nowak via Digitalmars-d-announce]

First beta for the 2.073.1 point release.

This version resolves a few regressions and bugs in the 2.073.0
release.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.073.1.html

Please report any bugs at https://issues.dlang.org

-Martin

Re: Questionnaire

[Mike via Digitalmars-d-announce]

On Wednesday, 8 February 2017 at 22:52:36 UTC, bpr wrote:

On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote:
Suggesting D would be an exercise in futility, unless I can 
create a notable project in D in my spare time that 
demonstrates its advantages and appeal to the masses.  I tried 
to do this 2 years ago, but D failed me, primarily due to 
https://issues.dlang.org/show_bug.cgi?id=14758


I read this comment from you on another thread too, and 
(caveat: I'm not working in such resource constrained domains 
as you are) it seems sensible. It seems like it may be a good 
GSOC project to modify dmd as you suggest elsewhere. Have you 
considered trying to find someone to do that?


First, for that to happen, the D leadership would need to chime 
in with a plan on how they want to address this problem.  Second, 
for me to allocate any more of my resources, I'd have to be 
convinced that their plan is a good solution to the problem.  A 
-betterC switch is not at all attractive to me.


I think the D leadership are too busy addressing broader issues 
with the language at the moment, so this specific case is just 
not a high priority.  Also, if it's not a priority to the them, 
then anyone that does attempt to work on it will just suffer an 
eternity in pull request purgatory.


So, I would not recommend it as a project for anyone until the D 
leadership decides to get involved.


I'd love to see a D3, but that seems unlikely, and more 
unlikely if D2 languishes. It seems though that your issues are 
with the implementation, not the language itself, so if you got 
your wishes below



Instead I suggest following through on things like
https://issues.dlang.org/show_bug.cgi?id=12270 and considering 
this proposal

(http://forum.dlang.org/post/psssnzurlzeqeneag...@forum.dlang.org) instead.


wouldn't you be mostly satisfied with D2?


Correct, my issue is not really with the language, but with its 
implementation.


Resolving issue 12270 and implementing my proposal for decoupling 
the compiler and druntime would prompt me to further explore D.


I'd also like to see how the recent DIP25 and DIP1000 could be 
leveraged.  I'm looking forward to an article on the topic, or 
Walter's talk at DConf2017 before I dedicate any of my time to 
it.  At first glance, however, it seems like a lot of attribute 
patchwork.


It's become apparent to me that D just hasn't been designed with 
bare-metal systems programming in mind, so I'm skeptical that 
even if issue 12270 and my decoupling proposal were implemented, 
I'd still run into other disappointments.   But I'd at least be 
willing to give it another try, and would be thrilled to be 
proven wrong.


Mike

Re: Questionnaire

[Nicholas Wilson via Digitalmars-d-announce]

On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:
All my current D project are finished. Probably I will use 
other languages for production this year, Java/Go/whatever.


N...

I Guess I'll have to try to convince you to help with DCompute 
once the necessary compiler stuff gets merged into LDC.

Re: Questionnaire

[bpr via Digitalmars-d-announce]

On Wednesday, 8 February 2017 at 21:41:24 UTC, Mike wrote:
Suggesting D would be an exercise in futility, unless I can 
create a notable project in D in my spare time that 
demonstrates its advantages and appeal to the masses.  I tried 
to do this 2 years ago, but D failed me, primarily due to 
https://issues.dlang.org/show_bug.cgi?id=14758


I read this comment from you on another thread too, and (caveat: 
I'm not working in such resource constrained domains as you are) 
it seems sensible. It seems like it may be a good GSOC project to 
modify dmd as you suggest elsewhere. Have you considered trying 
to find someone to do that?


I believe D has the potential to bury all other emerging 
languages out there, but only if it drops its historical 
baggage.
 At the moment, I'm of the opinion that D will remain an 
obscure language until someone forks D and takes it in a 
different direction (unlikely), or the D Foundation decides to 
"reboot" and start working on D3 with a new, updated 
perspective (more unlikely).


I'd love to see a D3, but that seems unlikely, and more unlikely 
if D2 languishes. It seems though that your issues are with the 
implementation, not the language itself, so if you got your 
wishes below



Instead I suggest following through on things like
https://issues.dlang.org/show_bug.cgi?id=12270 and considering 
this proposal

(http://forum.dlang.org/post/psssnzurlzeqeneag...@forum.dlang.org) instead.


wouldn't you be mostly satisfied with D2?

[Issue 17160] Apparently faulty behavior comparing enum members using `is`

[via Digitalmars-d-bugs]

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

j...@red.email.ne.jp changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||j...@red.email.ne.jp

--- Comment #2 from j...@red.email.ne.jp ---
This seems to work without the parameter attr 'in'.

test(Enum a)

--

Re: Questionnaire

[Mike via Digitalmars-d-announce]

On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko 
wrote:

1. Why your company uses  D?


We don't use D.


2. Does your company uses C/C++, Java, Scala, Go, Rust?


C/C++.  Currently exploring Rust.


3. If yes, what the reasons to do not use D instead?


* The powers that be in my company are the kind of C programmers 
that can't understand why anyone would want to use C++ (i.e. 
Electrical engineers that write software).  Suggesting D would be 
an exercise in futility, unless I can create a notable project in 
D in my spare time that demonstrates its advantages and appeal to 
the masses.  I tried to do this 2 years ago, but D failed me, 
primarily due to https://issues.dlang.org/show_bug.cgi?id=14758


* Our customers don't use D.  Some of our products are libraries 
and tools that our customers use.  It doesn't make sense to 
program them in D if our customers don't use D.  Though, if D had 
a minimal runtime, we could write them in D and distribute them 
with bindings to other languages.


* For us, binary size efficiency and minimal runtime are 
important features.  D is not pay-as-you-go; many heavy-weight 
features are opt-out instead of opt-in.  In contrast Rust has 
"minimal runtime" as one of its pillars making it a much better 
alternative language choice for us than D.



2. Have you use one of the following Mir projects in production:


No

3. If Yes, can Mir community use your company's logo in a 
section "Used by" or similar.


N/A

4. Have you use one of the following Tamedia projects in your 
production:


No


5. What D misses to be commercially successful languages?


I believe D has the potential to bury all other emerging 
languages out there, but only if it drops its historical baggage. 
 At the moment, I'm of the opinion that D will remain an obscure 
language until someone forks D and takes it in a different 
direction (unlikely), or the D Foundation decides to "reboot" and 
start working on D3 with a new, updated perspective (more 
unlikely).


6. Why many topnotch system projects use C programming language 
nowadays?


Which topnotch system projects?

* C is the lowest common denominator.  All modern languages that 
I'm aware of can interface with C.  If one wants to write a 
library for mass adoption, the best way to do so is to write it 
in C and create bindings for other languages.  D could be a good 
substitute for this if it had a "minimal runtime" philosophy.


* C is a simple, efficient, and powerful language.  Some equate 
language complexity and heavy runtimes to bloat and inefficiency. 
 Some see too much language complexity as an impediment to 
productivity.  C creates the appearance of simplicity with 
efficiency.


* "Minimal Runtime" is the building block of systems programming. 
 If this is not a core feature of a language, it will never 
compete with C.  Systems programmers in my field need to 
incrementally opt-in to features in a pay-as-you-go fashion to 
make precise tradeoffs for their unique requirements and hardware 
platforms.  Rust is the only modern language that I'm aware of 
that's getting this right.


* You may also be interested Dan Sak's recent talk "extern c: 
Talking to C Programmers about C++": 
https://www.youtube.com/watch?v=D7Sd8A6_fYU=2631s

[Issue 17160] Apparently faulty behavior comparing enum members using `is`

[via Digitalmars-d-bugs]

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

--- Comment #1 from Sophie  ---
This issue seems not to occur when using `enum Enum: real` instead of double.

>From IRC:

 hmm it does a byte comparison but they differ, one is 00D0CC... the other
is CDCC...
 i am guessing that the enum treats it more like a literal than
the variable does so it gets imprecise passed to functions
 it stores the literial enum value as a real 80-bit floating point number
 but it looks like it passes a double into the function

--

Re: Codecov and CyberShadow failure

[Jack Stouffer via Digitalmars-d]

On Wednesday, 8 February 2017 at 17:30:53 UTC, RazvanN wrote:
I've noticed a couple of days ago that the 2 components 
mentioned in $title aren't working when making PRs. I don't 
have any experience with this, so what is there to be done?


RazvanN


Trying to narrow it down here: 
https://github.com/dlang/phobos/pull/5099

[Issue 17160] New: Apparently faulty behavior comparing enum members using `is`

[via Digitalmars-d-bugs]

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

  Issue ID: 17160
   Summary: Apparently faulty behavior comparing enum members
using `is`
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: meapineap...@gmail.com

With DMD v2.072.2 on Windows 7 this code produces an assertion error:

unittest{
enum Enum: double{A = 0.1}
bool test(in Enum a){return a is Enum.A;}
assert(test(Enum.A));
}

When `A = 1` or other values that can be represented more exactly as a floating
point, the code does not produce an error.

Given that this code does not produce such an error, I'm especially inclined to
think this is not intended behavior:

unittest{
enum Enum: double{A = 0.1}
assert(Enum.A is Enum.A);
}

--

Re: Questionnaire

[Nick Sabalausky via Digitalmars-d-announce]

On 02/08/2017 01:27 PM, Ilya Yaroshenko wrote:

1. Why your company uses  D?

   a. D is the best
   b. We like D
   c. I like D and my company allowed me to use D
   d. My head like D
   e. Because marketing reasons
   f. Because my company can be more efficient with D for some tasks
then with any other system language


x. Because I'm self-employed so I get to choose the best tool for the 
job instead of whatever some know-nothing manager thinks "must be good 
because its popular". Also, all of the above.



2. Does your company uses C/C++, Java, Scala, Go, Rust?


Not when I can help it.


3. If yes, what the reasons to do not use D instead?


If, for whatever reason, my hands are tied and it's just not a 
possibility. Usually platform/framework compatibility. Or somebody above 
me deciding "You must use language X". (But, after having had more than 
enough PHP/VB/Java/C++/Python/etc in my life, I'm more inclined now to 
simply avoid situations that would involve such restraints. Life's too 
short to suffer bad tools for bad reasons.)



2. Have you use one of the following Mir projects in production:


No. I keep hearing about Mir, but still haven't quite wrapped my head 
around what it is, or how/where to use it. (and that bugs me)



3. If Yes, can Mir community use your company's logo in a section "Used
by" or similar.


N/A


4. Have you use one of the following Tamedia projects in your production:

   a. https://github.com/tamediadigital/asdf
   b. https://github.com/tamediadigital/je
   c. https://github.com/tamediadigital/lincount


First I've heard of them. I'll take a look.


5. What D misses to be commercially successful languages?


A groupthink mentality and loads of bad ideas and broken reasoning. Ie, 
the basic requirements for anything to be popular in the computing arena.


Seriously. I'm not joking.

Well, that and, nobody's ever really been in a situation where they're 
more or less FORCED to use D. Many, heck probably most, big-name 
languages got big because there were enough people who didn't have much 
of a choice:


- Earlier days of Unix/Linux dev? Hard to avoid C/C++.
- Work for a company that's heavily invested in MS tools? Hard to avoid 
VB (90's) or C# (2000's).
- Work for a non-MS-based enterprise? Hard to avoid Java, because that's 
what the higher-ups had already been sold on.

- Need to use a relational DB? SQL, period.
- Need client-side scripting on a web page? JavaScript, period (until 
just recently).
- If you wanted an MVC web framework, for a short while Ruby was the 
only choice. I guarantee Ruby would be more popular today if that time 
period had been longer. It's undeniable nobody would've ever heard of 
Ruby were it not for Rails.
- Need to run something on an affordable commodity server in the late 
90's/2000's? PHP, period. Unless you paid an extra $5-$10/mo. and 
restricted your choice of providers - then you could use VBScript/ASP, 
which was basically the same exact thing as PHP, but just incompatible.
- Need low-level hardware access, memory management or other direct 
control over performance and resource usage? Until recently, had to be 
C/C++.


Then once onboard, stockholm syndrome sets in. Instant popularity.

Coercion (and perceived coercion[1] for that matter) makes technologies 
popular far more than any other factor. The computing sector is NOT a 
meritocracy, not by a longshot. That right there is D's #1 biggest 
marketing flaw, period. If you nail that coercion part, it doesn't 
matter HOW badly you do on any other technical or marketing aspect. Been 
proven time and time again. And if you DON'T have that coercion, you 
face an uphill battle no matter how good you do on technical and 
marketing fronts. Also been proven time and time again.


[1] The "I must keep up or get left behind" thought train. See also 
"Cover Fire" and the Fire and Motion stuff here: 
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/



6. Why many topnotch system projects use C programming language nowadays?


Partly inertia, but also because there was a decade or two (that only 
ended a few years ago) where nearly all language designers obsessed over 
VMs and eliminating low-level capabilities, and in general dumbing down 
their languages to the point of uselessness for anyone but novices, 
hobbyists, and those who could afford to throw money/hardware at any and 
all performance/resource/scalability issues[2]. Because of that, for 
many C/C++ users, there simply was no realistic alternative, period.


[2] I'm sure 90's Sun LOVED their JVM/Java - it virtually guaranteed 
"optimization" could only mean "rent/buy more hardware" - Everything 
else besides reducing algorithmic complexity was deliberately banned by 
both the language and the VM...as a self-proclaimed "feature" no less. 
That "feature" allegedly being for safety, but decades of security 
patches and exploits for every VM on the planet proved that to be a load 
of...male cow.

[Issue 16577] deduplicate deprecation messages

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
   Severity|minor   |enhancement

--- Comment #2 from Martin Nowak  ---
Would be fairly simple to deduplicate deprecation messages when triggering
them, not sure about the memory requirements (prolly not much) or other
strategies to avoid emitting the same message.
We should only deduplicate messages occuring at the same source location, so
that it remains possible to fix all of them in one go.

--

Re: Passing variables, preserving UDAs: A Gripe

[Nick Sabalausky via Digitalmars-d]

On 02/08/2017 01:00 PM, Nick Sabalausky wrote:


But even if that did compile, it still wouldn't work because doStuff
wouldn't be able to access "foo.s" since "foo" isn't getting passed in
in any way.



I mean, in order to *set* a value for "foo.s", not *just* access UDAs.

Re: GC question

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

On Saturday, 4 February 2017 at 15:23:53 UTC, Adam D. Ruppe wrote:

On Saturday, 4 February 2017 at 12:56:55 UTC, osa1 wrote:

- Automatic but conservative. Can leak at any time.


All GCs are prone to leak, including precise ones. The point of 
garbage collection is not to prevent leaks, but rather to 
prevent use-after-free bugs.


No, the main point of GC is to prevent leaks in the case where 
you have circular references.


Precise GCs don't leak, by definition. If the object is reachable 
then it isn't a leak.


Now, you might claim that objects that provably won't be touched 
again should be classified as dead and freed and that this is a 
bug that exhibit the same behaviour as a leak (running out of 
memory). But it's really nothing like the leaks you experience 
with manual memory management (e.g. circular references 
preventing memory from being released in a reference counting 
management scheme)

Re: Internal error on Wiki page

[Vladimir Panteleev via Digitalmars-d]

On Wednesday, 8 February 2017 at 02:20:59 UTC, rikki cattermole 
wrote:

Probably related. Help! :)

code.dlang.org/

500 - Internal Server Error

Internal Server Error

Ali


Last I checked they are not integrated or use the same 
technologies.

New post please.


Yep, different server :)

Re: Questionnaire

[Ilya Yaroshenko via Digitalmars-d-announce]

Plus, it can be enchanted during the GSoC 2017.


EDIT: enhanced

Re: Mir Algorithm preview: the new ndslice, dlang Iterators, fast generics

[Ilya Yaroshenko via Digitalmars-d]

2. Canonical:
BLAS-like, raw stride is assumed to be 1


EDIT: row stride

Questionnaire

[Ilya Yaroshenko via Digitalmars-d-announce]

1. Why your company uses  D?

  a. D is the best
  b. We like D
  c. I like D and my company allowed me to use D
  d. My head like D
  e. Because marketing reasons
  f. Because my company can be more efficient with D for some 
tasks then with any other system language


2. Does your company uses C/C++, Java, Scala, Go, Rust?

3. If yes, what the reasons to do not use D instead?

2. Have you use one of the following Mir projects in production:

  a. https://github.com/libmir/mir
  b. https://github.com/libmir/mir-algorithm
  c. https://github.com/libmir/mir-cpuid
  d. https://github.com/libmir/mir-random
  e. https://github.com/libmir/dcv - D Computer Vision Library
  f. std.experimental.ndslice

3. If Yes, can Mir community use your company's logo in a section 
"Used by" or similar.


4. Have you use one of the following Tamedia projects in your 
production:


  a. https://github.com/tamediadigital/asdf
  b. https://github.com/tamediadigital/je
  c. https://github.com/tamediadigital/lincount

5. What D misses to be commercially successful languages?

6. Why many topnotch system projects use C programming language 
nowadays?


=

All my current D project are finished. Probably I will use other 
languages for production this year, Java/Go/whatever. Mir 
libraries are amazing and good quality. If you use them this 
would be a good motivation for us to improve the docs and provide 
regular updates. Plus, it can be enchanted during the GSoC 2017.


Thanks,
Ilya

Life is better with community automation

[qznc via Digitalmars-d]

I just watched this talk "Life is better with Rust's community 
automation" by E. Dunham


Video: https://youtu.be/dIageYT0Vgg
Blog post: 
http://edunham.net/2016/09/27/rust_s_community_automation.html 
(Not the same talk, but very close and by the correct 
speaker/blogger)


Some of the 2017 H1 vision [0] concerns "Improve process 
(release, DIPs, deprecations/enhancements)" and "Improve 
operational efficiency". So community automation fits the agenda.


I guess most people are roughly aware of the Rust tooling (bors, 
highfive, etc). Somethings are replicated with D, but we don't 
anthropomorphize [1] our tools.


One thing, I did not know yet was the Servo Starters website [2]. 
Servo is not Rust itself, but its biggest "demo" project. The 
starters website is for newbies, who would like to contribute a 
little. It maintains a list of open issues for newbies and 
filters them a little.


With D, we just point people to the wiki [3]. Maybe this approach 
would be a little more inviting?


[0] https://wiki.dlang.org/Vision/2017H1
[1] https://auto-tester.puremagic.com/
[2] https://starters.servo.org/
[3] https://wiki.dlang.org/Get_involved

Re: Passing variables, preserving UDAs: A Gripe

[Nick Sabalausky via Digitalmars-d]

On 02/08/2017 07:38 AM, Kagamin wrote:

try this:
void main()
{
 auto foo = new Foo();
 doStuff!(Foo.s);
}


Same result:
Error: need 'this' for 'doStuff' of type 'pure nothrow @nogc @safe void()'

But even if that did compile, it still wouldn't work because doStuff 
wouldn't be able to access "foo.s" since "foo" isn't getting passed in 
in any way.

Re: Cross-compile with LDC

[kinke via Digitalmars-d-learn]

On Wednesday, 8 February 2017 at 17:21:03 UTC, Oleg B wrote:
If I understand correctly with vanilla LDC I can't 
cross-compiling from host linux-x86_64, but with your patch I 
can. Right?


Right. Joakim Noah has worked on LDC for Android and as far as I 
know provides some prebuilt compilers, a native one and a 
cross-compiler (Linux x86_64 host) including that patch.
There's also a pre-built Windows -> ARM cross-compiler; see 
http://forum.dlang.org/thread/xzzzfvahuwvgsluli...@forum.dlang.org and more ARM-related threads in our subforum.


If I use your patch must I use in my programs only double or I 
can stay real in existing code?


Don't worry, the reals can stay.

[Issue 17159] Behavior of unions at compile time is not documented

[via Digitalmars-d-bugs]

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

Sophie  changed:

   What|Removed |Added

 CC||meapineap...@gmail.com

--- Comment #1 from Sophie  ---
>From IRC:

 lost my login
 can someone answer this
http://forum.dlang.org/thread/mailman.319.1486565256.31550.digitalmars-d-b...@puremagic.com
and say that this has been the case for ages
 and that newCTFE will eventually fix it if it is _really_ desired
I'd say it catches bugs

--

Codecov and CyberShadow failure

[RazvanN via Digitalmars-d]

I've noticed a couple of days ago that the 2 components mentioned 
in $title aren't working when making PRs. I don't have any 
experience with this, so what is there to be done?


RazvanN

Re: Cross-compile with LDC

[Oleg B via Digitalmars-d-learn]

On Wednesday, 8 February 2017 at 16:21:49 UTC, kinke wrote:

On Wednesday, 8 February 2017 at 14:57:41 UTC, Oleg B wrote:
Hello all! I want to build ldc cross compiller. I found this 
instruction  
https://wiki.dlang.org/LDC_cross-compilation_for_ARM_GNU/Linux, but I have some doubts: will it works with ldc-1.1.0? Particularly interested in the patch https://gist.githubusercontent.com/claudemr/3367c13095b15d449b1591eb38d098d9/raw/3517a5db2228e57da9dd8880a82d6bfe6f0e38f1/ldc_1.0.0_gnu_arm. It's for ldc-1.0.0 and sources can be changed.

Maybe somewhere I found patch for ldc-1.1.0?
Maybe someone already build cross ldc for linux x86_64?))


Hi Oleg,

first of all, we have an LDC forum/NG 
(http://forum.dlang.org/group/ldc) which would be more 
appropriate for your question. The referenced LDC patch is 
derived from https://github.com/ldc-developers/ldc/pull/1317, 
which hasn't been merged yet (but will be in not-too-distant 
future).
As you haven't explicitly specified what your target platform 
is, I can only assume that it's 32-bit ARM. With a vanilla LDC, 
cross-compiling to ARM with its double-precision reals will 
only work correctly if your LDC host compiler uses 
double-precision reals too, which isn't the case for Linux 
x86(_64), but for Windows. My LDC PR would make it work with a 
non-Windows x86(_64) host too, but only if the target (not the 
host) uses at most double-precision reals.


Thank you, in future I create new question about ldc in special 
forum. Yes, my target arch is ARMv7 (rpi2 and beaglebone) and 
ARMv8 (rpi3). If I understand correctly with vanilla LDC I can't 
cross-compiling from host linux-x86_64, but with your patch I 
can. Right? Maximum precision for ARMv7(8) is 64bit doubles, for 
x86_64 is 80bit reals. If I use your patch must I use in my 
programs only double or I can stay real in existing code?

Re: Mir Algorithm preview: the new ndslice, dlang Iterators, fast generics

[Ilya Yaroshenko via Digitalmars-d]

On Wednesday, 8 February 2017 at 15:33:25 UTC, jmh530 wrote:
On Tuesday, 7 February 2017 at 16:18:20 UTC, Ilya Yaroshenko 
wrote:


Feedback is welcome!



I don't have time right now to play around with it, but I 
looked through the documentation. Here are my comments:


1) I would consider
http://docs.algorithm.dlang.io/latest/mir_ndslice.html
to be the first thing that anyone looks at when they think 
about mir ndslice. I think it's pretty good, but there's always 
room for some improvements, such as


a) The extent of the compatibility between D's standard library 
and mir (such as what you wrote in the post above)
b) Some of your high level explanation for the motivation for 
recent changes, such as iterators, 
universal/canonical/contigous. I.e., something along the lines 
of ndslice is so powerful it can do all these different things.


2) The explanation of the difference between universal, 
canonical, and contiguous is in

http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#.Slice
It should be referenced in functions like 
Universal/Canonical/Contigous/universal/canonical.


3) mir.ndslice.topology has universal, canonical, 
assumeCanonical, and assumeContiguous. Why no contiguous or 
assumeUniversal?


4) It looks like some of the functions from std.algorithm, like 
map, are now in mir.ndslice.topology instead of 
mir.ndslice.algorithm. You might include more detailed 
explanations at the top of the documentation of topology and 
algorithm for why the modules are split up this way.


Keep up the good work.


1, 2, 4 Agreed. I wonder if ndslice (any) is used by companies, 
if so, i can invest more my time to it. Will post a questionary 
in announce.


3) contiguous and canonical can be always safely converted to 
universal. Plus, contiguous can be always safely converted to 
canonical.


Safe: contiguous -> canonical -> universal
Unsafe (has assume prefix)  universal -> canonical -> contiguous

The ndslice composes all kind of random access ranges you may 
have in real life with one interface, one declaration. And this 
is faster to develop (2-10 times less LOC), compile, and execute 
because of implementation techniques. In addition, it is 
multidimensional. bitwise, zip, map are good examples to compare 
Mir and Phobos.

Re: Cross-compile with LDC

[kinke via Digitalmars-d-learn]

On Wednesday, 8 February 2017 at 14:57:41 UTC, Oleg B wrote:
Hello all! I want to build ldc cross compiller. I found this 
instruction  
https://wiki.dlang.org/LDC_cross-compilation_for_ARM_GNU/Linux, 
but I have some doubts: will it works with ldc-1.1.0? 
Particularly interested in the patch 
https://gist.githubusercontent.com/claudemr/3367c13095b15d449b1591eb38d098d9/raw/3517a5db2228e57da9dd8880a82d6bfe6f0e38f1/ldc_1.0.0_gnu_arm. It's for ldc-1.0.0 and sources can be changed.

Maybe somewhere I found patch for ldc-1.1.0?
Maybe someone already build cross ldc for linux x86_64?))


Hi Oleg,

first of all, we have an LDC forum/NG 
(http://forum.dlang.org/group/ldc) which would be more 
appropriate for your question. The referenced LDC patch is 
derived from https://github.com/ldc-developers/ldc/pull/1317, 
which hasn't been merged yet (but will be in not-too-distant 
future).
As you haven't explicitly specified what your target platform is, 
I can only assume that it's 32-bit ARM. With a vanilla LDC, 
cross-compiling to ARM with its double-precision reals will only 
work correctly if your LDC host compiler uses double-precision 
reals too, which isn't the case for Linux x86(_64), but for 
Windows. My LDC PR would make it work with a non-Windows x86(_64) 
host too, but only if the target (not the host) uses at most 
double-precision reals.

Re: Mir Algorithm preview: the new ndslice, dlang Iterators, fast generics

[jmh530 via Digitalmars-d]

On Wednesday, 8 February 2017 at 15:33:25 UTC, jmh530 wrote:


I don't have time right now to play around with it, but I 
looked through the documentation. Here are my comments:




Also on #2, you might beef that link up with some of the comments 
from the post up top.

Re: Mir Algorithm preview: the new ndslice, dlang Iterators, fast generics

[jmh530 via Digitalmars-d]

On Tuesday, 7 February 2017 at 16:18:20 UTC, Ilya Yaroshenko 
wrote:


Feedback is welcome!



I don't have time right now to play around with it, but I looked 
through the documentation. Here are my comments:


1) I would consider
http://docs.algorithm.dlang.io/latest/mir_ndslice.html
to be the first thing that anyone looks at when they think about 
mir ndslice. I think it's pretty good, but there's always room 
for some improvements, such as


a) The extent of the compatibility between D's standard library 
and mir (such as what you wrote in the post above)
b) Some of your high level explanation for the motivation for 
recent changes, such as iterators, universal/canonical/contigous. 
I.e., something along the lines of ndslice is so powerful it can 
do all these different things.


2) The explanation of the difference between universal, 
canonical, and contiguous is in

http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#.Slice
It should be referenced in functions like 
Universal/Canonical/Contigous/universal/canonical.


3) mir.ndslice.topology has universal, canonical, 
assumeCanonical, and assumeContiguous. Why no contiguous or 
assumeUniversal?


4) It looks like some of the functions from std.algorithm, like 
map, are now in mir.ndslice.topology instead of 
mir.ndslice.algorithm. You might include more detailed 
explanations at the top of the documentation of topology and 
algorithm for why the modules are split up this way.


Keep up the good work.

Re: vibe.d 0.8.0 and 0.7.31 beta releases

[Sönke Ludwig via Digitalmars-d-announce]

Am 08.02.2017 um 11:30 schrieb Kagamin:

On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote:

Keeping the system overloads would break the safety guarantees at a
relatively deep level and would render the whole effort rather useless
(this is the case for non-scope callbacks only, so if you stumble over
a deprecated function with a scope callback, then it should be fixed).


That's kind of intended: the system would inherit safety of the code it
calls. If the user code is not safe, there's no safety guarantee.


The problem is that there are two affected call stacks - the @system API 
function that registers the @system callback, wrapping/casting it as 
@trusted, and the event handler that later on actually calls the 
callback. The latter place is where the hidden violation of the @safe 
guarantees happens.



First, it actually has helped to detect some rather subtle issues in
the past that have gone unnoticed for a long time otherwise.


Being @safe-compatible and provide @safe guarantees are different
issues. The latter follows from the former if user code is @safe and
doesn't follow otherwise.


True, but that goes a bit beside my point. I was just arguing in favor 
of the @safe system in general here, not about this particular instance.





And, maybe more importantly, annotating code as safe is the only way
to guarantee proper bounds checks, which is critical for a server
component.


-boundscheck=on should do it, ldc provides even more control how code is
compiled.


True, but that also imposes this restriction on all user code, while 
just requiring -boundscheck=safeonly would enable dependent packages to 
make a choice (aside from manually sidestepping boundschecks in code).





And finally, I feel that if nobody starts to embrace this on a broader
level now, it will never reach a truly mature state.


Fake @trusted annotations don't count as adoption of safety.
Pedantically speaking @safe loses its purpose if @trusted code is not
verified. Especially if fake @trusted becomes a habit. That's why safety
can't be forced and is opt-in.


I agree with the pedantic statement, but not with the conclusion. Right 
now it's simply not possible in practice to write either fully compiler 
checked code or fully audited trusted code on a large scale. But 
starting to work towards a fully compiler checked code base makes all of 
the missing spots visible, so that there is more pressure to actually 
fix them. I was actually considering to open PRs for each instance, but 
it quickly became clear that it were too many places for me to be able 
to do that in a reasonable time frame (also, @trusted is still necessary 
to support old compiler versions), so that had to be postponed.

Cross-compile with LDC

[Oleg B via Digitalmars-d-learn]

Hello all! I want to build ldc cross compiller. I found this 
instruction  
https://wiki.dlang.org/LDC_cross-compilation_for_ARM_GNU/Linux, 
but I have some doubts: will it works with ldc-1.1.0? 
Particularly interested in the patch 
https://gist.githubusercontent.com/claudemr/3367c13095b15d449b1591eb38d098d9/raw/3517a5db2228e57da9dd8880a82d6bfe6f0e38f1/ldc_1.0.0_gnu_arm. It's for ldc-1.0.0 and sources can be changed.

Maybe somewhere I found patch for ldc-1.1.0?
Maybe someone already build cross ldc for linux x86_64?))

Implementation of B+ trees

[Nestor via Digitalmars-d-learn]

Hi,

Is there a native D implementation of B+ tree anywhere?

So far I have found only std.container.rbtree but I wanted to 
compare both algorithms regarding search performance, memory and 
cpu usage, and storage space required for serialization.


Thanks in advance.

[Issue 17159] New: Behavior of unions at compile time is not documented

[via Digitalmars-d-bugs]

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

  Issue ID: 17159
   Summary: Behavior of unions at compile time is not documented
   Product: D
   Version: D2
  Hardware: All
   URL: https://dlang.org/spec/function.html#interpretation
OS: All
Status: NEW
  Keywords: CTFE, spec
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: dfj1es...@sneakemail.com

E.g. access to overlapped fields is not allowed.

--

Re: CTFE Status

[Kagamin via Digitalmars-d]

On Wednesday, 8 February 2017 at 14:03:13 UTC, Stefan Koch wrote:

generally it takes as much space as the largest member.
Why do you ask ?
And in what context ?


Asking about memory consumption.
I thought it allowed access to overlapped fields, now I see it 
doesn't.

Re: code.dlang.org internal server error

[Sönke Ludwig via Digitalmars-d]

Am 08.02.2017 um 14:29 schrieb singingbush:

On Wednesday, 8 February 2017 at 12:54:00 UTC, John Colvin wrote:

On Wednesday, 8 February 2017 at 05:49:55 UTC, Ali Çehreli wrote:

code.dlang.org gives the following error:

500 - Internal Server Error

Internal Server Error

Ali


Seeing as code.dlang.org is pretty critical these days, it would be
great if there was a better way to handle this than "wait for Sönke to
notice it's down".


I raised github issue in dub repo for this a while back:
https://github.com/dlang/dub/issues/995

It'd be good to have multiple repos and be able to configure dub to use
whichever the user wants to use as with tools like maven or gradle.

For use in my workplace I'd want dub to try getting dependencies from
our own internal dub repo which in turn could look to code.dlang.org for
anything that wouldn't exist internally.


Yes, we need to prioritize this somehow. Having a fallback mirror, 
coupled with dependency upgrade checks that run asynchronously would get 
rid of these issues. It would be great if somebody could find the time 
to tackle one or the other. I personally have an very limited time 
budget for open source at the moment and I need to focus that on vibe.d 
for a bit.


BTW, the server is running again (it ran out of disk space again and I 
need to configure a proactive alert for that).

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Wednesday, 8 February 2017 at 14:01:33 UTC, Kagamin wrote:
Do I understand it right that union at compile time takes space 
equal to the sum of sizes of its members instead of the size of 
the largest member?


generally it takes as much space as the largest member.
Why do you ask ?
And in what context ?

Re: CTFE Status

[Kagamin via Digitalmars-d]

Do I understand it right that union at compile time takes space 
equal to the sum of sizes of its members instead of the size of 
the largest member?

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

Function pointers and other advanced features interfere with the 
ability to cache bytecode I just never noticed because the 
bytecode caching feature was disabled a long time.
Since I do not know how much of it is bitrot I removed it 
alltogether.
This feature will return and be more performant, when the outside 
function-arguments are getting fixed.
When this is done we can also remove a few special cases for the 
interpreter backend which is always good.

Re: code.dlang.org internal server error

[Eugene Wissner via Digitalmars-d]

On Wednesday, 8 February 2017 at 12:54:00 UTC, John Colvin wrote:
On Wednesday, 8 February 2017 at 05:49:55 UTC, Ali Çehreli 
wrote:

code.dlang.org gives the following error:

500 - Internal Server Error

Internal Server Error

Ali


Seeing as code.dlang.org is pretty critical these days, it 
would be great if there was a better way to handle this than 
"wait for Sönke to notice it's down".


or just support git/githab & co. directly from dub.

Re: glibc resolve.h for D

[Seb via Digitalmars-d]

On Wednesday, 8 February 2017 at 12:49:39 UTC, Márcio Martins 
wrote:

Anyone has a binding readily available that I can use?
code.dlang.org is down, so I can't check there - I am in a 
hurry! :)


Use dstep to generate the binding automatically:

https://github.com/jacob-carlborg/dstep

[Issue 17158] New: [404 Not Found]

[via Digitalmars-d-bugs]

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

  Issue ID: 17158
   Summary: [404 Not Found]
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: basti...@veelo.net

The std.concurrencybase link in the side bar of
https://dlang.org/phobos/index.html yields a 404.

--

Re: code.dlang.org internal server error

[singingbush via Digitalmars-d]

On Wednesday, 8 February 2017 at 12:54:00 UTC, John Colvin wrote:
On Wednesday, 8 February 2017 at 05:49:55 UTC, Ali Çehreli 
wrote:

code.dlang.org gives the following error:

500 - Internal Server Error

Internal Server Error

Ali


Seeing as code.dlang.org is pretty critical these days, it 
would be great if there was a better way to handle this than 
"wait for Sönke to notice it's down".


I raised github issue in dub repo for this a while back:
https://github.com/dlang/dub/issues/995

It'd be good to have multiple repos and be able to configure dub 
to use whichever the user wants to use as with tools like maven 
or gradle.


For use in my workplace I'd want dub to try getting dependencies 
from our own internal dub repo which in turn could look to 
code.dlang.org for anything that wouldn't exist internally.

Re: Passing variables, preserving UDAs: A Gripe

[John Colvin via Digitalmars-d]

On Wednesday, 8 February 2017 at 07:57:15 UTC, Timon Gehr wrote:

On 07.02.2017 22:59, Nick Sabalausky wrote:
Suppose I have some code that operates on a variable's value 
and its
UDAs. And I want to refactor that code into a reusable 
function. Sounds

simple enough, right?

So, consider a basic example:


class Foo
{
@("Hello")
string s;
}

void doStuff(alias var)()
{
var = "abc";

import std.traits;
assert(hasUDA!(var, "Hello") == true);
}

void main()
{
@("Hello")
string s;
doStuff!(s);

auto foo = new Foo();
// Error: need 'this' for 'doStuff' of type 'pure nothrow 
@nogc

@safe void()'
doStuff!(foo.s);
}


Note the error. Naturally, that cannot compile, because you 
can't
instantiate a template based on the value of a variable at 
runtime (ie,

based on the value of `foo`).


It actually can compile. (It just doesn't.)
There is no essential difference between the two cases.


How much work is it likely to be to make this happen in dmd? I 
imagine your frontend can do this already, but that's not a 
practical solution even for the medium term.

Re: glibc resolve.h for D

[John Colvin via Digitalmars-d]

On Wednesday, 8 February 2017 at 12:49:39 UTC, Márcio Martins 
wrote:

Anyone has a binding readily available that I can use?
code.dlang.org is down, so I can't check there - I am in a 
hurry! :)


I dont' have one, but if you're in a hurry then copy and port the 
C function/constant defs and port them one-by-one as you need 
them (it's not like you're going to call every single function 
and use every single constant are you?). It's a tiny amount of 
work.


I often write as if I *have* ported the header and then just use 
the compiler errors to fill in the gaps.



P.S. there's no need to port the __res_state struct as afaics 
it's never used directly in the API:


struct __res_state;
alias res_state = __res_state*;

will do fine.

Re: code.dlang.org internal server error

[John Colvin via Digitalmars-d]

On Wednesday, 8 February 2017 at 05:49:55 UTC, Ali Çehreli wrote:

code.dlang.org gives the following error:

500 - Internal Server Error

Internal Server Error

Ali


Seeing as code.dlang.org is pretty critical these days, it would 
be great if there was a better way to handle this than "wait for 
Sönke to notice it's down".

glibc resolve.h for D

[Márcio Martins via Digitalmars-d]

Anyone has a binding readily available that I can use?
code.dlang.org is down, so I can't check there - I am in a hurry! 
:)

Re: Passing variables, preserving UDAs: A Gripe

[Kagamin via Digitalmars-d]

try this:
void main()
{
auto foo = new Foo();
doStuff!(Foo.s);
}

Re: How do I call a C++ struct default constructor from D?

[evilrat via Digitalmars-d-learn]

On Tuesday, 7 February 2017 at 14:26:11 UTC, MGW wrote:

On Tuesday, 7 February 2017 at 13:37:01 UTC, Atila Neves wrote:

Here still example
https://pp.vk.me/c636630/v636630885/46579/neSdIip1ySI.jpg


I'm sorry for being offensive, but...

Of course, and the next step will be pragma mangle on D function 
to map it to correct ctor, then we call malloc(oops, how do we 
know correct class instance size?), then we call placement new 
from C++ RT on malloc'd memory, easy. Oh and then we also should 
call pragma mangled dtor, we do want no mem leaks, right?


Now, sorry for being sarcastic but this is not the way, just 
imagine making all this new wrappers for every ctor manually for 
any serious project like Qt, PhysX, Bullet Physics, or FBX or 
Alembic SDK... Ok, and then we are standing at the point of 
supporting the future releases and changes

Re: Array start index

[Bastiaan Veelo via Digitalmars-d-learn]

Wrapup: I am going to go for the original approach of index 
conversion, and leaving the offset-pointer approach for what it 
is.


Reasons:
1) uncertain efficiency gain/loss,
2) theoretically it may fail,
3) .sizeof does not include the payload,
4) analysis of the assembler generated by our reference compiler 
(Prospero) shows that it also uses index conversion. 
(Interestingly, it does so at compile time, when possible).


Thanks for many interesting insights.

Bastiaan.

Re: code.dlang.org internal server error

[bachmeier via Digitalmars-d]

On Wednesday, 8 February 2017 at 06:35:41 UTC, Eugene Wissner 
wrote:
On Wednesday, 8 February 2017 at 05:49:55 UTC, Ali Çehreli 
wrote:

code.dlang.org gives the following error:

500 - Internal Server Error

Internal Server Error

Ali


code.dlang.org is quite often down with the same errror.


Considering how often others are told to visit that site, this 
will turn into the next Tango/Phobos thing that appears in the 
comments on every D story for the next 10 years.

Re: vibe.d 0.8.0 and 0.7.31 beta releases

[Kagamin via Digitalmars-d-announce]

On Friday, 3 February 2017 at 13:21:18 UTC, Sönke Ludwig wrote:
Keeping the system overloads would break the safety guarantees 
at a relatively deep level and would render the whole effort 
rather useless (this is the case for non-scope callbacks only, 
so if you stumble over a deprecated function with a scope 
callback, then it should be fixed).


That's kind of intended: the system would inherit safety of the 
code it calls. If the user code is not safe, there's no safety 
guarantee.


First, it actually has helped to detect some rather subtle 
issues in the past that have gone unnoticed for a long time 
otherwise.


Being @safe-compatible and provide @safe guarantees are different 
issues. The latter follows from the former if user code is @safe 
and doesn't follow otherwise.


And, maybe more importantly, annotating code as safe is the 
only way to guarantee proper bounds checks, which is critical 
for a server component.


-boundscheck=on should do it, ldc provides even more control how 
code is compiled.


And finally, I feel that if nobody starts to embrace this on a 
broader level now, it will never reach a truly mature state.


Fake @trusted annotations don't count as adoption of safety. 
Pedantically speaking @safe loses its purpose if @trusted code is 
not verified. Especially if fake @trusted becomes a habit. That's 
why safety can't be forced and is opt-in.

[Issue 17157] New: ctRegex.matchAll doesn't set last item in Captures

[via Digitalmars-d-bugs]

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

  Issue ID: 17157
   Summary: ctRegex.matchAll doesn't set last item in Captures
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: criman...@gmail.com

Reproduce code:
int main() 
{
import std.stdio;
import std.regex;

//auto r = ctRegex!"(a)|(b)|(c)|(d)"; /* // <- uncomment to switch to
ctRegex
auto r = regex("(a)|(b)|(c)|(d)"); //*/
auto s = "--a--b--c--d--";

foreach(match; s.matchAll(r))
{
foreach(i; 0..match.length)
write(i,":",match[i]," ");
writeln();
}

return 0;
}

if line 6 commented and regex() is used then output is correct:
0:a 1:a 2: 3: 4: 
0:b 1: 2:b 3: 4: 
0:c 1: 2: 3:c 4: 
0:d 1: 2: 3: 4:d 

if comment at line 6 beginning is removed and ctRegex is used then we have
exception:

core.exception.AssertError@/usr/include/dmd/phobos/std/regex/package.d(565):
wrong match: 1..0

??:? _d_assert_msg [0x4edba6]
??:? std.regex.Captures!(immutable(char)[],
ulong).Captures.opIndex!().opIndexinout(pure nothrow @trusted
inout(immutable(char)[]) function(ulong)) [0x4e4f01]
??:? _Dmain [0x4bb73e]
??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv [0x4ef333]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x4ef25b]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() [0x4ef2d8]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x4ef25b]
??:? _d_run_main [0x4ef1c7]
??:? main [0x4eae0f]
??:? __libc_start_main [0xc012282f]

More experiments have shown: last element of match is not set and attempt to
access it leads to exception. 

Compiler: DMD64 D Compiler v2.073.0
OS: Ubuntu 16.04 LTS

--

Re: Internal error on Wiki page

[Puming via Digitalmars-d]

On Wednesday, 8 February 2017 at 02:19:23 UTC, Ali Çehreli wrote:

On 02/06/2017 06:43 PM, Luís Marques wrote:
This page 
 shows

an error instead of displaying the Wiki content:

[54c97baea4172eeabd69f522] 2017-02-06 13:47:44: Fatal 
exception of type

"Error"




Probably related. Help! :)

code.dlang.org/

500 - Internal Server Error

Internal Server Error

Ali


+1

this is the first time that I realize how important 
code.dlang.org is, I can not do anything now that dub won't 
work

Re: Natural sorted list of files

[Ali Çehreli via Digitalmars-d-learn]

On 02/07/2017 11:47 PM, Dmitry wrote:

On Wednesday, 8 February 2017 at 07:41:29 UTC, Ali Çehreli wrote:

test.naturalSort would sort the array in place before calling writeln
and 'test' would appear naturally sorted as well. I've fixed it like
this:


Great! Thank you!



Well, the title sort is still broken and I can't see my way through it. :-/

Ali

Re: My next D related talk

[Ethan Watson via Digitalmars-d]

On Wednesday, 8 February 2017 at 02:02:27 UTC, extrawurst wrote:

Hey congratz Ethan! By the way will you be at GDC in 3 weeks ?


I won't be at GDC. A few other people from Remedy will be.

[Issue 17156] New: Local function declaration not inferred to be static

[via Digitalmars-d-bugs]

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

  Issue ID: 17156
   Summary: Local function declaration not inferred to be static
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

void f() {
uint function() a = () => 5; // OK

static uint s() { return 5; }
uint function() b =  // ALSO OK

uint g() { return 5; }
uint function() c =  // BOOM! "" is a delegate. why?
}


There should not really be a difference between "s" and "g". The "static" there
should be inferred from lack of any lexical capture.

--

[Issue 16434] dmd assertion failure in declaration.d

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Walter Bright  ---
Can't reproduce it. Please reopen if it can be reproduced in HEAD.

--

Re: Passing variables, preserving UDAs: A Gripe

[Timon Gehr via Digitalmars-d]

On 07.02.2017 22:59, Nick Sabalausky wrote:

Suppose I have some code that operates on a variable's value and its
UDAs. And I want to refactor that code into a reusable function. Sounds
simple enough, right?

So, consider a basic example:


class Foo
{
@("Hello")
string s;
}

void doStuff(alias var)()
{
var = "abc";

import std.traits;
assert(hasUDA!(var, "Hello") == true);
}

void main()
{
@("Hello")
string s;
doStuff!(s);

auto foo = new Foo();
// Error: need 'this' for 'doStuff' of type 'pure nothrow @nogc
@safe void()'
doStuff!(foo.s);
}


Note the error. Naturally, that cannot compile, because you can't
instantiate a template based on the value of a variable at runtime (ie,
based on the value of `foo`).


It actually can compile. (It just doesn't.)
There is no essential difference between the two cases.