Re: [Freedos-user] [ANN] picotap 0.0.2 - DOS/OpenWatcom compatible TAP generator & parser

[Rugxulo]

Hi,

On Tue, May 14, 2013 at 5:10 PM, Louis Santillan  wrote:
>
> Personally, I'd love to see a portable/multiple uclock implementations.

I don't think you're going to find it. Or at least you'd be lucky if
even clock() and time() from ANSI C worked reliably.

At risk of embarrassing myself, here's "timeit.c":

http://pastebin.com/2RC9922s


And, for comparison, "timeit.lua" and "timeit.rex":

http://pastebin.com/KeiYHg8J

http://pastebin.com/5Y7Y1Ggp


 (N.B. Lua/DJGPP and Regina/DJGPP may be worth looking at their C
sources, if you wish to mimic them.)

You could also check how DJGPP's "redir -t" does it:

http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/utils/redir.c?rev=1.7

EDIT: Apparently it calls gettimeofday() , which they claim is only
accurate to 1/20th of a second (should be good enough, no?).

Or, again, just use something like FreeDOS' RUNTIME (Eric Auer, x86 asm):

http://www.freedos.org/software/?prog=runtime

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

Power management (e.g. Turbo Boost) and multiple cores (RDTSCP is only
on fairly new cpus) can be problematic. Again, there is no perfect
solution, so you'll probably have to compromise.

> I'll definitely be using uclock, however, when I port the code to DJGPP.

P.S. We do have Perl 5.8.8 for DJGPP, but that is fairly old by now.
Or at least I don't think a lot of Perl code works with it anymore.
And neither upstream nor downstream seem to have heavy interest in
updating it. I dunno, you've been mentioning it, so maybe it's worth
looking into its sources, if you want, though I doubt it does anything
special for timing.

http://na.mirror.garr.it/mirrors/djgpp/current/v2gnu/perl588s.zip   (14 MB)

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

[Louis Santillan]

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

> Hi,
>
> On Tue, May 14, 2013 at 2:14 PM, Eric Auer  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

[Rugxulo]

Hi,

On Tue, May 14, 2013 at 2:14 PM, Eric Auer  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

[Eric Auer]

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

[Louis Santillan]

Thanks for the feedback.


On Mon, May 13, 2013 at 2:27 PM, Rugxulo  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 
> 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  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
> funct

Re: [Freedos-user] [ANN] picotap 0.0.2 - DOS/OpenWatcom compatible TAP generator & parser

[Rugxulo]

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

[Freedos-user] [ANN] picotap 0.0.2 - DOS/OpenWatcom compatible TAP generator & parser

[Louis Santillan]

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