September 15, 2004
Ant wrote:
> In article <ci6nf0$2p89$1@digitaldaemon.com>, Arcane Jill says...
> 
>>In article <ci3jv1$10v8$1@digitaldaemon.com>, Arcane Jill says...
>>
>>I want to change my mind 
> 
> nah, nah, too late for that. ;)
> 
> 
>>vote instead for DEBUGGING INFORMATION.
> 
> 
> See Walter? this is very important!
> 
> 
>>I can use D with Visual Studio to a limited extent,
> 
> 
> now imagine us linux guys... :(
> 
> 
>>[...] In fact, it's the sole reason I'm not using templates yet.
> 
> 
> if all the other people here were like you there would be no linux
> projects at all.
> 
> Ant
> 
> 
if you used the gcc backend to compile D, then it works quite nicely with gdb.  it's not perfect, but you can get a whole heck of a lot more info than with DMD.exe (I can only end up running this thru wine... the linux native one won't work with my glibc :-(   )

is gdc (gcc backend) ever going to get updated to support the post .81 bugfixes/features(mixins)
I'm getting kind of tired of the oldness of .81 and most importantly the bugs (can't make statically sized arrays cast properly to dynamically sized arrays for instance)
or can it magically be compiled with the latest frontend source
September 15, 2004
In article <ci93cn$12ol$1@digitaldaemon.com>, Daniel Horn says...
>
>> 
>if you used the gcc backend to compile D, then it works quite nicely with gdb.  it's not perfect, but you can get a whole heck of a lot more info than with DMD.exe (I can only end up running this thru wine... the linux native one won't work with my glibc :-(   )
>
>is gdc (gcc backend) ever going to get updated to support the post .81
>bugfixes/features(mixins)
>I'm getting kind of tired of the oldness of .81 and most importantly the
>bugs (can't make statically sized arrays cast properly to dynamically
>sized arrays for instance)
>or can it magically be compiled with the latest frontend source

maybe it's time to try to keep it up with dmd as D is not changing dramatically from week to week.

I was able to compile a small test with gdc when it first come out.
(see you on the d.gnu group)

Ant


September 15, 2004
Mike Swieton wrote:

> On Tue, 14 Sep 2004 09:42:26 -0400, Berin Loritsch wrote:
> 
>>I'm not sure I agree with those suggestions based on what I think D unit
>>testing can be.  Here are my suggestions:
>>
>>* Add a text parameter to the assert keyword so that additional
>>   information can be passed back to the user.  This will allow
>>   libraries of useful "assertXXX" functions to be written and
>>   still include the developer defined message.
> 
> 
> I think this is a strange restriction. Wouldn't making it a regular function
> be more powerful, or at least make more sense?

There is nothing stopping regular methods wrapped around this from being
written, as is the case in the XXXUnit libraries.  I think it would
over-complicate the *language* to have a zillion assert variant
keywords.

>>* Separate the unit-test entry point from the application entry
>>   point.  A "d-unit" utility (like the dmd utility) should be used
>>   to collect and run the tests.  Information from those tests should
>>   be collected in a file--or at the very least provide a "callback"
>>   function to add on test reporting in a way that fits the developer.
> 
> I dislike a utility. Purely for philosophical reasons: why should I need a
> separate application to use a language feature? I had in mind something more
> like a library I could link against (or would automatically be linked in when
> in -unittest mode). Or is that what you just suggested?

For purely practical reasons in TDD unit testing is more a function of
compilation than runtime.  One could do what Java does and have all the
JDK tools written in Java with EXE shells to link to the tools.jar lib.
The equivalent would satisfy both our needs (i.e. have the bulk of the
logic in a library with a utility to call it from the command line).

The bottom line is that I want to be able to execute just the tests any
time I want.

>>* Provide a class-wide "unit-init" and "unit-destroy" style blocks so
>>   that the variables associated with the unit testing can be set up and
>>   used in each "unit" block.  Associated with this is a way to
>>   distinguish variables used for unit testing from variables used for
>>   operation.  It should be a compile error to access unit testing
>>   variables from outside a "unitXXX" block.  By the same token, it
>>   should be a compile error for the "unit-init" and "unit-destroy"
>>   blocks to touch non-unit testing variables.  During a "-release" build
>>   all those variables can be safely removed without side-effect.
> 
> 
> My thinking was that this could be done in a library, for two reasons:
> firstly, it's less invasive to the language (simpler change). Secondly, it is
> more extensible.  As long as the test methods themselves are accessible, a
> library can be written and features can be added. But without that, we're
> stuck with one design forever.
> 
> The big question is where to draw the line: what is a language feature, and
> what should be done in a library? I think most of it should be a library, for
> extensibility and future-proofing D.

To tell the truth, it would be easy enough writing a DUnit library to do
everything you want.  Of course having something like DCover (coverage
utility) would rock as well.  The proposal I came up with preserves the
idea of completing the Unit Testing integration--which until now is
almost too limiting to be truly useful.

> 
> I don't think the unit testing is quite as important as proper debugging
> information, or Arcane Jill's hooks for the GC, as those affect coding and not
> testing. But without changes to address the testing issues, I don't feel that
> D can honestly advertise that it has 'built-in unit testing'. That's why I
> feel this is definitely a D 1.0 feature, not 2.0. It's not a 'nice feature' to
> have, it's a feature D claims to have, but really doesn't.
> 
> Anyone have any thoughts?

Well, having been test infected, I like being able to claim my tests
have 100% coverage.  However, in order for tests to be useful, proper
debugging information and stack trace information are very important.
If D has to come up with its own debugger (like Java had to do), then
it is a worthwhile endeavor.  You will find that writing the debugger
will help determine what callbacks and tie-ins to the compiled binary
are necessary.
September 15, 2004
On Wed, 15 Sep 2004 09:27:06 -0400, Berin Loritsch wrote:
> There is nothing stopping regular methods wrapped around this from being written, as is the case in the XXXUnit libraries.  I think it would over-complicate the *language* to have a zillion assert variant keywords.

Right now, there is: it's impossible to get the file/line number information that the assert keyword right now provides. I don't really care too much about the mechanism, though, as long as I can override assert.

> For purely practical reasons in TDD unit testing is more a function of compilation than runtime.  One could do what Java does and have all the JDK tools written in Java with EXE shells to link to the tools.jar lib. The equivalent would satisfy both our needs (i.e. have the bulk of the logic in a library with a utility to call it from the command line).
> 
> The bottom line is that I want to be able to execute just the tests any time I want.

That would be an acceptable solution.

>>>* Provide a class-wide "unit-init" and "unit-destroy" style blocks so
>>>   that the variables associated with the unit testing can be set up and
>>>   used in each "unit" block.  Associated with this is a way to
>>>   distinguish variables used for unit testing from variables used for
>>>   operation.  It should be a compile error to access unit testing
>>>   variables from outside a "unitXXX" block.  By the same token, it
>>>   should be a compile error for the "unit-init" and "unit-destroy"
>>>   blocks to touch non-unit testing variables.  During a "-release" build
>>>   all those variables can be safely removed without side-effect.
>> 
>> 
>> My thinking was that this could be done in a library, for two reasons: firstly, it's less invasive to the language (simpler change). Secondly, it is more extensible.  As long as the test methods themselves are accessible, a library can be written and features can be added. But without that, we're stuck with one design forever.
>> 
>> The big question is where to draw the line: what is a language feature, and what should be done in a library? I think most of it should be a library, for extensibility and future-proofing D.
> 
> To tell the truth, it would be easy enough writing a DUnit library to do everything you want.  Of course having something like DCover (coverage utility) would rock as well.  The proposal I came up with preserves the idea of completing the Unit Testing integration--which until now is almost too limiting to be truly useful.

Yeah, all of what I want would be pretty trivial to implement. However, D claims to have 'built in unit testing'. Either it does, or it doesn't. If I have to write DUnit, then it definately does not, and such a deviation from the spec must be a bug.

>> 
>> I don't think the unit testing is quite as important as proper debugging information, or Arcane Jill's hooks for the GC, as those affect coding and not testing. But without changes to address the testing issues, I don't feel that D can honestly advertise that it has 'built-in unit testing'. That's why I feel this is definitely a D 1.0 feature, not 2.0. It's not a 'nice feature' to have, it's a feature D claims to have, but really doesn't.
>> 
>> Anyone have any thoughts?
> 
> Well, having been test infected, I like being able to claim my tests have 100% coverage.  However, in order for tests to be useful, proper debugging information and stack trace information are very important. If D has to come up with its own debugger (like Java had to do), then it is a worthwhile endeavor.  You will find that writing the debugger will help determine what callbacks and tie-ins to the compiled binary are necessary.

That's beyond my area of expertise, I'm afraid. As long as I can debug my D code, I'll be happy. And test it, too.

Mike Swieton
__
What would you attempt to do if you knew you would not fail?
	- Dr. Robert Schuller

September 15, 2004
On Wed, 15 Sep 2004 08:12:23 +0000, Roberto Mariottini wrote:

<snip>

> # unittest {
> #   // init test module
> #   Test.setModule("mycompany.myproduct.mypackage.Sum")
> #
> #   // test feature add()
> #   if (Test.enabled("mycompany.myproduct.mypackage.Sum.add")) {
> #     Test.expr(add(3,4) == 7, "Positive add test");
> #     Test.expr(add(-2,0) == -2, "Negative add test");
> #   }
> #
> #   // test feature sub()
> #   if (Test.enabled("mycompany.myproduct.mypackage.Sum.sub")) {
> #     Test.expr(sub(3,4) == -1, "Negative sub test");
> #     Test.expr(sub(2,1) == 1, "Positive sub test");
> #   }
> # }
> 
> Where the Test class is a singleton that loads a configuration file at startup,
> thus the user can decide wich tests to enable for each run.
> Since the unittests are run before the main function is called, a simple:
> 
> int main() {
> if (Test.enabled()) {
> return 0;
> }
> 
> .. // the rest of the main function
> }

That's a solution that works, but that relegates D's unittest keyword to be basically nothing more than version(unittest){}. If that's the most testing support the language provides, then it just doesn't provide testing support. I shouldn't have to throw away and work around the language for a feature it claims to have built in.

Mike Swieton
__
History will be kind to me, for I intend to write it.
	- Winston Churchill

September 15, 2004
Walter wrote:
...
> So I'd like to kick off this thread as an opportunity for all to post their
> two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
> mean pragmatic things like:

Thanks for asking.

I have some specific suggestions for Phobos:

1) Rename std.std* to std.*, i.e.
   std.stdarg => std.arg
   std.stdint => std.integer
   std.stdio  => std.io


2) Reorganize a little bit:
    std.asserterror => std.error.asserterr
    std.outofmemory => std.error.outofmemory
    std.switcherr   => std.error.switcherr
    std.syserror    => std.error.syserr

    object          => std.object


3) Remove printf and wprintf from object.d and change the bool alias to:
  alias int bool; /* (line 11) */

After changing the definition of bool, these redundant lines could be removed from Phobos:
  public alias recls_bool_t boolean;     /* std.recls (line 90) */
  public alias int boolean;              /* std.loader (line 81) */



-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
September 16, 2004
Ummm... would've forgotten. Fixing typeinfos is crucial for D 1.0
September 16, 2004

J C Calvarese wrote:
> 
> Walter wrote:
> ...
> > So I'd like to kick off this thread as an opportunity for all to post their two Most Important Issues for D with respect to getting 1.0 done. By MIID, I mean pragmatic things like:
> 
> Thanks for asking.
> 
> I have some specific suggestions for Phobos:
> 
> 1) Rename std.std* to std.*, i.e.
>     std.stdarg => std.arg
>     std.stdint => std.integer
>     std.stdio  => std.io
> 
> 2) Reorganize a little bit:
>      std.asserterror => std.error.asserterr

                    maybe std.error.assert ?

>      std.outofmemory => std.error.outofmemory
>      std.switcherr   => std.error.switcherr

                    maybe std.error.switch ?

>      std.syserror    => std.error.syserr

                    maybe std.error.sys ?

> 
>      object          => std.object
> 
> 3) Remove printf and wprintf from object.d and change the bool alias to:
>    alias int bool; /* (line 11) */
> 
> After changing the definition of bool, these redundant lines could be
> removed from Phobos:
>    public alias recls_bool_t boolean;     /* std.recls (line 90) */
>    public alias int boolean;              /* std.loader (line 81) */
> 
> --
> Justin (a/k/a jcc7)
> http://jcc_7.tripod.com/d/

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com
September 16, 2004
In article <ciaj0k$1rrg$1@digitaldaemon.com>, J C Calvarese says...
>
[...]
>
>I have some specific suggestions for Phobos:
>
>1) Rename std.std* to std.*, i.e.
>    std.stdarg => std.arg
>    std.stdint => std.integer
>    std.stdio  => std.io

Good.

>2) Reorganize a little bit:
>     std.asserterror => std.error.asserterr
>     std.outofmemory => std.error.outofmemory
>     std.switcherr   => std.error.switcherr
>     std.syserror    => std.error.syserr

Why not:

std.asserterror => std.error.assert
std.outofmemory => std.error.outofmemory
std.switcherr   => std.error.switch
std.syserror    => std.error.system

>     object          => std.object
>
>
>3) Remove printf and wprintf from object.d and change the bool alias to:
>   alias int bool; /* (line 11) */
>
>After changing the definition of bool, these redundant lines could be removed from Phobos:
>   public alias recls_bool_t boolean;     /* std.recls (line 90) */
>   public alias int boolean;              /* std.loader (line 81) */

It's good enough for me (considered I vote for true-boolean type :-).

Ciao


September 16, 2004
Dear all,

I'm a beginner to C and C++. Yesterday i search over internet and found D is easiest to learn than
the predeccessors and very comfortable for me. But several question makes me a little doubt, please
help.

1. D can only run on Windows Console, i can not run it in pure DOS Console. This is is something
very important since C and C++ can do that. How can i run it on embedded system if it should require
windows ?
2. The executable file size is so big, test using "Hello World" program around 97 kb and in linux it's bigger. Is that because D runs in
win32 console mode ? Even i use exe compressor, the size doesn't cut for the half of the original
size instead.

Thank you. Keep up good working

Regards,

Budi