How to split a string to a 2D array

[Domain via Digitalmars-d-learn]

I want to convert a string like " a,b1, 23 " to a 
2D array like:

[["a", "b"],
 ["1", "2"],
 ["3", "" ]]


auto html = " a,b1, 23 ";
auto rows = html.strip.chomp("").split("");
string[][] data;
rows.each!(a => data ~= a.split(","));
string[][] result = data.map!(a => a.padRight("", 
data[0].length).map!(b => b.strip)).array;


but the result is not a string[][]:

Error: cannot implicitly convert expression `array(map(data))` of 
type `MapResult!(__lambda2, Result)[]` to `string[][]`

[Issue 18513] Error: module `scripting` is in file 'std/experimental/scripting.d' which cannot be read

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

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

greenify  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greeen...@gmail.com
 Resolution|--- |MOVED

--- Comment #1 from greenify  ---
This looks like it's an issue with the cache. Just modify one character and it
will work:

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

We should probably reduce the cache to just one day for dmd-nightly.
I will close this here as nothing is wrong with Phobos (well in this regard). I
opened:

https://github.com/dlang-tour/core/issues/684


Also note that it will be renamed to std.experimental.all soon:

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

--

Re: Beta 2.079.0

[psychoticRabbit via Digitalmars-d-announce]

On Saturday, 24 February 2018 at 07:09:05 UTC, zabruk70 wrote:

i don't understand whole theread.
why all import must be written on one line?
curent syntax very handy and readable.


you must have understood the thread, cause you summarised it 
pretty well ;-)

Re: Game and GC

[Guillaume Piolat via Digitalmars-d-learn]

On Friday, 23 February 2018 at 01:54:07 UTC, Leonardo wrote:

Hi, I'm new to language and games.
Many people say that GC is bad and can slow down your project 
in some moments.
What can happen if I create a game using D without worrying 
with memory management?

(using full GC)


From my experience a combination of the following is necessary:
- not having the audio thread registered
- using pools aggressively for game entities

Re: Beta 2.079.0

[zabruk70 via Digitalmars-d-announce]

i don't understand whole theread.
why all import must be written on one line?
curent syntax very handy and readable.

Re: Slow code, slow

[Dmitry Olshansky via Digitalmars-d]

On Saturday, 24 February 2018 at 00:21:06 UTC, Andrei 
Alexandrescu wrote:

On 2/23/18 3:15 PM, H. S. Teoh wrote:


tl;dr: A trivial piece of code, written as ostensibly 
"idiomatic D" with.  Makes me cringe every time I hear
"fast code, fast". Our old slogan is a much more accurate 
description of

the current state of things.)


cc Dmitry

Thanks for a solid bug report. The right response here is to 
live into our "fast code, fast" principle. It might be the case 
that the slowdown is actually the negative side of an 
acceleration :o) - before Dmitry's recent work, the sheer act 
of importing std.regex would be slow. Dmitry, do you think you 
could use some precompiled tables to mitigate this?


First things first sombody need to profile compiler while 
compiling this snippet.


My guesswork is that instantiating templates + generating long 
symbols is the problem.


The template system obviously needs some (re)work, I think at a 
time nobody thought templates would be that abundant in D code.


Nowdays it’s easily more templates then normal functions.


Is your caching compiler going to help the matter?


In some distant bright future where it may be finally applied to 
instantiating templates and caching codegen but even then I’m not 
100% positive.


Finally, I repeat - we have not yet identified problem. What 
takes time in the compiler needs to be figured out by disecting 
the time taken via profiler and experimentation.



—
Dmitry Olshansky

Re: How do you get comfortable with Dlang.org's Forum?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/23/2018 11:57 AM, Kagamin wrote:


Bold and italic is a wrong way to format text because it's visual 
formatting that lacks semantic.


Bleh. That's actually my #1 favortie example for how the web world has 
gone completely, utterly insane.


For one thing, bold and italic have *always* carried a semantic meaning 
of "emplasis". That's the whole fucking reason anyone *ever* used bold 
or italic in the first place. (Well, that, and to turn late-90's emails 
and web pages into eye-cancer - which is exactly what happends when you 
treat "bold" and "italic" as instances of "style" instead of "emphasis").


Secondly, when has anybody EVER come up with a legitimate, practical 
application for programatically determining the emphasised portions of a 
sentence? Not even the content-thief sites can make any use out of THAT 
psuedo-"semantic web" clue.

Re: How do you get comfortable with Dlang.org's Forum?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/23/2018 10:18 AM, Steven Schveighoffer wrote:


TB has these, though I prefer plain text. It supports a crude form of 
markdown, so *bold*, _underline_ all are enhanced by TB. Emoticons turn 
into graphics too ;)




I turned those off in my TB installation. I hate having my software 
messing with my content.

Re: How do you get comfortable with Dlang.org's Forum?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/23/2018 11:24 PM, psychoticRabbit wrote:


(in the 90's companies made their name for not being Microsoft. As 
Microsoft wanted to dominate the world. I wonder if that same situation 
exists now, except, now its not being Google).


Oh, it DEFINITELY does. The only difference is that instead of a 
monopoly, it's now an oligopoly of Google/Facebook/Apple each trying to 
pull the same shit MS was famous for running in the 90's, in each of 
their respective domains.

Re: PackedAliasSeq?

[deadalnix via Digitalmars-d]

On Thursday, 22 February 2018 at 19:26:54 UTC, Andrei 
Alexandrescu wrote:
After coding https://github.com/dlang/phobos/pull/6192 with 
AliasSeq, the experience has been quite pleasurable. However, 
in places the AliasSeq tends to expand too eagerly, leading to 
a need to "keep it together" e.g. when you need to pass two of 
those to a template.


I worked around the issue by nesting templates like this:

template Merge(T...)
{
template With(U...)
{
static if (T.length == 0)
alias With = U;
else static if (U.length == 0)
alias With = T;
else static if (T[0] < U[0]
 || T[0] == U[0] && T[1].stringof <= 
U[1].stringof)

alias With =
AliasSeq!(T[0], T[1], Merge!(T[2 .. $]).With!U);
   else
alias With =
AliasSeq!(U[0], U[1], Merge!T.With!(U[2 .. $]));
}
}

So instead of the unworkable Merge!(AliasSeq!(...), 
AliasSeq!(...)), one would write 
Merge!(AliasSeq!(...)).With!(AliasSeq!(...)).


The problem remains for other use cases, so I was thinking of 
adding to std.meta this simple artifact:


template PackedAliasSeq!(T...)
{
alias expand = AliasSeq!T;
}

That way, everything stays together and can be expanded on 
demand.



Andrei


Isn't a packed AliasSeq just a tuple ?

Re: Postgres and other database interfaces

[Erik Smith via Digitalmars-d]

On Saturday, 24 February 2018 at 05:45:45 UTC, rikki cattermole 
wrote:
There is plenty of desire to build a generalized SQL interface 
for Phobos.


But somebody needs to do it and it won't be all that much fun 
to do.


Hi Joe and Rikki,

This is the goal of my dstddb project and I've picked it up again 
after a long hiatus.I do have limited support for a native 
postgres driver and there is plenty of work to do in general, but 
I'm working on it.   I have some type support improvements for 
postgres that will arrive shortly.


erik

Re: How do you get comfortable with Dlang.org's Forum?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 02/23/2018 08:47 AM, biocyberman wrote:


 From my experience with forum platforms like vBulletin, phpBB, Invision 
Power, and even interfaces of Google group, and Github Issues, I still 
find it very difficult to understand the logics of using dlang's forum. 


I really don't see what there is to not understand, for the most part. 
The only real tricky point, really, is just that it's a threaded format 
and the web interface (unfortunately, and mistakenly IMO) insists on 
defaulting to an unthreaded view of an inherently threaded system.


Aside from that though, it's just like any other email or message board 
system:


1. Read the posts in the threads (topics).

2. Hit "reply" on a post.

3. Type your reply.

4. Send.

That's all there is to it: It's nothing fundamentally different from 
anything else that's ever existed (except maybe Google Wave, but, 
well...umm, yea...that was that ;) )


So, how do you guys 
overcome these problems:


=
1. No post editting. After clicking send, and found out that you made 
mistakes in the post, but you can't edit the post anymore.


1. Proofread *before* sending. (Just like any letter or email.)

2. Follow-up post if there's any important corrections (hardly a big deal)

3. Don't be a perfectionist (it's just a forum, not a doctorial thesis.)

2. Old-day quoting presentation. I always feel reluctant to read texts 
that stays after two levels of quotes, like this:

  >First post quoted
  >>Second post quoted
  >>>Third post quoted
  >>Second post quoted




If you mean the angle-bracket syntax: What's the big deal? Surely not 
just that it *isn't* something brand-new, I would hope?


If you mean reading *all* the quoted text: Don't bother. Just skim 
enough to know what it is that's being replied to, then move on the 
actual message.



3. No Rich-text format support. No minimal bold/italic support. Some 
tools to emphasize important points will make it easier to let the 
readers know what the posters want to say.


Anything beyond *doing this* for emphasis is just wasting your time 
futzing with trivialities that don't matter. You probably have better 
things to be doing. It's just a forum, not a journal article.


4.  No code formatting. Same feeling here. I am reluctant to post more 
than 5 lines of code.


Just mark it like anyone else does:

---
code here
---

Or post a link.

5. No image support. In many cases a screenshots will be helpful to 
communicate problems.


Just post a link.

6. Last but not least, a trendy feature: tags, keywords for threads so 
we can locate related threads easily.


That's would be like adding tags to your emails. Waste of bother. This 
is for discussions, it's not really meant as a database.


If I may say it honestly, and despite the useful 'save unsent draft' 
feature, the forum is by far the most user-unfriendly forum platform 
ever (by appearance).


You don't like its appearance? I think the web interface is WAY 
nicer-looking than any phpbb forum or the latest versions of the popular 
webmail clients, but I guess to each his own. But that's one of the nice 
things about it being a newsgroup instead of a web message board: You 
can use whatever interface you want. Personally, I use thunderbird (I 
even get to use a dark theme that way.)


Aside from maybe code formatting, these are all very trivial, 
unimportant features, and I strongly beleive the second half of the 
following is appropriate here (ie, the "Fire and Motion" aka "Covering 
Fire" stuff):

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

Re: Postgres and other database interfaces

[rikki cattermole via Digitalmars-d]

There is plenty of desire to build a generalized SQL interface for Phobos.

But somebody needs to do it and it won't be all that much fun to do.

Postgres and other database interfaces

[Joe via Digitalmars-d]

Back on 13 January, I posted in the Learn forum some questions 
regarding using Postgres and got a reply that stated the 
following:


On Monday, 15 January 2018 at 02:28:29 UTC, Matthias Klumpp wrote:
In any case, please don't start another Postgres library and 
consider contributing to one of the existing ones, so that we 
maybe have one really awesome, 100% complete library at some 
point.


I'm revisiting this because I now have had the chance to look at 
the various libraries and IMHO the "really awesome, 100% complete 
library" depends on the users' goals and their definition of 
awesome and complete.


Aside from ddbc which is like ODBC/JDBC and thus supports 
multiple db's (not my interest), I've found five 
Postgres-specific libraries worthy of further exploration:


1. derelict-pq. This is the most downloaded one and is simply a 
binding over libpq, so AFAICT it's nearly 100% complete. It's 
also well-documented, in part because the Derelict libraries 
provide overall guidance, but mainly because a D user can refer 
directly to the comprehensive libpq documentation and (C) 
examples. The only strange fact is that it's been stuck in a 
beta.3 release for the last five months.


2. dpq2. Second most downloaded and built on top of derelict-pq. 
The "documentation" consists of a README listing the features and 
a single example, which appears to focus on support for JSON/BSON.


3. vibe-d-postgresql. Third most downloaded and built on top of 
dpq2. Docs consist of a single example program.


4. ddb. About the same number of downloads as the above. 
Implemented on top of front/backend protocol. No documentation 
although repository has a folder with two sample programs.


5. dpq. Implements its own wrapper over libpq and has some ORM 
functionality. Docs are a README with example program.


The main issue is that, other than derelict-pq, using any of 
these libraries involves reading the library code and 
understanding the sui generis interfaces implemented by each.


I'm new to the D community, but coming from Python, the contrast 
is significant. First there is the well-documented PEP 249 
(https://www.python.org/dev/peps/pep-0249/) promulgated by the 
Python DB-SIG (and note that 249 is v.2), which led to the 
implementation of psycopg (also well-documented including various 
extensions to the API) and many other adapters to Postgres and 
other databases.


Since I'm new, I don't know if there's any interest in moving in 
such a direction.

[Issue 18515] New: freebsd 11 ships with gcc unable to link 32 bit binaries, dmd uses it by default

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

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

  Issue ID: 18515
   Summary: freebsd 11 ships with gcc unable to link 32 bit
binaries, dmd uses it by default
   Product: D
   Version: D2
  Hardware: x86
OS: FreeBSD
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bra...@puremagic.com

DMD uses 'gcc' to perform the link step.  On freebsd 11 (and likely other
earlier versions, unexplored), gcc -m32 fails to link, looking at 64 bit
library paths instead.

This combination results in freebsd 11 32 non-functional.  Either 'clang' or
'cc' work just fine.  For the auto-testers, they're currently running with CC
set to cc in their environment.  That's not particularly acceptable an out of
the box experience for users of that platform.

IMHO, DMD needs to use 'cc' by default rather than gcc.  Without having double
checked, I suspect that will work on any relatively modern platform without
causing regressions.

--

Re: Template Constraints

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, February 24, 2018 04:33:52 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 04:22:12 UTC, Jonathan M Davis
>
> wrote:
> > Why is there anything dodgy going on and why would you need
> > contracts? Contracts actually tend to go very badly with
> > generic code, because whatever they assert has to be generic,
> > and while that works sometimes, more often than not, it doesn't.
> >
> > - Jonathan M Davis
>
> what if 3.3 is passed to the template, and it explicately casts
> it to an int.
>
> To me, that would be dodgy

It could be exactly how the function is intended to work, since that's how
casting to int works for float. And there's nothing dodgy about a cast from
float to int losing the part of the value to the right of the decimal place.
That's the expected behavior.

> - unless there was a contract, that I
> had accepted and agreed to, so that this not dodgy.

All contracts are are assertions. That's it. There's nothing special about
them. An in contract is used to verify that the function is given valid
data, but there really isn't any accepting or agreeing to a contract.
Rather, it's something that blows up in your face if you give it bad data so
that you can catch bugs. Presumably, the documentation gives the
requirements for the function if it has them, and then an in contract can be
used to verify that the arguments don't violate those requirements, but all
it is is a tool for catching bugs.

And there isn't necesarily anything buggy about casting 3.3 to an int. That
depends entirely on what the code is supposed to be doing.

Now, by having the function simply accept int you avoid the entire question,
because then it's up to the caller to decide how they go about converting to
int, and I'd argue that that's better in general, but there are times when
casting within the function may make more sense.

- Jonathan M Davis

[Issue 18514] New: freebsd 11 with clang fails cpp abi tests

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

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

  Issue ID: 18514
   Summary: freebsd 11 with clang fails cpp abi tests
   Product: D
   Version: D2
  Hardware: x86
OS: FreeBSD
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bra...@puremagic.com

/home/ec2-user/sandbox/at-client/pull-3047185-FreeBSD_32/dmd/generated/freebsd/release/32/dmd
-conf= -m32 -Irunnable   -L-lstdc++  -odgenerated/runnable
-ofgenerated/runnable/cppa_0  runnable/cppa.d generated/runnable/cppb.cpp.o 
generated/runnable/cppa_0
core.exception.AssertError@runnable/cppa.d(259): Assertion failure

??:? _d_assertp [0x285a87ae]
??:? ??? [0x8049b00]
??:? pure nothrow ref @nogc @trusted immutable(char) object.__equals!(char,
immutable(char)).__equals(char[],
immutable(char)[]).at!(immutable(char)).at(immutable(char)[], uint) [0x804b429]
??:? ??? [0x8049b24]
??:? ??? [0x804ab35]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll().__lambda1() [0x285ce20a]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x285ce059]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() [0x285ce174]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0x285ce059]
??:? _d_run_main [0x285cdfbf]
??:? pure nothrow ref @nogc @trusted immutable(char) object.__equals!(char,
immutable(char)).__equals(char[],
immutable(char)[]).at!(immutable(char)).at(immutable(char)[], uint) [0x804acab]
??:? ??? [0x8049518]
??:? ??? [0x80493f7]
??:? ??? [0x0]
i = 1
j = 2
k = 3
i = 1
j = 2
k = 3
i = 1
j = 2
k = 3
this = 0x288d2000
i = 4
j = 5
k = 6
this = 0x28c1e1f0
D.bar: i = 9
D.bar: j = 10
D.bar: k = 11
F.bar: i = 11
F.bar: j = 12
F.bar: k = 13


==
Test failed: expected rc == 0, exited with rc == 1

--

Re: How do you get comfortable with Dlang.org's Forum?

[H. S. Teoh via Digitalmars-d]

On Sat, Feb 24, 2018 at 04:18:29AM +, MattCoder via Digitalmars-d wrote:
> On Friday, 23 February 2018 at 13:47:16 UTC, biocyberman wrote:
> > 1. No post editing...
> 
> You should be grateful for this, because I hate systems like: Forums,
> Reddit and whatever, where people can edit/delete posts changing the
> context of things.
[...]

+1. In the old days, it was called "bait and switch". After people reply
to an initial post, edit it and change it into something else
completely. It was one of the trolls' favorite tools.


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees 
and try again."

Re: Template Constraints

[psychoticRabbit via Digitalmars-d-learn]

On Saturday, 24 February 2018 at 04:22:12 UTC, Jonathan M Davis 
wrote:
Why is there anything dodgy going on and why would you need 
contracts? Contracts actually tend to go very badly with 
generic code, because whatever they assert has to be generic, 
and while that works sometimes, more often than not, it doesn't.


- Jonathan M Davis


what if 3.3 is passed to the template, and it explicately casts 
it to an int.


To me, that would be dodgy - unless there was a contract, that I 
had accepted and agreed to, so that this not dodgy.

Re: Template Constraints

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

On Sat, Feb 24, 2018 at 02:54:13AM +, Jonathan via Digitalmars-d-learn 
wrote:
> I am having trouble finding many useful explanations of using template
> constraints beyond basic usage.
> 
> I would like to have a template constrant to enforce that a type can
> be explicitly cast to another type:
> 
> void (T)(T t)
> if (cast(int) T)//force `cast(int) T` to be possible
> {
> // Yay I know `t` can be cast to an `int`!
> }
> 
> Is this possible?

Yes:

void (T)(T t)
if (is(typeof(cast(int) T.init)))
{
...
}

Explanation:

- is(X) generally means "is X a valid type?". It's the usual way of
  testing whether something is valid, because an invalid expression will
  have no type, and is(X) will return false for it.

- To make use of is(X), generally you want to use typeof to extract the
  type of some test expression.

- T.init is the usual D way of saying "give me an instance of type T",
  because every type has an .init.

- Putting it together, we have our test object T.init, and our test
  expression `cast(int) T.init`, extract the type of that using typeof,
  and use the is(...) operator to test whether that type exists.


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't 
seem to remove the bugs on my system! -- Mike Dresser

Re: How do you get comfortable with Dlang.org's Forum?

[psychoticRabbit via Digitalmars-d]

On Saturday, 24 February 2018 at 04:13:15 UTC, Johannes Loher 
wrote:
There are Browser extensions gor this (e.g. 
https://chrome.google.com/webstore/detail/stylish-custom-themes-for/fjnbnpbmkenffdnngjfgmeleoegfcffe?hl=en)


Hey. thanks for the tip.

though..I just refuse to use chrome ;-)

(in the 90's companies made their name for not being Microsoft. 
As Microsoft wanted to dominate the world. I wonder if that same 
situation exists now, except, now its not being Google).


anyways... a quick search and I discovered something similar for 
firefox.


so I might check that out.

https://addons.mozilla.org/en-US/firefox/addon/stylish/

Re: Template Constraints

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, February 24, 2018 04:13:30 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 03:58:48 UTC, Jonathan M Davis
>
> wrote:
> > Whether an implicit cast or an explicit cast makes more sense
> > depends entirely on what the code is doing, but either way, the
> > conversion needs to be forced inside the function, or you end
> > up with bugs. Far too often, when someone has a template
> > constraint that checks an implicit conversion, the function
> > doesn't actually force the conversion, and that can do anything
> > from resulting in some instantiations not compiling to causing
> > subtle bugs due to the argument being used without being
> > converted. In general, it's actually best to avoid conversions
> > entirely with generic code and force the caller to do the
> > conversion if a conversion is appropriate.
> >
> > But ultimately, what works best depends on what the code is
> > trying to do.
> >
> > - Jonathan M Davis
>
> yeah it's hard to say much more without knowing what the code
> really wants to do..but presumably, you'd want to incorporate
> some contract programming in such a solution too, particulary
> given there's something potentially dodgy going on within such a
> function.

Why is there anything dodgy going on and why would you need contracts?
Contracts actually tend to go very badly with generic code, because whatever
they assert has to be generic, and while that works sometimes, more often
than not, it doesn't.

If you're testing for a conversion in a template constraint, simply forcing
the conversion by assigning it to a variable of the target type (with an
explicit cast if necessary) solves all of the problems related to testing
for a conversion and then writing the code as if the argument were of the
target type rather than a type that converted to the target type.

- Jonathan M Davis

Re: How do you get comfortable with Dlang.org's Forum?

[MattCoder via Digitalmars-d]

On Friday, 23 February 2018 at 13:47:16 UTC, biocyberman wrote:

1. No post editing...


You should be grateful for this, because I hate systems like: 
Forums, Reddit and whatever, where people can edit/delete posts 
changing the context of things.


MattCoder.

Re: How do you get comfortable with Dlang.org's Forum?

[Johannes Loher via Digitalmars-d]

On Saturday, 24 February 2018 at 02:27:27 UTC, psychoticRabbit 
wrote:
On Saturday, 24 February 2018 at 01:53:48 UTC, Ali Çehreli 
wrote:

On 02/23/2018 06:25 AM, psychoticRabbit wrote:

> If there is one change that I would really like, it's dark
theme

I've never needed myself but most browsers allow overriding 
themes.


Ali


yeah..I tried this a while back, but unfortunately it's effect 
is 'global', rather than per site.


i'd also like to see D conf videos go dark theme too ;-)
There are Browser extensions gor this (e.g. 
https://chrome.google.com/webstore/detail/stylish-custom-themes-for/fjnbnpbmkenffdnngjfgmeleoegfcffe?hl=en)

Re: Template Constraints

[psychoticRabbit via Digitalmars-d-learn]

On Saturday, 24 February 2018 at 03:58:48 UTC, Jonathan M Davis 
wrote:


Whether an implicit cast or an explicit cast makes more sense 
depends entirely on what the code is doing, but either way, the 
conversion needs to be forced inside the function, or you end 
up with bugs. Far too often, when someone has a template 
constraint that checks an implicit conversion, the function 
doesn't actually force the conversion, and that can do anything 
from resulting in some instantiations not compiling to causing 
subtle bugs due to the argument being used without being 
converted. In general, it's actually best to avoid conversions 
entirely with generic code and force the caller to do the 
conversion if a conversion is appropriate.


But ultimately, what works best depends on what the code is 
trying to do.


- Jonathan M Davis


yeah it's hard to say much more without knowing what the code 
really wants to do..but presumably, you'd want to incorporate 
some contract programming in such a solution too, particulary 
given there's something potentially dodgy going on within such a 
function.

Re: Template Constraints

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, February 24, 2018 03:48:44 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 03:43:25 UTC, Jonathan M Davis
>
> wrote:
> > That does not do what the OP requested at all. That tests
> > whether T is one of byte, ubyte, short, ushort, int, uint,
> > long, and ulong, whereas what the OP wants is to test whether T
> > can be cast to int.
> >
> > - Jonathan M Davis
>
> yeah. I realised that after I had posted.
>
> I posted a more suitable response after that though (I hope),
> with the intention of leading the OP away from an explicit cast,
> towards an implicit cast.

Whether an implicit cast or an explicit cast makes more sense depends
entirely on what the code is doing, but either way, the conversion needs to
be forced inside the function, or you end up with bugs. Far too often, when
someone has a template constraint that checks an implicit conversion, the
function doesn't actually force the conversion, and that can do anything
from resulting in some instantiations not compiling to causing subtle bugs
due to the argument being used without being converted. In general, it's
actually best to avoid conversions entirely with generic code and force the
caller to do the conversion if a conversion is appropriate.

But ultimately, what works best depends on what the code is trying to do.

- Jonathan M Davis

Re: Template Constraints

[psychoticRabbit via Digitalmars-d-learn]

On Saturday, 24 February 2018 at 03:43:25 UTC, Jonathan M Davis 
wrote:
That does not do what the OP requested at all. That tests 
whether T is one of byte, ubyte, short, ushort, int, uint, 
long, and ulong, whereas what the OP wants is to test whether T 
can be cast to int.


- Jonathan M Davis


yeah. I realised that after I had posted.

I posted a more suitable response after that though (I hope), 
with the intention of leading the OP away from an explicit cast, 
towards an implicit cast.

Re: Template Constraints

[psychoticRabbit via Digitalmars-d-learn]

On Saturday, 24 February 2018 at 03:30:45 UTC, psychoticRabbit 
wrote:

On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using 
template constraints beyond basic usage.


I would like to have a template constrant to enforce that a 
type can be explicitly cast to another type:


void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be 
possible

{
// Yay I know `t` can be cast to an `int`!
}

Is this possible?


import std.traits : isIntegral;
void testTemplate(T)(T x) if (isIntegral!T)
{
writeln(x, " is an integral. yeah!");

}


or this is probably more suitable ;-)

(should you really be using an explicity convert anyway?)

void testTemplate2(T)(T x) if (isImplicitlyConvertible!(T, int))
{
writeln(x, " is implicitly convertible to an int. yeah!");

}

Re: Template Constraints

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, February 24, 2018 03:30:45 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
> > I am having trouble finding many useful explanations of using
> > template constraints beyond basic usage.
> >
> > I would like to have a template constrant to enforce that a
> >
> > type can be explicitly cast to another type:
> > void (T)(T t)
> >
> > if (cast(int) T)//force `cast(int) T` to be possible
> >
> > {
> >
> > // Yay I know `t` can be cast to an `int`!
> >
> > }
> >
> > Is this possible?
>
> import std.traits : isIntegral;
> void testTemplate(T)(T x) if (isIntegral!T)
> {
>  writeln(x, " is an integral. yeah!");
>
> }

That does not do what the OP requested at all. That tests whether T is one
of byte, ubyte, short, ushort, int, uint, long, and ulong, whereas what the
OP wants is to test whether T can be cast to int.

- Jonathan M Davis

Re: Template Constraints

[psychoticRabbit via Digitalmars-d-learn]

On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using 
template constraints beyond basic usage.


I would like to have a template constrant to enforce that a 
type can be explicitly cast to another type:


void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be possible
{
// Yay I know `t` can be cast to an `int`!
}

Is this possible?


import std.traits : isIntegral;
void testTemplate(T)(T x) if (isIntegral!T)
{
writeln(x, " is an integral. yeah!");

}

[Issue 18513] New: Error: module `scripting` is in file 'std/experimental/scripting.d' which cannot be read

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

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

  Issue ID: 18513
   Summary: Error: module `scripting` is in file
'std/experimental/scripting.d' which cannot be read
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

documented unittest fails in
https://dlang.org/phobos-prerelease/std_experimental_scripting.html

onlineapp.d(3): Error: module `scripting` is in file
'std/experimental/scripting.d' which cannot be read
import path[0] = /dlang/dmd-nightly/linux/bin64/../../src/phobos
import path[1] = /dlang/dmd-nightly/linux/bin64/../../src/druntime/import

--

[Issue 18512] auto-tester fails /usr/local/bin/ld: cannot find -lpthread only on FreeBSD_32

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

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m
 OS|Mac OS X|FreeBSD

--

[Issue 18512] New: auto-tester fails /usr/local/bin/ld: cannot find -lpthread only on FreeBSD_32

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

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

  Issue ID: 18512
   Summary: auto-tester fails /usr/local/bin/ld: cannot find
-lpthread only on FreeBSD_32
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

https://auto-tester.puremagic.com/show-run.ghtml?projectid=14=3047114=true


CC="c++"
/home/ec2-user/sandbox/at-client/release-build/install/freebsd/bin32/dmd
-of../generated/freebsd/release/32/dmd -m32 -vtls
-J../generated/freebsd/release/32 -J../res -L-lstdc++ -version=MARS  -w -de -O
-release -inline dmd/access.d dmd/aggregate.d dmd/aliasthis.d dmd/apply.d
dmd/argtypes.d dmd/arrayop.d dmd/arraytypes.d dmd/astcodegen.d dmd/attrib.d
dmd/builtin.d dmd/canthrow.d dmd/cli.d dmd/clone.d dmd/compiler.d dmd/complex.d
dmd/cond.d dmd/constfold.d dmd/cppmangle.d dmd/cppmanglewin.d dmd/ctfeexpr.d
dmd/dcast.d dmd/dclass.d dmd/declaration.d dmd/delegatize.d dmd/denum.d
dmd/dimport.d dmd/dinifile.d dmd/dinterpret.d dmd/dmacro.d dmd/dmangle.d
dmd/dmodule.d dmd/doc.d dmd/dscope.d dmd/dstruct.d dmd/dsymbol.d
dmd/dsymbolsem.d dmd/dtemplate.d dmd/dversion.d dmd/escape.d dmd/expression.d
dmd/expressionsem.d dmd/func.d dmd/hdrgen.d dmd/id.d dmd/impcnvtab.d
dmd/imphint.d dmd/init.d dmd/initsem.d dmd/inline.d dmd/inlinecost.d
dmd/intrange.d dmd/json.d dmd/lambdacomp.d dmd/lib.d dmd/libelf.d dmd/libmach.d
dmd/link.d dmd/mars.d dmd/mtype.d dmd/nogc.d dmd/nspace.d dmd/objc.d
dmd/opover.d dmd/optimize.d dmd/parse.d dmd/permissivevisitor.d dmd/sapply.d
dmd/templateparamsem.d dmd/sideeffect.d dmd/statement.d dmd/staticassert.d
dmd/target.d dmd/typesem.d dmd/traits.d dmd/transitivevisitor.d
dmd/parsetimevisitor.d dmd/visitor.d dmd/typinf.d dmd/utils.d dmd/scanelf.d
dmd/scanmach.d dmd/statement_rewrite_walker.d dmd/statementsem.d
dmd/staticcond.d dmd/safe.d dmd/blockexit.d dmd/printast.d dmd/semantic2.d
dmd/semantic3.d dmd/irstate.d dmd/toctype.d dmd/glue.d dmd/gluelayer.d
dmd/todt.d dmd/tocsym.d dmd/toir.d dmd/dmsc.d dmd/tocvdebug.d dmd/s2ir.d
dmd/toobj.d dmd/e2ir.d dmd/eh.d dmd/iasm.d dmd/objc_glue.d
dmd/backend/bcomplex.d dmd/backend/cc.d dmd/backend/cdef.d dmd/backend/cgcv.d
dmd/backend/code.d dmd/backend/cv4.d dmd/backend/dt.d dmd/backend/el.d
dmd/backend/global.d dmd/backend/obj.d dmd/backend/oper.d dmd/backend/outbuf.d
dmd/backend/rtlsym.d dmd/backend/code_x86.d dmd/backend/iasm.d dmd/backend/ty.d
dmd/backend/type.d dmd/backend/exh.d dmd/backend/mach.d dmd/backend/md5.d
dmd/backend/mscoff.d dmd/backend/dwarf.d dmd/backend/dwarf2.d dmd/backend/xmm.d
dmd/tk/dlist.d dmd/root/aav.d dmd/root/man.d dmd/root/response.d
dmd/root/speller.d ../generated/freebsd/release/32/newdelete.o
../generated/freebsd/release/32/backend.a
../generated/freebsd/release/32/lexer.a
../generated/freebsd/release/32/cxx-unittest
gmake[1]: Leaving directory
'/media/ephemeral0/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/src'
gmake -C src -f posix.mak all
gmake[1]: Entering directory
'/media/ephemeral0/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/src'
no cpu specified, assuming X86
posix.mak:123: == Use HOST_DMD instead of HOST_DC == 
gmake[1]: Nothing to be done for 'all'.
gmake[1]: Leaving directory
'/media/ephemeral0/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/src'
gmake
INSTALL_DIR=/home/ec2-user/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/../install
-C src -f posix.mak install
gmake[1]: Entering directory
'/media/ephemeral0/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/src'
no cpu specified, assuming X86
posix.mak:123: == Use HOST_DMD instead of HOST_DC == 
gmake -C ../docs
DMD=/home/ec2-user/sandbox/at-client/release-build/install/freebsd/bin32/dmd
build
gmake[2]: Entering directory
'/media/ephemeral0/sandbox/at-client/pull-3047114-FreeBSD_32/dmd/docs'
/home/ec2-user/sandbox/at-client/release-build/install/freebsd/bin32/dmd
-I../src -of../generated/freebsd/release/32/gen_man gen_man.d ../src/dmd/cli.d
cp man/man1/obj2asm.1 ../generated/docs/man/man1/obj2asm.1
cp man/man1/dumpobj.1 ../generated/docs/man/man1/dumpobj.1
cp man/man5/dmd.conf.5 ../generated/docs/man/man5/dmd.conf.5
/usr/local/bin/ld: skipping incompatible //usr/lib/libpthread.so when searching
for -lpthread
/usr/local/bin/ld: skipping incompatible //usr/lib/libpthread.a when searching
for -lpthread
/usr/local/bin/ld: cannot find -lpthread
/usr/local/bin/ld: skipping incompatible //usr/lib/libm.so when searching for
-lm
/usr/local/bin/ld: skipping incompatible //usr/lib/libm.a when searching for
-lm
/usr/local/bin/ld: cannot find -lm
/usr/local/bin/ld: skipping incompatible
/usr/local/lib/gcc6/gcc/x86_64-portbld-freebsd11.1/6.4.0/libgcc.a when
searching for -lgcc
/usr/local/bin/ld: skipping incompatible //usr/lib/libgcc.a when searching for
-lgcc
/usr/local/bin/ld: cannot find -lgcc

Re: Template Constraints

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, February 24, 2018 03:04:53 psychoticRabbit via Digitalmars-d-
learn wrote:
> On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
> > I am having trouble finding many useful explanations of using
> > template constraints beyond basic usage.
> >
> > I would like to have a template constrant to enforce that a
> >
> > type can be explicitly cast to another type:
> > void (T)(T t)
> >
> > if (cast(int) T)//force `cast(int) T` to be possible
> >
> > {
> >
> > // Yay I know `t` can be cast to an `int`!
> >
> > }
> >
> > Is this possible?
>
> I would have thought contracts would be ideal here?
>
> https://dlang.org/spec/contracts.html

Contracts are used to assert runtime state, whereas template constraints
control which arguments can be used with the template (including being used
for function overloading).

The OP wants his function template to reject any arguments that can't be
explicitly cast to int, whereas an in contract would be used for something
like verifying at runtime that the argument was within a particular range of
values.

- Jonathan M Davis

Re: Template Constraints

[psychoticRabbit via Digitalmars-d-learn]

On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using 
template constraints beyond basic usage.


I would like to have a template constrant to enforce that a 
type can be explicitly cast to another type:


void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be possible
{
// Yay I know `t` can be cast to an `int`!
}

Is this possible?


I would have thought contracts would be ideal here?

https://dlang.org/spec/contracts.html

Re: Template Constraints

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

On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using 
template constraints beyond basic usage.


The constraint is just like static if as to what it allows 
inside, so you can check almost anything in there.


Like for the cast, you might do

void name(T)(T t) if(__traits(compiles, cast(int) t) {}

just seeing it the cast compiles.

You might also do

if(is(T : int))

which asks if T is implicitly convertible to int. But since you 
want explicit cast, the compiles is prolly the way to go.


is: https://dlang.org/spec/expression.html#IsExpression
compiles: https://dlang.org/spec/traits.html#compiles

Re: Template Constraints

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, February 24, 2018 02:54:13 Jonathan via Digitalmars-d-learn 
wrote:
> I am having trouble finding many useful explanations of using
> template constraints beyond basic usage.
>
> I would like to have a template constrant to enforce that a type
> can be explicitly cast to another type:
>
>  void (T)(T t)
>  if (cast(int) T)//force `cast(int) T` to be possible
>  {
>  // Yay I know `t` can be cast to an `int`!
>  }
>
> Is this possible?

Well, template constraints in general usually either test that the type of
one expression matches another or that a particular piece of code compiles.
So, you'd need to test that the cast compiles. That requires either an is
expression or __traits(compiles, ...) (or an eponymous template that
contains such an expression). In this case, you could probably just do

if(is(typeof(cast(int)t)))

since as long as the result of the expression isn't void, the is expression
will be true.

And note that the expression uses t, not T. You can't cast the type itself.
You have to cast a value of that type.

- Jonathan M Davis

Re: Beta 2.079.0

[psychoticRabbit via Digitalmars-d-announce]

On Friday, 23 February 2018 at 16:03:56 UTC, Aurélien Plazzotta 
wrote:


Perhaps, we could use Backus-Naur notation, as it is already 
widely known into formal documents all over the globe, like the 
following:


import std.stdio, std.whatever{this, that}, std.somethingelse, 
std.grr{wtf};


That is with curly brackets instead of square brackets like you 
suggest :)


Yeah...again.. I'd prefer to not to have to think differently 
about syntax, just for writing imports. That's why I'd prefer to 
just think of them as arrays using D's array like syntax.


import std.stdio [writeln, write = cwrite, writefln], 
std.whatever;


I'm not sufficiently motivated to do anything here anyway, as I 
don't believe a case for change can really be justified - cause 
how many imports can you realistically include on a single line 
anyway?


The current way is just fine, and provides really good clarity 
for what's going on.


But I would (and am) very, very motivated to oppose introduction 
of an obscure, confusing, or foreign syntax.


The real motivator for the change, as i see it, seemed to be 
related to thinking that the imports section was not really for 
human consumption - which it not true at all. The second motivate 
seemed to be related to saving a few keystrokes or line space. 
Again, human consumption should take priority here in my view.


Anyway, the point is moot at this point - since the change is 
being reversed and nobody seems motivated to push it again. Which 
is just fine with me ;-)

Template Constraints

[Jonathan via Digitalmars-d-learn]

I am having trouble finding many useful explanations of using 
template constraints beyond basic usage.


I would like to have a template constrant to enforce that a type 
can be explicitly cast to another type:


void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be possible
{
// Yay I know `t` can be cast to an `int`!
}

Is this possible?

Re: How do you get comfortable with Dlang.org's Forum?

[psychoticRabbit via Digitalmars-d]

On Saturday, 24 February 2018 at 01:53:48 UTC, Ali Çehreli wrote:

On 02/23/2018 06:25 AM, psychoticRabbit wrote:

> If there is one change that I would really like, it's dark
theme

I've never needed myself but most browsers allow overriding 
themes.


Ali


yeah..I tried this a while back, but unfortunately it's effect is 
'global', rather than per site.


i'd also like to see D conf videos go dark theme too ;-)

Re: Slow code, slow

[kdevel via Digitalmars-d]

On Friday, 23 February 2018 at 20:15:12 UTC, H. S. Teoh wrote:

Now that I got your attention:

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


Your bug report is about slowdown in *compilation* time. I 
wondered if the longer compilation time is due to the better 
(faster) generated code. But this is not the case either:


$ ./dotbench
initialized arrays of type double
dot_fast: 279 ms
value = 0
dot_slow: 5413 ms
value = 0
dotProduct: 217 ms
value = 0

Re: How do you get comfortable with Dlang.org's Forum?

[Ali Çehreli via Digitalmars-d]

On 02/23/2018 06:25 AM, psychoticRabbit wrote:

> If there is one change that I would really like, it's dark theme

I've never needed myself but most browsers allow overriding themes.

Ali

Re: How do you get comfortable with Dlang.org's Forum?

[psychoticRabbit via Digitalmars-d]

On Friday, 23 February 2018 at 18:51:45 UTC, Biocyberman wrote:
I think it has much to do with setting expectation right. 
Haven't used dfeed, I had trouble understanding dlang's forum 
but much less trouble with others.


Well... D users will reach a some critical mass, at some point, 
whereby things will certainly change, and the main discussions 
will then be going on elsewhere - cause this whole 'tied to NNTP' 
thing is kinda backwards, for 21st century.


Till then, we have what we have.

As for editing, I've always though a git like change log would be 
great, so you can edit as much as you want, and your editing 
history is there for all to see, so that it can't be abused.


Pictures would be so nice.

Code formatting would be really nice.

Theme's would be nice (I'm fed up with bright white backgrounds!)

Lot's of other stuff that most new comers would expect ...

But all that and more, will only come in some different forum .. 
not this one.

Re: Beta 2.079.0

[psychoticRabbit via Digitalmars-d-announce]

On Friday, 23 February 2018 at 23:46:02 UTC, Norm wrote:

Well, D is already a compiled scripting language :)


technically (and otherwise) that is not correct...thank god!

lets keep it that way.

Re: Slow code, slow

[Rubn via Digitalmars-d]

On Friday, 23 February 2018 at 21:10:25 UTC, H. S. Teoh wrote:
On Fri, Feb 23, 2018 at 08:51:20PM +, Rubn via 
Digitalmars-d wrote: [...]
This slowdown for this specific example isn't cause by 
templates, it's caused by having to parse all the extra lines 
of code from phobos. I didn't say there aren't problems with 
templates, but this example accurately depicts nothing.


I say again, do you have measurements to back up your statement?

Parsing is actually very fast with the DMD front end.  I can't 
believe that it will take half a second to parse a Phobos 
module -- the compiler's parser is not that stupid.  I have a 
1600+ line module that compiles in about 0.4 seconds (that's 
lexing + parsing + semantic + codegen), but that time more than 
doubles when you just change a loop into a range-based 
algorithm.  Clearly, parsing is not the bottleneck here.



T



I did measure it, adding another instigation of the templates 
using a different type adds a fraction of the time. Not another 
0.3 seconds.


I don't know what your so called 1600+ line module is doing, just 
cause it's 1600 lines doesn't mean there won't be the same slow 
down if you don't use part of phobos in all those lines. Then add 
a few lines that do use it, which will incur this slowdown.

Re: Beta 2.079.0

[psychoticRabbit via Digitalmars-d-announce]

On Friday, 23 February 2018 at 18:13:51 UTC, Patrick Schluter 
wrote:
On Friday, 23 February 2018 at 13:42:45 UTC, psychoticRabbit 
wrote:
On Friday, 23 February 2018 at 12:06:23 UTC, Patrick Schluter 
wrote:
Absolutely. D scripting is the trojan horse that enables 
introduction of it in hostile environment. Runnable compiled 
source code is nice.


scripting languages is reinventing computer science.. only 
really badly.


No, scripting languages is about getting shit done...


that's exactly the problem.

we're all to focused on getting 'shit' done ;-)

[Issue 18508] Using statement without effect should error

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #2 from Steven Schveighoffer  ---
It is supposed to be illegal to use the result of a comma expression. See here:
https://dlang.org/spec/expression.html#expression

--

Re: Slow code, slow

[Andrei Alexandrescu via Digitalmars-d]

On 2/23/18 3:15 PM, H. S. Teoh wrote:

Now that I got your attention:

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

tl;dr: A trivial piece of code, written as ostensibly "idiomatic D" with
std.algorithm and std.range templates, compiles *an order of magnitude*
slower than the equivalent hand-written loop.  The way the compiler
compiles templates needs some serious improvement.

(And this is why our current fast-fast-fast slogan annoys me so much.
One can argue that it's misleading advertising, given that what's
considered "idiomatic D", using features like templates and generic code
that's highly-touted as D's strong points, compiles a whole order of
magnitude slower than C-style D.  Makes me cringe every time I hear
"fast code, fast". Our old slogan is a much more accurate description of
the current state of things.)


cc Dmitry

Thanks for a solid bug report. The right response here is to live into 
our "fast code, fast" principle. It might be the case that the slowdown 
is actually the negative side of an acceleration :o) - before Dmitry's 
recent work, the sheer act of importing std.regex would be slow. Dmitry, 
do you think you could use some precompiled tables to mitigate this? Is 
your caching compiler going to help the matter?


Andrei

[Issue 18511] Using std.range / std.algorithm templates cause big slowdown in compilation time

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

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 18504] Assert in synchronized crashes with SIGILL on exit

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

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

Re: Beta 2.079.0

[Norm via Digitalmars-d-announce]

On Friday, 23 February 2018 at 10:48:10 UTC, psychoticRabbit 
wrote:

On Friday, 23 February 2018 at 09:48:33 UTC, Norm wrote:


This import feature and surrounding discussion I couldn't care 
less about ...


I actually spend far more time reading large chunks of code, 
than writing code, and I certainly do NOT want to spend extra 
time deciphering imports, due to an unpopular and confusing 
syntax change.


If I were mainly writing 'scripts', then I too would probably 
not care less ;-)


If D just wants to become a compiled scripting language...good 
luck to it.


I'll go find a proper progamming langauge long before that 
happens.


Well, D is already a compiled scripting language :)

It is also a language used for BSD and Linux kernel drivers, 
applications, backend servers et. al. So you can have your cake 
and eat it too.


Cheers,
Norm

Re: How do you get comfortable with Dlang.org's Forum?

[Jonathan M Davis via Digitalmars-d]

On Friday, February 23, 2018 18:56:29 Biocyberman via Digitalmars-d wrote:
> We may need a survey to have a good overview about users opinions.
>
> Speaking on behalf of myself, after additional inputs from many
> excellent and respectful users in this 'forum'. I can say that, on the
> scale of 1 (least geeky) to 10 (most geeky), I would put forum.dlang.org
> to the level 8 of geekiness required to use the forum. It may be natural
> for long-time users, but for newcomers, it is very challenging.

I don't understand this at all. The web interface is extremely simple.
You're just reading and writing plain text like you would in an e-mail
client that wasn't using html. There aren't complicated controls to learn.
You just read and type. No, you can't format your text in fancy ways using a
rich text interface, but that doesn't make it any harder to read and write
text. And the interface really isn't all that different from your typical
web forum, many of which don't provide any rich text editing capabilities
beyond putting a piece of text in italics or bold.

I'm sorry if the web interface does not fit your vision of a what a web
forum should look like, but I don't understand how you can argue that it's
hard to use. It just lacks some of the fancier features that some other
forum software has. You can choose to use it or not, but plenty of folks use
the web interface with no problems, and they're not all hardcore
programmers.

- Jonathan M Davis

Re: Vibe.d no more using static this() {}

[aberba via Digitalmars-d-learn]

On Friday, 23 February 2018 at 23:11:13 UTC, aberba wrote:
I recently noticed vibe.d now using main loop which call the 
vibe.d event loop. Why that change?


Like:

#!/usr/bin/env dub
/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0"
+/
import vibe.d;

void main()
{
auto settings = new HTTPServerSettings;
settings.port = 8080;

listenHTTP(settings, (req, res) { res.writeBody("Hello 
Vibe.d: " ~ req.path); });

runApplication();
}

Vibe.d no more using static this() {}

[aberba via Digitalmars-d-learn]

I recently noticed vibe.d now using main loop which call the 
vibe.d event loop. Why that change?

[Issue 18508] Using statement without effect should error

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

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #1 from Jonathan M Davis  ---
I'm not sure what is and isn't supposed to be legal with the comma operator
now, but if the issue is that the statement has no effect, then there isn't
necessarily a bug here, because f isn't pure. Yes, _we_ can see that f has no
effect, but the compiler doesn't look past the signature. Now, I slapped pure
on f to see what would happen, and that still doesn't produce an error, so
there probably is a bug if your example has pure on f, but as-is, I'm not sure
that it actually shows a bug.

--

Re: mysql-native v2.1.0-rc1: New features

[aberba via Digitalmars-d-announce]

On Friday, 23 February 2018 at 22:15:37 UTC, Nick Sabalausky 
(Abscissa) wrote:

An all-D MySQL/MariaDB client library:
https://github.com/mysql-d/mysql-native
==

[...]

That's a very useful feature. Will simplify some code.

As well as additional tools for optional micro-management of 
registering/releasing prepared statements.


[...]

Re: How do you get comfortable with Dlang.org's Forum?

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 23, 2018 at 10:01:44PM +, bachmeier via Digitalmars-d wrote:
> On Friday, 23 February 2018 at 17:56:29 UTC, Biocyberman wrote:
> > Speaking on behalf of myself, after additional inputs from many
> > excellent and respectful users in this 'forum'. I can say that, on
> > the scale of 1 (least geeky) to 10 (most geeky), I would put
> > forum.dlang.org to the level 8 of geekiness required to use the
> > forum. It may be natural for long-time users, but for newcomers, it
> > is very challenging.

Hold it right there.

You're saying that it's a bad thing for a *programming language* forum
to have a high geekiness rating?  Implying that *programmers* (y'know,
ostensibly the target audience of said forum) are not geeky enough to
know how to operate a geeky forum?

Whoa.  I think I need to sit down.


> I have to admit that I don't understand this. I don't think it would
> be possible for it to be simpler to use this forum. No registration
> needed, plain text messages, just click "Reply" and type in your
> message. Additional features would make it more complicated.

Well, obviously non-programmers (or should I say, "non-geeky
programmers", whatever that might mean) have every right to be able to
operate a forum dedicated for a programming language without any undue
handicaps, so we have to make concessions on the level of "geekiness"
required to participate in the programming language discussions that
take place here, such that said discussions would be more accessible to
said non-programmers (or "non-geeky" programmers, whoever they may be).

P.S. I think my geekiness-11 brain just blew several fuses and 2
transistors.  Please excuse me while I take a break to go off to the
brain shop to replace them. Maybe I'll pick up an oxymoron compensation
diode on the way as well.


T

-- 
Gone Chopin. Bach in a minuet.

mysql-native v2.1.0-rc1: New features

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

An all-D MySQL/MariaDB client library:
https://github.com/mysql-d/mysql-native
==

Tagged 'v2.1.0-rc1', release candidate for v2.1.0, which mainly adds a 
few new features, inlcuding greatly simplified shortcut syntax for 
prepared statements (with automatic, implicit caching and re-use):


---
int i = 5;
string s = "Hello world";
conn.exec("INSERT INTO table_name VALUES (?, ?)", i, s);
conn.query("SELECT * FROM table_name WHERE id=? AND name=?", i, s);

// Also works:
Prepared stmt = conn.prepare("INSERT ...blah... (?, ?)");
conn.exec(stmt, i, s);
---

As well as additional tools for optional micro-management of 
registering/releasing prepared statements.


Full changelog for this release is in the 'v2.1.x' branch:
https://github.com/mysql-d/mysql-native/blob/v2.1.x/CHANGELOG.md

Final v2.1.0 release is tentatively scheduled for one week from today.

Re: How do you get comfortable with Dlang.org's Forum?

[bachmeier via Digitalmars-d]

On Friday, 23 February 2018 at 17:56:29 UTC, Biocyberman wrote:
Speaking on behalf of myself, after additional inputs from many 
excellent and respectful users in this 'forum'. I can say that, 
on the scale of 1 (least geeky) to 10 (most geeky), I would put 
forum.dlang.org to the level 8 of geekiness required to use the 
forum. It may be natural for long-time users, but for 
newcomers, it is very challenging.


I have to admit that I don't understand this. I don't think it 
would be possible for it to be simpler to use this forum. No 
registration needed, plain text messages, just click "Reply" and 
type in your message. Additional features would make it more 
complicated.

Re: Beta 2.079.0

[Steven Schveighoffer via Digitalmars-d-announce]

On 2/23/18 6:57 AM, Martin Nowak wrote:

On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
17. Allow multiple selective imports from different modules in a 
single import statement


Let me hopefully conclude this discussion :).

We have an existing ambiguity in the language since at least dmd 1.0. 
This is unfortunate but seems costly to remove and minor in impact 
(after learning this behavior).


     import trees, fruits : apple, birds;

A newcomer to D could rightfully conclude that comma is a module 
separator and the following is the correct syntax to import multiple 
symbols.


     import std.stdio, std.conv : to, std.conv : parse;


Maybe I misunderstand the problem here,

birds must be a symbol under fruits in order for it to work (I tested 
it, and this is indeed the case).


Your post seems to suggest that the birds module is imported (as it has 
nothing to do with fruits). Is that what you meant?


In any case, I think we should not delay in discussing the merits of 
this, as Andrei seems to want this update, and we should have plenty of 
time now to discuss it before the 2.080 version.


Embracing that existing ambiguity to support multi-module selective 
imports wasn't well received, partly because it amplifies the ambiguity 
and partly because multi-module imports are frowned upon.


I think the biggest problem really is that the problem it solves is so 
minor compared to the perceived ambiguity. As Andrei pointed out in the 
PR to revert, there really isn't a technical ambiguity. Only one 
possible interpretation makes sense. But to a human, it looks very 
ambiguous.


On the plus side, we've understood that the actual wish for that syntax 
arised from scripting and example contexts, which might be better 
addressed by 
https://dlang.org/changelog/2.079.0.html#std-experimental-scripting, 
lazy import resolution by the compiler or a library, or automatic 
imports (https://github.com/CyberShadow/AutoFix).


Yes, I think globbing together imports in one spot makes scripting and 
toy examples far easier to write. I'm reminded of my days at topcoder, 
when everyone had their "library" that just had all their proper imports 
and shorthand typedefs for things allowing them to code much faster 
during competitions.


Furthermore there remain various ideas that would avoid the original 
ambiguity. Whether such changes are worthwhile is up for discussion and 
would benefit from someone taking the lead.


TBH, I'm somewhat opposed to mucking with import syntax. Seeing some of 
the examples of "all on one line" imports, it just looks so hard to 
parse through, I'd rather not worry about saving the keystrokes and line 
space.




I still think that local imports are nice for being explicit and 
toolable but have the downside of being brittle.

Something like bash style expansion could help to hit a sweet spot IMHO.

     import std.{algorithm : {find, findSplit}, stdio : writeln};
     import std.experimental.allocator.building_blocks.{free_list, region};


For comparison:

import std.algorithm: find, findSplit;
import std.stdio : writeln;
import std.experimental.allocator.building_blocks.free_list;
import std.experimental.allocator.building_blocks.region;

I don't find the latter extra verbose (except std.experimental, but that 
should go away eventually). When you list all the modules in order, it's 
easy to visually parse and see the differences.


Perhaps a mechanism to specify submodules in a common large package may 
be useful.


Given the effort required for a language change, it's seductive to 
streamline seemingly small changes, but it certainly increases the risk 
of design mistakes, thanks for appealing against this one.


And thanks for understanding the response and acting on it.

-Steve

Re: Slow code, slow

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 23, 2018 at 08:51:20PM +, Rubn via Digitalmars-d wrote:
[...]
> This slowdown for this specific example isn't cause by templates, it's
> caused by having to parse all the extra lines of code from phobos. I
> didn't say there aren't problems with templates, but this example
> accurately depicts nothing.

I say again, do you have measurements to back up your statement?

Parsing is actually very fast with the DMD front end.  I can't believe
that it will take half a second to parse a Phobos module -- the
compiler's parser is not that stupid.  I have a 1600+ line module that
compiles in about 0.4 seconds (that's lexing + parsing + semantic +
codegen), but that time more than doubles when you just change a loop
into a range-based algorithm.  Clearly, parsing is not the bottleneck
here.


T

-- 
Unix is my IDE. -- Justin Whear

Re: Slow code, slow

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 23, 2018 at 08:41:17PM +, bauss via Digitalmars-d wrote:
[...]
> It actually matters a lot for big projects with lots of templates,
> especially nested templates. Gets a whole lot worse when it's
> templates within mixin templates with templates.

The situation has actually improved somewhat after Rainer's symbol
backreferencing PR was merged late last year. Before that, deeply nested
templates were spending most of their time generating, scanning, and
writing out 20MB-long symbols. :-D

Now that superlong symbols are no longer the bottleneck, though, other
issues with the implementation of templates are coming to the surface.
Like this one, where it takes *3 seconds* to compile a program
containing a *single* (trivial) regex:

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


> It's not just a "0.3" second difference, but can be half a minute or
> even more.

In the old days, when yours truly submitted a naïve implementation of
cartesianProduct to Phobos, compiling Phobos unittests would cause the
autotester to freeze for a long time and then die with an OOM, because
using cartesianProduct with multiple arguments caused an exponential
number of templates to get instantiated. :-D

Over the years there have also been a number of PRs that try to mitigate
the problem somewhat by, e.g., replacing a linearly-recursive template
(usually tail-recursive -- but the compiler currently does not take
advantage of that) with a divide-and-conquer scheme instead. A lot of
stuff that iterates over AliasSeq suffers from this problem, actually.
AIUI, due to the way templates are currently implemented, a
linearly-recursive template causes quadratic slowdown in compilation
time.  Clearly, the quality of implementation needs improvement here.


T

-- 
Once bitten, twice cry...

Re: Slow code, slow

[Rubn via Digitalmars-d]

On Friday, 23 February 2018 at 20:52:47 UTC, H. S. Teoh wrote:
On Fri, Feb 23, 2018 at 08:35:44PM +, Rubn via 
Digitalmars-d wrote: [...]
It's not that big of a slow down. Using "fast" you don't 
import any modules so they never have to be parsed. That's 
pretty much all of phobos you don't have to parse in that 
example. That's just the initial cost too. In a big project 
this won't make a difference.


Wrong.  This code was reduced from a bigger module (1600+ lines 
of code) containing the offending function.  If I write that 
function with a straight loop, the entire module compiles in 
about 0.4 seconds.  If I change that function to use Phobos 
algorithms, the compilation time slows down to more than 1 
second.


I don't know what else you are doing, but if you aren't using 
phobos or any of it's functions in there other than those few 
lines of code. Then yah you'll get the same result.


You create a tiny example that is irrelevant to the larger 
scale, that takes 0.3 seconds longer to compile.  It's a 
magnitude slower cause in your fast example it's literately 
only parsing 5 lines of code instead of hundreds of lines like 
it is in your slow example.


Please measure before you make statements like that.  You're 
assuming I wrote that example out of thin air, but it's 
actually code reduced from a larger module where changing a 
single function more than doubles the compilation time of the 
*entire module*.  Parsing is actually extremely fast, esp. with 
the DMD front end.  The slowdown is caused by the way the 
compiler handles templates (and possibly the way Phobos uses 
exponential templates in some places).


And this is only a smaller example of a single module.  I do 
have code across multiple modules that take horrendously long 
to compile because of heavy template use.



T


I did measure it, adding another instigation of the templates 
using a different type adds a fraction of the time. Not another 
0.3 seconds.

[Issue 17961] std.uni does not compile with -unittest -dip1000

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

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

Carsten Blüggel  changed:

   What|Removed |Added

   Assignee|chi...@posteo.net   |nob...@puremagic.com

--

Re: Slow code, slow

[Rubn via Digitalmars-d]

On Friday, 23 February 2018 at 20:41:17 UTC, bauss wrote:

On Friday, 23 February 2018 at 20:35:44 UTC, Rubn wrote:

On Friday, 23 February 2018 at 20:15:12 UTC, H. S. Teoh wrote:

Now that I got your attention:

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

tl;dr: A trivial piece of code, written as ostensibly 
"idiomatic D" with std.algorithm and std.range templates, 
compiles *an order of magnitude* slower than the equivalent 
hand-written loop.  The way the compiler compiles templates 
needs some serious improvement.


(And this is why our current fast-fast-fast slogan annoys me 
so much. One can argue that it's misleading advertising, 
given that what's considered "idiomatic D", using features 
like templates and generic code that's highly-touted as D's 
strong points, compiles a whole order of magnitude slower 
than C-style D.  Makes me cringe every time I hear "fast 
code, fast". Our old slogan is a much more accurate 
description of the current state of things.)



T


It's not that big of a slow down. Using "fast" you don't 
import any modules so they never have to be parsed. That's 
pretty much all of phobos you don't have to parse in that 
example. That's just the initial cost too. In a big project 
this won't make a difference. You create a tiny example that 
is irrelevant to the larger scale, that takes 0.3 seconds 
longer to compile. It's a magnitude slower cause in your fast 
example it's literately only parsing 5 lines of code instead 
of hundreds of lines like it is in your slow example.


I disagree.

It actually matters a lot for big projects with lots of 
templates, especially nested templates. Gets a whole lot worse 
when it's templates within mixin templates with templates.


It's not just a "0.3" second difference, but can be half a 
minute or even more.


Like with anything, since you can now basically run code at 
compile time, you are going to have to make optimizations to your 
code. If you make a million template instances, well a compiler 
isn't going to magically be able to make that fast. This slowdown 
for this specific example isn't cause by templates, it's caused 
by having to parse all the extra lines of code from phobos. I 
didn't say there aren't problems with templates, but this example 
accurately depicts nothing.

[Issue 18510] [Beta 2.079] lld-link.exe fails to open obj file in subpath

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

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

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Rainer Schuetze  ---
https://github.com/dlang/dmd/pull/7946

--

Re: Slow code, slow

[H. S. Teoh via Digitalmars-d]

On Fri, Feb 23, 2018 at 08:35:44PM +, Rubn via Digitalmars-d wrote:
[...]
> It's not that big of a slow down. Using "fast" you don't import any modules
> so they never have to be parsed. That's pretty much all of phobos you don't
> have to parse in that example. That's just the initial cost too. In a big
> project this won't make a difference.

Wrong.  This code was reduced from a bigger module (1600+ lines of code)
containing the offending function.  If I write that function with a
straight loop, the entire module compiles in about 0.4 seconds.  If I
change that function to use Phobos algorithms, the compilation time
slows down to more than 1 second.


> You create a tiny example that is irrelevant to the larger scale, that
> takes 0.3 seconds longer to compile.  It's a magnitude slower cause in
> your fast example it's literately only parsing 5 lines of code instead
> of hundreds of lines like it is in your slow example.

Please measure before you make statements like that.  You're assuming I
wrote that example out of thin air, but it's actually code reduced from
a larger module where changing a single function more than doubles the
compilation time of the *entire module*.  Parsing is actually extremely
fast, esp. with the DMD front end.  The slowdown is caused by the way
the compiler handles templates (and possibly the way Phobos uses
exponential templates in some places).

And this is only a smaller example of a single module.  I do have code
across multiple modules that take horrendously long to compile because
of heavy template use.


T

-- 
If blunt statements had a point, they wouldn't be blunt...

Re: Slow code, slow

[bauss via Digitalmars-d]

On Friday, 23 February 2018 at 20:35:44 UTC, Rubn wrote:

On Friday, 23 February 2018 at 20:15:12 UTC, H. S. Teoh wrote:

Now that I got your attention:

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

tl;dr: A trivial piece of code, written as ostensibly 
"idiomatic D" with std.algorithm and std.range templates, 
compiles *an order of magnitude* slower than the equivalent 
hand-written loop.  The way the compiler compiles templates 
needs some serious improvement.


(And this is why our current fast-fast-fast slogan annoys me 
so much. One can argue that it's misleading advertising, given 
that what's considered "idiomatic D", using features like 
templates and generic code that's highly-touted as D's strong 
points, compiles a whole order of magnitude slower than 
C-style D.  Makes me cringe every time I hear "fast code, 
fast". Our old slogan is a much more accurate description of 
the current state of things.)



T


It's not that big of a slow down. Using "fast" you don't import 
any modules so they never have to be parsed. That's pretty much 
all of phobos you don't have to parse in that example. That's 
just the initial cost too. In a big project this won't make a 
difference. You create a tiny example that is irrelevant to the 
larger scale, that takes 0.3 seconds longer to compile. It's a 
magnitude slower cause in your fast example it's literately 
only parsing 5 lines of code instead of hundreds of lines like 
it is in your slow example.


I disagree.

It actually matters a lot for big projects with lots of 
templates, especially nested templates. Gets a whole lot worse 
when it's templates within mixin templates with templates.


It's not just a "0.3" second difference, but can be half a minute 
or even more.

Re: Slow code, slow

[Rubn via Digitalmars-d]

On Friday, 23 February 2018 at 20:15:12 UTC, H. S. Teoh wrote:

Now that I got your attention:

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

tl;dr: A trivial piece of code, written as ostensibly 
"idiomatic D" with std.algorithm and std.range templates, 
compiles *an order of magnitude* slower than the equivalent 
hand-written loop.  The way the compiler compiles templates 
needs some serious improvement.


(And this is why our current fast-fast-fast slogan annoys me so 
much. One can argue that it's misleading advertising, given 
that what's considered "idiomatic D", using features like 
templates and generic code that's highly-touted as D's strong 
points, compiles a whole order of magnitude slower than C-style 
D.  Makes me cringe every time I hear "fast code, fast". Our 
old slogan is a much more accurate description of the current 
state of things.)



T


It's not that big of a slow down. Using "fast" you don't import 
any modules so they never have to be parsed. That's pretty much 
all of phobos you don't have to parse in that example. That's 
just the initial cost too. In a big project this won't make a 
difference. You create a tiny example that is irrelevant to the 
larger scale, that takes 0.3 seconds longer to compile. It's a 
magnitude slower cause in your fast example it's literately only 
parsing 5 lines of code instead of hundreds of lines like it is 
in your slow example.

Slow code, slow

[H. S. Teoh via Digitalmars-d]

Now that I got your attention:

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

tl;dr: A trivial piece of code, written as ostensibly "idiomatic D" with
std.algorithm and std.range templates, compiles *an order of magnitude*
slower than the equivalent hand-written loop.  The way the compiler
compiles templates needs some serious improvement.

(And this is why our current fast-fast-fast slogan annoys me so much.
One can argue that it's misleading advertising, given that what's
considered "idiomatic D", using features like templates and generic code
that's highly-touted as D's strong points, compiles a whole order of
magnitude slower than C-style D.  Makes me cringe every time I hear
"fast code, fast". Our old slogan is a much more accurate description of
the current state of things.)


T

-- 
Don't throw out the baby with the bathwater. Use your hands...

Re: Typedef.toString?

[Denis F via Digitalmars-d]

On Friday, 23 February 2018 at 15:26:02 UTC, Meta wrote:

On Friday, 23 February 2018 at 13:56:35 UTC, Denis F wrote:

On Thursday, 22 February 2018 at 20:26:17 UTC, Meta wrote:

find all this inclusions.  Maybe it is need to implement 
simple toString method inside of Typedef struct? Or just 
disable it at all?


Yes. I doubt this behaviour is intended, so it's likely an 
oversight in Typedef's implementation.


Should be disabled also:

factory
opCmp
opEquals
toHash

?


No, Typedef just needs a custom implementation of `toString`.


I lean towards the idea to disable toString at all. Because if we 
wrap string type into it, string can leave Typedef wrapper 
unhindered.

[Issue 17819] static foreach segfaults on __traits(allMembers)

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

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

--- Comment #2 from Jean-Louis Leroy  ---
Still present in v2.078.3 - it seems that no one is looking into this.

--

[Issue 18511] Using std.range / std.algorithm templates cause big slowdown in compilation time

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

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

--- Comment #1 from hst...@quickfur.ath.cx ---
Sorry, missed the command for compiling the slow version:

time dmd -c -version=slow test.d

--

[Issue 18511] New: Using std.range / std.algorithm templates cause big slowdown in compilation time

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

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

  Issue ID: 18511
   Summary: Using std.range / std.algorithm templates cause big
slowdown in compilation time
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Code:
--
double dot(double[] a, double[] b) {
version(fast) {
assert(a.length == b.length);
double acc = 0.0;
foreach (i; 0 .. a.length)
acc += a[i] * b[i];
return acc;
}
version (slow) {
import std.range : zip;
import std.algorithm.iteration : fold, map;

return zip(a[], b[])
.map!(x => x[0]*x[1])
.fold!((a, b) => a + b)(0.0);
}
}
--

Compiling with manually-written loop:
--
$ time dmd -c -version=fast test.d
real0m0.021s
user0m0.014s
sys 0m0.007s
--

Compiling with fancy std.algorithm / std.range templates:
--
real0m0.499s
user0m0.444s
sys 0m0.054s
--

Now, I understand that using fancy generic code templates requires more work on
the part of the compiler, so some degree of slowdown in compilation times is to
be expected.

However, this is an *order of magnitude* slowdown in compiling two
functionally-equivalent pieces of code, and very simple code at that.  Given
our current fast-fast-fast slogan, I think this is unacceptable.

--

[Issue 18510] [Beta 2.079] lld-link.exe fails to open obj file in subpath

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

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

--- Comment #1 from Rainer Schuetze  ---
Not automatically appending the ".obj" seems to be an incompatibility with the
MS linker.

--

[Issue 18509] [Beta 2.079] lld-link.exe needs msvcp140.dll

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

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

--- Comment #3 from ki...@gmx.net ---
(In reply to Rainer Schuetze from comment #1)
> I think we should link lld-link.exe statically against the VC/C++ libraries.

I agree; CMake option LLVM_USE_CRT_RELEASE=MT (assuming
CMAKE_BUILD_TYPE=Release).

> I suspect LLVM does not build with anything before VC2015 because latest C++
> is used.

Yep, from https://llvm.org/docs/GettingStartedVS.html:
"You will need Visual Studio 2015 or higher, with the latest Update installed."

--

[Issue 18509] [Beta 2.079] lld-link.exe needs msvcp140.dll

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

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

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Rainer Schuetze  ---
https://github.com/dlang/installer/pull/305

--

Re: lld-link.exe [in: Re: Beta 2.079.0]

[Andre Pany via Digitalmars-d-announce]

On Friday, 23 February 2018 at 19:06:42 UTC, Martin Nowak wrote:

On Friday, 23 February 2018 at 18:13:01 UTC, Martin Nowak wrote:

On Monday, 19 February 2018 at 20:17:05 UTC, Andre Pany wrote:

You also need to install VC++ 2015 redistributable to run 
lld-link.exe.


The x86 one btw.

Also [18510 – [Beta 2.079] lld-link.exe fails to open obj file 
in subpath](https://issues.dlang.org/show_bug.cgi?id=18510) so 
it doesn't work with dub and likely fails for more complex 
applications.


Thanks a lot for the info. I will give it a try.

Kind regards
Andre

Re: lld-link.exe [in: Re: Beta 2.079.0]

[Martin Nowak via Digitalmars-d-announce]

On Friday, 23 February 2018 at 18:13:01 UTC, Martin Nowak wrote:

On Monday, 19 February 2018 at 20:17:05 UTC, Andre Pany wrote:

You also need to install VC++ 2015 redistributable to run 
lld-link.exe.


The x86 one btw.

Also [18510 – [Beta 2.079] lld-link.exe fails to open obj file in 
subpath](https://issues.dlang.org/show_bug.cgi?id=18510) so it 
doesn't work with dub and likely fails for more complex 
applications.

Re: How do you get comfortable with Dlang.org's Forum?

[Biocyberman via Digitalmars-d]

Kagamin wrote:

On Friday, 23 February 2018 at 13:47:16 UTC, biocyberman wrote:
From my experience with forum platforms like vBulletin, phpBB, 
Invision Power, and even interfaces of Google group, and Github 
Issues, I still find it very difficult to understand the logics of 
using dlang's forum.


You make it sound like "I even learned clay tablets" :)
Sorry that it kicked in that way. I didn't mean I know all from modern 
to ancient if that is what you mean with 'learning clay tablets'. But I 
did mean that even with quite some experience, I still find it 
challenging to use the forum. I gave example of an typical forum 
interface to a less typical one. dlang's forum is not anywhere on this 
scale, in my opinion.




1. No post editting. After clicking send, and found out that you made 
mistakes in the post, but you can't edit the post anymore.


Stackoverflow has this feature, and it's pretty popular on forums too, 
because when someone abuses editing, people complain that discussions 
make no sense anymore.


I mean to edit a post right after posting. stackoverflow and many other 
forums have 5 minutes or more before they lock editing. Only comments on 
stackoverflow are locked by the way.


2. Old-day quoting presentation. I always feel reluctant to read texts 
that stays after two levels of quotes, like this:

 >First post quoted
 >>Second post quoted
 >>>Third post quoted
 >>Second post quoted


Stackoverflow and github have this feature. Though normally web 
interface hides the angle quotes, so they shouldn't interfere with reading.



I mean, the angle quotes are the problem.


3. No Rich-text format support. No minimal bold/italic support.
 Some tools to emphasize important points will make it easier to let 
the readers know what the posters want to say.


Bold and italic is a wrong way to format text because it's visual 
formatting that lacks semantic. You can use markdown to add *emphasis*, 
it's pretty intuitive, stackoverflow and github have it too. Emphasis 
only expresses emotions, which can actually distract from content, you 
better spend time expressing ideas.


I appreciate your preference on this. And I agree with out if it is some 
sort of formal writing. In short and informal one, it is a way to give 
visual cues.


4.  No code formatting. Same feeling here. I am reluctant to post more 
than 5 lines of code.


run.dlang.org


I will use this from now on.

5. No image support. In many cases a screenshots will be helpful to 
communicate problems.


abload.de
I am aware of third party sites to upload image, but I meant a built-in 
and in-place image display.


6. Last but not least, a trendy feature: tags, keywords for threads so 
we can locate related threads easily.


Usually nobody bothers to fill them, so they won't give you any result.

I do fill them for every question post on stackoverflow. And I find them 
very helpful.


If I may say it honestly, and despite the useful 'save unsent draft' 
feature, the forum is by far the most user-unfriendly forum platform 
ever (by appearance).


If I were to order them by user-friendliness (in descending order):
dfeed > forums >>> github > stackoverflow > skype
I think it has much to do with setting expectation right. Haven't used 
dfeed, I had trouble understanding dlang's forum but much less trouble 
with others.

[Issue 18510] New: [Beta 2.079] lld-link.exe fails to open obj file in subpath

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

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

  Issue ID: 18510
   Summary: [Beta 2.079] lld-link.exe fails to open obj file in
subpath
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: major
  Priority: P2
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu
CC: r.sagita...@gmx.de

C:\>C:\D\dmd2\windows\bin\dmd.exe -ofdub.exe sub\dub.obj -m32mscoff -v
predefs   DigitalMars Windows LittleEndian D_Version2 all D_InlineAsm
D_InlineAs
m_X86 X86 Win32 CRuntime_Microsoft assert D_HardFloat
binaryC:\D\dmd2\windows\bin\dmd.exe
version   v2.079.0-beta.1

configC:\D\dmd2\windows\bin\sc.ini
DFLAGS-IC:\D\dmd2\windows\bin\..\..\src\phobos
-IC:\D\dmd2\windows\bin\..\..\src\druntime\import
C:\D\dmd2\windows\bin\lld-link.exe /NOLOGO "sub\dub" /OUT:"dub.exe"  /OPT:NOICF
C:\D\dmd2\windows\bin\lld-link.exe: error: could not open sub\dub: no such file
or directory
C:\D\dmd2\windows\bin\lld-link.exe: warning: /machine is not specified. x64 is
assumed
error: entry point must be defined
Error: linker exited with status 1



Weirdly the .obj suffix is stripped from the command line, might be a leftover
from optlink.

--

[Issue 18509] [Beta 2.079] lld-link.exe needs msvcp140.dll

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

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

--- Comment #1 from Rainer Schuetze  ---
I think we should link lld-link.exe statically against the VC/C++ libraries. I
suspect LLVM does not build with anything before VC2015 because latest C++ is
used.

I chose VC2010 in the hope that it is already installed on most systems, though
plain Windows doesn't seem to have it.

The runtimes for VC2015 or later are a bit messy as they rely on the UCRT
aswell. It is a bit of a hassle to install these on Win7 or earlier.

--

[Issue 18385] [REG 2.079] method cannot be overloaded with another extern(C) method

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

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

Jesse Phillips  changed:

   What|Removed |Added

 CC||jesse.k.phillip...@gmail.co
   ||m

--- Comment #7 from Jesse Phillips  ---
So C clearly doesn't support function overloads, but D provides for better type
checking and generally expects as much.

I think it would be nice to allow D to specify function overloads if the C call
is ultimately the same (parameter sizes and such).

This way in D a function can be specified to accept pointer types of A, B, and
C rather than needing to be a void* as it is defined in C. I think it is
similar to marking a parameter const even though it has no meaning to C and
isn't actually enforced. This also appears to be how DWT has utilized
definitions.

I've realized that my upgrade to dxml and DWT for an application has cause my
application to not compile on any of the D compilers, so a solution here would
be nice or for [18475] to be fixed on 2.078.

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

--

Re: Help using lubeck on Windows

[Ilya Yaroshenko via Digitalmars-d-learn]

On Friday, 23 February 2018 at 12:13:11 UTC, Arredondo wrote:

Help using lubeck on Windows

I'd like to experiment with linear algebra in D, and it looks 
like lubeck is the way to do it right now. However, I'm having 
a hard time dealing with the CBLAS and LAPACK dependencies.


I downloaded the OpenBLAS binaries for Windows 
(libopenblas.dll), but I am cluless as to what to do with them. 
I can't find an example of how to link them/what commands to 
pass to dmd. Any help deeply appreciated.


openblas.net contains precompiled openblas library for Windows. 
It may not be optimised well for exactly your CPU but it is fast 
enought to start. Put the library files into your prodject and 
add openblas library to your project dub configuration. A .dll 
files are dinamic, you need also a .lib /.a to link with.


OpenBLAS contains both cblas and lapack api by default.

We defenetely need to add an example for Windows

Best
Ilya

lld-link.exe [in: Re: Beta 2.079.0]

[Martin Nowak via Digitalmars-d-announce]

On Monday, 19 February 2018 at 20:17:05 UTC, Andre Pany wrote:

You also need to install VC++ 2015 redistributable to run 
lld-link.exe. Let's see if we can lift that requirement until the 
release.
[18509 – [Beta 2.079] lld-link.exe needs 
msvcp140.dll](https://issues.dlang.org/show_bug.cgi?id=18509)

Re: Beta 2.079.0

[Patrick Schluter via Digitalmars-d-announce]

On Friday, 23 February 2018 at 13:42:45 UTC, psychoticRabbit 
wrote:
On Friday, 23 February 2018 at 12:06:23 UTC, Patrick Schluter 
wrote:
Absolutely. D scripting is the trojan horse that enables 
introduction of it in hostile environment. Runnable compiled 
source code is nice.


scripting languages is reinventing computer science.. only 
really badly.


No, scripting languages is about getting shit done...

d.godbolt.org now supports DMD

[Seb via Digitalmars-d-announce]

Thanks to the work of Rabs Rincon [1] DMD is now supported on 
https://d.godbolt.org


A simple example of comparing DMD's object code with LDC's + 
GDC's output:


https://godbolt.org/g/EQCTNy

[1] https://github.com/mattgodbolt/compiler-explorer/issues/306

[Issue 18509] New: [Beta 2.079] lld-link.exe needs msvcp140.dll

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

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

  Issue ID: 18509
   Summary: [Beta 2.079] lld-link.exe needs msvcp140.dll
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P2
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu
CC: r.sagita...@gmx.de

While we're installing the VC++ 2010 redisditributable, we've apparently linked
lld-link.exe against VC++ 2015 or so.
I just deinstalled all MSVC++ redistributables prior to trying the installer
with the new MinGW option.
Seems like we have a couple of options:

- compile lld-link.exe with VC++ 2010 if that still works (could possibly break
depending on lld codebase)
- use VC++ 2015 redist as C runtime (requires some changes in the mingw build
script and possibly the msvcrt stub)
(https://github.com/dlang/installer/pull/289)
- install both redistributables with the MinGW option
- ship msvcp140.dll with lld-link.exe
(https://msdn.microsoft.com/en-us/library/dd293574.aspx#Anchor_1)
- link lld-link.exe statically against MSVCRT

Any opionion?
Why was 2010 choosen as redistributable? It feels weird to install such an old
C runtime.
IIRC there was some point about msvcrt100.dll being preinstalled on all Windows
versions, that would be a plus for distributing D apps.
But I'm not sure how relevant that is and why the installer requires me to
install a redistributable VC++ 2010 regardless.

--

Re: Tuts/Aritcles: Incrementasl C++-to-D conversion?

[Kagamin via Digitalmars-d-learn]

On Thursday, 22 February 2018 at 04:16:44 UTC, Nick Sabalausky 
(Abscissa) wrote:
Are there any tutorials or articles out there for "getting 
started with converting a C++ codebase to D one module at a 
time?" Or at the very least: tips, tricks, lessions learned, 
from those who have come before.


AFAIK, visuald has a tool that just translated C++ to D 
https://github.com/dlang/visuald/tree/master/c2d

Re: How do you get comfortable with Dlang.org's Forum?

[Biocyberman via Digitalmars-d]

We may need a survey to have a good overview about users opinions.

Speaking on behalf of myself, after additional inputs from many 
excellent and respectful users in this 'forum'. I can say that, on the 
scale of 1 (least geeky) to 10 (most geeky), I would put forum.dlang.org 
to the level 8 of geekiness required to use the forum. It may be natural 
for long-time users, but for newcomers, it is very challenging.


Mentioning 'challening', here is an excerpt from a fictional interview 
with the inventor of C++:


=
Interviewer: I see, but what's the point?

Stroustrup: Well, one day, when I was sitting in my office, I thought of 
this little scheme, which would redress the balance a little. I thought 
'I wonder what would happen, if there were a language so complicated, so 
difficult to learn, that nobody would ever be able to swamp the market 
with programmers? Actually, I got some of the ideas from X10, you know, 
X windows. That was such a bitch of a graphics system, that it only just 
ran on those Sun 3/60 things. They had all the ingredients for what I 
wanted. A really ridiculously complex syntax, obscure functions, and 
pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif 
is the only way to go if you want to retain your sanity.


Interviewer: You're kidding...?
(https://www-users.cs.york.ac.uk/susan/joke/cpp.htm)
=
I hope it is not offensive to bring up C++'s problems and relate them to 
D, but the point I am trying to make is *accessibility*. Provided that 
dlang community is not a the point of saturation, and still needs to 
grow, things need to be: Accessible (less geeky, less restrictions); 
Easy to learn and implement; Safe and Fast to program and to run. That 
would make a good acronym: SAFE safe-accessible-fast-easy, all go in 
parallel :)



Jonathan M Davis wrote:

On Friday, February 23, 2018 16:51:01 Biocyberman via Digitalmars-d wrote:

So far so much better :)

I really appreciate all answers given so far. Sorry I haven't found a
way to reply to everyone.

Many seems to be using the forum's web interface as a second - tier of
interaction. I still don't know what can justify this practice.


The NNTP and mailing list interfaces predate the web interface by quite a
bit. The web interface was added primarily as a means of making it easier
for more casual folks to comment. Those who wish to use it as their primary
interface to the newsgroup are free to do so, but anyone looking for the
feature set of the web interface to change needs to understand that the web
interface is just one interface to an NNTP server and not your typical forum
software.

- Jonathan M Davis

Re: Beta 2.079.0

[Seb via Digitalmars-d-announce]

On Friday, 23 February 2018 at 17:47:08 UTC, Kagamin wrote:

auto result = foo(), bar();

Doesn't look like it works.

---
int f(int a){ return a; }
int main()
{
int a=f(0),f(1); //doesn't compile
return 0;
}
---
int f(int a){ return a; }
int main()
{
int a;
a=f(0),f(1);
assert(a==1); //fails
return 0;
}
---
https://run.dlang.io/is/IgArs0


Yeah that should result in an error: 
https://issues.dlang.org/show_bug.cgi?id=18508

[Issue 18508] New: Using statement without effect should error

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

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

  Issue ID: 18508
   Summary: Using statement without effect should error
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

cat << EOF | dmd -c -o- -
int f(int a){ return a; }
void main()
{
int a;
a=f(0),f(1);
assert(a==1);
}
EOF

It already errors for

cat << EOF | dmd -c -o- -
int f(int a){ return a; }
void main()
{
int a;
a=0,1;
assert(a==1);
}
EOF

--

Re: Beta 2.079.0

[Kagamin via Digitalmars-d-announce]

auto result = foo(), bar();

Doesn't look like it works.

---
int f(int a){ return a; }
int main()
{
int a=f(0),f(1); //doesn't compile
return 0;
}
---
int f(int a){ return a; }
int main()
{
int a;
a=f(0),f(1);
assert(a==1); //fails
return 0;
}
---
https://run.dlang.io/is/IgArs0

Re: How do you get comfortable with Dlang.org's Forum?

[Kagamin via Digitalmars-d]

On Friday, 23 February 2018 at 13:47:16 UTC, biocyberman wrote:
From my experience with forum platforms like vBulletin, phpBB, 
Invision Power, and even interfaces of Google group, and Github 
Issues, I still find it very difficult to understand the logics 
of using dlang's forum.


You make it sound like "I even learned clay tablets" :)

1. No post editting. After clicking send, and found out that 
you made mistakes in the post, but you can't edit the post 
anymore.


Stackoverflow has this feature, and it's pretty popular on forums 
too, because when someone abuses editing, people complain that 
discussions make no sense anymore.


2. Old-day quoting presentation. I always feel reluctant to 
read texts that stays after two levels of quotes, like this:

 >First post quoted
 >>Second post quoted
 >>>Third post quoted
 >>Second post quoted


Stackoverflow and github have this feature. Though normally web 
interface hides the angle quotes, so they shouldn't interfere 
with reading.



3. No Rich-text format support. No minimal bold/italic support.
 Some tools to emphasize important points will make it easier 
to let the readers know what the posters want to say.


Bold and italic is a wrong way to format text because it's visual 
formatting that lacks semantic. You can use markdown to add 
*emphasis*, it's pretty intuitive, stackoverflow and github have 
it too. Emphasis only expresses emotions, which can actually 
distract from content, you better spend time expressing ideas.


4.  No code formatting. Same feeling here. I am reluctant to 
post more than 5 lines of code.


run.dlang.org

5. No image support. In many cases a screenshots will be 
helpful to communicate problems.


abload.de

6. Last but not least, a trendy feature: tags, keywords for 
threads so we can locate related threads easily.


Usually nobody bothers to fill them, so they won't give you any 
result.


If I may say it honestly, and despite the useful 'save unsent 
draft' feature, the forum is by far the most user-unfriendly 
forum platform ever (by appearance).


If I were to order them by user-friendliness (in descending 
order):

dfeed > forums >>> github > stackoverflow > skype

Re: Help using lubeck on Windows

[jmh530 via Digitalmars-d-learn]

On Friday, 23 February 2018 at 12:13:11 UTC, Arredondo wrote:

Help using lubeck on Windows

I'd like to experiment with linear algebra in D, and it looks 
like lubeck is the way to do it right now. However, I'm having 
a hard time dealing with the CBLAS and LAPACK dependencies.


I downloaded the OpenBLAS binaries for Windows 
(libopenblas.dll), but I am cluless as to what to do with them. 
I can't find an example of how to link them/what commands to 
pass to dmd. Any help deeply appreciated.


It is a rather frustrating experience on Windows. I've banged my 
head against my desk a few times trying to get it working.


My suggestion is to get the Windows Subsystem for Linux set up. 
With Ubuntu, you can follow all of the Linux instructions and it 
is pretty easy.


For trying to get it to work on Windows, first look at lubeck's 
dub.sdl, it depends on mir-blas and mir-lapack. So before you 
think about getting lubeck to work, you'll need to get those to 
work. Both of those depend on calling C libraries, you might 
refer to


https://dlang.org/blog/2017/12/05/interfacing-d-with-c-getting-started/

mir-blas depends on the D package cblas, which has headers for 
blas. It uses blas/cblas as libs, so you'll need to link in a 
blas library to get it to work.


mir-lapack depends on the D package lapack, which has headers for 
LAPACK. So again, I'm pretty sure you'll need to link in a lapack 
library to get it to work.


The lapack downloads usually contain a blas, though it may not be 
the most optimized one. The annoying thing is that when you go to 
the download links for things like lapack for Windows

http://icl.cs.utk.edu/lapack-for-windows/
the pre-built libraries require you to either have Visual Studio 
with Intel Compilers or MinGW and D's support with MinGW isn't 
all that great. So then what you'd need to do is use CMAKE to 
compile it with Visual Studio without Intel Compilers. This 
should work on DMD with -m32mscoff or -m64 and LDC. Also, make 
sure you link in the library correctly. Visual Studio's linker is 
different than DMD's when compiling 32bit code. I had given up 
and used WSL at this point rather than compile it myself with 
CMAKE. Less of a headache.

[Issue 11216] Make synchronized statement `nothrow`

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

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

--- Comment #11 from FeepingCreature  ---
Istm a possible approach would be:

 * Define SimpleMonitor : Monitor with nothrow

 * change DMD to use nothrow when locking SimpleMonitors

 * subclass druntime's Mutex with SimpleMutex : Mutex, SimpleMonitor

 * use SimpleMutex as the mutex implementation for class monitors

Then synchronized(this) should be nothrow without breaking existing code that
depends on Mutex/Monitor. It would only break if you were assigning to
_monitor, and that's easily fixed by using a separate member.

I don't know how to implement this on the DMD side though.

--

[Issue 18507] New: Linker errors on FreeBSD related to .data.d_dso_rec

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

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

  Issue ID: 18507
   Summary: Linker errors on FreeBSD related to .data.d_dso_rec
   Product: D
   Version: D2
  Hardware: x86_64
OS: FreeBSD
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: issues.dl...@jmdavisprog.com

Created attachment 1681
  --> https://issues.dlang.org/attachment.cgi?id=1681=edit
File which reproduces the issue

If the attached file is compiled with

dmd -main -unittest test.d

on x86_64 FreeBSD 11.1 then I get this linker error:

/usr/bin/ld: test.o: no group info for section .data.d_dso_rec
/usr/bin/ld: test.o: no group info for section .text.d_dso_init
/usr/bin/ld: test.o: no group info for section .dtors.d_dso_dtor
/usr/bin/ld: test.o: no group info for section .ctors.d_dso_ctor

I have no idea if x86 has the same problem or not, but the problem does not
seem to occur on 64-bit Linux. So, the problem seems to be FreeBSD-specific. I
have no clue whether older versions of FreeBSD have the problem or not, but in
theory, we're only supporting the latest version of FreeBSD, which is currently
11.1.

I'm sorry that the example code is as disgusting-looking as it is, but it's the
result of several runs of dustmite on one of my projects, and the linker errors
seem to happen only under some fairly specific circumstances, since it doesn't
take much to tweak the code to make the problem go away - though I did manage
to get the actual project to into a state where it was very hard to make the
problem go away. Fortunately for the project, after some serious refactoring to
remove some templated stuff that didn't turn out to be necessary, the problem
went away, so this isn't currently blocking my project, but we really shouldn't
be getting linker errors like this - especially when other platforms have no
problem with the exact same code.

--

[Issue 11216] Make synchronized statement `nothrow`

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

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

FeepingCreature  changed:

   What|Removed |Added

 CC||default_357-l...@yahoo.de

--- Comment #10 from FeepingCreature  ---
Still an issue in 2018.

--

Re: Beta 2.079.0

[Aurélien Plazzotta via Digitalmars-d-announce]

On Friday, 23 February 2018 at 02:20:41 UTC, psychotyicRabbit 
wrote:

On Friday, 23 February 2018 at 01:57:37 UTC, Martin Nowak wrote:
On Thursday, 22 February 2018 at 11:15:35 UTC, psychoticRabbit 
wrote:
import std.rabbit [food, water], std.house, std.family 
[carer];






Also, D is pretty good a depracating stuff, so why not 
deprecate the current way of imports, and gradually move to 
something (that resolves issues):


import std.stdio, std.whatever[this, that], std.somethingelse, 
std.grr[wtf];



Perhaps, we could use Backus-Naur notation, as it is already 
widely known into formal documents all over the globe, like the 
following:


import std.stdio, std.whatever{this, that}, std.somethingelse, 
std.grr{wtf};


That is with curly brackets instead of square brackets like you 
suggest :)

Re: NNTP client configuration

[Jonathan M Davis via Digitalmars-d]

On Tuesday, February 20, 2018 17:09:22 Brad Roberts via Digitalmars-d wrote:
> On 2/20/2018 4:53 PM, Seb via Digitalmars-d wrote:
> > On Wednesday, 21 February 2018 at 00:32:54 UTC, Manu wrote:
> >> On 20 February 2018 at 02:05, Jonathan M Davis via Digitalmars-d
> >>
> >>  wrote:
> >>> Now, the double-posting with both text and html is another matter
> >>> entirely
> >>
> >> but if the NG really doesn't
> >> want the html version of the email, it would be easy for the mailing
> >> list to mechanically truncate the html,
> >
> > Yes, but only one guy (Brad) is admin here.
> > There's really no point is discussing this for hours here.
> > Simply write Brad. You can reach him either via GitHub Issues:
> >
> > https://github.com/braddr/d-tester/issues
> >
> > Or for his email, simply look at the git log (he made the first git
> > commit)
> Do not use the d-tester issues for non tester related issues, please.
>
> Jonathan alerted me to the issue a couple days ago and I've been looking
> into this today.  It's due to a behavior change between versions of
> mailman used on the old (being a relative term.. been a few months now)
> mail server and the current mail server.  I don't see the solution yet,
> but I'm working to figure out how to restore the previous behavior.

Well, it looks like you fixed it, since all of the recent posts seem to only
have the mailing list address in the Reply-To header.

Thanks!

- Jonathan M Davis