On D's, and in particular GDC's, way to conquer the world there will evidently be many newbies to notice D, look at it, be drawn to it (and be happily trapped).

I am such a newbie and the idea behind this thread is to collect all the issues, quirks and nuisances a newbie might encounter.
Please note that quite typically this is not to do with GDC being at fault but rather with a newbie naturally not yet knowing all the ins and outs (like, e.g. that with GDC one must use "-fdebug" and not "-debug" as with dmd).

I assume that for most issues someone more experienced will step in and provide an explanation, a solution or a workaround or just some magic *g

So, here goes:

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

char[] someDynArray;

// in main, after someDynArray is somehow init'd...

     char c;
     for(int i = 0; i < someDynArray; i++)
        c = someDynArray[i];

Now, in the debugger:

> print someDynArray
// whatever it happens to hold. Works fine.

> print someDynArray[i]
Structure has no component named operator[].

Any ideas?

On Fri, Sep 06, 2013 at 01:49:17AM +0200, Ramon wrote:
> On D's, and in particular GDC's, way to conquer the world there will evidently be many newbies to notice D, look at it, be drawn to it (and be happily trapped).
> 
> I am such a newbie and the idea behind this thread is to collect all
> the issues, quirks and nuisances a newbie might encounter.
> Please note that quite typically this is not to do with GDC being at
> fault but rather with a newbie naturally not yet knowing all the ins
> and outs (like, e.g. that with GDC one must use "-fdebug" and not
> "-debug" as with dmd).

Note that -fdebug isn't the only one you have to watch out for. A *lot*
of DMD options are renamed in GDC (mainly due to conflicts with GCC
native options). Most of them are just prepended with -f (like -debug =>
-fdebug) but there are some that are complete renames (like -D => -fdoc)
and syntax rewrites (-Dddocdir => -fdoc-dir=docdir).

The gdc manpage should be consulted when in doubt.


> I assume that for most issues someone more experienced will step in and provide an explanation, a solution or a workaround or just some magic *g
> 
> So, here goes:
> 
> -------------
> 
> char[] someDynArray;
> 
> // in main, after someDynArray is somehow init'd...
> 
>      char c;
>      for(int i = 0; i < someDynArray; i++)
>         c = someDynArray[i];
> 
> Now, in the debugger:
> 
> >print someDynArray
> // whatever it happens to hold. Works fine.
> 
> >print someDynArray[i]
> Structure has no component named operator[].
> 
> Any ideas?

Hmm. Maybe try someDynArray.ptr[i]? (Caveat: I never tried this before,
so dunno if it will work.)

@Iain: on that note, it looks like gdb thinks it's debugging C++, but D doesn't have anything called 'operator[]'. It would be Really Nice if we could somehow coax gdb to use opIndex instead (though it doesn't really help in the case of dyn arrays 'cos they are built-in, and don't actually have any opIndex to speak of).


T

-- 
Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.

On Thursday, 5 September 2013 at 23:58:06 UTC, H. S. Teoh wrote:

Thanks and

> @Iain: on that note, it looks like gdb thinks it's debugging C++, but D
> doesn't have anything called 'operator[]'. It would be Really Nice if we
> could somehow coax gdb to use opIndex instead (though it doesn't really
> help in the case of dyn arrays 'cos they are built-in, and don't
> actually have any opIndex to speak of).

I'm not so sure.

Observation:

> print someDynArray.length
10                               // works

char[5] cArray = "Hello";        // Let's try C like fixed length array

> print cArray[3]
'l'                              // works

I'm not that sure dyn arrays have no [] (or index or whatever it's called) operator. In the end they are just arrays with smart housekeeping behind the curtains and some methods (like "length").

I'm looking forward to hear and learn from Iain.

A+ -R

On Fri, Sep 06, 2013 at 02:59:30AM +0200, Ramon wrote:
> On Thursday, 5 September 2013 at 23:58:06 UTC, H. S. Teoh wrote:
> 
> Thanks and
> 
> >@Iain: on that note, it looks like gdb thinks it's debugging C++, but D doesn't have anything called 'operator[]'. It would be Really Nice if we could somehow coax gdb to use opIndex instead (though it doesn't really help in the case of dyn arrays 'cos they are built-in, and don't actually have any opIndex to speak of).
> 
> I'm not so sure.
> 
> Observation:
> 
> >print someDynArray.length
> 10                               // works
> 
> char[5] cArray = "Hello";        // Let's try C like fixed length array
> 
> >print cArray[3]
> 'l'                              // works
> 
> I'm not that sure dyn arrays have no [] (or index or whatever it's
> called) operator. In the end they are just arrays with smart
> housekeeping behind the curtains and some methods (like "length").
[...]

Actually, D arrays are implemented something like this:

	/* C code equivalent */
	struct int_array {
		int *ptr;
		size_t length;
	}

So if you do something like 'print someDynArray.ptr[4]' it should work.

Now obviously gdb does support more abstract array-like types, like C++ types that define operator[], so I was just saying that it would be nice if we could figure out what to put in the debug data segment to make gdb translate arr[i] in D into arr.ptr[i].

Static arrays in D are closer to C's stack-allocated arrays (e.g. if you declare 'char localVar[10];' inside a function), so they more-or-less work seamlessly with C array indexing notation.


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser

On 6 September 2013 00:56, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
>
> @Iain: on that note, it looks like gdb thinks it's debugging C++, but D doesn't have anything called 'operator[]'. It would be Really Nice if we could somehow coax gdb to use opIndex instead (though it doesn't really help in the case of dyn arrays 'cos they are built-in, and don't actually have any opIndex to speak of).
>

It's using the D front-end of the gdb.  You'd know if gdb was trying to debug it as C++, as it has a different error.

No symbol "operator[]" in current context.

The other error is generic and you can reproduce it when debugging C.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 6 September 2013 01:59, Ramon <spam@thanks.no> wrote:
> On Thursday, 5 September 2013 at 23:58:06 UTC, H. S. Teoh wrote:
>
> Thanks and
>
>
>> @Iain: on that note, it looks like gdb thinks it's debugging C++, but D doesn't have anything called 'operator[]'. It would be Really Nice if we could somehow coax gdb to use opIndex instead (though it doesn't really help in the case of dyn arrays 'cos they are built-in, and don't actually have any opIndex to speak of).
>
>
> I'm not so sure.
>
> Observation:
>
>> print someDynArray.length
>
> 10                               // works
>
> char[5] cArray = "Hello";        // Let's try C like fixed length array
>
>> print cArray[3]
>
> 'l'                              // works
>
> I'm not that sure dyn arrays have no [] (or index or whatever it's called)
> operator. In the end they are just arrays with smart housekeeping behind the
> curtains and some methods (like "length").
>
> I'm looking forward to hear and learn from Iain.
>

Dynamic arrays are just structs with a length and ptr field.  So when you invoke '.length' in the debugger you aren't calling a method, you are just retrieving the type's field value.

Currently, the only fancy thing the gdb does with D arrays is that it pretty prints them. So take for example you have:

{ .length = 5, .ptr = "Hello" };


Rather than printing the dynamic array like the above, it does a printf("%*.s") style operation to print the contents of .ptr, but only as far as .length.  This is important because dynamic arrays are not expected to be '0' terminated, and you can slice a dynamic array into smaller arrays without copying data.


Having the ability to slice D arrays using [] in gdb is something on my todo list when I get round to improving gdb for D.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Thursday, 5 September 2013 at 23:49:18 UTC, Ramon wrote:
> On D's, and in particular GDC's, way to conquer the world there will evidently be many newbies to notice D, look at it, be drawn to it (and be happily trapped).
>
> I am such a newbie and the idea behind this thread is to collect all the issues, quirks and nuisances a newbie might encounter.

That being said, Iain, could you please update this example of yours:

http://iainbuclaw.wordpress.com/2010/05/22/writing-a-linux-kernel-module-in-d/

It is a very interesting concept, if it works...

Using the git head gdc I have these errors:

$make VERBOSE=1
gdc -c dinterface.d -o dinterface.o
make -C /lib/modules/3.11.0-5-generic/build M=/home/user/kernelmodule CONFIG_HELLO=m MAKE_KBUILD=1 modules
make[1]: Entering directory `/usr/src/linux-headers-3.11.0-5-generic'
  LD [M]  /home/user/kernelmodule/hello.o
  Building modules, stage 2.
  MODPOST 1 modules
WARNING: could not find /home/user/kernelmodule/.dinterface.o.cmd for /home/user/kernelmodule/dinterface.o
WARNING: "_D3std3utf12UTFException7__ClassZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std4conv21ConvOverflowException6__ctorMFAyaAyamZC3std4conv21ConvOverflowException" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D6object9Exception6__ctorMFNaNbNfAyaAyamC6object9ThrowableZC9Exception" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_assert_msg" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std5ascii7isDigitFNaNbNfwZb" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraycopy" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D9Exception7__ClassZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std3utf12UTFException6__ctorMFAyamAyamC6object9ThrowableZC3std3utf12UTFException" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_newclass" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D4core6memory2GC6qallocFNaNbmkZS4core6memory8BlkInfo_" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std4conv21ConvOverflowException7__ClassZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D12TypeInfo_Aya6__initZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std9exception7bailOutFNaNfAyamxAaZv" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std4conv13ConvException7__ClassZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_Dmodule_ref" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_newitemT" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D4core6memory2GC6extendFNaNbPvmmZm" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D14TypeInfo_Array6__vtblZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std6format15FormatException7__ClassZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std6string9toStringzFNaNbAyaZPya" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std4conv13ConvException6__ctorMFAyaAyamZC3std4conv13ConvException" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D15TypeInfo_Struct6__vtblZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_assert" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std6format15FormatException6__ctorMFAyaAyamC6object9ThrowableZC3std6format15FormatException" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_Unwind_Resume" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arrayappendT" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D11TypeInfo_Aa6__initZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std4math7signbitFNaNbNeeZi" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std3utf6encodeFNaNfKG4awZm" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraycatnT" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_throw" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std3utf12isValidDcharFNaNbNfwZb" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_array_bounds" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D16TypeInfo_Pointer6__vtblZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D14TypeInfo_Const6__vtblZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D3std6string12__ModuleInfoZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_D10TypeInfo_a6__initZ" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraycatT" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_adDupT" [/home/user/kernelmodule/hello.ko] undefined!
WARNING: "_d_arraysetcapacity" [/home/user/kernelmodule/hello.ko] undefined!
  CC      /home/user/kernelmodule/hello.mod.o
  LD [M]  /home/user/kernelmodule/hello.ko
make[1]: Leaving directory `/usr/src/linux-headers-3.11.0-5-generic'

Should the Makefile be updated to not link in libraries?

On Friday, 6 September 2013 at 07:02:56 UTC, Iain Buclaw wrote:
>
> Dynamic arrays are just structs with a length and ptr field.  So when
> you invoke '.length' in the debugger you aren't calling a method, you
> are just retrieving the type's field value.
>
> Currently, the only fancy thing the gdb does with D arrays is that it
> pretty prints them. So take for example you have:
>
> { .length = 5, .ptr = "Hello" };
>
>
> Rather than printing the dynamic array like the above, it does a
> printf("%*.s") style operation to print the contents of .ptr, but only
> as far as .length.  This is important because dynamic arrays are not
> expected to be '0' terminated, and you can slice a dynamic array into
> smaller arrays without copying data.
>
>
> Having the ability to slice D arrays using [] in gdb is something on
> my todo list when I get round to improving gdb for D.

Thanks for the explanation, Iain.

But: Doesn't that mean that myArray[] is just syntactic sugar for myArray.ptr[i]? And if so wouldn't it make sense to fool gdb, too, to accept print myArray[4] instead of myArray.ptr[4]?

Funnily btw. "p myArray" prints out the whole array, yet asking it to print out myArray[3] fails as described.

Thanks also to HS for his hints

A+ -R

On 6 September 2013 08:34, Ramon <spam@thanks.no> wrote:
> On Friday, 6 September 2013 at 07:02:56 UTC, Iain Buclaw wrote:
>>
>>
>> Dynamic arrays are just structs with a length and ptr field.  So when you invoke '.length' in the debugger you aren't calling a method, you are just retrieving the type's field value.
>>
>> Currently, the only fancy thing the gdb does with D arrays is that it pretty prints them. So take for example you have:
>>
>> { .length = 5, .ptr = "Hello" };
>>
>>
>> Rather than printing the dynamic array like the above, it does a printf("%*.s") style operation to print the contents of .ptr, but only as far as .length.  This is important because dynamic arrays are not expected to be '0' terminated, and you can slice a dynamic array into smaller arrays without copying data.
>>
>>
>> Having the ability to slice D arrays using [] in gdb is something on my todo list when I get round to improving gdb for D.
>
>
> Thanks for the explanation, Iain.
>
> But: Doesn't that mean that myArray[] is just syntactic sugar for myArray.ptr[i]? And if so wouldn't it make sense to fool gdb, too, to accept print myArray[4] instead of myArray.ptr[4]?
>

Yes, myArray[] is just syntactical sugar.  What the compiler code generates is myArray.ptr[i].

gdb will always accept myArray.ptr[4] because arrays are just structs.
 As I said, [] is something on my todo list.


> Funnily btw. "p myArray" prints out the whole array, yet asking it to print out myArray[3] fails as described.
>

As I said in my previous message, this is the only thing that gdb does fancy with D arrays at this moment.  If you wrote the equivalent code in C and called 'p myArray' in the debugger you'd get:

{ .length = 5, .ptr = "Hello12maybesomegarbageontheend" }


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 6 September 2013 08:32, eles <eles@eles.com> wrote:
> On Thursday, 5 September 2013 at 23:49:18 UTC, Ramon wrote:
>>
>> On D's, and in particular GDC's, way to conquer the world there will evidently be many newbies to notice D, look at it, be drawn to it (and be happily trapped).
>>
>> I am such a newbie and the idea behind this thread is to collect all the issues, quirks and nuisances a newbie might encounter.
>
>
> That being said, Iain, could you please update this example of yours:
>
> http://iainbuclaw.wordpress.com/2010/05/22/writing-a-linux-kernel-module-in-d/
>
> It is a very interesting concept, if it works...
>
> Using the git head gdc I have these errors:
>
> $make VERBOSE=1
> gdc -c dinterface.d -o dinterface.o
> make -C /lib/modules/3.11.0-5-generic/build M=/home/user/kernelmodule
> CONFIG_HELLO=m MAKE_KBUILD=1 modules
> make[1]: Entering directory `/usr/src/linux-headers-3.11.0-5-generic'
>   LD [M]  /home/user/kernelmodule/hello.o
>   Building modules, stage 2.
>   MODPOST 1 modules
> WARNING: could not find /home/user/kernelmodule/.dinterface.o.cmd for
> /home/user/kernelmodule/dinterface.o
> WARNING: "_D3std3utf12UTFException7__ClassZ"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING:
> "_D3std4conv21ConvOverflowException6__ctorMFAyaAyamZC3std4conv21ConvOverflowException"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING:
> "_D6object9Exception6__ctorMFNaNbNfAyaAyamC6object9ThrowableZC9Exception"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_d_assert_msg" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D3std5ascii7isDigitFNaNbNfwZb" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING: "_d_arraycopy" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D9Exception7__ClassZ" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING:
> "_D3std3utf12UTFException6__ctorMFAyamAyamC6object9ThrowableZC3std3utf12UTFException"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_d_newclass" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D4core6memory2GC6qallocFNaNbmkZS4core6memory8BlkInfo_"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D3std4conv21ConvOverflowException7__ClassZ"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D12TypeInfo_Aya6__initZ" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING: "_D3std9exception7bailOutFNaNfAyamxAaZv"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D3std4conv13ConvException7__ClassZ"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_Dmodule_ref" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_d_newitemT" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D4core6memory2GC6extendFNaNbPvmmZm"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D14TypeInfo_Array6__vtblZ" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING: "_D3std6format15FormatException7__ClassZ"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D3std6string9toStringzFNaNbAyaZPya"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING:
> "_D3std4conv13ConvException6__ctorMFAyaAyamZC3std4conv13ConvException"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D15TypeInfo_Struct6__vtblZ" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING: "_d_assert" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING:
> "_D3std6format15FormatException6__ctorMFAyaAyamC6object9ThrowableZC3std6format15FormatException"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_Unwind_Resume" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_d_arrayappendT" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D11TypeInfo_Aa6__initZ" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING: "_D3std4math7signbitFNaNbNeeZi" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING: "_D3std3utf6encodeFNaNfKG4awZm" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING: "_d_arraycatnT" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_d_throw" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D3std3utf12isValidDcharFNaNbNfwZb"
> [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_d_array_bounds" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_D16TypeInfo_Pointer6__vtblZ" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING: "_D14TypeInfo_Const6__vtblZ" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING: "_D3std6string12__ModuleInfoZ" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING: "_D10TypeInfo_a6__initZ" [/home/user/kernelmodule/hello.ko]
> undefined!
> WARNING: "_d_arraycatT" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_adDupT" [/home/user/kernelmodule/hello.ko] undefined!
> WARNING: "_d_arraysetcapacity" [/home/user/kernelmodule/hello.ko] undefined!
>   CC      /home/user/kernelmodule/hello.mod.o
>   LD [M]  /home/user/kernelmodule/hello.ko
> make[1]: Leaving directory `/usr/src/linux-headers-3.11.0-5-generic'
>
> Should the Makefile be updated to not link in libraries?

That's interesting, as gdc is only used to compile dinterface.o (which has no reference to libphobos/druntime and shouldn't be emitting references to it).

In today's gdc implementation (back then I believe that was for D1) -
you'd have to use -fno-emit-moduleinfo  (maybe I should reverse the
logic of that switch to make it easier to use).


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';