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 :)
Got a post for the D Blog?
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
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.
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)
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
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
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
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
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
Re: Fun: Shooting yourself in the foot in 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
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: Fun: Shooting yourself in the foot in 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
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?
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
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.
[Issue 16628] Special case std.algorithm.equal for known empty or infinite ranges
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
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
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
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
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
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
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
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
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!
[Issue 8087] Improve clarity of std.algorithm documentation
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
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
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: State of issues.dlang.org
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
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
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
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
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
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
https://issues.dlang.org/show_bug.cgi?id=16650 Jacob Carlborgchanged: 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
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
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
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.