Re: general questions about static this() at module level
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
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 :)
Re: strange -fPIC compilation error
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
Re: Parse a String given some delimiters
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
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
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
splitter trouble
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
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
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: strange -fPIC compilation error
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
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.
Re: Parse a String given some delimiters
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;
}
=
Re: strange -fPIC compilation error
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.
Parse a String given some delimiters
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
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!
Re: Construct D Arrray with explicit capacity
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
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
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
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: test for equality of the content of two AA
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!
