September 14, 2004
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


September 14, 2004
Mike Swieton wrote:

> On Mon, 13 Sep 2004 19:46:56 +0000, Nick wrote:
> 
>>Ok. Do you (or anyone else) have any specific suggestions as to how to improve
>>the D unit test system so it will meet your criteria? I admit I'm pretty
>>clueless about this.
>>
>>Nick

<snip type="a bunch of great stuff"/>

Mike, great post detailing the same things I observed.  Now, what I like
about D unit tests is that the test is next to the code being tested--
this is a good thing.  If done correctly, it should allow you to test
even private member functions (something that JUnit cannot do).  I
second the cry for restructuring how tests are compiled and run.

> 
> My suggestions to accomplish the above:
> 
> - Change assert to be a normal function that can be overridden, and have it
> 	thrown an exception. That is, make it Java-like. This will require some
> 	magic to continue to let assertions have line numbers and file names. This
> 	addresses #4, and #1.
> - Separate tests into actual functions, named, and expose them somehow (such
> 	as an AA).

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.

* 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.

* Test failure and test errors are separated.  Any test that throws
  an exception other than an AssertionError (or whatever it is called)
  has an error because the condition was not planned for.  If the assert
  fails then the test fails.  ****Stack Traces Are Imperative****,
  with unit tests it is more important to follow the trail of activity
  with class names, method names, and line numbers.  The actual point
  of failure is less important than what led up to it.

* 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.

I think this will solve the desires for TDD in a "D" way.
September 14, 2004
> Is this hindering development? Yes, absolutely. In fact, it's the sole
reason
> I'm not using templates yet.

<alert comment="newbie">

No doubt I overuse debuggers ... but for me, learning a new language is typically an order of magnitude harder without a symbolic debugger. I'm trying to get the native Win32 TreeView to work, and it is mostly trial and error ... like coding in Braille. I don't look forward to a possible project using "D" that involves "bit twiddling" until a debugger is more usable.

It can be VERY difficult to follow quasi-magical invocations of delegates, virtuals, overloading, constructors, destructors, etc. without a very servicable debugger. I'm reluctantly holding off learning and using mixins and associative arrays until debugging support improves.

In the dsource forums, I came across the latest thread (2004-May-21: Project on hold) that effort on the debugger project ("DigDug") has been suspended until a gui library is standardized and matures. http://dsource.org/forums/viewtopic.php?t=153

</alert>


September 14, 2004
Based on a number of your posts, I consider you (among several others) a fluent "voice of reason" on this list. I'd been wondering what your MIID's would be. The WB posted the question on the 10th and I have to speculate that a number of people were more or less eagerly awaiting your response.

And thanks for your previous efforts to figure out how to get the Visual Studio (98 & .Net) debugger partly working with "D".

Hope all is well with your family. We missed you some time back when you needed some time by yourself. The list wasn't the same.


September 14, 2004
"Walter" <newshound@digitalmars.com> wrote in message news:cht9gl$20m8$1@digitaldaemon.com...
> It's time to prioritize and get us on a rational, sensible path for releasing 1.0.

Years ago, there was a "metric" for whether software was getting ready for release: existing bugs were getting fixed faster than new bugs were being reported. Overall, you like to see that the number of unresolved bugs has been declining long enough to discern a trend.

Just curious: is this the case for D? Does this seem like a reasonable guide to whether software is getting ready to release?

Another question to consider asking the list participants (if not already
asked):
Do you consider D 0.1## ready to release as ver 1.0? If not, why?


September 14, 2004
"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:ci0bq2$iof$1@digitaldaemon.com...
> about D and not seeing anything about GUI frameworks.

As noted in a related MIID post, a stable GUI framework is pretty much a prerequisite to an IDE/Debugger. The DigDug project is currently suspended until a mature GUI framework is available.


September 14, 2004
I'm hoping it isn't to late to post but I wanted to read all posts to be sure I wasn't repeating what someone said.

I would want to implement my class methods in another file. When I want to have a platform specific implementation in C++ I ussualy create a linux/, windows/ and macosx/ folder.

In D I have keep the entire implementation in one file and use version()s. Witch isn't to bad when there's only two platforms but three or more platforms isn't that easy.

The other way is to maintain copies of each file for each platform in diferent folders and then I have to remember that when I change one of the common methods I have to update the other files. This kind of development doesn't scale.

In a previous post you said we could use a "striper" to acomplish this. ¿Where can I find such a tool?.


Thanks.


Walter wrote:

> In some delightful ways, D is a victim of its own success. There's a lot of
> traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
> a day goes by without new proposals for features. It's simply beyond my
> capacity to give these all the attention they deserve, or even to read them
> all. I probably spend a minimum of 2 hours a day reading messages, and I
> could easilly spend 12 hours a day at it, and accomplish nothing else.
> 
> Hence, I inadvertently overlook important issues. I know that this has been
> frustrating to some people, and I apologize for it.
> 
> 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:
> 
> 1) compiler bugs
> 2) language shortcomings with no reasonable workarounds
> 3) issues that are fundamentally blocking projects from using or proceeding
> with D
> 4) severe library faults
> 
> I don't mean things like:
> 
> 1) D 2.0 issues
> 2) feature proposals like "It would be nice if ..."
> 3) minor irritants
> 4) philosophical issues
> 5) issues that have been beaten to death already <g>
> 
> If a thread here exists for the topic, a reference to that thread would be
> nice rather than reproducing it.
> 
> It's time to prioritize and get us on a rational, sensible path for
> releasing 1.0.
> 
> 
September 14, 2004
In article <ci7pr9$bbu$1@digitaldaemon.com>, Lynn Allan says...
>
>"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:ci0bq2$iof$1@digitaldaemon.com...
>> about D and not seeing anything about GUI frameworks.
>
>As noted in a related MIID post, a stable GUI framework is pretty much a prerequisite to an IDE/Debugger. The DigDug project is currently suspended until a mature GUI framework is available.

No one said the debugger had to be written in D.  Also, there are debuggers out there (gdb) with no GUI component at all.  From what Jill has said, it sounds like the biggest obstacle to decent interactive debugging is with template code.


Sean


September 15, 2004
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?

> * 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?

> * Test failure and test errors are separated.  Any test that throws
>    an exception other than an AssertionError (or whatever it is called)
>    has an error because the condition was not planned for.  If the assert
>    fails then the test fails.  ****Stack Traces Are Imperative****,
>    with unit tests it is more important to follow the trail of activity
>    with class names, method names, and line numbers.  The actual point
>    of failure is less important than what led up to it.

Agreed, completely.

> * 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.

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?

Mike Swieton
__
Brutes find out where their talents lie; a bear will not attempt to fly.
	- Jonathan Swift

September 15, 2004
Hi,
I start with an example, because I think I didn't understand.

# class Sum
# {
#   int add(int x, int y) { return x + y; }
#   int sub(int x, int y) { return x - y; }
#
#   unittest
#   {
#     assert(add(3,4) == 7);
#     assert(add(-2,0) == -2);
#     assert(sub(3,4) == -1);
#     assert(sub(2,1) == 1);
#   }
# }

According to the language specification, the unittest member function is called automatically at startup, before the main() function is called.

This can be accomplished by not issuing an assert() in case of failure, but logging to a file instead. From the previous example:

# 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
}

will run the tests and not the application.

Ciao