Re: Safely writing to the same file in parallel foreach loop

[Vijay Nayar]

I think this is what you want around the file access section:

http://dlang.org/statement.html#SynchronizedStatement

 - Vijay

On Wednesday, 14 November 2012 at 16:43:37 UTC, Joseph Rushton 
Wakeling wrote:
I take it there's no more native-to-D way of implementing a 
file lock? :-(

funky property error with assoc array

[Dan]

This fails to compile when accessing as m.pgoo() complaining 
about postblit.

What is wrong with this?

Note: If I alias as array instead of map: alias const(X)[] Map;
it compiles fine.

Thanks
Dan
-
struct X { this(this) {} }
alias const(X)[string] Map;
@property int pgoo(ref Map x) { return 3; }

void main() {
  Map m;
  pgoo(m);
  m.pgoo();
}

funky property error with assoc array

[Dan]

This fails to compile when accessing as m.pgoo() complaining
about postblit.
What is wrong with this?

Note: If I alias as array instead of map: alias const(X)[] Map;
it compiles fine.

Thanks
Dan
-
struct X { this(this) {} }
alias const(X)[string] Map;
@property int pgoo(ref Map x) { return 3; }

void main() {
   Map m;
   pgoo(m);
   m.pgoo();
}

funky property error with assoc array

[Dan]

This fails to compile when accessing as m.pgoo() complaining
about postblit.
What is wrong with this?

Note: If I alias as array instead of map: alias const(X)[] Map;
it compiles fine.

Thanks
Dan
-
struct X { this(this) {} }
alias const(X)[string] Map;
@property int pgoo(ref Map x) { return 3; }

void main() {
   Map m;
   pgoo(m);
   m.pgoo();
}

Re: Safely writing to the same file in parallel foreach loop

[Jonathan M Davis]

On Wednesday, November 14, 2012 18:59:29 Joseph Rushton Wakeling wrote:
 On 11/14/2012 06:49 PM, Vijay Nayar wrote:
  Could you put the file access in a synchronized block?
  
  http://dlang.org/statement.html#SynchronizedStatement
 
 Oh, good call -- seems to work.

I would point out though that given how expensive disk writes are, unless 
you're doing a lot of work within the parallel foreach loop, there's a good 
chance that it would be more efficient to use std.concurrency and pass the 
writes to another thread to do the writing. And the loop itself should still 
be able to be a parallel foreach, so you wouldn't have to change much 
otherwise. But with the synchronized block, you'll probably end up with each 
thread spending a lot of its time waiting on the lock, which will end up 
making the whole thing effectively single-threaded. If the work being done in 
the parallel foreach is small enough, it might even be the case that simply 
making it a normal foreach and ditching the synchronized block would be 
faster. But you'll obviously have to experiment to see what works best with 
whatever you're doing.

- Jonathan M Davis

Some stuff about unittests, contracts, etc

[bearophile]

http://www.reddit.com/r/programming/comments/137kqg/static_typing_contracts_and_unit_tests/#

Bye,
bearophile

[Issue 8863] struct passed to template: cannot access frame pointer

[d-bugmail]

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



--- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-11-14 00:13:59 PST ---
(In reply to comment #2)
 So I'd say it is a bug, and the fault is likely in
 TemplateInstance::hasNestedArgs().

I think that the rule should not be applied to the template type argument, even
if the type is a nested struct.

Let's consider more complicated case.
This code currently compiles successfully.

auto foo() {
struct X { void f(){} } // nested
return X();
}
auto bar() {
struct Y { void g(){} } // nested
return Y();
}

// import std.typecons;
struct Tuple(T...) {
T field;
}
Tuple!T tuple(T...)(T args) {
return typeof(return)(args);
}

void main() {
auto t = tuple(foo(), bar());
}

In above code, the template struct Tuple is instantiated with X and Y.
If the nested struct type argument make the given template instance nested,
Tuple!(X, Y) should have two context pointers, but the code generation will
fail.

Then the change you say will break much existing code. I think it is not mostly
acceptable.

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

[Issue 8863] struct passed to template: cannot access frame pointer

[d-bugmail]

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



--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2012-11-14 
00:31:21 PST ---
The example you gave an example of a bug where a reference to a local is
returned, something entirely different.

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

[Issue 8863] struct passed to template: cannot access frame pointer

[d-bugmail]

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



--- Comment #5 from Kenji Hara k.hara...@gmail.com 2012-11-14 01:07:54 PST ---
(In reply to comment #4)
 The example you gave an example of a bug where a reference to a local is
 returned, something entirely different.

No, they are is related.

My argue is: there is no generic rule which make Tuple!(X, Y) un-nested but
fun!A make nested. TemplateInstance::hasNestedArgs() works on the template
instance, so it cannot know the actual instantiated result is a type (from
Tuple!(X, Y)) or a function (from fun!A). It's time paradox.

To implement your argument, we need much special code to support the case.
It increases the compiler complexity for the much less benefit.

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

[Issue 8991] adding a __ctfe branch with return to a function breaks NRVO

[d-bugmail]

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



--- Comment #3 from Don clugd...@yahoo.com.au 2012-11-14 01:08:32 PST ---
I have no idea why this evil hacky code exists in Phobos, I cannot see how it
can possibly be correct. If it bypasses postblit, surely that's wrong.
If it is faster to use memcpy(), that's a compiler bug.

But anyway, it fails because it detects that two different variables are being
returned.
The workaround is easy:

+T result = void;
  if (__ctfe)
{
*cast(int*)0 = 0; //to demonstrate that no CTFE is attempted
-T result = source;
+result = source;
return result;   //must have broke NRVO
}   

-T result = void;

Now, although it would be possible to hack IfStatement::semantic to check for
__ctfe
 or !__ctfe, and restore fd-nrvo_var, this would fail in cases like:

   if (__ctfe) {
Lnasty:
   T result = source;
   return result;
   }
   if (b)  goto Lnasty;
   T result = void;
   return result;

The problem is, that NRVO is run during the semantic pass, rather than
afterwards.
Personally I think that inlining should happen after the semantic3 pass (it
would make CTFE *much* simpler), and I think NRVO could happen then as well.
Otherwise I'm not sure that this is worth doing anything about. It is still
true that if (__ctfe ) never affects backend code generation, it's just odd
that DMD is doing NRVO in the front-end.

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

[Issue 8863] struct passed to template: cannot access frame pointer

[d-bugmail]

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



--- Comment #6 from Kenji Hara k.hara...@gmail.com 2012-11-14 01:08:01 PST ---
Furthermore, the original code had generated incorrect code silently. This
slight complicated code might cause access violation in 2.060 or earlier.

auto fun(T)(out T ret) {
// ret is incorrectly initialized,
// and has null context pointer
ret.f();// Access Violation
}
void main() {
int val;
struct A {
auto f(){ val = 1; }
}
A a;
fun!A(a);
}

So, I'd like to argue that this issues should be an 'accepts-invalid' bug
rather than a regression.

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

[Issue 8863] struct passed to template: cannot access frame pointer

[d-bugmail]

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



--- Comment #7 from Walter Bright bugzi...@digitalmars.com 2012-11-14 
01:13:28 PST ---
I agree that the original code silently generated wrong code. So this isn't
really a regression.

But I think we can fix it. There is no way to make your example work, because
it is returning a reference to a local. But the original one can work, and
there are many examples of local structs being used as parameters to global
templates, and they work because of the isnested logic.

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

[Issue 9023] New: CTFE: cannot use ~= on an empty AA.

[d-bugmail]

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

   Summary: CTFE: cannot use ~= on an empty AA.
   Product: D
   Version: D1  D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au


--- Comment #0 from Don clugd...@yahoo.com.au 2012-11-14 01:33:48 PST ---
Reported in bug 4019 comment 3 (Mike van Dongen)

enum auto i = test();

int test()
{
string[][string] s;
s[a] ~= anything;

return 6;
}


Error: cannot index null array s

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

[Issue 4019] [CTFE] Adding an item to an empty AA

[d-bugmail]

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


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


--- Comment #4 from Don clugd...@yahoo.com.au 2012-11-14 01:38:11 PST ---
(In reply to comment #3)
 It seems that when I use an 2D AA this problem still occurs.

Your test case is completely different to the original bug, it is a bug in ~=.

Please do not reopen ancient bugs. The *only* time you should open a bug which
was listed as fixed in a previous changelog, is if you find that the test cases
in bug weren't actually fixed in that release.

Moved to bug 9023.

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

[Issue 8936] Throwing results in searching the whole directory tree rooted in current directory

[d-bugmail]

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



--- Comment #5 from Denis Shelomovskij verylonglogin@gmail.com 2012-11-14 
12:49:12 MSK ---
(In reply to comment #4)
 Any idea what file it's looking for?

Launching throw-C-release.exe with code from the second example from
description:

Call stack of main thread
AddressStack  Procedure / arguments
 Called from   Frame
Call stack of main thread
AddressStack  Procedure / arguments
 Called from   Frame
0012D540   7C90D5AA   Includes ntdll.KiFastSystemCallRet   
 ntdll.7C90D5A80012D838
0012D544   7C80EC96   Includes ntdll.7C90D5AA  
 kernel32.7C80EC94 0012D838
0012D83C   7C8138B7   kernel32.FindFirstFileExW
 kernel32.7C8138B2 0012D838
0012DAD0   59C7117B   kernel32.FindFirstFileA  
 dbghelp.59C71175  0012DACC
0012DAD4   0012DE44 FileName = .\Documents and Settings\Denis\Local
Settings\Temp\
0012DAD8   0012DC00 pFindFileData = 0012DC00
0012DF50   59C71636   dbghelp.59C7109F 
 dbghelp.59C71631  0012DF4C
0012E0C4   59C717C6   ? dbghelp.59C7149F   
 dbghelp.59C717C1  0012E0C0
0012E110   59C71839   ? dbghelp.59C716F4   
 dbghelp.59C71834  0012E10C
0012E114   00B27E68 Arg1 = 00B27E68 ASCII throw-C-release.exe
0012E118   00B7FEA0 Arg2 = 00B7FEA0
0012E11C   00B27772 Arg3 = 00B27772 ASCII C:\throw-C-release.exe
0012E120   59C7ABE7 Arg4 = 59C7ABE7
0012E124   00B27748 Arg5 = 00B27748
0012E128    Arg6 = 
0012E130   59C7B424   ? dbghelp.FindExecutableImageEx  
 dbghelp.59C7B41F  0012E12C
0012E134   00B27E68 Arg1 = 00B27E68 ASCII throw-C-release.exe
0012E138   00B7FEA0 Arg2 = 00B7FEA0
0012E13C   00B27772 Arg3 = 00B27772 ASCII C:\throw-C-release.exe
0012E140   59C7ABE7 Arg4 = 59C7ABE7
0012E144   00B27748 Arg5 = 00B27748
0012E174   59C816F7   ? dbghelp.59C7B2D1
same as in comment 3

MSDN about FindExecutableImageEx function:
http://msdn.microsoft.com/ru-ru/library/windows/desktop/ms679343(v=vs.85).aspx

P.S.
Common, OllyDbg if free and easy to use. And probably not the only available
debugger. Everybody can do the same himself.

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

[Issue 8863] struct passed to template: cannot access frame pointer

[d-bugmail]

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



--- Comment #8 from Kenji Hara k.hara...@gmail.com 2012-11-14 02:05:18 PST ---
(In reply to comment #7)
 But I think we can fix it. There is no way to make your example work, because
 it is returning a reference to a local. But the original one can work, and
 there are many examples of local structs being used as parameters to global
 templates, and they work because of the isnested logic.

Since months ago, I have fixed some nested struct and template bugs not to
break existing codes. From the experience, it seems much difficult to *fix*
this issue. If you can implement that without ugly hack, I'd like to see it
before merging to the main trunk.

Could you create a pull request for that?

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

[Issue 7632] [64bit] byValue() for associative arrays doesn't return the correct values

[d-bugmail]

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


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|byValue() for associative   |[64bit] byValue() for
   |arrays doesn't return the   |associative arrays doesn't
   |correct values  |return the correct values
   Severity|minor   |major


--- Comment #11 from Don clugd...@yahoo.com.au 2012-11-14 02:36:19 PST ---
Still valid. Marked as a 64bit wrong-code bug, raised severity.

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

[Issue 8175] aa.c assert(0)

[d-bugmail]

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


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

   Keywords||ice
 Status|NEW |RESOLVED
 Resolution||INVALID


--- Comment #3 from Don clugd...@yahoo.com.au 2012-11-14 02:41:08 PST ---
Almost certainly a bad build. Closing because there is no test case.

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

[Issue 7632] [64bit] byValue() for associative arrays doesn't return the correct values

[d-bugmail]

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


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


--- Comment #12 from Don clugd...@yahoo.com.au 2012-11-14 02:46:21 PST ---
Marking as a duplicate of bug 8583, which is a better bug report.

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

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

[Issue 8583] [64 bit] AA ushort[dchar] byValue range is corrupted on x86_64

[d-bugmail]

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


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 CC||exe...@gmail.com


--- Comment #3 from Don clugd...@yahoo.com.au 2012-11-14 02:46:21 PST ---
*** Issue 7632 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 8596] Indeterministic assertion failure in rehash

[d-bugmail]

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



--- Comment #20 from deadalnix deadal...@gmail.com 2012-11-14 04:40:08 PST ---
(In reply to comment #19)
 Ok, the next step is to compile your app without -g. The reason is because 
 hash
 tables are used in the dwarf debug generation, and I want to see if that one 
 is
 the problem or other uses.

Tested with flags : -m64 -w -debug -unittest (removing the -gc flag I usually
use).

I � successfully � triggered the error as well.

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

[Issue 9019] invariant does not compile/run if class does not define constructor

[d-bugmail]

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


Maxim Fomin ma...@maxim-fomin.ru changed:

   What|Removed |Added

 CC||ma...@maxim-fomin.ru


--- Comment #1 from Maxim Fomin ma...@maxim-fomin.ru 2012-11-14 04:40:52 PST 
---
(In reply to comment #0)
 C has an implicitly generated constructor

Why? It seems there is no constructor in case like this. 

 but the invariant isn't compiled or
 it doesn't run. If you add an explicit empty constructor then it does get
 added.

It is compiled but is not run because there is no ctor. The spec says that
invariant is called when ctor completes but it does not say what happens when
there is no ctor. You actually asking either create dummy ctor for cases like
this or call invariant just after allocating class object which is not
efficient - the first call to public function will abort the application
anyway.

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

[Issue 9024] New: Inferring function argument types from other template parameters

[d-bugmail]

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

   Summary: Inferring function argument types from other template
parameters
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: joseph.wakel...@webdrake.net


--- Comment #0 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 
2012-11-14 05:43:25 PST ---
The attached code most likely ought to be valid according to the spec at
http://dlang.org/template.html (point 2 under Argument Deduction states: If
the type specialization is dependent on a type parameter, the type of that
parameter is set to be the corresponding part of the type argument):

struct Foo(_T)
{
  alias _T T;
}

void func(T)(T foo, T.T x)
{
}

void main()
{
  Foo!int foo;
  func(foo, 3);
}

However, it fails to compile with an error

infer.d(13): Error: undefined identifier T.T
infer.d(13): Error: template infer.func does not match any function template
declaration
infer.d(13): Error: template infer.func(T) cannot deduce template function from
argument types !()(Foo!(int),int)

See discussion thread here:
http://forum.dlang.org/post/mailman.1810.1352724147.5162.digitalmars-d-le...@puremagic.com
http://forum.dlang.org/post/mailman.1812.1352726032.5162.digitalmars-d-le...@puremagic.com
http://forum.dlang.org/post/k7u134$1t35$1...@digitalmars.com

... and also the following bug report where the issue is discussed:
http://d.puremagic.com/issues/show_bug.cgi?id=9004

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

[Issue 9024] Inferring function argument types from other template parameters

[d-bugmail]

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



--- Comment #1 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 
2012-11-14 05:44:26 PST ---
Created an attachment (id=1161)
Minimal source code with example of the issue

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

[Issue 9014] ICE(glue.c) line 1225: with array.front and missing array

[d-bugmail]

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



--- Comment #2 from github-bugzi...@puremagic.com 2012-11-14 06:01:34 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/3c2ddd90bed08abdf064091e9b56d55bc692dde8
fix Issue 9014 - ICE(glue.c) line 1225: with array.front and missing array

UFCS property setter semantic should not gagging errors in e2.

https://github.com/D-Programming-Language/dmd/commit/8b45f5e06a8e3a23aa246dcba966c6f0db28331e
Merge pull request #1286 from 9rnsr/fix9014

Issue 9014 - ICE(glue.c) line 1225: with array.front and missing array

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

[Issue 8991] adding a __ctfe branch with return to a function breaks NRVO

[d-bugmail]

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



--- Comment #4 from Dmitry Olshansky dmitry.o...@gmail.com 2012-11-14 
06:42:57 PST ---
(In reply to comment #3)
I have no idea why this evil hacky code exists in Phobos, I cannot see how it
can possibly be correct. If it bypasses postblit, surely that's wrong.
If it is faster to use memcpy(), that's a compiler bug.

The whole point of move is to avoid extra postblit and turn l-value into an
r-value.
The way to do it seems to be (and very simillar in swap) is to blit T.init into
source and whatever it contained before return as result. 
The source will eventually get destroyed with T.init. 

Thus the postblit is not required and no double destroy of the same object
happens.

While I thought this could work to paint things as r-value:
T move(ref T x ){ return x; }

it will still do a postblit as ref-ed param stays intact elsewhere.

 The workaround is easy:
 
 +T result = void;
   if (__ctfe)
 {
 *cast(int*)0 = 0; //to demonstrate that no CTFE is attempted
 -T result = source;
 +result = source;
 return result;   //must have broke NRVO
 }   
 

That was what I did in the first place. Problem is  - it doesn't work for
structs with immutable fields as after:
T result = void; 
this line:
result = source;
does't compile. 
I wouldn't have noticed this if Phobos unittests haven't failed
while memcpy hacked through any such inconveniences.

In any case I've found a workaround that seems to pass through:
https://github.com/D-Programming-Language/phobos/pull/936

 The problem is, that NRVO is run during the semantic pass, rather than
 afterwards.
 Personally I think that inlining should happen after the semantic3 pass (it
 would make CTFE *much* simpler), and I think NRVO could happen then as well.
 Otherwise I'm not sure that this is worth doing anything about.

Okay let's either close it or turn into an enhancement request for doing
inlining and NRVO after completion of the semantic pass.

 It is still
 true that if (__ctfe ) never affects backend code generation, it's just odd
 that DMD is doing NRVO in the front-end.

Okay that makes it clearer.

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

[Issue 9014] ICE(glue.c) line 1225: with array.front and missing array

[d-bugmail]

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


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Issue 7954] x86_64 Windows fibers do not save nonvolatile XMM registers

[d-bugmail]

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


Manu turkey...@gmail.com changed:

   What|Removed |Added

 CC||turkey...@gmail.com


--- Comment #1 from Manu turkey...@gmail.com 2012-11-14 09:09:52 PST ---
(In reply to comment #0)
 According to MSDN (http://msdn.microsoft.com/en-us/library/9z1stfyw.aspx), the
 XMM6-XMM15 registers are nonvolatile on x64 Windows. The current 
 implementation
 of core.thread.Fiber for this platform does not preserve them.

Are you using the unreleased DMD-win64 (2.061)?
I'm finding it just crashes and doesn't work at all.

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

[Issue 9025] New: core.thread.Fiber seems to crash on Win64

[d-bugmail]

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

   Summary: core.thread.Fiber seems to crash on Win64
   Product: D
   Version: D2
  Platform: x86_64
OS/Version: Windows
Status: NEW
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: turkey...@gmail.com


--- Comment #0 from Manu turkey...@gmail.com 2012-11-14 09:19:15 PST ---
It seems core.thread.Fiber doesn't work under the new DMD for win64.
Crashes on call(), in fiber_switchcontext(), access violation, looks like an
alignment problem, since the pointer is valid.


fiber_switchContext:
07FEE25509E0  pushrbp  
07FEE25509E1  mov rbp,rsp  
07FEE25509E4  pushrbx  
07FEE25509E5  pushr12  
07FEE25509E7  pushr13  
07FEE25509E9  pushr14  
07FEE25509EB  pushr15  
07FEE25509ED  pushqword ptr gs:[fiber_switchContext+15h
(7FEE25509F5h)]  *** CRASH*** +15h? does 'push qword' support reading from
unaligned addresses like that?
07FEE25509F5  pushqword ptr gs:[fiber_switchContext+25h
(7FEE2550A05h)]  
07FEE25509FD  pushqword ptr gs:[fiber_switchContext+35h
(7FEE2550A15h)]  
07FEE2550A05  mov qword ptr [rdi],rsp  
07FEE2550A08  mov rsp,rsi  
07FEE2550A0B  pop qword ptr gs:[fiber_switchContext+43h
(7FEE2550A23h)]  
07FEE2550A13  pop qword ptr gs:[fiber_switchContext+43h
(7FEE2550A23h)]  
07FEE2550A1B  pop qword ptr gs:[fiber_switchContext+43h
(7FEE2550A23h)]  
07FEE2550A23  pop r15  
07FEE2550A25  pop r14  
07FEE2550A27  pop r13  
07FEE2550A29  pop r12  
07FEE2550A2B  pop rbx  
07FEE2550A2C  pop rbp  
07FEE2550A2D  pop rcx  
07FEE2550A2E  jmp rcx

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

[Issue 9025] core.thread.Fiber seems to crash on Win64

[d-bugmail]

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


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

   What|Removed |Added

 CC||bugzi...@digitalmars.com


--- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-11-14 
13:56:02 PST ---
qword means 4 bytes, and you can't push 4 bytes in 64 bit mode. Only 8 bytes.

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

[Issue 8968] std.traits.ParameterIdentifierTuple is undocumented and doesn't work with ref params

[d-bugmail]

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


Ellery Newcomer ellery-newco...@utulsa.edu changed:

   What|Removed |Added

 CC||ellery-newco...@utulsa.edu


--- Comment #1 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-11-14 
17:38:58 PST ---
its documented now

https://github.com/D-Programming-Language/phobos/pull/946

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

[Issue 8968] std.traits.ParameterIdentifierTuple is undocumented and doesn't work with ref params

[d-bugmail]

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


Ellery Newcomer ellery-newco...@utulsa.edu changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #2 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-11-14 
17:57:25 PST ---
and evidently does work with ref int now:

https://github.com/D-Programming-Language/phobos/commit/49cbab43c2bdf5d14d51d869c62e010befa3bcab

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

[Issue 8939] ICE(glue.c) on passing by ref statically initialized const/immutable variable

[d-bugmail]

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


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

   Keywords||pull


--- Comment #2 from Kenji Hara k.hara...@gmail.com 2012-11-14 17:59:05 PST ---
https://github.com/D-Programming-Language/dmd/pull/1288

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

[Issue 8939] ICE(glue.c) on passing by ref statically initialized const/immutable variable

[d-bugmail]

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



--- Comment #3 from github-bugzi...@puremagic.com 2012-11-14 18:46:11 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/7daa39cc3ff563b50004cda86f4cdc1ae76c2888
fix Issue 8939 - ICE(glue.c) on passing by ref statically initialized
const/immutable variable

Don't optimize an argument on ref parameter, even which can interpret at
compile time.

https://github.com/D-Programming-Language/dmd/commit/a1e763cda40722305adb924509dd726af99e9e45
Merge pull request #1288 from 9rnsr/fix8939

Issue 8939 - ICE(glue.c) on passing by ref statically initialized
const/immutable variable

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

[Issue 8936] Throwing results in searching the whole directory tree rooted in current directory

[d-bugmail]

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



--- Comment #7 from Walter Bright bugzi...@digitalmars.com 2012-11-14 
18:50:51 PST ---
(In reply to comment #6)
 It's damn hard to find matching DMD+druntime+phobos versions that compile
 together for that pull so I can't test these out.

Just use the latest versions of everything, but the older version of the stack
trace code.

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

[Issue 8939] ICE(glue.c) on passing by ref statically initialized const/immutable variable

[d-bugmail]

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


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

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


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

[Issue 8996] [ICE](e2ir.c line 768) with bigint main-imported

[d-bugmail]

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


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

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||WORKSFORME


--- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-11-14 
19:33:25 PST ---
It compile fine for me with the latest.

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

[Issue 9026] New: Template mixin identifier as template alias parameter doesn't work

[d-bugmail]

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

   Summary: Template mixin identifier as template alias parameter
doesn't work
   Product: D
   Version: D2
  Platform: All
OS/Version: All
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com


--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-11-14 21:13:35 PST ---
From the digitalmars.d.learn forum:
http://forum.dlang.org/thread/xftbyifuuubxhhsol...@forum.dlang.org

Code:
---
mixin template node() {
static if (is(this == struct))
alias typeof(this)* E;
else
alias typeof(this) E;  //Line5
E prev, next;
}
struct list(alias N) {
N.E head;
N.E tail;
}
class A {
mixin node L1;  //Line13
mixin node L2;  //Line14
}
list!(A.L1) l1;  //Line16
list!(A.L2) l2;  //Line17
---

Output:
---
test.d(5): Error: this is not in a class or struct scope
test.d(5): Error: 'this' is only defined in non-static member functions, not
node!()
test.d(13): Error: mixin test.node!() error instantiating
test.d(16): Error: list!(L1) is used as a type
test.d(5): Error: this is not in a class or struct scope
test.d(5): Error: 'this' is only defined in non-static member functions, not
node!()
test.d(14): Error: mixin test.node!() error instantiating
test.d(17): Error: list!(L2) is used as a type
---

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

[Issue 9026] Template mixin identifier as template alias parameter doesn't work

[d-bugmail]

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


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

   Keywords||pull


--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-11-14 21:19:18 PST ---
https://github.com/D-Programming-Language/dmd/pull/1289

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

[Issue 8688] Qualified indexing type tuple returns wrong result

[d-bugmail]

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


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Issue 8702] tuple(tuple(1)) fails to compile, but tuple(tuple(1), 1) works

[d-bugmail]

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


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Issue 8617] std.typecons.Proxy.opEquals compiles error: undefined identifier 'startsWith'

[d-bugmail]

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


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Issue 8645] ICE: Assertion failed: (0), function totym, file glue.c, line 1150.

[d-bugmail]

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


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Issue 8522] Comparison operator overloading doesn't consider the qualifier of lhs

[d-bugmail]

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


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Issue 8629] UFCS resolution prints fake error

[d-bugmail]

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


Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Issue 8966] ICE(cgcod.c) when passing cfloat argument with indirection

[d-bugmail]

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



--- Comment #1 from github-bugzi...@puremagic.com 2012-11-14 22:08:46 PST ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/10eefc3f5799585d618da90a595d158a22ca5e95
fix Issue 8966 - ICE(cgcod.c) when passing cfloat argument with indirection

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

[Issue 8966] ICE(cgcod.c) when passing cfloat argument with indirection

[d-bugmail]

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


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

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


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

[Issue 6772] Cannot pass cfloat argument type to a function on x86_64

[d-bugmail]

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


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

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||WORKSFORME


--- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-11-14 
23:47:10 PST ---
This is working with the latest.

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

[Issue 8517] ICE(toir.c 178) or stack overflow with recursive alias template

[d-bugmail]

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


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

Version|D2  |D1  D2
Summary|ICE(toir.c 178) |ICE(toir.c 178) or stack
   ||overflow with recursive
   ||alias template


--- Comment #1 from Don clugd...@yahoo.com.au 2012-11-14 23:53:57 PST ---
Actually y!() is the problem, the other bit is just instantiating y.
Also stack overflows on D1 and 2.057.
The reason is, that the FQN of the delegate includes the FQN of the template.
You can see this if you use .mangleof (uncomment the pragma).
Simplified test case:

void y (alias f) () { 
int delegate(int) qq;
//   pragma(msg, qq.mangleof);
y!(qq)();
}

void x1() { int q;y!(q)(); }

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