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


 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.


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


 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.


 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








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.


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


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


Then you will start something new ;-)
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


somebody's

 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




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


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






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


 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.



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


 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.


 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.


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


restrictions

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


if

 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


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.


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


 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.


 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.


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


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.


Your points are well taken. My emphasis on "systems" programming was an

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