Quoth tlaro...@polynum.com:
> But is clock_gettime(2) available in APE in any instance of Plan9 or is
> there a routine achieving the same purpose?
Here's a quick sketch of something that we could add; note
that the implemented monotonicity is really crude.
diff 03d870e0283299404b0eb46689d13f8538
The Vita Nuova man pages are woefully outdated. You might want to consider
purchasing the printed 9front man pages. http://9front.org/propaganda/books
Of course the most up-to-date man pages are available via man after a
sysupdate.
> For what I need, in fact I can simply use nsec(2), diffing nan
yeah, that's exactly it... well done man... good stuff ta failte roimhat...
/c:20211410:1900
On Thu, Oct 14, 2021 at 6:31 PM wrote:
> Le Thu, Oct 14, 2021 at 06:11:54PM +, Conor Williams a écrit :
> > surely you can shift a 64 bit long?
> >
>
> In fact, I have read cursorily the man page an
Le Thu, Oct 14, 2021 at 06:11:54PM +, Conor Williams a écrit :
> surely you can shift a 64 bit long?
>
In fact, I have read cursorily the man page and misread "the time is
expressed in seconds and microseconds since EPOCH" to mean "expressed
in seconds AND expressed in microseconds" while the
surely you can shift a 64 bit long?
On Thu, Oct 14, 2021 at 6:04 PM wrote:
> Le Thu, Oct 14, 2021 at 07:56:37PM +0200, tlaronde a écrit :
> > As suggested by o...@eigenstate.org, I have used gettimeofday(2) to
> > achieve what I needed.
> >
> > But I had to change suseconds_t (in POSIX) to long
Le Thu, Oct 14, 2021 at 07:56:37PM +0200, tlaronde a écrit :
> As suggested by o...@eigenstate.org, I have used gettimeofday(2) to
> achieve what I needed.
>
> But I had to change suseconds_t (in POSIX) to long (in Plan9
> ape/include/sys/time.h).
>
> But are all the compilers in Plan9 making lon
As suggested by o...@eigenstate.org, I have used gettimeofday(2) to
achieve what I needed.
But I had to change suseconds_t (in POSIX) to long (in Plan9
ape/include/sys/time.h).
But are all the compilers in Plan9 making long an octabytes, whatever
the arch and the machine? Because a long, if it is
Le Thu, Oct 14, 2021 at 12:49:47PM -0400, o...@eigenstate.org a écrit :
> Quoth tlaro...@polynum.com:
> > For kerTeX, I need to access a time reference with better than the
> > second.
> >
> > The answer is nsec(2).
> >
>
> For posix: we already have gettimeofday(),
> which has microsecond resol
Le Thu, Oct 14, 2021 at 06:42:53PM +0200, Sigrid Solveig Haflínudóttir a écrit :
> Sorry for not exactly being helpful with your issue, but that one is
> the exact reason I started on https://git.sr.ht/~ft/npe.
> APE is too limiting and sometimes it's easier to rewrite small parts
> of the software
Quoth tlaro...@polynum.com:
> For kerTeX, I need to access a time reference with better than the
> second.
>
> The answer is nsec(2).
>
For posix: we already have gettimeofday(),
which has microsecond resolution.
But also, I'd commit a patch that adds
clock_gettime: it's standardized, widely
us
Sigrid Solveig Haflinudottir
I have to take issue with your fourth point
Do NOT port anything for the sake of “porting” alone./c:202110015
On Thu, Oct 14, 2021 at 4:44 PM Sigrid Solveig Haflínudóttir <
ftrvxm...@gmail.com> wrote:
> Sorry for not exactly being helpful with your issue, but that one
Sorry for not exactly being helpful with your issue, but that one is
the exact reason I started on https://git.sr.ht/~ft/npe.
APE is too limiting and sometimes it's easier to rewrite small parts
of the software being ported with plan 9 libc-specific api.
I also did a small write-up on porting in ge
For kerTeX, I need to access a time reference with better than the
second.
The answer is nsec(2).
If there is no problem creating an object .o mixing POSIX functions and
nsec(2), when linking, under APE, nsec is not visible in libc.
How can one mix the two, preferably under APE (my framework use
13 matches
Mail list logo
