Hi, 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> wrote: > > picotap is a tiny TAP-protocol[1] generator library (test) and TAP parser > (test harness) written in C and JavaScript (Browser & OneMonkey JS). It was > inspired by code in kazuho's github projects. It now compiles and runs on > Linux, OSX, DOS and your Browser. > > Code: > https://github.com/lpsantil/picotap > > Zip: > https://sites.google.com/site/lpsantil/Home/ptap002s.zip > > [1] 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 instead. 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. 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.) 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 permissions.) 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. 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). 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.) 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!) 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.) ------------------------------------------------------------------------------ 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. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
