www.digitalmars.com         C & C++   DMDScript  

D - unittest() on module ???

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Ok, another question...as I read the specs, unittest() sounded like it
only was available as a member function of classes.  But adi.d has a
bunch of them out at module level.  I presume that this means that all
of them are run automatically as the unit test of the module.  If this
is correct, the QA dept should have noted that in the spec ;-)

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Apr 10 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CB50812.32369985 deming-os.org...

 Ok, another question...as I read the specs, unittest() sounded like it
 only was available as a member function of classes.  But adi.d has a
 bunch of them out at module level.  I presume that this means that all
 of them are run automatically as the unit test of the module.  If this
 is correct, the QA dept should have noted that in the spec ;-)

In fact, unittest is module-level function. See string.d, regexp.d...
Apr 10 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Pavel Minayev wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CB50812.32369985 deming-os.org...

 Ok, another question...as I read the specs, unittest() sounded like it
 only was available as a member function of classes.  But adi.d has a
 bunch of them out at module level.  I presume that this means that all
 of them are run automatically as the unit test of the module.  If this
 is correct, the QA dept should have noted that in the spec ;-)

In fact, unittest is module-level function. See string.d, regexp.d...

Yeah, it makes sense. But it should be in the docs. Also, the docs should note that one module can have multiple unittests. -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Apr 10 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CB50E8C.EA1F02D5 deming-os.org...
 Pavel Minayev wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CB50812.32369985 deming-os.org...
 Ok, another question...as I read the specs, unittest() sounded like it
 only was available as a member function of classes.  But adi.d has a
 bunch of them out at module level.  I presume that this means that all
 of them are run automatically as the unit test of the module.  If this
 is correct, the QA dept should have noted that in the spec ;-)



 note that one module can have multiple unittests.

Bruce Eckel originally pointed out that D needed language support for unit testing. He showed me some of the kludgy ways it was done in other languages that weren't accommodating of the concept. Once I implemented it and tried it out, my thinking on how it should be used evolved and its role expanded. Unit testing has in my mind risen to become a main feature of D. For library functions it works out great, serving both to guarantee that the functions actually work and to illustrate how to use the functions. Consider the many C++ library and application code bases out there for download on the web. How much of it comes with *any* verification tests at all, let alone unit testing? Less than 1%? The usual practice is if it compiles, we assume it works. And we wonder if the warnings the compiler spit out in the process are real bugs or just an irrelevancy. Along with design by contract, unit testing makes D far and away the best language for writing reliable, robust systems applications. Nearly every one of those library routines had at least one bug exposed by the unit testing. Unit testing also gives us a quick-and-dirty estimate of the quality of some unknown piece of D code dropped in our laps - if it has no unit tests and no contracts, it's unacceptable. (I'm going to regret making that last statement!)
Apr 10 2002
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CB50E8C.EA1F02D5 deming-os.org...
 Pavel Minayev wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CB50812.32369985 deming-os.org...
 Ok, another question...as I read the specs, unittest() sounded like it
 only was available as a member function of classes.  But adi.d has a
 bunch of them out at module level.  I presume that this means that all
 of them are run automatically as the unit test of the module.  If this
 is correct, the QA dept should have noted that in the spec ;-)



 note that one module can have multiple unittests.

Bruce Eckel originally pointed out that D needed language support for unit testing. He showed me some of the kludgy ways it was done in other languages that weren't accommodating of the concept. Once I implemented it and tried it out, my thinking on how it should be used evolved and its role expanded. Unit testing has in my mind risen to become a main feature of D. For library functions it works out great, serving both to guarantee that the functions actually work and to illustrate how to use the functions. Consider the many C++ library and application code bases out there for download on the web. How much of it comes with *any* verification tests at all, let alone unit testing? Less than 1%? The usual practice is if it compiles, we assume it works. And we wonder if the warnings the compiler spit out in the process are real bugs or just an irrelevancy. Along with design by contract, unit testing makes D far and away the best language for writing reliable, robust systems applications. Nearly every one of those library routines had at least one bug exposed by the unit testing. Unit testing also gives us a quick-and-dirty estimate of the quality of some unknown piece of D code dropped in our laps - if it has no unit tests and no contracts, it's unacceptable. (I'm going to regret making that last statement!)

I like it :) And I'm sorry, I now see that unittest *is* documented under modules...I just jumped to the conclusion that they were only for classes. :/ -- The Villagers are Online! http://villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Apr 10 2002
prev sibling parent reply "J. Daniel Smith" <j_daniel_smith HoTMaiL.com> writes:
IMHO, you really need to stop focusing on the "system" aspects of D.  Your
third paragraph below should read "...makes D far and away the best language
for writing reliable, robust applications. ..."  "Systems" programming to me
means conjures up things like device drivers, compilers and linkers.

Your comments (here and on the website) about unit tests and
design-by-contract are valid for ALL types of applications, and D by and
large looks to be well on it's way to having the makings of a great
general-purpose programming language.

   Dan

"Walter" <walter digitalmars.com> wrote in message
news:a9381e$jin$1 digitaldaemon.com...
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CB50E8C.EA1F02D5 deming-os.org...
 Pavel Minayev wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CB50812.32369985 deming-os.org...
 Ok, another question...as I read the specs, unittest() sounded like




 only was available as a member function of classes.  But adi.d has a
 bunch of them out at module level.  I presume that this means that




 of them are run automatically as the unit test of the module.  If




 is correct, the QA dept should have noted that in the spec ;-)



 note that one module can have multiple unittests.

Bruce Eckel originally pointed out that D needed language support for unit testing. He showed me some of the kludgy ways it was done in other

 that weren't accommodating of the concept. Once I implemented it and tried
 it out, my thinking on how it should be used evolved and its role

 Unit testing has in my mind risen to become a main feature of D. For

 functions it works out great, serving both to guarantee that the functions
 actually work and to illustrate how to use the functions.

 Consider the many C++ library and application code bases out there for
 download on the web. How much of it comes with *any* verification tests at
 all, let alone unit testing? Less than 1%? The usual practice is if it
 compiles, we assume it works. And we wonder if the warnings the compiler
 spit out in the process are real bugs or just an irrelevancy.

 Along with design by contract, unit testing makes D far and away the best
 language for writing reliable, robust systems applications. Nearly every

 of those library routines had at least one bug exposed by the unit

 Unit testing also gives us a quick-and-dirty estimate of the quality of

 unknown piece of D code dropped in our laps - if it has no unit tests and

 contracts, it's unacceptable.

 (I'm going to regret making that last statement!)

Apr 11 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"J. Daniel Smith" wrote:

 IMHO, you really need to stop focusing on the "system" aspects of D.  Your
 third paragraph below should read "...makes D far and away the best language
 for writing reliable, robust applications. ..."  "Systems" programming to me
 means conjures up things like device drivers, compilers and linkers.

 Your comments (here and on the website) about unit tests and
 design-by-contract are valid for ALL types of applications, and D by and
 large looks to be well on it's way to having the makings of a great
 general-purpose programming language.

I agree (about the terminology). I think "general-purpose" is exactly what Walter is getting at - unlike some other languages (like Java, BASIC, or whatever), D is useful for BOTH applications AND low-level drivers and kernel programming. However, the term "systems applications" conjures up (in my mind) an explicit focus on low-level stuff. Frankly, I'm excited about using D for all my applications...and somebody's going to have start porting the Linux kernel over ;-) (Pavel, you seem the most avid porter of all of us...there's a project for you!) -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Apr 11 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CB5BEFA.8355ACC deming-os.org...

 Frankly, I'm excited about using D for all my applications...and

 going to have start porting the Linux kernel over ;-)  (Pavel, you seem

 avid porter of all of us...there's a project for you!)

Well, since I don't like Linux, I guess it's not a project for me... =)
Apr 11 2002
parent Stephan Wienczny <wienczny web.de> writes:
Pavel Minayev wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CB5BEFA.8355ACC deming-os.org...
 
 
Frankly, I'm excited about using D for all my applications...and

somebody's
going to have start porting the Linux kernel over ;-)  (Pavel, you seem

the most
avid porter of all of us...there's a project for you!)

Well, since I don't like Linux, I guess it's not a project for me... =)

Jun 09 2003
prev sibling parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CB5BEFA.8355ACC deming-os.org...

snip

 Frankly, I'm excited about using D for all my applications...and

 going to have start porting the Linux kernel over ;-)

It isn't obvious, at least to me :-), that a garbage collected language will work for an operating system. I know there has been much gnashing of teeth over Java's GC system among the people who want to use JAVA for embedded applications. I don't know all of the details, but much of it revolves arount having the system decide to do GC at inopportune times, like when a response is required in reeal time to some external event. (Pavel, you seem the most
 avid porter of all of us...there's a project for you!)

 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]

Apr 12 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Stephen Fuld wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CB5BEFA.8355ACC deming-os.org...

 It isn't obvious, at least to me :-), that a garbage collected language will
 work for an operating system.  I know there has been much gnashing of teeth
 over Java's GC system among the people who want to use JAVA for embedded
 applications.  I don't know all of the details, but much of it revolves
 arount having the system decide to do GC at inopportune times, like when a
 response is required in reeal time to some external event.

Well, hopefully (for the existing code) Linux already does all of the memory allocation manually...so there never will be any leftover objects for the GC to cleanup. However, I figure a port of Linux would require a custom (or modified) GC. When somebody turns off interrupts, then you can disable the GC at the same time, or something like that... -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Apr 12 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CB750BE.21B151D7 deming-os.org...
 Stephen Fuld wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CB5BEFA.8355ACC deming-os.org...
 It isn't obvious, at least to me :-), that a garbage collected language


 work for an operating system.  I know there has been much gnashing of


 over Java's GC system among the people who want to use JAVA for embedded
 applications.  I don't know all of the details, but much of it revolves
 arount having the system decide to do GC at inopportune times, like when


 response is required in reeal time to some external event.


 allocation manually...so there never will be any leftover objects for the

 cleanup.  However, I figure a port of Linux would require a custom (or

 GC.  When somebody turns off interrupts, then you can disable the GC at

 time, or something like that...

It may not be obvious, but unlike Java, D does not force you to allocate objects using the garbage collector. You can revert to using the underlying C functions (which is what the GC implementation itself does for the tables). The linux kernel is written in C anyway, does not use class objects, and so would be readilly portable to D.
Apr 12 2002
parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a97juu$273c$1 digitaldaemon.com...
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CB750BE.21B151D7 deming-os.org...
 Stephen Fuld wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3CB5BEFA.8355ACC deming-os.org...
 It isn't obvious, at least to me :-), that a garbage collected



 will
 work for an operating system.  I know there has been much gnashing of


 over Java's GC system among the people who want to use JAVA for



 applications.  I don't know all of the details, but much of it



 arount having the system decide to do GC at inopportune times, like



 a
 response is required in reeal time to some external event.


 allocation manually...so there never will be any leftover objects for


 GC to
 cleanup.  However, I figure a port of Linux would require a custom (or

 GC.  When somebody turns off interrupts, then you can disable the GC at

 time, or something like that...

It may not be obvious, but unlike Java, D does not force you to allocate objects using the garbage collector. You can revert to using the

 C functions (which is what the GC implementation itself does for the
 tables). The linux kernel is written in C anyway, does not use class
 objects, and so would be readilly portable to D.

You're right! It wasn't obvious, but it is interesting. So, if I understand this correctly, you could port the Linux kernel, but if you wanted to do any enhancements that weren't just ports of the underlying C implementation, you would have to be a little carefull about what D constructs you used. Is one assured that all of the D library one would need to link in conforms to the restrictions? Would it make sense in some future release to add a compiler option that would enforce the restrictions and even mark the resutling output such that the GC wasn't even linked in if it wasn't needed? So you would get some of the advantages of D, but not all of them and must exerise more than normal care. Not a bad price to pay. Thanks Walter. -- - Stephen Fuld e-mail address disguised to prevent spam
Apr 13 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:a99prg$2acq$1 digitaldaemon.com...
 It may not be obvious, but unlike Java, D does not force you to allocate
 objects using the garbage collector. You can revert to using the

 C functions (which is what the GC implementation itself does for the
 tables). The linux kernel is written in C anyway, does not use class
 objects, and so would be readilly portable to D.

understand this correctly, you could port the Linux kernel, but if you wanted to do any enhancements that weren't just ports of the underlying C implementation, you would have to be a little carefull about what D constructs you used.

Correct. It wouldn't be a job for a novice, but then again, Linux kernel hacking is for experts anyway <g>.
 Is one assured that all of the D library one would
 need to link in conforms to the restrictions?  Would it make sense in some
 future release to add a compiler option that would enforce the

 and even mark the resutling output such that the GC wasn't even linked in

 it wasn't needed?

The thing to do would be to create a special D library (note that the linux kernel uses its own C runtime library anyway, not the standard one, so this wouldn't be any travesty) that doesn't contain the GC.
 So you would get some of the advantages of D, but not all of them and must
 exerise more than normal care.   Not a bad price to pay.  Thanks Walter.

You're welcome. There are plenty of other benefits D can bring to the kernel, for example, versioning, elimination of the preprocessor, modular name spaces, unit testing, contracts, a MUCH better inline assembler <g>, etc.
Apr 14 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a9clk6$1sfj$2 digitaldaemon.com...

 The thing to do would be to create a special D library (note that the

 kernel uses its own C runtime library anyway, not the standard one, so

 wouldn't be any travesty) that doesn't contain the GC.

What about making the GC built into the kernel? Yes, an OS with built-in garbage collection memory allocation system! API with contracts would be really nice as well.
Apr 14 2002
parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a9cnvi$1v5a$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:a9clk6$1sfj$2 digitaldaemon.com...
 The thing to do would be to create a special D library (note that the

 kernel uses its own C runtime library anyway, not the standard one, so

 wouldn't be any travesty) that doesn't contain the GC.

garbage collection memory allocation system! API with contracts would be really nice as well.

I think GC would benefit if it was built in to the operating system's virtual paging system. I don't know enough about the kernel to know what kinds of issues there are with GC for the kernel itself.
Apr 14 2002
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I'm not convinced that GC in a kernel is a bad idea...provided you can turn it
off, and you have enough smarts to not require memory cleanup during interrupt
handlers and the like.

Also, kernel-side GC would have to run in supervisor mode, and we wouldn't want
that to be a blocking, non-preemptible process, but Linux is moving toward
preemptible kernel processes anyway.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Apr 14 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"J. Daniel Smith" <j_daniel_smith HoTMaiL.com> wrote in message
news:a941gl$1efo$1 digitaldaemon.com...
 IMHO, you really need to stop focusing on the "system" aspects of D.  Your
 third paragraph below should read "...makes D far and away the best

 for writing reliable, robust applications. ..."  "Systems" programming to

 means conjures up things like device drivers, compilers and linkers.

 Your comments (here and on the website) about unit tests and
 design-by-contract are valid for ALL types of applications, and D by and
 large looks to be well on it's way to having the makings of a great
 general-purpose programming language.

Your points are well taken. My emphasis on "systems" programming was an attempt to distinguish D from so-called "web" languages like C#, Java, Javascript, etc., which compile to a bytecode that is then interpreted/compiled in an attempt to have portable executables (as opposed to portable source).
Apr 11 2002
prev sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CB50812.32369985 deming-os.org...
 Ok, another question...as I read the specs, unittest() sounded like it
 only was available as a member function of classes.  But adi.d has a
 bunch of them out at module level.  I presume that this means that all
 of them are run automatically as the unit test of the module.  If this
 is correct, the QA dept should have noted that in the spec ;-)

 --
 The Villagers are Online! http://villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]

"the QA dept should have noted that in the spec ;-)" Fire 'em I say! :) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
Apr 12 2002
parent "Walter" <walter digitalmars.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a97nl1$2b4i$1 digitaldaemon.com...
 "the QA dept should have noted that in the spec ;-)"
 Fire 'em I say!

Good suggestion. ... [lots of shouting and banging] ... Ok, they're gone now.
Apr 12 2002