Nick Sabalausky a@a.a wrote in message
news:ioanmi$82c$1...@digitalmars.com...
Andrej Mitrovic Wrote:
What I meant was that code like this will throw if MyType isn't
defined anywhere:
int main(int x)
{
MyType var;
}
Nick Sabalausky Wrote:
Yea, turns out that grammar just doesn't support using user-defined types
without preceding them with struct, union, or enum. You can see that
here:
Var Decl ::= Mod Type Var Var List ';'
| Type Var Var List ';'
| Mod
Kagamin s...@here.lot wrote in message
news:iod552$rbe$1...@digitalmars.com...
Nick Sabalausky Wrote:
Yea, turns out that grammar just doesn't support using user-defined types
without preceding them with struct, union, or enum. You can see
that
here:
Var Decl ::= Mod Type Var Var
Nick Sabalausky a@a.a wrote in message
news:iod6fn$tch$1...@digitalmars.com...
Kagamin s...@here.lot wrote in message
news:iod552$rbe$1...@digitalmars.com...
As I understand, Type is a type, Var is a variable. There should be
no problem here.
First of all, the name Var up there is
Nick Sabalausky a@a.a wrote in message
news:iobh9o$1d04$1...@digitalmars.com...
Nick Sabalausky a@a.a wrote in message
news:ioanmi$82c$1...@digitalmars.com...
Andrej Mitrovic Wrote:
What I meant was that code like this will throw if MyType isn't
defined anywhere:
int main(int x)
{
On Fri, 15 Apr 2011 23:22:04 -0400, dsimcha dsim...@yahoo.com wrote:
I'm trying to debug an extremely strange bug whose symptoms appear in a
std.parallelism example, though I'm not at all sure the root cause is in
std.parallelism. The bug report is at
Roman Ivanov wrote:
== Quote from Jacob Carlborg (d...@me.com)'s article
On 2011-04-14 18:48, Andrei Alexandrescu wrote:
On 4/14/11 9:03 AM, Steven Schveighoffer wrote:
Sometimes, I worry that my unit tests or asserts aren't running. Every
once in a while, I have to change one to fail to make
On 4/15/2011 8:40 PM, Andrei Alexandrescu wrote:
On 4/15/11 10:22 PM, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear in a
std.parallelism example, though I'm not at all sure the root cause is in
std.parallelism. The bug report is at
On 4/15/11 8:19 PM, Andrej Mitrovic wrote:
[…] My biggest issue is that
I can't modify variables at compile time. I wish there was some
special CTFE int type which is only visible at compile-time and which
we can use however we want. That way I could keep count of things, for
example I could
On 16-apr-11, at 09:41, Walter Bright wrote:
On 4/15/2011 8:40 PM, Andrei Alexandrescu wrote:
On 4/15/11 10:22 PM, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear
in a
std.parallelism example, though I'm not at all sure the root cause
is in
On 16-apr-11, at 05:22, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear
in a std.parallelism example, though I'm not at all sure the root
cause is in std.parallelism. The bug report is at https://github.com/dsimcha/std.parallelism/issues/1
Walter:
Yes, it allows one to break the purity of the function. The alternative is to
use casts (which also breaks the purity) or another compiler switch (which
also
breaks the purity).
A compiler switch to disable purity doesn't break purity. It just turns all
pure functions inside the
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
On 4/15/2011 8:40 PM, Andrei Alexandrescu wrote:
On 4/15/11 10:22 PM, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear in a
std.parallelism example, though I'm not at all sure the root cause
On 30/07/2009 10:12, MIURA Masahiro wrote:
Walter Bright wrote:
How about #d-lang ?
#dpl ?
I just tested those two.
Although noone else uses #d-lang, it seems that twitter.com
doesn't treat it as a hashtag (because it contains a dash?).
#dpl gives a few false positives.
So what do
On 4/15/2011 11:40 PM, Andrei Alexandrescu wrote:
On 4/15/11 10:22 PM, dsimcha wrote:
I'm trying to debug an extremely strange bug whose symptoms appear in a
std.parallelism example, though I'm not at all sure the root cause is in
std.parallelism. The bug report is at
On 4/16/2011 2:09 AM, Robert Jacques wrote:
On Fri, 15 Apr 2011 23:22:04 -0400, dsimcha dsim...@yahoo.com wrote:
I'm trying to debug an extremely strange bug whose symptoms appear in
a std.parallelism example, though I'm not at all sure the root cause
is in std.parallelism. The bug report is
On 4/16/11 9:44 AM, David Wang wrote:
Hi, all,
[snip]
What operating system?
Andrei
Hi, all,
I've download the latest dmd druntime phobos from gitHub.com;
I copied them into a 32bit folder and a 64bit folder; I combined them
separately into 32bit version and 64bit.
1). 32bit for dmd druntime phobos -- passed.
2). 64bit for dmd druntime -- passed; but phobos -- failed.
On 4/16/2011 10:11 AM, dsimcha wrote:
My only concern is whether this non-determinism represents some deep
underlying bug. For a given work unit allocation (work unit allocations
are deterministic and only change when the number of threads changes or
they're changed explicitly), I can't figure
On 4/16/2011 10:55 AM, Andrei Alexandrescu wrote:
On 4/16/11 9:52 AM, dsimcha wrote:
Output:
Rounding mode: 0
0.7853986633972191094
Rounding mode: 0
0.7853986633972437348
I think at this precision the difference may be in random bits. Probably
you don't need to worry about it.
Andrei
On 4/16/11 9:52 AM, dsimcha wrote:
Output:
Rounding mode: 0
0.7853986633972191094
Rounding mode: 0
0.7853986633972437348
I think at this precision the difference may be in random bits. Probably
you don't need to worry about it.
Andrei
== Quote from dsimcha (dsim...@yahoo.com)'s article
On 4/16/2011 10:11 AM, dsimcha wrote:
Output:
Rounding mode: 0
0.7853986633972191094
Rounding mode: 0
0.7853986633972437348
This is not something I can replicate on my workstation.
On 4/16/2011 11:16 AM, Iain Buclaw wrote:
== Quote from dsimcha (dsim...@yahoo.com)'s article
On 4/16/2011 10:11 AM, dsimcha wrote:
Output:
Rounding mode: 0
0.7853986633972191094
Rounding mode: 0
0.7853986633972437348
This is not something I can replicate on my workstation.
Interesting.
== Forward by Andrei Alexandrescu (seewebsiteforem...@erdani.org)
== Posted at 2011/04/16 10:43 to digitalmars.D
On 4/16/11 9:44 AM, David Wang wrote:
Hi, all,
[snip]
What operating system?
Andrei
Hi, Andrei,
I'm using Fedora 14 x86_64.
Best
dsimcha dsim...@yahoo.com wrote in message
news:iocalv$2h58$1...@digitalmars.com...
Output:
Rounding mode: 0
0.7853986633972191094
Rounding mode: 0
0.7853986633972437348
Could be something somewhere is getting truncated from real to double, which
would mean 12 fewer bits of mantisa.
On 4/16/11 9:59 AM, dsimcha wrote:
On 4/16/2011 10:55 AM, Andrei Alexandrescu wrote:
On 4/16/11 9:52 AM, dsimcha wrote:
Output:
Rounding mode: 0
0.7853986633972191094
Rounding mode: 0
0.7853986633972437348
I think at this precision the difference may be in random bits. Probably
you don't
On 4/16/2011 6:41 AM, bearophile wrote:
Yes, it allows one to break the purity of the function. The alternative is
to use casts (which also breaks the purity) or another compiler switch
(which also breaks the purity).
A compiler switch to disable purity doesn't break purity. It just turns all
On 4/16/2011 6:46 AM, Iain Buclaw wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
That's a good thought. FP addition results can differ dramatically depending on
associativity.
And not to forget optimisations too. ;)
The dmd optimizer is careful not to reorder
Could be something somewhere is getting truncated from real to double, which
would mean 12 fewer bits of mantisa. Maybe the FPU is set to lower precision
in one of the threads?
Yes indeed, this is a _Windows_ bug.
I have experienced this in Windows before, the main thread's FPU state register
On 4/16/2011 2:15 PM, Timon Gehr wrote:
Could be something somewhere is getting truncated from real to double, which
would mean 12 fewer bits of mantisa. Maybe the FPU is set to lower precision
in one of the threads?
Yes indeed, this is a _Windows_ bug.
I have experienced this in Windows
On 13/04/2011 15:28, Lars T. Kyllingstad wrote:
We now resume the formal review of David Simcha's std.parallelism
module. Code and documentation can be found here:
https://github.com/dsimcha/std.parallelism/blob/master/parallelism.d
I'm reconsidering the naming of std.parallelism. The name is catchy,
but perhaps too general. std.parallelism currently targets SMP
parallelism. In the future it would be nice for Phobos to target SIMD
parallelism and distributed message passing parallelism, too. These
might belong in
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
On 4/16/2011 6:46 AM, Iain Buclaw wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
That's a good thought. FP addition results can differ dramatically
depending on
associativity.
And not to
On 4/16/2011 2:24 PM, dsimcha wrote:
On 4/16/2011 2:15 PM, Timon Gehr wrote:
Could be something somewhere is getting truncated from real to
double, which
would mean 12 fewer bits of mantisa. Maybe the FPU is set to lower
precision
in one of the threads?
Yes indeed, this is a _Windows_ bug.
On 4/16/2011 9:52 AM, Andrei Alexandrescu wrote:
I seem to remember that essentially some of the last bits printed in such a
result are essentially arbitrary. I forgot what could cause this.
To see what the exact bits are, print using %A format.
In any case, floating point bits are not
On 4/16/2011 11:43 AM, Iain Buclaw wrote:
I was thinking more of a case of FPU precision rather than ordering: as in you
get
a different result computing on SSE in double precision mode on the one hand,
and
by computing on x87 in double precision then writing to a double variable in
memory.
Walter:
Saying it is a safe way to break purity assumes that there was no purpose to
the purity.
There is no guaranteed safe way to break purity, with or without a compiler
switch.
The compiler switch I am talking about doesn't break purity. Its purpose is
similar to removing the pure
On Apr 16, 2011, at 11:43 AM, dsimcha wrote:
Close: If I add this instruction to the function for the new thread, the
difference goes away. The relevant statement is:
auto t = new Thread( {
asm { fninit; }
res2 = sumRange(terms);
} );
At any rate, this is a **huge** WTF that should
std.multicore? :p
On 4/16/11 1:39 PM, dsimcha wrote:
I'm reconsidering the naming of std.parallelism. The name is catchy, but
perhaps too general. std.parallelism currently targets SMP parallelism.
In the future it would be nice for Phobos to target SIMD parallelism and
distributed message passing parallelism,
On 4/16/2011 11:52 AM, bearophile wrote:
Walter:
Saying it is a safe way to break purity assumes that there was no purpose
to the purity. There is no guaranteed safe way to break purity, with or
without a compiler switch.
The compiler switch I am talking about doesn't break purity. Its
On 4/16/2011 11:51 AM, Sean Kelly wrote:
On Apr 16, 2011, at 11:43 AM, dsimcha wrote:
Close: If I add this instruction to the function for the new thread, the
difference goes away. The relevant statement is:
auto t = new Thread( { asm { fninit; } res2 = sumRange(terms); } );
At any rate,
Walter:
The dmd startup code (actually the C startup code) does an fninit. I never
thought about new thread starts. So, yeah, druntime should do an fninit on
thread creation.
My congratulations to all the (mostly two) people involved in finding this bug
and its causes :-)
I'd like to see
On Sat, 16 Apr 2011 15:32:12 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/16/2011 11:51 AM, Sean Kelly wrote:
On Apr 16, 2011, at 11:43 AM, dsimcha wrote:
Close: If I add this instruction to the function for the new thread,
the
difference goes away. The relevant
On 16.04.2011 22:39, dsimcha wrote:
I'm reconsidering the naming of std.parallelism. The name is catchy,
but perhaps too general. std.parallelism currently targets SMP
parallelism. In the future it would be nice for Phobos to target SIMD
parallelism and distributed message passing
Walter:
No, it is not. You seem to be thinking that purity is just a bug finding or
optimization feature. That is not so. Purity is a guarantee that can be relied
upon for a program's behavior. Breaking purity breaks that guarantee.
(Think multithreaded programs, for example.)
I was not
On 2011-04-16 14:39:23 -0400, dsimcha dsim...@yahoo.com said:
I'm reconsidering the naming of std.parallelism. The name is catchy,
but perhaps too general. std.parallelism currently targets SMP
parallelism. In the future it would be nice for Phobos to target SIMD
parallelism and
On 4/12/11 6:40 PM, David Nadlinger wrote:
- The helper functions for creating instances of new unit types (scale,
affine, ...) are currently template functions taking an instance of the
unit they manipulate as actual argument. This is only for »historical«
reasons really, would it be cleaner to
Yeah, I never formalized it at all, but that's roughly what TempAlloc
accomplishes. My other concern is, what happens in the case of the
following code:
uint nonLeaky() pure {
foreach(i; 0..42) {
auto arr = new uint[666];
// do stuff
}
return 8675309;
On 4/16/2011 1:21 PM, bearophile wrote:
Walter:
No, it is not. You seem to be thinking that purity is just a bug finding
or optimization feature. That is not so. Purity is a guarantee that can be
relied upon for a program's behavior. Breaking purity breaks that
guarantee.
(Think multithreaded
Timon Gehr:
The problem is, that inside a non-leaky pure function the general case for
dynamic
allocations might be just as complicated as in other parts of the program.
If this is true, then you need a sealed temporary heap.
Bye,
bearophile
On 04/16/2011 06:55 AM, Andrej Mitrovic wrote:
I wonder.. in all these years.. have they ever thought about using a
convention in C where the length is embedded as a 32/64bit value at
the pointed location of a pointer, followed by the array contents?
Sometimes called Pascal strings (actually,
int[3] a = [1,2,4];
float[3] b = [1,2,4];
float[3] c;
// Why doesn't this work?
c = a[] + b[]; // Error: incompatible types for ((a[]) + (b[])):
'int[]' and 'float[]'
// When this works?
c[0] = a[0] + b[0];
c[1] = a[1] + b[1];
c[2] = a[2] + b[2];
On 16.04.2011 12:12, simendsjo wrote:
int[3] a = [1,2,4];
float[3] b = [1,2,4];
float[3] c;
// Why doesn't this work?
c = a[] + b[]; // Error: incompatible types for ((a[]) + (b[])): 'int[]'
and 'float[]'
// When this works?
c[0] = a[0] + b[0];
c[1] = a[1] + b[1];
c[2] = a[2] + b[2];
assert(c ==
is there any different b/w:
auto arr = new int[10];
and
int[10] arr;
?
%u wrote:
is there any different b/w:
auto arr = new int[10];
arr is dynamic array of int with ten elements
and
int[10] arr;
?
arr is static array of int with ten elements
simendsjo:
int[3] a = [1,2,4];
float[3] b = [1,2,4];
float[3] c;
// Why doesn't this work?
c = a[] + b[]; // Error: incompatible types for ((a[]) + (b[])):
'int[]' and 'float[]'
// When this works?
c[0] = a[0] + b[0];
c[1] = a[1] + b[1];
Yeah I basically took the idea from the existing D implementation.
Although D's arrays are a struct with a length and a pointer (I think
so).
Is there any way to access the your current scope? For instance the
following pseudocode is what I am after more or less:
class Foo
{
alias byte function(int) BarCompatibleInterface;
byte Bar(int)
{
static assert(is(typeof(localscope) == function));
static
Sean Cavanaugh:
Is there any way to access the your current scope? For instance the
following pseudocode is what I am after more or less:
class Foo
{
alias byte function(int) BarCompatibleInterface;
byte Bar(int)
{
static assert(is(typeof(localscope) == function));
http://d.puremagic.com/issues/show_bug.cgi?id=5678
--- Comment #2 from bearophile_h...@eml.cc 2011-04-16 06:46:24 PDT ---
Is the same problem with associative arrays in another bug report?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving
http://d.puremagic.com/issues/show_bug.cgi?id=5846
Summary: String literals can be assigned to static char arrays
without .dup
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
http://d.puremagic.com/issues/show_bug.cgi?id=5847
Summary: Threads started by core.thread should have same
floating point state as main thread
Product: D
Version: unspecified
Platform: Other
OS/Version: Windows
http://d.puremagic.com/issues/show_bug.cgi?id=5848
Summary: Coverage always report 000 for inlined function
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
http://d.puremagic.com/issues/show_bug.cgi?id=5848
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
---
http://d.puremagic.com/issues/show_bug.cgi?id=5848
--- Comment #2 from kenn...@gmail.com 2011-04-16 12:06:15 PDT ---
(In reply to comment #1)
What kind of textual output do you desire in this situation?
What do you mean?
--
Configure issuemail:
http://d.puremagic.com/issues/show_bug.cgi?id=5848
--- Comment #3 from bearophile_h...@eml.cc 2011-04-16 12:54:22 PDT ---
(In reply to comment #2)
(In reply to comment #1)
What kind of textual output do you desire in this situation?
What do you mean?
What coverage results textual file do
http://d.puremagic.com/issues/show_bug.cgi?id=4851
--- Comment #2 from bearophile_h...@eml.cc 2011-04-16 12:54:38 PDT ---
That fourth idea is also useful to avoid a little trap. This code looks
correct, here randomCover() is used to act like the Python random.choice(), but
here it keeps taking
http://d.puremagic.com/issues/show_bug.cgi?id=5140
--- Comment #2 from bearophile_h...@eml.cc 2011-04-16 15:36:18 PDT ---
See a better explanations and some examples of __function:
http://rosettacode.org/wiki/Anonymous_recursion
And I see this is another use case for __function:
http://d.puremagic.com/issues/show_bug.cgi?id=5849
Summary: std.random.dice is better as a range
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
http://d.puremagic.com/issues/show_bug.cgi?id=5850
Summary: Default arguments of out and ref arguments
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: wrong-code
Severity: normal
http://d.puremagic.com/issues/show_bug.cgi?id=1389
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||patch
http://d.puremagic.com/issues/show_bug.cgi?id=5771
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||patch, rejects-valid
http://d.puremagic.com/issues/show_bug.cgi?id=5657
--- Comment #6 from Kenji Hara k.hara...@gmail.com 2011-04-16 19:31:55 PDT ---
Pull request.
https://github.com/D-Programming-Language/dmd/pull/26
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are
http://d.puremagic.com/issues/show_bug.cgi?id=5678
--- Comment #3 from Don clugd...@yahoo.com.au 2011-04-16 22:26:16 PDT ---
(In reply to comment #2)
Is the same problem with associative arrays in another bug report?
The general bug, which includes AAs, was fixed with this commit:
75 matches
Mail list logo
