gdc-6.3.0 on travis borked?
When using gdc-6.3.0 on travis-ci, travis is reporting that it can't download the compiler: -- $ source "$(CURL_USER_AGENT="$CURL_USER_AGENT" bash install.sh gdc-6.3.0 --activate)" curl: (22) The requested URL returned error: 404 Not Found curl: (22) The requested URL returned error: 404 Not Found curl: (22) The requested URL returned error: 404 Not Found curl: (22) The requested URL returned error: 404 Not Found curl: (22) The requested URL returned error: 404 Not Found Failed to download 'http://gdcproject.org/downloads/binaries/x86_64-linux-gnu/gdc-6.3.0.tar.xz' /home/travis/.travis/job_stages: line 57: : No such file or directory The command "source "$(CURL_USER_AGENT="$CURL_USER_AGENT" bash install.sh gdc-6.3.0 --activate)"" failed and exited with 1 during . -- Anyone know anything about this? Where (and to whom) should this be reported?
Re: Template specialisation, "Generic type locking", offline stdlib docs and case-based template question
On Friday, December 01, 2017 03:39:12 helxi via Digitalmars-d-learn wrote:
> 1. Template specialisation.
> Why is this useful?:
> T getResponse(T = int)(string question); And how does it differ
> from
> int getResponse(string question); ?
>
> Context: http://ddili.org/ders/d.en/templates.html : Section:
> "Default template parameters"
I would point out that that isn't template specialization at all. Template
specialization uses : not =, and would look like
T getResponse(T : int)(string question) {...}
and is a different beast entirely. As the section you're referring to
mentions, what you have there is a default template parameter, which is
useful in cases where you want to be able to have the flexibility of a
template parameter but not require it in the common case. One prime example
is std.algorithm's find function. You can pass it a predicate that it will
use for comparing elements in the range, but by default it uses equality.
- Jonathan M Davis
Re: Template specialisation, "Generic type locking", offline stdlib docs and case-based template question
On Friday, 1 December 2017 at 03:39:12 UTC, helxi wrote:
1. Template specialisation.
Why is this useful?:
T getResponse(T = int)(string question); And how does it differ
from
int getResponse(string question); ?
Because you can change the T at the call site. Let me give you a
real world example from my cgi.d
docs:
http://dpldocs.info/experimental-docs/arsd.cgi.Cgi.request.html
source:
https://github.com/adamdruppe/arsd/blob/master/cgi.d#L2057
In the doc example, you'll see:
int a = cgi.request("number", 10);
You can also do:
string name = cgi.request("name");
or something kinda crazy like:
float number = cgi.request!float("brightness");
In the first case, it uses the passed param - 10 - to infer the
type of T you want returned. It sees 10 is an int, so it tries to
convert the value from the URL to an int and return it.
The second case uses the default parameter, described in the link
you gave. The default here is (T = string), so if you don't
specify anything else, it simply returns a string.
The third case shows explicit passing of a new type, instead of
using the default T = string, we get T = float, so the function
converts the value from URL to float and returns that.
All three of these uses are supported by the code.
2. "Generic locking".
Is it possible to specialise templates for a certain group of
types? For example
auto fn(T)(T arg)
auto fn(T : int, double, float, ulong)(T arg); //shares same
behaviour
auto fn(T : char, string, dchar, wchar, dstring, wstring)(T
arg); // shares same behavior
Yeah, that is possible.
class Stack(T)
{
private:
T[] data;
public:
this(T)(T[] data){ /*..*/}
this(T)(){}
//...
}
void main()
{
auto s = new Stack!int;
}
Says:
Error: template app.Stack!int.Stack.__ctor cannot deduce
function from argument types !()(), candidates are:
source/app.d(6,2):app.Stack!int.Stack.__ctor(T)(T[]
data)
source/app.d(9,2):app.Stack!int.Stack.__ctor(T)()
Why is Stack!int a ctor()() instead of a ctor(int)()?
You passed int to the Stack(T) template, but not to the this(T)
template. There's two levels there, the outer argument and the
inner argument.
It is the same as if you did a
void delegate(int) returns_a_function(int);
if you called
returns_a_function(0), it would still return the delegate. If you
want to call both, you need another set of params to pass an
argument to the returned function, too.
Re: Template specialisation, "Generic type locking", offline stdlib docs and case-based template question
On Friday, 1 December 2017 at 03:39:12 UTC, helxi wrote:
1. Template specialisation.
Why is this useful?:
T getResponse(T = int)(string question); And how does it differ
from
int getResponse(string question); ?
Good Q. Without thinking more it looks like a pointless example.
The only difference i see is that the templatized version won't
get compiled unless used.
Context: http://ddili.org/ders/d.en/templates.html : Section:
"Default template parameters"
2. "Generic locking".
Is it possible to specialise templates for a certain group of
types? For example
auto fn(T)(T arg)
auto fn(T : int, double, float, ulong)(T arg); //shares same
behaviour
auto fn(T : char, string, dchar, wchar, dstring, wstring)(T
arg); // shares same behavior
You can use template constraints:
auto fn(T)(T arg)
if (is(T==int) || is(T==double) || is(T==float) || is(T==ulong)){}
auto fn(T)(T arg)
if (is(T==char) || is(T==string) || is(T==dchar) ||
is(T==wchar)){}
3. "Offline docs".
Is there any offline documentation of the stdlib? Like
https://en.cppreference.com/mwiki/index.php?title=Cppreference:Archives=95461
Yes, distributes with each release. look inside the 7z archive.
On linux it's setup
here: /usr/share/dmd/html/d/phobos/
4. Case based question regarding templates:
class Stack(T)
{
private:
T[] data;
public:
this(T)(T[] data){ /*..*/}
this(T)(){}
//...
}
void main()
{
auto s = new Stack!int;
}
Says:
Error: template app.Stack!int.Stack.__ctor cannot deduce
function from argument types !()(), candidates are:
source/app.d(6,2):app.Stack!int.Stack.__ctor(T)(T[]
data)
source/app.d(9,2):app.Stack!int.Stack.__ctor(T)()
Why is Stack!int a ctor()() instead of a ctor(int)()?
You must use another identifier here
class Stack(T)
{
private:
T[] data;
public:
this(TT)(TT[] data){ /*..*/}
this()(){}
//...
}
Template specialisation, "Generic type locking", offline stdlib docs and case-based template question
1. Template specialisation.
Why is this useful?:
T getResponse(T = int)(string question); And how does it differ
from
int getResponse(string question); ?
Context: http://ddili.org/ders/d.en/templates.html : Section:
"Default template parameters"
2. "Generic locking".
Is it possible to specialise templates for a certain group of
types? For example
auto fn(T)(T arg)
auto fn(T : int, double, float, ulong)(T arg); //shares same
behaviour
auto fn(T : char, string, dchar, wchar, dstring, wstring)(T arg);
// shares same behavior
3. "Offline docs".
Is there any offline documentation of the stdlib? Like
https://en.cppreference.com/mwiki/index.php?title=Cppreference:Archives=95461
4. Case based question regarding templates:
class Stack(T)
{
private:
T[] data;
public:
this(T)(T[] data){ /*..*/}
this(T)(){}
//...
}
void main()
{
auto s = new Stack!int;
}
Says:
Error: template app.Stack!int.Stack.__ctor cannot deduce
function from argument types !()(), candidates are:
source/app.d(6,2):app.Stack!int.Stack.__ctor(T)(T[] data)
source/app.d(9,2):app.Stack!int.Stack.__ctor(T)()
Why is Stack!int a ctor()() instead of a ctor(int)()?
Re: associative array: unexpected results after static initialization
Seems like this problem is already known: https://issues.dlang.org/show_bug.cgi?id=15290 Here's the fix: https://github.com/dlang/druntime/pull/1980 --T
Re: associative array: unexpected results after static initialization
On Thu, Nov 30, 2017 at 03:57:37PM -0800, H. S. Teoh via Digitalmars-d-learn wrote: > Hmm, which compiler are you using, and which version? I cannot > reproduce this bug with DMD git head. It may be have fixed since the > release you're using? [...] Sorry, I was testing the wrong code. This problem does still happen on DMD git head. Looking into the code right now... Please still file the bug if you haven't already. T -- "How are you doing?" "Doing what?"
Re: associative array: unexpected results after static initialization
Hmm, which compiler are you using, and which version? I cannot reproduce this bug with DMD git head. It may be have fixed since the release you're using? --T
Re: associative array: unexpected results after static initialization
On Thu, Nov 30, 2017 at 11:50:13PM +, kdevel via Digitalmars-d-learn
wrote:
> This program
>
> ``` void aa_stat(T, U) (T[U] aa) { import std.stdio; writefln ("aa
> : %s", aa); writefln ("aa.length : %d", aa.length); writefln ("aa.keys
> : %s", aa.keys); writefln ("aa.values : %s", aa.values); foreach (k,
> v; aa) writeln (k, ": ", v); }
>
> void main () { string[int] aa = [ 0: "null", 0: "eins" ]; aa.aa_stat;
> } ```
>
> produces this output:
>
>aa: [0:"eins", ] aa.length : 2 aa.keys : [0, 32767]
>aa.values : ["eins", ""] 0: eins
[...]
This looks like a bug in the implementation of AA literals. Please file
a bug at http://issues.dlang.org/.
--T
associative array: unexpected results after static initialization
This program
```
void aa_stat(T, U) (T[U] aa)
{
import std.stdio;
writefln ("aa: %s", aa);
writefln ("aa.length : %d", aa.length);
writefln ("aa.keys : %s", aa.keys);
writefln ("aa.values : %s", aa.values);
foreach (k, v; aa)
writeln (k, ": ", v);
}
void main ()
{
string[int] aa = [
0: "null",
0: "eins"
];
aa.aa_stat;
}
```
produces this output:
aa: [0:"eins", ]
aa.length : 2
aa.keys : [0, 32767]
aa.values : ["eins", ""]
0: eins
I would have expected either a compile time or a runtime error or
this result:
aa: [0:"eins"]
aa.length : 1
aa.keys : [0]
aa.values : ["eins"]
0: eins
What's happening here?
Re: std.algorithm
On Thursday, 30 November 2017 at 21:49:56 UTC, Meta wrote: On Thursday, 30 November 2017 at 20:49:36 UTC, flamencofantasy wrote: [...] This *almost* works: [...] That's what I needed, thanks!
Re: Convert a single element into a range
On Thursday, 30 November 2017 at 22:52:33 UTC, Ali Çehreli wrote:
On 11/30/2017 02:47 PM, A Guy With a Question wrote:
This is probably a dumb question, but what I did looks ugly.
Is there a way (preferably a one liner) to convert a single
element, like an int or char or bool, into a range?
import std.range;
void main() {
auto r = only(42);
static assert(isInputRange!(typeof(r)));
}
Ali
Excellent!
Re: Convert a single element into a range
On 11/30/2017 02:47 PM, A Guy With a Question wrote:
This is probably a dumb question, but what I did looks ugly. Is there a
way (preferably a one liner) to convert a single element, like an int or
char or bool, into a range?
import std.range;
void main() {
auto r = only(42);
static assert(isInputRange!(typeof(r)));
}
Ali
Convert a single element into a range
This is probably a dumb question, but what I did looks ugly. Is there a way (preferably a one liner) to convert a single element, like an int or char or bool, into a range?
Re: std.algorithm
On Thursday, 30 November 2017 at 20:49:36 UTC, flamencofantasy
wrote:
Hello,
I have the following csv text;
auto input = "Start Date,End Date,Subject,All day
event,Categories,Show time as
1/1/2018,1/1/2018,New Year's Day,TRUE,Holiday,3
1/15/2018,1/15/2018,\"Martin Luther King, Jr.
Day\",TRUE,Holiday,3
2/19/2018,2/19/2018,President's Day,TRUE,Holiday,3
5/28/2018,5/28/2018,Memorial Day,TRUE,Holiday,3
7/4/2018,7/4/2018,Independence Day,TRUE,Holiday,3
9/3/2018,9/3/2018,Labor Day,TRUE,Holiday,3
11/22/2018,11/22/2018,Thanksgiving Day,TRUE,Holiday,3
11/23/2018,11/23/2018,Day after Thanksgiving,TRUE,Holiday,3
12/24/2018,12/24/2018,Christmas Eve,TRUE,Holiday,3
12/25/2018,12/25/2018,Christmas Day,TRUE,Holiday,3";
What is the most clean compact efficient/lazy way to produce a
range that removes the first line and then retains the second
and third columns of the following lines, basically producing
this;
"1/1/2018,New Year's Day
1/15/2018,\"Martin Luther King, Jr. Day\"
2/19/2018,President's Day
5/28/2018,Memorial Day
7/4/2018,Independence Day
9/3/2018,Labor Day,TRUE
11/22/2018,Thanksgiving Day
11/23/2018,Day after Thanksgiving
12/24/2018,Christmas Eve
12/25/2018,Christmas Day"
Thanks a bunch
This *almost* works:
import std.algorithm;
import std.range;
import std.stdio;
import std.string;
void main()
{
auto input = "Start Date,End Date,Subject,All day
event,Categories,Show time as
1/1/2018,1/1/2018,New Year's Day,TRUE,Holiday,3
1/15/2018,1/15/2018,\"Martin Luther King, Jr.
Day\",TRUE,Holiday,3
2/19/2018,2/19/2018,President's Day,TRUE,Holiday,3
5/28/2018,5/28/2018,Memorial Day,TRUE,Holiday,3
7/4/2018,7/4/2018,Independence Day,TRUE,Holiday,3
9/3/2018,9/3/2018,Labor Day,TRUE,Holiday,3
11/22/2018,11/22/2018,Thanksgiving
Day,TRUE,Holiday,3
11/23/2018,11/23/2018,Day after
Thanksgiving,TRUE,Holiday,3
12/24/2018,12/24/2018,Christmas Eve,TRUE,Holiday,3
12/25/2018,12/25/2018,Christmas
Day,TRUE,Holiday,3";
input.lineSplitter()
.dropOne()
.map!(l =>
l.splitter(',')
.dropOne()
.take(2)
.joiner(","))
.each!writeln();
}
The only problem is the comma in Martin Luther King, Jr. Day, so
that line comes out as `1/15/2018,"Martin Luther King`.
std.algorithm
Hello, I have the following csv text; auto input = "Start Date,End Date,Subject,All day event,Categories,Show time as 1/1/2018,1/1/2018,New Year's Day,TRUE,Holiday,3 1/15/2018,1/15/2018,\"Martin Luther King, Jr. Day\",TRUE,Holiday,3 2/19/2018,2/19/2018,President's Day,TRUE,Holiday,3 5/28/2018,5/28/2018,Memorial Day,TRUE,Holiday,3 7/4/2018,7/4/2018,Independence Day,TRUE,Holiday,3 9/3/2018,9/3/2018,Labor Day,TRUE,Holiday,3 11/22/2018,11/22/2018,Thanksgiving Day,TRUE,Holiday,3 11/23/2018,11/23/2018,Day after Thanksgiving,TRUE,Holiday,3 12/24/2018,12/24/2018,Christmas Eve,TRUE,Holiday,3 12/25/2018,12/25/2018,Christmas Day,TRUE,Holiday,3"; What is the most clean compact efficient/lazy way to produce a range that removes the first line and then retains the second and third columns of the following lines, basically producing this; "1/1/2018,New Year's Day 1/15/2018,\"Martin Luther King, Jr. Day\" 2/19/2018,President's Day 5/28/2018,Memorial Day 7/4/2018,Independence Day 9/3/2018,Labor Day,TRUE 11/22/2018,Thanksgiving Day 11/23/2018,Day after Thanksgiving 12/24/2018,Christmas Eve 12/25/2018,Christmas Day" Thanks a bunch
Re: std.range.interfaces : InputRange moveFront
On 11/30/2017 07:31 AM, Tony wrote: On Thursday, 30 November 2017 at 09:50:37 UTC, Tony wrote: On Thursday, 30 November 2017 at 09:47:14 UTC, Tony wrote: Thanks for the reply. Probably just missing it, but in poking around dlang.org (Language Reference and Library Reference) I am having trouble finding out about the move(), front() and moveFront() functions, as is used here on a dynamic array. That should just be front() and moveFront() used here. I ran across move() in looking at the standard library for the definitions of the other two. Found a move() here: https://dlang.org/library/std/algorithm/mutation/move.html Function std.algorithm.mutation.move I don't know why it isn't listed at the top of the page but front() for arrays is here: https://dlang.org/phobos/std_range_primitives.html#.front And moveFront(): https://dlang.org/phobos/std_range_primitives.html#.moveFront Ali
Re: Private imports and Objects
On Thursday, 30 November 2017 at 06:44:43 UTC, Jonathan M Davis wrote: Object exists primarily because D didn't originally have templates, and when you don't have templates, having a single base class is the only way to have a function accept any class, and for something like a container, you'd pretty much be forced to use void* without Object if you don't have templates. However, once templates were added to D, the benefits of Object were significantly reduced, and it's arguably not a particularly good idea to be writing code that operates on Object. However, it's far too late in the game to get rid of Object. And they come in very handy when one ports code from Java. As a first approach a simple 1 to 1 adaptation of the code makes the porting so much easier. Templates and D magic can come afterwards.
Re: Private imports and Objects
On Thursday, November 30, 2017 10:54:44 helxi via Digitalmars-d-learn wrote: > On Thursday, 30 November 2017 at 06:44:43 UTC, Jonathan M Davis > > wrote: > > On Thursday, November 30, 2017 06:29:43 helxi via > > > Digitalmars-d-learn wrote: > [] > > > I don't understand the question. You're asking whether casting > > from a base class to a derived class creates overhead? Or are > > you asking whether having a base class for all classes creates > > overhead? Or something else? > > > > Object exists primarily because D didn't originally have > > templates, and when you don't have templates, having a single > > base class is the only way to have a function accept any class, > > and for something like a container, you'd pretty much be forced > > to use void* without Object if you don't have templates. > > However, once templates were added to D, the benefits of Object > > were significantly reduced, and it's arguably not a > > particularly good idea to be writing code that operates on > > Object. However, it's far too late in the game to get rid of > > Object. > > > > At one point, it was decided to remove Object's member > > functions, because having them on Object needlessly locks in a > > particular set of attributes for those functions, and if we did > > that, then there really wouldn't be much reason to use Object > > directly, but that change has never happened, and it's not > > clear that it's going to happen, since there are a number of > > technical issues that make it a bit of a pain to do > > (particularly if we don't want to break a lot of code). One of > > the bigger issues is that the AA implementation in druntime > > needs to be templated so that it doesn't need to operate on > > Object, and that's proven to be a bit of a challenge. > > > > https://issues.dlang.org/show_bug.cgi?id=9769 > > https://issues.dlang.org/show_bug.cgi?id=9770 > > https://issues.dlang.org/show_bug.cgi?id=9771 > > https://issues.dlang.org/show_bug.cgi?id=9772 > > > > - Jonathan M Davis > > I was actually referring to both. Override functions such as > opCmp, opEquals, toString, toHash etc --wouldn't they be > inherently expensive? I thought they are virtual functions. Also, > with regards to casting, wouldn't this be an extra legwork? Both > of these seem to be a performance handicap to me. But I'm no > expert on this matter. Maybe the compiler optimises it away since > normally you'd cast to a constant subclass. Virtual functions do have a cost but not a huge one, and to a point, they're kind of the whole point of classes. If you don't need inheritance, then use a struct. D separates structs and classes so that classes have inheritance and are always reference types (like in Java), whereas structs don't have inheritance. Classes in D cost about what they would cost in C++ or Java. Unlike C++, they do have an invisible monitor member to enable synchronized to work, and public member functions are virtual by default, but in general, calling a function on a class in D costs what it would to call a virtual function in C++ - and if you don't need virtual functions, then why use a class? You can mark individual member functions as final to devirtualize them (assuming that they're not overriding a base class member), but if you don't need any virtual functions, then you don't need inheritance, and you don't need a class. As for casting, I don't know what the concern is. You typically construct a class object and then either reference it through a class reference of its actual type or through a class reference of a base type, just like you would in C++, Java, C#, etc. You don't typically need explicit casting, and implicit casting is only going to happen if you assign the object to another reference of a base type of the current reference. Casting class objects shouldn't be any more expensive in D than it is in other languages. Having Object exist doesn't really affect much of any of this. It just provides a common base class. The functions that are on it don't need to be there, and if we were doing things from scratch, they certainly wouldn't be, but it doesn't make functions or casting more expensive. Any extra cost that's there is inherent to inheritance in general, and that's the whole reason that classes exist. - Jonathan M Davis
Re: Instructions to build DMD from source don't work (anymore) here
On 2017-11-30 12:19, Basile B. wrote: That's strange because as said i had g++ / c++ but DMD compiles only once gcc-c++ setup. Anyway, working now. It should be possible to get which package the "g++" file belongs to [1]. [1] https://unix.stackexchange.com/questions/4705/how-to-find-out-which-package-a-file-belongs-to -- /Jacob Carlborg
Re: std.range.interfaces : InputRange moveFront
On Thursday, 30 November 2017 at 09:50:37 UTC, Tony wrote: On Thursday, 30 November 2017 at 09:47:14 UTC, Tony wrote: Thanks for the reply. Probably just missing it, but in poking around dlang.org (Language Reference and Library Reference) I am having trouble finding out about the move(), front() and moveFront() functions, as is used here on a dynamic array. That should just be front() and moveFront() used here. I ran across move() in looking at the standard library for the definitions of the other two. Found a move() here: https://dlang.org/library/std/algorithm/mutation/move.html Function std.algorithm.mutation.move
Re: Instructions to build DMD from source don't work (anymore) here
On Thursday, 30 November 2017 at 10:47:57 UTC, Jacob Carlborg wrote: On 2017-11-30 09:56, Basile B. wrote: On Thursday, 30 November 2017 at 08:38:15 UTC, Basile B. wrote: [...] All required tools are setup. I do not set AUTOBOOTSTRAP=1 since dmd 2.077 is setup. I needed gcc-c++... I don't know why but since "which g++" gave a valid file name i thought it was enough. What's the difference ? I don't know how Fedora works but you need a C++ compiler [1]. It seems like "gcc-c++" is the name of the "g++" package in Fedora. [1] https://stackoverflow.com/questions/12952913/how-do-i-install-g-for-fedora That's strange because as said i had g++ / c++ but DMD compiles only once gcc-c++ setup. Anyway, working now.
Re: Private imports and Objects
On Thursday, 30 November 2017 at 06:44:43 UTC, Jonathan M Davis wrote: On Thursday, November 30, 2017 06:29:43 helxi via Digitalmars-d-learn wrote: [] I don't understand the question. You're asking whether casting from a base class to a derived class creates overhead? Or are you asking whether having a base class for all classes creates overhead? Or something else? Object exists primarily because D didn't originally have templates, and when you don't have templates, having a single base class is the only way to have a function accept any class, and for something like a container, you'd pretty much be forced to use void* without Object if you don't have templates. However, once templates were added to D, the benefits of Object were significantly reduced, and it's arguably not a particularly good idea to be writing code that operates on Object. However, it's far too late in the game to get rid of Object. At one point, it was decided to remove Object's member functions, because having them on Object needlessly locks in a particular set of attributes for those functions, and if we did that, then there really wouldn't be much reason to use Object directly, but that change has never happened, and it's not clear that it's going to happen, since there are a number of technical issues that make it a bit of a pain to do (particularly if we don't want to break a lot of code). One of the bigger issues is that the AA implementation in druntime needs to be templated so that it doesn't need to operate on Object, and that's proven to be a bit of a challenge. https://issues.dlang.org/show_bug.cgi?id=9769 https://issues.dlang.org/show_bug.cgi?id=9770 https://issues.dlang.org/show_bug.cgi?id=9771 https://issues.dlang.org/show_bug.cgi?id=9772 - Jonathan M Davis I was actually referring to both. Override functions such as opCmp, opEquals, toString, toHash etc --wouldn't they be inherently expensive? I thought they are virtual functions. Also, with regards to casting, wouldn't this be an extra legwork? Both of these seem to be a performance handicap to me. But I'm no expert on this matter. Maybe the compiler optimises it away since normally you'd cast to a constant subclass.
Re: Instructions to build DMD from source don't work (anymore) here
On 2017-11-30 09:56, Basile B. wrote: On Thursday, 30 November 2017 at 08:38:15 UTC, Basile B. wrote: [...] All required tools are setup. I do not set AUTOBOOTSTRAP=1 since dmd 2.077 is setup. I needed gcc-c++... I don't know why but since "which g++" gave a valid file name i thought it was enough. What's the difference ? I don't know how Fedora works but you need a C++ compiler [1]. It seems like "gcc-c++" is the name of the "g++" package in Fedora. [1] https://stackoverflow.com/questions/12952913/how-do-i-install-g-for-fedora -- /Jacob Carlborg
Re: Shared and race conditions
On 2017-11-29 17:13, Wanderer wrote: I'm trying to simulate a race condition in D with the following code: I'm not sure what your end goal is but perhaps you could try to see if the LLVM thread sanitizer [1] can be used with LDC. The thread sanitizer can identify race conditions even though they're not actually triggered [2]. It can be quite difficult to simulate a race condition because x86 has an almost strong memory model. [1] https://clang.llvm.org/docs/ThreadSanitizer.html [2] https://developer.apple.com/videos/play/wwdc2016/412/ 16:00 -- /Jacob Carlborg
Re: Problems with ctRegex
On Tuesday, 28 November 2017 at 19:12:29 UTC, crimaniak wrote: First problem: it doesn't understand enums, it seems to be a bug: or just "to!string(TopicMask.publishMask)" would have worked too. [...] Is there any change to use regex inside or pure function? I just need some pure bool test() method to test string against the mask. I don't think so, the factory system has static mutable data, lazily initialized, so purity seems impossible. If you put "pure" everywhere in the call chain you will land here: https://github.com/dlang/phobos/blob/ad489989ec3fac9f65f4bb9d43d2254a0b718dc7/std/regex/internal/ir.d#L521-L522
Re: std.range.interfaces : InputRange moveFront
On Thursday, 30 November 2017 at 09:47:14 UTC, Tony wrote: Thanks for the reply. Probably just missing it, but in poking around dlang.org (Language Reference and Library Reference) I am having trouble finding out about the move(), front() and moveFront() functions, as is used here on a dynamic array. That should just be front() and moveFront() used here. I ran across move() in looking at the standard library for the definitions of the other two.
Re: std.range.interfaces : InputRange moveFront
On Thursday, 30 November 2017 at 06:36:12 UTC, Ali Çehreli wrote:
move is an operation that transfers the state of the source to
the destination. The front element becomes its .init value and
its previous values is returned by moveFront().
The important bit is that, the element is *not* copied:
import std.range;
struct S {
int i;
bool is_a_copy = false;
this(this) {
is_a_copy = true;
}
}
void main() {
auto r = [S(1)];
auto a = r.front;
assert(a.is_a_copy); // yes, a is a copy
assert(a.i == 1); // as expected, 1
assert(r.front.i == 1);// front is still 1
auto b = r.moveFront();
assert(!b.is_a_copy); // no, b is not a copy
assert(b.i == 1); // state is transferred
assert(r.front.i == 0);// front is int.init
}
Thanks for the reply. Probably just missing it, but in poking
around dlang.org (Language Reference and Library Reference) I am
having trouble finding out about the move(), front() and
moveFront() functions, as is used here on a dynamic array.
Re: Instructions to build DMD from source don't work (anymore) here
On Thursday, 30 November 2017 at 08:38:15 UTC, Basile B. wrote: [...] All required tools are setup. I do not set AUTOBOOTSTRAP=1 since dmd 2.077 is setup. I needed gcc-c++... I don't know why but since "which g++" gave a valid file name i thought it was enough. What's the difference ?
Instructions to build DMD from source don't work (anymore) here
Hi, I've recently switched from a linux distribution to another (F27). During the last 2 years i used a script to build DMD, unfortunately i forgot to include it in my backup. Initially i thought "No problem, there's the instructions in the wiki, it's more or less about calling make with a couple of option". In theory only... make -fposix.mak gives me [basile@pc1 dmd]$ make -f posix.mak make -C src -f posix.mak make[1] : on entre dans le répertoire « /home/basile/dev/repos/dlang/dmd/src » no cpu specified, assuming X86 (CC) ROOT_OBJS ddmd/root/newdelete.c c++ -c -o../generated/linux/release/64/newdelete.o -Wno-deprecated -Wstrict- aliasing -fno-exceptions -fno-rtti -D__pascal= -DMARS=1 -DTARGET_LINUX=1 - DDM_TARGET_CPU_X86=1 -m64 -fPIC -std=gnu++98 -Iddmd/root -MMD -MF ../generated/linux/release/64/newdelete.deps ddmd/root/newdelete.c cc1plus: désolé, pas implémenté: mode 64 bits pas compilé make[1]: *** [posix.mak:568: ../generated/linux/release/64/newdelete.o] Error 1 make[1] : on quitte le répertoire « /home/basile/dev/repos/dlang/dmd/src » make: *** [posix.mak:8: all] Error 2 All required tools are setup. I do not set AUTOBOOTSTRAP=1 since dmd 2.077 is setup.
