[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] mintlib wide character overhaul
On Fri, 22 Feb 2013, Eero Tamminen wrote:
https://github.com/ArmstrongJ/MiNTLib/commit/ee9bdae3036cde3501aadce931da29fda286cb56
Ok, so nl_langinfo supports just C-locale (English / UTF-8)
and locale specific number separators. Based on sources,
I'm not sure does it support POSIX dates ("date -I" format),
but support for that's a must, as it's the only sortable
date format.
Not really sure on this one.
*
https://github.com/ArmstrongJ/MiNTLib/commit/f2555bc73d9f03ed12bd18a3a9b7c99da73e8cd7
What's the inline math problem with old GCC? It doesn't support it at all?
Well, it does support inline math, but apparently GCC 4.x source contains
it's own 68k inline math routines, so the inline stuff was removed from
the mintlib build. Therefore, this check will ensure that if someone is
still using GCC 2.95, the build can progress without failing to find a
non-existant inline math inlude.
*
https://github.com/ArmstrongJ/MiNTLib/commit/cb6a350f7ac9f88f692dc1c5db604e21cc9f3ff0
Why -fwrapv is removed from time objects build options?
Based on its description in GCC manual, it can change results.
GCC 2.95 doesn't support this flag. It can be added back in, but it
breaks the build on my system.
*
https://github.com/ArmstrongJ/MiNTLib/commit/6d188b1f756a09382b80477a043f8e4b8749189c
Does usleep(1) sched_yield implementation allow other threads to be
scheduled? Or is that small loop done in-process in usleep() for
performance reasons?
That's really an issue for the kernel itself. In theory, when a process
sleeps, the kernel should recognize this and switch tasks. I'm guessing
that a GNU/Linux sched_yield() implementation might do something fancier,
but just going idle for a moment should allow the OS to switch tasks.
I saw this simple solution in a few implementations for other alternative
OSes.
*
https://github.com/ArmstrongJ/MiNTLib/commit/e772a4670f5c451a0469437a9775651789959461
Does MiNT support syscall restarts at all?
My guess is no. However, the constant was missing. It was actually set
to zero internally in another mintlib source file whose name escapes me at
the moment.
Do you just build Python, or also run all of its supplied tests succesfully?
(I've never built Python myself, but I know it has such things.)
I haven't done much testing. I think any test failures would be Python's
fault, not necessarily mintlib's. Tests on the new mintlib code would be
more appropriate.
I'm not MiNTlib maintainer, but in general your patches looked fine. :-)
I appreciate the comments!
-Jeff
Jeff Armstrong - jba@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org