Re: Silicon Valley D Meetup - December 22, 2016 - "The Curse of Knowledge: Et tu, D?" by Adam Wilson

[Ali Çehreli via Digitalmars-d-announce]

On 12/15/2016 12:20 AM, Ali Çehreli wrote:


  https://www.meetup.com/D-Lang-Silicon-Valley/events/236253882/


The slides: 
http://files.meetup.com/18234529/The%20Curse%20of%20Knowledge.pptx


The video: http://youtu.be/XjnBMfVTI0k

(There is no audio on the recording until 45:45.)

Ali

Re: Many documentation examples can now be run online

[Seb via Digitalmars-d-announce]

On Saturday, 24 December 2016 at 06:08:49 UTC, Saurabh Das wrote:

On Saturday, 24 December 2016 at 00:04:54 UTC, Seb wrote:

Hehe, that's already in the queue:

https://github.com/dlang/dlang.org/pull/1529


This is really wonderful. An excellent feature for new users – 
lowers the cost of "just try it out".


Feedback:


Thanks for your feedback :)

1. It will be aesthetically better if the edit/run buttons are 
inside the code box, say just inside the right top corner.


Sure - that should be fairly trivial.

2. Could we add a "open in an external website/new window" 
icon/button (for example: 
http://findicons.com/files/icons/2315/default_icon/256/open_in_new_window.png ) to open the example in say a dpaste window or an equivalent playground.


Yes, that would be pretty nice to have.
Unfortunately the maintainer of DPaste has been quite 
unresponsive in the past, so it's not possible with DPaste (e.g. 
we would need a simple POST API which returns a URL).
If someone is planning to reboot sth. like DPaste (e.g. with DUB 
support, fast caches, ...), please let us know!

[Issue 17025] New: integrate dmd docs on dlang.org

[via Digitalmars-d-bugs]

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

  Issue ID: 17025
   Summary: integrate dmd docs on dlang.org
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: greeen...@gmail.com

Since a couple of month Ddoc documentation generation of DMD has been enabled,
see e.g. http://dlang.org/dmd-prerelease/expression.html

However it's not visible to a user in any way yet and I think the docs will
only get better if they are exposed to the public - see e.g.

http://forum.dlang.org/post/jlzrarkeqwjvyabfi...@forum.dlang.org

Moreover, the menu on the left of course needs to be include the DMD modules
for easy navigation.

Also note that there's a scheduled move to ddox:

http://forum.dlang.org/post/niv6b9$2q5l$1...@digitalmars.com

--

Re: Many documentation examples can now be run online

[safety0ff via Digitalmars-d-announce]

On Saturday, 24 December 2016 at 06:08:49 UTC, Saurabh Das wrote:


Feedback:

1. It will be aesthetically better if the edit/run buttons are 
inside the code box, say just inside the right top corner.


I agree the button placement should be improved, I think they 
should be immediately to the right of "Examples:"


e.g. "Examples: [Edit][Run]"

Which makes it more clear that the examples can be run & edited.

Re: Many documentation examples can now be run online

[Saurabh Das via Digitalmars-d-announce]

On Saturday, 24 December 2016 at 00:04:54 UTC, Seb wrote:
On Friday, 23 December 2016 at 23:52:48 UTC, Johan Engelen 
wrote:

On Tuesday, 20 December 2016 at 07:04:38 UTC, Seb wrote:


https://github.com/dlang/dlang.org/pull/1527


Nice. It's pretty awesome!

When clicking the "edit" button, a new box appears with the 
example's code in it but editable. Then when clicking "run", 
the editted code disappears (it's saved for future use, pfew!).


How about this: when clicking _either_ "edit" or "run", the 
non-editable code box disappears, and the edittable code box 
appears and stays there forever.


(also, the height of the editable-code-box is too small; 
should fit the whole example's code?)


cheers,
  Johan


Hehe, that's already in the queue:

https://github.com/dlang/dlang.org/pull/1529


This is really wonderful. An excellent feature for new users – 
lowers the cost of "just try it out".


Feedback:

1. It will be aesthetically better if the edit/run buttons are 
inside the code box, say just inside the right top corner.


2. Could we add a "open in an external website/new window" 
icon/button (for example: 
http://findicons.com/files/icons/2315/default_icon/256/open_in_new_window.png ) to open the example in say a dpaste window or an equivalent playground.


Thanks,
Saurabh

[Issue 12647] Lazy parameter evaluation should be marked as nothrow

[via Digitalmars-d-bugs]

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

--- Comment #7 from greenify  ---
There's a newer attempt by LemonBoy:

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

--

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/16 9:23 PM, Chris Wright wrote:

The comparison to mach.d is a strawman.


The mach.d is given as an example of the approach of breaking code into 
fine-grained module. No comparison is made or implied.



Then I looked at the code.

Phobos has 26 templates that would use this special syntax, referencing
14 distinct templates and CTFE functions in three modules.


Could you please give more detail about the method you used? What 
special syntax are you referring to - would that be the "with (import 
...)" syntax? If that's the case there's a bunch of stuff missing. 
Consider e.g.:


int cmp(alias pred = "a < b", R1, R2)(R1 r1, R2 r2)
if (isInputRange!R1 && isInputRange!R2 && !(isSomeString!R1 && 
isSomeString!R2));


int cmp(alias pred = "a < b", R1, R2)(R1 r1, R2 r2)
if (isSomeString!R1 && isSomeString!R2);

These and many like them would use the "with import" construct, wouldn't 
they? They are missing from your list.



The templates that have to be parsed are std.traits, std.meta, and
std.range.primitives.


That's where most introspection primitives for the standard library are 
situated indeed.



I wrote a test program that imported them without
using them. It compiled in too little time to accurately measure --
`time` reports 0.01s wall time.

You want to add new language syntax to save me ten milliseconds during
compilation.


DIP1005 enumerates several benefits of the proposed feature. Speed is 
not the most important and is not presented as such, but it takes most 
space because the others are more difficult to experiment with without 
an experimental implementation.



You hope that template constraints become more common.


Well, to the extent that is the way correct code is written, that's more 
than just hope.



If they do, this
change relies on:

* projects defining their own constraints (not just using std.traits)
* those constraints being defined in modules other than where they're used
* those constraints being defined in very large modules
* my code not depending on anything in those constraint-defining modules
* my code depending on something in a file with a template with one of
those constraints
* this whole situation being common enough to give me a death by a
thousand papercuts


It's not only constraints, it's everything in declarations that relies 
on entities (e.g. types) defined in other modules. And again the 
feature's benefits go well beyond making general projects faster to build.


A simple way to look at things is - local imports are The Right Thing, 
for many reasons beyond compilation speed. There needs to be a way to do 
the right thing for the declaration part as well.


(I'm glad we're getting to the point of diminished returns - I recall an 
argument made a while ago was that, on the contrary, our compilation 
model cannot possibly scale for large projects.)



Appendix A: templates that would receive 'with(import foo)' in Phobos.


Could you please provide more detail on how you measured this and what 
assumptions you made? Most templates in Phobos would receive a with 
clause, so there's a disconnect somewhere.



Andrei

Re: How to detect free/unfree memory segments?

[Suliman via Digitalmars-d-learn]

On Saturday, 24 December 2016 at 01:15:43 UTC, jkpl wrote:

On Friday, 23 December 2016 at 06:18:02 UTC, Suliman wrote:
I would like to visualize how GC works and display free/not 
free memory segments.

How I can understand which of them are used and which not?

Could anybody explain what dangerous of memory fragmentation 
in languages without GC? Am I right understand that there is 
stay some small memory chunks that very hard to reuse?


You start with a wrong assumption. The C malloc functions is 
not just a nasty and mean memory provider. Several 
implementations uses internally freelists. Which means that the 
gaps created by a free() may be filled again.


For example
- TCMallocator use free lists
- GCC C malloc use free lists (as stated here 
http://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html)

- for snn.lib malloc (used by DMD win32) I can't say.


So there is no any problems with memory fragmentation and all 
used memory arr successfuly reuse?

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Chris Wright via Digitalmars-d]

tldr: the performance impact of this DIP would be too small to easily 
measure and only impacts 26 declarations referencing 14 templates in the 
standard library anyway.

On Fri, 23 Dec 2016 18:55:25 -0500, Andrei Alexandrescu wrote:
>> I grant that everyone uses phobos, and phobos uses template constraints
>> a lot. If it's *just* a problem inside phobos, though, there's another
>> obvious solution: split up modules that tend to house a lot of template
>> constraints. Split up the modules that use a wide variety of template
>> constraints.
> 
> This point is discussed carefully in DIP1005. Please let me know if
> anything needs to be added.

An estimate for the actual impact on phobos, since that's your primary 
driver for the change -- both under the status quo and if we try to split 
modules.

The comparison to mach.d is a strawman. When I thought this might be a 
problem within phobos, I thought we'd probably split std.traits and maybe 
std.meta up, probably into 2-5 modules each. Not 150 lines per module; 
more like 1500 to 4000 lines per module.

Then I looked at the code.

Phobos has 26 templates that would use this special syntax, referencing 
14 distinct templates and CTFE functions in three modules.

If you kept the same ratios as are found in mach.d, you'd have one file 
for every template used as a constraint outside its own module, one for 
everything else, and as many files again with nothing in them.

The templates that have to be parsed are std.traits, std.meta, and 
std.range.primitives. I wrote a test program that imported them without 
using them. It compiled in too little time to accurately measure -- 
`time` reports 0.01s wall time.

You want to add new language syntax to save me ten milliseconds during 
compilation.

You hope that template constraints become more common. If they do, this 
change relies on:

* projects defining their own constraints (not just using std.traits)
* those constraints being defined in modules other than where they're used
* those constraints being defined in very large modules
* my code not depending on anything in those constraint-defining modules
* my code depending on something in a file with a template with one of 
those constraints
* this whole situation being common enough to give me a death by a 
thousand papercuts

If any project aside from the standard library has a 7k line module 
defining things mainly used in template constraints, something is 
seriously weird. But on the plus side, it would only cost me 10 
milliseconds. Now, if *dozens* of projects did that, well, I'd be running 
to the relative simplicity of Java APIs long before I worried about 
compilation speed.

> Lazier compilation is indeed a projected benefit of this DIP. I did not
> want to dilute the thrust of the proposal with a remote promise.

Lazier compilation would *obviate* this DIP. Lazy compilation of 
selective and static imports would not require any parser changes and 
would make a lot of code faster (at the cost of allowing some things that 
don't compile to start compiling, as does your proposal). You can't get 
any performance advantages outside templates without implementing lazy 
imports.



Appendix A: templates that would receive 'with(import foo)' in Phobos.

I used a relatively simple regex to look for this. If someone put more 
than one line between a template and its constraints, or comments with 
certain formatting, I may have missed it. However, that would violate the 
phobos style guide.

This doesn't include templates that use constraints defined in their own 
modules, because that module must already be parsed and no efficiency 
gains could be realized.

It also omits a few cases where the module has a strong reason to import 
the dependency aside from template constraints. I believe this was only 
two constraints defined in std.digest, used in one or two other modules.

algorithm/comparison.d:98:template among(values...)
experimental/typecons.d:82:private template implementsInterface(Source, 
Targets...)
experimental/typecons.d:94:template implementsInterface()
experimental/typecons.d:126:private template implementsInterface(Source, 
Targets...)
experimental/typecons.d:184:template wrap(Targets...)
experimental/typecons.d:237:template wrap(Source)
range/package.d:2069:template Take(R)
range/package.d:3501:template Cycle(R)
range/interfaces.d:277:template MostDerivedInputRange(R)
range/interfaces.d:336:template InputRangeObject(R)
numeric.d:678:template FPTemporary(F)
conv.d:3894:template octal(alias decimalInteger)
utf.d:1136:package template codeUnitLimit(S)
typecons.d:1779:private mixin template RebindableCommon(T, U, alias This)
typecons.d:1838:template Rebindable(T)
typecons.d:4239:template wrap(Targets...)
typecons.d:4252:template wrap(Source)
typecons.d:4412:template wrap(Targets...)
typecons.d:4429:template unwrap(Target)
typecons.d:4461:template unwrap(Target)
format.d:657:template FormatSpec(Char)

Re: Optimization problem: bulk Boolean operations on vectors

[Stefan Koch via Digitalmars-d]

On Saturday, 24 December 2016 at 01:38:24 UTC, safety0ff wrote:
On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright 
wrote:


For this D code:

enum SIZE = 1;

void foo(int* a, int* b) {
int* atop = a + 1000;
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}


Is subtraction of pointers which do not belong to the same 
array defined behavior in D?


Yes, I think so.
There are not crazy rules to make pointer math ub.

Re: Optimization problem: bulk Boolean operations on vectors

[Walter Bright via Digitalmars-d]

On 12/23/2016 5:06 PM, hardreset wrote:

I patched up the prolog code and timed it and it came out identical to my asm. I
tried the ptrdiff C-like code and that still comes out 20% slower here. I'm
compiling with...

rdmd test.d -O -release -inline

Am I missing something? How do I get the asm output?


dmd test -O
obj2asm test.obj

Re: Optimization problem: bulk Boolean operations on vectors

[safety0ff via Digitalmars-d]

On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright wrote:


For this D code:

enum SIZE = 1;

void foo(int* a, int* b) {
int* atop = a + 1000;
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}


Is subtraction of pointers which do not belong to the same array 
defined behavior in D?

Re: How to detect free/unfree memory segments?

[jkpl via Digitalmars-d-learn]

On Friday, 23 December 2016 at 06:18:02 UTC, Suliman wrote:
I would like to visualize how GC works and display free/not 
free memory segments.

How I can understand which of them are used and which not?

Could anybody explain what dangerous of memory fragmentation in 
languages without GC? Am I right understand that there is stay 
some small memory chunks that very hard to reuse?


You start with a wrong assumption. The C malloc functions is not 
just a nasty and mean memory provider. Several implementations 
uses internally freelists. Which means that the gaps created by a 
free() may be filled again.


For example
- TCMallocator use free lists
- GCC C malloc use free lists (as stated here 
http://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html)

- for snn.lib malloc (used by DMD win32) I can't say.

Re: Optimization problem: bulk Boolean operations on vectors

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/2016 08:06 PM, hardreset wrote:


rdmd test.d -O -release -inline


This passes the three flags to test.d. Place test.d at the end.

Re: Optimization problem: bulk Boolean operations on vectors

[hardreset via Digitalmars-d]

On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright wrote:

On 12/23/2016 10:03 AM, hardreset wrote:

For this D code:

enum SIZE = 1;

void foo(int* a, int* b) {
int* atop = a + 1000;
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}

The following asm is generated by DMD:

pushEBX
mov EBX,8[ESP]
sub EAX,EBX
pushESI
cdq
and EDX,3
add EAX,EDX
sar EAX,2
lea ECX,0FA0h[EBX]
mov ESI,EAX
cmp EBX,ECX
jae L2C
L20:mov EDX,[ESI*4][EBX]
and [EBX],EDX
add EBX,4
cmp EBX,ECX
jb  L20
L2C:pop ESI
pop EBX
ret 4

The inner loop is 5 instructions, whereas the one you wrote is 
7 instructions (I didn't benchmark it). With some more source 
code manipulation the divide can be eliminated, but that is 
irrelevant to the inner loop.


I patched up the prolog code and timed it and it came out 
identical to my asm. I tried the ptrdiff C-like code and that 
still comes out 20% slower here. I'm compiling with...


rdmd test.d -O -release -inline

Am I missing something? How do I get the asm output?

Re: How to initialize a associative array?

[Nicholas Wilson via Digitalmars-d-learn]

On Saturday, 24 December 2016 at 00:57:04 UTC, Yuxuan Shui wrote:
On Saturday, 24 December 2016 at 00:55:01 UTC, Yuxuan Shui 
wrote:

I tried this:

immutable int[char] xx = ['Q':0, 'B':1, 'N':2, 'R':3, 
'P':4];


And got a "non-constant expression" error (with or without 
'immutable').


What's the correct way?


This example here: https://dlang.org/spec/hash-map.html, 
doesn't work either.


Is this at global scope?

You need to use a `shared static this() { ... }` to initialise it.

How to initialize a associative array?

[Yuxuan Shui via Digitalmars-d-learn]

I tried this:

immutable int[char] xx = ['Q':0, 'B':1, 'N':2, 'R':3, 'P':4];

And got a "non-constant expression" error (with or without 
'immutable').


What's the correct way?

Re: Simplest way to build a DMD compatible C lib, and how to link using DUB.

[hardreset via Digitalmars-d-learn]

On Saturday, 17 December 2016 at 04:58:45 UTC, Mike Parker wrote:

On Friday, 16 December 2016 at 22:37:13 UTC, hardreset wrote:

To be honest I was having some odd linking problems anyway. I 
initially wrapped the FT init function in plain D function and 
that kept causing "_FT_ not found" link errors. As soon as 
I took all the actual D functions out and left just FT 
declarations in there it stopped. Even now if I add...


int foo() { return 0; }

to my freetype.d (contains just FT interface declarations)

and call it from font.d (my font class)

i start getting linker errors. Why would adding a plain D 
function suddenly make it sound the linker cant find what it 
needs in the freetype.lib?


The only thing I can think of offhand: did you compile and link 
your freetype.d? As long as it's just interface declarations, 
there's no need to -- it only needs to be on the import path. 
But once you start adding implementations, it needs to be 
compiled and linked into the executable.


Yeah that was it. I had it in a separate folder for libs and 
mistakenly assumed that because it was importing OK that mean it 
was being compiled and linked too. I moved it into the source 
folder and it worked fine! It makes sense now.


thanks for the help!

[Issue 16950] [Downloads]

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

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

--- Comment #1 from greenify  ---
Hmm a beta can always be downloaded with:

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

(same for dmd-nightly)

I think at the moment the policy is that betas are mere "preview" builds and
are not officially released. Only the point releases are, e.g:

http://dlang.org/changelog/2.072.1.html

So I am closing this as invalid, but feel free to reopen if you disagree or
sth. like this happens again ;-)

--

[Issue 17024] New: check Phobos for convenience wrapper for templated struct

[via Digitalmars-d-bugs]

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

  Issue ID: 17024
   Summary: check Phobos for convenience wrapper for templated
struct
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greeen...@gmail.com

Helps to let the compiler do its job. This style is very common in newer
modules of Phobos, but older bits still lack it.

One example from https://github.com/dlang/phobos/pull/4989

NullableRef!(int)() -> nullableRef();


Another example is [Unique](https://dlang.org/phobos/std_typecons.html#.Unique)

--

Re: Many documentation examples can now be run online

[Seb via Digitalmars-d-announce]

On Friday, 23 December 2016 at 23:52:48 UTC, Johan Engelen wrote:

On Tuesday, 20 December 2016 at 07:04:38 UTC, Seb wrote:


https://github.com/dlang/dlang.org/pull/1527


Nice. It's pretty awesome!

When clicking the "edit" button, a new box appears with the 
example's code in it but editable. Then when clicking "run", 
the editted code disappears (it's saved for future use, pfew!).


How about this: when clicking _either_ "edit" or "run", the 
non-editable code box disappears, and the edittable code box 
appears and stays there forever.


(also, the height of the editable-code-box is too small; should 
fit the whole example's code?)


cheers,
  Johan


Hehe, that's already in the queue:

https://github.com/dlang/dlang.org/pull/1529

Re: Optimization problem: bulk Boolean operations on vectors

[Walter Bright via Digitalmars-d]

On 12/23/2016 3:35 PM, Johan Engelen wrote:

On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright wrote:


enum SIZE = 1;

void foo(int* a, int* b) {
int* atop = a + 1000; // should be `a + SIZE`, right?
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}


This code is not equivalent with the plain foreach loop. Execution is different
when a > (size_t.max-SIZE).


The assumption is that 'a' points to the start of an array [0..SIZE], so there's 
no overflow.



Thus the "ptrdiff" loop cannot be vectorized (or can
only be vectorized when guarded with a check for potential overflow first).
LDC:
https://godbolt.org/g/YcCJdZ
(note the funny jmp .LBB1_6 to a ret instruction... what's that?!)

GDC does something more complex:
https://godbolt.org/g/3XeI9p

Just for info. Don't know which is faster, but I'm guessing the vectorized
foreach loop.


The vectorized one probably is. But it sure is a lot of code. (The loop speed 
could possibly be doubled just by unrolling it a few times.)

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/2016 05:33 PM, Chris Wright wrote:

On Fri, 23 Dec 2016 11:25:41 -0500, Andrei Alexandrescu wrote:

Dependency-Carrying Declarations allow scalable template libraries.



template libraries


*This* is the part I hadn't noticed before, and it explains the confusion
I had.

If you *only* apply this to templates, it works. The current situation is
a result of where template constraints are located. If there were a
`static throw` equivalent for indicating that parameters were invalid, or
if template constraints were in an `in` block like contracts, then this
wouldn't even have come up. If phobos went for object oriented code
instead of templates (as an example, not a recommendation), then this
wouldn't be an issue.


I acknowledge that if the language were defined a different way this 
issue wouldn't have come up. But this is a truism - one can say that 
about any issue.



However, at that point, it would be utterly useless to me. I'm looking at
my entire dub package cache, plus the ten-ish most recently updated dub
packages:

* units-d uses allSatisfy. Once.
* vibe has two structs that would benefit, except they're inside a
unittest. I've never compiled dub's unittests.


Fair enough. I reckon a number of traditional ways of designing software 
would not be helped radically by DIP1005.



Template constraints have little adoption outside phobos.


That will change. We definitely need to do all we can to support and 
improve language support for template constraints.



When they *are*
used, they tend to use language facilities instead of templates to
express the condition. And when a template is used, it tends to be
defined in the same module where it's used.


That may be true for some code today but not for future code. std.traits 
gets larger and better with more interesting introspection capabilities. 
I envision introspection as a core differentiating feature of D that 
will put it ahead of all other languages.



I grant that everyone uses phobos, and phobos uses template constraints a
lot. If it's *just* a problem inside phobos, though, there's another
obvious solution: split up modules that tend to house a lot of template
constraints. Split up the modules that use a wide variety of template
constraints.


This point is discussed carefully in DIP1005. Please let me know if 
anything needs to be added.



Now, if you want to apply this to things that are *not* templates, then
you could get a lot further. However, you would end up with code that
compiles when it wouldn't today. Code that compiles because the portions
you use would compile if they were on their own, while other bits
wouldn't. That's the status quo for templates, even no-arg templates, but
a change from what we currently do everywhere else.

And *that* is what would make it equivalent to use static or selective
imports. It would also increase the utility from my perspective from "why
the hell are we even doing this?" to "that's kinda nice".


Lazier compilation is indeed a projected benefit of this DIP. I did not 
want to dilute the thrust of the proposal with a remote promise.



Andrei

Re: Many documentation examples can now be run online

[Johan Engelen via Digitalmars-d-announce]

On Tuesday, 20 December 2016 at 07:04:38 UTC, Seb wrote:


https://github.com/dlang/dlang.org/pull/1527


Nice. It's pretty awesome!

When clicking the "edit" button, a new box appears with the 
example's code in it but editable. Then when clicking "run", the 
editted code disappears (it's saved for future use, pfew!).


How about this: when clicking _either_ "edit" or "run", the 
non-editable code box disappears, and the edittable code box 
appears and stays there forever.


(also, the height of the editable-code-box is too small; should 
fit the whole example's code?)


cheers,
  Johan

Re: Optimization problem: bulk Boolean operations on vectors

[Johan Engelen via Digitalmars-d]

On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright wrote:


enum SIZE = 1;

void foo(int* a, int* b) {
int* atop = a + 1000; // should be `a + SIZE`, right?
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}


This code is not equivalent with the plain foreach loop. 
Execution is different when a > (size_t.max-SIZE). Thus the 
"ptrdiff" loop cannot be vectorized (or can only be vectorized 
when guarded with a check for potential overflow first).

LDC:
https://godbolt.org/g/YcCJdZ
(note the funny jmp .LBB1_6 to a ret instruction... what's that?!)

GDC does something more complex:
https://godbolt.org/g/3XeI9p

Just for info. Don't know which is faster, but I'm guessing the 
vectorized foreach loop.

[Issue 17023] New: opUnaryAssign is missing

[via Digitalmars-d-bugs]

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

  Issue ID: 17023
   Summary: opUnaryAssign is missing
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

opUnaryAssign operator method for overloading is missing.
It is required for pointer simulation in code like:

---
*ptr = value;
---

when *ptr can not return by reference.

Required for mir/ndslice.

--

Re: Red Hat's issues in considering the D language

[rikki cattermole via Digitalmars-d]

On 24/12/2016 7:29 AM, Russel Winder via Digitalmars-d wrote:

On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d
wrote:

[…]

Except dmd's backend is far more well proven then LLVM is.


Come now that is obfuscation – you need to make good on this claim.

The LLVM backend has many, many more users than the DMD backend and the
LLVM backend is used with many more different languages than the DMD
backend. The LLVM backend is proven far more than the DMD backend
simply on the basis of statistical likelihood.

I'll back LLVM any day in this argument.


So that argument needs to be tweaked a little bit.


No it doesn't, it stands as stated.


My entire argument there is from its age.

Re: Red Hat's issues in considering the D language

[Nicholas Wilson via Digitalmars-d]

On Friday, 23 December 2016 at 22:41:28 UTC, Chris Wright wrote:
On Fri, 23 Dec 2016 18:29:15 +, Russel Winder via 
Digitalmars-d wrote:


On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via 
Digitalmars-d wrote:

[…]

Except dmd's backend is far more well proven then LLVM is.


Come now that is obfuscation – you need to make good on this 
claim.


The LLVM backend has many, many more users than the DMD 
backend and the LLVM backend is used with many more different 
languages than the DMD backend. The LLVM backend is proven far 
more than the DMD backend simply on the basis of statistical 
likelihood.


Plus the number of people on hand to fix errors in LLVM 
outweighs the number available to fix errors in the DigitalMars 
backend by a factor of several hundred.


Although there is a small delay in that. While we try to remain 
compilable with LLVM trunk it does tend to break frequently and 
you then have to use llvm trunk.

Re: Red Hat's issues in considering the D language

[Chris Wright via Digitalmars-d]

On Fri, 23 Dec 2016 18:29:15 +, Russel Winder via Digitalmars-d wrote:

> On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d
> wrote:
>> […]
>> 
>> Except dmd's backend is far more well proven then LLVM is.
> 
> Come now that is obfuscation – you need to make good on this claim.
> 
> The LLVM backend has many, many more users than the DMD backend and the
> LLVM backend is used with many more different languages than the DMD
> backend. The LLVM backend is proven far more than the DMD backend simply
> on the basis of statistical likelihood.

Plus the number of people on hand to fix errors in LLVM outweighs the 
number available to fix errors in the DigitalMars backend by a factor of 
several hundred.

Re: Red Hat's issues in considering the D language

[Chris Wright via Digitalmars-d]

On Fri, 23 Dec 2016 07:59:40 -0800, Jonathan M Davis via Digitalmars-d
wrote:
> dmd compiles code faster, which is better from a development standpoint.
> Assuming that dmd and ldc are compatible enough, it makes a lot of sense
> to do most of the development with dmd and produce the actual product
> with ldc.

You'll want your CI server to build with both thanks to ABI 
incompatibilities. That way, if I depend on a library that you wrote, I 
can grab an official build from the CI server that's ABI-compatible with 
DMD. Or do everything from source.

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

[Chris Wright via Digitalmars-d]

On Fri, 23 Dec 2016 11:25:41 -0500, Andrei Alexandrescu wrote:
> Dependency-Carrying Declarations allow scalable template libraries.

> template libraries

*This* is the part I hadn't noticed before, and it explains the confusion 
I had.

If you *only* apply this to templates, it works. The current situation is 
a result of where template constraints are located. If there were a 
`static throw` equivalent for indicating that parameters were invalid, or 
if template constraints were in an `in` block like contracts, then this 
wouldn't even have come up. If phobos went for object oriented code 
instead of templates (as an example, not a recommendation), then this 
wouldn't be an issue.

However, at that point, it would be utterly useless to me. I'm looking at 
my entire dub package cache, plus the ten-ish most recently updated dub 
packages:

* units-d uses allSatisfy. Once.
* vibe has two structs that would benefit, except they're inside a 
unittest. I've never compiled dub's unittests.

Template constraints have little adoption outside phobos. When they *are* 
used, they tend to use language facilities instead of templates to 
express the condition. And when a template is used, it tends to be 
defined in the same module where it's used.

I grant that everyone uses phobos, and phobos uses template constraints a 
lot. If it's *just* a problem inside phobos, though, there's another 
obvious solution: split up modules that tend to house a lot of template 
constraints. Split up the modules that use a wide variety of template 
constraints.

Then I can decide whether the convenience of not hunting for narrower 
imports is worth the extra quarter second of compilation.



Now, if you want to apply this to things that are *not* templates, then 
you could get a lot further. However, you would end up with code that 
compiles when it wouldn't today. Code that compiles because the portions 
you use would compile if they were on their own, while other bits 
wouldn't. That's the status quo for templates, even no-arg templates, but 
a change from what we currently do everywhere else.

And *that* is what would make it equivalent to use static or selective 
imports. It would also increase the utility from my perspective from "why 
the hell are we even doing this?" to "that's kinda nice".

Re: Optimization problem: bulk Boolean operations on vectors

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/2016 05:11 PM, Walter Bright wrote:

void foo(int* a, int* b) {
int* atop = a + 1000;
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}


That's a neat trick, thanks hardreset (and Walter for making it 
high-level). There are a bunch of places in druntime and phobos that 
could use it. -- Andrei

Re: Optimization problem: bulk Boolean operations on vectors

[Walter Bright via Digitalmars-d]

On 12/23/2016 10:03 AM, hardreset wrote:

enum SIZE = 1;

void foo3(int* a, int* b)
{
asm
{
mov   EAX,a;
mov   EDX,b;
sub   EDX,EAX;
mov   ECX,EAX;
add   ECX,SIZE*4;
l1:;
cmp   EAX,ECX;
jae   done;
mov   EBX,[EAX];
and   EBX,[EAX+EDX];
mov   [EAX],EBX;
add   EAX,4;
jmp l1;
done:;
}
}

I get..

456ms for unconditional
505ms for conditional
268ms for assembler

So the asm is about 40% faster than the best of the alternatives. The point
being that it's the generated code not the source that's the problem.


For this D code:

enum SIZE = 1;

void foo(int* a, int* b) {
int* atop = a + 1000;
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &= *(a + offset);
}

The following asm is generated by DMD:

pushEBX
mov EBX,8[ESP]
sub EAX,EBX
pushESI
cdq
and EDX,3
add EAX,EDX
sar EAX,2
lea ECX,0FA0h[EBX]
mov ESI,EAX
cmp EBX,ECX
jae L2C
L20:mov EDX,[ESI*4][EBX]
and [EBX],EDX
add EBX,4
cmp EBX,ECX
jb  L20
L2C:pop ESI
pop EBX
ret 4

The inner loop is 5 instructions, whereas the one you wrote is 7 instructions (I 
didn't benchmark it). With some more source code manipulation the divide can be 
eliminated, but that is irrelevant to the inner loop.

[Issue 14224] std.range.chunks variable chunk size

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||trivial
 CC||edi33...@gmail.com

--

[Issue 15364] BitArray.len should be private

[via Digitalmars-d-bugs]

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

--- Comment #6 from Steven Schveighoffer  ---
Just as a matter of record, here is the commit that fixed this issue:

https://github.com/dlang/phobos/commit/43227b12c462ab116539302570eeff1ed6dd8d74

--

[Issue 14006] "Contribute" button/option on the main site and sitemap

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||edi33...@gmail.com
 Resolution|--- |INVALID

--- Comment #3 from Eduard Staniloiu  ---
Closing this since we have a Community drop-down button that provides links to
the wiki, issues, github etc.

--

[Issue 13892] Erroneous information on the variadic template page

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||trivial
 CC||edi33...@gmail.com

--

[Issue 16209] std.string.isNumeric can work with forward ranges

[via Digitalmars-d-bugs]

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

--- Comment #6 from Andrei Alexandrescu  ---
(In reply to Jack Stouffer from comment #5)
> I doubt that parse can handle all of the esoteric inputs that isNumeric can
> handle right now.

That's part of the problem. There's very little use of a function that tells
you something is numeric, that is not complemented by a function that tells you
what the actual number is.

This function is inspired from scripting languages that need it for logic such
as "if it looks like a number, consider it a number". Has no place in D.

--

[Issue 16209] std.string.isNumeric can work with forward ranges

[via Digitalmars-d-bugs]

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

--- Comment #5 from Jack Stouffer  ---
(In reply to Andrei Alexandrescu from comment #4)
> I think we should just undocument `isNumeric` and cease enhancing it. It's a
> terrible function. A simple way to figure out whether something is numeric
> is simply parse it as a number - the work done is similar and you get the
> number too.

1. someone would first need to make sure that every input on isNumeric works
with parse
2. and if so we could just make isNumeric forward to parse 

That way you don't have to go through the deprecation cycle.

I doubt that parse can handle all of the esoteric inputs that isNumeric can
handle right now.

--

[Issue 14608] Enum members should be formatted as a table

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

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

--- Comment #8 from Andrei Alexandrescu  ---
Looks like this is fixed now, right Sönke?

--

[Issue 14561] Large enums cannot be parsed due to too many recursive template expansions

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |WORKSFORME

--- Comment #4 from Andrei Alexandrescu  ---
Could compile quickly with the current dmd.

--

[Issue 15215] Erroneous error messages in to!IntegralType conversions

[via Digitalmars-d-bugs]

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

--- Comment #10 from Andrei Alexandrescu  ---
(In reply to Vladimir Panteleev from comment #9)
> Please use WORKSFORME for entries that have been fixed elsewhere, so they
> don't appear in the changelog.

Roger.

--

[Issue 15215] Erroneous error messages in to!IntegralType conversions

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Resolution|FIXED   |WORKSFORME

--- Comment #9 from Vladimir Panteleev  ---
Please use WORKSFORME for entries that have been fixed elsewhere, so they don't
appear in the changelog.

--

[Issue 14963] Cross-module docs in phobos-prerelease have wrong link targets

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |FIXED

--- Comment #3 from Andrei Alexandrescu  ---
Things look fine now, please reopen if we're missing something.

--

[Issue 15364] BitArray.len should be private

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||and...@erdani.com
 Resolution|--- |FIXED

--- Comment #5 from Andrei Alexandrescu  ---
Current compilation result:

/d498/f670.d(6): Error: no property 'len' for type 'BitArray', did you mean
'_len

--

[Issue 15215] Erroneous error messages in to!IntegralType conversions

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |FIXED

--- Comment #8 from Andrei Alexandrescu  ---
Current output:

Testing string: 2A
to!ubyte  : Unexpected 'A' when converting from type string to type ubyte
to!ushort : Unexpected 'A' when converting from type string to type ushort
to!uint   : Unexpected 'A' when converting from type string to type uint
to!ulong  : Unexpected 'A' when converting from type string to type ulong
to!byte   : Unexpected 'A' when converting from type string to type byte
to!short  : Unexpected 'A' when converting from type string to type short
to!int: Unexpected 'A' when converting from type string to type int
to!long   : Unexpected 'A' when converting from type string to type long

Testing string: -2A
to!ubyte  : Unexpected '-' when converting from type string to type uint
to!ushort : Unexpected '-' when converting from type string to type uint
to!uint   : Unexpected '-' when converting from type string to type uint
to!ulong  : Unexpected '-' when converting from type string to type ulong
to!byte   : Unexpected 'A' when converting from type string to type byte
to!short  : Unexpected 'A' when converting from type string to type short
to!int: Unexpected 'A' when converting from type string to type int
to!long   : Unexpected 'A' when converting from type string to type long

Testing string: #2A
to!ubyte  : Unexpected '#' when converting from type string to type uint
to!ushort : Unexpected '#' when converting from type string to type uint
to!uint   : Unexpected '#' when converting from type string to type uint
to!ulong  : Unexpected '#' when converting from type string to type ulong
to!byte   : Unexpected '#' when converting from type string to type int
to!short  : Unexpected '#' when converting from type string to type int
to!int: Unexpected '#' when converting from type string to type int
to!long   : Unexpected '#' when converting from type string to type long

--

[Issue 15695] Wrong error message in failed conversion from string to int

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |FIXED

--

[Issue 16209] std.string.isNumeric can work with forward ranges

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #4 from Andrei Alexandrescu  ---
I think we should just undocument `isNumeric` and cease enhancing it. It's a
terrible function. A simple way to figure out whether something is numeric is
simply parse it as a number - the work done is similar and you get the number
too.

--

[Issue 13844] core.stdc.config isn't listed in the docs

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||trivial
 CC||edi33...@gmail.com

--

[Issue 14503] BigInt to binary/octal and lower case "%x" (hexadecimal format)

[via Digitalmars-d-bugs]

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

--- Comment #7 from Andrei Alexandrescu  ---
(In reply to Andrei Alexandrescu from comment #6)
> https://dlang.org/phobos/std_array.html#replicate

sorry, wrong issue!

--

[Issue 16168] isCopyable trait for value types

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |FIXED

--

[Issue 16108] `to!string` fails on struct with disabled postblit

[via Digitalmars-d-bugs]

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

Issue 16168 Summary: isCopyable trait for value types
https://issues.dlang.org/show_bug.cgi?id=16168

   What|Removed |Added

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

--

[Issue 14494] Improve std.array.replicate documentation

[via Digitalmars-d-bugs]

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

--- Comment #2 from Andrei Alexandrescu  ---
(Doc refers to std.range.repeat, not joiner)

--

[Issue 14494] Improve std.array.replicate documentation

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

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

--

[Issue 14494] Improve std.array.replicate documentation

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Andrei Alexandrescu  ---
https://dlang.org/phobos/std_array.html#replicate

--

[Issue 14503] BigInt to binary/octal and lower case "%x" (hexadecimal format)

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |FIXED

--- Comment #6 from Andrei Alexandrescu  ---
https://dlang.org/phobos/std_array.html#replicate

--

[Issue 13677] Add function template explanation on dlang.org

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||edi33...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Eduard Staniloiu  ---
Closing this as it has been fixed by the PR below in Jan 2015:
https://github.com/dlang/dlang.org/pull/690

--

[Issue 13685] std.numeric.arrayShape

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||trivial
 CC||edi33...@gmail.com

--

[Issue 16824] std.experimental.allocator.dispose leaks memory for arrays of more than 1 dimension

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #9 from greenify  ---
FWIW there's makeNdarray in ndslice:

https://github.com/dlang/phobos/blob/master/std/experimental/ndslice/slice.d#L834

Tt can infer the dimension size from a Slice.

--

[Issue 13684] std.numeric.isRectangular

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||trivial
 CC||edi33...@gmail.com

--

[Issue 14635] inconsistent type for line: uint vs size_t

[via Digitalmars-d-bugs]

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

--- Comment #1 from Martin Krejcirik  ---
Hmm, dmd uses uint and Phobos uses size_t. I'm not sure what (if anything) to
do with it.

--

[Issue 13619] std.container.array capacity not updated when length increases

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||trivial
 CC||edi33...@gmail.com

--

[Issue 13440] Keyed array literal is not documented

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||edi33...@gmail.com
 Resolution|--- |FIXED

--- Comment #2 from Eduard Staniloiu  ---
Closing this because, as it was pointed out, it is (now) documented.

--

Re: Improvement in pure functions specification

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/2016 02:32 PM, Andrei Alexandrescu wrote:

On 12/23/2016 01:53 PM, Johan Engelen wrote:

Perhaps I read this wrong but: the paragraph says that non-strongly-pure
functions receive no special treatment, but then the next paragraph adds
special treatment for a subset of non-strongly-pure functions... :)


Fixed. Keep destruction coming. -- Andrei


Added:

$(P Destructors will always be called even if they appear to be strongly 
pure.)


Any other special functions we should worry about?


Andrei

[Issue 13033] std.conv.toBase too

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |WONTFIX

--- Comment #1 from Andrei Alexandrescu  ---
This seems too small and niche to warrant a special function.

--

Have some down time at the year's end?

[Andrei Alexandrescu via Digitalmars-d]

My students and I are making a pass through a bunch of bugzilla issues 
closing the ones that ought to be closed and marking the simple ones 
with the "trivial" bug.


https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED_status=VERIFIED=dlang.org=dmd=druntime=installer=phobos=tools=visuald=trivial%2C%20_type=allwords_id=212553=D_format=advanced=---=D2

The list is likely to grow so refresh often. If you have some down time 
this time of the year, you may want to take a look at fixing some of 
them. Happy Holidays!



Thanks,

Andrei

[Issue 12952] size_t input for bswap and bitswap

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||edi33...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Eduard Staniloiu  ---
Closing this at is already implemented.

bswap offers version for both uint and ulong:

https://github.com/dlang/druntime/blob/master/src/core/bitop.d#L502
https://github.com/dlang/druntime/blob/master/src/core/bitop.d#L508

so does bitswap:

https://github.com/dlang/druntime/blob/master/src/core/bitop.d#L797
https://github.com/dlang/druntime/blob/master/src/core/bitop.d#L831

--

Re: Improvement in pure functions specification

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/2016 01:53 PM, Johan Engelen wrote:

Perhaps I read this wrong but: the paragraph says that non-strongly-pure
functions receive no special treatment, but then the next paragraph adds
special treatment for a subset of non-strongly-pure functions... :)


Fixed. Keep destruction coming. -- Andrei

Re: Poll

[LeqxLeqx via Digitalmars-d-learn]

On Friday, 23 December 2016 at 12:51:29 UTC, Nemanja Boric wrote:
What's in the `core.sys.posix.poll` is just a C wrapper, 
meaning if you use  functions declared there, you're just 
calling the same one you would do in C, so it's very likely 
that you're doing something different in D and C program. 
Here's the example that works for me:


[...]


Thank you so much! That worked perfectly. It looks like the 
problem was that I was passing in the wrong fileno and this was 
causing it to always return 1.


Thanks again!

[Issue 16352] dead-lock in std.allocator.free_list unittest

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/5caa66ef31e40725c5548d40ead7dbefd19a0d79
Fix issue 16352 - dead-lock in std.allocator.free_list unittest

https://github.com/dlang/phobos/commit/05e9cba20e2455cb94b5d70a0d6e873bf45cec14
Merge pull request #4988 from WalterWaldron/fix16352

Fix issue 16352 - dead-lock in std.allocator.free_list unittest

--

[Issue 13369] std.math.iLog10

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||trivial
 CC||edi33...@gmail.com

--

Re: ModuleInfo, factories, and unittesting

[Piotrek via Digitalmars-d]

On Friday, 23 December 2016 at 17:07:29 UTC, Atila Neves wrote:

On Friday, 23 December 2016 at 16:28:58 UTC, Piotrek wrote:

On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote:
The worst is how useless plain `assert` is. But, all of these 
issues can (and have) be solved by libraries.


Atila


Cheers,
Piotrek

Would assert fixing take into account it's presence in betterC 
code?


Why would you care if the unittest build is betterC or not? The 
main build, sure, but it really shouldn't matter if the unit 
tests need druntime or the whole kitchen sink.


Atila


I was referring to "assert" call in general here. I don't have 
enough experience for all betterC requirements. And I think I 
have never used unit tests and betterC switch together.


Cheers,
Piotrek

[Issue 13371] std.math.factorial

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||trivial
 CC||edi33...@gmail.com

--

[Issue 13326] Specification of CaseStatement doesn't fit empty case body

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||trivial
 CC||edi33...@gmail.com

--

[Issue 4271] drop/pop methods for std.algorithm.BinaryHeap

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #4 from greenify  ---
Imho this is a common problem of the range API and I would love to see a
generic solution. For prior art see e.g.

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

and a good, generic solution in phobos-next that checks as a constraint whether
it's valid to do the move:

https://github.com/nordlow/phobos-next/blob/master/src/range_ex.d#L57

--

[Issue 16794] .deb not working on Ubuntu 16.10 because of default PIE linking

[via Digitalmars-d-bugs]

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

--- Comment #14 from Martin Nowak  ---
Benchmarks are OK, tested druntime/benchmarks and Higgs.
The missing PIC support of the asm SHA code is the only slowdown. It's also the
main blocker for shipping a PIC compiled static phobos on all linux amd64
platforms.
Hopefully not to difficult to fix, also see issue 9378.

--

Re: Improvement in pure functions specification

[Johan Engelen via Digitalmars-d]

On Friday, 23 December 2016 at 17:42:40 UTC, Andrei Alexandrescu 
wrote:

On 12/23/2016 12:32 PM, Johan Engelen wrote:

On Thursday, 22 December 2016 at 20:53:37 UTC, deadalnix wrote:
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei 
Alexandrescu

wrote:

Instead of
  "Any `pure` function that is not strongly pure cannot be 
memoized."

why not
  "Any `pure` function that is not strongly pure _may not 
be assumed to

be_ memoizable."


Got it. Good point. Will do.



That worse than the current wording.


Yes, and I fixed it a few minutes after:
https://forum.dlang.org/post/tnvpmtxcmqiwlmedy...@forum.dlang.org


Is the situash good now? -- Andrei


Yeah, with the extra sentences it's clear to (at least) me. The 
"cannot be assumed" may be read as "can never be assumed"; but 
it's clarified at the end of the paragraph.


Perhaps I read this wrong but: the paragraph says that 
non-strongly-pure functions receive no special treatment, but 
then the next paragraph adds special treatment for a subset of 
non-strongly-pure functions... :)


It's all nitpicking of course, and now things may be obvious. But 
one year from now I'm sure we'll have trouble figuring out what 
was really meant... :S

Re: ModuleInfo, factories, and unittesting

[Piotrek via Digitalmars-d]

On Friday, 23 December 2016 at 17:22:48 UTC, Kagamin wrote:

On Friday, 23 December 2016 at 16:25:13 UTC, Piotrek wrote:
In result I have to accept small obstacles and go on. 
Otherwise I wouldn't go anywhere.


So the real question is: what can we do and what should we do 
with the current amount of resources we have?


If you need a testing framework, try dunit 
https://wiki.dlang.org/Libraries_and_Frameworks#Unit_Testing_Framework


No. I want to use build-in unit testing.

Cheers,
Piotrek

Re: Optimization problem: bulk Boolean operations on vectors

[Stefan Koch via Digitalmars-d]

On Friday, 23 December 2016 at 18:33:52 UTC, Seb wrote:

On Friday, 23 December 2016 at 18:03:54 UTC, hardreset wrote:

I get..

456ms for unconditional
505ms for conditional
268ms for assembler

So the asm is about 40% faster than the best of the 
alternatives. The point being that it's the generated code not 
the source that's the problem.


Has anyone considered using ldc for DMD release compilations?


 dmd -O -release -inline -run foo.d

138 ms, 603 μs, and 6 hnsecs


ldmd -O -release -inline -run foo.d

84 ms and 719 μs


This is indeed already done.

Re: Optimization problem: bulk Boolean operations on vectors

[Seb via Digitalmars-d]

On Friday, 23 December 2016 at 18:03:54 UTC, hardreset wrote:

I get..

456ms for unconditional
505ms for conditional
268ms for assembler

So the asm is about 40% faster than the best of the 
alternatives. The point being that it's the generated code not 
the source that's the problem.


Has anyone considered using ldc for DMD release compilations?


 dmd -O -release -inline -run foo.d

138 ms, 603 μs, and 6 hnsecs


ldmd -O -release -inline -run foo.d

84 ms and 719 μs

Re: Red Hat's issues in considering the D language

[Russel Winder via Digitalmars-d]

On Sat, 2016-12-24 at 03:44 +1300, rikki cattermole via Digitalmars-d
wrote:
> […]
> 
> Except dmd's backend is far more well proven then LLVM is.

Come now that is obfuscation – you need to make good on this claim.

The LLVM backend has many, many more users than the DMD backend and the
LLVM backend is used with many more different languages than the DMD
backend. The LLVM backend is proven far more than the DMD backend
simply on the basis of statistical likelihood.

I'll back LLVM any day in this argument.
 
> So that argument needs to be tweaked a little bit.

No it doesn't, it stands as stated.

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

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

[Issue 16211] [REG 2.058] Cyclic dependencies broken again

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/druntime/commit/5ad304a4323a80e581a5e8da61b9bd81205c9438
fixup for issue 16211 - Add deprecate feature for cycle detection as the

--

[Issue 12940] std.bigint.Bigint.toSize_t too, and alternative API suggestion

[via Digitalmars-d-bugs]

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

Eduard Staniloiu  changed:

   What|Removed |Added

   Keywords||trivial
 CC||edi33...@gmail.com

--

Re: Optimization problem: bulk Boolean operations on vectors

[safety0ff via Digitalmars-d]

On Friday, 23 December 2016 at 16:15:44 UTC, Andrei Alexandrescu 
wrote:

An interesting problem to look at:



The foreach macro (src/tk/vec.h#L62) looks like low hanging fruit 
for optimization as well.

Re: Optimization problem: bulk Boolean operations on vectors

[hardreset via Digitalmars-d]

On Friday, 23 December 2016 at 16:15:44 UTC, Andrei Alexandrescu 
wrote:

An interesting problem to look at:

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

Andrei


Ok some hand written assembler to and-assign ints...

enum SIZE = 1;

void foo3(int* a, int* b)
{
asm
{
mov   EAX,a;
mov   EDX,b;
sub   EDX,EAX;
mov   ECX,EAX;
add   ECX,SIZE*4;
l1:;
cmp   EAX,ECX;
jae   done;
mov   EBX,[EAX];
and   EBX,[EAX+EDX];
mov   [EAX],EBX;
add   EAX,4;
jmp l1;
done:;
}
}

I get..

456ms for unconditional
505ms for conditional
268ms for assembler

So the asm is about 40% faster than the best of the alternatives. 
The point being that it's the generated code not the source 
that's the problem.

[Issue 16794] .deb not working on Ubuntu 16.10 because of default PIE linking

[via Digitalmars-d-bugs]

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

--- Comment #13 from Martin Nowak  ---
Shared libraries are working, people were asking for PIE support with static
phobos libraries.

I'm running benchmarks atm., but even if those were OK for -fPIC on amd64, we
still have a few problems.

Phobos built with -fPIC can't be used without -fPIC (because some modules, e.g.
SHA1, check for version (D_PIC)) atm.

OTOH distributing phobos with and without PIC might bloat the binary package,
and runs into the annoying limitations of dmd's CLI to select the right one.

Using -fno-pie by default remains the easiest path forward.

--

[Issue 16677] -L flag ignores quotes in the arguments passed to the linker

[via Digitalmars-d-bugs]

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

--- Comment #2 from Atila Neves  ---
If the problem was cmd.exe then cl.exe would also suffer from this, which
doesn't happen.

--

Re: Improvement in pure functions specification

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/2016 12:32 PM, Johan Engelen wrote:

On Thursday, 22 December 2016 at 20:53:37 UTC, deadalnix wrote:

On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei Alexandrescu
wrote:

Instead of
  "Any `pure` function that is not strongly pure cannot be memoized."
why not
  "Any `pure` function that is not strongly pure _may not be assumed to
be_ memoizable."


Got it. Good point. Will do.



That worse than the current wording.


Yes, and I fixed it a few minutes after:
https://forum.dlang.org/post/tnvpmtxcmqiwlmedy...@forum.dlang.org


Is the situash good now? -- Andrei

Pure factory functions

[Andrei Alexandrescu via Digitalmars-d]

https://github.com/dlang/dlang.org/pull/1528 identifies the category 
"pure factory functions" - pure functions that can be assumed to create 
new mutable data, as of yet not referenced by any part in the program.


This has far-reaching consequences with regard to creating complex 
immutable data structures. Other idioms may also be affordable with this 
notion. Thought it might be a good topic to look into for the more 
theoretically-inclined of us such as Timon Gehr.



Andrei

Re: Improvement in pure functions specification

[Johan Engelen via Digitalmars-d]

On Thursday, 22 December 2016 at 20:53:37 UTC, deadalnix wrote:
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei 
Alexandrescu wrote:

Instead of
  "Any `pure` function that is not strongly pure cannot be 
memoized."

why not
  "Any `pure` function that is not strongly pure _may not be 
assumed to

be_ memoizable."


Got it. Good point. Will do.



That worse than the current wording.


Yes, and I fixed it a few minutes after: 
https://forum.dlang.org/post/tnvpmtxcmqiwlmedy...@forum.dlang.org

Re: ModuleInfo, factories, and unittesting

[Kagamin via Digitalmars-d]

On Friday, 23 December 2016 at 16:25:13 UTC, Piotrek wrote:
In result I have to accept small obstacles and go on. Otherwise 
I wouldn't go anywhere.


So the real question is: what can we do and what should we do 
with the current amount of resources we have?


If you need a testing framework, try dunit 
https://wiki.dlang.org/Libraries_and_Frameworks#Unit_Testing_Framework

[Issue 12562] std.algorithm.mul

[via Digitalmars-d-bugs]

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

--- Comment #3 from greenify  ---
If someone starts with this, he should read the comment at the cumulativeSum
discussion:

https://github.com/dlang/phobos/pull/4881#issuecomment-259489117

--

[Issue 16824] std.experimental.allocator.dispose leaks memory for arrays of more than 1 dimension

[via Digitalmars-d-bugs]

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

--- Comment #8 from Andrei Alexandrescu  ---
worksforme

Atila you just volunteered to help @Razvan our grad student in case he needs
assistance and review with *CompactMultidimensional, which may have subtleties
related to alignment.

--

Re: ModuleInfo, factories, and unittesting

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/2016 02:37 AM, Jacob Carlborg wrote:

On 2016-12-22 19:19, Andrei Alexandrescu wrote:


Both of these are affordable with the current language (attributes) with
changes to druntime. Who wants to take this? -- Andrei


What do you think about this idea [1]?

[1] http://forum.dlang.org/post/npptbk$2mk0$1...@digitalmars.com


It looks like a solid traditional approach. It would be great to explore 
approaches where D's unique features would bring a strategic advantage. 
-- Andrei

[Issue 16824] std.experimental.allocator.dispose leaks memory for arrays of more than 1 dimension

[via Digitalmars-d-bugs]

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

--- Comment #7 from Atila Neves  ---
I think adding the extra functions is the way forward.

--

Re: ModuleInfo, factories, and unittesting

[Atila Neves via Digitalmars-d]

On Friday, 23 December 2016 at 16:28:58 UTC, Piotrek wrote:

On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote:
The worst is how useless plain `assert` is. But, all of these 
issues can (and have) be solved by libraries.


Atila


Cheers,
Piotrek

Would assert fixing take into account it's presence in betterC 
code?


Why would you care if the unittest build is betterC or not? The 
main build, sure, but it really shouldn't matter if the unit 
tests need druntime or the whole kitchen sink.


Atila

Re: ModuleInfo, factories, and unittesting

[Andrei Alexandrescu via Digitalmars-d]

On 12/23/2016 06:18 AM, Atila Neves wrote:

On Thursday, 22 December 2016 at 18:19:31 UTC, Andrei Alexandrescu wrote:

On 12/22/2016 12:46 PM, Piotrek wrote:

The inability to give test a name (plus selective unittesting) and
continue on failure is puzzling to me.


Both of these are affordable with the current language (attributes)
with changes to druntime. Who wants to take this? -- Andrei


I would, but I don't see how this is possible without one of:

1) A standardised build system
2) Changes to the language

Attributes mean static reflection, and that means explicitly (and at
compile-time) stating every module being built somewhere. There is no
current way to reflect on packages.


Oh, I see. So there needs to be some sort of cooperation between the 
compile-time realm (stash the unittest attributes during compilation) 
and the run-time realm (pick up that data and use it).



The only way I know how to do this
is to use the build system to autogenerate a D file listing all modules
to reflect on, which not coincidentally is how unit-threaded does it,
with dub. But it only works if you're using dub and even then fails
sometimes if it can't parse `dub describe` properly.


Got it.


I would've changed druntime 4 years ago if I could, it's the only reason
I know of ModuleInfo and what it has to do with unit tests.

Maybe I'm missing something or lacking imagination.


Well clearly some changes in the compiler and/or runtime could bring us 
to where we want to be.



Andrei

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Friday, 23 December 2016 at 11:31:14 UTC, Stefan Koch wrote:

On Friday, 23 December 2016 at 10:25:57 UTC, Stefan Koch wrote:
On Thursday, 22 December 2016 at 20:34:50 UTC, Stefan Koch 
wrote:

I just fixed the "" case for StringLiterals.


This exposed bugs in the code-generator because now 
phobos-unittests with "" are run.

(Which would previously be counted as uncompilable)
Apparently we run into a situation where the interpreter tries 
to fetch instructions that are out-of-range.

This can only be caused by miscompiled code.
I am investigating.


Seems like that one was triggerd by random garbage being 
written into empty strings :)

Empty string literals are now fixed for good.


I just made global enums and static immutables visible to newCTFE.
Before they would trigger a bailout since they are not defined in 
the functions stack-frame.


meaning this compiles now:
uint[] arrayLiteralReturn()
{
  return [1,2,3];
}
static immutable alr = arrayLiteralReturn();
static assert(alr == [1,2,3]);

[Issue 16824] std.experimental.allocator.dispose leaks memory for arrays of more than 1 dimension

[via Digitalmars-d-bugs]

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

--- Comment #6 from Andrei Alexandrescu  ---
(In reply to Atila Neves from comment #5)
> I understand the arguments; but I still think there should be an easy,
> canonical way of allocating arrays of more than one dimension and be able to
> dispose of them without leaking memory. I didn't even know I _was_ leaking
> memory until I wrote that test allocator. And I only did _that_ because I'm
> paranoid.

It seems the right view is this:

* If you used a loop to allocate your multidimensional array, you're supposed
to use a loop to deallocate your multidimensional array. The library can't
guess what you did.
* If the library provides a means to dispose a multidimensional array in one
shot under certain assumptions, the library must provide a means to create a
multidimensional array in one shot such that those assumptions are fulfilled.

One way I see this moving forward is to provide the following functions:

* makeMultidimensional -> does the looparoo that Atila currently does by hand
* disposeMultidimensional -> does what Razvan does now in his PR, i.e. disposes
the whole array ASSUMING it had been created by makeMultidimensional

(maybe later)

* makeCompactMultidimensional -> computes the appopriate sizes and allocates
one hunk that is then sliced and diced to return the multidimensional array.
* disposeCompactMultidimensional -> disposes an array ASSUMING it had been
created by makeCompactMultidimensional

--

Re: Red Hat's issues in considering the D language

[Walter Bright via Digitalmars-d]

On 12/21/2016 5:30 PM, Andrei Alexandrescu wrote:

Would be great to narrow this down regardless. Shouldn't be too difficult since
the penalty is so huge. Must be a pathological case we should fix anyway. -- 
Andrei


Not a complete solution, but should help:

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