[Issue 7995] regression(2.059): D runtime initialization from C fails on OSX in 2.059, worked in 2.058
http://d.puremagic.com/issues/show_bug.cgi?id=7995 --- Comment #6 from Jacob Carlborg d...@me.com 2012-05-26 09:15:59 PDT --- New pull request: https://github.com/D-Programming-Language/druntime/pull/228 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Seg-fault interfacing C library (GSL)
Hi,
I am currently trying to call functions from the GNU Scientific
Library (GSL) with my code, and I observed a very strange
behaviour. The following test-program compiles, but generates a
Segmentation fault when run.
gsltest.d
--
import std.stdio;
extern (C) double gsl_sf_hyperg_2F1(double a, double b, double c,
double x);
void main() {
double f = 0.0025;
// The following line causes a crash
auto ret = f * gsl_sf_hyperg_2F1(1.0, 10.0, 11.0, 1.0 - f /
0.025);
// The following line should be identical, but it does not
cause the seg fault.
// auto ret = 0.0025 * gsl_sf_hyperg_2F1(1.0, 10.0, 11.0, 1.0 -
f / 0.025);
writeln(ret);
}
---
If you comment out the crashing line and comment in the line
below, the program runs and returns 0.015681, which is the
numerically correct result.
To compile and run the code, I used the following command line:
rdmd -L-L/opt/local/lib -L-lgsl -L-lgslcblas gsltest.d
I tested this on Unix and Mac OS X. Can anyone reproduce the
error and have an idea what is going on?
Cheers,
Stephan
[Issue 7675] std.format needs better exception messages
http://d.puremagic.com/issues/show_bug.cgi?id=7675
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-05-26
09:54:34 PDT ---
If anyone else is annoyed by this you can use a workaround like this:
/** Workaround for Issue 7675 - std.format needs better exception messages */
string safeFmt(string file = __FILE__, int line = __LINE__, T...)(string fmt, T
args)
{
auto specCount = count(fmt, %s);
enforce(specCount == T.length,
new Exception(format(Arg count %s doesn't match spec count %s.,
T.length, specCount), file, line));
return format(fmt, args);
}
That implies using %s exclusively and it only throws on argument count
mismatch, but it's still a shitload better than Error occurred somewhere, have
fun debugging!.
Throwing exceptions in Phobos with no information on what went wrong should be
*banned*.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Re: Seg-fault interfacing C library (GSL)
On Saturday, May 26, 2012 18:41:34 Stephan wrote: Hi, Please do not post to this list directly. It's intended for those wishing to receive updates to all of the bug reports on bugzilla. If you have a question about learning d, please post it in digitalsmarsD.Learn. If you have a question or something that you want to discuss about D in general, then post it in digitalmars.D. And if you have a bug report, please report it on bugzilla ( http://d.puremagic.com/issues ). - Jonathan M Davis
[Issue 7675] std.format needs better exception messages
http://d.puremagic.com/issues/show_bug.cgi?id=7675
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #2 from bearophile_h...@eml.cc 2012-05-26 11:57:34 PDT ---
(In reply to comment #1)
enforce(specCount == T.length,
new Exception(format(Arg count %s doesn't match spec count %s.,
T.length, specCount), file, line));
Andrei wants formatted printing to be sloppy, so currently this doesn't raise
an error:
import std.string;
void main() {
string res = format(%s , 1, 2);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Re: Seg-fault interfacing C library (GSL)
OK, sorry. I will post it on bugzilla then. Best, Stephan On Saturday, 26 May 2012 at 18:12:20 UTC, Jonathan M Davis wrote: On Saturday, May 26, 2012 18:41:34 Stephan wrote: Hi, Please do not post to this list directly. It's intended for those wishing to receive updates to all of the bug reports on bugzilla. If you have a question about learning d, please post it in digitalsmarsD.Learn. If you have a question or something that you want to discuss about D in general, then post it in digitalmars.D. And if you have a bug report, please report it on bugzilla ( http://d.puremagic.com/issues ). - Jonathan M Davis
[Issue 7675] std.format needs better exception messages
http://d.puremagic.com/issues/show_bug.cgi?id=7675 --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-05-26 12:42:38 PDT --- (In reply to comment #2) Andrei wants formatted printing to be sloppy, so currently this doesn't raise an error.. Right, but the OP code does raise an exception except it gives absolutely no information whatsoever on what went wrong. Reading a stack trace of a dozen template instantiations doesn't help either. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8152] New: Linking C library causes Seg-fault
http://d.puremagic.com/issues/show_bug.cgi?id=8152
Summary: Linking C library causes Seg-fault
Product: D
Version: D2
Platform: x86_64
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: stephan.schiff...@mac.com
--- Comment #0 from Stephan stephan.schiff...@mac.com 2012-05-26 14:29:20 PDT
---
The following program tries to trivially run a function from the GSL. It
compiles, but generates a segmentation fault when run.
gsltest.d
--
import std.stdio;
extern (C) double gsl_sf_hyperg_2F1(double a, double b, double c,
double x);
void main() {
double f = 0.0025;
auto ret = f * gsl_sf_hyperg_2F1(1.0, 10.0, 11.0, 1.0 - f /
0.025);
writeln(ret);
}
---
The program should return 0.015681, which is the
numerically correct result. Note that the bug can not be in the GSL itself, as
it works correctly when used with C or C++.
To compile and run the code, I used the following command line:
rdmd -L-L/opt/local/lib -L-lgsl -L-lgslcblas gsltest.d
(assuming that gel libraries are in /opt/local/lib)
This seems to be a bug related to how C library functions are called from D.
Stephan
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8153] New: Warning about toHash is incorrect
http://d.puremagic.com/issues/show_bug.cgi?id=8153 Summary: Warning about toHash is incorrect Product: D Version: unspecified Platform: x86_64 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: jmdavisp...@gmx.com --- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-26 15:05:26 PDT --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8153] Warning about toHash signature is incorrect on x86_64
http://d.puremagic.com/issues/show_bug.cgi?id=8153
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
Summary|Warning about toHash is |Warning about toHash
|incorrect |signature is incorrect on
||x86_64
--- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-26 15:09:58
PDT ---
Sorry, I accidentally hit enter. Here's the bug description:
This code:
struct S
{
size_t toHash() const pure
{
return 42;
}
string val;
}
void main()
{
}
results in this error with -w:
q.d(3): Warning: toHash() must be declared as extern (D) uint toHash() const
nothrow @safe, not const pure ulong()
The _correct_ signature for toHash is
size_t toHash() @safe const pure nothrow
The warning incorrectly lists uint. It should say size_t. It should probably
also say pure, but that might not be required yet given the flux that toHash,
toString, opEquals, et al. are in at the moment with regards to their required
attributes.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8152] Linking C library causes Seg-fault
http://d.puremagic.com/issues/show_bug.cgi?id=8152 --- Comment #1 from Stephan stephan.schiff...@mac.com 2012-05-26 16:56:44 PDT --- I ran the executable through the GNU debugger. Here is the output: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x 0x7fff912a86cd in misaligned_stack_error_entering_dyld_stub_binder () And most peculiar by the way: If I drop the variable f, but simply put 0.025 directly in front of the function, the program does NOT crash... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
