• Bartosz Milewski <bartosz-nospam relisoft.com> Oct 13 2009
• Michel Fortin <michel.fortin michelf.com> Oct 13 2009
• bearophile <bearophileHUGS lycos.com> Oct 14 2009
• Jeremie Pelletier <jeremiep gmail.com> Oct 14 2009
• Jeremie Pelletier <jeremiep gmail.com> Oct 14 2009
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Oct 14 2009
• Nick B <nickB gmail.com> Oct 14 2009
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Oct 14 2009
• Nick B <nickB gmail.com> Oct 14 2009
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Oct 14 2009
• Bartosz Milewski <bartosz-nospam relisoft.com> Oct 14 2009
• Don <nospam nospam.com> Oct 14 2009
• Nick B <nickB gmail.com> Oct 14 2009
• Bartosz Milewski <bartosz-nospam relisoft.com> Oct 14 2009
• Nick B <nickB gmail.com> Oct 14 2009
• Nick B <nickB gmail.com> Oct 15 2009
• Don <nospam nospam.com> Oct 20 2009
• Nick B <nickB gmail.com> Oct 20 2009
• Don <nospam nospam.com> Oct 21 2009
• Nick B <nickB gmail.com> Oct 21 2009
• Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Oct 22 2009
• Nick B <"nick_NOSPAM_.barbalich" gmail.com> Oct 27 2009
• Don <nospam nospam.com> Oct 27 2009
• Nick B <"nick_NOSPAM_.barbalich" gmail.com> Oct 27 2009
• bearophile <bearophileHUGS lycos.com> Oct 27 2009
• "Denis Koroskin" <2korden gmail.com> Oct 22 2009
• "Steven Schveighoffer" <schveiguy yahoo.com> Oct 22 2009
• "Adam D. Ruppe" <destructionator gmail.com> Oct 14 2009
• Leandro Lucarella <llucax gmail.com> Oct 22 2009
• Leandro Lucarella <llucax gmail.com> Oct 20 2009
• Leandro Lucarella <llucax gmail.com> Oct 21 2009

Bartosz Milewski <bartosz-nospam relisoft.com> writes:

Nick B Wrote:

 Nick B wrote:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Unfortunately, Bartosz has declined to contribute.<


 I have read a good amount of his interesting blog posts, he has shown
 me many things I didn't know about. And he was very happy about the
 idea of helping D concurrency. Do you know why he has changed his
 mind regarding this? Maybe because Walter has refused the
 uniqueness/lend ideas?


 You may want to email Bartosz and ask him.

 Andrei


 I will ask him, via his blog, and then will post the link.
 
 Nick B.


 here it is.
 
 http://bartoszmilewski.wordpress.com/2009/09/22/ownership-systems-against-data-races/#comment-922
 
 Nick B.


It's good to know that my ideas are still circulating in the D community.
Thanks, guys! 

Since I'm now put on the spot, I have to explain my recent detachment from D.

I didn't so much "decline to contribute" as hit a wall. I'm a bit of a
perfectionist and it's hard for me to subscribe to the "good enough" philosophy
(as long as it's better that C++, it's fine for D). My impression is that, as
the release of D2 and the publication of Andrei's book are nearing, this
attitude is gaining ground. I try to fight this attitude but it's an uphill
battle. Or, as Andrei puts it, I start whining and give up ;-). 

Particular issues that bother me are:

The semantics of "shared." I can live with postponing the implementation of the
race-free type system, but not with the compiler inserting barriers around all
shared reads and writes, even inside synchronized sections. 

The C++-derived template metaprogramming mess. Especially when C++0x provides
better support for variadic templates than D (see my upcoming blog). I fought
successfully for non-functional approach to string mixins. The same is needed
for more general templates. In my opinion, there should not be any part of the
language that is understandable only by seasoned library writers. 

The "better than Java" aspect of D ignores the latest development in Java. In
particular the work on non-null pointers and the use of annotations for
type-system extensions. Annotations are being added to D as we speak because it
finally became obvious that no amount of cleverness can make object properties
work without additional syntax. So the patching begins, without a clear vision
of the role of annotation in future D.

As far as my thread work went, I had an almost working implementation of spawn,
except for a nasty compiler bug which resisted all efforts to reduce it to a
simple test case. Threads also required some clever work with templates
(testing arguments to "spawn" for sharing violations). I implemented typelist.d
in Phobos to make it easier, and learned how inflexible D templates were. At
least they are better than C++, or are they?

Michel Fortin <michel.fortin michelf.com> writes:

On 2009-10-13 18:26:04 -0400, Bartosz Milewski 
<bartosz-nospam relisoft.com> said:

 I didn't so much "decline to contribute" as hit a wall. I'm a bit of a 
 perfectionist and it's hard for me to subscribe to the "good enough" 
 philosophy (as long as it's better that C++, it's fine for D). My 
 impression is that, as the release of D2 and the publication of 
 Andrei's book are nearing, this attitude is gaining ground. I try to 
 fight this attitude but it's an uphill battle. Or, as Andrei puts it, I 
 start whining and give up ;-).


I don't like that attitude either. I'd rather remove completely an 
unfinished feature than leave it there half-done. If the main feature 
of D2 is a new concurrency model, then leaving things in the state they 
are now isn't going to impress much.


 The semantics of "shared." I can live with postponing the 
 implementation of the race-free type system, but not with the compiler 
 inserting barriers around all shared reads and writes, even inside 
 synchronized sections.


I hadn't thought about that, but it's somewhat ridiculous. On my part 
I'm more preoccupied by the absence of lent semantics as it goes much 
deeper than concurrency: you need it to implement proper invariant 
constructors and unique references.


 The C++-derived template metaprogramming mess. Especially when C++0x 
 provides better support for variadic templates than D (see my upcoming 
 blog). I fought successfully for non-functional approach to string 
 mixins. The same is needed for more general templates. In my opinion, 
 there should not be any part of the language that is understandable 
 only by seasoned library writers.


I'm quite eager to read about that.


 The "better than Java" aspect of D ignores the latest development in 
 Java. In particular the work on non-null pointers and the use of 
 annotations for type-system extensions. Annotations are being added to 
 D as we speak because it finally became obvious that no amount of 
 cleverness can make object properties work without additional syntax. 
 So the patching begins, without a clear vision of the role of 
 annotation in future D.


I'm not even sure what convinced Walter to put annotations in and what 
they're supposed to be capable of. I hope it's not just a new way to 
create keywords without them really being keywords.


 As far as my thread work went, I had an almost working implementation 
 of spawn, except for a nasty compiler bug which resisted all efforts to 
 reduce it to a simple test case. Threads also required some clever work 
 with templates (testing arguments to "spawn" for sharing violations). I 
 implemented typelist.d in Phobos to make it easier, and learned how 
 inflexible D templates were. At least they are better than C++, or are 
 they?


I'm not that satisfied with D templates either. You can use them in 
mixins to achieve pretty amazing things, but I've been hindered by the 
visibility rules with non-mixin templates and how templates with alias 
arguments are difficult to instantiate in certain contexts.

If it were me in charge of the D2 project, given the approaching 
deadline, I'd scrap the new concurrency model completely (including 
immutable, unless we are given a way to write safe constructor for it) 
and focus on everything else. In my view, that's better than leave it 
in the state it is now. (Note that I'm speaking of the model at the 
compiler level, creating new library code is a perfectly fine idea.)


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

bearophile <bearophileHUGS lycos.com> writes:

Bartosz Milewski:

It's good to know that my ideas are still circulating in the D community.
Thanks, guys!<


They will keep circulating! And there's not just D in computer science, future
computer languages may use your ideas. Someday I'll design my own C-like
language, simpler (and more limited in scope) than D ;-)


Since I'm now put on the spot, I have to explain my recent detachment from D.<


This makes me (and surely many other persons here) a little sad. 

D is an engineering project, and it's not small. And the first thing to learn
about all sizeable real-world engineering projects (like the creation of a
large bridge, or many other things) is that they are first of all politics.
They are not the result of rationality, even if often some rationality is
required. All large engineering project come out of a large amount of
compromises. If you pretend to see one of such systems to come out of
rationality alone, you will never see a real one. 

So every time you have to fight for the rationality to prevail, and you have to
be ready to accept some compromises. It's life.


it's hard for me to subscribe to the "good enough" philosophy (as long as it's
better that C++, it's fine for D).<


D language is largely grown, and not designed. D is not Scala or Haskell. I
think there is not enough brain mass in this group to design rationally a
C++-class language. Probably there's not even brain mass to design a
Python-class language. D2 will surely have a big amount of design mistakes,
every one here can list you some of them. But one of the best qualities of
Walter is that he's not frozen, he sometimes seems to move very slowly, but he
never stops moving, and usually he eventually sees the light (and when this
happens it's usually a small surprise for everyone else, like the show of a
rabbit pulled out of a hat). So I think some of the design mistakes of D2 will
be fixed in D3 :-)


My impression is that, as the release of D2 and the publication of Andrei's
book are nearing, this attitude is gaining ground. I try to fight this attitude
but it's an uphill battle. Or, as Andrei puts it, I start whining and give up
;-).<


Andrei's book comes too much early, forcing rhythms that I think aren't good
for D2. On the other hand no software is ever finished, it's just abandoned.
And you must not think of D2 as the finished product :-) You may even think of
D2 as just a bridge toward D3 :-) D2 is probably just an experiment, to
experimentally see what design ideas are good and what to throw away and
redesign. And such things are slow. So you may want to come back in few years,
to try to improve the concurrency design of D3 :-)


The semantics of "shared." I can live with postponing the implementation of the
race-free type system, but not with the compiler inserting barriers around all
shared reads and writes, even inside synchronized sections.<


This is a topic that can be discussed. If enough people think this is a
problem, then eventually Walter may change his mind, or he may design something
better, etc. If no one discussed problems they can't be fixed/improved. I know
that discussing things and accepting compromises is a pain, but it's an
inevitable pain. Rationality alone usually never wins, you need politics too.


The C++-derived template metaprogramming mess. Especially when C++0x provides
better support for variadic templates than D (see my upcoming blog). I fought
successfully for non-functional approach to string mixins. The same is needed
for more general templates. In my opinion, there should not be any part of the
language that is understandable only by seasoned library writers.<


Again, this seems a small piece of D2, so it may be fixed if enough people
think this is bad. You can explain what do you want to change here, and people
will see and think. Eventually it may even be fixed.


The "better than Java" aspect of D ignores the latest development in Java. In
particular the work on non-null pointers<


We have discussed weeks about nonnull references in D (and I have even
discussed about nonnull pointers too), I have done my best. A good percentage
of people have said that they like to try this idea. Walter in the end was not
interested (I think). But maybe in future the situation will change. There's
always hope on this. At the end I have seen no one say "This is a totally wrong
idea and will never see the light in D".


and the use of annotations for type-system extensions. Annotations are being
added to D as we speak because it finally became obvious that no amount of
cleverness can make object properties work without additional syntax. So the
patching begins, without a clear vision of the role of annotation in future D.<


Annotations in D are just an embryo, and I think they come from no design yet,
they are just a bit copied from Java. If you have a vision for their role in D,
then it's a very good moment to talk and show such vision. I am sure we will be
interested to listen. It's surely not too much late to design them well.


As far as my thread work went, I had an almost working implementation of spawn,
except for a nasty compiler bug which resisted all efforts to reduce it to a
simple test case. Threads also required some clever work with templates
(testing arguments to "spawn" for sharing violations).<


Walter isn't magic. If some feature is very hard to implement then it may be
better to not add it until a good implementation is actually created.


I implemented typelist.d in Phobos to make it easier, and learned how
inflexible D templates were. At least they are better than C++, or are they?<


D templates are not "better" than C++ ones, they are simpler to use, less
bug-prone, nicer-looking, but I think they are also less flexible. In D there
are many things that are less flexible than similar things in C++ (see for
example operator overloading too), this can be a good thing, a design choice,
because too much flexibility makes a design bug-prone, complex to implement and
harder to use. So you often want less flexibility, even if in hard situations
(like your one) such limits may look bad.

Bye and thank you for all your work so far,
bearophile

Jeremie Pelletier <jeremiep gmail.com> writes:

bearophile wrote:
 Bartosz Milewski:
 
 It's good to know that my ideas are still circulating in the D community.
Thanks, guys!<


 They will keep circulating! And there's not just D in computer science, future
computer languages may use your ideas. Someday I'll design my own C-like
language, simpler (and more limited in scope) than D ;-)
 
 
 Since I'm now put on the spot, I have to explain my recent detachment from D.<


 This makes me (and surely many other persons here) a little sad. 


Same here, I read your blog with much interest and check it almost daily 
for updates, your ideas about concurrency are really inspiring!

I'm also sure many of us here, me included, did our first steps in GUI 
programming years ago by following your tutorial on reliable software.

 D is an engineering project, and it's not small. And the first thing to learn
about all sizeable real-world engineering projects (like the creation of a
large bridge, or many other things) is that they are first of all politics.
They are not the result of rationality, even if often some rationality is
required. All large engineering project come out of a large amount of
compromises. If you pretend to see one of such systems to come out of
rationality alone, you will never see a real one. 
 
 So every time you have to fight for the rationality to prevail, and you have
to be ready to accept some compromises. It's life.


I still have faith that Walter and Andrei can filter out all the ideas 
here no matter how heated up the arguments and come up with a design 
that will be a decent compromise in the requested features and design 
changes.

 it's hard for me to subscribe to the "good enough" philosophy (as long as it's
better that C++, it's fine for D).<


 D language is largely grown, and not designed. D is not Scala or Haskell. I
think there is not enough brain mass in this group to design rationally a
C++-class language. Probably there's not even brain mass to design a
Python-class language. D2 will surely have a big amount of design mistakes,
every one here can list you some of them. But one of the best qualities of
Walter is that he's not frozen, he sometimes seems to move very slowly, but he
never stops moving, and usually he eventually sees the light (and when this
happens it's usually a small surprise for everyone else, like the show of a
rabbit pulled out of a hat). So I think some of the design mistakes of D2 will
be fixed in D3 :-)


The brain mass is there, more than enough too. Its the manpower that 
lacks, we propose way more features than we have manpower to implement 
in time to either release them or properly test them and see if the 
design works as good as wanted.

A lot of us would like to contribute to the compiler and library but 
we're already busy with our daily jobs, maybe Walter needs to hire half 
this newsgroup and build us an office :o)

 My impression is that, as the release of D2 and the publication of Andrei's
book are nearing, this attitude is gaining ground. I try to fight this attitude
but it's an uphill battle. Or, as Andrei puts it, I start whining and give up
;-).<


 Andrei's book comes too much early, forcing rhythms that I think aren't good
for D2. On the other hand no software is ever finished, it's just abandoned.
And you must not think of D2 as the finished product :-) You may even think of
D2 as just a bridge toward D3 :-) D2 is probably just an experiment, to
experimentally see what design ideas are good and what to throw away and
redesign. And such things are slow. So you may want to come back in few years,
to try to improve the concurrency design of D3 :-)


I agree here, while I think Andrei's book is a must for the community to 
grow, it should rush the compiler. I strongly believe D2 needs proper 
shared and lent semantics, or else we're just creating a stepping stone 
for D3, leaving D2 in a state that isn't suited for concurrent model 
implementations in a type-safe manner.

I don't mind however getting the spec ready with the features coming in 
the near future as part of D2 (either in patch releases or minor 
releases, ie 2.1).

 The semantics of "shared." I can live with postponing the implementation of
the race-free type system, but not with the compiler inserting barriers around
all shared reads and writes, even inside synchronized sections.<


 This is a topic that can be discussed. If enough people think this is a
problem, then eventually Walter may change his mind, or he may design something
better, etc. If no one discussed problems they can't be fixed/improved. I know
that discussing things and accepting compromises is a pain, but it's an
inevitable pain. Rationality alone usually never wins, you need politics too.


I brought up this topic a number of time without much success. Shared is 
hard to work with right now without tons of casting. It's also way too 
easy to accidentally write recursive locks with the current synchronized 
model, which is a nice fallback for the code to run, but generates way 
more calls than is actually needed.

If what we need are politics, then the republic of J (aka my ego) 
declares we need shared and lent qualifier in D that are as easy to use 
without a casting mess as immutable and const are, the rest of the 
concurrent details will follow in the many, many library implemented models.

 The C++-derived template metaprogramming mess. Especially when C++0x provides
better support for variadic templates than D (see my upcoming blog). I fought
successfully for non-functional approach to string mixins. The same is needed
for more general templates. In my opinion, there should not be any part of the
language that is understandable only by seasoned library writers.<


 Again, this seems a small piece of D2, so it may be fixed if enough people
think this is bad. You can explain what do you want to change here, and people
will see and think. Eventually it may even be fixed.


I can't wait to read the article, I agree that forcing templates to work 
in a functional way is often counter-intuitive, took me a while to get 
used to it.

 The "better than Java" aspect of D ignores the latest development in Java. In
particular the work on non-null pointers<


 We have discussed weeks about nonnull references in D (and I have even
discussed about nonnull pointers too), I have done my best. A good percentage
of people have said that they like to try this idea. Walter in the end was not
interested (I think). But maybe in future the situation will change. There's
always hope on this. At the end I have seen no one say "This is a totally wrong
idea and will never see the light in D".


We just haven't found an elegant and practical solution to it yet.

 and the use of annotations for type-system extensions. Annotations are being
added to D as we speak because it finally became obvious that no amount of
cleverness can make object properties work without additional syntax. So the
patching begins, without a clear vision of the role of annotation in future D.<


 Annotations in D are just an embryo, and I think they come from no design yet,
they are just a bit copied from Java. If you have a vision for their role in D,
then it's a very good moment to talk and show such vision. I am sure we will be
interested to listen. It's surely not too much late to design them well.
 
 
 As far as my thread work went, I had an almost working implementation of
spawn, except for a nasty compiler bug which resisted all efforts to reduce it
to a simple test case. Threads also required some clever work with templates
(testing arguments to "spawn" for sharing violations).<


 Walter isn't magic. If some feature is very hard to implement then it may be
better to not add it until a good implementation is actually created.


 I implemented typelist.d in Phobos to make it easier, and learned how
inflexible D templates were. At least they are better than C++, or are they?<


 D templates are not "better" than C++ ones, they are simpler to use, less
bug-prone, nicer-looking, but I think they are also less flexible. In D there
are many things that are less flexible than similar things in C++ (see for
example operator overloading too), this can be a good thing, a design choice,
because too much flexibility makes a design bug-prone, complex to implement and
harder to use. So you often want less flexibility, even if in hard situations
(like your one) such limits may look bad.


I partly disagree here, more flexibility is a great thing for a systems 
language, but it doesn't have to be the only way of doing things. Less 
flexibility is often only a good thing in higher level languages.

 Bye and thank you for all your work so far,
 bearophile

Jeremie Pelletier <jeremiep gmail.com> writes:

Jeremie Pelletier wrote:
 I agree here, while I think Andrei's book is a must for the community to 
 grow, it should rush the compiler. I strongly believe D2 needs proper 
 shared and lent semantics, or else we're just creating a stepping stone 
 for D3, leaving D2 in a state that isn't suited for concurrent model 
 implementations in a type-safe manner.


s/should rush/shouldn't rush/

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Jeremie Pelletier wrote:
 Jeremie Pelletier wrote:
 I agree here, while I think Andrei's book is a must for the community 
 to grow, it should rush the compiler. I strongly believe D2 needs 
 proper shared and lent semantics, or else we're just creating a 
 stepping stone for D3, leaving D2 in a state that isn't suited for 
 concurrent model implementations in a type-safe manner.


 s/should rush/shouldn't rush/


For the record, I delayed signing for the book for quite a few months. 
Before I did sign, there was solemn agreement in the D team that we can 
commit. The book is already late by a few months. If the book is trying 
to rush anything, it's doing a lousy job at that.

Andrei

Nick B <nickB gmail.com> writes:

Andrei Alexandrescu wrote:

 
 For the record, I delayed signing for the book for quite a few months. 
 Before I did sign, there was solemn agreement in the D team that we can 
 commit. [snip]
 



Nick B

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Nick B wrote:
 Andrei Alexandrescu wrote:
 
 For the record, I delayed signing for the book for quite a few months. 
 Before I did sign, there was solemn agreement in the D team that we 
 can commit. [snip]


 
 Nick B
 


Commit to delivering the book and the language matching it.

Andrei

Nick B <nickB gmail.com> writes:

Andrei Alexandrescu wrote:




 Nick B


 Commit to delivering the book and the language matching it.
 
 Andrei


To meet a final release of D 2.0 ?

Nick B

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Nick B wrote:
 Andrei Alexandrescu wrote:
 



 Nick B


 Commit to delivering the book and the language matching it.

 Andrei


 To meet a final release of D 2.0 ?
 
 Nick B


Yes, that's the plan. D2 final release begets TDPL, and TDPL describes 
the final release of D2.

Andrei

Bartosz Milewski <bartosz-nospam relisoft.com> writes:

bearophile Wrote:

 
it's hard for me to subscribe to the "good enough" philosophy (as long as it's
better that C++, it's fine for D).<


 D language is largely grown, and not designed. D is not Scala or Haskell. 
 ...
  So I think some of the design mistakes of D2 will be fixed in D3 :-)
 


With every release of D we are narrowing our options. After D2 and TDPL,
backward compatibility will become a major thing, so every ad-hoc feature in D2
will have to be carried over. 

Why is C++ so bad? Not for lack of brainpower. It's because it fell into the
compatibility trap (essentially from day one). 

There are some areas of D, like Andrei's ranges, that are well thought out and
theoretically sound (we hope), but there are also hacks upon hacks that make my
hair stand on end.

Don <nospam nospam.com> writes:

Bartosz Milewski wrote:
 Nick B Wrote:
 
 Nick B wrote:
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Andrei Alexandrescu:

 Unfortunately, Bartosz has declined to contribute.<


 me many things I didn't know about. And he was very happy about the
 idea of helping D concurrency. Do you know why he has changed his
 mind regarding this? Maybe because Walter has refused the
 uniqueness/lend ideas?



 Andrei



 Nick B.



 http://bartoszmilewski.wordpress.com/2009/09/22/ownership-systems-against-data-races/#comment-922

 Nick B.


 It's good to know that my ideas are still circulating in the D community.
Thanks, guys! 
 
 Since I'm now put on the spot, I have to explain my recent detachment from D.
 
 I didn't so much "decline to contribute" as hit a wall. I'm a bit of a
perfectionist and it's hard for me to subscribe to the "good enough" philosophy
(as long as it's better that C++, it's fine for D). My impression is that, as
the release of D2 and the publication of Andrei's book are nearing, this
attitude is gaining ground. I try to fight this attitude but it's an uphill
battle. Or, as Andrei puts it, I start whining and give up ;-). 


Please stay in touch, we will try to win you back...

Of the issues you mention, this one seems the easiest to address:

 As far as my thread work went, I had an almost working implementation of
spawn, except for a nasty compiler bug which resisted all efforts to reduce it
to a simple test case.


Could you give us _any_ kind of test case (even if it's enormous)?

Nick B <nickB gmail.com> writes:

Don wrote:
 Bartosz Milewski wrote:


 [snip]


 Please stay in touch, we will try to win you back...
 
 Of the issues you mention, this one seems the easiest to address:
 
 As far as my thread work went, I had an almost working implementation 
 of spawn, except for a nasty compiler bug which resisted all efforts 
 to reduce it to a simple test case.


 Could you give us _any_ kind of test case (even if it's enormous)?


Bartosz - are you able to provide a test case as requested by Don ?
Then it might be possible, to get this bug fixed.

Nick B.

Bartosz Milewski <bartosz-nospam relisoft.com> writes:

Nick B Wrote:
 
 Could you give us _any_ kind of test case (even if it's enormous)?


 Bartosz - are you able to provide a test case as requested by Don ?
 Then it might be possible, to get this bug fixed.
 
 Nick B.


I can send you the files I have checked out. 

The problem was in core.thread. I tried to implement a struct Tid (thread ID)
with reference-counting semantics and deterministic destruction. It passed all
the tests, but when it was used in one particular place in druntime it produced
incorrect assembly. Even the slightest change made the bug disappear, so I
wasn't able to reproduce it under controlled conditions.

Unfortunately, I have undone some of my changes trying to bypass the bug, so at
the moment I don't even have the buggy version, but it can be reconstructed. We
can discuss it off-line, if you want. Use my email address with -nospam removed.

Nick B <nickB gmail.com> writes:

Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?


 Then it might be possible, to get this bug fixed.

 Nick B.


 I can send you the files I have checked out. 
 
 The problem was in core.thread. I tried to implement a struct Tid (thread ID)
with reference-counting semantics and deterministic destruction. It passed all
the tests, but when it was used in one particular place in druntime it produced
incorrect assembly. Even the slightest change made the bug disappear, so I
wasn't able to reproduce it under controlled conditions.
 
 Unfortunately, I have undone some of my changes trying to bypass the bug, so
at the moment I don't even have the buggy version, but it can be reconstructed.
We can discuss it off-line, if you want. Use my email address with -nospam
removed.


Bartosz

I think that Don is the best person to contact you. I will try to 
contact him.

Nick B

Nick B <nickB gmail.com> writes:

Nick B wrote:
 Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?


 Then it might be possible, to get this bug fixed.

 Nick B.


 I can send you the files I have checked out.
 The problem was in core.thread. I tried to implement a struct Tid 
 (thread ID) with reference-counting semantics and deterministic 
 destruction. It passed all the tests, but when it was used in one 
 particular place in druntime it produced incorrect assembly. Even the 
 slightest change made the bug disappear, so I wasn't able to reproduce 
 it under controlled conditions.

 Unfortunately, I have undone some of my changes trying to bypass the 
 bug, so at the moment I don't even have the buggy version, but it can 
 be reconstructed. We can discuss it off-line, if you want. Use my 
 email address with -nospam removed.


 Bartosz
 
 I think that Don is the best person to contact you. I will try to 
 contact him.
 
 Nick B


Don, are you able to contact Bartosz, re the details of this test case.

Nick B

Don <nospam nospam.com> writes:

Nick B wrote:
 Nick B wrote:
 Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?


 Then it might be possible, to get this bug fixed.

 Nick B.


 I can send you the files I have checked out.
 The problem was in core.thread. I tried to implement a struct Tid 
 (thread ID) with reference-counting semantics and deterministic 
 destruction. It passed all the tests, but when it was used in one 
 particular place in druntime it produced incorrect assembly. Even the 
 slightest change made the bug disappear, so I wasn't able to 
 reproduce it under controlled conditions.

 Unfortunately, I have undone some of my changes trying to bypass the 
 bug, so at the moment I don't even have the buggy version, but it can 
 be reconstructed. We can discuss it off-line, if you want. Use my 
 email address with -nospam removed.


 Bartosz

 I think that Don is the best person to contact you. I will try to 
 contact him.

 Nick B


 Don, are you able to contact Bartosz, re the details of this test case.
 
 Nick B


Bartosz has sent it to me. I can reproduce the error. It's my top 
priority, but it'll take a while -- it's nasty.

Nick B <nickB gmail.com> writes:

Don wrote:


 Don, are you able to contact Bartosz, re the details of this test case.

 Nick B


 Bartosz has sent it to me. I can reproduce the error. It's my top 
 priority, but it'll take a while -- it's nasty.


Don - thanks for filing this. I did try to contact you, via bugzilla 
email (which bounced back)and via Skype,(no reply), without success.

Nick B

Don <nospam nospam.com> writes:

Nick B wrote:
 Don wrote:
 
 
 Don, are you able to contact Bartosz, re the details of this test case.

 Nick B


 Bartosz has sent it to me. I can reproduce the error. It's my top 
 priority, but it'll take a while -- it's nasty.


 Don - thanks for filing this. I did try to contact you, via bugzilla 
 email (which bounced back)and via Skype,(no reply), without success.
 
 Nick B
 


clearly comes from a more innocent age. I once made the mistake of 
submitting a bug to gcc. Although the GCC Bugzilla hides the email in 
the submitter field, the idiots include the real email address in the 
100% useless 'X-Ref' line. Two weeks later, my email address was dead. 
I've never made that mistake again.
I am contactable through my dsource account.

Nick B <nickB gmail.com> writes:

Leandro Lucarella wrote:
 Don, el 21 de octubre a las 09:46 me escribiste:
 
 All my public email addresses are fake. Bugzilla is just spam bait.
 It clearly comes from a more innocent age. I once made the mistake
 of submitting a bug to gcc. Although the GCC Bugzilla hides the
 email in the submitter field, the idiots include the real email
 address in the 100% useless 'X-Ref' line. Two weeks later, my email
 address was dead. I've never made that mistake again.
 I am contactable through my dsource account.


 You don't even use a real account for personal e-mails! That's odd.
 I couldn't reply your private e-mail about changing the title of the
 bugzilla report because the From address were fake.
 


accounts hammered with spam. I could add -nospam to the name, but I am 
unsure how good the spammers are these days to get around this.

Any suggestions/comments, anyone ?

Nick B

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Nick B wrote:
 Leandro Lucarella wrote:
 Don, el 21 de octubre a las 09:46 me escribiste:
 All my public email addresses are fake. Bugzilla is just spam bait.
 It clearly comes from a more innocent age. I once made the mistake
 of submitting a bug to gcc. Although the GCC Bugzilla hides the
 email in the submitter field, the idiots include the real email
 address in the 100% useless 'X-Ref' line. Two weeks later, my email
 address was dead. I've never made that mistake again.
 I am contactable through my dsource account.


 You don't even use a real account for personal e-mails! That's odd.
 I couldn't reply your private e-mail about changing the title of the
 bugzilla report because the From address were fake.


 accounts hammered with spam. I could add -nospam to the name, but I am 
 unsure how good the spammers are these days to get around this.
 
 Any suggestions/comments, anyone ?
 
 Nick B


If you have a domain, my low-tech approach seems to work pretty well.

Andrei

Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:

Don wrote:
 Nick B wrote:
 Nick B wrote:
 Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?


 Then it might be possible, to get this bug fixed.

 Nick B.


 I can send you the files I have checked out.
 The problem was in core.thread. I tried to implement a struct Tid 
 (thread ID) with reference-counting semantics and deterministic 
 destruction. It passed all the tests, but when it was used in one 
 particular place in druntime it produced incorrect assembly. Even 
 the slightest change made the bug disappear, so I wasn't able to 
 reproduce it under controlled conditions.

 Unfortunately, I have undone some of my changes trying to bypass the 
 bug, so at the moment I don't even have the buggy version, but it 
 can be reconstructed. We can discuss it off-line, if you want. Use 
 my email address with -nospam removed.


 Bartosz

 I think that Don is the best person to contact you. I will try to 
 contact him.

 Nick B


 Don, are you able to contact Bartosz, re the details of this test case.

 Nick B


 Bartosz has sent it to me. I can reproduce the error. It's my top 
 priority, but it'll take a while -- it's nasty.


Don - can you advise the Bugzilla number for this ?

thanks
Nick B

Don <nospam nospam.com> writes:

Nick B wrote:
 Don wrote:
 Nick B wrote:
 Nick B wrote:
 Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?


 Then it might be possible, to get this bug fixed.

 Nick B.


 I can send you the files I have checked out.
 The problem was in core.thread. I tried to implement a struct Tid 
 (thread ID) with reference-counting semantics and deterministic 
 destruction. It passed all the tests, but when it was used in one 
 particular place in druntime it produced incorrect assembly. Even 
 the slightest change made the bug disappear, so I wasn't able to 
 reproduce it under controlled conditions.

 Unfortunately, I have undone some of my changes trying to bypass 
 the bug, so at the moment I don't even have the buggy version, but 
 it can be reconstructed. We can discuss it off-line, if you want. 
 Use my email address with -nospam removed.


 Bartosz

 I think that Don is the best person to contact you. I will try to 
 contact him.

 Nick B


 Don, are you able to contact Bartosz, re the details of this test case.

 Nick B


 Bartosz has sent it to me. I can reproduce the error. It's my top 
 priority, but it'll take a while -- it's nasty.


 Don - can you advise the Bugzilla number for this ?
 
 thanks
 Nick B


a compiled DMD with the bug fixed.

Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:

Don wrote:
 Nick B wrote:
 Don wrote:
 Nick B wrote:
 Nick B wrote:
 Bartosz Milewski wrote:
 Nick B Wrote:
 Could you give us _any_ kind of test case (even if it's enormous)?


 Then it might be possible, to get this bug fixed.

 Nick B.


 I can send you the files I have checked out.
 The problem was in core.thread. I tried to implement a struct Tid 
 (thread ID) with reference-counting semantics and deterministic 
 destruction. It passed all the tests, but when it was used in one 
 particular place in druntime it produced incorrect assembly. Even 
 the slightest change made the bug disappear, so I wasn't able to 
 reproduce it under controlled conditions.

 Unfortunately, I have undone some of my changes trying to bypass 
 the bug, so at the moment I don't even have the buggy version, but 
 it can be reconstructed. We can discuss it off-line, if you want. 
 Use my email address with -nospam removed.


 Bartosz

 I think that Don is the best person to contact you. I will try to 
 contact him.

 Nick B


 Don, are you able to contact Bartosz, re the details of this test case.

 Nick B


 Bartosz has sent it to me. I can reproduce the error. It's my top 
 priority, but it'll take a while -- it's nasty.


 Don - can you advise the Bugzilla number for this ?

 thanks
 Nick B


 a compiled DMD with the bug fixed.


Don

Thanks for the quick response.  Hopefully Bartosz will be able to get a 
working implementation of spawn running (see his reply of 13 Oct 2009).

Nick B

bearophile <bearophileHUGS lycos.com> writes:

Don:
 3423. My patch has already been included in the dmd svn, and Bartosz has 
 a compiled DMD with the bug fixed.


You are my third hero :-)
(the first is Richard Feynman).

Bye,
bearophile

"Denis Koroskin" <2korden gmail.com> writes:

On Thu, 22 Oct 2009 17:32:00 +0400, Leandro Lucarella <llucax gmail.com>  
wrote:

 Nick B, el 22 de octubre a las 19:35 me escribiste:
 Leandro Lucarella wrote:
Don, el 21 de octubre a las 09:46 me escribiste:
All my public email addresses are fake. Bugzilla is just spam bait.
It clearly comes from a more innocent age. I once made the mistake
of submitting a bug to gcc. Although the GCC Bugzilla hides the
email in the submitter field, the idiots include the real email
address in the 100% useless 'X-Ref' line. Two weeks later, my email
address was dead. I've never made that mistake again.
I am contactable through my dsource account.


You don't even use a real account for personal e-mails! That's odd.
I couldn't reply your private e-mail about changing the title of the
bugzilla report because the From address were fake.


 gmail accounts hammered with spam. I could add -nospam to the name,
 but I am unsure how good the spammers are these days to get around
 this.

 Any suggestions/comments, anyone ?


 I just use my real e-mail everywhere and let the spammers eat the world's
 BW as they please. I just let my anti-spam (bogofilter and gmail in case
 of the gmail address) to take care of things...


So do I. And as a result I missed a very important message sent to me  
about a week ago (I was classified as a spam for some reason) :(

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 22 Oct 2009 09:32:00 -0400, Leandro Lucarella <llucax gmail.com>  
wrote:

 Nick B, el 22 de octubre a las 19:35 me escribiste:
 Leandro Lucarella wrote:
Don, el 21 de octubre a las 09:46 me escribiste:
All my public email addresses are fake. Bugzilla is just spam bait.
It clearly comes from a more innocent age. I once made the mistake
of submitting a bug to gcc. Although the GCC Bugzilla hides the
email in the submitter field, the idiots include the real email
address in the 100% useless 'X-Ref' line. Two weeks later, my email
address was dead. I've never made that mistake again.
I am contactable through my dsource account.


You don't even use a real account for personal e-mails! That's odd.
I couldn't reply your private e-mail about changing the title of the
bugzilla report because the From address were fake.


 gmail accounts hammered with spam. I could add -nospam to the name,
 but I am unsure how good the spammers are these days to get around
 this.

 Any suggestions/comments, anyone ?


 I just use my real e-mail everywhere and let the spammers eat the world's
 BW as they please. I just let my anti-spam (bogofilter and gmail in case
 of the gmail address) to take care of things...


Been posting on D for over 2 years with my real address.  Haven't seen  
much difference in my spam input (except occasionally when Andrei replies  
directly to me instead of the newsgroup by accident ;) )

-Steve

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Wed, Oct 14, 2009 at 05:56:10PM -0400, Bartosz Milewski wrote:
 The problem was in core.thread. I tried to implement a struct Tid (thread ID)
with reference-counting semantics and deterministic destruction. It passed all
the tests, but when it was used in one particular place in druntime it produced
incorrect assembly. Even the slightest change made the bug disappear, so I
wasn't able to reproduce it under controlled conditions.


Was it by any chance a null this pointer making its way into the ebx register
somehow, thus causing an access violation on Windows seemingly at random?
(My bug didn't happen if I compiled the exact same code on Linux - I figure
 it must be a Windows codegen problem.)

If so, I've been fighting that bug for over two years, similarly unable to
track down a small test case. I haven't put it on bugzilla since I can't
even really prove it exists to an outsider. I just keep hoping that the
next dmd release will magically fix it.

-- 
Adam D. Ruppe
http://arsdnet.net

Leandro Lucarella <llucax gmail.com> writes:

Nick B, el 22 de octubre a las 19:35 me escribiste:
 Leandro Lucarella wrote:
Don, el 21 de octubre a las 09:46 me escribiste:
All my public email addresses are fake. Bugzilla is just spam bait.
It clearly comes from a more innocent age. I once made the mistake
of submitting a bug to gcc. Although the GCC Bugzilla hides the
email in the submitter field, the idiots include the real email
address in the 100% useless 'X-Ref' line. Two weeks later, my email
address was dead. I've never made that mistake again.
I am contactable through my dsource account.


You don't even use a real account for personal e-mails! That's odd.
I couldn't reply your private e-mail about changing the title of the
bugzilla report because the From address were fake.


 gmail accounts hammered with spam. I could add -nospam to the name,
 but I am unsure how good the spammers are these days to get around
 this.
 
 Any suggestions/comments, anyone ?


I just use my real e-mail everywhere and let the spammers eat the world's
BW as they please. I just let my anti-spam (bogofilter and gmail in case
of the gmail address) to take care of things...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Que importante, entonces en estos días de globalización refregar
nuestras almas, pasarle el lampazo a nuestros corazones para alcanzar
un verdadero estado de babia peperianal.
	-- Peperino Pómoro

Leandro Lucarella <llucax gmail.com> writes:

Don, el 20 de octubre a las 09:00 me escribiste:
Unfortunately, I have undone some of my changes trying to
bypass the bug, so at the moment I don't even have the buggy
version, but it can be reconstructed. We can discuss it
off-line, if you want. Use my email address with -nospam
removed.


Bartosz

I think that Don is the best person to contact you. I will try
to contact him.

Nick B


Don, are you able to contact Bartosz, re the details of this test case.

Nick B


 Bartosz has sent it to me. I can reproduce the error. It's my top
 priority, but it'll take a while -- it's nasty.


Do you have a bugzilla # so we can keep track of it?

Thanks.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
HACIA NEUQUEN: EL JUEVES SALDRA CARAVANA CON PERROS
DESDE CAPITAL EN APOYO AL CACHORRO CONDENADO A MUERTE
	-- Crónica TV

Leandro Lucarella <llucax gmail.com> writes:

Don, el 21 de octubre a las 09:46 me escribiste:
 Nick B wrote:
Don wrote:


Don, are you able to contact Bartosz, re the details of this test case.

Nick B


Bartosz has sent it to me. I can reproduce the error. It's my
top priority, but it'll take a while -- it's nasty.


Don - thanks for filing this. I did try to contact you, via
bugzilla email (which bounced back)and via Skype,(no reply),
without success.

Nick B


 It clearly comes from a more innocent age. I once made the mistake
 of submitting a bug to gcc. Although the GCC Bugzilla hides the
 email in the submitter field, the idiots include the real email
 address in the 100% useless 'X-Ref' line. Two weeks later, my email
 address was dead. I've never made that mistake again.
 I am contactable through my dsource account.


You don't even use a real account for personal e-mails! That's odd.
I couldn't reply your private e-mail about changing the title of the
bugzilla report because the From address were fake.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hoy estuvimos en el museo de antropología, pero yo voy a volver
para estar por lo menos un día ahí adentro... es una locura, como Disney pero
de indigenas
	-- Carla Lucarella (10/2008 contando de su viaje a México)