On 18.02.2011 11:18, Walter Bright wrote:
Now with 64 bit Linux support! (Though expect problems with it, it's
brand new.)
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.067.zip
http://www.digitalmars.com/d/2.0/changelog.html
On 21.02.2011 11:53, Stephan wrote:
On 18.02.2011 11:18, Walter Bright wrote:
Now with 64 bit Linux support! (Though expect problems with it, it's
brand new.)
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.067.zip
On 21.02.2011 12:34, Dmitry Olshansky wrote:
On 21.02.2011 11:53, Stephan wrote:
On 18.02.2011 11:18, Walter Bright wrote:
Now with 64 bit Linux support! (Though expect problems with it, it's
brand new.)
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.067.zip
On 18/02/2011 10:18, Walter Bright wrote:
Now with 64 bit Linux support! (Though expect problems with it, it's
brand new.)
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.067.zip
http://www.digitalmars.com/d/2.0/changelog.html
On 21/02/11 16:14, Michel Fortin wrote:
On 2011-02-20 20:21:20 -0500, Graham St Jack
graham.stj...@internode.on.net said:
In particular, are there any plans to re-examine the tail-const issue
in light of the compiler patch proposed by Michel Fortin in his post:
const(Object)ref is here! back
SWIG 2.0.2, the first version to come with support for D, has been
released yesterday. For more detail, please refer to my blog:
http://klickverbot.at/blog/2011/02/swig-2-0-2-with-d-support-released/
David
On 02/21/2011 05:32 AM, Walter Bright wrote:
Kevin Bealer wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Kevin Bealer wrote:
You could switch to this:
struct {
BigInt numerator;
BigInt denominator;
};
Bingo -- no compromise.
It cannot represent irrational numbers
On 02/21/2011 08:52 AM, Kevin Bealer wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
...
I do understand that if you have a full symbolic representation, you can do so
with zero losses. But Kevin's proposal was not that, it was for a ratio
representation.
All it
naked INSIDE of the context which is adress with the attribute - looks
very strange to me, because it changes the pro- AND epilog of an
function/codeblock
real blabla(real x)
{
asm{
naked;
mov EAX,[RSP];
naked;
add EAX,0x3fff;
naked;
}
}
wouldn't it be better to have
Kevin Bealer wrote:
1. To solve the basic problem the original poster was asking -- if you are
working
with simple decimals and arithmetic you can get completely accurate
representations
this way. For some cases like simple financial work this might work really
well.
e.g. where float would
spir wrote:
Naturally non-representable numbers (irrationals), or results of
naturally approximate operations (like trig), are not an issue because
they are expected to yield inaccuracy.
Huh, I regularly run into people who are befuddled by the trig functions not
conforming to the usual trig
On Mon, 21 Feb 2011 12:45:21 +0300, dennis luehring dl.so...@gmx.net
wrote:
naked INSIDE of the context which is adress with the attribute - looks
very strange to me, because it changes the pro- AND epilog of an
function/codeblock
real blabla(real x)
{
asm{
naked;
mov
On Sun, 5 Sep 2010 22:28:41 -0700
SK s...@metrokings.com wrote:
Why labor over buggy Makefiles when you could be laboring over buggy
CMake files at a much more productive level of abstraction? :o)
I played with Waf a bit and it has nice support for D.
However, despite many contributors
On Monday 21 February 2011 01:55:28 Walter Bright wrote:
Kevin Bealer wrote:
1. To solve the basic problem the original poster was asking -- if you
are working with simple decimals and arithmetic you can get completely
accurate representations this way. For some cases like simple financial
On Mon, 2011-02-21 at 11:31 +0100, Gour wrote:
[ . . . ]
I played with Waf a bit and it has nice support for D.
However, despite many contributors listed, it still seems to be mostly
one-man-show which makes me a bit reluctant to use it over Cmake
(SCons seems to be very slow without much
On Mon, 21 Feb 2011 10:56:50 +
Russel Winder rus...@russel.org.uk wrote:
Any hope that D support will be applied in upstream?
What about 64bit support in dmd2?
Are you talking about CMake or SCons here?
CMake.
For SCons, I have forked the D tool in the SCons core to be a
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Kevin Bealer wrote:
A reasonable way to do financial work is to use longs to represent pennies.
After all, you don't have fractional cents in your accounts.
Using floating point to represent money is a disaster in the making.
Gour wrote:
On Sun, 5 Sep 2010 22:28:41 -0700
SK s...@metrokings.com wrote:
Why labor over buggy Makefiles when you could be laboring over buggy
CMake files at a much more productive level of abstraction? :o)
I played with Waf a bit and it has nice support for D.
However, despite
Walter Bright newshou...@digitalmars.com wrote:
A reasonable way to do financial work is to use longs to represent
pennies. After all, you don't have fractional cents in your accounts.
I tend to favor using floating point, doing calculations in pennies, and
explicitly rounding result to
In 2.052 several of the most complicated dependencies on snn.lib (those
relating to exception handling) were removed. I don't know how many more
DMC-specific ones there are, but using another snn.lib might be possible
now.
Compiled a hello world with empty snn.lib:
OPTLINK (R) for Win32
Trass3r wrote:
In 2.052 several of the most complicated dependencies on snn.lib (those
relating to exception handling) were removed. I don't know how many more
DMC-specific ones there are, but using another snn.lib might be possible
now.
Compiled a hello world with empty snn.lib:
That's
spir wrote:
On 02/21/2011 05:32 AM, Walter Bright wrote:
Kevin Bealer wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
Kevin Bealer wrote:
You could switch to this:
struct {
BigInt numerator;
BigInt denominator;
};
Bingo -- no compromise.
It cannot represent
Don Wrote:
That's pretty good. Almost all of those things are standard C.
LDIV and UDIV could easily be eliminated.
__except_list is a null asm label (it is FS:[0]).
So the main problematic ones are:
_xi_a , __acrtused_con, the __fp functions, and _Ccmp
Yep, they need to be taken care of
bearophile Wrote:
Jonathan M Davis:
The thing is, of course, that actual equality sucks for floating point
values.
So much, that some people have proposed to deprecate the normal FP equality.
MISRA-C disallows them. When you see a == among FP values is often a code
smell.
Is it
On Mon, 21 Feb 2011 10:15:28 -0500, Kagamin s...@here.lot wrote:
bearophile Wrote:
Jonathan M Davis:
The thing is, of course, that actual equality sucks for floating
point values.
So much, that some people have proposed to deprecate the normal FP
equality. MISRA-C disallows them. When
On Sat, 19 Feb 2011 14:06:38 +0200, spir denis.s...@gmail.com wrote:
Hello,
What do you think of this?
unittest {
assert(-1.1 + 2.2 == 1.1); // pass
assert(-1.1 + 2.2 + 3.3 == 4.4);// pass
assert(-1.1 + 3.3 + 2.2 == 4.4);// fail
assert(-1.1 + 3.3 == 2.2);
On Sun, 20 Feb 2011 14:53:03 +0200, bearophile bearophileh...@lycos.com
wrote:
Walter:
There's a total lack of evidence for that.
MISRA-C standard disallows the equality among FP values. I presume they
have some serious evidence for their choices, but I don't know such
evidence. Today
On Mon, 2011-02-21 at 12:40 +0100, Jens Mueller wrote:
[ . . . ]
I don't know about upstreaming it. Certainly it would be nice. But for
doing so I need polish it further.
Can the code comprising the D support for CMake be packaged up so that
it can be offerred to everyone direct from a DVCS
so:
I still think == should mean the exact equality test and must be
consistent in language.
Everyone in this thread has misunderstood what I have tried to say, so I will
try to explain again, see the bottom of this post.
My idea was to turn the == operator among FP values into a syntax
Following came to my mind while coding some generic collection
classes: The toHash and opCmp operations are not supported for
builtin-types though their implementation is trivial.
* toHash
The code is already there inside TypeInfo.getHash. But
typeid(value).getHash(value) is much uglier than
Russel Winder wrote:
On Mon, 2011-02-21 at 12:40 +0100, Jens Mueller wrote:
[ . . . ]
I don't know about upstreaming it. Certainly it would be nice. But for
doing so I need polish it further.
Can the code comprising the D support for CMake be packaged up so that
it can be offerred to
Am 21.02.2011 20:59, schrieb Simon Buerger:
Following came to my mind while coding some generic collection classes:
The toHash and opCmp operations are not supported for builtin-types
though their implementation is trivial.
* toHash
The code is already there inside TypeInfo.getHash. But
On 21.02.2011 21:22, Daniel Gibson wrote:
Am 21.02.2011 20:59, schrieb Simon Buerger:
Following came to my mind while coding some generic collection classes:
The toHash and opCmp operations are not supported for builtin-types
though their implementation is trivial.
* toHash
The code is already
sadly no: (-30) - (30) = -170532704 which is
incorrect. It does however work for short/byte (and opCmp still
returning int).
oops, wrong example. It is: (-20) - (20) = 294967296,
sry. Anyway, you see the point with overflows
Am 21.02.2011 21:55, schrieb Simon Buerger:
sadly no: (-30) - (30) = -170532704 which is
incorrect. It does however work for short/byte (and opCmp still
returning int).
oops, wrong example. It is: (-20) - (20) = 294967296,
sry. Anyway, you see the point with
On Mon, 21 Feb 2011 12:40:11 +0100
Jens Mueller jens.k.muel...@gmx.de wrote:
I don't know about upstreaming it. Certainly it would be nice. But for
doing so I need polish it further.
OK.
It seems that not many people are using CMakeD and there seems to be
less interest in it.
I believe
If one doesn't know what floating point is and insists on using it, it
is
his own responsibility to face the consequences.
I don't buy this argument.
Why not? A logical flaw on my part or the statement being somewhat harsh?
Because i don't think it is the former, i will give an example for
so:
Why not?
A system language has to allow the programmer to do everything the hardware is
capable to do, including comparing floats in the usual way. But in general for
a well designed language it's better to clearly denote dangerous/unsafe/bad
things, and to make the safer routes the
That's pretty good. Almost all of those things are standard C.
LDIV and UDIV could easily be eliminated.
__except_list is a null asm label (it is FS:[0]).
So the main problematic ones are:
_xi_a , __acrtused_con, the __fp functions, and _Ccmp
So how to tackle that?
On 2/21/11 4:48 AM, Jonathan M Davis wrote:
On Monday 21 February 2011 01:55:28 Walter Bright wrote:
Kevin Bealer wrote:
1. To solve the basic problem the original poster was asking -- if you
are working with simple decimals and arithmetic you can get completely
accurate representations this
Andrei Alexandrescu:
This is a long-standing myth. I worked on Wall Street and have friends
who have been doing it for years. Everybody uses double.
Unbrutal Python programmers are encouraged to avoid the float type to manage
money values, and use decimal instead:
On 2/21/11 6:08 PM, bearophile wrote:
Andrei Alexandrescu:
This is a long-standing myth. I worked on Wall Street and have friends
who have been doing it for years. Everybody uses double.
Unbrutal Python programmers are encouraged to avoid the float type to manage
money values, and use
On Monday 21 February 2011 15:58:03 Andrei Alexandrescu wrote:
On 2/21/11 4:48 AM, Jonathan M Davis wrote:
On Monday 21 February 2011 01:55:28 Walter Bright wrote:
Kevin Bealer wrote:
1. To solve the basic problem the original poster was asking -- if you
are working with simple decimals
I just noticed that the TDPL sample chapter at
http://erdani.com/d/thermopylae.pdf still contains a lot of warnings
concerning failed unit test, which have been fixed since the sample
chapter was published. This might probably leave a bad impression to
people interested in D.
Is there any
Nick Sabalausky a@a.a wrote in message
news:ijpvpl$2l8u$1...@digitalmars.com...
I've been updating the docs for my Goldie project in preparation of a new
release, and figured the they looked a bit...sterile, so I've tweaked the
CSS a bit. And, well, I think I've stumbled upon a
Okay, removing elements from a container sucks right now. You can do stuff like
removeAny (generally pretty useless IMHO) or removeFront just fine, but
removing
an arbitrary range from a container just plain sucks.
remove takes a range type which is the range type for the container that it's
On Monday 21 February 2011 18:22:01 Nick Sabalausky wrote:
Nick Sabalausky a@a.a wrote in message
news:ijpvpl$2l8u$1...@digitalmars.com...
I've been updating the docs for my Goldie project in preparation of a new
release, and figured the they looked a bit...sterile, so I've tweaked the
Sorry, maybe this question is not so proper, but I really want to get some
feedback, for here we have many professors about D.
Before, if D want to use the GUI, such as GTK+, we can use a gtkD port.
http://www.dsource.org/projects/gtkd
And when the Milestone version for GTK+ (GTK+ 3.0) formally
On 2/20/2011 8:05 PM, Jason House wrote:
Sounds promising. How does it effect other cases? Some typical GC-heavy
benchmark? Lots of smaller no scan objects that are just under your
optimization threshold?
I posted some new benchmarks that are more like realistic workloads to
the original
On 2/21/2011 11:46 PM, %u wrote:
Hi,
I'm just curious... why is saying something like this:
extern(C)
private static const pure override final synchronized ~this() { }
allowed?
Thanks!
...And when's the last time you needed one?
Hi,
I'm just curious... why is saying something like this:
extern(C)
private static const pure override final synchronized ~this() { }
allowed?
Thanks!
That's pretty good. Almost all of those things are standard C.
LDIV and UDIV could easily be eliminated.
__except_list is a null asm label (it is FS:[0]).
So the main problematic ones are:
_xi_a , __acrtused_con, the __fp functions, and _Ccmp
So how to tackle that?
I'm really glad that
remove takes a range type which is the range type for the
container that it's on. That makes sense. It's obviously not going
to be able to a take an arbitrary range and remove that from itself.
How would it know which elements in that range corresponded to which
elements in itself - especially
On Monday 21 February 2011 20:46:56 %u wrote:
Hi,
I'm just curious... why is saying something like this:
extern(C)
private static const pure override final synchronized ~this() { }
allowed?
dmd is pretty lax about attributes which don't apply. It generally just ignores
them.
On Monday 21 February 2011 21:04:47 %u wrote:
remove takes a range type which is the range type for the
container that it's on. That makes sense. It's obviously not going
to be able to a take an arbitrary range and remove that from itself.
How would it know which elements in that range
The more I look at it, the more I'm convinced that we really need to
add a primitive to forward ranges that returns the first n elements of
that range. Without that, I don't see how you can get a range of the
correct type with only those elements in it unless it's also a
bidirectional range,
You know, I'm actually now questioning whether STL did the right thing
with requiring iterators for the erase() method. It actually seems
quite pointless -- there's no reason why integer indices wouldn't
work. I don't think we really need to follow suit with STL here... is
there some situation
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
I worked on Wall Street and have friends who have been doing it for
years. Everybody uses double.
Makes sense. Not many people on earth has more than
4,503,599,627,370,496 pennies lying about.
--
Simen
On Monday 21 February 2011 21:51:51 %u wrote:
You know, I'm actually now questioning whether STL did the right thing
with requiring iterators for the erase() method. It actually seems
quite pointless -- there's no reason why integer indices wouldn't
work. I don't think we really need to follow
dmd is pretty lax about attributes which don't apply. It generally just
ignores them. Personally,
I think that it should error on invalid attributes, but for some reason, that's
not how it works.
Of course, there could be other bugs in play here, but there's every
possibility that the end
Hm... so the entire issue here seems to be the capability to do
iteration and modification in a concurrent manner, right?
IMHO that may not be worth the costs we're paying -- I would argue
that you normally shouldn't be modifying a collection that you're
iterating over in the first place; it just
On Monday 21 February 2011 22:51:25 %u wrote:
Hm... so the entire issue here seems to be the capability to do
iteration and modification in a concurrent manner, right?
IMHO that may not be worth the costs we're paying -- I would argue
that you normally shouldn't be modifying a collection
On 2011-02-20 22:42:06 +0100, Nick Sabalausky said:
[snip]
We used to have occasional breking changes in the language itself (in
D2-only), since D2 was the deliberately the development branch rather
than the stable branch that D1 has been, but D2's language spec is
pretty much finalized now.
On Sun, 20 Feb 2011 15:23:29 -0500, Steven Schveighoffer wrote:
On Sun, 20 Feb 2011 14:51:10 -0500, bearophile
bearophileh...@lycos.com wrote:
Jacob Carlborg:
Every time I try to use D2 it's just a PITA to use. I've used D1 and
Tango for
several years and had no problem with that.
I
Hey guys,
I've a small problem implementing multiple opCall()-methods. At first, I've the
following interface:
interface Invoker {
void opCall(uint i);
}
... and an abstract class which inherits from the Invoker-interface like the
following:
abstract class AbstractInvoker : Invoker {
Hi,
I'm trying to figure out how I could get a simple OpenGL/GLUT program working
in DMD2. As an attachment, I've added a C version of what I'd like to do. I'd
compile the C version using:
gcc simple.c -lglut -lGLU -o simple
I've found a few OpenGL projects, like bindings
== Auszug aus Siqu (u...@example.net)'s Artikel
Hi,
I'm trying to figure out how I could get a simple OpenGL/GLUT
program working
in DMD2. As an attachment, I've added a C version of what I'd like
to do. I'd
compile the C version using:
gcc simple.c -lglut -lGLU -o simple
I've found a few
Am 21.02.2011 11:18, schrieb useo:
Hey guys,
I've a small problem implementing multiple opCall()-methods. At first, I've the
following interface:
interface Invoker {
void opCall(uint i);
}
... and an abstract class which inherits from the Invoker-interface like the
following:
abstract
== Auszug aus Mafi (m...@example.org)'s Artikel
Am 21.02.2011 11:18, schrieb useo:
Hey guys,
I've a small problem implementing multiple opCall()-methods. At
first, I've the following interface:
interface Invoker {
void opCall(uint i);
}
... and an abstract class which inherits
On 2011-02-20 19:22:20 +0100, Magnus Lie Hetland said:
On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:
[snip]
Unfortunately, rdmd doesn't seem to have gotten much attention lately.
I've had a few patches for it sitting in bugzilla for a number of
months. (Not that I'm complaning, I
On 21.02.2011 13:33, Siqu wrote:
Hi,
I'm trying to figure out how I could get a simple OpenGL/GLUT program working
in DMD2. As an attachment, I've added a C version of what I'd like to do. I'd
compile the C version using:
gcc simple.c -lglut -lGLU -o simple
I've found a few OpenGL projects,
On Mon, 21 Feb 2011 14:45:51 +0300, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
On 21.02.2011 13:33, Siqu wrote:
Hi,
I'm trying to figure out how I could get a simple OpenGL/GLUT program
working
in DMD2. As an attachment, I've added a C version of what I'd like to
do. I'd
compile the
On Monday 21 February 2011 02:47:03 Mafi wrote:
Am 21.02.2011 11:18, schrieb useo:
Hey guys,
I've a small problem implementing multiple opCall()-methods. At first,
I've the following interface:
interface Invoker {
void opCall(uint i);
}
... and an abstract class
On Mon, 21 Feb 2011 12:18:54 +0100, Magnus Lie Hetland wrote:
On 2011-02-20 19:22:20 +0100, Magnus Lie Hetland said:
On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:
[snip]
Unfortunately, rdmd doesn't seem to have gotten much attention lately.
I've had a few patches for it sitting in
I've found a few OpenGL projects, like bindings
(http://www.dsource.org/projects/bindings/) and derelict
(http://www.dsource.org/projects/derelict/), but I still can't find any way to
easily use or install them (for D2 on Ubuntu).
Use derelict2 from svn and xfBuild. Then you just need to tell
On 2011-02-21 14:16, Lars T. Kyllingstad wrote:
On Mon, 21 Feb 2011 12:18:54 +0100, Magnus Lie Hetland wrote:
On 2011-02-20 19:22:20 +0100, Magnus Lie Hetland said:
On 2011-02-19 22:25:31 +0100, Nick Sabalausky said:
[snip]
Unfortunately, rdmd doesn't seem to have gotten much attention
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
As noted in my earlier email on the other list, I too got this problem.
Fromn what I can tell 1.066 and 2.051 have dmd.conf files but there is
no such thing in the 1.067
On 2/19/2011 10:46 PM, Lutger Blijdestijn wrote:
Nick wrote:
I know I can parametrize template mixin types, but how about mixin
identifiers? This is the code:
mixin template Box(T) {
T val;
}
class Set(A, B) {
mixin
Maybe a little stupid, but I get an assert when I try to compare a valid
pointer with an int casted pointer.
I know, I could compare the pointer itself, but shouldn't is-poerator
also work?
Also, shouldn't an assert always reproted as a bug?
struct Test {}
void main()
{
Test t,t2;
Matthias Pleh:
Also, shouldn't an assert always reproted as a bug?
Added:
http://d.puremagic.com/issues/show_bug.cgi?id=5633
Bye,
bearophile
On 21/02/2011 00:24, Steven Schveighoffer wrote:
On Sun, 20 Feb 2011 16:23:14 -0500, Nick Sabalausky a@a.a wrote:
Simon s.d.hamm...@gmail.com wrote in message
news:ijrdif$1nn6$1...@digitalmars.com...
On 20/02/2011 14:59, d coder wrote:
Greetings
I tried to initialize a struct member with a
Am 21.02.2011 19:00, schrieb bearophile:
Matthias Pleh:
Also, shouldn't an assert always reproted as a bug?
Added:
http://d.puremagic.com/issues/show_bug.cgi?id=5633
Bye,
bearophile
Ah, thanks!
On Monday 21 February 2011 08:40:38 Kai Meyer wrote:
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
On Friday, February 18, 2011 16:27:23 Russel Winder wrote:
As noted in my earlier email on the other list, I too got this problem.
Fromn what I can tell 1.066 and 2.051
http://d.puremagic.com/issues/show_bug.cgi?id=5626
Masahiro Nakagawa repeate...@gmail.com changed:
What|Removed |Added
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=5631
Summary: Large Address Aware
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: Optlink
http://d.puremagic.com/issues/show_bug.cgi?id=5632
Summary: replace() not evaluatable at compile-time anymore
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity:
http://d.puremagic.com/issues/show_bug.cgi?id=5373
--- Comment #8 from Trass3r mrmoc...@gmx.de 2011-02-21 08:16:16 PST ---
Well, as of 2.052 replace() has moved to std.array and can't be called at
compile-time anymore at all cause of Appender using pointers.
I've opened a new report:
http://d.puremagic.com/issues/show_bug.cgi?id=5632
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
---
http://d.puremagic.com/issues/show_bug.cgi?id=5633
Summary: (constfold.c): pointer is null
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
http://d.puremagic.com/issues/show_bug.cgi?id=5632
--- Comment #2 from Trass3r mrmoc...@gmx.de 2011-02-21 10:25:05 PST ---
Yeah, I know it is no requirement.
On the other hand you could also see it as a regression since replace was
CTFE-able before ;)
But I agree, string functions should be
http://d.puremagic.com/issues/show_bug.cgi?id=5631
Vladimir thecybersha...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=2837
Vladimir thecybersha...@gmail.com changed:
What|Removed |Added
CC||dsim...@yahoo.com
http://d.puremagic.com/issues/show_bug.cgi?id=5633
Trass3r mrmoc...@gmx.de changed:
What|Removed |Added
CC||mrmoc...@gmx.de
--- Comment
http://d.puremagic.com/issues/show_bug.cgi?id=5633
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords|rejects-valid |ice-on-valid-code
http://d.puremagic.com/issues/show_bug.cgi?id=4640
kenn...@gmail.com changed:
What|Removed |Added
CC||kenn...@gmail.com
--- Comment #2
http://d.puremagic.com/issues/show_bug.cgi?id=5006
kenn...@gmail.com changed:
What|Removed |Added
CC||kenn...@gmail.com
--- Comment #5
http://d.puremagic.com/issues/show_bug.cgi?id=5634
Summary: ICE on Mac OS X when there are multiple 'main's
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=5006
--- Comment #6 from kenn...@gmail.com 2011-02-21 11:50:21 PST ---
(In reply to comment #5)
On the other hand, bearophile's 2nd program now result in ICE (at least on Mac
OS X)
Internal error: ../ztc/machobj.c 1805
Never mind, it ICE only
http://d.puremagic.com/issues/show_bug.cgi?id=5635
Summary: Code inside 'foreach' cannot modify variable out of
its scope in a template function.
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status:
http://d.puremagic.com/issues/show_bug.cgi?id=4640
bearophile_h...@eml.cc changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
1 - 100 of 111 matches
Mail list logo
