Re: Building DMD on OpenBSD

[Kai Nacke via Digitalmars-d]

On Monday, 17 July 2017 at 18:58:40 UTC, Joakim wrote:

On Monday, 17 July 2017 at 18:42:39 UTC, Anonymous wrote:

On Monday, 17 July 2017 at 17:18:23 UTC, Joakim wrote:
Unfortunately, dmd has not kept porters in mind and 
hasnt kept the C++ version updated, or kept a workflow 
that enables easy bootstrapping:


http://forum.dlang.org/thread/xgtbpcvbikxlilanr...@forum.dlang.org

You will have to build druntime and phobos for 2.067 also and 
collect it all in a different location, which you could 
invoke to bootstrap a new dmd.  You may run into issues 
related to D/C++ integration when building the latest dmd, as 
that hasnt been tested on OpenBSD, only FreeBSD.


Why do you want the latest dmd on OpenBSD?  I ask because it 
will likely require some work, though likely not a lot.


Ive already tried building 2.067 druntime by mistake and 
run into problems. Most are resolvable by just adding 
TARGET_OPENBSD next to TARGET_FREEBSD. But yeah, its 
gonna take some work. I want it because Im using OpenBSD 
as my main OS and I have a project that I want to port to D.


Btw I shouldve built the `install` target (got confused 
by the wiki). Now I get:


cp: ../ini/openbsd/bin64/dmd.conf: No such file or directory

which is more understandable.


Alright, there was a contributor who recently got ldc working 
on NetBSD, take a look at his PRs as a guide for what you'll 
likely have to do:


https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3AnrTQgc
https://github.com/dlang/druntime/pulls?q=is%3Apr+author%3AnrTQgc
https://github.com/dlang/phobos/pulls?q=is%3Apr+author%3AnrTQgc

OpenBSD PRs welcome! :)

In the meantime, you can see that I've raised this bootstrap 
issue internally and hopefully we can make it easier for future 
porters.


:-)

In master there is already some OpenBSD support. Some time ago I 
worked on druntime support but I still need to finish this. 
Mostly there is nothing magic here - just translating the header 
files. The only non-obvious work is required for the 
module/shared library stuff (in rt.sections). If there is an 
OpenBSD expert around who can help here it would be nice.


Regards,
Kai

Re: New library: open multi-methods

[Ali Çehreli via Digitalmars-d-announce]

On 07/16/2017 10:24 AM, Jean-Louis Leroy wrote:
> TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md

Woot! :) I'm so happy to see this project complete.

Honestly, growing up with languages without this feature (C and C++), 
I've not even known that I needed this feature but your example (e.g. 
matrix multiplication) are very convincing.


If there are enough differences compared to your C++ articles, perhaps 
you may consider following this up with a blog post. It would be nice to 
see some performance results as well like you have on your C++ articles.


Ali

Re: (char* str) is not callable using argument types (string)

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 18 July 2017 at 03:58:49 UTC, Shachar Shemesh wrote:
If you cast a D string to const char* may or may not null 
terminate the string.


I do not recommend explicitly casting. This specific case is a 
string literal, which is guaranteed to be null terminated and 
will implicitly cast.


In the cases where it is not null terminated, the compiler will 
reject it as a type error.

Re: (char* str) is not callable using argument types (string)

[Shachar Shemesh via Digitalmars-d]

On 07/17/2017 05:10 PM, Adam D. Ruppe wrote:

On Monday, 17 July 2017 at 13:56:24 UTC, Zaheer Ahmed wrote:

I Developed OS in C and C++ but first time stuck in types.


A lot of C and C++ knowledge will carry over to D, but it isn't exactly 
the same. D's strings are of type `string` which is another word for 
`immutable(char)[]`.


immutable means the contents never change. A `[]` slice is a 
pointer+length pair in a single type.



For your simple case, making it `const char*` should work...


No, it shouldn't.

Worst, it should work *most* of the time.

If you cast a D string to const char* may or may not null terminate the 
string.


Shachar

Re: Idiomatic way of writing nested loops?

[Nicholas Wilson via Digitalmars-d-learn]

On Monday, 17 July 2017 at 11:07:35 UTC, Anton Fediushin wrote:
Hello! What is the best way of rewriting this code in idiomatic 
D manner?

--
foreach(a; ["foo", "bar"]) {
  foreach(b; ["baz", "foz", "bof"]) {
foreach(c; ["FOO", "BAR"]) {
  // Some operations on a, b and c
}
  }
}
--

Every array has at least 1 element, and adding/removing new 
"nested loops" should be as easy as possible.


Also, I have a question about running this in parallel: if I 
want to use nested loops with `parallel` from 
`std.parallelism`, should I add `parallel` to every loop like 
this?

--
foreach(a; ["foo", "bar"].parallel) {
  foreach(b; ["baz", "foz", "bof"].parallel) {
foreach(c; ["FOO", "BAR"].parallel) {
  // Some operations on a, b and c
}
  }
}
--
I am worried about running thousands of threads, because in 
this case first `parallel` runs 2 tasks, every task runs 3 
tasks and every task runned inside a task runs 2 more tasks.


So, how to write this in idiomatic D manner and run it _if 
possible_ in parallel?


With regards to parallel, only use it on the outermost loop. 
Assuming you have more items in the outermost loop than you do 
threads parallelising more than one loop won't net you any speed.

[Issue 17661] New isInputRange rejects valid input range

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17416] SocketOption.REUSEPORT not available on linux

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--

Re: D doesn't read the first character of a file (reads everything but the first chararacter) with either read() or readText()

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 18 July 2017 at 02:21:59 UTC, Enjoys Math wrote:


DMD32 D Compiler v2.074.1

import std.file;

void main() {
   string bigInput = readText("input.txt");
}

The file is 7 MB of ascii text, don't know if that matters...

Should I upgrade versions?


I wonder if it thinks there is a BOM and eats it?

[Issue 17660] ICE with `static foreach`: AssertError@ddmd/visitor.d(39)

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/425f129192605d53288190762ebd75a50a300a26
fix Issue 17660 - ICE with : AssertError@ddmd/visitor.d(39)

https://github.com/dlang/dmd/commit/af3eacf44280c8f368e6938c09cfae68e6489ee1
Merge pull request #7005 from tgehr/fix17660

Fix Issue 17660 - ICE with `static foreach`: AssertError@ddmd/visitor.d(39)

--

Re: New library: open multi-methods

[Jay Norwood via Digitalmars-d-announce]

On Tuesday, 18 July 2017 at 00:47:04 UTC, Jean-Louis Leroy wrote:

I don't know R but after a trip to Wikipedia it looks like it.

J-L


R is listed as one of the languages with built-in support in this 
wiki link.  I searched for  multiple dispatch because I was 
familiar with the similar feature in julia, and that's how they 
refer to it.

https://en.wikipedia.org/wiki/Multiple_dispatch

An excerpt statement from this wiki page is :
"  dynamically dispatched based on the run-time (dynamic) type 
or, in the more general case some other attribute, of more than 
one of its arguments"



Based on the 'some other attribute', I wonder if the library 
could conceivably be extended to dispatch based on the User 
Defined Attribute info


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

@('c') string s;
pragma(msg, __traits(getAttributes, s)); // prints tuple('c')

D doesn't read the first character of a file (reads everything but the first chararacter) with either read() or readText()

[Enjoys Math via Digitalmars-d-learn]

DMD32 D Compiler v2.074.1

import std.file;

void main() {
   string bigInput = readText("input.txt");
}

The file is 7 MB of ascii text, don't know if that matters...

Should I upgrade versions?

[Issue 17662] New: Replace 2.0^e2 with std.math.ldexp(1.0, cast(int) e2)

[via Digitalmars-d-bugs]

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

  Issue ID: 17662
   Summary: Replace 2.0^e2 with std.math.ldexp(1.0, cast(int) e2)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: performance
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

See also: https://github.com/dlang/phobos/pull/5057

> It should be clear that just setting the exponent (some integer ops) is way 
> faster than the current loop for bigger absolute N, but I didn't perform any 
> speed tests.
I'd rather drop this and add the optimization to the compiler, something like
[1]


[1]
https://github.com/kinke/ldc/commit/dc01a338d73c2cdb843de6426f520f6c175640d3

--

Re: proposed @noreturn attribute

[Timon Gehr via Digitalmars-d]

On 18.07.2017 03:06, Walter Bright wrote:

On 7/17/2017 5:13 PM, Timon Gehr wrote:

(Reminds me of divide by 0 discussions in calculus class.)


The reason division by 0 is left undefined is that instead saying 1/0 
= ∞ introduces a new number ∞ that does not play nice with the axioms 
of a complete ordered field.


The question for instance size is based on the wrong assumption that 
there is such an instance. It is true none the less that ∞ is the most 
natural answer to this question, as if you have multiple answers for 
instance size, you'd take the supremum. Of course, size_t does not 
contain ∞.


Infinity makes sense for 1/0, but I don't see how that automatically 
transfers to size_t.


It does not. The reasoning is unrelated.

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/17/2017 5:13 PM, Timon Gehr wrote:

(Reminds me of divide by 0 discussions in calculus class.)


The reason division by 0 is left undefined is that instead saying 1/0 = ∞ 
introduces a new number ∞ that does not play nice with the axioms of a complete 
ordered field.


The question for instance size is based on the wrong assumption that there is 
such an instance. It is true none the less that ∞ is the most natural answer to 
this question, as if you have multiple answers for instance size, you'd take the 
supremum. Of course, size_t does not contain ∞.


Infinity makes sense for 1/0, but I don't see how that automatically transfers 
to size_t.

Re: proposed @noreturn attribute

[Nicholas Wilson via Digitalmars-d]

On Monday, 17 July 2017 at 18:54:37 UTC, H. S. Teoh wrote:
IMO, the observations "used rarely" and "attention-seeking 
notation" are better satisfied by an attribute named @noreturn 
than some strange, convoluted, arcane invocation like 
`typeof(assert(0))`.  Because:


(1) "used rarely" means it should be as non-intrusive as 
possible as far as the language is concerned -- we should not 
spend a lot of language real estate on something that's rarely 
used, nor should it be something complicated to implement, 
and/or introduces tricky corner cases that we're likely to get 
wrong on first attempt. A @noreturn attribute is non-intrusive 
-- doesn't interact with anything else in the language, easy to 
implement -- has no tricky corner cases.


(2) "attention-seeking": an arcane invocation like 
`typeof(assert(0))` is harder to parse and therefore more 
likely to invite people to just gloss over it as 
"incomprehensible gibberish that I'll just ignore unless I have 
to look further", than catch people's attention.  Whereas an 
annotation like `@noreturn` is immediately obvious by its very 
presence, with a name that instantly tells you what it does 
while it still holds your attention.


I see `typeof(assert(0))` as the same kind of over-engineering 
of
something trivially solved and relatively unimportant ("rarely 
used")
that has unfortunately plagued C++ design and led C++ to become 
the mess

it is today.  It's sad to see D start down the same path...


T


(3) LDC and GDC already have an implementation in the form of an 
attribute so we can just have an AliasSeq of the front end 
recognised attribute and the one for GDC and LDC (assuming my 
attributes DIP goes through).

Re: DCompute: GPGPU with Native D for OpenCL and CUDA

[Nicholas Wilson via Digitalmars-d-announce]

On Monday, 17 July 2017 at 13:50:22 UTC, Mike Parker wrote:
Nicholas Wilson has put together a blog post on his progress 
with DCompute, expanding on his DConf talk. I have to admit 
that this is one of the D projects I'm most excited about, even 
though I'll probably never have a need to use it. I'd love to 
find an excuse to do so, though!


Blog:
https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native-d-for-opencl-and-cuda/

Reddit:
https://www.reddit.com/r/programming/comments/6nt4ba/dcompute_gpgpu_with_native_d_for_opencl_and_cuda/


Thanks for that.

Oh and @JohnColvin do you like the solution for the lambdas?

Re: New library: open multi-methods

[Jean-Louis Leroy via Digitalmars-d-announce]

On Monday, 17 July 2017 at 21:32:13 UTC, jmh530 wrote:

On Monday, 17 July 2017 at 21:31:20 UTC, jmh530 wrote:
On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy 
wrote:
Thinking about it, 'openmethods' would probably be a better 
module/package name than just 'methods'. It emphasizes the #1 
feature, i.e. polymorphism outside of classes.


Googling `multimethods` brought up more programming-related 
topics than `openmethods`.


Or you could call it omm and then just refer to open 
multi-methods in the documentation.


Yeah that's what the omm in yomm11 means, but I am not too fond 
of acronyms. In C++ it was the library name (-lyomm11) and also 
the project name but no the namespace.


J-L

Re: New library: open multi-methods

[Jean-Louis Leroy via Digitalmars-d-announce]

On Monday, 17 July 2017 at 22:59:03 UTC, jmh530 wrote:

On Monday, 17 July 2017 at 22:46:02 UTC, Jean-Louis Leroy wrote:


I think I will rename 'methods' to 'openmethods' for the time 
being, but the discussion remains open. Not renaming the repo 
yet.



On the other hand, when I saw methods, my first thought was R's 
methods, which I imagine is similar if I'm not mistaken.


I don't know R but after a trip to Wikipedia it looks like it.

J-L

Re: proposed @noreturn attribute

[Brad Roberts via Digitalmars-d]

On 7/17/2017 5:06 PM, Seb via Digitalmars-d wrote:


I can't agree more. This is textbook procrastination and bike-shedding [1]!
There are dozens of open regressions that could have fixed or great, 
stalled PRs that could have been reviewed.
In fact if only PRs would be as heartily reviewed as the discussion 
here, things like the fact that DMD leaks all symbols when imported 
selectively [2] would have been uncovered earlier.


[1] https://en.wikipedia.org/wiki/Law_of_triviality
[2] https://github.com/dlang/phobos/pull/5584#issuecomment-314910297


Semi-valid, but fungability of time and effort>.

Re: proposed @noreturn attribute

[Timon Gehr via Digitalmars-d]

On 18.07.2017 01:01, Walter Bright wrote:

...

But if Bottom does not exist, then S doesn't exist either, and hence the 
< size relationship has no meaning.

...


Both Bottom and S exist, but they have no instances.


(Reminds me of divide by 0 discussions in calculus class.)


The reason division by 0 is left undefined is that instead saying 1/0 = 
∞ introduces a new number ∞ that does not play nice with the axioms of a 
complete ordered field.


The question for instance size is based on the wrong assumption that 
there is such an instance. It is true none the less that ∞ is the most 
natural answer to this question, as if you have multiple answers for 
instance size, you'd take the supremum. Of course, size_t does not 
contain ∞.

Re: proposed @noreturn attribute

[Seb via Digitalmars-d]

On Monday, 17 July 2017 at 23:26:18 UTC, H. S. Teoh wrote:


Actually, I don't really care enough about this issue to want 
it to be implemented one way or another, as long as there is 
*some* way to annotate a non-returning function.


But the point is that so much time and effort is being spent on 
discussing and designing a feature that you have admitted 
yourself to be "rarely used". As a disinterested bystander I 
find it somewhat amusing (and sad) to see so much 
over-engineering of an overly-complex system involving a new 
basic type in the language, which in turn entails all sorts of 
corner cases in how it will interact with existing types and 
constructs, not to mention the implementation complexities that 
will be involved to pull it off -- all for what?  Just to be 
able to say "function F doesn't return".  Seems like 
disproportionate effort for only marginal returns (har har).



I can't agree more. This is textbook procrastination and 
bike-shedding [1]!
There are dozens of open regressions that could have fixed or 
great, stalled PRs that could have been reviewed.
In fact if only PRs would be as heartily reviewed as the 
discussion here, things like the fact that DMD leaks all symbols 
when imported selectively [2] would have been uncovered earlier.


[1] https://en.wikipedia.org/wiki/Law_of_triviality
[2] 
https://github.com/dlang/phobos/pull/5584#issuecomment-314910297

[Issue 17250] ProcessPipes (std.process) should provide a test for a null pid

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/b4284db1f937e90fec6ffe4a9e4e2bf4783799bb
Fix Issue 17250 - ProcessPipes (std.process) should provide a test for a null
pid

https://github.com/dlang/phobos/commit/1e296c11d8f8083402f8611d495cdcd015ff6fb3
Merge pull request #5621 from RazvanN7/Issue_17250

Fix Issue 17250 - ProcessPipes (std.process) should provide a test for a null
pid
merged-on-behalf-of: Vladimir Panteleev 

--

Re: proposed @noreturn attribute

[H. S. Teoh via Digitalmars-d]

On Mon, Jul 17, 2017 at 06:42:02PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 7/17/17 2:54 PM, H. S. Teoh via Digitalmars-d wrote:
> > I see `typeof(assert(0))` as the same kind of over-engineering of
> > something trivially solved and relatively unimportant ("rarely
> > used") that has unfortunately plagued C++ design and led C++ to
> > become the mess it is today.  It's sad to see D start down the same
> > path...
> 
> There is no reason to over-react seeing as the option of adding a name
> is easy and always available; removing it not so much. This makes
> taking options in language design highly asymmetrical. Having the type
> available as an actual expression brings good options on the table
> because people can return those on unreachable paths etc. -- Andrei

Actually, I don't really care enough about this issue to want it to be
implemented one way or another, as long as there is *some* way to
annotate a non-returning function.

But the point is that so much time and effort is being spent on
discussing and designing a feature that you have admitted yourself to be
"rarely used". As a disinterested bystander I find it somewhat amusing
(and sad) to see so much over-engineering of an overly-complex system
involving a new basic type in the language, which in turn entails all
sorts of corner cases in how it will interact with existing types and
constructs, not to mention the implementation complexities that will be
involved to pull it off -- all for what?  Just to be able to say
"function F doesn't return".  Seems like disproportionate effort for
only marginal returns (har har).


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/16/2017 5:41 AM, Timon Gehr wrote:

struct S{
T x;
Bottom everything;
}

turns the entire struct into an empty type. It is therefore most natural to say 
that Bottom.sizeof == ∞. (It's the only choice for which S.sizeof == 
Bottom.sizeof.)


Another way to think about it: If something of type A* converts to something of 
type B* without problems, then one would expect B.sizeof <= A.sizeof. This would 
imply that Bottom.sizeof >= size_t.max. (Because Bottom* converts to all other 
pointer types.)


One small issue is that one needs to avoid overflow for the size of a struct 
that has multiple fields where one of them is of type Bottom.




But if Bottom does not exist, then S doesn't exist either, and hence the < size 
relationship has no meaning.


(Reminds me of divide by 0 discussions in calculus class.)

[Issue 17661] New isInputRange rejects valid input range

[via Digitalmars-d-bugs]

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

--- Comment #2 from hst...@quickfur.ath.cx ---
Haha, I tried doing that but ran into another bug:

--
struct C {
private S* impl;
}
struct S {
bool empty;
@property C front() return { return C(); }
void popFront() { }

pragma(msg, typeof((S r) return => r.front));
}
--

Compiler output (dmd -dip25 -dip1000):
--
test.d(10): Error: returning r.front() escapes a reference to parameter r,
perhaps annotate with return
_error_
--

Because of this, isInputRange still doesn't work, with your proposed change.

Apparently dmd fails to pick up the `return` annotation for some reason.  Which
is actually rather strange, because:

---
pragma(msg, typeof((int* r) return => r));
---

prints:

---
int* function(return int* r) pure nothrow @nogc return @safe
---

so obviously the syntax is correct, and at least some of the time dmd is able
to process it correctly.  I've no idea why it doesn't pick up the annotation
and/or process it correctly when in the first code snippet above.

--

Re: New library: open multi-methods

[jmh530 via Digitalmars-d-announce]

On Monday, 17 July 2017 at 22:46:02 UTC, Jean-Louis Leroy wrote:


I think I will rename 'methods' to 'openmethods' for the time 
being, but the discussion remains open. Not renaming the repo 
yet.



On the other hand, when I saw methods, my first thought was R's 
methods, which I imagine is similar if I'm not mistaken.

[Issue 17661] New isInputRange rejects valid input range

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Andrei Alexandrescu  ---
Can you try replacing the clause is(typeof((R r) => r.front)) with 

is(typeof((R r) => r.front)) || is(typeof((R r) return => r.front))

?

If that works you may want to create a PR with it. Thanks!

--

Re: New library: open multi-methods

[Jean-Louis Leroy via Digitalmars-d-announce]

On Monday, 17 July 2017 at 21:31:20 UTC, jmh530 wrote:

On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy wrote:
Thinking about it, 'openmethods' would probably be a better 
module/package name than just 'methods'. It emphasizes the #1 
feature, i.e. polymorphism outside of classes.


Googling `multimethods` brought up more programming-related 
topics than `openmethods`.


Yeah, I know, but I can imagine someone casually browsing the 
registry, coming across the module and saying "multi-methods? 
yeah, cool, but I don't remember ever needing such a thing". 
Indeed "multi" is nice, but IMO "open" is much more important. It 
is still much more frequent to have only one virtual argument. 
Take the awful Visitor pattern, for example. It can be neatly 
replaced with an open method taking only one virtual argument 
(barring other considerations).


'openmultimethods' is another option but again it emphasizes 
'multi'.


Anyway, if I go for just 'openmethods', there are enough mentions 
of 'multi-methods' in the docs.


I think I will rename 'methods' to 'openmethods' for the time 
being, but the discussion remains open. Not renaming the repo yet.


Thinking about it, I should add a Visitor replacement example...

J-L

Re: Appending static arrays

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

On Mon, Jul 17, 2017 at 10:32:14PM +, Nordlöw via Digitalmars-d-learn wrote:
> On Monday, 17 July 2017 at 20:01:41 UTC, H. S. Teoh wrote:
[...]
> > result[offset .. offset + a.length] = a[];
> 
> This slice assignment doesn't support conversion between different
> element-types, for instance from `int[]` to `double[]`.
> 
> But I'm not convinced that we should allow `CommonType` when operator
> ~ doesn't.

True.  Maybe we should just leave out the `CommonType` thing for now.
Not sure how to express that all element types should be equal in the
sig constraints, though.

(It shouldn't be overly hard to support `CommonType`; just replace the
slice assignment with a manual loop. But yeah, probably not worth the
effort.)


T

-- 
Do not reason with the unreasonable; you lose by definition.

Re: DIP 1010--Static foreach--Accepted

[Andrei Alexandrescu via Digitalmars-d-announce]

On 7/17/17 8:38 AM, Steven Schveighoffer wrote:
What is the resolution of how break statements affect static 
foreach/foreach?


We initially allowed break and continue to refer to the enclosing 
statement, but upon further consideration we will make it an error. This 
allows us to collect more experience with the feature and leaves us the 
option to permit break/continue later on. I have contacted Timon about 
the matter. Thanks! -- Andrei

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/16/2017 1:15 PM, Timon Gehr wrote:

In this case, Bottom.sizeof is a value of type Bottom, which must not exist.


T.sizeof is a value of type size_t, not type T.

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 7/17/17 2:54 PM, H. S. Teoh via Digitalmars-d wrote:

I see `typeof(assert(0))` as the same kind of over-engineering of
something trivially solved and relatively unimportant ("rarely used")
that has unfortunately plagued C++ design and led C++ to become the mess
it is today.  It's sad to see D start down the same path...


There is no reason to over-react seeing as the option of adding a name 
is easy and always available; removing it not so much. This makes taking 
options in language design highly asymmetrical. Having the type 
available as an actual expression brings good options on the table 
because people can return those on unreachable paths etc. -- Andrei

Re: Appending static arrays

[Nordlöw via Digitalmars-d-learn]

On Monday, 17 July 2017 at 20:28:12 UTC, Nordlöw wrote:

Made some adjustments with working unittest and put it up on

https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2467


Moved here

https://github.com/nordlow/phobos-next/blob/master/src/array_ex.d#L2765

[Issue 15759] chunks should work with only an input range

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

   Keywords||pull

--- Comment #1 from hst...@quickfur.ath.cx ---
https://github.com/dlang/phobos/pull/5624

--

Re: Appending static arrays

[Nordlöw via Digitalmars-d-learn]

On Monday, 17 July 2017 at 20:01:41 UTC, H. S. Teoh wrote:

OK, here's an actual, compilable, runnable version:

import std.algorithm : sum;
import std.meta : allSatisfy, staticMap;
import std.range : only;
import std.traits : CommonType, isStaticArray;

alias Elem(A : E[n], E, size_t n) = E;
enum Length(A) = A.length;
enum sumLengths(A...) = sum(only(0, staticMap!(Length, A)));

	CommonType!(staticMap!(Elem, A))[sumLengths!A] append(A...)(A 
arrays)

if (allSatisfy!(isStaticArray, A))
{
typeof(return) result = void;
foreach (i, a; arrays) {
enum offset = sumLengths!(A[0 .. i]);
result[offset .. offset + a.length] = a[];


This slice assignment doesn't support conversion between 
different element-types, for instance from `int[]` to `double[]`.


But I'm not convinced that we should allow `CommonType` when 
operator ~ doesn't.

Re: proposed @noreturn attribute

[Stefan Koch via Digitalmars-d]

On Monday, 17 July 2017 at 18:54:37 UTC, H. S. Teoh wrote:
On Mon, Jul 17, 2017 at 02:10:27PM -0400, Andrei Alexandrescu 
via Digitalmars-d wrote:

On 7/17/17 11:39 AM, Olivier FAURE wrote:
> I'd really prefer if you avoided the whole 
> `typeof(assert(0))`

> thing.
> 
> First off, it's way too verbose for a simple concept.


Noted, thanks. I won't debate this much but for now I 
disagree. The "no return" type has several particular 
properties that set it aside (e.g. it's impossible to 
implement as a library, does things no other types do, etc).  
It's also used rarely. Therefore it stands to reason to 
consider an attention-seeking notation for it.

[...]

IMO, the observations "used rarely" and "attention-seeking 
notation" are better satisfied by an attribute named @noreturn 
than some strange, convoluted, arcane invocation like 
`typeof(assert(0))`.  Because:


(1) "used rarely" means it should be as non-intrusive as 
possible as far as the language is concerned -- we should not 
spend a lot of language real estate on something that's rarely 
used, nor should it be something complicated to implement, 
and/or introduces tricky corner cases that we're likely to get 
wrong on first attempt. A @noreturn attribute is non-intrusive 
-- doesn't interact with anything else in the language, easy to 
implement -- has no tricky corner cases.


(2) "attention-seeking": an arcane invocation like 
`typeof(assert(0))` is harder to parse and therefore more 
likely to invite people to just gloss over it as 
"incomprehensible gibberish that I'll just ignore unless I have 
to look further", than catch people's attention.  Whereas an 
annotation like `@noreturn` is immediately obvious by its very 
presence, with a name that instantly tells you what it does 
while it still holds your attention.


I see `typeof(assert(0))` as the same kind of over-engineering 
of
something trivially solved and relatively unimportant ("rarely 
used")
that has unfortunately plagued C++ design and led C++ to become 
the mess

it is today.  It's sad to see D start down the same path...


T


+1000!
You've said it all!

[Issue 15759] chunks should work with only an input range

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 17517] DMD fails to build on amd64 debian jessie

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

Re: Appending static arrays

[Nordlöw via Digitalmars-d-learn]

On Monday, 17 July 2017 at 20:53:36 UTC, H. S. Teoh wrote:
See the working implementation in my latest post on this 
thread.  That version supports CommonType, and works correctly 
with empty tuples as well.



T


Thanks.

[Issue 17661] New: New isInputRange rejects valid input range

[via Digitalmars-d-bugs]

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

  Issue ID: 17661
   Summary: New isInputRange rejects valid input range
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Code (compile with -dip25 -dip1000):


import std.range.primitives;
struct C {
private S* impl;
}
struct S {
bool empty;
@property C front() return { return C(); }
void popFront() { }

static assert(isInputRange!S); // FAILS
}


Prior to git commit 82c3371d85154b7f98b1c9187b79805a50fc59dd, the assert
passes. However, the new isInputRange checks introduced by this commit causes
the above breakage.

The problem is the new clause `typeof((R r) => r.front` in the new
isInputRange. Because S.front returns a reference to `this` it carries the
`return` annotation, so the compiler does not reject `front`. However, the
check in isInputRange does not have this annotation, so the compiler rejects it
as escaping a reference to `this`, thus causing isInputRange to fail to
recognize S as an input range.

--

Re: New library: open multi-methods

[jmh530 via Digitalmars-d-announce]

On Monday, 17 July 2017 at 21:31:20 UTC, jmh530 wrote:

On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy wrote:
Thinking about it, 'openmethods' would probably be a better 
module/package name than just 'methods'. It emphasizes the #1 
feature, i.e. polymorphism outside of classes.


Googling `multimethods` brought up more programming-related 
topics than `openmethods`.


Or you could call it omm and then just refer to open 
multi-methods in the documentation.

Re: New library: open multi-methods

[jmh530 via Digitalmars-d-announce]

On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy wrote:
Thinking about it, 'openmethods' would probably be a better 
module/package name than just 'methods'. It emphasizes the #1 
feature, i.e. polymorphism outside of classes.


Googling `multimethods` brought up more programming-related 
topics than `openmethods`.

Re: static foreach is now in github master

[Martin Nowak via Digitalmars-d-announce]

On Monday, 17 July 2017 at 18:14:35 UTC, Andrei Alexandrescu 
wrote:
For those who want to play with our new static foreach feature 
and are willing to take the steps to building their own dmd,


Or just wait for the next nightly until tomorrow around 5AM UTC.

curl -fsS https://dlang.org/install.sh | bash -s dmd-nightly

the feature is now merged in master: 
https://github.com/dlang/dmd/pull/6760


Great news.

Re: static foreach is now in github master

[John Colvin via Digitalmars-d-announce]

On Monday, 17 July 2017 at 18:14:35 UTC, Andrei Alexandrescu 
wrote:
For those who want to play with our new static foreach feature 
and are willing to take the steps to building their own dmd, 
the feature is now merged in master: 
https://github.com/dlang/dmd/pull/6760


Happy hacking!

Andrei


or for those using homebrew: `brew install dmd --HEAD`

Re: regex(q"<[^]>")

[unDEFER via Digitalmars-d]

On Monday, 17 July 2017 at 20:43:29 UTC, unDEFER wrote:

Sorry, fixed in the newest DMD also as the other bug in regex...


Oh, no. Not fixed. Fixed only other bug.

Re: Appending static arrays

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

On Mon, Jul 17, 2017 at 08:28:12PM +, Nordlöw via Digitalmars-d-learn wrote:
[...]
> I had to special-case foreach body for `i == 0` since `sumOfLengths`
> couldn't instantiate with empty tuple `()`.
> 
> Further, should `concat` support `CommonType`? That is, should
> 
> int[2] x = [1, 2];
> const double[2] y = [3, 4];
> auto z = concat(x, y);
> static assert(is(typeof(z) == double[4]));
> 
> be allowed?

See the working implementation in my latest post on this thread.  That
version supports CommonType, and works correctly with empty tuples as
well.


T

-- 
Trying to define yourself is like trying to bite your own teeth. -- Alan Watts

Re: New library: open multi-methods

[Jean-Louis Leroy via Digitalmars-d-announce]

Thinking about it, 'openmethods' would probably be a better 
module/package name than just 'methods'. It emphasizes the #1 
feature, i.e. polymorphism outside of classes.

Re: regex(q"<[^]>")

[unDEFER via Digitalmars-d]

Sorry, fixed in the newest DMD also as the other bug in regex...

Profiling Windows App and DLL

[Igor via Digitalmars-d-learn]

Is there a known limitation in profiling these or am I doing 
something wrong?


When I try to run my application from VisualD (x64 build) with 
-profile switch I just get Access Violation reported on WinMain 
function (actual declaration, it doesn't enter its body). If I 
build it with dub build --build=profile and then try to run it 
nothing happens, like it doesn't run at all.


If I only add -profile switch on DLL part of the application I 
get the same Access Violation on DllMain.


I also tried "Very Sleepy" profiler but it only shows symbols for 
main application and not for the DLL that it loads which is also 
built with debug info.

Re: Appending static arrays

[Nordlöw via Digitalmars-d-learn]

On Monday, 17 July 2017 at 20:10:31 UTC, H. S. Teoh wrote:
On Mon, Jul 17, 2017 at 08:11:03PM +, Nordlöw via 
Digitalmars-d-learn wrote: [...]

Does this have a place in Phobos?


Never know till you try. :-D



If so,

- under what name: append, concat or cat?


I'd vote for concat.



- where: std.algorithm or std.array?


std.array, IMO, since it's specific to static arrays.


T


Made some adjustments with working unittest and put it up on

https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2467

I had to special-case foreach body for `i == 0` since 
`sumOfLengths` couldn't instantiate with empty tuple `()`.


Further, should `concat` support `CommonType`? That is, should

int[2] x = [1, 2];
const double[2] y = [3, 4];
auto z = concat(x, y);
static assert(is(typeof(z) == double[4]));

be allowed?

Re: DCompute: GPGPU with Native D for OpenCL and CUDA

[Walter Bright via Digitalmars-d-announce]

On 7/17/2017 6:50 AM, Mike Parker wrote:

Blog:
https://dlang.org/blog/2017/07/17/dcompute-gpgpu-with-native-d-for-opencl-and-cuda/

Reddit:
https://www.reddit.com/r/programming/comments/6nt4ba/dcompute_gpgpu_with_native_d_for_opencl_and_cuda/ 


It's now #10 on Hacker News!

  https://news.ycombinator.com/news

Re: Appending static arrays

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

On Mon, Jul 17, 2017 at 08:11:03PM +, Nordlöw via Digitalmars-d-learn wrote:
[...]
> Does this have a place in Phobos?

Never know till you try. :-D


> If so,
> 
> - under what name: append, concat or cat?

I'd vote for concat.


> - where: std.algorithm or std.array?

std.array, IMO, since it's specific to static arrays.


T

-- 
Without outlines, life would be pointless.

Re: Appending static arrays

[Nordlöw via Digitalmars-d-learn]

On Monday, 17 July 2017 at 19:11:26 UTC, H. S. Teoh wrote:
Hmm, since we already have sumOfLengths available at 
compile-time, what about:


 	T[sumOfLengths!StaticArrays] 
append(StaticArrays...)(StaticArrays arrays)

if (allSatisfy!(isStaticArray, StaticArrays))
{
typeof(return) result = void;
foreach (i, a; 0 .. arrays.length)
{
enum offset = sumOfLengths!(arrays[0 .. i]);
result[offset .. offset + a.length] = a[];
}
return result;
}


T


Thanks, I'll try this!

Does this have a place in Phobos?

If so,

- under what name: append, concat or cat?
- where: std.algorithm or std.array?

Re: Appending static arrays

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

OK, here's an actual, compilable, runnable version:

import std.algorithm : sum;
import std.meta : allSatisfy, staticMap;
import std.range : only;
import std.traits : CommonType, isStaticArray;

alias Elem(A : E[n], E, size_t n) = E;
enum Length(A) = A.length;
enum sumLengths(A...) = sum(only(0, staticMap!(Length, A)));

CommonType!(staticMap!(Elem, A))[sumLengths!A] append(A...)(A arrays)
if (allSatisfy!(isStaticArray, A))
{
typeof(return) result = void;
foreach (i, a; arrays) {
enum offset = sumLengths!(A[0 .. i]);
result[offset .. offset + a.length] = a[];
}
return result;
}

@nogc unittest {
int[2] a = [ 1, 2 ];
int[3] b = [ 3, 4, 5 ];
int[4] c = [ 6, 7, 8, 9 ];

auto d = append(a, b, c);
assert(is(typeof(d) == int[9]));
assert(d == [ 1, 2, 3, 4, 5, 6, 7, 8, 9 ]);
}


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you 
wish you hadn't.

Re: Appending static arrays

[Nordlöw via Digitalmars-d-learn]

On Monday, 17 July 2017 at 18:54:31 UTC, Stefan Koch wrote:

we have special code in the compiler to optimize a ~ b ~ c.


Interesting, can you elaborate on what you mean with "optimize".

In that case, is there a reason why

int x[2];
int y[2];
int z[x.length + y.length] = x ~ y;

isn't @nogc?

Re: Appending static arrays

[Nordlöw via Digitalmars-d-learn]

On Monday, 17 July 2017 at 18:54:31 UTC, Stefan Koch wrote:

So all you need to do make it so
auto cat(T[]...)(T args)
{
T[] result;
mixin(() {
  string mix  = `result = `;
  foreach(i;args.length)
  {
mix ~= `args[` ~ itos(i) ~ `] ~`;
  }
  mix[$-1] = ';';
  return mix;
}());

return result;
}

that should do it :)


Thanks, but I wan't a @nogc-variant, which was posted below.

[Issue 17484] high penalty for vbroadcastsd with -mcpu=avx

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 17484] high penalty for vbroadcastsd with -mcpu=avx

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/1f11aa0eb8f6087b7dbadeb770e4526ec9808ccc
fix Issue 17484 - high penalty for AVX-256 instructions with AVX-128 regs

- as the upper 128-bits are no longer zero, the CPU will save/restore
  them when that register is used with legacy SSE instructions
- avoid using vbroadcastsd which is a AVX-256 only instruction to
  initialize 128-bit XMM vectors

--

Re: An Issue I Wish To Raise Awareness On

[Jack Stouffer via Digitalmars-d]

On Monday, 17 July 2017 at 17:41:58 UTC, Atila Neves wrote:

On Monday, 17 July 2017 at 14:26:19 UTC, Jack Stouffer wrote:
TL;DR: Issue 17658 [1] makes using shared very 
annoying/practically impossible.


[...]


I fixed this already, should be in the next release.

Atila


Are you sure? Because DMD nightly still errors:

https://run.dlang.io?compiler=dmd-nightly=struct%20A%0A%7B%0A%20%20%20%20this(string%20a)%20%7B%7D%0A%20%20%20%20this(string%20a)%20shared%20%7B%7D%0A%0A%20%20%20%20~this()%20%7B%7D%0A%20%20%20%20~this()%20shared%20%7B%7D%0A%0A%20%20%20%20this(this)%20%7B%7D%0A%20%20%20%20this(this)%20shared%20%7B%7D%0A%7D%0A%0Avoid%20main()%0A%7B%0A%20%20%20%20shared%20f%20%3D%20A(%22%22)%3B%0A%7D


(maybe we should remove the ban on URL shorteners for our own 
sites)

[Issue 17250] ProcessPipes (std.process) should provide a test for a null pid

[via Digitalmars-d-bugs]

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

--- Comment #6 from Jon Degenhardt  ---
(In reply to Jon Degenhardt from comment #5)
> (In reply to Vladimir Panteleev from comment #4)
> > (In reply to Jon Degenhardt from comment #1)
> > > The problem is that there is no method available to determine if pid is 
> > > null
> > > prior to call the pid() method.
> > 
> > Why not: if (pipes !is ProcessPipes.init)
> 
> Isn't 'is' a compile-time expression? The test needs to be run-time. Though
> that would mean 'if (pipes != ProcessPipes.init)' would work. Either way,
> these seem like very obscure ways to do such a test.

Never mind the 'compile-time expression' part, 'is' is a run-time test. Still,
it seems very obscure, and it's not obvious that a ProcessPipes struct that has
a null PID due to process startup failure will be in the same state as the
struct at .init time.

--

[Issue 17250] ProcessPipes (std.process) should provide a test for a null pid

[via Digitalmars-d-bugs]

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

--- Comment #5 from Jon Degenhardt  ---
(In reply to Vladimir Panteleev from comment #4)
> (In reply to Jon Degenhardt from comment #1)
> > The problem is that there is no method available to determine if pid is null
> > prior to call the pid() method.
> 
> Why not: if (pipes !is ProcessPipes.init)

Isn't 'is' a compile-time expression? The test needs to be run-time. Though
that would mean 'if (pipes != ProcessPipes.init)' would work. Either way, these
seem like very obscure ways to do such a test.

> 
> (In reply to RazvanN from comment #2)
> > I think the solution here is to remove the assert and expect the user to
> > check if the result of pid is null.
> 
> I think that's OK too, though it has the small downside that null
> dereferencing bugs are harder to diagnose on non-Windows systems.
> 
> We could also add an implicit conversion to bool.

Implicit conversion to bool sounds pretty good. Then it'd become:

scope(exit) if (pipes) wait(pipes.pid)

For me the downside of simply removing the assert and returning a null Pid
object is that it uses an internal implementation detail of ProcessPipes to
describe the state of the ProcessPipes instance. Modularity is better served by
separating the ProcessPipes state from the state internal _pid member, at least
in the ProcessPipes API. (This argument also says the original suggested API
name of 'isNullPid' is not a good name.)

--

[Issue 17660] New: ICE with `static foreach`: AssertError@ddmd/visitor.d(39)

[via Digitalmars-d-bugs]

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

  Issue ID: 17660
   Summary: ICE with `static foreach`:
AssertError@ddmd/visitor.d(39)
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: ice
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

test.d:

template AliasSeq(stuff ...) { alias AliasSeq = stuff; }

auto append()
{
static foreach (i; AliasSeq!(1)) {}
int result;
return result;
}


`dmd -c test.d`:

core.exception.AssertError@ddmd/visitor.d(39): Assertion failure

??:? _d_assertp [0x8098cf09]
??:? _ZN7Visitor5visitEP9Statement [0x8089b5f8]
??:? _ZN7Visitor5visitEP19ForwardingStatement [0x8089b679]
??:? _ZN19ForwardingStatement6acceptEP7Visitor [0x808930a9]
??:? _ZN22StatementRewriteWalker9visitStmtERP9Statement [0x8089ce43]
??:? _ZN22StatementRewriteWalker5visitEP17CompoundStatement [0x8089cf05]
??:? _ZN17CompoundStatement6acceptEP7Visitor [0x80892935]
??:? _ZN22StatementRewriteWalker9visitStmtERP9Statement [0x8089ce43]
??:? _ZN15FuncDeclaration9semantic3EP5Scope [0x8082e14c]
??:? _ZN6Module9semantic3EP5Scope [0x807d5995]
??:? int ddmd.mars.tryMain(ulong, const(char)**) [0x8085755e]
??:? _Dmain [0x8085857a]


Works without `static`. Also fails with `static foreach (i; 0 .. 1) {}`.

Tested with DMD64 D Compiler v2.075.0-rc1-190-ge3705e3d9.

--

Re: Appending static arrays

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

On Mon, Jul 17, 2017 at 12:01:48PM -0700, H. S. Teoh via Digitalmars-d-learn 
wrote:
[...]
>   template sumOfLengths(A...)
>   if (A.length > 0)
>   {
>   static if (A.length == 1)
>   enum sumOfLengths = A[0].length;
>   else
>   enum sumOfLengths = A[0].length + sumOfLengths!(A[1 .. 
> $]);
>   }
> 
>   T[sumOfLengths!StaticArrays] append(StaticArrays...)(StaticArrays 
> arrays)
>   if (/* insert static array constraints here */)
>   {
>   typeof(return) result = void;
>   size_t offset = 0;
>   foreach (a; arrays)
>   {
>   result[offset .. offset + a.length] = a[];
>   }
>   return result;
>   }
[...]

Hmm, since we already have sumOfLengths available at compile-time, what
about:

T[sumOfLengths!StaticArrays] append(StaticArrays...)(StaticArrays 
arrays)
if (allSatisfy!(isStaticArray, StaticArrays))
{
typeof(return) result = void;
foreach (i, a; 0 .. arrays.length)
{
enum offset = sumOfLengths!(arrays[0 .. i]);
result[offset .. offset + a.length] = a[];
}
return result;
}


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG

Re: Appending static arrays

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

On Mon, Jul 17, 2017 at 12:01:48PM -0700, H. S. Teoh via Digitalmars-d-learn 
wrote:
[...]
>   T[sumOfLengths!StaticArrays] append(StaticArrays...)(StaticArrays 
> arrays)
>   if (/* insert static array constraints here */)
>   {
>   typeof(return) result = void;
>   size_t offset = 0;
>   foreach (a; arrays)
>   {
>   result[offset .. offset + a.length] = a[];

Argh, forgot this important line:

offset += a.length;


>   }
>   return result;
>   }
[...]


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before 
which you fail to deliver after.

Re: Appending static arrays

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

On Mon, Jul 17, 2017 at 05:38:23PM +, Nordlöw via Digitalmars-d-learn wrote:
> I'm want to define a specialization of `append()` that takes only
> static arrays as inputs and returns a static array being the sum of
> the lengths of the inputs.
> 
> Have anybody already implemented this?
> 
> If not, I'm specifically interested in how to most conveniently infer
> the length (as an enum) of the returned static array from the
> `.length`s of inputs (which of course must be enum-values too).

Hmm. What about:

template sumOfLengths(A...)
if (A.length > 0)
{
static if (A.length == 1)
enum sumOfLengths = A[0].length;
else
enum sumOfLengths = A[0].length + sumOfLengths!(A[1 .. 
$]);
}

T[sumOfLengths!StaticArrays] append(StaticArrays...)(StaticArrays 
arrays)
if (/* insert static array constraints here */)
{
typeof(return) result = void;
size_t offset = 0;
foreach (a; arrays)
{
result[offset .. offset + a.length] = a[];
}
return result;
}


T

-- 
IBM = I'll Buy Microsoft!

Re: Appending static arrays

[ag0aep6g via Digitalmars-d-learn]

On 07/17/2017 08:35 PM, Nordlöw wrote:
Thanks, but I'm talking about the variadic case where the number of 
input arguments are unknown (>= 2) where the function header looks 
something like


import std.traits : allSatisfy, isStaticArray;

auto append(R, Args...)(auto ref Args args)
 if (args.length >= 2 &&
 allSatisfy!(isStaticArray, Args))
 // TODO all ElementTypes have CommonType
{
 // ...
}



I see. Here's what I could come up with:


import std.traits : allSatisfy, isStaticArray;

auto append(Args...)(auto ref Args args)
if (args.length >= 2 &&
allSatisfy!(isStaticArray, Args))
{
import std.algorithm : sum;
import std.meta : staticMap;
import std.range: ElementType;
import std.traits : CommonType;

enum staticArrayLength(A : E[n], E, size_t n) = n;

alias E = ElementType!(Args[0]);
static assert(is(CommonType!(staticMap!(ElementType, Args)) : E));
enum lengths = staticMap!(staticArrayLength, Args);

E[sum([lengths])] result;
foreach (i, length; lengths)
{
enum offset = sum!(size_t[])([lengths[0 .. i]]);
result[offset .. offset + length] = args[i];
}
return result;
}

@nogc unittest
{
int[3] a = [1, 2, 3];
const int[4] b = [4, 5, 6, 7];
immutable int[5] c = [8, 9, 10, 11, 12];

auto r = append(a, b, c);
assert(r == [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]);
static assert(is(typeof(r) == int[12]));
}

[Issue 6718] "nWayUnion" => "nWayMerge", plus true nWayUnion

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/9efa504bdca2b2644375e86d3b1527170512b726
Fix Issue 6718 - nWayUnion => nWayMerge, plus true nWayUnion

https://github.com/dlang/phobos/commit/bdae5f08f3cf4ed153063ad1d9a07fbb5aa12668
Merge pull request #5620 from RazvanN7/Issue_6718

[WIP] Fix Issue 6718 - nWayUnion => nWayMerge, plus true nWayUnion
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 15831] IFTI voldemort type exploding bloat

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

   Keywords||pull

--- Comment #18 from hst...@quickfur.ath.cx ---
https://github.com/dlang/dmd/pull/6998

--

Re: proposed @noreturn attribute

[H. S. Teoh via Digitalmars-d]

On Mon, Jul 17, 2017 at 02:10:27PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 7/17/17 11:39 AM, Olivier FAURE wrote:
> > I'd really prefer if you avoided the whole `typeof(assert(0))`
> > thing.
> > 
> > First off, it's way too verbose for a simple concept.
> 
> Noted, thanks. I won't debate this much but for now I disagree. The
> "no return" type has several particular properties that set it aside
> (e.g. it's impossible to implement as a library, does things no other
> types do, etc).  It's also used rarely. Therefore it stands to reason
> to consider an attention-seeking notation for it.
[...]

IMO, the observations "used rarely" and "attention-seeking notation" are
better satisfied by an attribute named @noreturn than some strange,
convoluted, arcane invocation like `typeof(assert(0))`.  Because:

(1) "used rarely" means it should be as non-intrusive as possible as far
as the language is concerned -- we should not spend a lot of language
real estate on something that's rarely used, nor should it be something
complicated to implement, and/or introduces tricky corner cases that
we're likely to get wrong on first attempt. A @noreturn attribute is
non-intrusive -- doesn't interact with anything else in the language,
easy to implement -- has no tricky corner cases.

(2) "attention-seeking": an arcane invocation like `typeof(assert(0))`
is harder to parse and therefore more likely to invite people to just
gloss over it as "incomprehensible gibberish that I'll just ignore
unless I have to look further", than catch people's attention.  Whereas
an annotation like `@noreturn` is immediately obvious by its very
presence, with a name that instantly tells you what it does while it
still holds your attention.

I see `typeof(assert(0))` as the same kind of over-engineering of
something trivially solved and relatively unimportant ("rarely used")
that has unfortunately plagued C++ design and led C++ to become the mess
it is today.  It's sad to see D start down the same path...


T

-- 
I see that you JS got Bach.

Re: Building DMD on OpenBSD

[Joakim via Digitalmars-d]

On Monday, 17 July 2017 at 18:42:39 UTC, Anonymous wrote:

On Monday, 17 July 2017 at 17:18:23 UTC, Joakim wrote:
Unfortunately, dmd has not kept porters in mind and 
hasnt kept the C++ version updated, or kept a workflow 
that enables easy bootstrapping:


http://forum.dlang.org/thread/xgtbpcvbikxlilanr...@forum.dlang.org

You will have to build druntime and phobos for 2.067 also and 
collect it all in a different location, which you could invoke 
to bootstrap a new dmd.  You may run into issues related to 
D/C++ integration when building the latest dmd, as that 
hasnt been tested on OpenBSD, only FreeBSD.


Why do you want the latest dmd on OpenBSD?  I ask because it 
will likely require some work, though likely not a lot.


Ive already tried building 2.067 druntime by mistake and 
run into problems. Most are resolvable by just adding 
TARGET_OPENBSD next to TARGET_FREEBSD. But yeah, its 
gonna take some work. I want it because Im using OpenBSD 
as my main OS and I have a project that I want to port to D.


Btw I shouldve built the `install` target (got confused 
by the wiki). Now I get:


cp: ../ini/openbsd/bin64/dmd.conf: No such file or directory

which is more understandable.


Alright, there was a contributor who recently got ldc working on 
NetBSD, take a look at his PRs as a guide for what you'll likely 
have to do:


https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3AnrTQgc
https://github.com/dlang/druntime/pulls?q=is%3Apr+author%3AnrTQgc
https://github.com/dlang/phobos/pulls?q=is%3Apr+author%3AnrTQgc

OpenBSD PRs welcome! :)

In the meantime, you can see that I've raised this bootstrap 
issue internally and hopefully we can make it easier for future 
porters.

Re: Error: -o no longer supported, use -of or -od

[Zaheer Ahmed via Digitalmars-d]

On Monday, 17 July 2017 at 17:10:51 UTC, Jonathan Marler wrote:

On Monday, 17 July 2017 at 16:08:30 UTC, Zaheer Ahmed wrote:

When Compiling kernel.d with makefile I get
Error: -o no longer supported, use -of or -od
and my Makefile Commands to do this is following.

DMDPARAMS = -m32
//...some objects
%.o: %.d
   dmd $(DMDPARAMS) -o $@ -c $<


 dmd $(DMDPARAMS) -of$@ -c $<


Thank You. This is working. I was trying but putting space 
between -of$@ like "-of $@" and source file should be immediately 
right after '-of'.

Re: Appending static arrays

[Stefan Koch via Digitalmars-d-learn]

On Monday, 17 July 2017 at 18:38:16 UTC, Nordlöw wrote:

On Monday, 17 July 2017 at 17:46:42 UTC, ag0aep6g wrote:

int[n + m] result = a ~ b;


Further, the expression `a ~ b` here will allocate and create a 
copy on the GC-heap before writing `result`.


Maybe LDC optimizes away this now or in the future but DMD 
cannot.


Yeah I know, kind of dumb but that's how it is currently.


we have special code in the compiler to optimize a ~ b ~ c.
So all you need to do make it so
auto cat(T[]...)(T args)
{
T[] result;
mixin(() {
  string mix  = `result = `;
  foreach(i;args.length)
  {
mix ~= `args[` ~ itos(i) ~ `] ~`;
  }
  mix[$-1] = ';';
  return mix;
}());

return result;
}

that should do it :)

Re: Compilation times and idiomatic D code

[H. S. Teoh via Digitalmars-d]

On Sat, Jul 15, 2017 at 07:11:54PM +, Enamex via Digitalmars-d wrote:
[...]
> All that time I'd assumed that 'symbols' as linkers used them were
> constant length :T

They may have been once upon a time, many decades ago. :-D  But modern
linkers support symbols of arbitrary length (well, up to a limit :-D)
because of the demands of modern languages that generate long symbols as
part of implementing function overloading, etc..


> Just to be clear: 100% of that bloat resides in the symbol table?

Pretty much, yes.  Unless your program happens to want to print a string
constructed from the type name (very unlikely unless it's purely for
debugging purposes).


> So the current proposed remedy is to hash symbols above a length
> threshold?

Rainers' PR (which is now available as a dmd/druntime branch, btw)
changes the mangling scheme so that when a symbol contains substrings
that are repeated, the repeated instances are replaced with an encoded
back-reference. When substrings are long and/or repeated frequently,
this leads to a significant reduction in symbol size.

In fact, I just tested the `mangle` branch this morning on my code, and
it shows major improvements: my executable sizes are now down to 4MB,
about half the size of what I could achieve by type erasure via OO
polymorphism.  The longest symbol lengths are now about 1000 characters
or so, as opposed to 20KB (or, before I applied the horcrux trick,
800KB).  Compared to the original 600MB executable sizes before I
started tackling this issue, this represents a 99% improvement(!).

Now Rainers' changes are just waiting for various dmd testsuite issues
to be ironed out, and it should be available in git master soon. Hooray!


> Besides the symbol problem though, does the template instantiation
> explosion problem imply as many duplicated function bodies
> corresponding to the new type symbols?

That's a different, though somewhat related, issue.  I have some ideas
on that front, but for now, Rainers' PR addresses only the problem of
symbol length.  So the next task after his fix is merged is to tackle
the larger problem of how to improve the implementation of templates.

One of the major issues with heavily-templated code is that you could
potentially end up with many duplicated function bodies that may in fact
be binary-identical, but are stored separately in the executable because
from the language's POV, they are distinct functions.  (Well, there's
also the problem of separate compilation, where you could end up with
the *same* function instantiated multiple times in different object
files, but for the most part, LTO (link-time optimization) takes care of
that: the compiler writes out the duplicated instantiations as "weak
symbols", so the linker discards all but the first copy.)

Often, this results from templates that contain helper code that's
independent of the template parameters, or dependent only on a subset of
template parameters. For example:

struct S(T, size_t size) {
T method1() {
// N.B.: independent of `size`
return T.init;
}
int[size] method2() {
// N.B.: independent of `T`
return int[size].init;
}
T[size] method3() {
// N.B.: depends on both `T` and `size`
return T[size].init;
}
}

S!(int, 5) si5;
S!(int, 6) si6;
S!(string, 2) ss2;
S!(string, 4) ss4;

Here, si5.method1 and si6.method1 are identical, because method1 is
independent of `size`.  However, because they are part of the template
S, they have distinct names: `S!(int, 5).method1` and `S!(int,
6).method1`, so they will be duplicated in the generated code.  Ideally,
the compiler should detect that they are actually identical, and merge
them accordingly.

A similar situation occurs with method2. For method3, since it depends
on both template parameters, two versions of the function must be
generated, obviously.

Of course, this example is contrived, and rather trivial.  A less
trivial example shows that there's more to this problem than just
detecting which template parameters a method depends on:

struct List(T) {
struct Node {
Node* next;
T t;
}
Node* removeNext(Node* prev) {
Node* tmp = prev.next;
prev.next = tmp.next;
tmp.next = null;
return tmp;
}
...
}

Here, removeNext takes Node* as parameter, and since the definition of
Node depends on T, it would appear that removeNext also depends on T.
However, closer inspection shows that actually it never touches the
portion of Node that is dependent on T.  Therefore, removeNext will
actually be identical across 

Re: Appending static arrays

[Nordlöw via Digitalmars-d-learn]

On Monday, 17 July 2017 at 17:38:23 UTC, Nordlöw wrote:
I'm want to define a specialization of `append()` that takes 
only static arrays as inputs and returns a static array being 
the sum of the lengths of the inputs.


Have anybody already implemented this?

If not, I'm specifically interested in how to most conveniently 
infer the length (as an enum) of the returned static array from 
the `.length`s of inputs (which of course must be enum-values 
too).


I just realized that I can use `std.meta.staticMap` to get the 
lengths but I still need to reduce them and there is no variant 
of `reduce` in `std.meta`. Why? Hasn't it been written yet?


I know I can always write yet another recursive CT-function, say 
`SumOfLengths`, but I thought I'd try to reuse `std.meta` this 
time. :)

Re: Building DMD on OpenBSD

[Anonymous via Digitalmars-d]

On Monday, 17 July 2017 at 17:18:23 UTC, Joakim wrote:
Unfortunately, dmd has not kept porters in mind and hasnt 
kept the C++ version updated, or kept a workflow that enables 
easy bootstrapping:


http://forum.dlang.org/thread/xgtbpcvbikxlilanr...@forum.dlang.org

You will have to build druntime and phobos for 2.067 also and 
collect it all in a different location, which you could invoke 
to bootstrap a new dmd.  You may run into issues related to 
D/C++ integration when building the latest dmd, as that 
hasnt been tested on OpenBSD, only FreeBSD.


Why do you want the latest dmd on OpenBSD?  I ask because it 
will likely require some work, though likely not a lot.


Ive already tried building 2.067 druntime by mistake and 
run into problems. Most are resolvable by just adding 
TARGET_OPENBSD next to TARGET_FREEBSD. But yeah, its gonna 
take some work. I want it because Im using OpenBSD as my 
main OS and I have a project that I want to port to D.


Btw I shouldve built the `install` target (got confused by 
the wiki). Now I get:


cp: ../ini/openbsd/bin64/dmd.conf: No such file or directory

which is more understandable.

Re: Appending static arrays

[Nordlöw via Digitalmars-d-learn]

On Monday, 17 July 2017 at 17:46:42 UTC, ag0aep6g wrote:

int[n + m] result = a ~ b;


Further, the expression `a ~ b` here will allocate and create a 
copy on the GC-heap before writing `result`.


Maybe LDC optimizes away this now or in the future but DMD cannot.

Yeah I know, kind of dumb but that's how it is currently.

Re: Appending static arrays

[Nordlöw via Digitalmars-d-learn]

On Monday, 17 July 2017 at 17:46:42 UTC, ag0aep6g wrote:

Like so?

int[n + m] append(size_t n, size_t m)(int[n] a, int[m] b)
{
int[n + m] result = a ~ b;
return result;
}


Thanks, but I'm talking about the variadic case where the number 
of input arguments are unknown (>= 2) where the function header 
looks something like


import std.traits : allSatisfy, isStaticArray;

auto append(R, Args...)(auto ref Args args)
if (args.length >= 2 &&
allSatisfy!(isStaticArray, Args))
// TODO all ElementTypes have CommonType
{
// ...
}

static foreach is now in github master

[Andrei Alexandrescu via Digitalmars-d-announce]

For those who want to play with our new static foreach feature and are 
willing to take the steps to building their own dmd, the feature is now 
merged in master: https://github.com/dlang/dmd/pull/6760


Happy hacking!

Andrei

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 7/17/17 11:39 AM, Olivier FAURE wrote:

I'd really prefer if you avoided the whole `typeof(assert(0))` thing.

First off, it's way too verbose for a simple concept.


Noted, thanks. I won't debate this much but for now I disagree. The "no 
return" type has several particular properties that set it aside (e.g. 
it's impossible to implement as a library, does things no other types 
do, etc). It's also used rarely. Therefore it stands to reason to 
consider an attention-seeking notation for it.


The upside of this is we can always add an alias to give the type a name 
if we so wish. For now I'd want to experiment with using typeof as notation.



Andrei

Re: Yesterday Visual D worked, today it does not!

[Enjoys Math via Digitalmars-d-learn]

On Monday, 17 July 2017 at 17:57:14 UTC, Enjoys Math wrote:
I made a console app the other day and there were build options 
present.


In the build options I had to specify the dmd2 executable 
directly.  Then it worked (but that's another error).


Today there are no build options!  I tried creating a regular 
console app and a GDC/DMD console app.


Okay, found them.  You have to right-click on the project.  Duh! 
:D

Yesterday Visual D worked, today it does not!

[Enjoys Math via Digitalmars-d-learn]

I made a console app the other day and there were build options 
present.


In the build options I had to specify the dmd2 executable 
directly.  Then it worked (but that's another error).


Today there are no build options!  I tried creating a regular 
console app and a GDC/DMD console app.

Re: newCTFE Status July 2017

[Stefan Koch via Digitalmars-d]

On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:

[ ... ]


I just figured out the bug in test/runnable/template8.d

What happens somewhere inside those templates is that the 
following expression is executed:


"some string literal" ~ null;

when then happens we executed the equivalent of the following in 
bytecode

{
  size_t lhsorrhs = lhs | rhs;
  if (!lhsorrhs)
return null;
   // needed to handle the special case null ~ null == null;
   immutable elemSize = elementSize(lhs); // can be assumed to be 
the same as rhs
  // sema would have 
complained otherwise


  int newSize = 0;
  int lhsSize = lhs ? getLength(lhs) * elemSize : 0;
  int rhsSize = rhs ? getLength(rhs) * elemSize : 0;
  newSize += lhsSize;

  newSize += (getLength(rhs) * elemSize);

  void* newString = allocateHeap(newSize + 
SliceDescriptor.sizeof);

  auto sliceDesc = cast(SliceDescriptor*) newString;
  sliceDesc.base = newString + SliceDescriptor.sizeof;
  sliceDesc.length = newSize / elemSize;
  newString += SliceDescriptor.sizeof;

  memcpy(newString, lhs, lhsSize);
  memcpy(newString + lhsSize, rhs, rhsSize);

}

now what happens if either lhs OR rhs are null but not both ?
right a null pointer dereference.

and this is what happend here.

Why did it take so long to find ?

Well please scan the test
https://github.com/dlang/dmd/blob/master/test/runnable/template8.d
yourself and tell me where you see "something" ~ null :)

[Issue 17645] `pure` is transitively applied to all delegates inside a pure function

[via Digitalmars-d-bugs]

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

--- Comment #7 from Steven Schveighoffer  ---
(In reply to Tomer Filiba (weka) from comment #5)
> the fact i *create* a delegate in a pure scope
> shouldn't force the *delegate* to be pure.

I'm not 100% sure about that, but it seems a plausible possibility. As long as
you aren't calling the delegate from within the function (your ASSERT function
seems to be, and assert definitely would be), then just accessing the stack
frame data should be OK.

As far as @nogc goes, that is simply an issue with the functions you need to
call. If you need GC functions within @nogc, then you have to obscure and cast.
I think it's possible to argue that assert should allow GC functionality, but
not 100% sure of that. It appears that any inner functions inside a pure
function are also marked pure. Since there's no "unpure" attribute, it's hard
to undo this.

--

Re: DCompute: GPGPU with Native D for OpenCL and CUDA

[Johan Engelen via Digitalmars-d-announce]

On Monday, 17 July 2017 at 13:50:22 UTC, Mike Parker wrote:
Nicholas Wilson has put together a blog post on his progress 
with DCompute


Great, Nick!

Re: Appending static arrays

[ag0aep6g via Digitalmars-d-learn]

On 07/17/2017 07:38 PM, Nordlöw wrote:
I'm want to define a specialization of `append()` that takes only static 
arrays as inputs and returns a static array being the sum of the lengths 
of the inputs.


Have anybody already implemented this?

If not, I'm specifically interested in how to most conveniently infer 
the length (as an enum) of the returned static array from the `.length`s 
of inputs (which of course must be enum-values too).


Like so?

int[n + m] append(size_t n, size_t m)(int[n] a, int[m] b)
{
int[n + m] result = a ~ b;
return result;
}

Re: An Issue I Wish To Raise Awareness On

[Atila Neves via Digitalmars-d]

On Monday, 17 July 2017 at 14:26:19 UTC, Jack Stouffer wrote:
TL;DR: Issue 17658 [1] makes using shared very 
annoying/practically impossible.


[...]


I fixed this already, should be in the next release.

Atila

[Issue 17659] `pure` causes function to be inferred as a delegate

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
I'll add a note that it certainly is possible for a function to be inferred:

void foo() pure {
   indirectCall(function() {x++;}); // void function() nothrow @nogc @system
}

The compiler should be able to do so.

--

Appending static arrays

[Nordlöw via Digitalmars-d-learn]

I'm want to define a specialization of `append()` that takes only 
static arrays as inputs and returns a static array being the sum 
of the lengths of the inputs.


Have anybody already implemented this?

If not, I'm specifically interested in how to most conveniently 
infer the length (as an enum) of the returned static array from 
the `.length`s of inputs (which of course must be enum-values 
too).

Re: proposed @noreturn attribute

[Patrick Schluter via Digitalmars-d]

On Monday, 17 July 2017 at 15:39:30 UTC, Olivier FAURE wrote:
On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu 
wrote:
An issue is that we already have typeof(null). typeof(null) 
and typeof(assert(0))* are two ways to specify almost the 
same thing. One question is whether typeof(assert(0))* and 
typeof(null) should be the same, or if the former should not 
implicitly convert to class references.
I have also argued in the past that there should be a 
separate typeof([]). This role would now be filled by 
typeof(assert(0))[]. However, changing the type of '[]' may 
break code.


You're on to something here. Perhaps we go the inverse route 
and define the bottom type as typeof(*null). Would that 
simplify matters? There is some good consistency about it:


null: a pointer to anything. But can't be dereferenced.
*null: well, therefore... anything. But can't be created.

The latter is a mere consequence of the former.


I'd really prefer if you avoided the whole `typeof(assert(0))` 
thing.


First off, it's way too verbose for a simple concept. In 
general, code is much more readable when you can read functions 
as `Type functionName(args)`, rather than template-style 
`expr(valueof!(thing + otherThing).typeof) functionName(args)`, 
so I think it would be better not to encourage adding more 
expressions as return types.


I think the following:

noreturn_t logThenQuit(string message)

is much more readable and obvious (especially to a beginner) 
than:


typeof(*null) logThenQuit(string message)

Of course, you could implement typeof(*null); and also add 
noreturn_t as an alias; it might be a good compromise; I'd 
still dislike it because it encourages people to use the 
verbose hard to understand version.


The second reason I don't like it is that I feel it's just 
trying to be clever for the sake of cleverness. I don't think 
we need a language feature that perfectly matches the idea of 
not returning from a function on a deep, philosophical level; 
we just need a way to tell the type system "Hey, this function 
doesn't return!".


I don't think `typeof(*null)`, or `typeof(assert(0))` brings 
any advantage in term of real life user code, and I don't think 
it's worth the confused users that would look at code and go 
"Uh? What is the type of *null?" or "I thought assert was void! 
What would you get the type of assert()?".


Yes, this!

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

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

--- Comment #17 from anonymous4  ---
(In reply to Vladimir Panteleev from comment #15)
> (In reply to Jonathan M Davis from comment #13)
> > That's a separate bug though: bug #17596.
> 
> Clickable link: issue 17596
> 
> See the Bugzilla manual:
> https://www.bugzilla.org/docs/4.4/en/html/hintsandtips.html#idp6611456

Autolinkification for bug 17596 syntax used to work, but is no more.

--

Re: Building DMD on OpenBSD

[Joakim via Digitalmars-d]

On Monday, 17 July 2017 at 16:45:28 UTC, Anonymous wrote:

On Monday, 17 July 2017 at 09:58:42 UTC, Joakim wrote:
The last dmd we released that was written in C++ was 2.067, 
for which you can still check out the branch.  Youd have 
to build that bootstrap compiler 2.067 first, then worry about 
the latest dmd.


Since we dont regularly build for OpenBSD, its 
possible that support has slipped behind.  Usually, its 
as easy as adding OpenBSD to a couple more #ifdefs, but 
sometimes you need to adapt the dmd source also for a rarely 
used platform like OpenBSD.


I managed to build the bootstrap dmd without any trouble. Btw 
the wiki page doesnt mention that the dependency is *GNU* 
Make which is typically installed as gmake on BSDs. Then I 
tried building the new dmd and got (in dmd/src):


CC=c++ dmd -of../generated/openbsd/release/64/idgen ddmd/idgen.d
Error: cannot find source code for runtime library file 
object.d
   dmd might not be correctly installed. Run dmd 
-man for installation instructions.

   config file: /etc/dmd.conf
Specify path to file object.d with -I switch
gmake[1]: *** [posix.mak:437: 
../generated/openbsd/release/64/idgen] Error 1


Now Im trying to figure out the /etc/dmd.conf business. I 
found ini/freebsd/bin64/dmd.conf in the 2.067 dmd folder so I 
guess Ill start from there. Thanks for the help so far.


Unfortunately, dmd has not kept porters in mind and hasn't kept 
the C++ version updated, or kept a workflow that enables easy 
bootstrapping:


http://forum.dlang.org/thread/xgtbpcvbikxlilanr...@forum.dlang.org

You will have to build druntime and phobos for 2.067 also and 
collect it all in a different location, which you could invoke to 
bootstrap a new dmd.  You may run into issues related to D/C++ 
integration when building the latest dmd, as that hasn't been 
tested on OpenBSD, only FreeBSD.


Why do you want the latest dmd on OpenBSD?  I ask because it will 
likely require some work, though likely not a lot.

Re: Error: -o no longer supported, use -of or -od

[Jonathan Marler via Digitalmars-d]

On Monday, 17 July 2017 at 16:08:30 UTC, Zaheer Ahmed wrote:

When Compiling kernel.d with makefile I get
Error: -o no longer supported, use -of or -od
and my Makefile Commands to do this is following.

DMDPARAMS = -m32
//...some objects
%.o: %.d
   dmd $(DMDPARAMS) -o $@ -c $<


 dmd $(DMDPARAMS) -of$@ -c $<

regex(q"<[^]>")

[unDEFER via Digitalmars-d]

Hello!
The code in the header leads to assertion!
But the user inputed data don't must leads to any assertions!

Re: Building DMD on OpenBSD

[Anonymous via Digitalmars-d]

On Monday, 17 July 2017 at 09:58:42 UTC, Joakim wrote:
The last dmd we released that was written in C++ was 2.067, for 
which you can still check out the branch.  Youd have to 
build that bootstrap compiler 2.067 first, then worry about the 
latest dmd.


Since we dont regularly build for OpenBSD, its 
possible that support has slipped behind.  Usually, its 
as easy as adding OpenBSD to a couple more #ifdefs, but 
sometimes you need to adapt the dmd source also for a rarely 
used platform like OpenBSD.


I managed to build the bootstrap dmd without any trouble. Btw the 
wiki page doesnt mention that the dependency is *GNU* Make 
which is typically installed as gmake on BSDs. Then I tried 
building the new dmd and got (in dmd/src):


CC=c++ dmd -of../generated/openbsd/release/64/idgen ddmd/idgen.d
Error: cannot find source code for runtime library file 
object.d
   dmd might not be correctly installed. Run dmd 
-man for installation instructions.

   config file: /etc/dmd.conf
Specify path to file object.d with -I switch
gmake[1]: *** [posix.mak:437: 
../generated/openbsd/release/64/idgen] Error 1


Now Im trying to figure out the /etc/dmd.conf business. I 
found ini/freebsd/bin64/dmd.conf in the 2.067 dmd folder so I 
guess Ill start from there. Thanks for the help so far.

[Issue 17645] `pure` is transitively applied to all delegates inside a pure function

[via Digitalmars-d-bugs]

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

--- Comment #6 from Tomer Filiba (weka)  ---
Opened https://issues.dlang.org/show_bug.cgi?id=17659

--

[Issue 17659] New: `pure` causes function to be inferred as a delegate

[via Digitalmars-d-bugs]

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

  Issue ID: 17659
   Summary: `pure` causes function to be inferred as a delegate
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: to...@weka.io

Consider the following

void indirectCall(T)(T fn) {
pragma(msg, T);
}

__gshared int x;

void f() {
indirectCall({x++;});  // void function() nothrow @nogc @system
}

void g() pure {
indirectCall({x++;}); // pure delegate 'dtest.g.__lambda1' cannot
access mutable static data 'x'
}

please ignore the mutable state issue -- the issue here that `{x++}` is treated
as a function

--

[Issue 17645] `pure` is transitively applied to all delegates inside a pure function

[via Digitalmars-d-bugs]

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

--- Comment #5 from Tomer Filiba (weka)  ---
(In reply to Steven Schveighoffer from comment #4)
> `format` actually is pure.

nitpicking. sure, format may be pure, but the variables i want to log in the
assert may be __gshared and then i can't access them. or i may want to invoke
some impure functions to add extra info before the process dies. e.g.

assert (cond, "%s x=%s".format(getTimeOfDay(), x));

> In your new example, you are actually calling the
> GC-allocating function from inside a @nogc context, not creating a delegate.
> Even if you did create a delegate and needed to save the context, that
> creates a closure, and that definitely needs the GC.

the ASSERT function takes a `scope delegate` so no closure of GC is needed.
unless it blows up, and then i'm ok with that.

> So you have a few choices here:
> 
> 1. Update the bug to say that these should be inferred as functions (even if
> you don't do this, another bug should be filed).
> 2. Argue that a delegate with a context of a pure function should be able to
> be unpure, and demonstrate why that's needed with an updated use case.
> 3. Alter the bug report to mean something different.

opting for 2. i will file another bug for the inference issue, but i don't see
why this is not a bug. the fact i *create* a delegate in a pure scope shouldn't
force the *delegate* to be pure. i shouldn't be able to *invoke* that impure
delegate, just like i shouldn't be able to invoke any other impure function.
but that's not the issue. once i have a delegate, i just cast it to a pure one
-- and this will happen only when the assert blows up.

and the function(){} hack won't help me, because i require access to
arguments/variables on the function's stack.

--

[Issue 17658] Shared postblits and dtors conflict with non-shared versions

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||16535

--

[Issue 17658] Shared postblits and dtors conflict with non-shared versions

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks|15768   |

--

[Issue 15768] std.stdio.trustedStdout accesses __gshared data without synchronization.

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 Depends on|17658   |

--