Re: [Freedos-user] [ANN] picotap 0.0.2 - DOS/OpenWatcom compatible TAP generator parser
Thanks for the feedback. On Mon, May 13, 2013 at 2:27 PM, Rugxulo rugx...@gmail.com wrote: 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. 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 Win32. :/ 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. 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
Re: [Freedos-user] [ANN] picotap 0.0.2 - DOS/OpenWatcom compatible TAP generator parser
Hi!
... 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...
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
How about uclock? DJGPP uses ca. 1.1 MHz resolution for that,
with a combination of medium frequency timer ticks and the
current count in the timer state to get to full resolution.
typedef unsigned int uint32;
#include time.h
uint32 get_ytime (void)
{
uclock_t uclock_time; /* DJGPP: 64 bit uint */
uclock_time = uclock () * (uclock_t) 100;
return (uint32) ( uclock_time / UCLOCKS_PER_SEC ); /* ca. 1.1M */
}
Not POSIX because it has no nice unit such as microseconds,
but certainly worth using. For even more detail, you can use
the CPU time stamp counter. An example for that can be found
in the source code of my 2004 NEWTRACK eye-tracking software,
in the timer.c file :-)
Regards, Eric
--
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
Re: [Freedos-user] [ANN] picotap 0.0.2 - DOS/OpenWatcom compatible TAP generator parser
Hi, On Tue, May 14, 2013 at 2:14 PM, Eric Auer e.a...@jpberlin.de wrote: How about uclock? DJGPP uses ca. 1.1 MHz resolution for that, with a combination of medium frequency timer ticks and the current count in the timer state to get to full resolution. Not POSIX because it has no nice unit such as microseconds, but certainly worth using. For even more detail, you can use the CPU time stamp counter. Yes, of course, for DJGPP, uclock() is fine. But when you try to support other compilers and OSes, it's less useful. BTW, just FYI, uclock() does (optionally) use RDTSC already: http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/pc_hw/timer/uclock.c?rev=1.5 -- 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
Re: [Freedos-user] [ANN] picotap 0.0.2 - DOS/OpenWatcom compatible TAP generator parser
Personally, I'd love to see a portable/multiple uclock implementations. Some where the interface is the same in DJGPP, OW, TC, Micro-C, etc, and recompilation is all that you need for your given compiler. While rdtsc is theoretically nice, there's some drift when interacting with Power Management on some CPUs (Pentium Ms, Centrinos, others come to mind) where clock frequencies are variable. I'll definitely be using uclock, however, when I port the code to DJGPP. On Tue, May 14, 2013 at 2:38 PM, Rugxulo rugx...@gmail.com wrote: Hi, On Tue, May 14, 2013 at 2:14 PM, Eric Auer e.a...@jpberlin.de wrote: How about uclock? DJGPP uses ca. 1.1 MHz resolution for that, with a combination of medium frequency timer ticks and the current count in the timer state to get to full resolution. Not POSIX because it has no nice unit such as microseconds, but certainly worth using. For even more detail, you can use the CPU time stamp counter. Yes, of course, for DJGPP, uclock() is fine. But when you try to support other compilers and OSes, it's less useful. BTW, just FYI, uclock() does (optionally) use RDTSC already: http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/pc_hw/timer/uclock.c?rev=1.5 -- 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 -- 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
Re: [Freedos-user] [ANN] picotap 0.0.2 - DOS/OpenWatcom compatible TAP generator parser
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
[Freedos-user] [ANN] picotap 0.0.2 - DOS/OpenWatcom compatible TAP generator parser
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 -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
