September 13, 2004
In article <cht9gl$20m8$1@digitaldaemon.com>, Walter says...
>
>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

Memory management issues - specifically, the interaction of the garbage collector with DLLs and the absence of C++-style memory management.

I shall be more specific.

(1) Suppose a class A has its own custom allocator/deallocator. Suppose it also
has a destructor. I want to be able to call the destructor (~this()) /without/
also calling the deallocator. I also want to be able to call the deallocator
(the delete override) /without/ also calling the destructor. Both of these
things are possible in C++, but not in D. Same goes for allocation versus
construction.

(2) I want to be able to globally (not just per-class) override new. For
example, I want to be able to do:

#    int[] array = new(myGlobalAllocator) array[n];

(3) And (most importantly) I want the garbage collector's memory-tracking
mechanism to /notify me/ when the memory I've allocated via my custom allocator
is no longer referenced.

With these modifications in place, all memory allocation issues, including garbage collection across DLL boundaries; plugging in an alternative garbage collector; secure wiping of sensitive data; super-fast allocation/deallocation of small objects; etc., would become immediately and simply solvable.

Okay, so that's three things, not two, but they go together, and missing any one of them out seemed a bit dumb.

Jill


September 13, 2004
Walter wrote:
<snip>
> 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.
<snip>

1. A complete spec.
2. Complete functionality in line with the spec.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.
September 13, 2004
Sai wrote:
<snip>
> 3. Documentation is very bad. I think any powerful API is useless
> unless it is well documented. Lacking of "Search" facility or "Index" in D documentation is a huge discouraging factor.
<snip>

Doesn't your web browser allow you to search within a page?

To me, the trouble with Phobos documentation is the amount of Phobos that is still undocumented.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.
September 13, 2004
In article <pan.2004.09.11.20.54.46.684151@swieton.net>, Mike Swieton says...
>
>I'm not sure if this is a shortcoming, or just a feature request, but I'll mention it again: D's unit test facility is not usable for test driven development (because it's unnecessarily difficult to run a subset of tests)

How narrow a subset do you need? I have set up my makefile to make a stand alone program of each module, called ut_modname, which does nothing but run the module unit tests.

> or for automated builds (because a single failure will halt
>execution of the test suite).

Can't you get around this by writing errors to stdout, stderr or a log file instead of using asserts?

Nick


September 13, 2004
In article <ci4oks$2rt0$1@digitaldaemon.com>, Nick says...
>
>In article <pan.2004.09.11.20.54.46.684151@swieton.net>, Mike Swieton says...
>>
>>I'm not sure if this is a shortcoming, or just a feature request, but I'll mention it again: D's unit test facility is not usable for test driven development (because it's unnecessarily difficult to run a subset of tests)
>
>How narrow a subset do you need? I have set up my makefile to make a stand alone program of each module, called ut_modname, which does nothing but run the module unit tests.
>
>> or for automated builds (because a single failure will halt
>>execution of the test suite).
>
>Can't you get around this by writing errors to stdout, stderr or a log file instead of using asserts?
>

No, not and have it still be D's unit test facility. Sure, I can write CppUnit
in D, and use that. But that's
hardly means that D's unit test feature works. Just because I can implement test
selection in a Makefile
doesn't mean that it's a solution. It's only a workaround.

Good unit test suites which meet all of my criteria can be made and written in
D. But that can be done
in assembly and befunge too. I am saying that if I want to do this in D, I have
to actively fight 'features'
of D's unit testing. Therefore, D does not have a sufficient unit test facility.


September 13, 2004
In article <ci4q6p$he$1@digitaldaemon.com>, Mike Swieton says...
>
>No, not and have it still be D's unit test facility. Sure, I can write CppUnit
>in D, and use that. But that's
>hardly means that D's unit test feature works. Just because I can implement test
>selection in a Makefile
>doesn't mean that it's a solution. It's only a workaround.

Point taken.

>Good unit test suites which meet all of my criteria can be made and written in
>D. But that can be done
>in assembly and befunge too. I am saying that if I want to do this in D, I have
>to actively fight 'features'
>of D's unit testing. Therefore, D does not have a sufficient unit test facility.

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


September 13, 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:
> 
> 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>

It might not exactly follow your guidelines, but I would add:
static initialization of dynamic arrays and hashes (assoziative arrays).

In Perl you write just

   my @array=( 1, 12, 333, -4, 5);
   my %hash=(  'darkred' => '#bb0000',  'red' => '#ff0000',  'lightred' => '#ffcccc');

and this makes array and hashes really a pleasure to use. Of course, the exact syntax for this isn't important.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com
September 13, 2004
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


These are my requirements (in no order):

1: Test isolation. I should be able to have a single test failure abort only
	that test.

	Rationale: Automated tests. At work, we have one particular product who's
	test suite takes hours to run fully. Others merely take tens of minutes. I
	run it over night, and I want to come in in the morning and see a complete
	report of the results, not just the first failure.

2: Test selection. I should be able to select a subset of tests
	programatically.

	Rationale: This stems from the above: with a large test suite, I should be
	able to run just a few. The 'programatically' part is essentially
	philosophical: managing the test suite is the job of the test framework, not
	the build system.

2: Separate tests from application. I should be able to run the tests without
	running the application.

	Rationale: A unit test for a single function doesn't require the entire app.
	Also, the startup of a large program may be time consuming, resource
	intensive, or interactive. Again, this is largely ideological: the tests and
	the app are simply not the same thing. It is illogical to run a batch of
	tests overnight, and come back to a running app in the morning. Why are the
	two activities connected?

3: Test reports. I should be able to generate some sort of report about which
	tests failed, and why.

	Rationale: Currently, if there's a failure, testing terminates. However, if
	I want to run a batch of 5000 tests, and 300 fail, it's impractical for me
	to not have a file documenting it.

4: Useful asserts. I want an assertEquals. I want an assert with a message.
	Rationale: I'm lazy. Also, I want a message because assert(x < 3 && x > 1)
	doesn't really *mean* "assert that x is between 1 and 3". It means something
	like "assert that x is within the range valid for brake forces".

	Walter has said that the line number output is enough, but that's gets less
	useful for unit test suites because if I get a test report of 300 failures,
	I want to look at the report and see why it failed. I don't want to see 300
	line numbers.

5: Setup/teardown methods.

	Rationale: it is tremendously useful to be able to run some setup/cleanup
	code before/after tests run, to ensure a clean environment. This is
	basically required when the code involves something persistent that needs
	the state to be reset, such as a hardware device or database.

Now, this is how I want things to behave. This doesn't necessarily mean that it needs to be implemented in the language itself, only that it should be able to be done without replacing D's unit testing.

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

If these two are done, a library could be written on top of D allowing D to keep the current behavior (test fatality would stay because the exception would be uncaught, and test selection would follow the current scheme). At the same time, a library could allow you to select which tests to run, handle all the logging, etc.

I don't care if this is how it's solved, but right now I don't feel that D can really advertise built in unit testing. It simply isn't there yet.

What I object to now is that to get the behavior I want (which is required for
TDD), I need to throw away or work around D's built in unit testing - one of
my (theoretically) favorite D features.

Mike Swieton
__
If the government wants us to respect the law, they should set a better
example.

September 14, 2004
Helmut Leitner wrote:
<snip>
> It might not exactly follow your guidelines, but I would add:
> static initialization of dynamic arrays and hashes (assoziative arrays).
> 
> In Perl you write just
> 
>    my @array=( 1, 12, 333, -4, 5);
>    my %hash=(  'darkred' => '#bb0000',  'red' => '#ff0000',  'lightred' => '#ffcccc');
> 
> and this makes array and hashes really a pleasure to use.
> Of course, the exact syntax for this isn't important.

Presumably they'd take on the exact same syntax we already have for static initialisation of static arrays.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.
September 14, 2004
In article <ci3jv1$10v8$1@digitaldaemon.com>, Arcane Jill says...

I want to change my mind about what I consider the most important and urgent impediment to writing code in D.

Instead of my previous suggestion (GC/DLL/memory management issues), I now want to vote instead for DEBUGGING INFORMATION.

I can use D with Visual Studio to a limited extent, but it won't expand non-primitive D types, and -- /most importantly/ -- if you try to step into a template class or function, the source-code view jumps to COMPLETELY THE WRONG PLACE.

Is this hindering development? Yes, absolutely. In fact, it's the sole reason I'm not using templates yet.

Jill