[Issue 1001] print stack trace (in debug mode) when program die
http://d.puremagic.com/issues/show_bug.cgi?id=1001 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #27 from nfx...@gmail.com 2010-08-22 23:19:26 PDT --- Note that Tango has a full implementation for backtraces both on Windows and Linux with demangled function names, files and line numbers. They are shown on uncatched exceptions, segfaults, or when explicitly requested. Only requirements are that the D program got compiled with debug infos switched on, and that backtracing explicitly is enabled by importing tango.core.tools.TraceException. Of course Phobos can use the Tango BSD implementation since Phobos switched to Boost license, but it shows that it's very possible. I wish the Phobos team good luck duplication the functionality. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: tupper fails
Excerpts from Yao G.'s message of Sun Aug 22 20:30:08 -0400 2010: > Hi. > > This newsgroup is used only for messages from D's Bugzilla. Maybe you > could repost this message on the digitalmars.D.learn NG? > My mistake. I'll do that. Erin
[Issue 4716] New: std.stdio.input() or similar
http://d.puremagic.com/issues/show_bug.cgi?id=4716
Summary: std.stdio.input() or similar
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-08-22 20:02:39 PDT ---
If not already present, a function template similar to this one may be useful
for the std.stdio module. Similar functions are present in Basic and Python
languages:
T input(T)(string msg) {
write(msg);
auto read = readln();
static if (!is(T == string) && !is(T == dstring) &&!is(T == wstring))
read = read.strip();
return to!T(read);
}
To be used mostly in scripts, as:
double x = input!double("Enter value x: ");
Its name may be changed if there is collision with something different, but it
needs to be simple, given its purpose.
This function may be made much more refined, but I suggest to keep it simple.
Even the static if it contains is more complex than originally thought.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4715] New: Bad error message with update for already defined variable
http://d.puremagic.com/issues/show_bug.cgi?id=4715
Summary: Bad error message with update for already defined
variable
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-08-22 19:48:41 PDT ---
This wrong D2 program:
void main() {
int foo = 1;
int foo = 1;
}
Produces a good error message (dmd 2.048):
test.d(3): Error: declaration test.main.foo is already defined
But this similar wrong program:
void main() {
int foo = 1;
int foo -= 1;
}
Produces two wrong error messages:
test.d(3): semicolon expected, not '-='
test.d(3): found '-=' instead of statement
I'd like this second situation to generate the same error as before.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Re: tupper fails
Hi. This newsgroup is used only for messages from D's Bugzilla. Maybe you could repost this message on the digitalmars.D.learn NG? -- Yao G.
tupper fails
Hi All -
I'm just getting started with D, and I'm liking it so far, thanks to
everyone for all the hard work.
I was doing some string work and found that toupper() is failing on my char[]
array, although tolower() does work. E.g. these two examples:
char[] s;
s ~= "Hello";
auto s_low = s.tolower();
auto s_up = s.toupper();
The tolower works but the toupper fails (error at the bottom of this message).
For reference I'm using 2.048.
I noticed that tolower() and toupper() have different implementations, although
there was a section commented out in tolower() that looks just like the toupper
implementation.
I converted toupper() to use essentially the same code as tolower() and all
seems to work well. e.g.
S toupper(S)(S s) if (isSomeString!S)
{
foreach (i, dchar c; s)
{
if (!std.uni.isUniLower(c)) continue;
auto result = s[0.. i].dup;
foreach (dchar c; s[i .. $])
{
if (std.uni.isUniLower(c))
{
c = std.uni.toUniUpper(c);
}
result ~= c;
}
return cast(S) result;
}
return s;
}
Perhaps toupper() was in the midst of being changed when this snapshot of the
code was made? Anyway, I thought I would bring it to your attention.
Thanks again,
Erin Scott Sheldon
/home/esheldon/local/dmd2/linux/bin/../../src/phobos/std/string.d(968): Error:
cannot implicitly convert expression (changed ?
cast(const(char)[])assumeUnique(r) : s) of type const(char)[] to char[]
/home/esheldon/local/dmd2/linux/bin/../../src/phobos/std/string.d(11): Error:
template instance std.string.toupper!(char[]) error instantiating
[Issue 4714] New: Cannot return ref this when struct has invariant
http://d.puremagic.com/issues/show_bug.cgi?id=4714
Summary: Cannot return ref this when struct has invariant
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmail.com
--- Comment #0 from Jonathan M Davis 2010-08-22
14:41:29 PDT ---
The following code
import std.stdio;
struct S
{
ref S hello()
{
writeln("hello");
return this;
}
invariant()
{
}
}
void main()
{
S().hello().hello().hello();
}
results in the error
prog.d(9): Error: __result = this is not mutable
prog.d(9): Error: __result = this is not an lvalue
If I remove the invariant, it compiles and runs just fine. Also, if I compile
with -release, it compiles and runs just fine. But if that invariant is there
and compiled in (as it would be without -release), it won't compile. The same
goes for out if I use it instead of invariant.
This makes it very difficulty to use the idiom where you have member functions
returning references to the object so that you can chain function calls. That
is, it's impossible to use that idiom and use invariants or out contracts. I
assume that something in the invariant and out code dealing with the return
value does not take into account the fact that you could return a reference to
this from a struct's member function.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4302] Regression(2.046, 1.061): compiler errors using startsWith in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=4302 --- Comment #7 from Rainer Schuetze 2010-08-22 13:56:02 PDT --- It seems to me that the module member list is not searched when looking for existing template instantations, but templdecl->instances. The failed template instance is currently removed from that array, so it should do no extra harm to remove it from the member list aswell. issue 4269 does not deal with templates, so it will not change with a fix to this bug. It's kind of the reverse problem: the declaration exists in the member list, but is not revisited after causing an error once. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
http://d.puremagic.com/issues/show_bug.cgi?id=1001 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmail.com --- Comment #26 from Jonathan M Davis 2010-08-22 13:50:51 PDT --- I don't know what the current state of stack traces is overall or where it is with regards to work being done on them, but I would point out that all you get on Linux right now is a list of addresses. e.g. object.except...@gregorian.d(241): Invalid year. ./test() [0x805936a] ./test() [0x804b168] ./test() [0x804b269] ./test() [0x805b9fb] ./test() [0x8068d3c] ./test() [0x8060bed] ./test() [0x8068c57] ./test() [0x8061a88] ./test() [0x80619b0] ./test() [0x8061956] /opt/lib32/lib/libc.so.6(__libc_start_main+0xe6) [0xf75cdc76] ./test() [0x8049341] So, as it stands (using dmd 2.048), stack traces on Linux are pretty useless. I would assume that Sean is aware of this, but I thought that I should post a reminder of the current state of stack traces on Linux. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4152] Function alias forward reference error
http://d.puremagic.com/issues/show_bug.cgi?id=4152
--- Comment #1 from bearophile_h...@eml.cc 2010-08-22 13:26:09 PDT ---
Another case, maybe with a different cause:
struct Foo(alias f) {}
Foo!main baz;
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4302] Regression(2.046, 1.061): compiler errors using startsWith in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=4302 --- Comment #6 from Don 2010-08-22 12:53:11 PDT --- (In reply to comment #5) > Or maybe even simpler: it's probably not necessary to add the template as a > member to the module if it is instantiated in a "static if" or similar. I think you're right. Maybe it should not be added, if it is only instantiated in an "is" expression (rather using "static if" as the criterion). But that might make compile times blow out, if an is() occurs in a loop. That may be the root cause of bug 4269 and bug 3996, as well. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4712] Issue of destructor for temporary instance of structs
http://d.puremagic.com/issues/show_bug.cgi?id=4712 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 2010-08-22 12:43:53 PDT --- Is this the same as bug 3516? The fact that turning on the optimiser is not mentioned there, and may indicate it's a different bug. But they seem to be closely related. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4713] New: PATCH for interface generation: cleanup, bugfixes and prettyprinting
http://d.puremagic.com/issues/show_bug.cgi?id=4713 Summary: PATCH for interface generation: cleanup, bugfixes and prettyprinting Product: D Version: 2.041 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: norb...@nemec-online.de --- Comment #0 from Norbert Nemec 2010-08-22 11:21:54 PDT --- Created an attachment (id=736) series of patches These patches (against DMD 2.048) affect the code for automatic interface (.di file) generation (activated by -H command line option). * internal code cleanup and simplification * automatic indentation * three bugfixes (these bugs made autogenerated interfaces of phobos2 uncompilable) Apply in order. Each patch should leave the code in working order (compile&testrun). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4264] Support opApply in std.algorithm, std.range where possible
http://d.puremagic.com/issues/show_bug.cgi?id=4264 --- Comment #9 from bearophile_h...@eml.cc 2010-08-22 07:48:32 PDT --- > Maybe you should bring it up on the newsgroup. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=115950 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4264] Support opApply in std.algorithm, std.range where possible
http://d.puremagic.com/issues/show_bug.cgi?id=4264 --- Comment #8 from bearophile_h...@eml.cc 2010-08-22 07:39:44 PDT --- Thank you for your answer David Simcha. > Since everything you mention except the opApply issue is fixed either > in 2.048 or in SVN, Yes, indeed now all tests but the one that uses map() work. I agree with more or less all your points here. And I have no final answer for your doubts. Here are few comments. > Even if these get fixed, supporting ref correctly would be non-trivial > enough that I don't want to implement everything w/o ref support and > then have to go back later and add ref support. I see. Working and fixing the std lib is a lot of work, so I suggest to keep Phobos as short (as in number of lines) as possible, so when bugs gets fixed you don't need a week to update it. A possible good solution is to wait and not support opApply until those bugs are fixed, to reduce your work. Sometimes the typical laziness of the programmer is positive. > 2. If we start building higher order iterables out of opApply, things could > become slow as molasses through multiple layers of delegate calls. I know LDC > can inline these at least in simple cases, but what about when you have N > 1 > levels of them? LDC can currently inline one level of opApply, but probably not much more than that. Performance may indeed be reduced (even if we assume LLVM will get a bit better with time). On the other hand: - D is not a functional language, D programmers don't write map(filter(chain(map(... all the time. They usually use no more than one or two level of lazy chaining. - Several operations (like zip) are not possible with opApply, so this reduces the places where they may be abused and where they can slow down code. - In a normal program a good percentage of its code doesn't need to be high-performance, for example you need to covert to numbers few (no more than 5) strings coming from args[] into numbers, and you use a map!(to!(int))(args[1..$]). Many (but not all) of the usages of std.algorithm are to shorten code, to make it more readable or less buggy, but they are not used where max performance is necessary. This means that in practice a map() performed on a struct that defines opApply is often not a performance problem. (But programmers will need to be careful). > 3. This is a big enough change to the way std.range/std.algorithm work that I > think it needs to be discussed first, rather than just being checked in one > day > like a bug fix or minor enhancement. Maybe you should bring it up on the > newsgroup. I will write a small post about this in the main D newsgroup soon then. I don't have a final answer for your doubts. Generally I am not for pure solutions, I think that ranges are good, but life is complex, and if you try to cram everything into a single abstraction, you will have problems. If std.algorithm doesn't support opApply at all, then opApply itself becomes much less useful. In D1 I have seen that you can implement most of std.algorithm using opApply only. Supporting opApply in Phobos may be a lot of work, but it's work done once. Then all D programs are able to use this hard work. This is why I like std libs as flexible as possible, to make them support both fixed-sized arrays and opApply, because this later makes user code simpler and more uniform, and this Python shows that this usage uniformity is _very_ important to make the language (its std lib) handy and quick to use. Another thing about ranges is more general. opApply and ranges may be used for the same purposes, like to create a lazy generator of items, or to offer a way to scan the leaves of a tree through a simple foreach. But if you try to write a tree visit using opApply or using the Range protocol you see that they are not the same thing. You may see other examples here: http://code.activestate.com/recipes/221457/ For example (Python 2.x code): # Inverse Gray code def A006068(): yield 0 for x in A006068(): if x & 1: yield 2*x+1 yield 2*x else: if x: yield 2*x yield 2*x+1 It's not too much hard to implement this using opApply, the code is similar to that Python code, just much more noisy. But if you use the Range protocol you need to manage the state manually. With this I am trying to say that the Range protocol doesn't replace opApply, there are algorithms more naturally implemented with opApply. If you try to cram everything into the Range idea, you risk losing something. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4703] Ambiguously designed array syntax
http://d.puremagic.com/issues/show_bug.cgi?id=4703 --- Comment #9 from Andrej Mitrovic 2010-08-22 07:26:10 PDT --- I did not know that, thanks! :) (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #2) > > > > Look on http://www.digitalmars.com/d/2.0/arrays.html section "Static > > > > Initialization of Static Arrays" (btw. Walter could you create an index > > > > of some > > > > sort, so one can post direct links, or, you know, actually find stuff > > > > without > > > > having to go through the whole damn spec? if ddoc wasn't shit, it'd do > > > > that > > > > automatically). > > > > > > I usually check the source of the page, many sections have an > > > so > > > you can create direct links if you **really** need them. > > > > > > Yes, I agree it sucks hard, an index would be the right thing to do, but > > > maybe > > > you didn't knew the "workaround". > > > > That's nice, but you still can't make a URL out of that so others can view > > the > > exact title, right? > > > > I had this problem when I was doing a review of the spec, I had to put > > quotes > > around the title to easily find the section since there's a shortage of href > > links. > > Yes you can, for example this is the link to the section mentioned by nfxjfg > in > comment 2: > > http://www.digitalmars.com/d/2.0/arrays.html#static-init-static -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4712] New: Issue of destructor for temporary instance of structs
http://d.puremagic.com/issues/show_bug.cgi?id=4712
Summary: Issue of destructor for temporary instance of structs
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: zan77...@nifty.com
--- Comment #0 from SHOO 2010-08-22 06:29:06 PDT ---
This code doesn't work!
import std.stdio;
auto func(int A = int.init)()
{
struct XXX
{
int a;
~this(){ writeln("dtor"); }
}
return XXX();
}
void main()
{
writeln("start");
{
auto x = func!();
}
writeln("end");
}
result:
start
dtor
end
object.Error: Access Violation
If I remove the destructor, it runs correctly.
Or I set -O switch to compiler, it runs correctly, too.
Workaround for this bug is making dummy constructor:
import std.stdio;
auto func(int A = int.init)()
{
struct XXX
{
int a;
this(int aa){ a = aa; writeln("ctor"); }
~this(){ writeln("dtor"); }
}
return XXX(A);
}
void main()
{
writeln("start");
{
auto x = func!();
}
writeln("end");
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4709] const struct leads DMD terminated abnormally
http://d.puremagic.com/issues/show_bug.cgi?id=4709
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc 2010-08-22 06:25:58 PDT ---
It's the undefined Bar inside a const struct that causes the problem:
const struct Foo {
Bar* p;
}
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4711] New: Incorrect handling of && operator with void operand
http://d.puremagic.com/issues/show_bug.cgi?id=4711
Summary: Incorrect handling of && operator with void operand
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ersin...@gmail.com
--- Comment #0 from Ersin Er 2010-08-22 02:51:37 PDT ---
The following code compiles and outputs "1 = 1" as expected when executed:
1 == 1 && writeln("1 = 1");
However, the following code fails to compile (although it should not):
1 == 2 && writeln("1 = 2");
The compiler error is as follows:
Error: integral constant must be scalar type, not void
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4710] New: writeln crashes when called from C code.
http://d.puremagic.com/issues/show_bug.cgi?id=4710
Summary: writeln crashes when called from C code.
Product: D
Version: D2
Platform: x86
OS/Version: Mac OS X
Status: NEW
Severity: major
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: kenn...@gmail.com
--- Comment #0 from kenn...@gmail.com 2010-08-22 01:44:15 PDT ---
Given the following content:
// x.d
import std.stdio;
extern (C) void foo() {
writeln("1");
}
// y.c
void foo(void);
int main () {
foo();
return 0;
}
And compile and run with
gcc -c -m32 y.c -o y.o
dmd x.d y.o -ofx
./x
Result in a Bus Error on Mac OS X. (I am using dmd r620, druntime r370 and
Phobos r1900.)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4708] expose rt.trace and rt.cover api's
http://d.puremagic.com/issues/show_bug.cgi?id=4708 --- Comment #2 from Brad Roberts 2010-08-22 00:56:34 PDT --- Ok.. ignore most of #1, I should have been using -profile instead of -cov. Of course, that just further outlines the problems caused by having the two result files generated with just the column headers merely by setting the destination file names. Compiling with -profile and running the sample code below produces the two files as expected: :: test_results/runnable/hello-profile.d.trace.def :: FUNCTIONS _Dmain _D5hello8showargsFAAaZv :: test_results/runnable/hello-profile.d.trace.log :: -- 1 _Dmain _D5hello8showargsFAAaZv 1 141436 141436 -- _Dmain 0 142088 652 1 _D5hello8showargsFAAaZv Timer Is 3579545 Ticks/Sec, Times are in Microsecs Num TreeFuncPer CallsTimeTimeCall 1 39512 39512 39512 _D5hello8showargsFAAaZv 1 39694 182 182 _Dmain -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4708] expose rt.trace and rt.cover api's
http://d.puremagic.com/issues/show_bug.cgi?id=4708
--- Comment #1 from Brad Roberts 2010-08-22 00:51:04 PDT
---
Merely adding the calls to set the trace log files is enough to cause the files
to be created, even without -cov. This is due to the calls being enough to
drag in the module and it's shared this/~this are invoked.
Also, for a simple test case, no trace results other than the file headers are
being produced:
module hello;
extern(C)
{
int printf(const char*, ...);
int trace_setlogfilename(string name);
int trace_setdeffilename(string name);
}
void showargs(char[][] args)
{
printf("hello world\n");
printf("args.length = %d\n", args.length);
for (int i = 0; i < args.length; i++)
printf("args[%d] = '%s'\n", i, cast(char *)args[i]);
}
int main(char[][] args)
{
trace_setlogfilename("test_results/runnable/hello-profile.d.trace.log");
trace_setdeffilename("test_results/runnable/hello-profile.d.trace.def");
showargs(args);
return 0;
}
Results in:
::
test_results/runnable/hello-profile.d.out
::
../src/dmd -Irunnable -cov -od./test_results/runnable
-of./test_results/runnable/hello-profile runnable/hello-profile.d
./test_results/runnable/hello-profile
hello world
args.length = 1
args[0] = './test_results/runnable/hello-profile'
::
test_results/runnable/hello-profile.d.trace.def
::
FUNCTIONS
::
test_results/runnable/hello-profile.d.trace.log
::
Timer Is 3579545 Ticks/Sec, Times are in Microsecs
Num TreeFuncPer
CallsTimeTimeCall
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4709] New: const struct leads DMD terminated abnormally
http://d.puremagic.com/issues/show_bug.cgi?id=4709
Summary: const struct leads DMD terminated abnormally
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bitwo...@qq.com
--- Comment #0 from Heromyth 2010-08-22 00:35:47 PDT ---
The following code will lead DMD terminated abnormally. After getting rid of
the "const" in "const struct SB_uint8", this termination problem is missing.
===
import std.stdio;
/*
struct D_Shift {
ushortsymbol;
ubyteshift_kind;
ubyteop_assoc;
intop_priority;
intterm_priority;
intaction_index;
}
*/
// the bug is here
const struct SB_uint8 {
D_Shift **shift;
ubyte*[2] scanner_block;
}
int main(string[] args)
{
return 0;
}
/*
Z:\>dmd main.d
main.d(17): Error: identifier 'D_Shift' is not defined
main.d(17): Error: D_Shift is used as a type
main.d(20): Error: identifier 'D_Shift' is not defined
main.d(20): Error: D_Shift is used as a type
Assertion failure: 'tn->mod & MODimmutable || tn->mod & MODconst' on line 875
in
file 'mtype.c'
abnormal program termination
*/
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4708] New: expose rt.trace and rt.cover api's
http://d.puremagic.com/issues/show_bug.cgi?id=4708 Summary: expose rt.trace and rt.cover api's Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: druntime AssignedTo: s...@invisibleduck.org ReportedBy: bra...@puremagic.com --- Comment #0 from Brad Roberts 2010-08-22 00:27:21 PDT --- The dmd test suite has a few tests that run -profile and -cov. Right now, those all output to the same filename with no non-hacky way of getting to those apis. They're extern(C)'ed, so they can be forced with repeating the extern declaration where needed, but that's awfully ugly. Food for thought.. could the defaults be better? What's the definition of better? Right now, both default to the current directory. Trace defaults to 'trace.log' and 'trace.def'. Cover defaults to sourcefile.lst, if I read the code correctly. Maybe this would be a good place for some env vars to influence the two? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
