http://uvu.freshsources.com/page9/page7/files/Syllabus4450.html

Andrei

On 11/15/10 2:00 PM, Andrei Alexandrescu wrote:
> http://uvu.freshsources.com/page9/page7/files/Syllabus4450.html
>
> Andrei

I had a class from Chuck; he introduced me to D.  He's an excellent teacher.

Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> [Good Stuff™]

Awesome!

-- 
Simen

Andrei:

> http://uvu.freshsources.com/page9/page7/files/Syllabus4450.html

This is good. Despite its bugs/unfinished parts D2 is a good language to teach certain kinds of lower level programming (and some OOP too).

This is the page of the resources of the course: http://uvu.freshsources.com/page9/page7/page7.html

This is the D Homework: http://uvu.freshsources.com/page9/page7/files/D%20Homework.docx

It contains:

Implement a deque in D using two dynamic arrays, as depicted above. The following functions should be present:
push_front(x)
push_back(x)
pop_front()
pop_back()
at(uint pos)
back()
front()
size()

I see two small problems there:
- uint used instead of size_t
- Names like_this instead of the D idiom likeThis.

He also gives a quite useful unittest that the student implementation must pass, this is a good usage of unittests. The unit test ends like this:

...
    writeln("unit test passed");
}

Indeed, a person needs feedback that the unittests have run (and have succeed), I have used similar things in my dlbs1 (but more refined). This kind of need for feedback is so natural that something like that will be better somehow done on default by D.

Bye,
bearophile

bearophile Wrote:
> 
> He also gives a quite useful unittest that the student implementation must pass, this is a good usage of unittests. The unit test ends like this:
> 
> ...
>     writeln("unit test passed");
> }
> 
> Indeed, a person needs feedback that the unittests have run (and have succeed), I have used similar things in my dlbs1 (but more refined). This kind of need for feedback is so natural that something like that will be better somehow done on default by D.

I'd like unit tests to be optionally named: unittest("name").  The rest could then be done in library code.

On Tuesday, November 16, 2010 07:53:01 Sean Kelly wrote:
> bearophile Wrote:
> > He also gives a quite useful unittest that the student implementation must pass, this is a good usage of unittests. The unit test ends like this:
> > 
> > ...
> > 
> >     writeln("unit test passed");
> > 
> > }
> > 
> > Indeed, a person needs feedback that the unittests have run (and have succeed), I have used similar things in my dlbs1 (but more refined). This kind of need for feedback is so natural that something like that will be better somehow done on default by D.
> 
> I'd like unit tests to be optionally named: unittest("name").  The rest could then be done in library code.

That would indeed be great. With that done, it could become possible to run unit tests by name (though that would likely mean more changes for the compiler) in an IDE or whatnot. There's at least one bug report suggesting it, IIRC, though I think that it was suggested that they be named without the quotes. unittest(name) should probably translate to something like unittest_name in whatever scope it's in.

In any case, it's a good enhancement request that hasn't come to fruition yet. Most of the rest (if not all of it) could indeed be done in a library. Right now unit tests follow the unix convention of saying nothing on success, which I think is best for the current set up - particularly when it's not all that hard to add code yourself which prints out success if you really want it to.

- Jonathan M Davis

On Tue, 16 Nov 2010 10:54:50 -0800, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

>On Tuesday, November 16, 2010 07:53:01 Sean Kelly wrote:
>> bearophile Wrote:
>> > He also gives a quite useful unittest that the student implementation must pass, this is a good usage of unittests. The unit test ends like this:
>> > 
>> > ...
>> > 
>> >     writeln("unit test passed");
>> > 
>> > }
>> > 
>> > Indeed, a person needs feedback that the unittests have run (and have succeed), I have used similar things in my dlbs1 (but more refined). This kind of need for feedback is so natural that something like that will be better somehow done on default by D.
>> 
>> I'd like unit tests to be optionally named: unittest("name").  The rest could then be done in library code.
>
>That would indeed be great. With that done, it could become possible to run unit tests by name (though that would likely mean more changes for the compiler) in an IDE or whatnot. There's at least one bug report suggesting it, IIRC, though I think that it was suggested that they be named without the quotes. unittest(name) should probably translate to something like unittest_name in whatever scope it's in.
>
>In any case, it's a good enhancement request that hasn't come to fruition yet. Most of the rest (if not all of it) could indeed be done in a library. Right now unit tests follow the unix convention of saying nothing on success, which I think is best for the current set up - particularly when it's not all that hard to add code yourself which prints out success if you really want it to.
>
>- Jonathan M Davis

Already requested, see http://d.puremagic.com/issues/show_bug.cgi?id=2749

Gide

Jonathan M Davis:

> Most of the rest (if not all of it) could indeed be done in a library.

I am not sure it could be done nicely too :-)


> Right now unit tests follow the unix convention of saying nothing on success,

That's an usability failure. Humans expect feedback, because you can't tell apart "unittests run and succeed" from "unittests not even run". That Unix convention is bad here. And Unix commands sometimes have a -v (verbose) command that gives feedback, while D unittests don't have this option.


> particularly when it's not all that hard to add code yourself which prints out success if you really want it to.

It's also not hard to define global functions, wrapped in a version(unittest){}, to replace the need of the unittest keyword (unittest becomes a version ID).

Bye,
bearophile

On Tuesday, November 16, 2010 13:33:54 bearophile wrote:
> Jonathan M Davis:
> > Most of the rest (if not all of it) could indeed be done in a library.
> 
> I am not sure it could be done nicely too :-)

That would depend on what you're trying to do. Printing test success or failure is as simple as adding the approprate scope statement to the beginning of each unittest block. A bit tedious perhaps, but not hard.

> > Right now
> > unit tests follow the unix convention of saying nothing on success,
> 
> That's an usability failure. Humans expect feedback, because you can't tell apart "unittests run and succeed" from "unittests not even run". That Unix convention is bad here. And Unix commands sometimes have a -v (verbose) command that gives feedback, while D unittests don't have this option.

I'm afraid that I have to disagree there. Having all of the successes print out would, in many cases, just be useless output flooding the console. I have no problem with making it possible for unit tests to report success, but I wouldn't want that to be the default. It's quite clear when a test fails, and that's what is necessary in order to fix test failures.

I can see why a beginner might want the positive feedback that a test has succeeded, but personally, I would just find it annoying. The only real advantage would be that it would indicate where in the unit tests the program was, and that's only particularly important if you have a _lot_ of them and they take a long time to run.

Adding named unit tests and making it possible to call locate and call unit tests functions externally would make it possible to have an IDE or some other external tool deal with unit test successes and failures in a manner closer to what you're looking for, and I think that that sort of thing would be a definite step forward, but what we have works quite well. I think that extensions to it (like adding names to unit tests) would be great, but the only major change that I can think of which really needs to be made (rather than an extension) would be to make it so that all unittest blocks in a module run independently so that they all run regardless of whether any others fail (and I think that that change is supposed to be being done at some point). Making changes such as making unittest blocks print on success is not something that I would consider a good change (though making it possible wouldn't necessarily be bad).

> > particularly when it's not all that hard
> > to add code yourself which prints out success if you really want it to.
> 
> It's also not hard to define global functions, wrapped in a
> version(unittest){}, to replace the need of the unittest keyword (unittest
> becomes a version ID).

Almost, but not quite. -unittest also enables assertions if they would otherwise be disabled, which a simple version couldn't do.

- Jonathan M Davis

bearophile wrote:

> Jonathan M Davis:
> 
>> Most of the rest (if not all of it) could indeed be done in a library.
> 
> I am not sure it could be done nicely too :-)
> 
> 
>> Right now
>> unit tests follow the unix convention of saying nothing on success,
> 
> That's an usability failure. Humans expect feedback, because you can't tell apart "unittests run and succeed" from "unittests not even run". That Unix convention is bad here. And Unix commands sometimes have a -v (verbose) command that gives feedback, while D unittests don't have this option.

Actually the unix convention is to give exit code 0 as an indicator of
success, so there is feedback. It is very usable for scripting. But with the
change Sean suggested - and I assume an extension point in druntime - there
would be enough for a more human friendly tool to be built on top of the
current D unittesting system.

>> particularly when it's not all that hard
>> to add code yourself which prints out success if you really want it to.
> 
> It's also not hard to define global functions, wrapped in a
> version(unittest){}, to replace the need of the unittest keyword (unittest
> becomes a version ID).
> 
> Bye,
> bearophile