>> It's the pointers in each list member. If nothing else, a list
>> member will have a pointer to the next member. The MRU list has
>> next, previous, and next-hash-chain pointers.
> Ouch, I'd try to fix that. Maybe a different list layout model?
> Given the churn in the MRU list it may be a
f...@fwright.net said:
> The 32-bit x86 architecture is so register-crippled that C code typically
> runs about 15% faster when compiled for X86_64 than when compiled for i386,
> in spite of the poorer cache locality caused by the larger pointers.
I don't want the code to run in 32 bit mode.
I
Yo Daniel!
On Sun, 26 Mar 2017 22:14:01 -0500
Daniel Poirot wrote:
> ...careful what you wish for...
:-)
> Rule 3-9-2
> (Advisory)
> typdefs that indicate size and signedness should be used in place of
> the basic numerical types.
We are slowly working that way.
RGDS
GARY
---
> bignum is integers, Hal needs floats.
Actually, I don't "need" floats. That's just what the python date/time stuff
uses.
The original goal that started this discussion was to remove one slot from
the python-c interface so I could remove some code ugly from the c side.
That slot just prints
...careful what you wish for...
The topic of this email thread is addressed in MISRA 2008 C++ Rule
3.9.2. See 'MISRA-Cpp-2008.pdf'
Rule 3-9-2
(Advisory)
typdefs that indicate size and signedness should be used in place of
the basic numerical types.
On Sun, Mar 26, 2017 at 9:41 PM, Gary E. Mille
Yo Daniel!
On Sun, 26 Mar 2017 21:11:13 -0500
Daniel Poirot wrote:
> Look for the 'bignum' package:
>
> https://www.python.org/dev/peps/pep-0237/
bignum is integers, Hal needs floats. Might be a way to wedge it in.
RGDS
GARY
---
Yo Hal!
On Sun, 26 Mar 2017 19:04:22 -0700
Hal Murray wrote:
> g...@rellim.com said:
> >> Isn't that as simple as convert a 64 bit integer to float and
> >> divide by 1<<32 to get the right scale?
> > Nope. Loss of precision. A double only has 52 bits of significant
> > digits. A float only
Yo Daniel!
On Sun, 26 Mar 2017 21:09:06 -0500
Daniel Poirot wrote:
> You want to see some real misery? Run the code through the MISRA
> rules. Horrible.
I love horrible. How do I do that?
RGDS
GARY
---
Gary E. Miller Rell
Yo Hal!
On Sun, 26 Mar 2017 17:53:18 -0700
Hal Murray wrote:
> g...@rellim.com said:
> > I don't see how 32/64 bit has any effect on the size of a list. At
> > least if the list is tightly specified. uint32 as opposed to
> > uint. Maybe if you pack the structure, or encode things tighter
> >
Look for the 'bignum' package:
https://www.python.org/dev/peps/pep-0237/
On Sun, Mar 26, 2017 at 9:04 PM, Hal Murray wrote:
>
> g...@rellim.com said:
>>> Isn't that as simple as convert a 64 bit integer to float and divide
>>> by 1<<32 to get the right scale?
>> Nope. Loss of precision. A do
...and isn't the root of the discussion questioning the use of char,
short, int and long in structures vs the more correct uint8_t,
uint16_t, uint32_t and uint64_t?
Write the code in the most correct ANSI standard as is possible for
portability, maintainability and to let the compiler do what it c
g...@rellim.com said:
>> Isn't that as simple as convert a 64 bit integer to float and divide
>> by 1<<32 to get the right scale?
> Nope. Loss of precision. A double only has 52 bits of significant digits.
> A float only 23. To fully encode a 64 bit int you need a long double with
> (usually) 8
On Sun, 26 Mar 2017, Hal Murray wrote:
> a...@comcast.net said:
> > Did you check out Linux' "X32 ABI" support?
> > https://sites.google.com/site/x32abi/
>
> Thanks. That seems to be what I was looking for.
>
> It's not in the Fedora kernels but is in Debian. I'll poke around more.
>
>
> I guess
f...@fwright.net said:
> BTW, the Linux kernel has generally been moving towards using 64-bit
> nanoseconds internally, though there's still a lot of timespec cruft.
Interesting. Thanks.
Is there a type for that? Is in exposed to the outside world by an API? Any
use within glibc?
My proble
g...@rellim.com said:
> I don't see how 32/64 bit has any effect on the size of a list. At least if
> the list is tightly specified. uint32 as opposed to uint. Maybe if you
> pack the structure, or encode things tighter you might make some headway.
It's the pointers in each list member. If n
a...@comcast.net said:
> Did you check out Linux' "X32 ABI" support?
> https://sites.google.com/site/x32abi/
Thanks. That seems to be what I was looking for.
It's not in the Fedora kernels but is in Debian. I'll poke around more.
I guess I'm slightly surprised that there isn't more interest
strom...@nexgo.de said:
> Given that the Tinkerboard currently does not seem to allow PPS out of the
> box I'll pass on that.
Is that "out" a typo? Where is the PPS coming from that it wants to get out?
--
These are my opinions. I hate spam.
__
On Sat, 25 Mar 2017, Hal Murray wrote:
> e...@thyrsus.com said:
> > I disagree with Fred, because 292 years is way too short an era.
>
> Will our code be around in 292 years?
>
> How long would it take to make you happy?
>
> I assume the answer depends on the context. For something like POSIX, I'
Trevor N. :
> The Trimble Thunderbolt's week rollover will happen on July 29th of this
> year, so it will
> need the rollover handling code if you plan on keeping the driver around. The
> Palisade and
> Acutime 2000 will also rollover soon. Since I have a collection of Acutime
> and Palisade
>
Yo Trevor!
On Sun, 26 Mar 2017 17:28:10 -0400
"Trevor N." wrote:
> The Palisade and Acutime 2000 will also
> rollover soon. Since I have a collection of Acutime and Palisade
> receivers which I use with the driver's "event input" method, I will
> be adding the rollover code to the driver. Shou
Yo Hal!
On Sat, 25 Mar 2017 22:45:18 -0700
Hal Murray wrote:
> > So, when was the last time you were short of memory?
>
> I have a pool server in the cloud. For $5/month I get 1/2 gig. With
> half of that allocated for the MRU list, it doesn't last a day.
> Close, but not quite.
I don't se
Yo Achim!
On Sun, 26 Mar 2017 12:50:53 +0200
Achim Gratz wrote:
> While playing around with the two new NTP boxen, I noticed a differnce
> to classic: the precision value reported by NTP classic for both is
> -22, while NTPsec reports -20 (run 'ntps -c rv'). At least for the
> rasPi the NTPsec
hmurray at megapathdsl.net wrote:
>Sun Mar 26 04:19:50 UTC 2017
>
>Previous message (by thread): How long is long enough?
>Next message (by thread): Is it easy/possible to run code with 32 bit
> pointers on a modern 64 bit OS?
>Messages sorted by: [ date ] [ thread ] [ subject ] [ auth
>hmurray at megapathdsl.net wrote:
>I think another chunk is trying to dance around 1024 week roll over. That
>comes from PGRMF sentences which I think are Garmin propriety. But there is
>a normal DDMMYY in there, so I don't see why we need the GPS stuff. ??
>
>Does gpsd handle broken uni
Eric S. Raymond writes:
> Achim Gratz :
>> NTPsec is up and running on both, but without a refclock at the moment.
>
> I'd love to have a patch for the HOWTO describing the TinkerBoard tweaks.
Given that the Tinkerboard currently does not seem to allow PPS out of
the box I'll pass on that. I've d
Achim Gratz writes:
> NTPsec is up and running on both, but without a refclock at the moment.
I've configured two NavSpark mini to go into the two boxen. I can just
fit them in, so they won't be outside anymore like on the Pi 2B. The
cases I bought don't have any way to get some cables out, but
While playing around with the two new NTP boxen, I noticed a differnce
to classic: the precision value reported by NTP classic for both is -22,
while NTPsec reports -20 (run 'ntps -c rv'). At least for the rasPi the
NTPsec value looks to be correct (since the time base is a nominally
1MHz softwar
Hal Murray writes:
> If so, how do I do it?
If you're talking x86 GNU/Linux, then you'd need to use a distro that
has a 32bit subsystem and compile ntpd to use that.
> The idea is to save space in data structures if you know you won't need more
> than a total of a few GB of VM.
Wouldn't it be e
Hal Murray writes:
> I assume the answer depends on the context. For something like POSIX, I'd
> prefer something longer than 292 years but might accept that if it solved the
> problem and seemed better/cleaner than the alternatives.
>
> For usage internal to a project like this, I'd be happy wi
Is there a spec or general agreement on what a normalized negative timespec
looks like?
I didn't find anything interesting with a quick search.
I'm looking for something like "the sign of tv_nsec is the same as the sign
of tv_sec" (where 0 matches either sign)
--
These are my opinions. I
30 matches
Mail list logo
