On Monday, 7 November 2016 at 17:12:32 UTC, Alex wrote:
dmd -c -of./app.o -debug -g -gc -O -profile -w ./app.d -vcolumns
dmd -of./app ./app.o -g -gc
Knowing this, I tried to find the option which does the
difference. This was the profile option. So, if I omit it, the
segmentation fault is
Ok, ok. Here, I pasted the code, minimized as far as I could.
There are 434 lines of code, sorry.
http://pastebin.com/UcZUc79g
The main is empty. This is intended. I still have the
segmentation fault.
Maybe, I have another hint:
If I comment all the attributes in the
private HeadUnshared!(T)
On 11/07/2016 12:21 PM, Alex wrote:
On Sunday, 6 November 2016 at 16:07:54 UTC, ag0aep6g wrote:
[...]
Very weird. Would be great if you could provide a test case. Doesn't
need to be minimal.
I would if I would know how... :) the problem is, setting up the
debugger itself was not a simple
On Sunday, 6 November 2016 at 16:07:54 UTC, ag0aep6g wrote:
On 11/06/2016 05:00 PM, Alex wrote:
On Sunday, 6 November 2016 at 15:13:56 UTC, Alex wrote:
ok... played with the code a little bit.
If I remove the @trusted attribute in line 657 inside atomic.d
everything works as expected...
Any
On 11/06/2016 05:00 PM, Alex wrote:
On Sunday, 6 November 2016 at 15:13:56 UTC, Alex wrote:
ok... played with the code a little bit.
If I remove the @trusted attribute in line 657 inside atomic.d
everything works as expected...
Any ideas, why it is so?
By the way, replacement with @safe
On Sunday, 6 November 2016 at 15:13:56 UTC, Alex wrote:
ok... played with the code a little bit.
If I remove the @trusted attribute in line 657 inside atomic.d
everything works as expected...
Any ideas, why it is so?
By the way, replacement with @safe works too...
ok... played with the code a little bit.
If I remove the @trusted attribute in line 657 inside atomic.d
everything works as expected...
Any ideas, why it is so?
On Sunday, 6 November 2016 at 08:48:14 UTC, SimonN wrote:
I'm not sure how to pass arbitrary dustmite arguments through
dub to dustmite. `dub dustmite -h' lists arguments.
When dustmite reduces your project to the empty project, maybe
try this from the dustmite website: "You can also surround
I'm not sure how to pass arbitrary dustmite arguments through dub
to dustmite. `dub dustmite -h' lists arguments.
When dustmite reduces your project to the empty project, maybe
try this from the dustmite website: "You can also surround code
that is not to be removed around the magic words
On Sunday, 6 November 2016 at 01:13:51 UTC, Vladimir Panteleev
wrote:
Try --program-status=139
(139 is 128 + 11)
tried
dub dustmite ../dm3 --program-status=139
which yields in
object.Exception@DustMite/dustmite.d(270): Initial test fails
(try using --no-redirect for details)
On Sunday, 6 November 2016 at 01:11:34 UTC, Alex wrote:
dub dustmite ../dm2 --program-status=11
Try --program-status=139
(139 is 128 + 11)
On Saturday, 5 November 2016 at 22:38:31 UTC, cym13 wrote:
Could you use DustMite to generate a minimal code sample
showing the bug?
https://github.com/CyberShadow/DustMite
tried
dub dustmite ../dm
which reduced my code to an empty main... :)
and tried
dub dustmite ../dm2
On Saturday, 5 November 2016 at 21:45:46 UTC, Alex wrote:
Hi everybody,
something strange is going on:
trying compiling and running my code after an update to 2.072,
I get a not very instructive segmentation fault (code -11).
[...]
Could you use DustMite to generate a minimal code sample
On 10/25/2016 11:30 AM, Benjamin Thaut wrote:
Please consider the following program:
[...]
I would assume that this program should run forever and never run out of
memory. But instead it triggers an assert inside alocator_list in pass
11. So I assume this is some bug in std.allocator?
I can
On Monday, 17 October 2016 at 14:01:26 UTC, Basile B. wrote:
Is this a bug or a case of hijacking protection ?
struct S
{
void test(void*, size_t){}
}
void test(ref S,void[]){}
void main()
{
ubyte[] a;
(*new S).test(a);
}
On Monday, 3 October 2016 at 11:40:00 UTC, deed wrote:
Unexpected auto-concatenation of string elements:
string[] arr = ["a", "b" "c"];// ["a", "bc"], length==2
int[] arr2 = [[1], [2] [3]];// Error: array index 3 is
out of bounds [2][0 .. 1]
//
On 10/03/2016 01:40 PM, deed wrote:
Unexpected auto-concatenation of string elements:
string[] arr = ["a", "b" "c"];// ["a", "bc"], length==2
int[] arr2 = [[1], [2] [3]];// Error: array index 3 is out of
bounds [2][0 .. 1]
// Error: array index 3 is
On Thursday, September 15, 2016 15:15:49 Jonathan M Davis via Digitalmars-d-
learn wrote:
> On Thursday, September 15, 2016 18:15:52 deed via Digitalmars-d-learn wrote:
> > I'm curious when you would need to do only `new Struct[](1000);`
> > instead of
> > `auto structs = new Struct[](1000);`?
>
>
On Thursday, September 15, 2016 18:15:52 deed via Digitalmars-d-learn wrote:
> I'm curious when you would need to do only `new Struct[](1000);`
> instead of
> `auto structs = new Struct[](1000);`?
Need to do? Probably never. It would be a pretty weird thing to do. But if
Struct has a destructor
On Thursday, 15 September 2016 at 14:42:13 UTC, Jonathan M Davis
wrote:
On Thursday, September 15, 2016 14:07:18 deed via
Digitalmars-d-learn wrote:
On Thursday, 15 September 2016 at 13:57:13 UTC, rikki
cattermole
wrote:
> Not a bug, it is never used.
I'd expect an "Error: ... no effect ..."
On Thursday, September 15, 2016 14:07:18 deed via Digitalmars-d-learn wrote:
> On Thursday, 15 September 2016 at 13:57:13 UTC, rikki cattermole
>
> wrote:
> > Not a bug, it is never used.
>
> I'd expect an "Error: ... no effect ..." from the compiler.
That would only work in fairly simplistic
On Thursday, 15 September 2016 at 13:57:13 UTC, rikki cattermole
wrote:
Not a bug, it is never used.
I'd expect an "Error: ... no effect ..." from the compiler.
Dne 15.9.2016 v 15:57 rikki cattermole via Digitalmars-d-learn napsal(a):
On 16/09/2016 1:54 AM, deed wrote:
void main ()
{
new int[](1);
}
Compiles with dmd 2.071.2-b2, but no code is generated for `new
int[](1);`.
Caused a bug due to:
char[] arr;
got updated to
char[] arr; new
On Thursday, 15 September 2016 at 13:54:44 UTC, deed wrote:
void main ()
{
new int[](1);
}
Compiles with dmd 2.071.2-b2, but no code is generated for `new
int[](1);`.
Caused a bug due to:
char[] arr;
got updated to
char[] arr; new char[](SIZE);
If it's considered a bug and someone would
On Thursday, 15 September 2016 at 14:00:47 UTC, koia wrote:
On Thursday, 15 September 2016 at 13:54:44 UTC, deed wrote:
void main ()
{
new int[](1);
}
Compiles with dmd 2.071.2-b2, but no code is generated for
`new int[](1);`.
Caused a bug due to:
char[] arr;
got updated to
char[] arr;
On 16/09/2016 1:54 AM, deed wrote:
void main ()
{
new int[](1);
}
Compiles with dmd 2.071.2-b2, but no code is generated for `new int[](1);`.
Caused a bug due to:
char[] arr;
got updated to
char[] arr; new char[](SIZE);
If it's considered a bug and someone would file it, I'd be thankful.
On 7/15/16 7:44 AM, ag0aep6g wrote:
On 07/15/2016 12:54 PM, dom wrote:
i just had a scenario like the one below. when calling .array on the
filterresult dmd goes nuts because of the init() function in Players.
Renaming to initialize() solved the problem.
Solution: As .init is used for struct
On 07/15/2016 12:54 PM, dom wrote:
i just had a scenario like the one below. when calling .array on the
filterresult dmd goes nuts because of the init() function in Players.
Renaming to initialize() solved the problem.
Solution: As .init is used for struct initialization and such
On Tuesday, 14 June 2016 at 03:40:01 UTC, Adam D. Ruppe wrote:
On Tuesday, 14 June 2016 at 03:15:04 UTC, Jonathan Marler wrote:
It actually is a free function
no, it isn't, it is on File.
Your code doesn't compile on my dmd (and indeed it shouldn't on
yours either unless you have a version
On Tuesday, 14 June 2016 at 03:15:04 UTC, Jonathan Marler wrote:
It actually is a free function
no, it isn't, it is on File.
Your code doesn't compile on my dmd (and indeed it shouldn't on
yours either unless you have a version mismatch. rdmd just calls
dmd, it doesn't produce its own
On Tuesday, 14 June 2016 at 01:35:32 UTC, Jeremy DeHaan wrote:
On Tuesday, 14 June 2016 at 01:05:46 UTC, Jonathan Marler wrote:
This code doesn't seem to work with rdmd. Is this a bug?
import std.stdio : byLine;
int main(string[] args)
{
foreach(line; stdin.byLine) {
}
On Saturday, 6 February 2016 at 14:15:04 UTC, rsw0x wrote:
I was playing around with alias templates and came across this,
I reduced it to:
---
struct A(alias C c){
auto foo(){
return c.i;
}
}
struct B{
C c;
A!c a;
}
struct C{
int i;
}
---
It gives me a "need 'this' for 'i'
The specification doesn't list (non-static) members a valid
template alias parameters:
http://dlang.org/spec/template.html#TemplateAliasParameter
I'd say support for this scenario is not implemented yet.
On Sunday, 10 January 2016 at 19:50:15 UTC, Tobi G. wrote:
On Sunday, 10 January 2016 at 19:07:52 UTC, Jesse Phillips
wrote:
On Sunday, 10 January 2016 at 18:09:23 UTC, Tobi G. wrote:
The bug has been fixed...
Do you have a link for the fix? Is there a BugZilla entry?
Yes sure..
On Friday, 8 January 2016 at 13:53:06 UTC, Guillaume Chatelet
wrote:
On Friday, 8 January 2016 at 13:22:40 UTC, Tobi G. wrote:
On Friday, 8 January 2016 at 12:13:59 UTC, Guillaume Chatelet
wrote:
On Friday, 8 January 2016 at 12:07:05 UTC, Tobi G. wrote:
No, sorry. Under Windows DMD v2.069.2 it
The bug has been fixed...
On Sunday, 10 January 2016 at 09:41:16 UTC, Keywan Ghadami wrote:
On Friday, 8 January 2016 at 13:53:06 UTC, Guillaume Chatelet
wrote:
I still do not understand half of the syntax(still learning)
but my guess is that it is a bug in the csv reader:
In
On Sunday, 10 January 2016 at 18:09:23 UTC, Tobi G. wrote:
The bug has been fixed...
Do you have a link for the fix? Is there a BugZilla entry?
On Sunday, 10 January 2016 at 19:07:52 UTC, Jesse Phillips wrote:
On Sunday, 10 January 2016 at 18:09:23 UTC, Tobi G. wrote:
The bug has been fixed...
Do you have a link for the fix? Is there a BugZilla entry?
Yes sure..
https://issues.dlang.org/show_bug.cgi?id=15545
and the fix at github
On Friday, 8 January 2016 at 09:59:26 UTC, Guillaume Chatelet
wrote:
Any idea ?
No, sorry. Under Windows DMD v2.069.2 it works perfectly in both
cases.
Which compiler do you use?
You could run DMD with the -g option. This will print often more
useful output, if it fails.
togrue
On Friday, 8 January 2016 at 13:22:40 UTC, Tobi G. wrote:
On Friday, 8 January 2016 at 12:13:59 UTC, Guillaume Chatelet
wrote:
On Friday, 8 January 2016 at 12:07:05 UTC, Tobi G. wrote:
No, sorry. Under Windows DMD v2.069.2 it works perfectly in
both cases.
Which compiler do you use?
-
On Friday, 8 January 2016 at 12:07:05 UTC, Tobi G. wrote:
No, sorry. Under Windows DMD v2.069.2 it works perfectly in
both cases.
Which compiler do you use?
- DMD64 D Compiler v2.069.2 on Linux.
- LDC 0.16.1 (DMD v2.067.1, LLVM 3.7.0)
So if it works on windows I guess it's a problem with
On Friday, 8 January 2016 at 12:13:59 UTC, Guillaume Chatelet
wrote:
On Friday, 8 January 2016 at 12:07:05 UTC, Tobi G. wrote:
No, sorry. Under Windows DMD v2.069.2 it works perfectly in
both cases.
Which compiler do you use?
- DMD64 D Compiler v2.069.2 on Linux.
- LDC 0.16.1 (DMD v2.067.1,
On Saturday, 14 November 2015 at 05:44:44 UTC, Anonymous wrote:
I was playing with some code someone posted on the forum that
involved opDispatch and compile time parameters. I pasted it in
a file named templOpDispatch.d, ran it, and got an error. Then
I noticed if I renamed the file it
On Saturday, 14 November 2015 at 05:44:44 UTC, Anonymous wrote:
Then running 'rdmd templOpDispatch.d' produces:
std.process.ProcessException@std\process.d(568): Failed to
spawn new process (The requested operation requires elevation.)
This is a Windows quirk. When they introduced UAC in
On Thursday, 8 October 2015 at 09:01:32 UTC, Dominikus Dittes
Scherkl wrote:
On Wednesday, 7 October 2015 at 16:25:02 UTC, Marc Schütz wrote:
Lionello Lunesu posted a PR that should fix this:
https://github.com/D-Programming-Language/dmd/pull/1913
See also the discussion in the linked bug
On Wednesday, 7 October 2015 at 16:25:02 UTC, Marc Schütz wrote:
Lionello Lunesu posted a PR that should fix this:
https://github.com/D-Programming-Language/dmd/pull/1913
See also the discussion in the linked bug report.
Unfortunately it seems it's been forgotten since then...
Meanwhile I
On 10/7/15 1:27 AM, Laeeth Isharc wrote:
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven Schveighoffer wrote:
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your code ends up
being portable ;) (It's trivial to do, obviously).
ptrdiff_t
On Thursday, 8 October 2015 at 13:32:17 UTC, Steven Schveighoffer
wrote:
On 10/7/15 1:27 AM, Laeeth Isharc wrote:
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven
Schveighoffer wrote:
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your
code
On Wednesday, 7 October 2015 at 05:27:12 UTC, Laeeth Isharc wrote:
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven
Schveighoffer wrote:
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your
code ends up
being portable ;) (It's trivial to do,
On Wednesday, 7 October 2015 at 07:38:44 UTC, Andrea Fontana
wrote:
On Wednesday, 7 October 2015 at 05:27:12 UTC, Laeeth Isharc
wrote:
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven
Schveighoffer wrote:
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos
On Tuesday, 6 October 2015 at 14:46:56 UTC, tcak wrote:
Maybe I am just too stressed out to see the problem.
[code]
import std.stdio;
void main(){
size_t dec = 0;
writeln( dec, " ", (dec <= -10), " ", (dec >= 10), " ", ((dec
<= -10) || (dec >= 10)) );
}
[/code]
[output]
0 true
On Wednesday, 7 October 2015 at 02:53:32 UTC, Steven
Schveighoffer wrote:
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your code
ends up
being portable ;) (It's trivial to do, obviously).
ptrdiff_t
-Steve
It seems unnatural to use such a
On Tuesday, 6 October 2015 at 14:46:56 UTC, tcak wrote:
Maybe I am just too stressed out to see the problem.
[code]
import std.stdio;
void main(){
size_t dec = 0;
writeln( dec, " ", (dec <= -10), " ", (dec >= 10), " ", ((dec
<= -10) || (dec >= 10)) );
}
[/code]
[output]
0 true
On Tuesday, 6 October 2015 at 14:46:56 UTC, tcak wrote:
void main(){
size_t dec = 0;
How is it generating "true" for (dec <= -10) ? Is there a
special casting or something?
size_t is unsigned, so the -10 is cast to unsigned too for the
comparison which yields some huge number.
On 10/6/15 7:21 PM, Laeeth Isharc wrote:
could we have ssize_t defined in phobos somewhere so your code ends up
being portable ;) (It's trivial to do, obviously).
ptrdiff_t
-Steve
On Tuesday, 6 October 2015 at 14:55:23 UTC, Adam D. Ruppe wrote:
On Tuesday, 6 October 2015 at 14:46:56 UTC, tcak wrote:
void main(){
size_t dec = 0;
How is it generating "true" for (dec <= -10) ? Is there a
special casting or something?
size_t is unsigned, so the -10 is cast to
On Tuesday, 6 October 2015 at 14:46:56 UTC, tcak wrote:
Maybe I am just too stressed out to see the problem.
[code]
import std.stdio;
void main(){
size_t dec = 0;
writeln( dec, " ", (dec <= -10), " ", (dec >= 10), " ", ((dec
<= -10) || (dec >= 10)) );
}
[/code]
[output]
0 true
This compiles with enabled warnings:
---
int f()
{
while(true){}
assert(false);
}
---
thank you :) works now
using DMD32 D Compiler v2.068.0 on windows x64
On Thursday, 17 September 2015 at 19:43:02 UTC, H. S. Teoh wrote:
On Thu, Sep 17, 2015 at 07:32:13PM +, ddos via
Digitalmars-d-learn wrote:
http://pastebin.com/fknwgjtz
i tried to call fibers in a loop forever, to multiplex some
networking
client worker fibers and a listener fiber
it
On Thu, Sep 17, 2015 at 07:32:13PM +, ddos via Digitalmars-d-learn wrote:
> http://pastebin.com/fknwgjtz
>
> i tried to call fibers in a loop forever, to multiplex some networking
> client worker fibers and a listener fiber
> it seems to work correctly with for(int i=0;i<1;)
>
> with
On Thursday, 17 September 2015 at 19:32:16 UTC, ddos wrote:
source\app.d(72): Warning: statement is not reachable
What's there? Anything after an endless loop is potentially
unreachable and dub treats warnings as errors.
With the for loop, the compiler can't be as sure that it is
endless
On Thursday, 17 September 2015 at 19:35:05 UTC, Adam D. Ruppe
wrote:
What's there? Anything after an endless loop is potentially
unreachable and dub treats warnings as errors.
i see, thx
On 09/17/2015 09:47 PM, ddos wrote:
yeah i tried for(;;) and it generates the same warning :)
sure, here is the full example, it's not too long anyways
( the example doesn't make much sense tho because socket.accept is
blocking :P )
http://pastebin.com/9K0wRRD6
ps: pastebin needs D support :-D
On Thursday, 17 September 2015 at 19:47:15 UTC, ddos wrote:
yeah i tried for(;;) and it generates the same warning :)
sure, here is the full example, it's not too long anyways
( the example doesn't make much sense tho because socket.accept
is blocking :P )
http://pastebin.com/9K0wRRD6
Yeah,
fix - https://github.com/D-Programming-Language/phobos/pull/3524
On Monday, 29 June 2015 at 14:28:06 UTC, anonymous wrote:
On Monday, 29 June 2015 at 12:04:46 UTC, Jonathan M Davis wrote:
You haven't declared an immutable constructor, so you can't
construct an immutable Foo.
That's not what's happening. Constructing an immutable Foo
works just fine.
On Sunday, June 28, 2015 11:37:59 Jack Applegame via Digitalmars-d-learn wrote:
I don't see any reason why it should not compile.
import std.array;
import std.range;
import std.algorithm;
class Foo {
}
void main() {
auto result = iota(3).map!(i = new immutable Foo).array();
}
On Monday, 29 June 2015 at 12:04:46 UTC, Jonathan M Davis wrote:
You haven't declared an immutable constructor, so you can't
construct an immutable Foo.
That's not what's happening. Constructing an immutable Foo works
just fine.
https://issues.dlang.org/show_bug.cgi?id=14751
I'd say bug, I think the array function is trying an optimization
it shouldn't be trying for immutable classes.
On Mon, 29 Jun 2015 05:04:36 -0700
Jonathan M Davis via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Sunday, June 28, 2015 11:37:59 Jack Applegame via
Digitalmars-d-learn wrote:
I don't see any reason why it should not compile.
import std.array;
import std.range;
On 05/10/2015 10:18 AM, Jack Applegame wrote:
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
Error: function B.test () is not callable using argument types (int)
It is a concept called name
On Sunday, May 10, 2015 10:48:33 Ali Çehreli via Digitalmars-d-learn wrote:
On 05/10/2015 10:18 AM, Jack Applegame wrote:
code:
class A {
void test(int) {}
}
class B : A {
void test() {
super.test(1); // compiles
test(10); // error
}
}
Jack Applegame wrote:
test(10); // error
One can import the declaration by using an alias:
class A {
void test(int) {}
}
class B : A {
alias test= super.test;
void test() {
super.test(1); // compiles
test(10); // compiles
}
}
-manfred
Ok, it's a feature. Thanks.
On 1/19/2015 2:35 PM, tcak wrote:
On Monday, 19 January 2015 at 04:18:47 UTC, tcak wrote:
On Sunday, 18 January 2015 at 22:25:39 UTC, anonymous wrote:
On Sunday, 18 January 2015 at 18:07:05 UTC, tcak wrote:
After these, it works perfectly. I hope this can be fixed in next
version.
Please
On Monday, 19 January 2015 at 05:35:46 UTC, tcak wrote:
Fixed shm.d file is put on issue page. If someone could put a
pull request on Github with it.
shmid_ds is on version(linux) part is fixed up on it, and works
properly. But tested on 64-bit system only.
Aand it's in:
On Monday, 19 January 2015 at 04:18:47 UTC, tcak wrote:
On Sunday, 18 January 2015 at 22:25:39 UTC, anonymous wrote:
On Sunday, 18 January 2015 at 18:07:05 UTC, tcak wrote:
After these, it works perfectly. I hope this can be fixed in
next version.
Please file a bug at
On Sunday, 18 January 2015 at 22:25:39 UTC, anonymous wrote:
On Sunday, 18 January 2015 at 18:07:05 UTC, tcak wrote:
After these, it works perfectly. I hope this can be fixed in
next version.
Please file a bug at https://issues.dlang.org/. And since you
seem to know how to fix it, maybe you
On Sunday, 18 January 2015 at 16:06:39 UTC, tcak wrote:
I create a shared memory by using shmget. And attach to it by
using shmat.
Finally, I use shmctl to get statistics to learn number of
attachments to
that shared memory. According to documentation
(linux.die.net/man/2/shmat), number of
On Sunday, 18 January 2015 at 18:07:05 UTC, tcak wrote:
After these, it works perfectly. I hope this can be fixed in
next version.
Please file a bug at https://issues.dlang.org/. And since you
seem to know how to fix it, maybe you can make a pull request via
GitHub, too?
On Thursday, 23 October 2014 at 21:42:46 UTC, anonymous wrote:
On Thursday, 23 October 2014 at 21:17:25 UTC, deed wrote:
Some testing can be found on http://dpaste.dzfl.pl/5f55f4152aa8
for both Windows and Linux. This just illustrates the sin
function.
I think the tests marked [1] are
On 10/23/14 2:46 PM, deed wrote:
On Thursday, 23 October 2014 at 18:26:53 UTC, Steven Schveighoffer wrote:
On 10/23/14 2:18 PM, deed wrote:
Using equality is not a good idea with floating point.
The compiler will on a whim, or depending on whether it can inline or
not, use higher precision
OK, I tried with OSX 64-bit compiler. Perhaps 32 bit would not
fare as well. What platform are you testing on?
Have tried Linux and Windows 64-bit and it seems to be an issue
when compiled with -m32. Tests are provided here
http://dpaste.dzfl.pl/5f55f4152aa8.
I agree that one cannot compare
--
Why bother?
import std.algorithm : max;
F fun (F a, F b) { return max(a,b) + 1.; }
unittest { assert (gun(1, 2) == gun(2, 1)); } // Passes
F pun (F a, F b) { return sin(max(a,b)); }
unittest { assert (fun(1, 2) == fun(2, 1)); } // Fails
// Fun, gun, pun...
unittest { assert (fun(1, 2)
On 10/23/14 1:08 PM, deed wrote:
// DMD v2.066.0
// All asserts pass (!)
Using equality is not a good idea with floating point.
The compiler will on a whim, or depending on whether it can inline or
not, use higher precision floats, changing the outcome slightly.
I cannot say for certain
assert (fasin(a) != fasin(a)); // ?
assert (facos(a) != facos(a)); // ?
Too quick there.. But:
assert (fasin(0.5) != fasin(0.5)); // ?
assert (facos(0.5) != facos(0.5)); // ?
Using equality is not a good idea with floating point.
The compiler will on a whim, or depending on whether it can
inline or not, use higher precision floats, changing the
outcome slightly.
I cannot say for certain whether this explains all the issues
you have, the very last one seems
On 10/23/14 2:18 PM, deed wrote:
Using equality is not a good idea with floating point.
The compiler will on a whim, or depending on whether it can inline or
not, use higher precision floats, changing the outcome slightly.
I cannot say for certain whether this explains all the issues you
have,
On Thursday, 23 October 2014 at 18:26:53 UTC, Steven
Schveighoffer wrote:
On 10/23/14 2:18 PM, deed wrote:
Using equality is not a good idea with floating point.
The compiler will on a whim, or depending on whether it can
inline or
not, use higher precision floats, changing the outcome
On Thu, Oct 23, 2014 at 02:26:52PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 10/23/14 2:18 PM, deed wrote:
[...]
Now, if fun's body is { return sin(a); }, the behaviour changes to:
auto c = fun(100);
auto d = fun(100);
assert (c == d); // Ok
assert
A similar problem was recently (about 2-3 weeks ago IIRC) seen
in one of
the Phobos PR's. It appears to be related to the autoextension
of float
to double (or double to real, I forget which) in certain
contexts on
Windows. @deed Could you please try to reduce the failing test
to a
minimal
Some testing can be found on http://dpaste.dzfl.pl/5f55f4152aa8
for both Windows and Linux. This just illustrates the sin
function.
Replacing double with real makes everything pass on Linux Mint 16
with -m32 and -m64. Replacing double with float seems to give the
same problems as before, but
On Thursday, 23 October 2014 at 21:17:25 UTC, deed wrote:
Some testing can be found on http://dpaste.dzfl.pl/5f55f4152aa8
for both Windows and Linux. This just illustrates the sin
function.
I think the tests marked [1] are expected to fail. They involve
converting one operand of the
On Thursday, 23 October 2014 at 21:42:46 UTC, anonymous wrote:
On Thursday, 23 October 2014 at 21:17:25 UTC, deed wrote:
Some testing can be found on http://dpaste.dzfl.pl/5f55f4152aa8
for both Windows and Linux. This just illustrates the sin
function.
I think the tests marked [1] are
On 08/27/2014 07:38 AM, Lemonfiend wrote:
I get:
src\app.d(19): Error: None of the overloads of 'foo' are callable using
argument types (C3), candidates are:
src\app.d(28):main.foo(C1 c)
src\app.d(38):main.foo(C2 c)
It does work when I explicitly import c3.foo.
--- file app.d
201 - 300 of 404 matches
Mail list logo
