[Issue 22599] Infinite loop using join with alias this and non-ascii unicode

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P3

--

[Issue 22599] Infinite loop using join with alias this and non-ascii unicode

[d-bugmail--- via Digitalmars-d-bugs]

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

yazan.dab...@gmail.com changed:

   What|Removed |Added

Summary|Infinite loop using join|Infinite loop using join
   |with alias this |with alias this and
   ||non-ascii unicode

--

[Issue 22599] New: Infinite loop using join with alias this

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 22599
   Summary: Infinite loop using join with alias this
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: yazan.dab...@gmail.com

Running the code below results in an infinite loop.
Removing alias this, the map call or using ascii makes the code run as
expected.


```
import std.algorithm: map;
import std.array: join;

struct T
{
string a;
alias a this;
}

void main()
{
auto t = [ T("أ") ]; // has to contain non-ascii unicode (this is the
arabic letter أ)
auto s = t.map!(same => same).join();
}

```

--

Re: Unnable to join Discord

[nayy via Digitalmars-d-learn]

On Thursday, 12 August 2021 at 18:24:44 UTC, Tejas wrote:

On Thursday, 12 August 2021 at 18:11:20 UTC, nayy wrote:

Hi

I cannot seems to be able to join the discord server

It gives me the following error: "unable to accept invit"

Is the invitation link expired? 
https://dlang.org/community.html https://discord.gg/bMZk9Q4


I joined last week with the same link.
It worked.

Try updating your app, maybe?


I am using the web version, I am not sure what to do, I tried to 
create a new account but it gives me the same error code, are the 
invitations not allowed anymore? Can anyone check please?

Thanks

Re: Unnable to join Discord

[nayy via Digitalmars-d-learn]

Maybe it doesn't like a VPN usage? I will try without it

Re: Unnable to join Discord

[Tejas via Digitalmars-d-learn]

On Thursday, 12 August 2021 at 18:11:20 UTC, nayy wrote:

Hi

I cannot seems to be able to join the discord server

It gives me the following error: "unable to accept invit"

Is the invitation link expired? 
https://dlang.org/community.html https://discord.gg/bMZk9Q4


I joined last week with the same link.
It worked.

Try updating your app, maybe?

Unnable to join Discord

[nayy via Digitalmars-d-learn]

Hi

I cannot seems to be able to join the discord server

It gives me the following error: "unable to accept invit"

Is the invitation link expired? https://dlang.org/community.html 
https://discord.gg/bMZk9Q4

[Issue 21337] join can iterates ranges multiple times

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Dlang Bot  ---
dlang/phobos pull request #7692 "merge stable" was merged into master:

- 10e862b458fe1b359ab050a08c8f4777a4c3cf7e by Richard Manthorpe:
  Fix Issue 21337: Join can iterate ranges multiple times

https://github.com/dlang/phobos/pull/7692

--

[Issue 21337] join can iterates ranges multiple times

[d-bugmail--- via Digitalmars-d-bugs]

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

Dlang Bot  changed:

   What|Removed |Added

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

--- Comment #2 from Dlang Bot  ---
dlang/phobos pull request #7674 "Fix Issue 21337: Join can iterate ranges
multiple times" was merged into stable:

- 529a28ce185375a793d16a84a4a05b2786af39b4 by Richard Manthorpe:
  Fix Issue 21337: Join can iterate ranges multiple times

https://github.com/dlang/phobos/pull/7674

--

[Issue 21337] join can iterates ranges multiple times

[d-bugmail--- via Digitalmars-d-bugs]

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

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Dlang Bot  ---
@rmanthorpe created dlang/phobos pull request #7674 "Fix Issue 21337: Join can
iterate ranges multiple times" fixing this issue:

- Fix Issue 21337: Join can iterates ranges multiple times

https://github.com/dlang/phobos/pull/7674

--

[Issue 21337] New: join can iterates ranges multiple times

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 21337
   Summary: join can iterates ranges multiple times
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: rma...@gmail.com

class Once
{
bool empty;
void popFront() { empty = true; }
int front() { return 0; }
}

void main()
{
import std.array : join;
import std.algorithm.iteration : map;

assert([1, 2].map!"[a]".join(new Once) == [1, 0, 2]); // fails
}


Join iterates `Once` once to make an array and again for each separator, which
obviously doesn't work.

--

[Issue 18135] [REG2.078] can't join RegexMatch anymore

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/b221120735b04095a6d4c7702eb9cc6e37aba170
fix Issue 18135 - can't join RegexMatch anymore

https://github.com/dlang/phobos/commit/8c19c30d239f034c14ec21d216ccf26ee136db61
Merge pull request #5972 from MartinNowak/fix18135

--

[Issue 18135] [REG2.078] can't join RegexMatch anymore

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 18135] [REG2.078] can't join RegexMatch anymore

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/b221120735b04095a6d4c7702eb9cc6e37aba170
fix Issue 18135 - can't join RegexMatch anymore

- fix copying of structs with RegexMatch fields by making
  const interface reference rebindable

https://github.com/dlang/phobos/commit/8c19c30d239f034c14ec21d216ccf26ee136db61
Merge pull request #5972 from MartinNowak/fix18135

fix Issue 18135 - can't join RegexMatch anymore
merged-on-behalf-of: Sebastian Wilzbach <sebi.wilzb...@gmail.com>

--

[Issue 18135] [REG2.078] can't join RegexMatch anymore

[d-bugmail--- via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #5 from Martin Nowak  ---
https://github.com/dlang/phobos/pull/5972

--

[Issue 18135] [REG2.078] can't join RegexMatch anymore

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Martin Nowak  ---
cat > bug.d << CODE
import std.regex : RegexMatch;

struct MapResult(Range)
{
Range input;
}

void bug()
{
MapResult!(RegexMatch!string) res;
res = MapResult!(RegexMatch!string)();
}
CODE
dmd -c bug.d

bug.d(11): Error: cannot modify struct res MapResult!(RegexMatch!string) with
immutable members


--

[Issue 18135] [REG2.078] can't join RegexMatch anymore

[d-bugmail--- via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #3 from Martin Nowak  ---
The referenced std.regex change is from 2016-12 and was reverted in the
meantime.
Digger pointed me to https://github.com/dlang/phobos/pull/5722 instead.

--

[Issue 18135] [REG2.078] can't join RegexMatch anymore

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Seb  ---
See also: https://issues.dlang.org/show_bug.cgi?id=17066

--

[Issue 18135] [REG2.078] can't join RegexMatch anymore

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from Seb  ---
This was introduced by https://github.com/dlang/phobos/pull/4286

--

[Issue 18135] New: [REG2.078] can't join RegexMatch anymore

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18135
   Summary: [REG2.078] can't join RegexMatch anymore
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

This used to compile, it doesn't anymore with 2.078.0:

```
import std.algorithm : joiner, map;

auto matchIssueRefs(string message)
{
import std.regex;

static auto matchToRefs(M)(M m)
{
enum splitRE = regex(`foo`);
return m.captures[0].splitter(splitRE);
}

enum issueRE = ctRegex!`foo`;
return message.matchAll(issueRE).map!matchToRefs;
}

auto getIssueRefs(string[] commits)
{
return commits
.map!matchIssueRefs
.joiner;
}
```

with:

```
/home/seb/dlang/phobos/std/algorithm/iteration.d(2504): Error: cannot modify
struct this._current MapResult!(matchToRefs, RegexMatch!string) with immutable
members
test.d(21): Error: template instance
std.algorithm.iteration.joiner!(MapResult!(matchIssueRefs, string[])) error
instantiating
```

--

[Issue 11691] can't join pathSplitter with dirSeparator

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|unspecified |D2

--

[Issue 13877] Problem with map+join

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to 2.067 at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/f81de7d9b9a9d4d8af4615306b2b759f845bd792
Fix Issue 13877 - join assumes forward range can be cheaply iterated twice

https://github.com/D-Programming-Language/phobos/commit/ba100ff803f8d266f97e9c02503e19f961be1e7e
Merge pull request #2837 from Poita/Issue13877

--

[Issue 13877] Problem with map+join

[via Digitalmars-d-bugs]

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

--- Comment #4 from Peter Alexander peter.alexander...@gmail.com ---
https://github.com/D-Programming-Language/phobos/pull/2837

For now, I'm limiting the optimization to arrays only. Any other range is
conservatively assumed to have arbitrarily expensive iteration, so the normal
appender path is used for those.

--

[Issue 13877] Problem with map+join

[via Digitalmars-d-bugs]

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

Peter Alexander peter.alexander...@gmail.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||peter.alexander...@gmail.co
   ||m
   Assignee|nob...@puremagic.com|peter.alexander...@gmail.co
   ||m

--

[Issue 13877] Problem with map+join

[via Digitalmars-d-bugs]

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

safety0ff.bugz safety0ff.b...@gmail.com changed:

   What|Removed |Added

 CC||safety0ff.b...@gmail.com
   Hardware|x86 |All
 OS|Windows |All

--- Comment #3 from safety0ff.bugz safety0ff.b...@gmail.com ---
IMO the problem is that join assumes that traversal of the range of ranges is
cheap.

All the optimization is doing is avoiding reallocation costs while building the
array of results (by computing length then allocating appropriately sized array
for the results.)

As shown by bearophile, this shouldn't be assumed in the general case.

I ran into an issue where std.parallelism assumed that opIndex was as cheap as
popFront, but for my specific range it was easier to compute the next front
knowing the previous one than it was to find the element given by the index.

If these type of optimizations are important, perhaps there should be some
performance hint tags for range operations. e.g. popFront on an array range
is cheap whereas popFront on a MapResult may vary arbitrarily.

--

[Issue 13877] New: Problem with map+join

[via Digitalmars-d-bugs]

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

  Issue ID: 13877
   Summary: Problem with map+join
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: Phobos
  Assignee: nob...@puremagic.com
  Reporter: bearophile_h...@eml.cc

This shows a different computational complexity using apparently equivalent
range-based code:


import std.stdio: writeln;
import std.algorithm: map, join;

uint count1, count2;

const(int)[] foo1(in int[] data, in int i, in int max) {
count1++;

if (i  max) {
typeof(return) result;
foreach (immutable n; data)
result ~= foo1(data, i + 1, max);
return result;
} else {
return data;
}
}

const(int)[] foo2(in int[] data, in int i, in int max) {
count2++;

if (i  max) {
return data.map!(n = foo2(data, i + 1, max)).join;
} else {
return data;
}
}

void main() {
const r1 = foo1([1, 2, 3, 4, 5], 1, 7);
writeln(count1); // 19531
const r2 = foo2([1, 2, 3, 4, 5], 1, 7);
writeln(count2); // 111
assert(r1 == r2); // Results are equally correct.
}


I think such performance traps should not be present using ranges.


The right complexity is restored using:

return data.map!(n = foo2(data, i + 1, max)).cache.joiner.array;

--

[Issue 13877] Problem with map+join

[via Digitalmars-d-bugs]

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

--- Comment #1 from bearophile_h...@eml.cc ---
The work-around was found by anon:

http://forum.dlang.org/thread/ibfthfpvccfamdezb...@forum.dlang.org#post-rincbqgpzcezcuiksvos:40forum.dlang.org

--

[Issue 13877] Problem with map+join

[via Digitalmars-d-bugs]

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

Ketmar Dark ket...@ketmar.no-ip.org changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--- Comment #2 from Ketmar Dark ket...@ketmar.no-ip.org ---
btw, with such modification both variants becomes equivalent:

  auto stripSave(RT) (auto ref RT rng) {
static struct R {
  RT r;
  @disable void save ();
  alias r this;
}
return R(rng);
  }


  const(int)[] foo2 (in int[] data, in int i, in int max) {
count2++;
if (i  max) {
  return data.map!(n = foo2(data, i + 1, max)).stripSave.join;
} else {
  return data;
}
  }


the code turns MapResult to non-forward range, and then join doesn't calculate
everything twice.

the question is: should MapResult has '.save' here in the first place?

or maybe we need some API — as `stripSave` to explicitly remove features from
ranges? it's very obvious to the programmer that recalculating range values is
costly in this case, so he can just remove `.save` to stop Phobos using it.

--

Re: Making enum join variadic

[Nordlöw]

artur


Thx!

Here's my final version that compiles and run:

import std.stdio: writeln;
import traits_ex: isEnum;
import std.typetuple: allSatisfy;

/** Join/Chain/Concatenate/Unite Enums $(D E1), $(D E2), ... into 
$(D E).
See also: 
http://forum.dlang.org/thread/f9vc6p$1b7k$1...@digitalmars.com

*/
template join(ES...) if (allSatisfy!(isEnum, ES)) {
mixin({
string r = enum join { ;
foreach (E; ES) {
import std.range: join;
r ~= [__traits(allMembers, E),  ].join(,);
}
return r ~ };
}());
}

unittest
{
enum E1 { a, b, c }
enum E2 { e, f, g }
enum E3 { h, i, j}
alias E1_ = join!(E1);
alias E12 = join!(E1, E2);
alias E123 = join!(E1, E2, E3);
writeln(E123.min, ,, E123.max);
}

Some final questions:

- Is join a good naming for this? Is chain better?
- Is it better to be verbose with joinEnums?
- What other useful enum algorithms are you missing?
- Should this perhaps go into Phobos? If so in what module? 
std.algorithm, range, traits?

Re: Making enum join variadic

[Nordlöw]

Its up: https://github.com/nordlow/justd/blob/master/enums.d

Re: Making enum join variadic

[Philippe Sigaud via Digitalmars-d-learn]

On Fri, May 2, 2014 at 12:59 PM, Nordlöw
digitalmars-d-learn@puremagic.com wrote:

 Some final questions:

 - Is join a good naming for this? Is chain better?
 - Is it better to be verbose with joinEnums?

I'd be verbose. It's an uncommon operation, bound to surprise a reader
a bit.It's better to type a few more letters.

I did not try to compile it, but what happens if the enum elements
have the same name ? The same min/max/values ?

Like this:

enum E1 { a, b, c }

alias E111 = join!(E1, E1, E1);



 - What other useful enum algorithms are you missing?
 - Should this perhaps go into Phobos? If so in what module? std.algorithm, 
 range, traits?

I would put it in std.typecons, since it's a type constructor

Re: Making enum join variadic

[Nordlöw]

I'd be verbose. It's an uncommon operation, bound to surprise a 
reader

a bit.It's better to type a few more letters.


See update.

I did not try to compile it, but what happens if the enum 
elements

have the same name ? The same min/max/values ?

Like this:

enum E1 { a, b, c }

alias E111 = join!(E1, E1, E1);


This should give a better error message, than current mixin error.
I'll work on that.


I would put it in std.typecons, since it's a type constructor


Ok.

Thx!

Re: Making enum join variadic

[Nordlöw]

On Friday, 2 May 2014 at 12:45:44 UTC, Nordlöw wrote:
I'd be verbose. It's an uncommon operation, bound to surprise 
a reader

a bit.It's better to type a few more letters.


See update.

I did not try to compile it, but what happens if the enum 
elements

have the same name ? The same min/max/values ?

Like this:

enum E1 { a, b, c }

alias E111 = join!(E1, E1, E1);


This should give a better error message, than current mixin 
error.

I'll work on that.


I would put it in std.typecons, since it's a type constructor


Ok.

Thx!


Here's my try at detecting member names collision at compile time:

template MemberNamesUnion(E...) if (allSatisfy!(isEnum, E))
{
bool[string] allMembers;   // used to detect member collisions
mixin({
string r = enum MemberNamesUnion { ;
foreach (T; E) {
import std.range: join;
foreach (member; __traits(allMembers, T)) {
static assert (member in allMembers, Member 
collision);

allMembers[member] = true;
}
r ~= [__traits(allMembers, T)].join(,) ~ ,;
}
return r ~  };
}());
}

It fails as

enums.d(25,46): Error: static variable allMembers cannot be read 
at compile time
enums.d(25,21):while evaluating: static assert(a in 
allMembers)


Is there a solution to this problem?

Re: Making enum join variadic

[Meta via Digitalmars-d-learn]

On Friday, 2 May 2014 at 13:38:39 UTC, Nordlöw wrote:
enums.d(25,46): Error: static variable allMembers cannot be 
read at compile time
enums.d(25,21):while evaluating: static assert(a in 
allMembers)


Is there a solution to this problem?


Associative arrays are not CTFE-able.

Re: Making enum join variadic

[Nordlöw]

On Friday, 2 May 2014 at 14:36:16 UTC, Meta wrote:

On Friday, 2 May 2014 at 13:38:39 UTC, Nordlöw wrote:
enums.d(25,46): Error: static variable allMembers cannot be 
read at compile time
enums.d(25,21):while evaluating: static assert(a in 
allMembers)


Is there a solution to this problem?


Associative arrays are not CTFE-able.


So that leaves me with using an array of bool and rank() then, I 
guess...

Re: Making enum join variadic

[Nordlöw]

So that leaves me with using an array of bool and rank() then, 
I guess...


Correction: I mean array of strings and find.

Re: Making enum join variadic

[Artur Skawina via Digitalmars-d-learn]

On 05/02/14 15:38, Nordlöw via Digitalmars-d-learn wrote:
 
 template MemberNamesUnion(E...) if (allSatisfy!(isEnum, E))
 {
 bool[string] allMembers;   // used to detect member collisions
 mixin({
 string r = enum MemberNamesUnion { ;
 foreach (T; E) {
 import std.range: join;
 foreach (member; __traits(allMembers, T)) {
 static assert (member in allMembers, Member collision);
 allMembers[member] = true;
 }
 r ~= [__traits(allMembers, T)].join(,) ~ ,;
 }
 return r ~  };
 }());
 }
 
 It fails as
 
 enums.d(25,46): Error: static variable allMembers cannot be read at compile 
 time
 enums.d(25,21):while evaluating: static assert(a in allMembers)
 
 Is there a solution to this problem?

Move the AA declaration to inside the lambda, remove the 'static'
from the assert, and fix the condition (member !in allMembers), then
it will work.

artur

Re: Making enum join variadic

[Meta via Digitalmars-d-learn]

On Friday, 2 May 2014 at 15:18:06 UTC, Artur Skawina via 
Digitalmars-d-learn wrote:

On 05/02/14 15:38, Nordlöw via Digitalmars-d-learn wrote:


template MemberNamesUnion(E...) if (allSatisfy!(isEnum, E))
{
bool[string] allMembers;   // used to detect member 
collisions

mixin({
string r = enum MemberNamesUnion { ;
foreach (T; E) {
import std.range: join;
foreach (member; __traits(allMembers, T)) {
static assert (member in allMembers, 
Member collision);

allMembers[member] = true;
}
r ~= [__traits(allMembers, T)].join(,) ~ ,;
}
return r ~  };
}());
}

It fails as

enums.d(25,46): Error: static variable allMembers cannot be 
read at compile time
enums.d(25,21):while evaluating: static assert(a in 
allMembers)


Is there a solution to this problem?


Move the AA declaration to inside the lambda, remove the 
'static'
from the assert, and fix the condition (member !in 
allMembers), then

it will work.

artur


But that will also move the compile time check to a runtime one.

Re: Making enum join variadic

[Artur Skawina via Digitalmars-d-learn]

On 05/02/14 17:27, Meta via Digitalmars-d-learn wrote:
 On Friday, 2 May 2014 at 15:18:06 UTC, Artur Skawina via Digitalmars-d-learn 
 wrote:
 On 05/02/14 15:38, Nordlöw via Digitalmars-d-learn wrote:

 template MemberNamesUnion(E...) if (allSatisfy!(isEnum, E))
 {
 bool[string] allMembers;   // used to detect member collisions
 mixin({
 string r = enum MemberNamesUnion { ;
 foreach (T; E) {
 import std.range: join;
 foreach (member; __traits(allMembers, T)) {
 static assert (member in allMembers, Member 
 collision);
 allMembers[member] = true;
 }
 r ~= [__traits(allMembers, T)].join(,) ~ ,;
 }
 return r ~  };
 }());
 }

 It fails as

 enums.d(25,46): Error: static variable allMembers cannot be read at compile 
 time
 enums.d(25,21):while evaluating: static assert(a in allMembers)

 Is there a solution to this problem?

 Move the AA declaration to inside the lambda, remove the 'static'
 from the assert, and fix the condition (member !in allMembers), then
 it will work.
 
 But that will also move the compile time check to a runtime one.

No; mixin arguments are always evaluated at CT.

artur

Making enum join variadic

[Nordlöw]

How can I make `join` variadic (by filling in njoin) in the 
following code?


import std.stdio: writeln;
import std.traits;

string enumsHelper(S...)(S s)
{
typeof(return) r;
foreach (i, e; s)
{
if (i = 1)
r ~= , ;
r ~= e;
}
return r;
}

/** Join/Chain/Concatenate/Unite Enums $(D E1), $(D E2), ... into 
$(D E).
See also: 
http://forum.dlang.org/thread/f9vc6p$1b7k$1...@digitalmars.com

*/
template join(string E, E1, E2)
{
const join = (enum  ~ E ~  {  ~
   enumsHelper(__traits(allMembers, E1)) ~ , ~
   enumsHelper(__traits(allMembers, E2)) ~  }
);
}

template njoin(string E, Ei...)
{
import std.algorithm: map;
enum string njoin = enum  ~ E ~  {  ~  ~  } ;
}

void main(string[] args)
{
enum E1 { A, B, C }
enum E2 { E, F, G }
mixin(join!(E12, E1, E2));
E12 e12;
writeln(e12.min, ,, e12.max);
}

Re: Making enum join variadic

[bearophile via Digitalmars-d-learn]

Nordlöw:

How can I make `join` variadic (by filling in njoin) in the 
following code?


When you have a D tuple (not Phobos tuple), and it contains 
values all of the same type, you can turn it into an array with 
just:


[mytuple]

Once you have an array of strings, you can use the normal phobos 
function to join the strings as you desire.


Bye,
bearophile

Re: Making enum join variadic

[Artur Skawina via Digitalmars-d-learn]

On 05/02/14 00:24, Nordlöw via Digitalmars-d-learn wrote:
 How can I make `join` variadic (by filling in njoin) in the following code?

   import std.array, std.range, std.algorithm;
   import std.stdio;

   template Njoin(ES...) {
  mixin({
 string r = enum Njoin { ;
 foreach (E; ES)
r ~= [__traits(allMembers, E),  ].join(,);
 return r ~ };
  }());
   }

   void main(string[] args)
   {
   enum E1 { A, B, C }
   enum E2 { E, F, G }
   alias E12 = Njoin!(E1, E2);
   E12 e12;
   writeln(e12.min, ,, e12.max);
   }

artur

[Issue 11691] New: can't join pathSplitter with pathSeparator

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11691

   Summary: can't join pathSplitter with pathSeparator
   Product: D
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: c...@dawg.eu


--- Comment #0 from Martin Nowak c...@dawg.eu 2013-12-05 06:13:43 PST ---
cat  bug.d  CODE
import std.range, std.path;

void bug()
{
auto comps = pathSplitter(foo/bar);
auto path = join(comps, pathSeparator);
}
CODE

dmd -c bug



This fails because the element type of PathSplitter
is const(C[]) where it should be const(C)[].

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11691] can't join pathSplitter with pathSeparator

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11691


Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

   Keywords||pull


--- Comment #1 from Martin Nowak c...@dawg.eu 2013-12-05 06:23:31 PST ---
https://github.com/D-Programming-Language/phobos/pull/1749

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11691] can't join pathSplitter with dirSeparator

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11691


Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

Summary|can't join pathSplitter |can't join pathSplitter
   |with pathSeparator  |with dirSeparator


--- Comment #2 from Martin Nowak c...@dawg.eu 2013-12-05 06:56:37 PST ---
Apparently I should have used dirSeparator but it doesn't affect the bug.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11691] can't join pathSplitter with dirSeparator

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11691



--- Comment #3 from github-bugzi...@puremagic.com 2013-12-05 08:45:41 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/c1251436ba67b39e26f61e54ab79f8ee769fe5e7
fix Issue 11691 - can't join pathSplitter with pathSeparator

- The inferred return type of front had an additional
  layer of const because it's a const method.

https://github.com/D-Programming-Language/phobos/commit/4d3a2c49c8c72a5873f8c64e5b49b6a9ab897382
Merge pull request #1749 from dawgfoto/fix11691

fix Issue 11691 - can't join pathSplitter with pathSeparator

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 11691] can't join pathSplitter with dirSeparator

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=11691


Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

Re: equivalent of python join?

[Ali Çehreli]

On 12/02/2013 11:32 PM, Jacob Carlborg wrote:

 On 2013-12-03 07:36, CJS wrote:
 In python a common performance tip for joining many strings together is
 to use the join method. So, for example, instead of
 a + b + c
 use
 ''.join([a,b,c]).
 The idea is to avoid creating temporary objects that are immediately
 thrown away. It's obviously overkill for such a small number of strings,
 though.

 Is there any equivalent method/advice when concatenating many strings
 together in D?

 There's std.algorithm.joiner[1] and std.array.join[2]. I don't know if
 they're any more efficient than using ~.

They are more efficient in the sense that they are lazy.

 There's also
 std.array.Appender[3] if you want to do a lot of appending and want the
 most efficient way.

 [1] http://dlang.org/phobos/std_algorithm.html#joiner
 [2] http://dlang.org/phobos/std_array.html#.join
 [3] http://dlang.org/phobos/std_array.html#.Appender

There is also the more general std.range.chain. It can join any type of 
range as long as the element types are the same:


import std.stdio;
import std.range;
import std.algorithm;

void main()
{
auto a_lazy_range_of_ints
= chain(5.iota,
[ 10, 9, 20, 8 ].filter!(a = a  10));

// writeln consumes the range eagerly
writeln(a_lazy_range_of_ints);

// Prints [0, 1, 2, 3, 4, 9, 8]
}

Ali

equivalent of python join?

[CJS]

In python a common performance tip for joining many strings 
together is to use the join method. So, for example, instead of

a + b + c
use
''.join([a,b,c]).
The idea is to avoid creating temporary objects that are 
immediately thrown away. It's obviously overkill for such a small 
number of strings, though.


Is there any equivalent method/advice when concatenating many 
strings together in D?

Re: equivalent of python join?

[Jacob Carlborg]

On 2013-12-03 07:36, CJS wrote:

In python a common performance tip for joining many strings together is
to use the join method. So, for example, instead of
a + b + c
use
''.join([a,b,c]).
The idea is to avoid creating temporary objects that are immediately
thrown away. It's obviously overkill for such a small number of strings,
though.

Is there any equivalent method/advice when concatenating many strings
together in D?


There's std.algorithm.joiner[1] and std.array.join[2]. I don't know if 
they're any more efficient than using ~. There's also 
std.array.Appender[3] if you want to do a lot of appending and want the 
most efficient way.


[1] http://dlang.org/phobos/std_algorithm.html#joiner
[2] http://dlang.org/phobos/std_array.html#.join
[3] http://dlang.org/phobos/std_array.html#.Appender

--
/Jacob Carlborg

join of range of ranges?

[bearophile]

In some cases I'd like to join a range of ranges in a single 
array/string (I know here the inner map could be replaced by 
something better, this code is just an example):



import std.algorithm: map;
import std.array: join, array;
void main() {
auto r1 = [1, 2]
  .map!(x = [1, 2].map!(y = '*').array)
  .join(_);
auto r2 = [1, 2]
  .map!(x = [1, 2].map!(y = '*'))
  .join(_);
}


The code works only if I add an 'array' inside, to turn it into a 
range of arrays. Do you think it's right to ask as enhancement 
for std.array.join to work with a range of ranges too, as in the 
r2 case?


Bye,
bearophile

Re: join of range of ranges?

[David Nadlinger]

On Sunday, 22 September 2013 at 14:26:14 UTC, bearophile wrote:
In some cases I'd like to join a range of ranges in a single 
array/string (I know here the inner map could be replaced by 
something better, this code is just an example):


std.algorithm.joiner, or am I missing something?

David

Re: join of range of ranges?

[bearophile]

Peter Alexander:

The problem is that you are trying to map a range of range of 
chars with a range of dchars.


auto r2 = [1, 2]
  .map!(x = [1, 2].map!(y = cast(dchar)'*'))
  .join(_);

This works.


I see, thank you. When I ask a question it seems my brain 
switches off a bit :-)




I really wish character literals in D where always dchar.


This is supported:

void main() {
auto s1 = hellow;
auto s2 = hellod;
}


So, what about adding support for this?

void main() {
auto c1 = 'X'w;
auto c2 = 'X'd;
static assert(is(typeof(c1) == wchar));
static assert(is(typeof(c2) == dchar));
}


Bye,
bearophile

Re: join of range of ranges?

[monarch_dodra]

On Sunday, 22 September 2013 at 20:27:01 UTC, bearophile wrote:

Peter Alexander:

The problem is that you are trying to map a range of range of 
chars with a range of dchars.


auto r2 = [1, 2]
 .map!(x = [1, 2].map!(y = cast(dchar)'*'))
 .join(_);

This works.


I see, thank you. When I ask a question it seems my brain 
switches off a bit :-)




I really wish character literals in D where always dchar.


This is supported:

void main() {
auto s1 = hellow;
auto s2 = hellod;
}


So, what about adding support for this?

void main() {
auto c1 = 'X'w;
auto c2 = 'X'd;
static assert(is(typeof(c1) == wchar));
static assert(is(typeof(c2) == dchar));
}


Bye,
bearophile


Even helloc is supported actually :) It can make a difference 
if you *don't* want your string implicitly promoted on 
declaration. EG:


dstring ds1 = hello; //Fine
dstring ds2 = helloc; //Nope.

As for allowing 'X'w, I think the rationale is that a cast will 
get you the same result (not so with string literals).

Re: join of range of ranges?

[Peter Alexander]

On Sunday, 22 September 2013 at 18:13:39 UTC, Peter Alexander 
wrote:

On Sunday, 22 September 2013 at 14:26:14 UTC, bearophile wrote:

   auto r2 = [1, 2]
 .map!(x = [1, 2].map!(y = '*'))
 .join(_);


The problem is that you are trying to map a range of range of 
chars with a range of dchars.


This could also be solved by having join return an array of the 
CommonType of the elements of both ranges.

Re: join of range of ranges?

[bearophile]

monarch_dodra:

As for allowing 'X'w, I think the rationale is that a cast will 
get you the same result (not so with string literals).


OK. I have desired those char suffixes for years, so now I have 
written an ER:


http://d.puremagic.com/issues/show_bug.cgi?id=11103

Bye,
bearophile

Generic string join

[JS]

Here is a optimal generic string joiner that maximizes compiler 
optimization, allows for a variable number of arguments that can 
be strings or arrays of strings.


http://dpaste.dzfl.pl/0a021e1f

Drawbacks:
1. Static if explosion
2. Not elegant
3. Only works with RT strings or RT string arrays, would be 
nice to work with chars and possibly others.
4. Does not have the ability to use book ends delimitation... 
not difficult to do but just more bloat-code.
5. Would be nice to allow apply a lambda to each element. 
Again, not hard but requires all those special cases to deal with 
proper delimitation due to the recursion required.
6. Requires a mixin statement... this is not pretty at all. 
One can't wrap the mixin in a normal function call because it 
defeats the purpose of optimization(CT strings will be passed as 
variables and not optimized by the CT).

etc...

While I have some code to flatten such arrays before 
delimitation, which would probably make it much easier, which is 
the way I started, the code was going to turn out to be the same 
in the end as the flattener, so I just modified the 
code(basically use string concatenation instead of tuple 
concatenation).



Anyways, maybe someone has a good idea how to improve the code to 
achieve the same results. Note in in the test, every possible 
3-combination is tried, which I think is good enough to prove the 
validity of the code.

Re: Generic string join

[JS]

On Monday, 29 July 2013 at 09:01:36 UTC, JS wrote:
Here is a optimal generic string joiner that maximizes compiler 
optimization, allows for a variable number of arguments that 
can be strings or arrays of strings.


http://dpaste.dzfl.pl/0a021e1f

Drawbacks:
1. Static if explosion
2. Not elegant
3. Only works with RT strings or RT string arrays, would be 
nice to work with chars and possibly others.
4. Does not have the ability to use book ends 
delimitation... not difficult to do but just more bloat-code.
5. Would be nice to allow apply a lambda to each element. 
Again, not hard but requires all those special cases to deal 
with proper delimitation due to the recursion required.
6. Requires a mixin statement... this is not pretty at all. 
One can't wrap the mixin in a normal function call because it 
defeats the purpose of optimization(CT strings will be passed 
as variables and not optimized by the CT).

etc...

While I have some code to flatten such arrays before 
delimitation, which would probably make it much easier, which 
is the way I started, the code was going to turn out to be the 
same in the end as the flattener, so I just modified the 
code(basically use string concatenation instead of tuple 
concatenation).



Anyways, maybe someone has a good idea how to improve the code 
to achieve the same results. Note in in the test, every 
possible 3-combination is tried, which I think is good enough 
to prove the validity of the code.


BTW, one can wrap the template to remove the mixin in #6 but this 
is not very satisfactory as it has a much higher performance hit 
for CT joining.


template t(T...)
{
string t(string d, T args)
{
return mixin(tJoin!(,, args));
}
}

mixin(tJoin!(,, a, b)) is just 4 instructions max. Using t 
is about 10-15 times that(although I'm not sure if inlining will 
solve that).

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com


--- Comment #11 from Walter Bright bugzi...@digitalmars.com 2012-12-25 
03:36:13 PST ---
Dmitry, does this mean this is not a bug in the compiler or library?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774



--- Comment #12 from Alex R�nne Petersen a...@lycus.org 2012-12-25 12:40:19 
CET ---
Well, we probably should make sure that by the time Thread.start() returns, the
thread is joinable (waiting for the thread to start in Thread.join() would
probably be undesirable).

In any case, it probably isn't a bug, but a very reasonable enhancement request
- I know I'd expect it to behave like that.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774



--- Comment #13 from luka8088 luka8...@owave.net 2012-12-25 04:42:33 PST ---
(In reply to comment #10)
 (In reply to comment #8)
  Here is a simple test case:
  
  -
  
  module program;
  
  import std.stdio;
  import core.thread;
  
  void main () {
  
Thread t1, t2;
  
t1 = new Thread(delegate { t2.start(); });
t2 = new Thread(delegate { Thread.sleep(dur!seconds(1)); });
  
t1.start();
t2.join();
  
  }
  
  -
  
  http://dpaste.dzfl.pl/0d24dd06
  
  output:
core.thread.ThreadException@src/core/thread.d(780): Unable to join thread
  
  if t2.join occurs after t2 already finished then exception is not thrown, 
  hence
  the sleep
 
 This one is a genuine race condition: t2.join could be called before t2 is
 actually started by t1. And as far as I can tell this is the *most* *probable*
 outcome. So it can't be seriously taken as test case without proper
 synchronization between threads.
 
 What it shows though is that you can't join a thread that isn't started and 
 the
 error is Unable to join thread.


Yes, you are correct, it does not make much sense, but there is another issue.
The following code throws an exception on 64-bit linux (32-bit linux and 32-bit
windows executes without throwing an exception). On 64-bit linux t2 is never
started.

-

module program;

import std.stdio;
import core.thread;

void main () {

  Thread t1, t2;
  bool runned = false;

  t1 = new Thread(delegate { t2.start(); });
  t2 = new Thread(delegate { runned = true; });

  t1.start();
  Thread.sleep(dur!seconds(1));
  assert(runned);

}

-

http://dpaste.dzfl.pl/5dc9733e


Should I file a new bug report ?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774



--- Comment #14 from Dmitry Olshansky dmitry.o...@gmail.com 2012-12-25 
06:03:35 PST ---
(In reply to comment #11)
 Dmitry, does this mean this is not a bug in the compiler or library?

From what I can gather the bug is not in compiler but in the original code
making wrong assumptions about behavior of map in Phobos(it doesn't cache any
value but computes them on demand). 

I suspect that this problem with the code was apparently hidden by the fact
that join didn't always throw exception on the wrong join (e.g. on a thread
that isn't started). In other words the code worked by pure luck and it needs
fixing. 

However I'm still getting access violation after fixing the original bug. I'll
investigate further as to what is the cause. It may be an unrelated bug with a
closure as there are 3 level of these.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774



--- Comment #15 from Dmitry Olshansky dmitry.o...@gmail.com 2012-12-25 
06:14:16 PST ---
(In reply to comment #13)
 
 Yes, you are correct, it does not make much sense, but there is another issue.
 The following code throws an exception on 64-bit linux (32-bit linux and 
 32-bit
 windows executes without throwing an exception). On 64-bit linux t2 is never
 started.
 
How did you get to this conclusion?

 -
 
 module program;
 
 import std.stdio;
 import core.thread;
 
 void main () {
 
   Thread t1, t2;
   bool runned = false;
 
   t1 = new Thread(delegate { t2.start(); });
   t2 = new Thread(delegate { runned = true; });
 
   t1.start();
   Thread.sleep(dur!seconds(1));
   assert(runned);
 
 }
 
 -
 
 http://dpaste.dzfl.pl/5dc9733e
 
 
 Should I file a new bug report ?

And again there is no guarantee that: 
a) access to runned is properly guarded and made visible in all threads as it's
on stack and not declared as shared nor there are memory barriers. TEchnically
compiler is free to do what the heck it wants to.
b) sleep is not a tool to coordinate threads, use locks and condition variables
(or spin on atomic variables) as there is *always* a *chance* to get to
assert(runned) before t2 is executed.

With all that being said it very well *may* be a bug. Yet the test is still
bogus. Again until proper synchronization is enacted it's wrong to conclude
*anything* aside from the fact that it's ultimately indeterministic.

So if you'd get this in a form where there are no probabilities involved then
sure it's a bug and the report is appreciated.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774


Dmitry Olshansky dmitry.o...@gmail.com changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com


--- Comment #9 from Dmitry Olshansky dmitry.o...@gmail.com 2012-12-23 
01:58:21 PST ---
This one was actually simple to decipher - map recomputes values across
multiple iterations. I instrumented the code to show
a) ref address of threads in start loop and join loop
b) print Mapped each time a functor that creates the thread is run.

I get 2 times and 2 different addresses. The only question left is why it ever
worked.

The right aproach would be to call array on result of task map and do not
attempt 2nd lazy evluation of it.

Modifed source below:


import std.algorithm ;
import std.datetime ;
import std.range ;
import std.stdio;

import core.thread ;

import output_d ;

shared double sum ;
shared Object sumMutex ;

void partialSum ( immutable int id , immutable int sliceSize , immutable double
delta ) {
  immutable start = 1 + id * sliceSize ;
  immutable end = ( id + 1 ) * sliceSize ;
  auto localSum = 0.0 ;
  foreach ( i ; start .. end + 1 ) {
immutable x = ( i - 0.5 ) * delta ;
localSum += 1.0 / ( 1.0 + x * x ) ;
  }
  synchronized ( sumMutex ) { sum += localSum ; }
}

void execute ( immutable int numberOfThreads ) {
  immutable n = 10 ;
  immutable delta = 1.0 / n ;
  StopWatch stopWatch ;
  stopWatch.start ( ) ;
  immutable sliceSize = n / numberOfThreads ;
  sum = 0.0 ;
  auto threads = map ! ( ( int i ) {
  auto closedPartialSum ( ) {
immutable ii = i ;
return delegate ( ) { partialSum ( ii , sliceSize , delta ) ; } ;
  }
  writeln(Mapped!);
  return new Thread ( closedPartialSum ) ;
  } ) ( iota ( numberOfThreads ) ) ;
  foreach ( thread ; threads ) { 
writefln(%x, cast(void*)thread);
thread.start ( ) ; 
  }
  foreach ( thread ; threads ) { 
writefln(%x, cast(void*)thread);
thread.join ( ) ; 
  }
  immutable pi = 4.0 * delta * sum ;
  stopWatch.stop ( ) ;
  immutable elapseTime = stopWatch.peek ( ).hnsecs * 100e-9 ;
  output ( __FILE__ , pi , n , elapseTime , numberOfThreads ) ;
}

int main ( immutable string[] args ) {
  sumMutex = new shared ( Object ) ;
  execute ( 1 ) ;
  execute ( 2 ) ;
  execute ( 8 ) ;
  execute ( 32 ) ;
  return 0 ;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774



--- Comment #10 from Dmitry Olshansky dmitry.o...@gmail.com 2012-12-23 
02:32:18 PST ---
(In reply to comment #8)
 Here is a simple test case:
 
 -
 
 module program;
 
 import std.stdio;
 import core.thread;
 
 void main () {
 
   Thread t1, t2;
 
   t1 = new Thread(delegate { t2.start(); });
   t2 = new Thread(delegate { Thread.sleep(dur!seconds(1)); });
 
   t1.start();
   t2.join();
 
 }
 
 -
 
 http://dpaste.dzfl.pl/0d24dd06
 
 output:
   core.thread.ThreadException@src/core/thread.d(780): Unable to join thread
 
 if t2.join occurs after t2 already finished then exception is not thrown, 
 hence
 the sleep

This one is a genuine race condition: t2.join could be called before t2 is
actually started by t1. And as far as I can tell this is the *most* *probable*
outcome. So it can't be seriously taken as test case without proper
synchronization between threads.

What it shows though is that you can't join a thread that isn't started and the
error is Unable to join thread.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 9082] New: join should accept types which are not ranges as the separator

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=9082

   Summary: join should accept types which are not ranges as the
separator
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com


--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-11-27 
04:05:05 PST ---
int[] arr = [1, 2, 3].join(0);  // fail

Expected:
[1, 0, 2, 0, 3]

This should work with any separator type if it's the element type of the range.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8852] New: Unable to join thread (started by another thread)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8852

   Summary: Unable to join thread (started by another thread)
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: luka8...@owave.net


--- Comment #0 from luka8088 luka8...@owave.net 2012-10-19 00:28:36 PDT ---
module program;

import std.stdio;
import core.thread;

void main () {

  Thread t1, t2;

  t1 = new Thread(delegate { t2.start(); });
  t2 = new Thread(delegate { Thread.sleep(dur!seconds(1)); });

  t1.start();
  t2.join();

}

-

http://dpaste.dzfl.pl/0d24dd06

output:
  core.thread.ThreadException@src/core/thread.d(780): Unable to join thread

if t2.join occurs after t2 already finished then exception is not thrown, hence
the sleep

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8852] Unable to join thread (started by another thread)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8852


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 CC||a...@lycus.org


--- Comment #1 from Alex R�nne Petersen a...@lycus.org 2012-10-19 09:29:58 
CEST ---
Possibly related to #8774.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 6116] May not join spawn()'ed threads

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=6116


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||a...@lycus.org
 Resolution||FIXED


--- Comment #5 from Alex R�nne Petersen a...@lycus.org 2012-10-19 09:31:01 
CEST ---
Closing this then. Please reopen if the bug resurfaces.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8852] Unable to join thread (started by another thread)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8852


luka8088 luka8...@owave.net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


--- Comment #2 from luka8088 luka8...@owave.net 2012-10-19 00:32:12 PDT ---
(In reply to comment #1)
 Possibly related to #8774.

Yes, thank you for the note

*** This issue has been marked as a duplicate of issue 8774 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774


luka8088 luka8...@owave.net changed:

   What|Removed |Added

 CC||luka8...@owave.net


--- Comment #7 from luka8088 luka8...@owave.net 2012-10-19 00:32:12 PDT ---
*** Issue 8852 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774



--- Comment #8 from luka8088 luka8...@owave.net 2012-10-19 00:33:58 PDT ---
Here is a simple test case:

-

module program;

import std.stdio;
import core.thread;

void main () {

  Thread t1, t2;

  t1 = new Thread(delegate { t2.start(); });
  t2 = new Thread(delegate { Thread.sleep(dur!seconds(1)); });

  t1.start();
  t2.join();

}

-

http://dpaste.dzfl.pl/0d24dd06

output:
  core.thread.ThreadException@src/core/thread.d(780): Unable to join thread

if t2.join occurs after t2 already finished then exception is not thrown, hence
the sleep

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] New: 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774

   Summary: 2.059 worked 2.060 does not: Unable to join thread
   Product: D
   Version: D2
  Platform: x86_64
OS/Version: Linux
Status: NEW
  Severity: regression
  Priority: P2
 Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: rus...@winder.org.uk


--- Comment #0 from Russel Winder rus...@winder.org.uk 2012-10-07 04:22:54 
PDT ---
The attached code compiles and runs fine under DMD 2.059 installed on Debian
Unstable via the distributed deb file. Under 2.060 it compiles but at runtime
gives:

core.thread.ThreadException@src/core/thread.d(780): Unable to join thread

/tmp/.rdmd-1000/rdmd-pi_d_threadsGlobalState_array_declarative.d-C963C499401209E276E9BB7F98EEB447/pi_d_threadsGlobalState_array_declarative(void
pi_d_threadsGlobalState_array_declarative.execute(immutable(int))+0x129)
[0x44dac5]
/tmp/.rdmd-1000/rdmd-pi_d_threadsGlobalState_array_declarative.d-C963C499401209E276E9BB7F98EEB447/pi_d_threadsGlobalState_array_declarative(_Dmain+0x28)
[0x44db8c]
/tmp/.rdmd-1000/rdmd-pi_d_threadsGlobalState_array_declarative.d-C963C499401209E276E9BB7F98EEB447/pi_d_threadsGlobalState_array_declarative(extern
(C) int rt.dmain2.main(int, char**).void runMain()+0x1c) [0x45b34c]
/tmp/.rdmd-1000/rdmd-pi_d_threadsGlobalState_array_declarative.d-C963C499401209E276E9BB7F98EEB447/pi_d_threadsGlobalState_array_declarative(extern
(C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate())+0x2a)
[0x45acc6]
/tmp/.rdmd-1000/rdmd-pi_d_threadsGlobalState_array_declarative.d-C963C499401209E276E9BB7F98EEB447/pi_d_threadsGlobalState_array_declarative(extern
(C) int rt.dmain2.main(int, char**).void runAll()+0x3b) [0x45b393]
/tmp/.rdmd-1000/rdmd-pi_d_threadsGlobalState_array_declarative.d-C963C499401209E276E9BB7F98EEB447/pi_d_threadsGlobalState_array_declarative(extern
(C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate())+0x2a)
[0x45acc6]
/tmp/.rdmd-1000/rdmd-pi_d_threadsGlobalState_array_declarative.d-C963C499401209E276E9BB7F98EEB447/pi_d_threadsGlobalState_array_declarative(main+0xd1)
[0x45ac51]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7fe18bb3aead]

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774



--- Comment #1 from Russel Winder rus...@winder.org.uk 2012-10-07 04:24:24 
PDT ---
Created an attachment (id=1146)
.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774


Russel Winder rus...@winder.org.uk changed:

   What|Removed |Added

   Attachment #1146|.   |pi_d_threadsGlobalState_arr
description||ay_declarative.d


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774


Alex R�nne Petersen a...@lycus.org changed:

   What|Removed |Added

 CC||a...@lycus.org


--- Comment #2 from Alex R�nne Petersen a...@lycus.org 2012-10-07 13:56:30 
CEST ---
pi_d_threadsGlobalState_array_declarative.d(13): Error: module output_d is in
file 'output_d.d' which cannot be read
import path[0] = .
import path[1] = /usr/include/dmd/phobos
import path[2] = /usr/include/dmd/druntime/import
Failed: 'dmd' '-v' '-o-' 'pi_d_threadsGlobalState_array_declarative.d' '-I.'

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774



--- Comment #3 from Russel Winder rus...@winder.org.uk 2012-10-07 05:00:53 
PDT ---
Created an attachment (id=1148)
output_d.d

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774



--- Comment #4 from Alex R�nne Petersen a...@lycus.org 2012-10-07 14:19:57 
CEST ---
What's happening is that pthread_join() is giving us ESRCH because the thread
handle is apparently no longer valid.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774



--- Comment #5 from Alex R�nne Petersen a...@lycus.org 2012-10-07 15:11:18 
CEST ---
Something is very wrong here and I'm not sure whether to blame the compiler or
Phobos:

starting 0 7FCE6E0B3E00
joining 0 7FCE6E0B3D00

First value is the thread number, second is its address. Notice how the address
it attempts to join with is very wrong.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 8774] 2.059 worked 2.060 does not: Unable to join thread

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=8774



--- Comment #6 from Russel Winder rus...@winder.org.uk 2012-10-07 07:44:02 
PDT ---
Perhaps worth noting that using ldc2 compiled from the Git repository gives
effectively the same result.

core.thread.ThreadException@/home/Checkouts/Git/Git/LDC/runtime/druntime/src/core/thread.d(788):
Unable to join thread

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 6116] May not join spawn()'ed threads

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=6116


SomeDude lovelyd...@mailmetrash.com changed:

   What|Removed |Added

 CC||lovelyd...@mailmetrash.com


--- Comment #3 from SomeDude lovelyd...@mailmetrash.com 2012-04-24 00:49:12 
PDT ---
Run with 2.059 Win32:

PS E:\DigitalMars\dmd2\samples rdmd bug
main done
intermediate done
intermediate2 done
intermediate3 done
0 foo
1 foo
2 foo
3 foo
4 foo
PS E:\DigitalMars\dmd2\samples

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 6116] May not join spawn()'ed threads

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=6116



--- Comment #4 from Ali Cehreli acehr...@yahoo.com 2012-04-24 06:29:21 PDT ---
Same here: This bug seems to have been fixed by other changes.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

Re: Thread join behaviour

[Russel Winder]

On Mon, 2012-04-16 at 21:03 +0200, Somedude wrote:
[...]
 Did you file a bug report ? If yes, which number ? This is an annoying
 regression in my opinion.

Issue 7919

http://d.puremagic.com/issues/show_bug.cgi?id=7919

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Thread join behaviour

[Somedude]

Le 17/04/2012 08:40, Russel Winder a écrit :
 On Mon, 2012-04-16 at 21:03 +0200, Somedude wrote:
 [...]
 
 Issue 7919
 
 http://d.puremagic.com/issues/show_bug.cgi?id=7919
 
Thanks.

Re: Thread join behaviour

[Russel Winder]

On Sun, 2012-04-15 at 23:36 +0200, Somedude wrote:
[...]
 It works here (DMD 2.058 win32), even without function.

It also works for me with 2.058 on x86_64 Linux.  So the conclusion is
that 2.059 is broken. I'll update the issue I set up for this.
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Thread join behaviour

[Somedude]

Le 15/04/2012 20:40, Russel Winder a écrit :
 On Sun, 2012-04-15 at 16:04 +0200, Artur Skawina wrote:
 [...]
 (my old GDC needs the explicit function, no idea if newer
 frontends still require that)
 
 OK, works for me with GDC as well, DMD is broken! I'll file a bug
 report.
 

Did you file a bug report ? If yes, which number ? This is an annoying
regression in my opinion.

Re: Thread join behaviour

[Russel Winder]

On Sat, 2012-04-14 at 23:25 +0200, Artur Skawina wrote:
[...]
 
 'threads' is a (lazy) range; 
 
auto threads = array(map ! ( ( int a ) {
void delegate ( ) f ( ) {
  return delegate ( ) { writeln ( a ) ; } ; 
}
return new Thread ( f )  ;
  } ) ( iota ( 10 ) )) ;
 

Sadly this is not going to work:


/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/traits.d(1482):
 Error: void does not have a default initializer
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/traits.d(1493):
 Error: template instance 
std.traits.hasIndirections!(Thread).Impl!(void[168LU]) error instantiating
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/array.d(143):
instantiated from here: hasIndirections!(Thread)
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/array.d(143):
 Error: template instance std.traits.hasIndirections!(Thread) error 
instantiating
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/array.d(243):
 Error: template instance std.array.blockAttribute!(Thread) error instantiating
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/array.d(194):
instantiated from here: arrayAllocImpl!(false,Thread[],uint)
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/array.d(42):
instantiated from here: uninitializedArray!(Thread[],uint)
./initializingWithAMap.d(9):instantiated from here: array!(Result)
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/array.d(194):
 Error: template instance std.array.arrayAllocImpl!(false,Thread[],uint) error 
instantiating
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/array.d(42):
instantiated from here: uninitializedArray!(Thread[],uint)
./initializingWithAMap.d(9):instantiated from here: array!(Result)
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/array.d(42):
 Error: template instance std.array.uninitializedArray!(Thread[],uint) error 
instantiating
./initializingWithAMap.d(9):instantiated from here: array!(Result)
./initializingWithAMap.d(9): Error: template instance std.array.array!(Result) 
error instantiating


-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Thread join behaviour

[Russel Winder]

On Sat, 2012-04-14 at 17:10 -0400, Matt Soucy wrote:
[...]
 If you merge the two foreach loops into one, doing t.start();t.join(); 
 it doesn't have this issue. Also, when I run your code repeatedly the 
 number of successful numbers printed changes a lot.
 I'm assuming that you're trying to join a thread that already exited...

This matches with Artur's comment about laziness/strictness, but doing
the above is only useful for experimentation, it cannot be a final
solution since it enforces serialization of thread execution.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Thread join behaviour

[Russel Winder]

On Sat, 2012-04-14 at 23:27 +0200, Somedude wrote:
[...]
 This works:
 
 int main ( immutable string[] args ) {
 
   auto threadgroup = new ThreadGroup();
 
   void delegate ( ) f (int a ) {
 return delegate ( ) { writeln ( a ) ; } ;
   }
 
   for ( int n = 0; n  10; n++ ) {
 threadgroup.create(f(n));
   }
   threadgroup.joinAll( );
   return 0 ;
 }
 
 Threads are tracked by the threadgroup, which knows who can be joined.

Thanks for this, a useful alternative realization.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Thread join behaviour

[Artur Skawina]

On 04/15/12 15:55, Russel Winder wrote:
 On Sat, 2012-04-14 at 23:25 +0200, Artur Skawina wrote:
 [...]

 'threads' is a (lazy) range; 

auto threads = array(map ! ( ( int a ) {
void delegate ( ) f ( ) {
  return delegate ( ) { writeln ( a ) ; } ; 
}
return new Thread ( f )  ;
  } ) ( iota ( 10 ) )) ;

 
 Sadly this is not going to work:

works here, when written as

   auto threads = array(map ! ( function ( int a ) {
   void delegate ( ) f ( ) {
 return delegate ( ) { writeln ( a ) ; } ; 
   }
   return new Thread ( f )  ;
 } ) ( iota ( 10 ) )) ;

(my old GDC needs the explicit function, no idea if newer
frontends still require that)

artur

Re: Thread join behaviour

[Russel Winder]

On Sun, 2012-04-15 at 16:04 +0200, Artur Skawina wrote:
[...]
 (my old GDC needs the explicit function, no idea if newer
 frontends still require that)

OK, works for me with GDC as well, DMD is broken! I'll file a bug
report.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Thread join behaviour

[Somedude]

Le 15/04/2012 20:40, Russel Winder a écrit :
 On Sun, 2012-04-15 at 16:04 +0200, Artur Skawina wrote:
 [...]
 (my old GDC needs the explicit function, no idea if newer
 frontends still require that)
 
 OK, works for me with GDC as well, DMD is broken! I'll file a bug
 report.
 

It works here (DMD 2.058 win32), even without function.

Thread join behaviour

[Russel Winder]

I thought the following would terminate gracefully having printed 0..9
in some (random) order:

#! /usr/bin/env rdmd

import std.algorithm ;
import std.range ;
import std.stdio ;
import core.thread ;

int main ( immutable string[] args ) {
  auto threads = map ! ( ( int a ) {
  void delegate ( ) f ( ) {
return delegate ( ) { writeln ( a ) ; } ; 
  }
  return new Thread ( f )  ;
} ) ( iota ( 10 ) ) ;
  foreach ( t ; threads ) { t.start ( ) ; }
  foreach ( t ; threads ) { t.join ( ) ; }
  return 0 ;
}

However, this does not happen, at least with 2.059 on Linux as per
Debian Unstable.  Instead I get:

1
2
4
5
8
3
7
6
9
0
core.thread.ThreadException@src/core/thread.d(906): Unable to join 
thread


/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(_Dmain+0x83)
 [0x425edb]

/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
 (C) int rt.dmain2.main(int, char**).void runMain()+0x17) [0x429bab]

/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
 (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate())+0x23) 
[0x42952b]

/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
 (C) int rt.dmain2.main(int, char**).void runAll()+0x3d) [0x429bf9]

/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
 (C) int rt.dmain2.main(int, char**).void tryExec(scope void delegate())+0x23) 
[0x42952b]

/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(main+0xd3)
 [0x4294c3]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f1ed17f8ead]


I think I must be having a dumb moment as my reaction continues to be
WTF.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Thread join behaviour

[Alex Rønne Petersen]

On 14-04-2012 18:04, Russel Winder wrote:

I thought the following would terminate gracefully having printed 0..9
in some (random) order:

 #! /usr/bin/env rdmd

 import std.algorithm ;
 import std.range ;
 import std.stdio ;
 import core.thread ;

 int main ( immutable string[] args ) {
   auto threads = map ! ( ( int a ) {
   void delegate ( ) f ( ) {
 return delegate ( ) { writeln ( a ) ; } ;
   }
   return new Thread ( f )  ;
 } ) ( iota ( 10 ) ) ;
   foreach ( t ; threads ) { t.start ( ) ; }
   foreach ( t ; threads ) { t.join ( ) ; }
   return 0 ;
 }

However, this does not happen, at least with 2.059 on Linux as per
Debian Unstable.  Instead I get:

 1
 2
 4
 5
 8
 3
 7
 6
 9
 0
 core.thread.ThreadException@src/core/thread.d(906): Unable to join 
thread
 
 
/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(_Dmain+0x83)
 [0x425edb]
 
/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
 (C) int rt.dmain2..main(int, char**).void runMain()+0x17) [0x429bab]
 
/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
 (C) int rt.dmain2..main(int, char**).void tryExec(scope void delegate())+0x23) 
[0x42952b]
 
/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
 (C) int rt.dmain2..main(int, char**).void runAll()+0x3d) [0x429bf9]
 
/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
 (C) int rt.dmain2..main(int, char**).void tryExec(scope void delegate())+0x23) 
[0x42952b]
 
/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(main+0xd3)
 [0x4294c3]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) 
[0x7f1ed17f8ead]
 

I think I must be having a dumb moment as my reaction continues to be
WTF.



http://www.kernel.org/doc/man-pages/online/pages/man3/pthread_join.3.html#ERRORS

We can rule out these:

EDEADLK: Can't happen with your code.
EINVAL (second case): No other thread is trying to join.
ESRCH: Shouldn't happen since druntime registers threads with libpthread.

So, the first case of EINVAL (thread is not a joinable thread) must be 
the cause. I have no clue *why* though...


--
- Alex

Re: Thread join behaviour

[Matt Soucy]

On 04/14/2012 04:56 PM, Alex Rønne Petersen wrote:

On 14-04-2012 18:04, Russel Winder wrote:

I thought the following would terminate gracefully having printed 0..9
in some (random) order:

#! /usr/bin/env rdmd

import std.algorithm ;
import std.range ;
import std.stdio ;
import core.thread ;

int main ( immutable string[] args ) {
auto threads = map ! ( ( int a ) {
void delegate ( ) f ( ) {
return delegate ( ) { writeln ( a ) ; } ;
}
return new Thread ( f ) ;
} ) ( iota ( 10 ) ) ;
foreach ( t ; threads ) { t.start ( ) ; }
foreach ( t ; threads ) { t.join ( ) ; }
return 0 ;
}

However, this does not happen, at least with 2.059 on Linux as per
Debian Unstable. Instead I get:

1
2
4
5
8
3
7
6
9
0
core.thread.ThreadException@src/core/thread.d(906): Unable to join thread

/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(_Dmain+0x83)
[0x425edb]
/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
(C) int rt.dmain2..main(int, char**).void runMain()+0x17) [0x429bab]
/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
(C) int rt.dmain2..main(int, char**).void tryExec(scope void
delegate())+0x23) [0x42952b]
/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
(C) int rt.dmain2..main(int, char**).void runAll()+0x3d) [0x429bf9]
/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
(C) int rt.dmain2..main(int, char**).void tryExec(scope void
delegate())+0x23) [0x42952b]
/tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(main+0xd3)
[0x4294c3]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f1ed17f8ead]


I think I must be having a dumb moment as my reaction continues to be
WTF.



http://www.kernel.org/doc/man-pages/online/pages/man3/pthread_join.3.html#ERRORS


We can rule out these:

EDEADLK: Can't happen with your code.
EINVAL (second case): No other thread is trying to join.
ESRCH: Shouldn't happen since druntime registers threads with libpthread.

So, the first case of EINVAL (thread is not a joinable thread) must be
the cause. I have no clue *why* though...

If you merge the two foreach loops into one, doing t.start();t.join(); 
it doesn't have this issue. Also, when I run your code repeatedly the 
number of successful numbers printed changes a lot.

I'm assuming that you're trying to join a thread that already exited...
-Matt

Re: Thread join behaviour

[Artur Skawina]

On 04/14/12 18:04, Russel Winder wrote:
 I thought the following would terminate gracefully having printed 0..9
 in some (random) order:
 
 #! /usr/bin/env rdmd
 
 import std.algorithm ;
 import std.range ;
 import std.stdio ;
 import core.thread ;
 
 int main ( immutable string[] args ) {
   auto threads = map ! ( ( int a ) {
   void delegate ( ) f ( ) {
 return delegate ( ) { writeln ( a ) ; } ; 
   }
   return new Thread ( f )  ;
 } ) ( iota ( 10 ) ) ;
   foreach ( t ; threads ) { t.start ( ) ; }
   foreach ( t ; threads ) { t.join ( ) ; }
   return 0 ;
 }
 
 However, this does not happen, at least with 2.059 on Linux as per
 Debian Unstable.  Instead I get:
 
 1
 2
 4
 5
 8
 3
 7
 6
 9
 0
 core.thread.ThreadException@src/core/thread.d(906): Unable to join 
 thread
 
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(_Dmain+0x83)
  [0x425edb]
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
  (C) int rt.dmain2.main(int, char**).void runMain()+0x17) [0x429bab]
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
  (C) int rt.dmain2.main(int, char**).void tryExec(scope void 
 delegate())+0x23) [0x42952b]
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
  (C) int rt.dmain2.main(int, char**).void runAll()+0x3d) [0x429bf9]
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
  (C) int rt.dmain2.main(int, char**).void tryExec(scope void 
 delegate())+0x23) [0x42952b]
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(main+0xd3)
  [0x4294c3]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) 
 [0x7f1ed17f8ead]
 
 
 I think I must be having a dumb moment as my reaction continues to be
 WTF.

'threads' is a (lazy) range; 

   auto threads = array(map ! ( ( int a ) {
   void delegate ( ) f ( ) {
 return delegate ( ) { writeln ( a ) ; } ; 
   }
   return new Thread ( f )  ;
 } ) ( iota ( 10 ) )) ;

artur

Re: Thread join behaviour

[Somedude]

Le 14/04/2012 18:04, Russel Winder a écrit :
 I thought the following would terminate gracefully having printed 0..9
 in some (random) order:
 
 #! /usr/bin/env rdmd
 
 import std.algorithm ;
 import std.range ;
 import std.stdio ;
 import core.thread ;
 
 int main ( immutable string[] args ) {
   auto threads = map ! ( ( int a ) {
   void delegate ( ) f ( ) {
 return delegate ( ) { writeln ( a ) ; } ; 
   }
   return new Thread ( f )  ;
 } ) ( iota ( 10 ) ) ;
   foreach ( t ; threads ) { t.start ( ) ; }
   foreach ( t ; threads ) { t.join ( ) ; }
   return 0 ;
 }
 
 However, this does not happen, at least with 2.059 on Linux as per
 Debian Unstable.  Instead I get:
 
 1
 2
 4
 5
 8
 3
 7
 6
 9
 0
 core.thread.ThreadException@src/core/thread.d(906): Unable to join 
 thread
 
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(_Dmain+0x83)
  [0x425edb]
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
  (C) int rt.dmain2.main(int, char**).void runMain()+0x17) [0x429bab]
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
  (C) int rt.dmain2.main(int, char**).void tryExec(scope void 
 delegate())+0x23) [0x42952b]
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
  (C) int rt.dmain2.main(int, char**).void runAll()+0x3d) [0x429bf9]
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(extern
  (C) int rt.dmain2.main(int, char**).void tryExec(scope void 
 delegate())+0x23) [0x42952b]
 
 /tmp/.rdmd-1000/home/users/russel/Progs/OddsByLanguage/D/Odds/initializingWithAMap.d.9532BBED12C814F25F173A9AEAB96D0D(main+0xd3)
  [0x4294c3]
 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) 
 [0x7f1ed17f8ead]
 
 
 I think I must be having a dumb moment as my reaction continues to be
 WTF.
 

This works:

int main ( immutable string[] args ) {

  auto threadgroup = new ThreadGroup();

  void delegate ( ) f (int a ) {
return delegate ( ) { writeln ( a ) ; } ;
  }

  for ( int n = 0; n  10; n++ ) {
threadgroup.create(f(n));
  }
  threadgroup.joinAll( );
  return 0 ;
}

Threads are tracked by the threadgroup, which knows who can be joined.

[Issue 6116] May not join spawn()'ed threads

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=6116


Sean Kelly s...@invisibleduck.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||s...@invisibleduck.org


--- Comment #2 from Sean Kelly s...@invisibleduck.org 2011-07-26 22:53:47 PDT 
---
What's likely happening is that the app is terminating before the new threads
actually start, so they aren't marked isRunning when the wait loop occurs.  The
fix for this will likely be to add a status field where a thread may be marked
as ready, starting, running, and terminated.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

Re: Immutable separator to join() doesn't work

[Jonathan M Davis]

On Tuesday 12 July 2011 15:46:41 Daniel Murphy wrote:
 Jonathan M Davis jmdavisp...@gmx.com wrote in message
 news:mailman.1552.1310429761.14074.digitalmar...@puremagic.com...
 
  This enhancement request would make the situation with immutable and
  const arrays so that they're much more in line with mutable container
  types and static arrays:
  
  http://d.puremagic.com/issues/show_bug.cgi?id=6289
  
  - Jonathan M Davis
 
 WAIT WHAT?  That doesn't work?!?

Nope. It works for static arrays but not for const or immutable arrays. Try 
it. It'll fail. I don't know _why_ it doesn't work, but it doesn't. If it did, 
this would be a much smaller issue. It would be nice if templates were 
improved such that they instantiated range-based functions in a manner which 
worked for static arrays and const or immutable arrays, but if you could solve 
the problem by slicing a const or immutable array, it would make the situation 
far less problematic.

- Jonathan M Davis

Re: Immutable separator to join() doesn't work

[Daniel Murphy]

Jonathan M Davis jmdavisp...@gmx.com wrote in message 
news:mailman.1554.1310450510.14074.digitalmar...@puremagic.com...
 Nope. It works for static arrays but not for const or immutable arrays. 
 Try
 it. It'll fail. I don't know _why_ it doesn't work, but it doesn't. If it 
 did,
 this would be a much smaller issue. It would be nice if templates were
 improved such that they instantiated range-based functions in a manner 
 which
 worked for static arrays and const or immutable arrays, but if you could 
 solve
 the problem by slicing a const or immutable array, it would make the 
 situation
 far less problematic.

 - Jonathan M Davis

Yeah, looking at the implementation and the test cases that rely on this, it 
seems to have been done to allow slicing typedefs to yeild the same type.  I 
really doubt this is something we need to support any more.
Every time this issue came up, I've always assumed this was how it worked!
Honestly, template deduction with implicit conversions is very unlikely to 
ever happen.  While it looks nice for one parameter, it quickly turns into a 
huge mess for multiple parameters.

There is a fairly easy workaround that could be used throughout phobos:
Accept T when isXXXRange!T || isXXXRange!(T[]), and use a static if to slice 
it when necessary.  This would solve the problem for containers, static 
arrays, immutable arrays, and other immutable ranges.