View mode: basic / threaded / horizontal-split · Log in · Help
January 24, 2007
Re: Real World usage of D, Today (was Re: challenge #2: implement the varargs_reduce metafunction)
Thomas Kuehne schrieb am 2007-01-24:
>
> Sean Kelly schrieb am 2007-01-24:
> [...]
>> For the record, I read through the Phobos code looking for the problem 
>> but nothing jumped out at me (and the lack of a usable stack trace 
>> didn't help much). 
>
> Have you tried Flectioned's Trace.getTrace() ?

The latest version contains a convenince function for
gdb. Simply issue the gdb command "call print_trace ($ebp)" to print a
stack trace.

Sample session:
# gdb ./y
# GNU gdb 6.4
[...]
# (gdb) run
# Starting program: /tmp/y 
# [Thread debugging using libthread_db enabled]
# [New Thread 4158613168 (LWP 18759)]
#
# Program received signal SIGSEGV, Segmentation fault.
# [Switching to Thread 4158613168 (LWP 18759)]
# 0x0804f312 in _D3deb3fooFiZv ()
# (gdb) call print_trace($ebp)
# 0xFFC81E24      0x804F30B       void deb.foo(int) (0x804F2F0, 39)
# 0xFFC81E30      0x804F30B       void deb.foo(int) (0x804F2F0, 39)
# 0xFFC81E38      0x804F325       int main(char[][]) (0x804F318, 17)
# 0xFFC81E68      0x8050B7B       extern(C) int main(int, char**)

Thomas
January 24, 2007
Re: Real World usage of D, Today (was Re: challenge #2: implement the varargs_reduce metafunction)
Thomas Kuehne schrieb am 2007-01-24:
>
> Sean Kelly schrieb am 2007-01-24:
> [...]
>> For the record, I read through the Phobos code looking for the problem 
>> but nothing jumped out at me (and the lack of a usable stack trace 
>> didn't help much). 
>
> Have you tried Flectioned's Trace.getTrace() ?

The latest version contains a convenience function for
gdb. Simply issue the gdb command "call print_trace ($ebp)" to print a
stack trace.

Sample session:
# gdb ./y
# GNU gdb 6.4
[...]
# (gdb) run
# Starting program: /tmp/y 
# [Thread debugging using libthread_db enabled]
# [New Thread 4158613168 (LWP 18759)]
#
# Program received signal SIGSEGV, Segmentation fault.
# [Switching to Thread 4158613168 (LWP 18759)]
# 0x0804f312 in _D3deb3fooFiZv ()
# (gdb) call print_trace($ebp)
# 0xFFC81E24      0x804F30B       void deb.foo(int) (0x804F2F0, 39)
# 0xFFC81E30      0x804F30B       void deb.foo(int) (0x804F2F0, 39)
# 0xFFC81E38      0x804F325       int main(char[][]) (0x804F318, 17)
# 0xFFC81E68      0x8050B7B       extern(C) int main(int, char**)

Thomas
January 24, 2007
Re: Real World usage of D, Today (was Re: challenge #2: implement the varargs_reduce metafunction)
Sean Kelly schrieb am 2007-01-24:
> Thomas Kuehne wrote:
>> Sean Kelly schrieb am 2007-01-24:
>> [...]
>>> For the record, I read through the Phobos code looking for the problem 
>>> but nothing jumped out at me (and the lack of a usable stack trace 
>>> didn't help much). 
>> 
>> Have you tried Flectioned's Trace.getTrace() ?
>
> No.  Would it work for a deadlock situation?

I think it should.

Thomas
January 24, 2007
Re: Real World usage of D, Today (was Re: challenge #2: implement the varargs_reduce metafunction)
Thomas Kuehne wrote:
[snip]

Hey, another post from the future...
(Please check your computer's clock)
January 25, 2007
Re: Real World usage of D, Today (was Re: challenge #2: implement the varargs_reduce metafunction)
kris wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> kris wrote:
>>
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>
>>>> That being said, my view on what should be fixed in D is a bit 
>>>> different. For example, as I said, one of my main foci is putting a 
>>>> lead sarcophagus around "inout" before its radioactive waste affects 
>>>> too much code that will become broken later. Also, implicit 
>>>> conversion rules will change, and again I want to get that in ASAP 
>>>> so not too much code suffers. And so on.
>>>
>>>
>>> Aye, and that is certainly appreciated. Some of the items you've 
>>> mentioned recently have long been festering sores for many. It'll 
>>> certainly be refreshing to see some attention focused upon those.
>>>
>>> Regarding implicit conversion rules -- are you including the "issues" 
>>> currently surrounding signature-matching when using constants?
>>
>>
>> Could you give more detail?
>>
>> Andrei
> 
> Yep -- will get back to you with examples (probably tomorrow)


Well there is this issue that &foo where foo is an overloaded will give 
you pointer to the first version of foo in the source file.  There's no 
way to disambiguate as far as I know.  Particularly frustrating for 
property methods

   void prop(float x) { ... }
   float prop() { ... }


&prop just gives you the first one no matter what.

Maybe not what you're talking about with "matching using constants" but 
it is related to signature matching (or lack thereof).

--bb
January 25, 2007
Re: Real World usage of D, Today (was Re: challenge #2: implement the varargs_reduce metafunction)
Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thomas Kuehne schrieb am 2007-01-24:
>> Sean Kelly schrieb am 2007-01-24:
>> [...]
>>> For the record, I read through the Phobos code looking for the problem 
>>> but nothing jumped out at me (and the lack of a usable stack trace 
>>> didn't help much). 
>> Have you tried Flectioned's Trace.getTrace() ?
> 
> The latest version contains a convenince function for
> gdb. Simply issue the gdb command "call print_trace ($ebp)" to print a
> stack trace.
> 
> Sample session:
> # gdb ./y
> # GNU gdb 6.4
> [...]
> # (gdb) run
> # Starting program: /tmp/y 
> # [Thread debugging using libthread_db enabled]
> # [New Thread 4158613168 (LWP 18759)]
> #
> # Program received signal SIGSEGV, Segmentation fault.
> # [Switching to Thread 4158613168 (LWP 18759)]
> # 0x0804f312 in _D3deb3fooFiZv ()
> # (gdb) call print_trace($ebp)
> # 0xFFC81E24      0x804F30B       void deb.foo(int) (0x804F2F0, 39)
> # 0xFFC81E30      0x804F30B       void deb.foo(int) (0x804F2F0, 39)
> # 0xFFC81E38      0x804F325       int main(char[][]) (0x804F318, 17)
> # 0xFFC81E68      0x8050B7B       extern(C) int main(int, char**)

Very nice!  I may just start doing all my D debugging on Linux.


Sean
January 25, 2007
Re: Real World usage of D, Today (was Re: challenge #2: implement the varargs_reduce metafunction)
Bill Baxter wrote:
> Well there is this issue that &foo where foo is an overloaded will give 
> you pointer to the first version of foo in the source file.  There's no 
> way to disambiguate as far as I know.  Particularly frustrating for 
> property methods
> 
>    void prop(float x) { ... }
>    float prop() { ... }
> 
> 
> &prop just gives you the first one no matter what.
> 
> Maybe not what you're talking about with "matching using constants" but 
> it is related to signature matching (or lack thereof).

Ouch. This warrants a bug report. It sure has ripples in lots of 
template code, too.

Andrei
January 25, 2007
Re: Real World usage of D, Today (was Re: challenge #2: implement the varargs_reduce metafunction)
Andrei Alexandrescu (See Website For Email) wrote:
> Bill Baxter wrote:
>> Well there is this issue that &foo where foo is an overloaded will 
>> give you pointer to the first version of foo in the source file.  
>> There's no way to disambiguate as far as I know.  Particularly 
>> frustrating for property methods
>>
>>    void prop(float x) { ... }
>>    float prop() { ... }
>>
>>
>> &prop just gives you the first one no matter what.
>>
>> Maybe not what you're talking about with "matching using constants" 
>> but it is related to signature matching (or lack thereof).
> 
> Ouch. This warrants a bug report. It sure has ripples in lots of 
> template code, too.
> 
> Andrei

It's in there.

http://d.puremagic.com/issues/show_bug.cgi?id=52

--bb
January 25, 2007
Re: Real World usage of D, Today (was Re: challenge #2: implement the varargs_reduce metafunction)
On Wed, 24 Jan 2007 23:12:21 -0800, Andrei Alexandrescu (See Website For
Email) wrote:

> Bill Baxter wrote:
>> Well there is this issue that &foo where foo is an overloaded will give 
>> you pointer to the first version of foo in the source file.  There's no 
>> way to disambiguate as far as I know.  Particularly frustrating for 
>> property methods
>> 
>>    void prop(float x) { ... }
>>    float prop() { ... }
>> 
>> 
>> &prop just gives you the first one no matter what.
>> 
>> Maybe not what you're talking about with "matching using constants" but 
>> it is related to signature matching (or lack thereof).
> 
> Ouch. This warrants a bug report. It sure has ripples in lots of 
> template code, too.
> 
> Andrei


That's not considered a bug, however.  There have been many complaints
about D's signature lookup "protocol" over the last 2 to 3 years.  Walter
has many times stated that it's done that way on purpose, I think to
avoid compiler complexity. Maybe this example shows yet another reason why
it hurts, but we've had no success convincing him otherwise.  That's just
one example of "silent acception" of the symbol.  I'm actually surprised
that Walter didn't invalidate that bug report.

I guess this is an example of the slow aggregation of evidence against
certain language/implementation mechanisms. Template issues related to
this may further this realization.

-JJR
January 26, 2007
Issues with constants, and inout (was Real World usage of D, Today)
Andrei Alexandrescu (See Website For Email) wrote:
> kris wrote:
> 
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>> That being said, my view on what should be fixed in D is a bit 
>>> different. For example, as I said, one of my main foci is putting a 
>>> lead sarcophagus around "inout" before its radioactive waste affects 
>>> too much code that will become broken later. Also, implicit 
>>> conversion rules will change, and again I want to get that in ASAP so 
>>> not too much code suffers. And so on.
>>
>>
>> Aye, and that is certainly appreciated. Some of the items you've 
>> mentioned recently have long been festering sores for many. It'll 
>> certainly be refreshing to see some attention focused upon those.
>>
>> Regarding implicit conversion rules -- are you including the "issues" 
>> currently surrounding signature-matching when using constants?
> 
> 
> Could you give more detail?
> 
> Andrei


Please pardon the delay, and the length of this post ... here's a test:

extern (C) int printf (char*, ...);

class Foo
{
        void write (int x) {printf("int\n");}
        void write (uint x) {printf("uint\n");}
        void write (long x) {printf("long\n");}
        void write (char x) {printf("char\n");}
        void write (wchar x) {printf("wchar\n");}
        void write (double x) {printf("double\n");}

        void write (char[] x) {printf("char[]\n");}
        void write (wchar[] x) {printf("wchar[]\n");}
}

void main()
{
        auto foo = new Foo;

        foo.write ('c');
        foo.write (1);
        foo.write (1u);
        foo.write (3.14);
        //foo.write ("asa");
}

prints:

char
int
uint
double


DMD has actually become smarter than the last time I tried something 
like this: it manages to select the correct overload for 'c' whereas 
before it couldn't decide whether int or uint was a better match for the 
char instead. This is good.

It seems clear from the above that D /defaults/ the type of character, 
and undecorated integers, to something appropriate? In the above case 
'c' is defaulted to char, rather than wchar, for example. The 
undecorated int constant is defaulted to int, rather than uint or long. 
This is good.

Now for the broken part. When you uncomment the string constant, the 
compiler gets all confused about whether it's a char[] or wchar[]. There 
is no defaulting to one type, as there is for other constants (such as 
char). It /is/ possible to decorate the string constant in a similar 
manner to decorating integer constants:

foo.write ("qwe"c);

And this, of course, compiles. It's a PITA though, and differs from the 
rules for other constants. Things start to go south when using templates 
with string constants. For example, take this template sig:

uint locate(T) (T[] source, T match, uint start=0)

This is intended to handle types of char[], wchar[] and dchar[]. There's 
a uint on the end, as opposed to an int. Suppose I call it like this:

locate ("abc", "ab", 1);

we get a compile error, since the int-constant does not match a uint in 
the sig (IFTI currently needs exact sig matches). In order to get around 
this, we wrap the template with a few functions:

uint locate (char[] source, char[] match, uint start=0)
{
    return locateT!(char) (source, match, start);
}

uint locate (wchar[] source, wchar[] match, uint start=0)
{
    return locateT!(wchar) (source, match, start);
}

and dchar too.

Now we call it:

locate ("abc", "ab", 1);

Well, the int/uint error goes away (since function matching operates 
differently than IFTI matching), but we've now got our old friend back 
again -- the constant char[], wchar[], dchar[] mismatch problem.


How about another type of template? Here's one that does some simply 
text processing:

T[] layout(T) (T[] output, T[] format, T[][] subs...)

This has an output buffer, a format string, and a set of optional args; 
all of the same type. If I call it like so:

char[128] tmp;
char[]    world = "world";
layout (tmp, "hello %1", world);

that compiles ok. If I use wchar[] instead, it doesn't compile:

wchar[128] tmp;
wchar[]    world = "world";
layout (tmp, "hello %1", world);

In this case, the constant string used for formatting remains as a 
char[], so the template match fails (args: wchar[], char[], wchar[])

However, if I change the template signature to this instead:

T[] layout(T) (T[] output, T[][] subs...)

then everything works the way I want it to, but the design is actually 
wrong (the format string is now not required). String constants can be a 
royal PITA.



inout
-----

Since you're working on inout also, I'd like to ask what the plan is 
relating to a couple of examples. Tango uses this style of call quite 
regularly:

get (inout int x);
get (inout char[] x);
etc.

This is a clean way to pass-by-reference, instead of dealing with all 
the pointer syntax. I sure hope D will retain reference semantics like 
this, in some form?


One current problem with inout, which you might not be aware of, is with 
regard to const structs. I need to pass structs by reference, because I 
don't want to pass them by value. Applying inout is the mechanism for 
describing this:

struct Bar {int a, b;}

Bar b = {1, 2};

void parf (inout Bar x) {}

void main()
{
   parf (b);
}

That all works fine. However, when I want to make those structs /const/ 
instead, I cannot use inout since it has mutating semantics: I get a 
compile error to that effect:

const Bar b = {1, 2};

>> Error: cannot modify const variable 'b'

That is, there's no supported way to pass a const struct by reference. 
The response from Walter in the past has been "just use a pointer 
instead" ... well, yes I could do that. But it appears to be indicative 
of a problem with the language design?

Why do I want to use const? Well, the data held therein is for reference 
only, and (via some future D vendor) I want that reference data placed 
into a ROM segment. I do a lot of work with MCUs, and this sort of thing 
is a common requirement.

Cheers;

- Kris
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home