Re: good RPC framework for D?

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 6 June 2017 at 01:01:34 UTC, Timothee Cour wrote:

Is there a good RPC framework for D?

requirements:
* efficient (no json/xml)
* supports at least sending/receiving raw bytes

I tried msgpack-rpc but it seems abandonned (last commit 2 y 
ago) and this issue makes it unusable: 
https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16 for 
messages of length >= 4090 bytes.


I would love to have a GRPC work with D but couldn't find a 
package for it.


Is there at least a reliable solution that sends raw bytes ? 
than I can for eg wrap protobufs or other serialized formats 
via serialization/deserialization.


Additional requirements: supports streaming data (either input 
or

output or both), and timeouts.


I am working right now on wrapping grpc, but it's a bit of work 
and I have lots of other things to do and can't be sure when or 
if I will finish.  The C API is not that bad once you understand 
what if is doing.  And see dprotobuf.

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Tuesday, 6 June 2017 at 02:03:46 UTC, jmh530 wrote:

On Tuesday, 6 June 2017 at 00:46:00 UTC, Stefan Koch wrote:


Time to find this: roughly 2 weeks.



Damn. That's some commitment.


There is no other way, really.
These things need to be fixed.

Re: good RPC framework for D?

[Neia Neutuladh via Digitalmars-d]

On Tuesday, 6 June 2017 at 01:01:34 UTC, Timothee Cour wrote:

Is there a good RPC framework for D?


Last time I needed one, I used Thrift. D support in Thrift is 
maintained upstream. Unfortunately, the version available in dub 
is really old. Also unfortunately, it's std.socket only -- no 
vibe.d.


https://thrift.apache.org/docs/features
https://github.com/apache/thrift/tree/master/lib/d


requirements:
* efficient (no json/xml)


Thrift uses a binary format relatively similar to protocol 
buffers.



* supports at least sending/receiving raw bytes


Thrift supports a `binary` data type representing a byte array.

Additional requirements: supports streaming data (either input 
or output or both)


I'm not sure what you mean by "streaming data", precisely, but 
Thrift supports multiple RPCs per  connection. This alone made a 
huge difference in my testing: a Thrift server on an AWS t2.micro 
 managed 2400 requests per second across ten clients, while HTTP 
handlers returning a fixed string only managed 75.



and timeouts.


Definitely supports timeouts.

Re: CTFE Status 2

[jmh530 via Digitalmars-d]

On Tuesday, 6 June 2017 at 00:46:00 UTC, Stefan Koch wrote:


Time to find this: roughly 2 weeks.



Damn. That's some commitment.

Re: Compile-Time Sort in D

[Mike Parker via Digitalmars-d-announce]

On Monday, 5 June 2017 at 21:35:54 UTC, Seb wrote:


This is a great article, Mike!


Thanks!

At the end I expected a reference to D's great template 
constraints [1], maybe it's still worth adding sth. like this 
to show how amazingly useful CTFE is?


It's a good idea! I don't think I'll and change it at this point, 
though. When I was rewriting the last section, I considered 
showing two versions of a templated function -- one that uses the 
validator in a constraint and one that uses it at runtime -- but 
I worried that would add more noise. The msg pragma and the 
writeln kept the focus more narrow (which is something that kept 
coming up in feedback). And at that point, I was ready to be done 
with it. I worked on that post for a significant chunk of two 
days.

Re: Compile-Time Sort in D

[Mike Parker via Digitalmars-d-announce]

On Monday, 5 June 2017 at 17:54:05 UTC, Jon Degenhardt wrote:



Very nice post!


Thanks! If it gets half as many page views as yours did, I'll be 
happy. Yours is the most-viewed post on the blog -- over 1000 
views more than #2 (my GC post), and 5,000 more than #3 (A New 
Import Idiom).

good RPC framework for D?

[Timothee Cour via Digitalmars-d]

Is there a good RPC framework for D?

requirements:
* efficient (no json/xml)
* supports at least sending/receiving raw bytes

I tried msgpack-rpc but it seems abandonned (last commit 2 y ago) and
this issue makes it unusable:
https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16 for messages of
length >= 4090 bytes.

I would love to have a GRPC work with D but couldn't find a package for it.

Is there at least a reliable solution that sends raw bytes ? than I
can for eg wrap protobufs or other serialized formats via
serialization/deserialization.

Additional requirements: supports streaming data (either input or
output or both), and timeouts.

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Monday, 5 June 2017 at 20:51:03 UTC, Stefan Koch wrote:
On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch 
wrote:

[ .. ]


Hi Guys,

I am still working on the buggy Slice-Assignment.
Just now I fixed a bug where an [Bytecode-Assert]
would flip it's the condition ... and trigger whenever it was 
true instead of false.
Assertions are one of things which cannot be tested at 
compiletime since they need to interact with dmd bummer.


Originally I intended for floating-point support to be 
implemented in this and the following month. Looks like I am 
not gonna make it.


My main system is waiting for replacement parts.
And as you know my laptop cannot link dmd when a gui is 
active... so that's not great either.


Cheers,
Stefan


I solved the slice assignment case.
Now here is a subtle bug for you.

As you may know, newCTFE has it's own type-system in order to 
help make the IR simpler.
Later on typed version of the ir gets lowered though until only 
int32 expressions remain.
When processing Slice expression I lowered to early though, and 
returned an i32 to be interpreted as pointer to a slice 
descriptor.
However in the slice-assignment code I wanted to the the 
elmementType form the SliceExp, which came back as 
BCType(invalid).
Then I took it the size of it, which came back as 0. (an invalid 
size for an invalid type).
And multiplied the index and length, with it to move to the 
correct point in the slice-buffer.


That comes back as target[0 .. 0] = source[0 .. 0].
So no modification occurs.

Time to find this: roughly 2 weeks.

Why did it take so long ?
Because I thought the ABI was at fault; And spent a lot of time 
staring on memory dumps :(

Re: Compile-Time Sort in D

[Stanislav Blinov via Digitalmars-d-announce]

On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
The crowd-edited (?) blog post exploring some of D's 
compile-time features is now live. Thanks again to everyone who 
helped out with it.


The blog:
https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/

Reddit:
https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/


Ah Reddit... The article about the elegance of CTFE. Let's 
discuss the meaning of "enum" then...

Re: GDC options

[Nicholas Wilson via Digitalmars-d-learn]

On Monday, 5 June 2017 at 18:22:31 UTC, Sebastien Alaiwan wrote:
On Wednesday, 22 March 2017 at 13:42:21 UTC, Matthias Klumpp 
wrote:
This is why most of my work in Meson to get D supported is 
adding weird hacks to translate compiler flags between GNU <-> 
non-GNU <-> DMD. It sucks quite badly, and every now and then 
I hit a weird corner case where things break.
For example: 
https://github.com/mesonbuild/meson/commit/d9cabe9f0ca6fb06808c1d5cf5206a7c5158517e


One day, we'll have to decide if we should align build systems 
on compilers, or the other way around.
In the meantime, could everyone please align on clang and gcc ? 
:-)


We're getting there, slowly. Although its a tight balance between 
dmd compatibility and gcc/clang compatibility, see -[f]unittest.


https://github.com/ldc-developers/ldc/pull/2149

Re: Question to GC experts: NO_SCAN for a part of the block

[Stanislav Blinov via Digitalmars-d]

On Monday, 5 June 2017 at 13:11:25 UTC, Steven Schveighoffer 
wrote:


adding a range marks it as having pointers to scan, AND stores 
a reference to that array, so it won't be GC collected (nor 
will anything it points to). The intention is for it to be used 
on non-GC memory, like C malloc'd memory, where it doesn't 
matter that the GC is pointing at it.




Huh?

https://dlang.org/phobos/core_memory.html#.GC.addRange :

Note that p[0 .. sz] is treated as an opaque range of memory 
assumed to be suitably managed by the caller. In particular, if 
p points into a GC-managed memory block, addRange does not mark 
this block as live.


Is that paragraph wrong?

I would say that you are better off allocating 2 arrays -- one 
with NO_SCAN where you put your non-pointer-containing data, 
and one without the flag to put your other data. This is 
similar to your "selective" function, but instead of allocating 
1 array, with a tuple of slices into it, just allocate 2 arrays 
and return the tuple of those 2 arrays.


Then it's just the obvious() function. The whole point of the 
exercise is to make one GC allocation instead of N :) But still 
GC, so as not to put additional responsibility on the caller.

Re: Can assumeSafeAppend() grab more and more capacity?

[Ali Çehreli via Digitalmars-d-learn]

On 06/05/2017 03:16 PM, ag0aep6g wrote:

> The spec says [1]: "one may use the .capacity property to determine how
> many elements can be appended to the array without reallocating." So the
> space indicated by `.capacity` is reserved for the array.

Cool. Thanks!

>> 3) Bonus: Shouldn't the array specialization of std.algorithm.remove
>> call assumeSafeAppend if the array has capacity to begin with? (The
>> equivalent of following code?)
>>
>>  const oldCap = arr.capacity;
>>  // ... do std.algorithm.remove magic on arr ...
>>  if (oldCap) {
>>  arr.assumeSafeAppend();
>>  }
>>
>> I'm aware that there can be multiple slices with non-zero capacity
>> until one of them grabs the capacity for itself but it's ok for
>> remove() to give the capacity to just one of them.
>
> Seems safe, but you'll have to justify claiming the capacity like that.

My justification was that it feels to be a bug anyway to have multiple 
slices to data where one is about to remove() elements from (hence 
jumbling the others' elements). My thinking was, if capacity were not 
guaranteed for any slice to begin with, then why not pull it under some 
slices arbitrarily. But I agree with you that remove() should still not 
decide on its own.


However, I've noticed an inconsistency when writing the previous 
paragraph: If capacity is guaranteed reserved space, multiple slices 
start their lives with a lie! :) From my earlier program:


auto a = [ 1, 2, 3, 4 ];
auto b = a;

Both of those slices have non-zero capacity yet one of them will be the 
lucky one to grab it. Such semantic issues make me unhappy. :-/


Ali

Re: Can assumeSafeAppend() grab more and more capacity?

[ag0aep6g via Digitalmars-d-learn]

On 06/05/2017 11:08 PM, Ali Çehreli wrote:
Imagine an array that wants to reuse its buffer after removing elements 
from it. For example, a PID waiting list can remove completed elements 
and add new ones at the end.


The code would call assumeSafeAppend like this:

 arr = arr.remove!(e => e % 2);
 arr.assumeSafeAppend();

1) Assuming that the array is not relocated, is it possible that the 
capacity will grow and grow? (Imagine that a new memory page from the GC 
beyond the current capacity becomes available? Would assumeSafeAppend() 
grab that as capacity as well?)


As far as I understand, assumeSafeAppend only grabs the existing 
capacity. New capacity gets created when appending or by calling `reserve`.


When there's free space beyond the capacity, then appending/`reserve` 
may extend the memory block instead of relocating. A quick test says 
this is done with large arrays (multiple KiB). For smaller arrays, the 
GC likely uses pools of fixed-width chunks.


For example, if capacity was non-zero before the two lines above, would 
that assumeSafeAppend() call find more capacity than before?


I don't think so.

2) If so, is the capacity "allocated" for this buffer or can the GC use 
those pages for other purposes, effectively reducing the array's capacity?


The spec says [1]: "one may use the .capacity property to determine how 
many elements can be appended to the array without reallocating." So the 
space indicated by `.capacity` is reserved for the array.


But I guess you should claim it by appending, so that the GC is knows 
what's happening. I.e., don't claim it by slicing a pointer.


In other words, is having capacity a guarantee like having called 
reserve()?


As far as I know, it's exactly the same. `reserve` makes capacity.

3) Bonus: Shouldn't the array specialization of std.algorithm.remove 
call assumeSafeAppend if the array has capacity to begin with? (The 
equivalent of following code?)


 const oldCap = arr.capacity;
 // ... do std.algorithm.remove magic on arr ...
 if (oldCap) {
 arr.assumeSafeAppend();
 }

I'm aware that there can be multiple slices with non-zero capacity until 
one of them grabs the capacity for itself but it's ok for remove() to 
give the capacity to just one of them.


Seems safe, but you'll have to justify claiming the capacity like that. 
How is it better than leaving it for the other slices? As it is, a user 
can do what you did there when they want the capacity. When `remove` 
claims the capacity eagerly, unrelated code may end up relocating 
without need.



[1] http://dlang.org/spec/arrays.html#resize

Re: Release D 2.074.1

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Monday, 5 June 2017 at 18:25:19 UTC, Martin Nowak wrote:
IMO the problem here is the usage of a VERSION file in the 
first place, which exists only b/c it's somewhat tricky to 
invoke git on Windows.


Yup, my instinct is that if a VERSION file needs to exist at all 
it should be created during the build process out of `git 
describe` output.


Apart from Windows, are there any other cases where it's still 
more convenient to have it up front?  And what makes invoking git 
tricky on the Windows side?


If your building a version, you know which one it is and 
can/should provide that version.


Who's "you" in this scenario? :-)

I think it's reasonable that e.g. an official source tarball 
should contain sufficient information that building it, without 
modification or the need for user input, will result in a 
compiler that reports correct version information.  (Official 
here means the stuff available on the Downloads page, not the 
autogenerated tarballs that GitHub offers which are just a copy 
of a checkout of the git tree.)


OTOH if one is building from within a git checkout, then git 
should be queried to provide the version info (with an option to 
disable/override this if the user wants to).


I'd have thought those two options would cover almost all 
requirements out there, no ... ?

Re: Compile-Time Sort in D

[Seb via Digitalmars-d-announce]

On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
The crowd-edited (?) blog post exploring some of D's 
compile-time features is now live. Thanks again to everyone who 
helped out with it.


The blog:
https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/

Reddit:
https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/


This is a great article, Mike!
At the end I expected a reference to D's great template 
constraints [1], maybe it's still worth adding sth. like this to 
show how amazingly useful CTFE is?


auto myRandomEngine(ulong m, ulong a, ulong c)(ulong seed)
if (properLinearCongruentialParameters!(m, a, c))
{
  return seed;
}

void main()
{
static assert(!__traits(compiles, myRandomEngine!(1, 2, 
3)(42)));

myRandomEngine!(1UL << 32, 1664525, 1013904223)(42);
}

Or alternatively if you don't want to rewrite 
properLinearCongruentialParameters e.g.


auto myRandomEngine(ulong m, ulong a, ulong c)(ulong seed)
if (pLCP!(m, a, c))
{
  return seed;
}

template pLCP(ulong m, ulong a, ulong c) {
enum pLCP = properLinearCongruentialParameters(m, a, c);
}

[1] https://dlang.org/spec/template.html#template_constraints

Can assumeSafeAppend() grab more and more capacity?

[Ali Çehreli via Digitalmars-d-learn]

Imagine an array that wants to reuse its buffer after removing elements 
from it. For example, a PID waiting list can remove completed elements 
and add new ones at the end.


The code would call assumeSafeAppend like this:

arr = arr.remove!(e => e % 2);
arr.assumeSafeAppend();

1) Assuming that the array is not relocated, is it possible that the 
capacity will grow and grow? (Imagine that a new memory page from the GC 
beyond the current capacity becomes available? Would assumeSafeAppend() 
grab that as capacity as well?)


For example, if capacity was non-zero before the two lines above, would 
that assumeSafeAppend() call find more capacity than before?


2) If so, is the capacity "allocated" for this buffer or can the GC use 
those pages for other purposes, effectively reducing the array's capacity?


In other words, is having capacity a guarantee like having called reserve()?

3) Bonus: Shouldn't the array specialization of std.algorithm.remove 
call assumeSafeAppend if the array has capacity to begin with? (The 
equivalent of following code?)


const oldCap = arr.capacity;
// ... do std.algorithm.remove magic on arr ...
if (oldCap) {
arr.assumeSafeAppend();
}

I'm aware that there can be multiple slices with non-zero capacity until 
one of them grabs the capacity for itself but it's ok for remove() to 
give the capacity to just one of them.


Here is a test program that plays with this idea, starting with two 
identical slices with same capacity:


import std.stdio;
import std.array;
import std.algorithm;

void myRemove(ref int[] arr) {
const cap = arr.capacity;

arr = arr.remove!(e => e % 2);

if (cap) {
arr.assumeSafeAppend();
}
}

void info(arrays...)(string title) {
writefln("\n%s", title);
foreach (i, arr; arrays) {
writefln("  %s - ptr: %s, len: %s, cap: %s",
 (arrays[i]).stringof, arr.ptr, arr.length, arr.capacity);
}
}

void main() {
auto a = [ 1, 2, 3, 4 ];
auto b = a;

info!(a, b)("before myRemove(a)");

myRemove(a);
info!(a, b)("after  myRemove(a)");

myRemove(b);
info!(a, b)("after myRemove(b)");
}

before myRemove(a)
  a - ptr: 7F15F40D4060, len: 4, cap: 7
  b - ptr: 7F15F40D4060, len: 4, cap: 7

after  myRemove(a)
  a - ptr: 7F15F40D4060, len: 2, cap: 7  <== 'a' grabbed capacity
  b - ptr: 7F15F40D4060, len: 4, cap: 0  <==

after myRemove(b)
  a - ptr: 7F15F40D4060, len: 2, cap: 7
  b - ptr: 7F15F40D4060, len: 3, cap: 0

Ali

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:

[ .. ]


Hi Guys,

I am still working on the buggy Slice-Assignment.
Just now I fixed a bug where an [Bytecode-Assert]
would flip it's the condition ... and trigger whenever it was 
true instead of false.
Assertions are one of things which cannot be tested at 
compiletime since they need to interact with dmd bummer.


Originally I intended for floating-point support to be 
implemented in this and the following month. Looks like I am not 
gonna make it.


My main system is waiting for replacement parts.
And as you know my laptop cannot link dmd when a gui is active... 
so that's not great either.


Cheers,
Stefan

Re: std.csv Performance Review

[H. S. Teoh via Digitalmars-d]

On Sun, Jun 04, 2017 at 03:59:03PM +, Jesse Phillips via Digitalmars-d 
wrote:
[...]
> Ok, I took you up on that, I'm still skeptical:
> 
> LDC2 -O3 -release -enable-cross-module-inlining
> 
> std.csv: 12487 msecs
> fastcsv (no gc): 1376 msecs
> csvslicing: 3039 msecs
> 
> That looks like about 10 times faster to me. Using the slicing version
> failed because of \r\n line endings (guess multi-part separators is
> broken) I changed the data file so I could get the execution time.

Thank you for testing it yourself.  I also tried to run the tests again
on my machine, and I can't seem to reproduce the 102136 msecs reading
again.  It seems that different compilers give somewhat readings, and
also we are using different compile flags.  In any case, in the spirit
of full disclosure, here's my test with the 3 compilers, that I just ran
just now just to be sure I'm not just copying old bad measurements:


$ dmd -O -inline benchmark.d fastcsv.d
$ ./benchmark stdstruct
std.csv read 2126883 records
std.csv (struct): 33119 msecs
$ ./benchmark faststruct2
fastcsv read 2126883 records
fastcsv (struct with const(char)[]): 2596 msecs

$ gdc -O3 -finline benchmark.d fastcsv.d -o benchmark
$ ./benchmark stdstruct
std.csv read 2126883 records
std.csv (struct): 23103 msecs
$ ./benchmark faststruct2
fastcsv read 2126883 records
fastcsv (struct with const(char)[]): 1909 msecs

$ ldc2 -O3 benchmark.d fastcsv.d 
$ ./benchmark stdstruct
std.csv read 2126883 records
std.csv (struct): 20776 msecs
$ ./benchmark faststruct2
fastcsv read 2126883 records
fastcsv (struct with const(char)[]): 1813 msecs


So, it looks like your 10x figure is more-or-less on target.  I've no
idea where the original 102136 msecs reading came from.  Perhaps that
was an unfortunate coincidence with a heavy load on my machine, or
something like that. Or maybe just a bungled copy-n-paste.


> Anyway, I'm not trying to claim fastcsv isn't good at what it does,
> all I'm trying to point out is std.csv is doing more work than these
> faster csv parsers. And I don't even want to claim that std.csv is
> better because of that work, it actually appears that it was a mistake
> to do validation.

I never intended for fastcsv to become a point of contention or as some
kind of competition with std.csv, and I apologize if I ever came across
that way.  I fully understand that std.csv does more work than fastcsv;
certainly, being able to assume an in-memory input and free slicing
gives a big advantage over being restricted to just input range
primitives. I had hoped to actually work fastcsv into a suitable form to
merge into std.csv -- to dispel wrong perceptions of D being "slow", you
see -- but it turned out to be more work than I had time for, so I
didn't get very far beyond the initial promising results.

My original hope was that the fastcsv code would be taken as a source of
ideas that we could adopt for speeding up std.csv, rather than be taken
in the way of "haha I wrote faster code than std.csv, so std.csv sux".
The latter was not my intention at all.

Anyway, I'm glad that you're looking into using slicing in std.csv. We
need Phobos modules to be highly performant so that newcomers don't get
the wrong impression about the language being slow. I'd also recommend
investigating reducing GC load, as I described in my previous post, as
another angle for improving the performance of std.csv.

As for whether to validate or not: if you were to ask me, I'd leave it
in, with a caveat in the docs that it would be less performant. As the
standard library, Phobos should give the user options, including the
option to validate input files that could potentially be malformed.  But
where the user knows the input is always well-formed, we can (and
should) take advantage of that to achieve better performance.


T

-- 
Why waste time reinventing the wheel, when you could be reinventing the engine? 
-- Damian Conway

Re: Compile-Time Sort in D

[Walter Bright via Digitalmars-d-announce]

On 6/5/2017 10:54 AM, Jon Degenhardt wrote:

On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
The crowd-edited (?) blog post exploring some of D's compile-time features is 
now live. Thanks again to everyone who helped out with it.


The blog:
https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/

Reddit:
https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/


Very nice post!


It's also on Hacker News under "Compile-Time Sort in D".

[Issue 17317] 2.074.0 release candidate does not have updated backend license

[via Digitalmars-d-bugs]

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

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #3 from greensunn...@gmail.com ---
> a small PR that removes license.txt from the packages.

Or simply updating the license file to Boost:

https://github.com/dlang/installer/pull/229

--

Re: Anyone tried to emscripten a D/SDL game?

[Sebastien Alaiwan via Digitalmars-d]

On Monday, 5 June 2017 at 10:48:54 UTC, Johan Engelen wrote:

On Monday, 5 June 2017 at 05:22:44 UTC, Sebastien Alaiwan wrote:


The whole simplified toolchain and example project live here: 
https://github.com/Ace17/dscripten


Are you planning on upstreaming some of your work to LDC? 
Please do! :-)


Don't let the small size of the LDC patch from dscripten deceive 
you ; it mangles LDC in the easiest possible way to adapt it to 
the quirks of emscripten-fastcomp (the LLVM fork).
(the official LLVM branch doesn't even declare the 
asmjs/Emscripten triples).


At this point, I think emscripten-fastcomp might be on the go ; 
especially if the WebAssembly backend from the official LLVM 
branch becomes widely used (at this point, I'll probably ditch 
emscripten-fastcomp from dscripten, to use WebAssembly instead).


Some stuff that could be easily upstreamed in a clean 
non-emscripten specific way:
- allowing to disable the build of phobos and druntime from the 
cmake build.
- allowing to disable the build of the debug information 
generator.

- allowing to disable the build of the tests.

Re: std.csv Performance Review

[Jon Degenhardt via Digitalmars-d]

On Saturday, 3 June 2017 at 04:25:27 UTC, Jesse Phillips wrote:

Author here:

The discussion[1] and articles[2] around "Faster Command Line 
Tools" had me trying out std.csv for the task.


[snip]

Keep in mind that the file itself has 10,512,769 rows of data 
with four columns. Now I've talked to std.csv's performance in 
the past, probably with the author of the fast command line 
tools.


[snip]


I'm the author of the TSV tools. I'd be happy to provide insights 
I've gained from this exercise to help improve std.csv. I did 
examine std.csv when I first starting writing the TSV tools, but 
decided they weren't appropriate for what I was trying to do. I 
don't remember the specifics at this point though. CSV imposes 
many requirements on an implementation that TSV does not, which 
makes it challenging to produce an implementation optimal for 
both.


--Jon

[Issue 17317] 2.074.0 release candidate does not have updated backend license

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #2 from Martin Nowak  ---
Thanks, interested in making a small PR that removes license.txt from the
packages.
https://github.com/dlang/installer/search?q=license.txt

--

Re: Release D 2.074.1

[Martin Nowak via Digitalmars-d-announce]

On Saturday, 3 June 2017 at 19:57:36 UTC, Joseph Rushton Wakeling 
wrote:
The problem here is that anyone downstream wanting to build or 
package from source has to work around this issue, that without 
manual intervention, the version information of the compiler 
will be incorrect.


If that's not fixed in how dmd itself is managed (NOT the 
dlang/installer scripts), this will continue to be an 
unnecessary burden on downstream packagers.


IMO the problem here is the usage of a VERSION file in the first 
place, which exists only b/c it's somewhat tricky to invoke git 
on Windows.
If your building a version, you know which one it is and 
can/should provide that version.

Re: GDC options

[Sebastien Alaiwan via Digitalmars-d-learn]

On Wednesday, 22 March 2017 at 13:42:21 UTC, Matthias Klumpp 
wrote:
This is why most of my work in Meson to get D supported is 
adding weird hacks to translate compiler flags between GNU <-> 
non-GNU <-> DMD. It sucks quite badly, and every now and then I 
hit a weird corner case where things break.
For example: 
https://github.com/mesonbuild/meson/commit/d9cabe9f0ca6fb06808c1d5cf5206a7c5158517e


One day, we'll have to decide if we should align build systems on 
compilers, or the other way around.
In the meantime, could everyone please align on clang and gcc ? 
:-)

Re: Release D 2.074.1

[Martin Nowak via Digitalmars-d-announce]

On Saturday, 3 June 2017 at 18:08:40 UTC, Joseph Rushton Wakeling 
wrote:

On Thursday, 1 June 2017 at 21:04:00 UTC, Martin Nowak wrote:
This point release fixes a few issues over 2.074.0, see the 
changelog for more details.


I'm afraid that the release has another fault: the VERSION file 
still gives 2.074.0.  This means that unless it is edited 
during the build process, the compiler will report the wrong 
version number when `dmd --version` is invoked.


All those VERSION files are a mess, in particular the dmd VERSION 
file currently gets updated at a different point than the 
dlang.org VERSION files.
I'd like to get rid of them all and exclusively use git tags, but 
there are too many other use cases.
Updated the release script to update the dmd VERSION file after a 
release.


Guess it would help a bit if we bumped the dmd development 
version WITH the release instead of AFTER the release. Would also 
match what git describe does, which might be the saner version 
anyhow.

Should we try to change that for 2.075.0?

[Issue 7952] invalid dwarf2 offset when trying to debug with gdb

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||c...@dawg.eu
 Resolution|--- |FIXED

--- Comment #2 from Martin Nowak  ---
Closing since OSX no longer ships with gdb and the problem was likely solved in
the meantime anyhow.
Newer gdb versions should work, see e.g.
https://www.patosai.com/posts/2015/03/24/installing-gdb-on-os-x-yosemite for
how to install gdb instead of lldb.
Not sure how good the lldb support is.

--

Re: Compile-Time Sort in D

[Jon Degenhardt via Digitalmars-d-announce]

On Monday, 5 June 2017 at 14:23:34 UTC, Mike Parker wrote:
The crowd-edited (?) blog post exploring some of D's 
compile-time features is now live. Thanks again to everyone who 
helped out with it.


The blog:
https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/

Reddit:
https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/


Very nice post!

Re: Avast virus warning?

[Anonymouse via Digitalmars-d-learn]

On Monday, 5 June 2017 at 16:40:25 UTC, rikki cattermole wrote:
It would be nice to get in touch with their engineers to find 
out what is really going on.


Tried an email and hit a paywall. :c

"We’re sorry, but we can’t seem to find a record of your 
license in our system."

[Issue 12518] Add ability to not rebuild the project on file with custom build tool change

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #3 from Rainer Schuetze  ---
> 1. The file output is only linked with the project (e.g. *.h or *.rc file 
> generating a *.res file).
>Here only relink is needed, no recompiling.

https://github.com/dlang/visuald/releases/tag/v0.45.0-beta1 now uses two
separate steps (with their own set of dependencies) if anything but "combined"
compilation is used.

--

Re: bug? floating point precision with std.format

[Jonathan M Davis via Digitalmars-d]

On Monday, June 05, 2017 13:23:38 Steven Schveighoffer via Digitalmars-d 
wrote:
> On 6/5/17 12:29 PM, Seb wrote:
> > You do realize that you have used "s" in the D version?
>
> Yes, I thought it was a stand in for "use the type to determine the
> specifier", and I mistakenly assumed that would be 'f', since that's
> what I've always used for floating point. Apparently it is 'g', which
> behaves as I have shown.

I always assumed that it just meant "convert to string" and that it did
basically the same thing that to!string would do, in which case, doing
something like passing a number to it like you did would not be legal.
Clearly, I never read the docs. :)

- Jonathan M Davis

[Issue 16619] Visual D: link dependency file does not exist - always prompted to rebuild

[via Digitalmars-d-bugs]

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

--- Comment #4 from Rainer Schuetze  ---
The newest version https://github.com/dlang/visuald/releases/tag/v0.45.0-beta1
uses generic dependency tracking for the compiler, too. So you might get hit by
this issue again with the next version.

If you are still using VS2005, I'd recomment installing some MS package
containing the file access tracker.exe. It should be part of anything
containing MSBuild, e.g. .NET SDK, Build Tools or other SDKs.

--

Re: bug? floating point precision with std.format

[Steven Schveighoffer via Digitalmars-d]

On 6/5/17 12:29 PM, Seb wrote:

You do realize that you have used "s" in the D version?


Yes, I thought it was a stand in for "use the type to determine the 
specifier", and I mistakenly assumed that would be 'f', since that's 
what I've always used for floating point. Apparently it is 'g', which 
behaves as I have shown.



This is a bit more interesting:

writefln("%0.3s", f); // 20.7
printf("%0.3s\n", f); // 20.


That is really bad, because %s means interpret the parameter as a char * 
string. So the memory pointed at by the bit pattern of 20.6 cast to 
a pointer, has the first 3 bytes '2', '0', and '.', and then a null 
character (or a bunch of unprintable characters, followed by a null).


Bizarre...

-Steve

Re: bug? floating point precision with std.format

[Steven Schveighoffer via Digitalmars-d]

On 6/5/17 12:53 PM, H. S. Teoh via Digitalmars-d wrote:

On Mon, Jun 05, 2017 at 04:29:06PM +, Seb via Digitalmars-d wrote:

On Monday, 5 June 2017 at 15:37:42 UTC, Steven Schveighoffer wrote:

It appears that the precision parameter in std.format differs from its
meaning in printf. Is that expected behavior?

Example:

import std.stdio;
import core.stdc.stdio;

void main()
{
auto f = 20.6;
writeln(f);
writefln("%0.3s", f);

[...]

That should be "%0.3f", not "%0.3s".

If you use the "%s" specifier, precision is interpreted differently,
i.e., as "maximum number of characters", as per "%s" in C's printf.


Interesting. I thought s just stood for "interpret based on the type", 
and would automatically switch to floating point 'f'. I see in the docs 
now, it uses 'g', something I've never used.


Curious that 'f' isn't used, I thought it would have been the default.

In any case, I have a fix for my code, move along :)

-Steve

[Issue 17197] Link failure with -m64 on Windows

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #3 from Rainer Schuetze  ---
"Invalid UTF-8" exceptions should no longer happen as I changed the critical
path to use byte[] arrays instead of char[] arrays.
Released in https://github.com/dlang/visuald/releases/tag/v0.45.0-beta1

--

[Issue 17355] Path to lib64 and $(DMDInstallDir) not correct

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #5 from Rainer Schuetze  ---
Now also reading the installer registry keys of Visual D and DMD. Fixed in
https://github.com/dlang/visuald/releases/tag/v0.45.0-beta1

--

[Issue 17470] [scope] this has longer lifetime than this

[via Digitalmars-d-bugs]

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

uplink.co...@googlemail.com changed:

   What|Removed |Added

 Resolution|WORKSFORME  |INVALID

--- Comment #4 from uplink.co...@googlemail.com ---
Apparently this error is valid because structs maybe moved.
in which case `s` would contain a dangling pointer.

--

Re: bug? floating point precision with std.format

[H. S. Teoh via Digitalmars-d]

On Mon, Jun 05, 2017 at 04:29:06PM +, Seb via Digitalmars-d wrote:
> On Monday, 5 June 2017 at 15:37:42 UTC, Steven Schveighoffer wrote:
> > It appears that the precision parameter in std.format differs from its
> > meaning in printf. Is that expected behavior?
> > 
> > Example:
> > 
> > import std.stdio;
> > import core.stdc.stdio;
> > 
> > void main()
> > {
> > auto f = 20.6;
> > writeln(f);
> > writefln("%0.3s", f);
[...]

That should be "%0.3f", not "%0.3s".

If you use the "%s" specifier, precision is interpreted differently,
i.e., as "maximum number of characters", as per "%s" in C's printf.


T

-- 
If it tastes good, it's probably bad for you.

Re: D and GDB

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

On Mon, Jun 05, 2017 at 05:34:14AM +, Basile B. via Digitalmars-d-learn 
wrote:
> On Monday, 5 June 2017 at 01:07:51 UTC, H. S. Teoh wrote:
> > 
> > It can't be any more trivial than just running ddemangle, which is
> > found in the dlang/tools repo on github.
[...]
> > (Arguably this should be shipped by default with dmd... or is it
> > already?)
> 
> Of course it is. Currently i don't use it much but at the beginning of
> 2017 it's been very useful to me, to process valgrind's output, dozen
> and dozen of times. How can anyone ignore that it's shipped with dmd ?

'cos I run dmd off git HEAD, so I've no idea what it ships with/without.
:-D


T

-- 
My program has no bugs! Only undocumented features...

[Issue 17453] I Have Many Issues

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #10 from Rainer Schuetze  ---
I've fixed issue 17260, should affect your code, too. Try
https://github.com/dlang/visuald/releases/tag/v0.45.0-beta1

If problems still exist, please open more specific reports.

--

[Issue 17260] Pending semantic analysis request

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #8 from Rainer Schuetze  ---
Completion on the respective code should work with
https://github.com/dlang/visuald/releases/tag/v0.45.0-beta1

Enabling UFCS might yield too many entries, though.

--

[Issue 17460] Debugger: registers don't work in expression evaluation

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #3 from Rainer Schuetze  ---
try this: https://github.com/dlang/visuald/releases/tag/v0.45.0-beta1

--

Re: Avast virus warning?

[rikki cattermole via Digitalmars-d-learn]

On 05/06/2017 5:31 PM, Anonymouse wrote:
I just sent a pre-compiled .exe of my project to a friend, and his Avast 
anti-virus promptly quarantined it and sent it off for analysis. I tried 
sending him a Hello World[1] with the same results.


Is this something common for d programs? Anything I can do to work 
around it from my end?


[1]: http://www.mediafire.com/file/fc51qz141r3ns6r/helloworld.exe


Yeah Avast is fairly hit happy for D programs, I've tried to get in 
touch with them but they don't make it too easy.


I have posited on IRC that maybe either somebody is doing something very 
bad with D (things like _Dmain as a symbol name are pretty obvious to 
look for!) or they have trained their neural network wrong.


It would be nice to get in touch with their engineers to find out what 
is really going on.

[Issue 17470] [scope] this has longer lifetime than this

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Resolution|FIXED   |WORKSFORME

--- Comment #3 from Vladimir Panteleev  ---
(N.B. Use WORKSFORME instead of FIXED for bugs that shouldn't appear in the
changelog)

--

Avast virus warning?

[Anonymouse via Digitalmars-d-learn]

I just sent a pre-compiled .exe of my project to a friend, and 
his Avast anti-virus promptly quarantined it and sent it off for 
analysis. I tried sending him a Hello World[1] with the same 
results.


Is this something common for d programs? Anything I can do to 
work around it from my end?


[1]: http://www.mediafire.com/file/fc51qz141r3ns6r/helloworld.exe

Re: rawRead using a struct with variable leght

[Era Scarecrow via Digitalmars-d-learn]

On Monday, 5 June 2017 at 16:04:28 UTC, ade90036 wrote:

Unfortunately the struct doesn't know at compile time what the 
size of the constant_pool array, or at-least was not able to 
specify it dynamically.


 It also won't know ahead of time how many fields, methods or 
attributes you have either.


 First I'd say all the arrays will have to be redefined to use 
[], rather than a fixed size.


 Glancing at the chapter information, you're probably not going 
to have an easy time, and will have to simply have to fill in the 
fields individually in order followed by allocating the arrays 
and probably filling/loading those immediately (although it's 
possible the array contents are done at the end, though it seems 
doubtful).

Re: bug? floating point precision with std.format

[Seb via Digitalmars-d]

On Monday, 5 June 2017 at 15:37:42 UTC, Steven Schveighoffer 
wrote:
It appears that the precision parameter in std.format differs 
from its meaning in printf. Is that expected behavior?


Example:

import std.stdio;
import core.stdc.stdio;

void main()
{
auto f = 20.6;
writeln(f);
writefln("%0.3s", f);
printf("%0.3f\n", f);
}

prints:
20.6667
20.7
20.667

It appears that the precision specifier is dictating the total 
number of digits on *both sides* of the decimal place. Whereas, 
in C, it's only the number of digits *after* the decimal place.


I'm trying to specify 3 places of precision after the decimal. 
How do I do this easily?


I'm having a hard time believing this behavior has never been 
reported, but I can't find anything about it in bugzilla. 
Tested all the way back to 2.040.


-Steve


You do realize that you have used "s" in the D version?
This works as expected:

writefln("%0.3f", f); // 20.667
printf("%0.3f\n", f); // 20.667

This is a bit more interesting:

writefln("%0.3s", f); // 20.7
printf("%0.3s\n", f); // 20.

Re: The design of the hooks in std.experimental.checkedint

[via Digitalmars-d]

On Monday, 5 June 2017 at 16:04:18 UTC, Petar Kirov [ZombineDev] 
wrote:

On Monday, 5 June 2017 at 10:29:26 UTC, Jacob Carlborg wrote:
Hook function is defined: "I want to hook this entire 
operation."


Hook function is not defined: "I am not interested in hooking 
this

operation."

If hook is always defined, the shell cannot identify what a 
particular

hook has an interest in.


Right.


(As I'm sure you know) this can be solved by using UDAs. I.e. 
the members of the mixin template can be tagged with e.g. 
@default indicating to the shell that the there was interest in 
overriding them. Of course static ifs will be needed again, but 
if we assume that in the common case the shell doesn't need to 
differentiate between user defined and default hooks, then this 
can be a net win in terms of LoC needed for the shell.


...indicating to the shell that the there was *no* interest in 
overriding them.

[Issue 17470] [scope] this has longer lifetime than this

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
I think the compiler is correct in issuing the error, though the error message
might need improvement. The problem is that you are creating an internal
pointer to the struct, which is forbidden. Since structs are value types,
constructing an instance of X on the stack, then returning it, will cause the s
field to refer to invalid memory.

--

Re: The design of the hooks in std.experimental.checkedint

[via Digitalmars-d]

On Monday, 5 June 2017 at 10:29:26 UTC, Jacob Carlborg wrote:
Hook function is defined: "I want to hook this entire 
operation."


Hook function is not defined: "I am not interested in hooking 
this

operation."

If hook is always defined, the shell cannot identify what a 
particular

hook has an interest in.


Right.


(As I'm sure you know) this can be solved by using UDAs. I.e. the 
members of the mixin template can be tagged with e.g. @default 
indicating to the shell that the there was interest in overriding 
them. Of course static ifs will be needed again, but if we assume 
that in the common case the shell doesn't need to differentiate 
between user defined and default hooks, then this can be a net 
win in terms of LoC needed for the shell.

rawRead using a struct with variable leght

[ade90036 via Digitalmars-d-learn]

Hi everyone,

I'm trying out Dland, always been and have been a big fan. So to 
give it a good run i wanted to create is a java class parser, 
based on the spec released here. ( 
https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html.)


The class file can be represented in the following "struct" like:

ClassFile {
u4 magic;
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_infoconstant_pool[constant_pool_count-1];
u2 access_flags;
u2 this_class;
u2 super_class;
u2 interfaces_count;
u2 interfaces[interfaces_count];
u2 fields_count;
field_info fields[fields_count];
u2 methods_count;
method_infomethods[methods_count];
u2 attributes_count;
attribute_info attributes[attributes_count];
}

where:
u4 == ubyte[4] --> integer
u2 == ubyte[2] --> short
u1 == ubyte[1] --> byte

I have the first 4 fields parsing, however i stumble upon an 
example where you can use a rawRead() with a struct, therefore 
representing the entire structure and then reading from rawRead() 
like


d
ClassFile[1] classFileStruct;
f.rawRead(claddFileStruct);


Unfortunately the struct doesn't know at compile time what the 
size of the constant_pool array, or at-least was not able to 
specify it dynamically.


What is the best approach to go about parsing such structure?

Should i have structs to represent the blocks of fixed fields 
from the structure and then parsing each variable (length) 
structure manually?



Something like this?


ClassHeader[1] classHeader;
f.rawRead(classHeader);

CpInfo[] cpInfo = new CpInfo[classHeader.constant_pool_count];
f.rawRead(cpInfo);
`

Really appreciate any knowledgeable suggestions.

Regards

Ade

[Issue 17470] [scope] this has longer lifetime than this

[via Digitalmars-d-bugs]

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

uplink.co...@googlemail.com changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|uplink.co...@googlemail.com
Summary|[scope] this has longer |[scope] this has longer
   |lifetime then this  |lifetime than this

--

[Issue 17470] New: [scope] this has longer lifetime then this

[via Digitalmars-d-bugs]

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

  Issue ID: 17470
   Summary: [scope] this has longer lifetime then this
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: uplink.co...@googlemail.com

The following code:

@safe struct X {
 byte[] s;
 byte[9] a;
 this(int n)
 {
   assert(n < 9);
   s = a[0 .. n];
 }
}

raises the error

t.d(8): Error: address of variable this assigned to this with longer lifetime
While infact, this has the exact same lifetime as this (it's the same pointer)

--

bug? floating point precision with std.format

[Steven Schveighoffer via Digitalmars-d]

It appears that the precision parameter in std.format differs from its 
meaning in printf. Is that expected behavior?


Example:

import std.stdio;
import core.stdc.stdio;

void main()
{
auto f = 20.6;
writeln(f);
writefln("%0.3s", f);
printf("%0.3f\n", f);
}

prints:
20.6667
20.7
20.667

It appears that the precision specifier is dictating the total number of 
digits on *both sides* of the decimal place. Whereas, in C, it's only 
the number of digits *after* the decimal place.


I'm trying to specify 3 places of precision after the decimal. How do I 
do this easily?


I'm having a hard time believing this behavior has never been reported, 
but I can't find anything about it in bugzilla. Tested all the way back 
to 2.040.


-Steve

Re: DIP 1008 Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Friday, 19 May 2017 at 15:45:28 UTC, Mike Parker wrote:

DIP 1008 is titled "Exceptions and @nogc".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md


I would like the DIP to fully articulate the choice that it's 
facing, that special-casing the language for `throw new` comes 
with some downsides, but that the alternative is to force 
programmers to rewrite all their exceptions if they want to mark 
their functions `@nogc`. This requires an analysis of the 
similarities and differences between `throw new` and other uses 
of `new`. My personal impression is that exceptions do indeed 
fall into a distinct category, where they are easier to contain 
and shorter-lived than ordinary `new` memory. But the downside is 
that the language loses a little elegance by having another 
special case, and there might be corner cases where the special 
case is undesirable. I can only assume that at minimum, should 
this DIP be _rejected_, it should be replaced by some official 
documentation and methods on how to properly throw exceptions in 
`@nogc` code.

[Issue 17469] View source code

[via Digitalmars-d-bugs]

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

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from greensunn...@gmail.com ---
pull: https://github.com/dlang/dlang.org/pull/1668

--

Compile-Time Sort in D

[Mike Parker via Digitalmars-d-announce]

The crowd-edited (?) blog post exploring some of D's compile-time 
features is now live. Thanks again to everyone who helped out 
with it.


The blog:
https://dlang.org/blog/2017/06/05/compile-time-sort-in-d/

Reddit:
https://www.reddit.com/r/programming/comments/6fefdg/compiletime_sort_in_d/

Re: Sorting in D Blog Post Review Request

[Mike Parker via Digitalmars-d]

On Monday, 5 June 2017 at 14:19:38 UTC, Vladimir Panteleev wrote:

On Monday, 5 June 2017 at 11:01:49 UTC, Mike Parker wrote:
Thanks to everyone who provided feedback here and elsewhere. 
I've incorporated much of it and that has resulted in a much 
better post. I'll be publishing it in a ~ 3 hours or so.


Sorry for the late feedback (only saw this recently), but I 
left some comments on the gist.


That's a stale copy now, but thanks anyway :-)

Re: Sorting in D Blog Post Review Request

[Vladimir Panteleev via Digitalmars-d]

On Monday, 5 June 2017 at 11:01:49 UTC, Mike Parker wrote:
Thanks to everyone who provided feedback here and elsewhere. 
I've incorporated much of it and that has resulted in a much 
better post. I'll be publishing it in a ~ 3 hours or so.


Sorry for the late feedback (only saw this recently), but I left 
some comments on the gist.

Re: Idea: Reverse Type Inference

[Steven Schveighoffer via Digitalmars-d]

On 6/3/17 7:37 PM, Enamex wrote:

On Wednesday, 24 May 2017 at 15:02:05 UTC, Steven Schveighoffer wrote:

In fact, you could simulate overloading of return values based on IFTI
instantiation:

void fooImpl(ref int retval, int x) { ... }
void fooImpl(ref string retval, int x) { ... }

T foo(T)(int x) { T t; fooImpl(t, x); return t; }
int x = foo(1);
string y = foo(2);


https://dpaste.dzfl.pl/7d8351fe2f07

What am I doing wrong?


You are not realizing that my example requires IFTI on return types, 
something that I proposed but is not implemented ;)


-Steve

Re: Concept proposal: Safely catching error

[Steven Schveighoffer via Digitalmars-d]

On 6/5/17 5:50 AM, Olivier FAURE wrote:

I recently skimmed the "Bad array indexing is considered deadly" thread,
which discusses the "array OOB throws Error, which throws the whole
program away" problem.

[snip]


My proposal for solving these problems would be to explicitly allow to
catch Errors in @safe code IF the try block from which the Error is
caught is perfectly pure.


I don't think this will work. Only throwing Error makes a function 
nothrow. A nothrow function may not properly clean up the stack while 
unwinding. Not because the stack unwinding code skips over it, but 
because the compiler knows nothing can throw, and so doesn't include the 
cleanup code.


So this means, regardless of whether you catch an Error or not, the 
program may be in a state that is not recoverable.


Not to mention that only doing this for pure code eliminates usages that 
sparked the original discussion, as my code communicates with a 
database, and that wouldn't be allowed in pure code.


The only possible language change I can think of here, is to have a 
third kind of Throwable type. Call it SafeError. A SafeError would be 
only catchable in @system or @trusted code.


This means that @safe code would have to terminate, but any wrapping 
code that is calling the @safe code (such as the vibe.d framework), 
could catch it and properly handle the error, knowing that everything 
was properly cleaned up, and knowing that because we are in @safe code, 
there hasn't been a memory corruption (right?).


Throwing a SafeError prevents a function from being marked nothrow. I 
can't see a way around this, unless we came up with another attribute 
(shudder).


Then we can change the compiler (runtime?) to throwing SafeRangeError 
instead of RangeError inside @safe code.


All of this, I'm not proposing to do, because I don't see it being 
accepted. Creating a new array type which is used in my code will work, 
and avoids all the hassle of navigating the DIP system.


-Steve

[Issue 17469] View source code

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
Probably this is true for everything in Druntime

--

Re: Label as Values in D ?

[Basile B. via Digitalmars-d]

On Monday, 5 June 2017 at 11:40:28 UTC, Patric Dexheimer wrote:

https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Is possible to use Label as Values in D?
Or there is a way to do dynamic goto statements?

Ps: This is out of curiosity / performance reasons. I know the 
potential of bad design / ugly code ;)


It seems that labels are strictly compile time concepts. Once 
used to set the JMP offsets they go back into the nil.


For dynamic goto i think that you're already been given the 
answer: jump tables can be emulated with array of 
delegates/functions, although probably slightly slower (CALL vs 
JMP, there can be a function frame for the CALL destination).

Re: Label as Values in D ?

[Patric Dexheimer via Digitalmars-d]

On Monday, 5 June 2017 at 13:16:43 UTC, ketmar wrote:

Patric Dexheimer wrote:


https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Is possible to use Label as Values in D?
Or there is a way to do dynamic goto statements?

Ps: This is out of curiosity / performance reasons. I know the 
potential of bad design / ugly code ;)


as we have nested functions, you can just initialize a table 
with function pointers, and use it instead of computed goto. 
this is way more powerful trick, as you can actually use any 
selector you want, in any way you want, and still have the 
speed of computed goto (most of the time).


That´s nice, I take a look with compiler explorer and it indeed 
create a jump instead of a call. Not sure if fast as goto, w´ll 
have to benchmark it :)

Re: difference between x = Nullable.init and x.nullify

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, June 05, 2017 10:46:39 Kagamin via Digitalmars-d-learn wrote:
> On Sunday, 4 June 2017 at 08:51:44 UTC, Jonathan M Davis wrote:
> >> On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis
> >>
> >> wrote:
> >> > Assigning Nullable!Test.init is equivalent to setting the
> >> > internal value to Test.init and setting _isNull to false.
> >
> > T _value;
> > bool _isNull = true;
>
> So it was a typo that Nullable.init sets _isNull to false?

Yes.

- Jonathan M Davis

Re: Alias this and inheritance

[ketmar via Digitalmars-d]

Jacob Carlborg wrote:


The following code does not compile:

void foo(string a) {}

class Base
{
 alias bar this;

 string bar()
 {
 return "";
 }
}

class Sub : Base {}

void main()
{
 auto sub = new Sub;
 foo(sub);
}

But if the "alias this" is copied/moved to the subclass it works. Is this 
expected behavior?


yes, afaik. the reasons are similar to not automatically bringing overloads 
when you're doing override, and avoiding other "automatic helpers" most of 
the time: it can quickly get out of control.

Re: Label as Values in D ?

[ketmar via Digitalmars-d]

Patric Dexheimer wrote:


https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Is possible to use Label as Values in D?
Or there is a way to do dynamic goto statements?

Ps: This is out of curiosity / performance reasons. I know the potential 
of bad design / ugly code ;)


as we have nested functions, you can just initialize a table with function 
pointers, and use it instead of computed goto. this is way more powerful 
trick, as you can actually use any selector you want, in any way you want, 
and still have the speed of computed goto (most of the time).

Re: Concept proposal: Safely catching error

[ketmar via Digitalmars-d]

Olivier FAURE wrote:


On Monday, 5 June 2017 at 10:09:30 UTC, ketmar wrote:


tbh, i think that it adds Yet Another Exception Rule to the language, 
and this does no good in the long run. "oh, you generally cannot do 
that, except if today is Friday, it is rainy, and you've seen pink 
unicorn at the morning." the more exceptions to general rules language 
has, the more it reminds Dragon Poker game from Robert Asprin books.


Fair enough. A few counterpoints:

- This one special case is pretty self-contained. It doesn't require 
adding annotations (unlike, say, DIP PR #61*), won't impact code that 
doesn't use it, and the users most likely to hear about it are the one 
who need to recover from Errors in their code.


- It doesn't introduce elaborate under-the-hood tricks (unlike DIP 
1008*). It uses already-existing concepts (@safe and @pure), and is in 
fact closer to the intuitive logic behind Error recovery than the current 
model; instead of "You can't recover from Errors" you have "You can't 
recover from Errors unless you flush all data that might have been 
affected by it".


*Note that I am not making a statement for or against those DIPs. I'm 
only using them as examples to compare my proposal against.


So while this would add feature creep to the language, but I'd argue that 
feature creep would be pretty minor and well-contained, and would 
probably be worth the problem it would solve.


this still nullifies the sense of Error/Exception differences. not all 
errors are recoverable, even in @safe code. assuming that it is safe to 
catch any Error in @safe immediately turns it no unsafe. so... we will need 
to introduce RecoverableInSafeCodeError class, and change runtime to throw 
it instead of Error (sometimes). and even more issues follows (it's 
avalanche of changes, and possible code breakage too).


so, in the original form your idea turns @safe code into unsafe, and with 
more changes it becomes a real pain to implement, and adds more complexity 
to the language (another Dragon Poker modifier).


using wrappers and carefully checking preconditions looks better to me. 
after all, if programmer failed to check some preconditions, the worst 
thing to do is trying to hide that by masking errors. bombing out is *way* 
better, i believe, 'cause it forcing programmer to really fix the bugs 
instead of creating hackish workarounds.

Re: Question to GC experts: NO_SCAN for a part of the block

[Steven Schveighoffer via Digitalmars-d]

On 6/4/17 5:57 AM, Stanislav Blinov wrote:

On Sunday, 4 June 2017 at 09:38:45 UTC, ag0aep6g wrote:


Should this work, and if not, why?


As far as I can tell, the `addRange` call works correctly, but maybe
too well in a sense. It keeps the `new`ed `C`s alive as long as
`arrays3.Cs` has pointers to them. And `arrays3.Cs` has those pointers
until the very end.


Yeah, after playing around with the code a bit, shuffling the calls,
making new allocations, etc., I saw those dtors indeed being run. I was
just expecting the behavior to be the same as for normal 'new'ed arrays,
but I guess there are nuances.


If you add `GC.removeRange(arrays3.Cs.ptr);` at the of `main`, the
dtors show up.


Yeah, well, calling it manually sort of defeats the purpose :)


adding a range marks it as having pointers to scan, AND stores a 
reference to that array, so it won't be GC collected (nor will anything 
it points to). The intention is for it to be used on non-GC memory, like 
C malloc'd memory, where it doesn't matter that the GC is pointing at it.


I would say that you are better off allocating 2 arrays -- one with 
NO_SCAN where you put your non-pointer-containing data, and one without 
the flag to put your other data. This is similar to your "selective" 
function, but instead of allocating 1 array, with a tuple of slices into 
it, just allocate 2 arrays and return the tuple of those 2 arrays.


In my dcollections library, the allocator I use uses malloc for 
non-pointer containing arrays, and GC for everything that could contain 
pointers, and then divvy up the array into the exact sizes I want. Works 
quite well, but the dtor of the container needs to deallocate the 
malloc'd one.


-Steve

Re: Linker cannot find malloc and free on OS X

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-06-05 13:48, bvoq wrote:


So I ran: dmd -unittest -main -v -L-lgmp -L-lc -g gmp/*
The error seems to stem from: cc dbgio.o -o dbgio -g -m64 -Xlinker
-no_compact_unwind -lgmp -lc -L/usr/local/Cellar/dmd/2.074.0/lib -lgmp
-lgmp -lgmp -lgmp -lc -lphobos2 -lpthread -lm

Full invocation of command with verbose flag: cc dbgio.o -o dbgio -g
-m64 -Xlinker -no_compact_unwind -lgmp -lc
-L/usr/local/Cellar/dmd/2.074.0/lib -lgmp -lgmp -lgmp -lgmp -lc
-lphobos2 -lpthread -lm -v
gmp -lc -L/usr/local/Cellar/dmd/2.074.0/lib -lgmp -lgmp -lgmp -lgmp -lc
-lphobos2 -lpthread -lm -v
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"
-demangle -lto_library
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib
-dynamic -arch x86_64 -macosx_version_min 10.12.0 -o dbgio
-L/usr/local/Cellar/dmd/2.074.0/lib dbgio.o -no_compact_unwind -lgmp -lc
-lgmp -lgmp -lgmp -lgmp -lc -lphobos2 -lpthread -lm -lSystem
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/lib/darwin/libclang_rt.osx.a

Undefined symbols for architecture x86_64:
  "free", referenced from:
  _D3gmp1z3MpZ6__ctorMFNaNbNcNiNexAyakZS3gmp1z3MpZ in dbgio.o
  _D3gmp1z3MpZ10fromStringMFNaNbNcNiNjNexAyakZS3gmp1z3MpZ in dbgio.o


I've managed to isolate and identified the problem. The problem is these 
two lines [1]:


pragma(mangle, "malloc") void* qualifiedMalloc(size_t size);
pragma(mangle, "free") void qualifiedFree(void* ptr);

On macOS all C symbols are mangled with an underscore prefix, meaning 
the "free" and "malloc" symbols are actually named _free and _malloc in 
the binary.


This is easy to verify by:

$ cat main.c
void foo();

int main()
{
foo();
return 0;
}

$ clang main.c
Undefined symbols for architecture x86_64:
  "_foo", referenced from:
  _main in main-8a6861.o

Here we can see that the linker is looking for the "_foo" symbol, while 
in your output it's looking for "free", without the underscore prefix.


When pragma(mangle) is used on an extern(C) symbol the compiler will 
automatically handle the prefixing of the symbol on macOS, making it 
line up with any C symbols.


Functions with D linkage have their own mangling, prefixed with _D, the 
fully qualified name mangled and the signature. It seems like that when 
using pragma(mangle) on function with D linkage the compiler will output 
the symbol exactly like it's specified in the source code, in 
pragma(mangle). This can be verified by:


$ cat main.d
void foo();

void main()
{
foo();
}

$ dmd -c main.d
$ nm main.o | grep foo
U _D4main3fooFZv

And when using pragma(mangle):

$ cat main.d
pragma(mangle, "foo") void foo();

void main()
{
foo();
}

$ dmd -c main.d
$ nm main.o | grep foo
U foo

No underscore prefix.

This happens to work on Linux because on Linux this mangling (with the 
underscore prefix) is not used for C symbols. But since the functions 
are not declared as extern(C) we're actually calling C functions using 
the D calling conventions, which just happens to work in this case 
because the C and D calling conventions are mostly the same.


[1] https://github.com/nordlow/gmp-d/blob/master/src/gmp/z.d#L1164-L1165

--
/Jacob Carlborg

Re: Concept proposal: Safely catching error

[Moritz Maxeiner via Digitalmars-d]

On Monday, 5 June 2017 at 12:01:35 UTC, Olivier FAURE wrote:

On Monday, 5 June 2017 at 10:59:28 UTC, Moritz Maxeiner wrote:


Pragmatic question: How much work do you think this will 
require?


Another problem is that non-gc memory allocated in the try 
block would be irreversibly leaked when an Error is thrown 
(though now that I think about it, that would probably count as 
impure and be impossible anyway).


D considers allocating memory as pure[1].

Either way, it's not a safety risk and the programmer can 
decide whether leaking memory is worse than brutally shutting 
down for their purpose.


Sure, but with regards to long running processes that are 
supposed to handle tens of thousands of requests, leaking memory 
(and continuing to run) will likely eventually end up brutally 
shutting down the process on out of memory errors. But yes, that 
is something that would have to be evaluated on a case by case 
basis.




Because writing a generic wrapper that you can customize the 
fault behaviour for using DbI requires very little.


Using an array wrapper only covers part of the problem.


It *replaces* the hard coded assert Errors with flexible attests, 
that can throw whatever you want (or even kill the process 
immediately), you just have to disable the runtimes internal 
bound checks via `-boundscheck=off`.


Users may want their server to keep going even if they fail an 
assertion


Normal assertions (other than assert(false)) are not present in 
-release mode, they are purely for debug mode.



or want the performance of @nothrow code


That's easily doable with the attest approach.

or use a library that throws RangeError in very rare and hard 
to pinpoint cases.


Fix the library (or get it fixed if you don't have the code).



Arrays aside, I think there's some use in being able to safely 
recover from (or safely shut down after) the kind of broken 
contracts that throw Errors.


I consider there to be value in allowing users to say "this is 
not a contract, it is a valid use case" (-> wrapper), but a 
broken contract being recoverable violates the entire concept of 
DbC.


[1] https://dlang.org/spec/function.html#pure-functions

Re: Concept proposal: Safely catching error

[ag0aep6g via Digitalmars-d]

On 06/05/2017 11:50 AM, Olivier FAURE wrote:
- But memory corruption is super bad, if a proved error *might* be 
caused by memory corruption then we must absolutely throw the 
potentially corrupted data away without using it.


- Besides, even without memory corruption, the same argument applies to 
broken invariants; if we have data that breaks invariants, we need to 
throw it away, and use it as little as possible.



[...]


My proposal for solving these problems would be to explicitly allow to 
catch Errors in @safe code IF the try block from which the Error is 
caught is perfectly pure.


In other words, @safe functions would be allowed to catch Error after 
try blocks if the block only mutates data declared inside of it; the 
code would look like:


 import vibe.d;

 // ...

 string handleRequestOrError(in HTTPServerRequest req) @safe {
 ServerData myData = createData();

 try {
 // both doSomethingWithData and mutateMyData are @pure

 doSomethingWithData(req, myData);
 mutateMyData(myData);

 return myData.toString;
 }
 catch (Error) {
 throw new SomeException("Oh no, a system error occured");
 }
 }

 void handleRequest(HTTPServerRequest req,
HTTPServerResponse res) @safe
 {
 try {
 res.writeBody(handleRequestOrError(req), "text/plain");
 }
 catch (SomeException) {
 // Handle exception
 }
 }

The point is, this is safe even when doSomethingWithData breaks an 
invariant or mutateMyData corrupts myData, because the compiler 
guarantees that the only data affected WILL be thrown away or otherwise 
unaccessible by the time catch(Error) is reached.


But `myData` is still alive when `catch (Error)` is reached, isn't it?

[...]


What do you think? Does the idea have merit? Should I make it into a DIP?


How does `@trusted` fit into this? The premise is that there's a bug 
somewhere. You can't assume that the bug is in a `@system` function. It 
can just as well be in a `@trusted` one. And then `@safe` and `pure` 
mean nothing.

Alias this and inheritance

[Jacob Carlborg via Digitalmars-d]

The following code does not compile:

void foo(string a) {}

class Base
{
alias bar this;

string bar()
{
return "";
}
}

class Sub : Base {}

void main()
{
auto sub = new Sub;
foo(sub);
}

But if the "alias this" is copied/moved to the subclass it works. Is 
this expected behavior?


--
/Jacob Carlborg

[Issue 15700] Source code links are partially broken

[via Digitalmars-d-bugs]

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

Nick Vitsas  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17469

--

[Issue 17469] View source code

[via Digitalmars-d-bugs]

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

Nick Vitsas  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15700

--

[Issue 17469] New: View source code

[via Digitalmars-d-bugs]

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

  Issue ID: 17469
   Summary: View source code
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/library/object.html
OS: All
Status: NEW
  Keywords: trivial
  Severity: minor
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: vit...@aueb.gr

Similar to previously reported [Issue 15700]. 

View source code link does not seem to work for HTML docs concerning object.d
(object.TypeInfo, object.Object, object.Throwable e.t.c.).

See for example https://github.com/dlang/phobos/blob/v2.074.1/object.d#L203 for
view source in object.d

--

Re: Concept proposal: Safely catching error

[Olivier FAURE via Digitalmars-d]

On Monday, 5 June 2017 at 10:59:28 UTC, Moritz Maxeiner wrote:


Pragmatic question: How much work do you think this will 
require?


Good question. I'm no compiler programmer, so I'm not sure what 
the answer is.


I would say "probably a few days at most". The change is fairly 
self-contained, and built around existing concepts (mutability 
and @safety); I think it would mostly be a matter of adding a 
function to the safety checks that tests whether a mutable 
reference to non-local data is used in any try block with 
catch(Error).


Another problem is that non-gc memory allocated in the try block 
would be irreversibly leaked when an Error is thrown (though now 
that I think about it, that would probably count as impure and be 
impossible anyway). Either way, it's not a safety risk and the 
programmer can decide whether leaking memory is worse than 
brutally shutting down for their purpose.


Because writing a generic wrapper that you can customize the 
fault behaviour for using DbI requires very little.


Using an array wrapper only covers part of the problem. Users may 
want their server to keep going even if they fail an assertion, 
or want the performance of @nothrow code, or use a library that 
throws RangeError in very rare and hard to pinpoint cases.


Arrays aside, I think there's some use in being able to safely 
recover from (or safely shut down after) the kind of broken 
contracts that throw Errors.

Boston D Meetup for 6/9

[Steven Schveighoffer via Digitalmars-d-announce]

Hi fellow Boston D enthusiasts. We are going to have another meetup at 
the Street in Chestnut Hill this Friday. Andrei and I will be there, 
hope you can join us! Please RSVP on the eventbrite page:


https://www.eventbrite.com/e/monthly-boston-d-get-together-tickets-35120523431


-Steve

Re: Concept proposal: Safely catching error

[Olivier FAURE via Digitalmars-d]

On Monday, 5 June 2017 at 10:09:30 UTC, ketmar wrote:


tbh, i think that it adds Yet Another Exception Rule to the 
language, and this does no good in the long run. "oh, you 
generally cannot do that, except if today is Friday, it is 
rainy, and you've seen pink unicorn at the morning." the more 
exceptions to general rules language has, the more it reminds 
Dragon Poker game from Robert Asprin books.


Fair enough. A few counterpoints:

- This one special case is pretty self-contained. It doesn't 
require adding annotations (unlike, say, DIP PR #61*), won't 
impact code that doesn't use it, and the users most likely to 
hear about it are the one who need to recover from Errors in 
their code.


- It doesn't introduce elaborate under-the-hood tricks (unlike 
DIP 1008*). It uses already-existing concepts (@safe and @pure), 
and is in fact closer to the intuitive logic behind Error 
recovery than the current model; instead of "You can't recover 
from Errors" you have "You can't recover from Errors unless you 
flush all data that might have been affected by it".


*Note that I am not making a statement for or against those DIPs. 
I'm only using them as examples to compare my proposal against.


So while this would add feature creep to the language, but I'd 
argue that feature creep would be pretty minor and 
well-contained, and would probably be worth the problem it would 
solve.

Re: Linker cannot find malloc and free on OS X

[bvoq via Digitalmars-d-learn]

On Monday, 5 June 2017 at 10:34:12 UTC, Jacob Carlborg wrote:

On 2017-06-05 01:14, bvoq wrote:


The flag -L-lc seems to have been passed to the library.
This is the full error message after running it with dub test 
--verbose


You need to continue to invoke the sub commands, that is, DMD, 
Clang and the linker with the verbose flag (-v) added. There's 
no point in looking for "-lc" since the C standard library on 
macOS is placed in /usr/lib/libSystem.B.dylib.


So I ran: dmd -unittest -main -v -L-lgmp -L-lc -g gmp/*
The error seems to stem from: cc dbgio.o -o dbgio -g -m64 
-Xlinker -no_compact_unwind -lgmp -lc 
-L/usr/local/Cellar/dmd/2.074.0/lib -lgmp -lgmp -lgmp -lgmp -lc 
-lphobos2 -lpthread -lm


Full invocation of command with verbose flag: cc dbgio.o -o dbgio 
-g -m64 -Xlinker -no_compact_unwind -lgmp -lc 
-L/usr/local/Cellar/dmd/2.074.0/lib -lgmp -lgmp -lgmp -lgmp -lc 
-lphobos2 -lpthread -lm -v
gmp -lc -L/usr/local/Cellar/dmd/2.074.0/lib -lgmp -lgmp -lgmp 
-lgmp -lc -lphobos2 -lpthread -lm -v

Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.12.0 -o dbgio -L/usr/local/Cellar/dmd/2.074.0/lib dbgio.o -no_compact_unwind -lgmp -lc -lgmp -lgmp -lgmp -lgmp -lc -lphobos2 -lpthread -lm -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/lib/darwin/libclang_rt.osx.a

Undefined symbols for architecture x86_64:
  "free", referenced from:
  _D3gmp1z3MpZ6__ctorMFNaNbNcNiNexAyakZS3gmp1z3MpZ in dbgio.o
  _D3gmp1z3MpZ10fromStringMFNaNbNcNiNjNexAyakZS3gmp1z3MpZ in 
dbgio.o
 (maybe you meant: 
_D2rt4util9container5treap33__T5TreapTS2gc11gcinterface4RootZ5Treap8freeNodeFNbNiPS2rt4util9container5treap33__T5TreapTS2gc11gcinterface4RootZ5Treap4NodeZv, _D2gc4impl12conservative2gc3Gcx8log_freeMFNbPvZv , _D2gc4impl12conservative2gc4Pool12freePageBitsMFNbmKxG4mZv , _D2gc4impl12conservative2gc8freeTimel , _D2rt5minfo11ModuleGroup4freeMFZv , _D2gc4impl6manual2gc8ManualGC4freeMFNbPvZv , _D2gc4impl12conservative2gc14ConservativeGC10freeNoSyncMFNbPvZv , _D2gc4impl12conservative2gc14ConservativeGC163__T9runLockedS63_D2gc4impl12conservative2gc14ConservativeGC10freeNoSyncMFNbPvZvS37_D2gc4impl12conservative2gc8freeTimelS37_D2gc4impl12conservative2gc8numFreeslTPvZ9runLockedMFNbKPvZv , _D2rt4util9container5treap34__T5TreapTS2gc11gcinterface5RangeZ5Treap8freeNodeFNbNiPS2rt4util9container5treap34__T5TreapTS2gc11gcinterface5RangeZ5Treap4NodeZv , _D2gc4impl12conservative2gc15LargeObjectPool9freePagesMFNbmmZv , _D2rt7dwarfeh15ExceptionHeader4freeFPS2rt7dwarfeh15ExceptionHeaderZv , _D2gc4!

impl12conservative2gc14ConservativeGC4freeMFNbPvZv , 
_D4core6memory2GC4freeFNaNbPvZv , _gc_free )
  "malloc", referenced from:
  _D3gmp1z3MpZ19_allocStringzCopyOfMFNaNbNiNexAyaZPa in 
dbgio.o
 (maybe you meant: 
_D2gc4impl12conservative2gc3Gcx10log_mallocMFNbPvmZv, 
_D2gc4impl12conservative2gc10mallocTimel , 
_D2gc4impl6manual2gc8ManualGC6mallocMFNbmkxC8TypeInfoZPv , 
_D2gc4impl12conservative2gc14ConservativeGC207__T9runLockedS83_D2gc4impl12conservative2gc14ConservativeGC13reallocNoSyncMFNbPvmKkKmxC8TypeInfoZPvS40_D2gc4impl12conservative2gc10mallocTimelS40_D2gc4impl12conservative2gc10numMallocslTPvTmTkTmTxC8TypeInfoZ9runLockedMFNbKPvKmKkKmKxC8TypeInfoZPv , _D2gc4impl12conservative2gc14ConservativeGC6mallocMFNbmkxC8TypeInfoZPv , _D2gc4impl12conservative2gc14ConservativeGC12mallocNoSyncMFNbmkKmxC8TypeInfoZPv , _D4core6memory2GC6mallocFNaNbmkxC8TypeInfoZPv , _gc_malloc , _D2rt4util9container6common7xmallocFNbNimZPv , _D2gc4impl12conservative2gc14ConservativeGC200__T9runLockedS79_D2gc4impl12conservative2gc14ConservativeGC12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS40_D2gc4impl12conservative2gc10mallocTimelS40_D2gc4impl12conservative2gc10numMallocslTmTkTmTxC8TypeInfoZ9runLockedMFNbKmKkKmKxC8TypeInfoZPv )

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)



--

From there the command which yielded the error is:

"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"
 -demangle -lto_library 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib
 -dynamic -arch x86_64 -macosx_version_min 10.12.0 -o dbgio 
-L/usr/local/Cellar/dmd/2.074.0/lib dbgio.o -no_compact_unwind -lgmp -lc -lgmp -lgmp 
-lgmp -lgmp -lc -lphobos2 -lpthread -lm -lSystem 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/lib/darwin/libclang_rt.osx.a
 -v



The 

Label as Values in D ?

[Patric Dexheimer via Digitalmars-d]

https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Is possible to use Label as Values in D?
Or there is a way to do dynamic goto statements?

Ps: This is out of curiosity / performance reasons. I know the 
potential of bad design / ugly code ;)

Re: Implicit casting of int enum members to int

[Mike Bierlee via Digitalmars-d-learn]

On Monday, 5 June 2017 at 01:23:22 UTC, Mike B Johnson wrote:
On Monday, 3 October 2016 at 09:21:37 UTC, Jonathan M Davis 
wrote:

Is this bug ever going to be fixed?



I've filed this issue under 
https://issues.dlang.org/show_bug.cgi?id=16586 a while ago, seems 
to have not been picked up yet.

Re: DIP 1003 (Remove body as a Keyword) Accepted!

[Olivier FAURE via Digitalmars-d-announce]

On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote:


https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md


The "See the previous version" link at the end of the document is 
currently broken and leads to a 404.


Thank you for your efforts and congratulations to Jared Hanson!

Re: Sorting in D Blog Post Review Request

[Mike Parker via Digitalmars-d]

On Sunday, 4 June 2017 at 16:07:35 UTC, Mike Parker wrote:

So I took the feedback I've gotten so far, stepped away and 
thought about it for a bit, and agreed that I was taking the 
wrong approach. So I've given it a rewrite. The original gist 
is still there, but the new one is here:


https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453

I'm open to any changes or additions anyone would like to make. 
That includes rewriting large portions of it (or all of it, if 
anyone is up for it).


Destroy!


Thanks to everyone who provided feedback here and elsewhere. I've 
incorporated much of it and that has resulted in a much better 
post. I'll be publishing it in a ~ 3 hours or so.

Re: Concept proposal: Safely catching error

[Moritz Maxeiner via Digitalmars-d]

On Monday, 5 June 2017 at 09:50:15 UTC, Olivier FAURE wrote:
My proposal for solving these problems would be to explicitly 
allow to catch Errors in @safe code IF the try block from which 
the Error is caught is perfectly pure.


This would allow to design applications that can fail 
gracefully when dealing with multiple independent clients or 
tasks, even when one of the tasks has to thrown away because of 
a programmer error.


What do you think? Does the idea have merit? Should I make it 
into a DIP?


Pragmatic question: How much work do you think this will require?
Because writing a generic wrapper that you can customize the 
fault behaviour for using DbI requires very little[1].


[1] 
https://github.com/Calrama/libds/blob/fbceda333dbf76697050faeb6e25dbfcc9e3fbc0/src/ds/linear/array/dynamic.d

Re: Anyone tried to emscripten a D/SDL game?

[Johan Engelen via Digitalmars-d]

On Monday, 5 June 2017 at 05:22:44 UTC, Sebastien Alaiwan wrote:


The whole simplified toolchain and example project live here: 
https://github.com/Ace17/dscripten


Are you planning on upstreaming some of your work to LDC? Please 
do! :-)
Looks like it is relatively easy to integrate most of your 
changes.


For `llvm::Triple::asmjs` and `llvm::Triple::Emscripten`, what 
predefined versions would you propose ?
Have a look here: 
https://dlang.org/spec/version.html#predefined-versions


Cheers,
  Johan

Re: difference between x = Nullable.init and x.nullify

[Kagamin via Digitalmars-d-learn]

On Sunday, 4 June 2017 at 08:51:44 UTC, Jonathan M Davis wrote:
On Saturday, 3 June 2017 at 06:19:29 UTC, Jonathan M Davis 
wrote:
> Assigning Nullable!Test.init is equivalent to setting the 
> internal value to Test.init and setting _isNull to false.



T _value;
bool _isNull = true;


So it was a typo that Nullable.init sets _isNull to false?

Re: Linker cannot find malloc and free on OS X

[Jacob Carlborg via Digitalmars-d-learn]

On 2017-06-05 01:14, bvoq wrote:


The flag -L-lc seems to have been passed to the library.
This is the full error message after running it with dub test --verbose


You need to continue to invoke the sub commands, that is, DMD, Clang and 
the linker with the verbose flag (-v) added. There's no point in looking 
for "-lc" since the C standard library on macOS is placed in 
/usr/lib/libSystem.B.dylib.


--
/Jacob Carlborg

Re: The design of the hooks in std.experimental.checkedint

[Jacob Carlborg via Digitalmars-d]

On 2017-06-04 21:52, Andrei Alexandrescu wrote:


What would be the advantage of moving the default into a hook?


The whole idea was to reduce the number of "static if" in the 
implementation.



Hook function is defined: "I want to hook this entire operation."

Hook function is not defined: "I am not interested in hooking this
operation."

If hook is always defined, the shell cannot identify what a particular
hook has an interest in.


Right.

--
/Jacob Carlborg

Re: Concept proposal: Safely catching error

[ketmar via Digitalmars-d]

Olivier FAURE wrote:


What do you think? Does the idea have merit? Should I make it into a DIP?


tbh, i think that it adds Yet Another Exception Rule to the language, and 
this does no good in the long run. "oh, you generally cannot do that, 
except if today is Friday, it is rainy, and you've seen pink unicorn at the 
morning." the more exceptions to general rules language has, the more it 
reminds Dragon Poker game from Robert Asprin books. any exception will 
usually have a strong rationale behind it, of course, so it will be a 
little reason to not accept it, especially if we had accepted some 
exceptions before. i think it is better to not follow that path, even if 
this one idea looks nice.

Concept proposal: Safely catching error

[Olivier FAURE via Digitalmars-d]

I recently skimmed the "Bad array indexing is considered deadly" 
thread, which discusses the "array OOB throws Error, which throws 
the whole program away" problem.


The gist of the debate is:

- Array OOB is a programming problem; it means an invariant is 
broken, which means the code surrounding it probably makes 
invalid assumptions and shouldn't be trusted.


- Also, it can be caused by memory corruption.

- But then again, anything can be cause by memory corruption, so 
it's kind of an odd thing to worry about. We should worry about 
not causing it, not making memory corrupted programs safe, since 
it's extremely rare and there's not much we can do about it 
anyway.


- But memory corruption is super bad, if a proved error *might* 
be caused by memory corruption then we must absolutely throw the 
potentially corrupted data away without using it.


- Besides, even without memory corruption, the same argument 
applies to broken invariants; if we have data that breaks 
invariants, we need to throw it away, and use it as little as 
possible.


- But sometimes we have very big applications with lots of data 
and lots of code. If my server deals with dozens of clients or 
more, I don't want to brutally disconnect them all because I need 
to throw away one user's data.


- This could be achieved with processes. Then again, using 
processes often isn't practical for performance or architecture 
reasons.


My proposal for solving these problems would be to explicitly 
allow to catch Errors in @safe code IF the try block from which 
the Error is caught is perfectly pure.


In other words, @safe functions would be allowed to catch Error 
after try blocks if the block only mutates data declared inside 
of it; the code would look like:


import vibe.d;

// ...

string handleRequestOrError(in HTTPServerRequest req) @safe {
ServerData myData = createData();

try {
// both doSomethingWithData and mutateMyData are @pure

doSomethingWithData(req, myData);
mutateMyData(myData);

return myData.toString;
}
catch (Error) {
throw new SomeException("Oh no, a system error 
occured");

}
}

void handleRequest(HTTPServerRequest req,
   HTTPServerResponse res) @safe
{
try {
res.writeBody(handleRequestOrError(req), 
"text/plain");

}
catch (SomeException) {
// Handle exception
}
}

The point is, this is safe even when doSomethingWithData breaks 
an invariant or mutateMyData corrupts myData, because the 
compiler guarantees that the only data affected WILL be thrown 
away or otherwise unaccessible by the time catch(Error) is 
reached.


This would allow to design applications that can fail gracefully 
when dealing with multiple independent clients or tasks, even 
when one of the tasks has to thrown away because of a programmer 
error.


What do you think? Does the idea have merit? Should I make it 
into a DIP?

Re: D and GDB

[Mike Wey via Digitalmars-d-learn]

On 06/05/2017 03:07 AM, H. S. Teoh via Digitalmars-d-learn wrote:

It can't be any more trivial than just running ddemangle, which is found
in the dlang/tools repo on github. (Arguably this should be shipped by
default with dmd... or is it already?)



Recent? versions of gdb also support demangling D symbols, it should 
detect it's D when you compile with -g.


--
Mike Wey

Re: DIP 1003 (Remove body as a Keyword) Accepted!

[via Digitalmars-d-announce]

On Saturday, 3 June 2017 at 20:06:05 UTC, Walter Bright wrote:

On 6/3/2017 12:28 AM, Petar Kirov [ZombineDev] wrote:
Personally, making contracts less verbose and more powerful is 
much higher on my list
We did discuss bouncing the DIP back with a request to revamp 
it as a complete overhaul of the contract syntax, but decided 
that this DIP was about resolving a simple and immediate 
problem, and it shouldn't be held up on that basis.


Yes, keeping scope of DIP1003 was the right call. In order to for 
the process to be effective, we need to have good turnaround time.
That said, I'm glad to hear that the idea of an overhaul the 
contract syntax is on your radar. Related to that, is the need to 
formally specify what exactly is the compiler allowed to assume 
via asserts. Currently the answer is offensive​ programming [0] 
which doesn't play well with domains that require defensive​ 
programming. But that's a topic for another day and another DIP.


[0]: 
https://en.wikipedia.org/wiki/Defensive_programming#Offensive_programming

Re: iOS Apps in D

[Joakim via Digitalmars-d-learn]

On Wednesday, 31 May 2017 at 12:49:38 UTC, Oleksii wrote:

Hi everybody,

Perhaps this topic has been raised many times before, but I'm 
going to go back to it anyways :-P


Are there any good reference materials and/or tutorials on 
programming for iOS and Android in D?


Other than this wiki page that shows you how to build a basic 
Android app and the README for the iOS port, no:


https://wiki.dlang.org/Build_LDC_for_Android
https://github.com/smolt/ldc-iphone-dev/blob/master/README.md

I wonder if anybody could share their story of success with D 
on mobile?


I don't think there has been one.  The closest is this demo of 
porting some DlangUI apps to Android:


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

Re: C++17 cannot beat D surely

[Atila Neves via Digitalmars-d]

On Saturday, 3 June 2017 at 22:00:56 UTC, Ali Çehreli wrote:

On 06/03/2017 12:12 PM, Steven Schveighoffer wrote:

> I'd say this deserves a blog post but it would be too short.

I made many good friends at C++Now. Some of them know Atila 
from CppCon and other C++ conferences. (Beer involved. :) ) 
They told me Atila would routinely tell them during C++ 
presentations "This wouldn't be a talk at a DConf; it's a 
language feature in D." :)




Beer involved. Conference. And they knew _me_? *Shocked*

:P

There were two distinct talks at CppCon2017 involving some 
seriously crazy C++ metaprogramming that I said that about. Very 
interesting how they made the compiler bend over backwards, very 
high-level stuff. Then when everyone was leaving the room I 
couldn't help but think that nobody would even mention those 
techniques in D, you'd get the job done in 5min.


Atila

Re: D scripting in D

[Joakim via Digitalmars-d-learn]

On Saturday, 3 June 2017 at 17:28:36 UTC, Adam D. Ruppe wrote:

On Saturday, 3 June 2017 at 17:24:08 UTC, Russel Winder wrote:
So why isn't rdmd shipped as a separate thing if it can wrap 
any of the three compilers?


it is... the link above is all there is to it, you simply 
compile it. The docs also call it a download: 
http://dlang.org/rdmd.html


dmd just happens to bundle it. The others prolly should too.


Ldc should have it in the next release, except on Windows:

https://github.com/ldc-developers/ldc/issues/548#issuecomment-306073946