The lack of proper mangling in internal symbols has been a problem the entire time I've been with D, well over a year.  Get with it, Walter. Attached shows a trigger for some of them and the response from DMD, although I couldn't figure out how to trigger "_array_<modulename>". There's even some new ones in "new" and "delete"!  There's no excuse to put such an easily avoided bug in the compiler now.

I can't release, or even finish, the next version of dig without this and path preservation (Preserving paths in .obj files) being released, so I'd appreciate it if 0.69 were to come soon after.

Can we expect TreeCtrl and ListCtrl in the next dig release ?

Charles


"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bfruug$pmg$1@digitaldaemon.com...
> The lack of proper mangling in internal symbols has been a problem the entire time I've been with D, well over a year.  Get with it, Walter. Attached shows a trigger for some of them and the response from DMD, although I couldn't figure out how to trigger "_array_<modulename>". There's even some new ones in "new" and "delete"!  There's no excuse to put such an easily avoided bug in the compiler now.
>
> I can't release, or even finish, the next version of dig without this and path preservation (Preserving paths in .obj files) being released, so I'd appreciate it if 0.69 were to come soon after.
>


----------------------------------------------------------------------------
----


> C:\>dmd f.d g.d
> c:\dmd\bin\..\..\dm\bin\link.exe f+g,,,user32+kernel32/noi;
> OPTLINK (R) for Win32  Release 7.50B1
> Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved
>
> g.obj(g)  Offset 001F7H Record Type 0091
>  Error 1: Previous Definition Different : __init_name_foo
> g.obj(g)  Offset 00381H Record Type 0091
>  Error 1: Previous Definition Different : __init_name_bar
> g.obj(g)  Offset 00397H Record Type 0091
>  Error 1: Previous Definition Different : __Class_name_bar
> g.obj(g)  Offset 003ACH Record Type 0091
>  Error 1: Previous Definition Different : __vtbl_name_bar
> g.obj(g)  Offset 003C3H Record Type 0091
>  Error 1: Previous Definition Different : __ModuleInfo_name
> g.obj(g)  Offset 003C5H Record Type 00C3
>  Error 1: Previous Definition Different : _Dname__staticCtor_FZv
> g.obj(g)  Offset 003D5H Record Type 00C3
>  Error 1: Previous Definition Different : _Dname__staticDtor_FZv
> g.obj(g)  Offset 003E5H Record Type 00C3
>  Error 1: Previous Definition Different : _Dname_bar_new_FkZPv
> g.obj(g)  Offset 003F7H Record Type 00C3
>  Error 1: Previous Definition Different : _Dname_bar_delete_FPvZv
> g.obj(g)  Offset 00407H Record Type 00C3
>  Error 1: Previous Definition Different : _Dname_bar__ctor_FZC8name_bar
> g.obj(g)  Offset 00436H Record Type 00C3
>  Error 1: Previous Definition Different : _Dname_bar__dtor_FZv
> g.obj(g)  Offset 00454H Record Type 00C3
>  Error 1: Previous Definition Different : _Dname_bar__staticCtor_FZv
> g.obj(g)  Offset 00464H Record Type 00C3
>  Error 1: Previous Definition Different : _Dname_bar__staticDtor_FZv
> g.obj(g)  Offset 00474H Record Type 00C3
>  Error 1: Previous Definition Different : _Dname_bar__invariant_FZv
> g.obj(g)  Offset 00484H Record Type 00C3
>  Error 1: Previous Definition Different : _Dname_bar_staticFunction_FZv
> g.obj(g)  Offset 005AAH Record Type 00C3
>  Error 1: Previous Definition Different : __modctor_name
> g.obj(g)  Offset 005D2H Record Type 00C3
>  Error 1: Previous Definition Different : __moddtor_name
> g.obj(g)  Offset 005FAH Record Type 00C3
>  Error 1: Previous Definition Different : _assert_name
> --- errorlevel 18


----------------------------------------------------------------------------
----


> module firstPackage.name;
>
> struct foo
> {
> }
>
> unittest
> {
> }
>
> static this ()
> {
>     assert (1);
> }
>
> static ~this () { }
>
> class bar
> {
>     new (uint size) { return null; }
>     delete (void *data) { }
>     this () { }
>     ~this () { }
>     static this () { }
>     static ~this () { }
>     invariant { }
>     static void staticFunction () { }
> }
>
> void main ()
> {
> }
>


----------------------------------------------------------------------------
----


> module secondPackage.name;
>
> struct foo
> {
> }
>
> unittest
> {
> }
>
> static this ()
> {
>     assert (1);
> }
>
> static ~this () { }
>
> class bar
> {
>     new (uint size) { return null; }
>     delete (void *data) { }
>     this () { }
>     ~this () { }
>     static this () { }
>     static ~this () { }
>     invariant { }
>     static void staticFunction () { }
> }
>

Charles Sanders wrote:
> Can we expect TreeCtrl and ListCtrl in the next dig release ?

ListBox has been in since 0.0.10, although it's not completed or really documented; I'll work on it.  For a tree control I've been vacillating between whether to make it a subclass of ListBox or a completely separate class.

Suggestions would be very valuable to me.  dig's development has been hermetic, which is bound to encourage obscure features or directions people don't agree with.  For example, would you prefer LabelControl over Label?  I'd never use an abbreviation, but this much doesn't bother me, and if it's a win for many people I'll make the change.

Oh, and which library are you using to get the menu in DIDE?

> ListBox has been in since 0.0.10, although it's not completed or really documented; I'll work on it.  For a tree control I've been vacillating between whether to make it a subclass of ListBox or a completely separate class.

Instinct says separate

> Suggestions would be very valuable to me.  dig's development has been hermetic, which is bound to encourage obscure features or directions people don't agree with.  For example, would you prefer LabelControl over Label?  I'd never use an abbreviation, but this much doesn't bother me, and if it's a win for many people I'll make the change.

Label. Let the namespace sort it out.

Ok!

Since you'll be in mangling anyway, could you fix symbol mangling to use numeric prefixes?  Rather than:

    _Dfoo_barbaz_i

It should be:

    _D3foo_6barbaz_i

I'd also like it if D symbols didn't use an underline but just started with D.  Then I don't have to guess about the nature of a variable.

I've attached files for inducing lots more of them.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bfv543$t04$1@digitaldaemon.com...
> Since you'll be in mangling anyway, could you fix symbol mangling to use numeric prefixes?  Rather than:
>
>     _Dfoo_barbaz_i
>
> It should be:
>
>     _D3foo_6barbaz_i

Sounds good.

> I'd also like it if D symbols didn't use an underline but just started with D.  Then I don't have to guess about the nature of a variable.

? The _D prefix makes it much less likely to have a collision with C functions.