Thanks for the feedback.
On Mon, May 13, 2013 at 2:27 PM, Rugxulo <rugx...@gmail.com> wrote:
> Hope this reply isn't overly pedantic. Most of it isn't worth
> worrying about, honestly. Just skim it.
> On Fri, May 10, 2013 at 4:56 PM, Louis Santillan <lpsan...@gmail.com>
> > picotap is a tiny TAP-protocol generator library (test) and TAP parser
> > inspired by code in kazuho's github projects. It now compiles and runs
> > Linux, OSX, DOS and your Browser.
> > Code:
> > https://github.com/lpsantil/picotap
> > Zip:
> > https://sites.google.com/site/lpsantil/Home/ptap002s.zip
> >  http://en.wikipedia.org/wiki/Test_Anything_Protocol
> Various comments:
> 1). Your MKWCC.BAT file has two minor errors:
> a). You can't put redirection stuff in REM comments (e.g. the <>
> around your email). You'll have to use unofficial "::" comments
> b). One of your "echo" lines (the one before "Build from scratch:")
> doesn't print an empty line (which is what I assume you intended) but
> instead "ECHO is off" ... use "echo." instead.
Thanks. Already fixed locally.
> 2). Your (GNU?) "Makefile" ...
> a). ... would be better off named "GNUMakefile" so as not to clash
> with other potential makes. (Probably not worth worrying about, but
> just FYI. Yes, I know, a lot of projects assume Gmake these days.)
> b). Also, your use of "cc" may not be ideal as I think latest POSIX
> deprecates or even removes that in favor of "c99". Similarly, I'm not
> sure anything (like your "-O3") besides "-O" is necessarily supported.
> (BTW, you can use the "owcc" POSIX driver, even in DOS, if you want to
> be more consistent.)
I seem to piss people off with the way I write Makefiles. :D I even had an
FreeBSD committer rant and rave at me about a Makefile that was marked
.POSIX in <https://code.google.com/p/ucpp/> that was written by someone
else. Told him I didn't care enough to change it to make POSIX, but if he
did, he could send me the patch. He never responded. :)
Anyways, the Makefile isn't intended for OW, :/, after I read about all the
limitations in wmake. It's intended for Linux/OSX with gcc/clang.
So, much of the "POSIX compatibility" is only available on Linux, OS/2, or
> c). I'm no expert, but it might be cleaner/wiser to make "rm -r" and
> "cp" into macros (RM, CP), for customizability. *nix users probably
> prefer "install" to install, but it probably? doesn't matter here.
> (Similarly, "cp -p" is preferred if wishing to keep timestamps and
> d). Also, hardcoding the rules for each .exe is probably redundant;
> you can use pattern rules ("%.exe: %.c").
> e). Actually, it might? be better to make an "EXE=" (or EXEEXT)
> macro, but that can be vaguely annoying either way, not necessarily
> worth the hassle (though it isn't too too hard).
> f). I know I'm going too arcane here, but "uname" from DJGPP 2.03p2
> (shl2011b.zip) doesn't correctly recognize "FreeDOS". Only the one
> from 2.04 does. Just checked, yeah, it says "Unknow??", blech.
C & D are good ideas. I'm using DJGPP 2.04b2 and uname returns FreeDOS.
> 3). I'm not sure I understand the point of "taptime.*". It may? be
> better to just let external tools do timings for you, e.g. runtime, sh
> -c time, redir -t, upct, or whatever. (Heck, I wrote my own in C, Lua,
> and Rexx. You're welcome to them.) You're relying on POSIX too heavily
> here. Do you really need milliseconds that badly? In my ANSI C
> version, I used both clock() and time()/difftime(), mostly because one
> method doesn't seem to work in my Linux install. One way should tell
> parts of seconds, the other only whole seconds. Either way is "close
> enough", IMHO (though there are ten bazillion corner cases for such
> timings: power management, multiple cores, FPU usage, threads, clock
> granularity, roll over, timezone).
I had considered that. Most TAP harnesses (tap runners, TAP comes from the
perl world) calculate the execution time themselves with resolution in the
msec range always. There's 15+ year old code around that'll reprogram the
PIT to 1kHz resolution and keep the standard 18.2 Hz tick going as well (~5
msec). Disappointedly, DJGPP, by default doesn't do any better either with
its POSIX functions. Even the DOS does 10 msec resolution via INT 0x21/0x2C
> 4). popen isn't ANSI C, it's POSIX, that's probably why OpenWatcom
> doesn't support it. Actually, they seem to have it in stdio.h as
> "_popen", but I've not tested it. It's probably a bad assumption to
> assume popen is supported. IIRC, even BWK's AWK had to workaround it
> for Windows. (N.B. stock DJGPP 2.04 has a bug that Juan is already
> fixing with code from CVS every time he ports something.)
_popen is only on Linux, OS/2, Win32. :/ I'll look into the popen but so
far haven't found it.
> 5). tempnam ... I can't even begin to remember all the various
> functions for such stuff. (EDIT: tmpnam, L_tmpnam is what I was
> thinking of. Hmmm, even popular mktemp / mkstemp aren't POSIX, or at
> least not older POSIX. Seems it's there in 2001.) I always thought
> using tmpfile() [ANSI C] was the easiest way, but some people don't
> use it. (Usually it works well, but IIRC, it was fairly broken in
> MSVCRT.DLL, it tried to write to C:\, hence needs Admin access!)
Same issue as popen. These don't seem that hard to implement by OW, even
> 6). I know it isn't hard to fake a stdbool.h (C99), but keep in mind
> that most older DOS compilers don't support it out-of-the-box. Well,
> I'm sure you thought of that if you plan to convert to various other C
> compilers too.
> 7). BTW, I've not really used various test harnesses. Mostly because
> they are too confusing, heavyweight, or POSIX specific. (IIRC, DejaGNU
> never worked with DJGPP for various reasons. It depends on Expect,
> which is written in Tcl. We do have some third-party Tcl builds, but
> they may not be too reliable, and I'm way too inexperienced to say for
> sure or fix them up. It's a lonely world for DOS developers.)
> I ended up writing my own testing .BAT (making some FreeCOM-specific
> assumptions about quotes around .BAT parameters being combined into
> one arg) for my own limited use. I doubt it's worth posting here, but
> the .BAT calls itself (pseudo functions) and pipes test input into the
> offending app, and the result is grep'd. If found (or not), grep
> returns an appropriate errorlevel, which I then saved in order to (at
> end) print "yyynnyy" style success/failure result for easier reading.
> (Yet another boring arcane detail: I would've used FreeDOS find, but
> it apparently doesn't like lines that don't end in CR+LF. Well, and it
> has a horrible LFN-status-related crash bug that I never bothered to
> track down either.)
So here's a little advocation for TAP vs other types of unit testing
(assert, J/Q/C/JS/Unit, Mocha, JSCheck/QuickCheck, Expect). I like TAP,
because, even in its most basic form (and as I implemented in picotap), it
forces very little form or structure on the test writer, and allows for a
"Test as you fly, Fly as you test" style of test writing. It let's you
write your tests as if you were writing a normal program with extra checks
embedded. So in that sense, it's a little like using assert. The main
difference is that a failed subtest doesn't kill the entire test plan
(program) where a failed assert will.
int main( int argc, char** argv )
plan( 3 );
ok( 5 == 5, "5 equals 5" );
ok( true == true, "true" );
ok( true == true, "true" );
return( 0 );
tap.h adds just two functions, plan( int ), and ok( bool, char* ).
Here's the output:
ok 1 - 5 equals 5
ok 2 - true
ok 3 - true
ok() will output ok (success) or not ok (fail). Everything after
ok/not ok is considered metadata. Even the "test number". They could
be out of order, missing, etc. The spec says they shouldn't matter
but some test harnesses are stricter. If you need to output status or
comment, prefix the message with a "#". tap in picotap is not very
sophisticated. Other tap test harnesses will provide more
sophisticated input parsing. If you prefix output with a space or a
tab or even have a blank line, it becomes part of the metadata of the
tap in picotap will parse the input into:
Examples/C/test.exe .. ok
All tests successful.
Files=1, Tests=3, 9 msecs
tap mimics prove's (from perl) output somewhat. So, the desire for
msec resolution time is to mimic that output. And, in some types of
testing, knowing the execution time is part successfully passing the
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
Freedos-user mailing list