On Wed, 29 Oct 2014 00:13:52 +
bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote:
no one published it yet, not no one attempted. i desperately
publish or perish! =)
oh, i want it to be at least pre-beta before showing it to the
world. ;-) what i'm really aiming at is a system
On Wednesday, 29 October 2014 at 01:22:43 UTC, Andrei
Alexandrescu wrote:
That won't work in D because in D pointers to methods carry
this with them, whereas in C++ they don't. -- Andrei
I have an idea ! We should call them delegates so people won't
make the confusion !
Looks like T[0] tries to take delegate to instanceMethod, hence
complains about this type.
It works after I added 'static' to the declaration of 'invoke()'
(and import std.stdio, std.traits.)
I fiddled around with it for hours before I tried 'static' there,
because I've only been studying D for a week, so only about half
of this code and the error messages made any sense to me when
On Monday, 27 October 2014 at 16:08:26 UTC, Solomon E wrote:
It works after I added 'static' to the declaration of
'invoke()' (and import std.stdio, std.traits.)
I fiddled around with it for hours before I tried 'static'
there, because I've only been studying D for a week, so only
about half
On Mon, 27 Oct 2014 22:17:24 +
bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote:
I have been trying to build a reflection system over the last few
weeks, and noticed different incarnations of this problem several
times:
(__error).instanceMethod
this means that something gone
this means that something gone wrong in the process.
'(__error)' is the
pseudotype for failed CTFE/instantiation.
But why did the instantiation fail? and more importantly, why did
it not have consistent behaviour between the two templates above?
what do you want to achieve
with second
quotes self
Here is a better example, showing that virtual function pointers
are available at compile time in C++. Essentially, I would expect
my D code to function similarly, but it won't compile.
class TestAddr {
public: virtual void test() { cout test endl; }
};
templatevoid
On Mon, 27 Oct 2014 23:52:38 +
bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote:
The code below suggests the latter, although it doesn't
explicitly state it:
static addr = TestClass.instanceMethod;
Error: non-constant expression instanceMethod
I may be missing a subtle
C++ compiler does some trickery behind the curtains. besides,
you
aren't supposed to make such hackish things easily in D. yet
you can:
There is nothing hackish in the above code. It's a non-type
template parameter and a member function pointer. If I was trying
to access the (implementation
besides, you can use CTFE to build wrapper code. Adam Ruppe
has that in
his jsvar.d, and i have that in my cong.d (cmdcon-ng) too.
I have actually found a work around as well, which was to wrap
the actual retrieval of the function address in a lambda, and
pass the lambda by template
On Tue, 28 Oct 2014 01:36:01 +
bitwise via Digitalmars-d digitalmars-d@puremagic.com wrote:
I have actually found a work around as well, which was to wrap
the actual retrieval of the function address in a lambda, and
pass the lambda by template parameter instead:
it's not a workaround,
On 16 June 2014 20:37, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 16 June 2014 at 19:18:29 UTC, Iain Buclaw via Digitalmars-d
wrote:
On 16 June 2014 17:31, safety0ff via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 16 June 2014 at 06:09:28 UTC,
On Wednesday, 18 June 2014 at 09:29:14 UTC, Iain Buclaw via
Digitalmars-d wrote:
Yeah, I did get that bit. I'm not sure of the optimisation
though.
IMO, the closure/frame generation should occur *after* inlining.
How would that work if your inliner operates on some
language-independent IR?
On Wednesday, 18 June 2014 at 09:29:14 UTC, Iain Buclaw via
Digitalmars-d wrote:
Yeah, I did get that bit. I'm not sure of the optimisation
though.
IMO, the closure/frame generation should occur *after* inlining.
That doesn't really work that way for LLVM. You generate language
independent
On 18 June 2014 14:18, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wednesday, 18 June 2014 at 09:29:14 UTC, Iain Buclaw via Digitalmars-d
wrote:
Yeah, I did get that bit. I'm not sure of the optimisation though.
IMO, the closure/frame generation should occur
On 18 June 2014 19:20, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wednesday, 18 June 2014 at 09:29:14 UTC, Iain Buclaw via Digitalmars-d
wrote:
Yeah, I did get that bit. I'm not sure of the optimisation though.
IMO, the closure/frame generation should occur *after*
On Wednesday, 18 June 2014 at 21:22:44 UTC, Iain Buclaw via
Digitalmars-d wrote:
Likewise here. But unless I'm missing something (I'm not sure
what
magic happens with @allocate, for instance), I'm not sure how
you
could expect the optimisation passes to squash closures
together.
Am I
On 18 June 2014 22:29, deadalnix via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wednesday, 18 June 2014 at 21:22:44 UTC, Iain Buclaw via
Digitalmars-d wrote:
Likewise here. But unless I'm missing something (I'm not sure what
magic happens with @allocate, for instance), I'm not sure
On Wednesday, 18 June 2014 at 21:14:48 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 18 June 2014 14:18, David Nadlinger via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Wednesday, 18 June 2014 at 09:29:14 UTC, Iain Buclaw via
Digitalmars-d
wrote:
IMO, the closure/frame generation should
On Wednesday, 18 June 2014 at 22:33:03 UTC, David Nadlinger wrote:
You stated that closure/frame generation should occur after
inlining. I doubt that this is feasible to implement in the
current LDC architecture, and probably also in GDC (although I
don't know its internals well enough to be
On Wednesday, 18 June 2014 at 23:08:06 UTC, deadalnix wrote:
Yes, but the problem is not limited to SDC. LDC exhibit the same
behavior (because it is an LLVM bug, not a SDC or LDC one).
Yes, certainly. To me, this looks like a limitation in GVN or so.
But coming back to the D side of things,
Am 18.06.2014 23:22, schrieb Iain Buclaw via Digitalmars-d:
Likewise here. But unless I'm missing something (I'm not sure what
magic happens with @allocate, for instance), I'm not sure how you
could expect the optimisation passes to squash closures together.
Am I correct in that it's asking
If they go for clang specific solution, that aren't gonna cut it
for us :(
Am 19.06.2014 07:16, schrieb deadalnix:
If they go for clang specific solution, that aren't gonna cut it
for us :(
only as an orientation what weaker language + optimizer can reach :)
On Monday, 16 June 2014 at 06:09:28 UTC, deadalnix wrote:
http://llvm.org/bugs/show_bug.cgi?id=20049
Basically when you have a closure in a closure and the whole
thing get inlined, LLVM mess up, which result in compiler not
being able to optimize GC allocation away.
Probably worth pushing
On Monday, 16 June 2014 at 16:31:20 UTC, safety0ff wrote:
On Monday, 16 June 2014 at 06:09:28 UTC, deadalnix wrote:
http://llvm.org/bugs/show_bug.cgi?id=20049
Basically when you have a closure in a closure and the whole
thing get inlined, LLVM mess up, which result in compiler not
being able
On 16 June 2014 17:31, safety0ff via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 16 June 2014 at 06:09:28 UTC, deadalnix wrote:
http://llvm.org/bugs/show_bug.cgi?id=20049
Basically when you have a closure in a closure and the whole thing get
inlined, LLVM mess up, which
On Monday, 16 June 2014 at 19:18:29 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 16 June 2014 17:31, safety0ff via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Monday, 16 June 2014 at 06:09:28 UTC, deadalnix wrote:
http://llvm.org/bugs/show_bug.cgi?id=20049
Basically when you have a
On Tuesday, 8 April 2014 at 21:13:47 UTC, Jeroen Bollen wrote:
Here we go: https://d.puremagic.com/issues/show_bug.cgi?id=12549
Not a bug:
What you are asking for is to allow immutable(T)** and int** to
convert to const(T)**
int a = 0;
int* pa = a;
const(int)** ppa = pa; // not currently
On 04/08/2014 02:38 PM, Peter Alexander wrote:
On Tuesday, 8 April 2014 at 21:13:47 UTC, Jeroen Bollen wrote:
Here we go: https://d.puremagic.com/issues/show_bug.cgi?id=12549
Not a bug:
Yeah. A known issue in C and C++ as well:
http://www.parashift.com/c++-faq/constptrptr-conversion.html
On 2/4/2012 2:04 PM, Era Scarecrow wrote:
[...]
struct X {
int i;
pure int squaredPlus(int x) {
return x*x + i
}
alias squaredPlus sqp;
}
X st(15);
writeln(st.sqp(0)); //15
int i1 = st.sqp(10); st.i++;
int i2 = st.sqp(10); st.i++;
int i3 =
On 2/4/2012 12:45 PM, Timon Gehr wrote:
[...]
Pure does not imply const in D.
[...]
I think this is a language defect:
struct Foo
{
int computed() pure { return x * y; }
int wrapper() const { return computed() + 5; }
int x;
int y;
}
void main()
{
}
src\Bug2.d(4): Error:
On Thu, Jan 02, 2014 at 04:31:24PM -0800, David Held wrote:
[...]
I think this is a language defect:
struct Foo
{
int computed() pure { return x * y; }
int wrapper() const { return computed() + 5; }
int x;
int y;
}
void main()
{
}
src\Bug2.d(4): Error: mutable
Sergei Nosov:
T identity(T)(T e) { return e; }
struct S(alias Func)
{
void call()
{
import std.stdio;
writeln(Func(string).length);
}
}
static struct S1
{
alias S!(identity) A1;
//alias S!(x = x) A2;
alias S!(function string (string e) { return e; }) A3;
On Thursday, 28 November 2013 at 08:23:22 UTC, bearophile wrote:
Global structs don't need the static attribute.
I've thought so, but added it just as a I really mean, that I
don't need context.
This version of your code gives the output 6 6 on Windows 32
bit:
Do you have a 64-bit OS at
Sergei Nosov:
Do you have a 64-bit OS at hand?
On 64 bit using dmd 2.064.2 it doesn't give the 6 6 output, so it
seems a 64 bit bug. This happens because the 64 bit version of
dmd is quite more new than the 32 bit version, so it has more
bugs.
Bye,
bearophile
On Thursday, 28 November 2013 at 09:48:47 UTC, bearophile wrote:
Sergei Nosov:
Do you have a 64-bit OS at hand?
On 64 bit using dmd 2.064.2 it doesn't give the 6 6 output, so
it seems a 64 bit bug. This happens because the 64 bit version
of dmd is quite more new than the 32 bit version, so
On Thursday, 28 November 2013 at 10:23:39 UTC, Kenji Hara wrote:
It's a known front-end issue.
https://d.puremagic.com/issues/show_bug.cgi?id=11545
Kenji Hara
Great! Does this pull resolve both issues? (correct length and
x=x syntax)
Don x...@nospam.com writes:
On Wednesday, 6 November 2013 at 06:28:59 UTC, Walter Bright wrote:
Perhaps an attribute rather than a function call.
double x;
double y = x.strictfloat;
double y = x.strictprecision;
ie, (expr).strictfloat would return expr, discarding any extra precision.
On 11/7/2013 8:55 AM, Jerry wrote:
What about something like the following?
double x;
double y;
with (strictprecision) {
y = x;
}
That has immediate problems with things like function calls that might or might
not be inlined.
On Thursday, 7 November 2013 at 20:02:05 UTC, Walter Bright wrote:
On 11/7/2013 8:55 AM, Jerry wrote:
What about something like the following?
double x;
double y;
with (strictprecision) {
y = x;
}
That has immediate problems with things like function calls
that might or might not be
On 11/7/2013 12:09 PM, John Colvin wrote:
On Thursday, 7 November 2013 at 20:02:05 UTC, Walter Bright wrote:
On 11/7/2013 8:55 AM, Jerry wrote:
What about something like the following?
double x;
double y;
with (strictprecision) {
y = x;
}
That has immediate problems with things like
On 11/6/2013 7:07 AM, Iain Buclaw wrote:
double y = cast(float) x; ? :o)
I don't like overlaying a new meaning onto the cast operation. For example, if
one was using it for type coercion, that is different from wanting precision
reduction. There'd be no way to separate the two effects if
On 11/6/2013 1:09 AM, Don wrote:
But we can test this. I predict that adding some extra bits to the internal
calculations in CTFE (to make it have eg 128 bit intermediate values instead of
80), will cause Phobos math unit tests to break.
Bring it on! Challenge accepted!
On Wednesday, 6 November 2013 at 06:28:59 UTC, Walter Bright
wrote:
On 11/5/2013 8:19 AM, Don wrote:
On Wednesday, 30 October 2013 at 18:28:14 UTC, Walter Bright
wrote:
Not exactly what I meant - I mean the algorithm should be
designed so that
extra precision does not break it.
On Wednesday, 6 November 2013 at 06:28:59 UTC, Walter Bright
wrote:
On 11/5/2013 8:19 AM, Don wrote:
On Wednesday, 30 October 2013 at 18:28:14 UTC, Walter Bright
wrote:
Not exactly what I meant - I mean the algorithm should be
designed so that
extra precision does not break it.
On 6 November 2013 09:09, Don x...@nospam.com wrote:
On Wednesday, 6 November 2013 at 06:28:59 UTC, Walter Bright wrote:
On 11/5/2013 8:19 AM, Don wrote:
On Wednesday, 30 October 2013 at 18:28:14 UTC, Walter Bright wrote:
Not exactly what I meant - I mean the algorithm should be designed
On Wednesday, 30 October 2013 at 18:28:14 UTC, Walter Bright
wrote:
On 10/30/2013 6:50 AM, Don wrote:
Unpredictable, sure, but it is unpredictable in that the
error is less than a
guaranteed maximum error. The error falls in a range
0=error=epsilon. As an
analogy, all engineering parts are
Don:
A compiler intrinsic, which generates no code (simply inserting
a barrier for the optimiser) sounds like the correct approach.
Coming up for a name for this operation is difficult.
Something like this?
noFPOpt
naiveFP
literalFP
asisFP
FPbarrier
barrierFP
Bye,
bearophile
On Tuesday, 5 November 2013 at 16:31:23 UTC, bearophile wrote:
Don:
A compiler intrinsic, which generates no code (simply
inserting a barrier for the optimiser) sounds like the correct
approach.
Coming up for a name for this operation is difficult.
Something like this?
noFPOpt
naiveFP
On 11/5/2013 8:19 AM, Don wrote:
On Wednesday, 30 October 2013 at 18:28:14 UTC, Walter Bright wrote:
Not exactly what I meant - I mean the algorithm should be designed so that
extra precision does not break it.
Unfortunately, that's considerably more difficult than writing an algorithm for
a
On 10/30/2013 3:36 PM, Iain Buclaw wrote:
Why do I feel like you recommend writing code in assembler every other post you
make. :o)
You're exaggerating. I recommend assembler in only 1 out of 4 posts.
On Tuesday, 29 October 2013 at 19:42:08 UTC, Walter Bright wrote:
On 10/29/2013 5:08 AM, Don wrote:
On Wednesday, 23 October 2013 at 16:50:52 UTC, Walter Bright
wrote:
On 10/23/2013 9:22 AM, David Nadlinger wrote:
On Wednesday, 23 October 2013 at 16:15:56 UTC, Walter Bright
wrote:
A D
On 23/10/13 18:16, Walter Bright wrote:
To precisely control maximum precision, I suggest using inline assembler to use
the exact sequence of instructions needed for double-double operations.
Could be relevant here: last year I wrote some code which divided up the closed
interval [0, 1] into
It's called excess precision and regularly causes confusion.
http://d.puremagic.com/issues/show_bug.cgi?id=6531
On 10/23/2013 06:16 PM, Walter Bright wrote:
A D compiler is allowed to compute floating point results at arbitrarily
large precision - the storage size (float, double, real) only specify
the minimum precision.
It seems like there is some change in C99 to address excess precision.
Namely
On 10/30/2013 6:50 AM, Don wrote:
Unpredictable, sure, but it is unpredictable in that the error is less than a
guaranteed maximum error. The error falls in a range 0=error=epsilon. As an
analogy, all engineering parts are designed with a maximum deviation from the
ideal size, not a minimum
On 10/30/2013 07:29 PM, Martin Nowak wrote:
It seems like there is some change in C99 to address excess precision.
Namely assignments and casts are NOT allowed to have greater precision.
Not sure if assignments refers to first storing and then loading a
value. So maybe it's useful to review that
On Oct 23, 2013 5:21 PM, Walter Bright newshou...@digitalmars.com wrote:
On 10/23/2013 8:44 AM, Apollo Hogan wrote:
That is: without optimization the run-time normalization is correct.
With
optimization it is broken. That is pretty easy to work around by simply
compiling the relevant
On Wednesday, 23 October 2013 at 16:50:52 UTC, Walter Bright
wrote:
On 10/23/2013 9:22 AM, David Nadlinger wrote:
On Wednesday, 23 October 2013 at 16:15:56 UTC, Walter Bright
wrote:
A D compiler is allowed to compute floating point results at
arbitrarily large
precision - the storage size
On 10/29/2013 5:08 AM, Don wrote:
On Wednesday, 23 October 2013 at 16:50:52 UTC, Walter Bright wrote:
On 10/23/2013 9:22 AM, David Nadlinger wrote:
On Wednesday, 23 October 2013 at 16:15:56 UTC, Walter Bright wrote:
A D compiler is allowed to compute floating point results at arbitrarily
On 10/23/2013 10:45 PM, qznc wrote:
Page 16 is probably the core argument Linguistically legislated exact
reproducibility is unenforceable, but everything Kahan says here is worth
listening to (despite the ugly presentation).
I agree that Prof Kahan is well worth listening to for anyone with
On Wednesday, 23 October 2013 at 15:44:54 UTC, Apollo Hogan wrote:
For example, the appended code produces the following output
when compiled (DMD32 D Compiler v2.063.2 under WinXP/cygwin)
with no optimization:
immutable(pair)(1.1, -2.03288e-20)
pair(1, 0.1)
pair(1.1, -8.32667e-17)
and the
On Thursday, 24 October 2013 at 06:12:03 UTC, qznc wrote:
import std.stdio;
struct pair { double hi, lo; }
pair normalize(pair q)
{
double h = q.hi + q.lo;
double l = q.lo + (q.hi - h);
return pair(h,l);
}
void main()
{
immutable static pair spn = normalize(pair(1.0,0.1));
writeln(spn);
On Thursday, 24 October 2013 at 07:27:09 UTC, qznc wrote:
On Thursday, 24 October 2013 at 06:12:03 UTC, qznc wrote:
import std.stdio;
struct pair { double hi, lo; }
pair normalize(pair q)
{
double h = q.hi + q.lo;
double l = q.lo + (q.hi - h);
return pair(h,l);
}
void main()
{
immutable static
Apollo Hogan:
import std.stdio;
struct Pair { double hi, lo; }
Pair normalize(Pair q) {
immutable h = q.hi + q.lo;
immutable l = q.lo + (q.hi - h);
return Pair(h, l);
}
void main() {
immutable static Pair spn = Pair(1.0, 0.1).normalize;
spn.writeln;
Pair(1.0,
On 10/23/2013 8:44 AM, Apollo Hogan wrote:
That is: without optimization the run-time normalization is correct. With
optimization it is broken. That is pretty easy to work around by simply
compiling the relevant library without optimization. (Though it would be nice
to have, for example,
Hi Bearophile-
Interesting. Looks like the run-time calculation in ldmd2 works
fine.
The compile-time computation in both my and your examples looks
like it is being done in 80-bit arithmetic.
Thanks,
--Apollo
On Wednesday, 23 October 2013 at 16:15:56 UTC, Walter Bright
wrote:
A D compiler is allowed to compute floating point results at
arbitrarily large precision - the storage size (float, double,
real) only specify the minimum precision.
This behavior is fairly deeply embedded into the front end,
On 10/23/2013 9:22 AM, David Nadlinger wrote:
On Wednesday, 23 October 2013 at 16:15:56 UTC, Walter Bright wrote:
A D compiler is allowed to compute floating point results at arbitrarily large
precision - the storage size (float, double, real) only specify the minimum
precision.
This behavior
On Wednesday, 23 October 2013 at 16:50:52 UTC, Walter Bright
wrote:
On 10/23/2013 9:22 AM, David Nadlinger wrote:
On Wednesday, 23 October 2013 at 16:15:56 UTC, Walter Bright
wrote:
A D compiler is allowed to compute floating point results at
arbitrarily large
precision - the storage size
On 10/23/2013 11:39 AM, Apollo Hogan wrote:
There are a couple of points here:
- it seems that whatever the semantics of floating-point arithmetic, they should
be the same at compile-time as at run-time.
It's not very practical, especially considering that the compile time
environment may be
On Wednesday, 23 October 2013 at 19:10:22 UTC, Walter Bright
wrote:
On 10/23/2013 11:39 AM, Apollo Hogan wrote:
There are a couple of points here:
- it seems that whatever the semantics of floating-point
arithmetic, they should
be the same at compile-time as at run-time.
It's not very
On 10/23/13 1:59 PM, Apollo Hogan wrote:
Thanks, a useful trick. It at least lets me confound the optimizer a
bit. (Though doesn't help with the compile vs. run headache. Though
this seems to be workaroundable by using a static constructor. Yeah,
I'm a noob.)
+1 for workaroundable.
Andrei
On Wednesday, 23 October 2013 at 16:50:52 UTC, Walter Bright
wrote:
Java initially tried to enforce a maximum precision, and it was
a major disaster for them. If I have been unable to convince
you, I suggest reviewing that case history.
It was recently on Hacker News. Here is one of the
Added to bugzilla
http://d.puremagic.com/issues/show_bug.cgi?id=11147
On Monday, 30 September 2013 at 08:48:08 UTC, andrea9940 wrote:
Added to bugzilla
http://d.puremagic.com/issues/show_bug.cgi?id=11147
Good news, it's already fixed :)
Thanks Kenji
On Sunday, 29 September 2013 at 16:36:22 UTC, andrea9940 wrote:
I think that I found a bug in the initialization of a struct.
This program throws a.v.y != 0 but all assert should pass...
(I'm using the latest dmd version available)
Code: http://pastebin.com/VHQP8DaE
I'm not sure what the
Thanks for the answer, I will use the aliases; however I just
tried my code on codepad and surprising it worked without errors
http://codepad.org/hp0YxIi7
On Sunday, 29 September 2013 at 17:35:33 UTC, andrea9940 wrote:
Thanks for the answer, I will use the aliases; however I just
tried my code on codepad and surprising it worked without
errors http://codepad.org/hp0YxIi7
I think there is a bug in there somewhere though:
//
struct V{
On Sunday, 29 September 2013 at 18:01:01 UTC, monarch_dodra wrote:
On Sunday, 29 September 2013 at 17:35:33 UTC, andrea9940 wrote:
Thanks for the answer, I will use the aliases; however I just
tried my code on codepad and surprising it worked without
errors http://codepad.org/hp0YxIi7
I
On 8/18/13, yaz yazan.dab...@gmail.com wrote:
I think this is the same issue as
https://github.com/aldacron/Derelict3/issues/143
I remember seeing that! I also tried -L/SUBSYSTEM:WINDOWS at first
(without the number), but it didnt' make a difference. However using
-L/SUBSYSTEM:WINDOWS:5.01
On 8/17/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
First, here is the C code:
Btw, here's the D equivalent where I can also recreate the bug:
-
import core.sys.windows.windows;
import std.stdio;
alias extern(C) void* function() Tcl_CreateInterp_Type;
alias extern(C) int
On Saturday, 17 August 2013 at 21:34:24 UTC, Andrej Mitrovic
wrote:
I think this is the same issue as
https://github.com/aldacron/Derelict3/issues/143
The solution advised by aldacron (Mike Parker) in his last few
posts is to compile your D executable as a Windows subsystem exe
or use
On Wednesday, 7 August 2013 at 19:10:11 UTC, Borislav Kosharov
wrote:
Something strange happens when I do this:
unittest {
import std.array, std.string;
string s = test;
//assert(s.toUpper.split().join(-) == T-E-S-T);
//Memory allocation failed
//[Finished in 26.5s]
On Wednesday, 7 August 2013 at 19:10:11 UTC, Borislav Kosharov
wrote:
Something strange happens when I do this:
unittest {
import std.array, std.string;
string s = test;
//assert(s.toUpper.split().join(-) == T-E-S-T);
//Memory allocation failed
//[Finished in 26.5s]
On Wed, Aug 07, 2013 at 09:10:04PM +0200, Borislav Kosharov wrote:
Something strange happens when I do this:
unittest {
import std.array, std.string;
string s = test;
//assert(s.toUpper.split().join(-) == T-E-S-T);
//Memory allocation failed
//[Finished in 26.5s]
On Wed, Aug 07, 2013 at 12:44:54PM -0700, H. S. Teoh wrote:
On Wed, Aug 07, 2013 at 09:10:04PM +0200, Borislav Kosharov wrote:
Something strange happens when I do this:
unittest {
import std.array, std.string;
string s = test;
//assert(s.toUpper.split().join(-) ==
On Wednesday, 7 August 2013 at 19:10:11 UTC, Borislav Kosharov
wrote:
Something strange happens when I do this:
unittest {
import std.array, std.string;
string s = test;
//assert(s.toUpper.split().join(-) == T-E-S-T);
//Memory allocation failed
//[Finished in 26.5s]
On Wed, Aug 07, 2013 at 10:39:11PM +0200, John Colvin wrote:
On Wednesday, 7 August 2013 at 19:10:11 UTC, Borislav Kosharov
wrote:
Something strange happens when I do this:
unittest {
import std.array, std.string;
string s = test;
//assert(s.toUpper.split().join(-) ==
On Wed, Aug 07, 2013 at 01:42:13PM -0700, H. S. Teoh wrote:
On Wed, Aug 07, 2013 at 10:39:11PM +0200, John Colvin wrote:
On Wednesday, 7 August 2013 at 19:10:11 UTC, Borislav Kosharov
wrote:
Something strange happens when I do this:
unittest {
import std.array, std.string;
denizzz:
says what sfTime* can not be implictly converted to sfTime*
Maybe it's a diagnostic bug. Please create a minimal example.
Bye,
bearophile
denizzz:
This message looks weird. I am spent hour to find this bug. :-(
Why aren't you just using code like this?
sfTime r = sfClock_getElapsedTime(sfPtr);
return Time(r);
I don't fully understand, it seems a diagnostic problem.
Please create a minimal test case that shows the problem.
On Tuesday, 11 June 2013 at 08:08:03 UTC, denizzz wrote:
sfClock_getElapsedTime return type actually defined in the
another file, typeid =
_D45TypeInfo_S8derelict5sfml211systemtypes6sfTime6__initZ
compilation causes:
dsfml/system.d(54): Error: static assert (is(sfTime ==
sfTime)) is
On Tuesday, 11 June 2013 at 11:22:15 UTC, bearophile wrote:
denizzz:
This message looks weird. I am spent hour to find this bug. :-(
Why aren't you just using code like this?
sfTime r = sfClock_getElapsedTime(sfPtr);
return Time(r);
sfTime* r = sfClock_getElapsedTime(sfPtr);
says what
On Tuesday, 11 June 2013 at 16:37:18 UTC, denizzz wrote:
sfTime* r = sfClock_getElapsedTime(sfPtr);
says what sfTime can not be implictly converted to sfTime
sfClock_getElapsedTime does not return a pointer.
You're going to continue to have type mismatches because you are
trying to use
On Wednesday, 12 June 2013 at 01:17:50 UTC, Mike Parker wrote:
On Tuesday, 11 June 2013 at 16:37:18 UTC, denizzz wrote:
sfTime* r = sfClock_getElapsedTime(sfPtr);
says what sfTime can not be implictly converted to sfTime
sfClock_getElapsedTime does not return a pointer.
You're going to
On Wednesday, 12 June 2013 at 02:01:27 UTC, denizzz wrote:
On Wednesday, 12 June 2013 at 01:17:50 UTC, Mike Parker wrote:
On Tuesday, 11 June 2013 at 16:37:18 UTC, denizzz wrote:
Ok, but why compiler says that types of these types is equal?
...that typeids of these types are equal?
On Tuesday, 11 June 2013 at 16:37:18 UTC, denizzz wrote:
On Tuesday, 11 June 2013 at 11:22:15 UTC, bearophile wrote:
denizzz:
This message looks weird. I am spent hour to find this bug.
:-(
Why aren't you just using code like this?
sfTime r = sfClock_getElapsedTime(sfPtr);
return Time(r);
301 - 400 of 531 matches
Mail list logo
