Re: general questions about static this() at module level

[sarn via Digitalmars-d-learn]

On Monday, 31 October 2016 at 04:35:35 UTC, WhatMeWorry wrote:
First, are there any other languages that has this feature?  
The few I know, certainly don't.


I've seen hacks to do the same thing in C++.  They're not pretty, 
though.


And how would you compare and contrast these this(s) with those 
of structs and classes?
Like, are they especially good for certain D idioms, particular 
cases, or are they good in general?


Class/struct static constructors are good for initialising 
class/struct static data.  Module static constructors are good 
for initialising module "static data" (i.e., globals).  They're 
especially handy for initialising immutable global data (which is 
the kind of global data D encourages).


BTW, immutable data is shared between threads, so you should use 
"shared static this" to initialise it.  Regular static 
constructors are executed per thread.

general questions about static this() at module level

[WhatMeWorry via Digitalmars-d-learn]

I am fascinated with D's module static this.

I have shamelessly stolen Ali's code directly from his book.

module cat;

static this() {
// ... the initial operations of the module ...
}
static ~this() {
// ... the final operations of the module ...
}


First, are there any other languages that has this feature?  The 
few I know, certainly don't.


And how would you compare and contrast these this(s) with those 
of structs and classes?
Like, are they especially good for certain D idioms, particular 
cases, or are they good in general?


Thirdly, can anyone point to existing code for good examples.

I searched on github for "static this" and 10,499 results were 
returned :)

Got a post for the D Blog?

[Mike Parker via Digitalmars-d-announce]

So far, getting content for the blog has, with a few exceptions, 
been a process of sending out emails prompted by activity on my 
radar. This is no problem when it comes to project highlights or 
other fairly broad topics, but it's highly inefficient for 
ginning up technical posts on the implementation of specific 
algorithms, or optimization details, or how a D feature prevented 
a nuclear meltdown.


I want to publish more posts like Andreas's 'Find Was Too Damn 
Slow, So We Fixed It` [1] (which, by the way, is the most-viewed 
post so far, just ahead of Joakim's interview with Walter [2]), 
or Steven's 'How to Write @trusted Code in D' [3], but I need 
help.


If you, or someone you know, have done something interesting with 
an algorithm or optimization in D, or have used a D idiom to do 
things in a way that pleasantly surprised you, please let me 
know. If I think it's something we can work with, I'll help you 
in putting together a guest post, or something like I do with the 
project highlights (where I build a post around whatever info you 
give me).


Also, I need news. If you see or hear any D news anywhere outside 
of the forums -- new projects, research papers, usage at a 
company, a game using D -- please drop me a line. I'll either get 
a post together for it or make sure Adam knows about it for 'This 
Week in D'.


I'm also open to ideas for other types of posts, like project 
highlights, but I'd really like more of the technical stuff. 
Please send any suggestions to aldac...@gmail.com.


Thanks!

[1] 
http://dlang.org/blog/2016/06/16/find-was-too-damn-slow-so-we-fixed-it/
[2] 
http://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/
[3] 
http://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/

Re: Release D 2.072.0

[Nick Sabalausky via Digitalmars-d-announce]

On 10/30/2016 09:27 PM, Martin Nowak wrote:


This is the release ships with the latest version of dub (v1.1.0),


Changelog for dub 1.1.0?

Dlang 2016 roadmap is over? Look rust roadmap.

[Brian via Digitalmars-d]

dlang:
http://wiki.dlang.org/Vision/2016H1

rust:
https://github.com/aturon/rfcs/blob/roadmap-2017/text/-roadmap-2017.md

Box2D Lite D Port (Yet Another)

[ketmar via Digitalmars-d-announce]

hi. i was in need of very simple (yet usable for something more 
than "hey, this is how Big Players doing physics!") 2d physics 
engine for some of my pet projects, and i decided to use Box2D 
Lite as base (mostly 'cause it has simple joints implemented). so 
i ported it, mutilated it and had it working in less than 40 kb 
of source code. so far, so good. but suddenly...


but suddenly i realised that B2DL can operate only on boxes (no 
other body shapes were implemented), and it has O(N^2) broad 
phase. of course, this is perfectly fine for a demo purposes, but 
little limiting for my projects. so after mutilating the patient, 
i surgically enhanced it a little[1].


now my port supports the following features:
* convex polygonal bodies with different density
* SAT collistion detection
* hard and soft joints
* friction
* O(N*logN) broad phase
* source size is still ~65 KB

this is not a finished physics engine, of course, and you will 
have to do some more work to make it usable in real apps (like 
adding contact callbacks, for example), but it can give you 
something you can start with, still not really hard to follow, 
but more complete than original Box2D Lite.


among other things my port has (almost) standalone implementation 
of Dynamic AABB Tree, which powers new broad phase. even without 
further optimizations (like frozen bodies), it allows me to 
process 1100 bodies in less than 30 milliseconds. don't even try 
that with O(N^2) broad phase! ;-)


even if you aren't interested in physics engine per se, you can 
rip (and tear ;-) this implementation and use it in your 
projects. any project that needs some form of fast spatial 
selection (either 2D or 3D, the implementation supports both) can 
benefit from using dynamic balanced trees for that. it is based 
on "real" Box2D AABB Trees, and is fairly efficient (and taken 
from another project too ;-). it is using malloced pool of nodes 
internally, so it should be suitable for nogc realtime rendering.


you will need my iv.vmath[2] library for vector math. physics 
library doesn't draw anything on it's own, but the sample does, 
so it requires my iv.glbinds[3] and simpledisplay from Adam's 
arsd[4].


the code itself is not the cleanest one, but it is still readable 
(i hope), and should be easy to follow and modify.


good luck and happy hacking!


p.s. it looks like Chipmunk library has the same origins (and 
genesis, at least to some extent ;-).



[1] http://repo.or.cz/b2ld.git
[2] http://repo.or.cz/iv.d.git/blob_plain/HEAD:/vmath.d
[3] http://repo.or.cz/iv.d.git/tree/HEAD:/glbinds
[4] https://github.com/adamdruppe/arsd

Re: strange -fPIC compilation error

[Charles Hixson via Digitalmars-d-learn]

On 10/30/2016 05:14 PM, Lodovico Giaretta via Digitalmars-d-learn wrote:

On Monday, 31 October 2016 at 00:08:59 UTC, Charles Hixson wrote:
So now I removed the repository version of dmd and dub, downloaded 
DMD64 D Compiler v2.072.0-b2, used dkpg to install it, and appear to 
get the same errors.


(Well, actually I removed the commenting out of the code, but it 
compiles and runs properly with ldc2.)


I don't think it's a problem of DMD. This is due to your gcc 
installation being hardened, that is, configured to produce PIE by 
default. To produce PIE, the linker needs to be fed PIC, which DMD 
does not produce by default. The -fPIC flags makes DMD produce PIC out 
of your sources. The problem is, libphobos2.a (the static version of 
Phobos) is not compiled with -fPIC, so even if your code is PIC, gcc 
will complain. The workaround is to use -defaultlib=libphobos2.so to 
dynamically link with the shared version of Phobos. Being it a shared 
object, it does not give any problem with PIE.


Looking on internet, I didn't find any clue about Debian shipping an 
hardened gcc, but this is the only cause I can think of for the 
behaviour you are experiencing.



Well, that certainly changed the error messages.  With
dmd -defaultlib=/usr/lib/x86_64-linux-gnu/libphobos2.so test.d
I get:
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1121): Error: found 
'nothrow' when expecting '{'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1123): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1124): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1125): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1126): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1127): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1128): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1129): Error: 
mismatched number of curly brackets
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1133): Error: asm 
statements must end in ';'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1136): Error: found 
'private' instead of statement
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1146): Error: no 
identifier for declarator add
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: no 
identifier for declarator usDone
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1149): Error: 
Declaration expected, not ':'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1157): Error: 
Declaration expected, not '('
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not 'foreach'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1159): Error: 
Declaration expected, not '0'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: no 
identifier for declarator __fhnd_info[fd]
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1164): Error: 
Declaration expected, not '='
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1165): Error: 
Declaration expected, not 'return'
/usr/include/dmd/druntime/import/core/stdc/stdio.d(1167): Error: 
unrecognized declaration
/usr/include/dmd/phobos/std/typecons.d(1124): Error: semicolon expected 
following function declaration

Release D 2.072.0

[Martin Nowak via Digitalmars-d-announce]

Glad to announce D 2.072.0.

http://dlang.org/download.html

This is the release ships with the latest version of dub (v1.1.0), comes
with lots of phobos additions and native TLS on OSX.
See the changelog for more details.

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

-Martin

[Issue 16629] [Reg 2.072] scope is stripped from some parameters

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dlang.org/commit/7888921913009becd68bd70195a073b4e051f17d
changelog entry for ignored scope on value params

--

Re: Parse a String given some delimiters

[Alfred Newman via Digitalmars-d-learn]

On Sunday, 30 October 2016 at 23:47:54 UTC, Ali Çehreli wrote:

On 10/30/2016 01:50 PM, Alfred Newman wrote:

[...]


Here is something along the lines of what others have suggested:

auto parse(R, S)(R range, S separators) {
import std.algorithm : splitter, filter, canFind;
import std.range : empty;

[...]


Thank you @all.

@Ali, that's exactly what I was looking for.
The phobos is awesome (and pretty huge).

Cheers

Re: strange -fPIC compilation error

[Lodovico Giaretta via Digitalmars-d-learn]

On Monday, 31 October 2016 at 00:08:59 UTC, Charles Hixson wrote:
So now I removed the repository version of dmd and dub, 
downloaded DMD64 D Compiler v2.072.0-b2, used dkpg to install 
it, and appear to get the same errors.


(Well, actually I removed the commenting out of the code, but 
it compiles and runs properly with ldc2.)


I don't think it's a problem of DMD. This is due to your gcc 
installation being hardened, that is, configured to produce PIE 
by default. To produce PIE, the linker needs to be fed PIC, which 
DMD does not produce by default. The -fPIC flags makes DMD 
produce PIC out of your sources. The problem is, libphobos2.a 
(the static version of Phobos) is not compiled with -fPIC, so 
even if your code is PIC, gcc will complain. The workaround is to 
use -defaultlib=libphobos2.so to dynamically link with the shared 
version of Phobos. Being it a shared object, it does not give any 
problem with PIE.


Looking on internet, I didn't find any clue about Debian shipping 
an hardened gcc, but this is the only cause I can think of for 
the behaviour you are experiencing.

Re: strange -fPIC compilation error

[Charles Hixson via Digitalmars-d-learn]

So now I removed the repository version of dmd and dub, downloaded DMD64 
D Compiler v2.072.0-b2, used dkpg to install it, and appear to get the 
same errors.


(Well, actually I removed the commenting out of the code, but it 
compiles and runs properly with ldc2.)



On 10/30/2016 11:02 AM, Charles Hixson via Digitalmars-d-learn wrote:

 dmd --version
DMD64 D Compiler v2.071.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
on debian testing.

dub is installed via apt-get.

Should I revert to an earlier version?  Or what?

The program:


importstd.stdio;

voidmain()
{//int[]t1;

//t1~=1;
//t1~=2;
//writeln ("t1 = ", t1);
}

fails with the 442 lines of error:

/usr/bin/ld: test.o: relocation R_X86_64_32 against symbol 
`__dmd_personality_v0' can not be used when making a shared object; 
recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_224_3b4.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_227_4a2.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_229_5cc.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_626_47b.o): 
relocation R_X86_64_32 against symbol `_D6object9Throwable7__ClassZ' 
can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_628_776.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(dwarfeh_62b_6b9.o): relocation 
R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when 
making a shared object; recompile with -fPIC

...

/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(aaA_51a_53e.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC

/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
--- errorlevel 1

Re: Fun: Shooting yourself in the foot in D

[Ali Çehreli via Digitalmars-d]

On 10/30/2016 04:41 PM, captaindet wrote:

> ulong toe0 = 2;
> shared ulong toe1 = 2;
> shared ulong toe2 = 2;
> shared ulong toe3 = 2;

Those toes are toolong and one is already missing. Make sure that the 
-boundscheck compiler flag is set. :o)


Ali

splitter trouble

[Ali Çehreli via Digitalmars-d-learn]

While working on a solution for Alfred Newman's thread, I came up with 
the following interim solution, which compiled but failed:


auto parse(R, S)(R range, S separators) {
import std.algorithm : splitter, filter, canFind;
import std.range : empty;

static bool pred(E, S)(E e, S s) {
return s.canFind(e);
}

return range.splitter!pred(separators).filter!(token => !token.empty);
}

unittest {
import std.algorithm : equal;
import std.string : format;
auto parsed = parse("_My   input.string", " _,.");
assert(parsed.equal([ "My", "input", "string" ]), format("%s", 
parsed));

}

void main() {
}

The unit test fails and prints

["put", "ing"]

not the expected

["My", "input", "string"].

How is that happening? Am I unintentionally hitting a weird overload of 
splitter?


Ali

Re: strange -fPIC compilation error

[Charles Hixson via Digitalmars-d-learn]

Just as a test I tried it with ldc, and, as expected, there wasn't any 
problem.



On 10/30/2016 11:02 AM, Charles Hixson via Digitalmars-d-learn wrote:

 dmd --version
DMD64 D Compiler v2.071.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
on debian testing.

dub is installed via apt-get.

Should I revert to an earlier version?  Or what?

The program:


importstd.stdio;

voidmain()
{//int[]t1;

//t1~=1;
//t1~=2;
//writeln ("t1 = ", t1);
}

fails with the 442 lines of error:

/usr/bin/ld: test.o: relocation R_X86_64_32 against symbol 
`__dmd_personality_v0' can not be used when making a shared object; 
recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_224_3b4.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_227_4a2.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_229_5cc.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_626_47b.o): 
relocation R_X86_64_32 against symbol `_D6object9Throwable7__ClassZ' 
can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_628_776.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(dwarfeh_62b_6b9.o): relocation 
R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when 
making a shared object; recompile with -fPIC

...

/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(aaA_51a_53e.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC

/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
--- errorlevel 1

Re: Parse a String given some delimiters

[Ali Çehreli via Digitalmars-d-learn]

On 10/30/2016 01:50 PM, Alfred Newman wrote:

Hello,

I'm migrating some Python code to D, but I stuck at a dead end...

Sorry to provide some .py lines over here, but I got some doubts about
the best (fastest) way to do that in D.

Executing the function parsertoken("_My   input.string", " _,.", 2) will
result "input".
Parsercount("Dlang=-rocks!", " =-") will result 2,

def parsertoken(istring, idelimiters, iposition):
"""
Return a specific token of a given input string,
considering its position and the provided delimiters

:param istring: raw input string
:param idelimiteres: delimiters to split the tokens
:param iposition: position of the token
:return: token
"""
vlist=''.join([s if s not in idelimiters else ' ' for s in
istring]).split()
return vlist[vposition]

def parsercount(istring, idelimiters):
"""
Return the number of tokens at the input string
considering the delimiters provided

:param istring: raw input string
:param idelimiteres: delimiters to split the tokens
:return: a list with all the tokens found
"""
vlist=''.join([s if s not in vdelimiters else ' ' for s in
istring]).split()
return len(vlist)-1


Thanks in advance


Here is something along the lines of what others have suggested:

auto parse(R, S)(R range, S separators) {
import std.algorithm : splitter, filter, canFind;
import std.range : empty;

return range.splitter!(c => separators.canFind(c)).filter!(token => 
!token.empty);

}

unittest {
import std.algorithm : equal;

assert(parse("_My   input.string", " _,.").equal([ "My", "input", 
"string" ]));

}

auto parsertoken(R, S)(R range, S separator, size_t position) {
import std.range : drop;

return parse(range, separator).drop(position).front;
}

unittest {
import std.algorithm : equal;

assert(parsertoken("_My   input.string", " _,.", 1).equal("input"));
}

auto parsercount(R, S)(R range, S separator) {
import std.algorithm : count;

return parse(range, separator).count;
}

unittest {
assert(parsercount("Dlang=-rocks!", " =-") == 2);
}

void main() {
}

Ali

Re: Fun: Shooting yourself in the foot in D

[captaindet via Digitalmars-d]

as i just happened to have me mutilated, i couldn't resist (even though 
the example 'works' only with DMD-m64 bullets):



being forced to share your foot among parallel universes, it will surely 
find a stray bullet in one of them.



can you guess which toe is going to be blown off?

'''
version(DigitalMars)version(D_LP64){
import std.stdio: writeln;
import core.atomic  : atomicOp;

ulong toe0 = 2;
shared ulong toe1 = 2;
shared ulong toe2 = 2;
shared ulong toe3 = 2;
uint bullet1 = 1;
int bullet2 = 1;
ulong bullet3 = 1;

toe0 -= 1;
writeln( "toe0: ", toe0 );

atomicOp!"-="( toe1, bullet1 );
writeln( "toe1: ", toe1 );

atomicOp!"-="( toe2, bullet2 );
writeln( "toe2: ", toe2 );

atomicOp!"-="( toe3, bullet3 );
writeln( "toe3: ", toe3 );
}


( https://issues.dlang.org/show_bug.cgi?id=16651 )

[Issue 16651] New: atomicOp!"-="(ulong, uint) = wrong result/codegen

[via Digitalmars-d-bugs]

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

  Issue ID: 16651
   Summary: atomicOp!"-="(ulong, uint) = wrong result/codegen
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: 2k...@gmx.net

wrong result/codegen for atomicOp!"-="(ulong, uint) using DMD -m64. tested on
win64 only, using DMD-2.071.2. problem does not occur with DMD -m32 or
ldc2-1.1.0-b3 -m64.

-

version(DigitalMars)version(D_LP64){
import std.stdio: writeln;
import core.atomic: atomicOp;

shared ulong foo = 2;
uint bar = 1;
atomicOp!"-="( foo, bar );
writeln( "foo = ", foo );// foo = 4294967297
}

--

Re: What is the right level of abstractions for D?

[Laeeth Isharc via Digitalmars-d]

Those categories - I am not sure how well they fit.

When I learnt to program, C was considered a high level language, 
 and now Swift is considered low level.  The world has changed a 
little, but that isn't my main point.


To grow in a healthy way, D doesn't need to think in terms of 
dominating the world in its totality in a single bound.  All that 
is necessary is to appeal to people around the world in different 
lines of work who are unhappy with what they have now and are 
searching for something better,  or who know about D but where 
there is some kind of barrier to adopting it (barriers are not 
impossible to overcome).


It's a big world,  and the work of Polanyi and Hayek should 
remind us that its very difficult to know where users will come 
from,  because that requires a knowledge of time and place that 
we don't have.   But at this size in relation to the total pool 
of programmers to grow,  and Walter's point about listening to 
your current customers who wish to become bigger ones is a good 
one.


Implicitly in what you wrote is the idea that low level 
programmers are the ones with real ability,  and people who write 
in Python might be productive,  but are of a different level of 
overall ability.


Once that kind of high level / low level mapping to ability might 
have made sense,  but if it's still useful,  I think it's much 
less applicable now.   There are plenty of mediocre embedded 
device programmers,  and plenty of people who used to write in C 
and now write in Python.   (I am sure ESR still writes in C, but 
he write about his love for python some time back).


And to call python a scripting language is misleading terminology 
- conventionally so,  but still  true - for example,  AHL,  the 
large quant money management firm,  wrote their risk management 
systems entirely in Python. You may be an enthusiast of Fisher 
Black's Noise paper and think that people in money management are 
fooling themselves,  and I am sympathetic to some of that,  but 
my impression is that technically this firm is decent.


And everything gets more mixed up when you can compile a Ruby 
dialect and have it appear at the top of the performance tables.  
 It was a scripting language before,  and now it's not?  (it's 
control and level of abstraction rather than performance that 
distinguishes level of a language,  but in the past these things 
went together).


It seems to me you are reifying your class structure of languages 
when I am not sure it is a good representation of how things are.


The reason scripting applications don't use D if it's not already 
used for other things is libraries and polish.   D has great 
python interoperability and also a nice package manager.   Well,  
try compiling a program as a python library depending on vibed 
using dub.   It won't go very well because the fPIC isn't 
propagated and you might need to compile in a little C code got 
the constructors.   And what needs to be done isn't completely 
documented anywhere. So at this point,  it's a less appealing 
proposition because for the people that currently use D,  these 
things don't bother them as much and because it's still a small 
community with a lot of work to do. John Colvin is working on it, 
 and maybe it will be fixed soon - because it did bother me.


But this isn't a consequence of the Platonic essence of D as a 
language.   It's merely contingent on the particular stage of 
development and it couldn't have been otherwise because you have 
to get the foundation right before putting sugar on top.


The experience of social learning is that every person that 
follows a course somewhat mysteriously makes it easier for those 
that follow.   It's not only mysterious,  because the signposts 
and guides get better too.   D is not an easy language to learn,  
but even today it's far from exceptionally difficult,  and it 
will get easier with time.


If you want a C and C++ ABI,  want to have control over memory 
and to go down to a low level if you need it,  but are someone in 
a position where you need to get stuff done,  and don't think 
modern C++ is the answer,  what choices do you have?  Not all 
that many.


And I have thought for a while that people were recklessly 
squandering performance and memory usage.   That's not good 
craftsmanship - it might be necessary to make compromises in a 
practical situation, but it's hardly something to be proud of,  
as people almost seem to be.   What Knuth said in his paper and 
speech is not what people take his words out of context to mean,  
and on the other hand look at the everyday experience of using 
applications written by people who follow this philosophy to see 
that there must be something wrong with it.


A language really takes off not because of something it started 
doing that it didn't before,  and all of a sudden everything is a 
success.   It takes off when you have the seeds of something,  
and external conditions change to the point that 

Re: strange -fPIC compilation error

[Charles Hixson via Digitalmars-d-learn]

On 10/30/2016 04:03 PM, Lodovico Giaretta via Digitalmars-d-learn wrote:

On Sunday, 30 October 2016 at 18:02:28 UTC, Charles Hixson wrote:

 dmd --version
DMD64 D Compiler v2.071.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
on debian testing.

dub is installed via apt-get.

Should I revert to an earlier version?  Or what?

The program:


importstd.stdio;

voidmain()
{//int[]t1;

//t1~=1;
//t1~=2;
//writeln ("t1 = ", t1);
}

fails with the 442 lines of error:

/usr/bin/ld: test.o: relocation R_X86_64_32 against symbol 
`__dmd_personality_v0' can not be used when making a shared object; 
recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_224_3b4.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_227_4a2.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_229_5cc.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_626_47b.o): relocation 
R_X86_64_32 against symbol `_D6object9Throwable7__ClassZ' can not be 
used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_628_776.o): relocation 
R_X86_64_32 against symbol `__dmd_personality_v0' can not be used 
when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(dwarfeh_62b_6b9.o): relocation 
R_X86_64_32 against symbol `__dmd_personality_v0' can not be used 
when making a shared object; recompile with -fPIC

...

/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(aaA_51a_53e.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not 
be used when making a shared object; recompile with -fPIC

/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
--- errorlevel 1


Are you on Ubuntu 16.10, or some other system with an hardened 
toolchain? If that's the case, you should compile with `-fPIC 
-defaultlib=libphobos2.so`. You can put those options in your dmd.conf 
configuration file, so that you don't have to type them every time.


Well, I'm using debian, but I've never had to do anything of that nature 
before.  OTOH, it's been a couple of months if this is a new change.

Re: Parse a String given some delimiters

[sarn via Digitalmars-d-learn]

On Sunday, 30 October 2016 at 20:50:47 UTC, Alfred Newman wrote:

Hello,

I'm migrating some Python code to D, but I stuck at a dead 
end...


Sorry to provide some .py lines over here, but I got some 
doubts about the best (fastest) way to do that in D.


The "splitter" generic function sounds like what you want.  The 
basic versions use a fixed separator, but you can make more 
complex separators using either the regex version, or the 
function version.  The function version is simplest for what 
you're doing.  Check out the first example here:

https://dlang.org/phobos/std_algorithm_iteration.html#.splitter.3

(You'd use "among" instead of plain ==)

Also check out "walkLength" for getting the number of tokens.

However, if you really care about speed, I suggest changing the 
API.  With your API, if you want to get multiple tokens from a 
string, you have to split the string every single time.  Why not 
just return the full range?  You can use "array" to return a 
proper array instead of an ad hoc range struct.

[Issue 16628] Special case std.algorithm.equal for known empty or infinite ranges

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/2a45a145e8d29bf0f4a12c8fc8296041e475ea60
Fix Issue 16628 - std.algorithm.equal for known empty or infinite ranges

* If one of the ranges has `Range.empty == true`, we can define `equal`
  even when each `front` is not comparable.
* If one range is infinite and the other defines `length`, return false.
* If both are infinite, cause a compile-time error.

https://github.com/dlang/phobos/commit/31dad0c099f33b5c584d24ed739e8e5785b71426
Merge pull request #4871 from ntrel/equal-empty-enum

Fix Issue 16628 - std.algorithm.equal for known empty or infinite ranges

--

Re: Parse a String given some delimiters

[Lodovico Giaretta via Digitalmars-d-learn]

On Sunday, 30 October 2016 at 20:50:47 UTC, Alfred Newman wrote:

Hello,

I'm migrating some Python code to D, but I stuck at a dead 
end...


Sorry to provide some .py lines over here, but I got some 
doubts about the best (fastest) way to do that in D.


Executing the function parsertoken("_My   input.string", " 
_,.", 2) will result "input".

Parsercount("Dlang=-rocks!", " =-") will result 2,

Thanks in advance


You can take inspiration from the following snippet:

=
import std.stdio, std.regex;

void main()
{
string s = "Hello.World !";
auto ss = split(s, regex(`\.| `));
ss.length.writeln;
ss[1].writeln;
}
=

[Issue 16628] Special case std.algorithm.equal for known empty or infinite ranges

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: strange -fPIC compilation error

[Lodovico Giaretta via Digitalmars-d-learn]

On Sunday, 30 October 2016 at 18:02:28 UTC, Charles Hixson wrote:

 dmd --version
DMD64 D Compiler v2.071.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
on debian testing.

dub is installed via apt-get.

Should I revert to an earlier version?  Or what?

The program:


importstd.stdio;

voidmain()
{//int[]t1;

//t1~=1;
//t1~=2;
//writeln ("t1 = ", t1);
}

fails with the 442 lines of error:

/usr/bin/ld: test.o: relocation R_X86_64_32 against symbol 
`__dmd_personality_v0' can not be used when making a shared 
object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_224_3b4.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' 
can not be used when making a shared object; recompile with 
-fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_227_4a2.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' 
can not be used when making a shared object; recompile with 
-fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_229_5cc.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' 
can not be used when making a shared object; recompile with 
-fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_626_47b.o): 
relocation R_X86_64_32 against symbol 
`_D6object9Throwable7__ClassZ' can not be used when making a 
shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_628_776.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' 
can not be used when making a shared object; recompile with 
-fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(dwarfeh_62b_6b9.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' 
can not be used when making a shared object; recompile with 
-fPIC

...

/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(aaA_51a_53e.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' 
can not be used when making a shared object; recompile with 
-fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on 
output

collect2: error: ld returned 1 exit status
--- errorlevel 1


Are you on Ubuntu 16.10, or some other system with an hardened 
toolchain? If that's the case, you should compile with `-fPIC 
-defaultlib=libphobos2.so`. You can put those options in your 
dmd.conf configuration file, so that you don't have to type them 
every time.

[Issue 16629] [Reg 2.072] scope is stripped from some parameters

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/7888921913009becd68bd70195a073b4e051f17d
changelog entry for ignored scope on value params

- see https://github.com/dlang/dmd/pull/5897
- fixes Issue 16629

--

[Issue 16629] [Reg 2.072] scope is stripped from some parameters

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Sunday, 30 October 2016 at 21:09:19 UTC, Stefan Koch wrote:

On Sunday, 30 October 2016 at 03:07:13 UTC, Stefan Koch wrote:

I just made progress on another fundamental feature,
function call support.

It's does not [fully] work yet, but it shows promise.


The following just compiled :
int fn(int a)
{
return a + fn2(2);
}


int fn2(int a)
{
return a + 2;
}

static assert(fn2(4) == 6);
static assert(fn(4) == 8);
static assert(fn(fn(2)) == 10);


Oh shoot!
I did not enable the new call system :(
This computed by the old interpreter.

The new engine fails :(

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Sunday, 30 October 2016 at 03:07:13 UTC, Stefan Koch wrote:

I just made progress on another fundamental feature,
function call support.

It's does not [fully] work yet, but it shows promise.


The following just compiled :
int fn(int a)
{
return a + fn2(2);
}


int fn2(int a)
{
return a + 2;
}

static assert(fn2(4) == 6);
static assert(fn(4) == 8);
static assert(fn(fn(2)) == 10);

Parse a String given some delimiters

[Alfred Newman via Digitalmars-d-learn]

Hello,

I'm migrating some Python code to D, but I stuck at a dead end...

Sorry to provide some .py lines over here, but I got some doubts 
about the best (fastest) way to do that in D.


Executing the function parsertoken("_My   input.string", " _,.", 
2) will result "input".

Parsercount("Dlang=-rocks!", " =-") will result 2,

def parsertoken(istring, idelimiters, iposition):
"""
Return a specific token of a given input string,
considering its position and the provided delimiters

:param istring: raw input string
:param idelimiteres: delimiters to split the tokens
:param iposition: position of the token
:return: token
"""
	vlist=''.join([s if s not in idelimiters else ' ' for s in 
istring]).split()

return vlist[vposition]

def parsercount(istring, idelimiters):
"""
Return the number of tokens at the input string
considering the delimiters provided

:param istring: raw input string
:param idelimiteres: delimiters to split the tokens
:return: a list with all the tokens found
"""
	vlist=''.join([s if s not in vdelimiters else ' ' for s in 
istring]).split()

return len(vlist)-1


Thanks in advance

Re: Construct D Arrray with explicit capacity

[Nordlöw via Digitalmars-d-learn]

On Sunday, 30 October 2016 at 18:26:54 UTC, arturg wrote:
you cant mutate capacity directly because its only a getter but 
you could use arr.reserve(someVal);


Thx!

[Issue 8087] Improve clarity of std.algorithm documentation

[via Digitalmars-d-bugs]

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

--- Comment #6 from Alexandru Razvan Caciulescu  
---
https://github.com/dlang/phobos/pull/4883

Regarding (1), since this bug was created the file hierarchy seems to have
changed. I updated the files from std/algorithm as explained in the original
post. Awaiting feedback.

--

[Issue 8087] Improve clarity of std.algorithm documentation

[via Digitalmars-d-bugs]

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

--- Comment #5 from Alexandru Razvan Caciulescu  
---
https://github.com/dlang/phobos/pull/4883

Regarding (1), since this bug was created the file hierarchy seems to have
changed. I updated the files from std/algorithm as explained in the original
post. Awaiting feedback.

--

Re: Construct D Arrray with explicit capacity

[arturg via Digitalmars-d-learn]

On Sunday, 30 October 2016 at 18:10:09 UTC, Nordlöw wrote:
Is there a recommended way to create a builtin D array with a 
given capacity?


I'm aware of the `.capacity` property.

Is it ok to mutate it?


you cant mutate capacity directly because its only a getter but 
you could use arr.reserve(someVal);

Re: Construct D Arrray with explicit capacity

[Nordlöw via Digitalmars-d-learn]

On Sunday, 30 October 2016 at 18:10:09 UTC, Nordlöw wrote:

Is it ok to mutate it?


I just checked. It is not.

Construct D Arrray with explicit capacity

[Nordlöw via Digitalmars-d-learn]

Is there a recommended way to create a builtin D array with a 
given capacity?


I'm aware of the `.capacity` property.

Is it ok to mutate it?

strange -fPIC compilation error

[Charles Hixson via Digitalmars-d-learn]

 dmd --version
DMD64 D Compiler v2.071.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
on debian testing.

dub is installed via apt-get.

Should I revert to an earlier version?  Or what?

The program:


importstd.stdio;

voidmain()
{//int[]t1;

//t1~=1;
//t1~=2;
//writeln ("t1 = ", t1);
}

fails with the 442 lines of error:

/usr/bin/ld: test.o: relocation R_X86_64_32 against symbol 
`__dmd_personality_v0' can not be used when making a shared object; 
recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_224_3b4.o): relocation 
R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when 
making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_227_4a2.o): relocation 
R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when 
making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_229_5cc.o): relocation 
R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when 
making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_626_47b.o): 
relocation R_X86_64_32 against symbol `_D6object9Throwable7__ClassZ' can 
not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(dmain2_628_776.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be 
used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(dwarfeh_62b_6b9.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be 
used when making a shared object; recompile with -fPIC

...

/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(aaA_51a_53e.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be 
used when making a shared object; recompile with -fPIC

/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
--- errorlevel 1

Re: State of issues.dlang.org

[Marco Leise via Digitalmars-d]

Am Sat, 29 Oct 2016 17:12:54 +
schrieb Jacob :

> That doesn't make the point any less valid. If something is broke 
> you fix it or replace it.

I agree with Vladimir and cannot really understand your urge
to completely replace it. As long as people don't abuse their
editing abilities it can be fine to make a title more
specific, add a tag and so on. And the custom views help in
getting the desired information out of it. It is extremely
flexible in that aspect; more than I would expect from a much
more modern and younger project.

-- 
Marco

Re: Linus' idea of "good taste" code

[Laeeth Isharc via Digitalmars-d]

On Sunday, 30 October 2016 at 05:30:04 UTC, Dicebot wrote:
On Saturday, 29 October 2016 at 21:46:37 UTC, Laeeth Isharc 
wrote:

Any thoughts on how much work is involved to port the runtime?
 And what other changes might be involved? The chap that used 
the C backend for LLVM wrote a little mini runtime but I guess 
didn't have to worry about the version blocks in the compiler 
front end as much.   (don't recall what architecture he 
pretended to be compiling to).


Glibc has obviously already been ported to run in browser by 
emscripten.


I have actually meant something quite different - implementing 
new backend for DMD which emits wasm directly (possibly by 
embedding binaryen). That is more work than simply using LLVM 
stack as-is but would result in unique marketing advantage - 
existing pipeline of C -> Emscripten -> asm.js -> asm2wasm is 
rather annoying. And native wasm backend for LLVM is in 
development for quite a while now with no clear ETA.


At the same time intended wasm spec 
(https://github.com/WebAssembly/design) is much more simple 
than machine code for something like x86_64. If Walter gets 
interested, that may be a feasible path :)


Existing pipeline is string together with gaffer tape and string, 
 so it's hardly there yet - and add up that,  last I looked,  
when you turned on O2 with emscripten it didn't always go well.


But what I meant was LLVM will have a wasm backend.   So on basis 
of my limited understanding,  it would be some work to make LDC 
produce wasm code,  and then runtime and phobos would need work.  
 Adam Ruppe of course had something like this working with plain 
javascript and dmd about four years back, including basic D 
wrapping of DOM etc and extern(js).  But compiler has diverged a 
bit from that version used,  and I guess at time there wasn't the 
interest or manpower to turn that experiment /prototype into 
something one could depend on.   But maybe someone would pick it 
up now more people start to be involved,  given that Walter has 
higher priority things to do.


And wouldn't the changes to runtime and phobos be quite similar 
for both dmd and ldc? I don't see how the work flow would be any 
different as a language user whether you used an LDC with wasm 
back end,  or dmd with similar.


Joakim - native on mobile is so much better (setting aside having 
to deal with Apple or Google)   but I guess the browser isn't 
going away on the desktop for a while yet.

Re: test for equality of the content of two AA

[Paolo Invernizzi via Digitalmars-d-learn]

On Wednesday, 26 October 2016 at 19:03:45 UTC, Ali Çehreli wrote:

On 10/26/2016 08:03 AM, Paolo Invernizzi wrote:

[...]


If you mean D's AAs, then that is already implemented:

  void main() {
auto a = [ "hello" : 1, "world" : 2 ];
auto b = [ "world" : 2, "hello" : 1 ];
assert(a == b);
}

[...]


Thank you Ali, very exhaustive!

Re: Having trouble compiling D on Ubuntu 16.10

[Dechcaudron via Digitalmars-d]

On Sunday, 30 October 2016 at 11:40:01 UTC, Mike Parker wrote:

On Sunday, 30 October 2016 at 11:25:30 UTC, Dechcaudron wrote:




Anybody has any idea why this is happening? Is the only 
solution to downgrade to Ubuntu 16.04 to be able to work in 
the meantime?


Thanks beforehand :)


Try adding `-fPIC -defaultlib=libphobos2.so` to your dmd.conf. 
And see the following links:


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

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


Thanks Mike, changing dmd.config did the trick. I'll learn the 
details from the discussion you linked.

Re: Having trouble compiling D on Ubuntu 16.10

[Mike Parker via Digitalmars-d]

On Sunday, 30 October 2016 at 11:25:30 UTC, Dechcaudron wrote:




Anybody has any idea why this is happening? Is the only 
solution to downgrade to Ubuntu 16.04 to be able to work in the 
meantime?


Thanks beforehand :)


Try adding `-fPIC -defaultlib=libphobos2.so` to your dmd.conf. 
And see the following links:


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

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

Having trouble compiling D on Ubuntu 16.10

[Dechcaudron via Digitalmars-d]

Hey there community,

some weeks ago I upgraded from 16.04 to 16.10, but it wasn't 
until now that I realized I can't develop with D anymore due to 
an error in the linking stage of the compilation process. dmd 
seems to be doing its job just fine, compiling with the -c flag 
does not produce any warnings or errors that should not be there. 
But when I move on to the linking stage with the instruction that 
dmd uses itself:


cc app.o -o app -m64 -L/usr/lib/x86_64-linux-gnu -Xlinker 
--export-dynamic -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic 
-lpthread -lm -lrt -ldl


I get a neverending ocean of errors that look pretty much all 
like these:


/usr/bin/ld: app.o: relocation R_X86_64_32 against symbol 
`__dmd_personality_v0' can not be used when making a shared 
object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_24b_55a.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can 
not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_24c_3b4.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can 
not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/libphobos2.a(exception_24f_4a2.o): 
relocation R_X86_64_32 against symbol `__dmd_personality_v0' can 
not be used when making a shared object; recompile with -fPIC


Anybody has any idea why this is happening? Is the only solution 
to downgrade to Ubuntu 16.04 to be able to work in the meantime?


Thanks beforehand :)

[Issue 16650] Wrong mangling for extern(C++) with posix stat_t

[via Digitalmars-d-bugs]

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

Jacob Carlborg  changed:

   What|Removed |Added

 CC||d...@me.com

--- Comment #1 from Jacob Carlborg  ---
I don't think it's the mangling that is wrong. Rather it's the declaration of
the struct. Not sure why it's called "stat_t" in the D version when it's called
"stat" in the C headers.

--

Re: Linus' idea of "good taste" code

[Patrick Schluter via Digitalmars-d]

On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote:


It is not worth it, the web is dying.  I was stunned to see 
this chart of mobile web usage in the US:


https://mobile.twitter.com/asymco/status/777915894659964928

This isn't some third-world country with mostly 2G usage, the 
web numbers in those places are much worse. Combined with 
mobile passing even TV for time spent, there is no point in 
wasting time porting D to a dying platform.


Yes, because outside of web on mobile nothing else exists... 
bwahahahah

[Issue 14613] DMD: Internal error: backend/cod1.c 1567 on '-O' switch

[via Digitalmars-d-bugs]

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

--- Comment #4 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6218

--

Re: Linus' idea of "good taste" code

[Joakim via Digitalmars-d]

On Sunday, 30 October 2016 at 05:53:09 UTC, Walter Bright wrote:

On 10/29/2016 10:30 PM, Dicebot wrote:
At the same time intended wasm spec 
(https://github.com/WebAssembly/design) is
much more simple than machine code for something like x86_64. 
If Walter gets

interested, that may be a feasible path :)


I looked at it for 5 minutes :-) and it looks like typical 
intermediate code that a compiler might generate. It wouldn't 
be hard to translate the intermediate code generated for the 
dmd back end to wasm. What I didn't see was any mention 
symbolic debug information, linking, or how to connect to 
system services like mutexes, I/O, etc. Time risks would also 
be wasm is an incomplete, moving target.


Looks like a fun project, but I don't see how I could split off 
time to work on it.


It is not worth it, the web is dying.  I was stunned to see this 
chart of mobile web usage in the US:


https://mobile.twitter.com/asymco/status/777915894659964928

This isn't some third-world country with mostly 2G usage, the web 
numbers in those places are much worse. Combined with mobile 
passing even TV for time spent, there is no point in wasting time 
porting D to a dying platform.