On Mon, Oct 25, 2010 at 9:43 AM, Ryan Lortie wrote:
> We're already planning to inject timestamps received from the X server
> for vblank (generated in the kernel IRQ handlers, I think?) directly
> into GPeriodic. I can easily imagine other situations where this might
> be useful.
I hope that s
hi Pavel,
On Mon, 2010-10-25 at 11:24 +0200, Pavel Holejsovsky wrote:
> Just out of curiosity; would you mind trying to specify reasons why you
> don't like it?
My general uneasiness with this idea developed along these lines:
- If we have some API for getting this int64 for the current time t
On 10/23/2010 4:46 PM, Ryan Lortie wrote:
I briefly considered having a per-process epoch whereby the first time
you request the monotonic time, that becomes "time zero". After rolling
it over in my head a few times, I like it less and less.
Just out of curiosity; would you mind trying to spec
hi,
Am 22.10.2010 18:06, schrieb Ryan Lortie:
> Hello
>
> We have an agreement at the hackfest that I will do the following things
> now:
>
> - Starting immediately, glib will depend on librt (and therefore
> libpthread) on systems that have it.
>
> - We will add GTimeSpec which is GTime
On Fri, 2010-10-22 at 15:02 -0400, Havoc Pennington wrote:
> Hi,
>
> On Fri, Oct 22, 2010 at 11:06 AM, Ryan Lortie wrote:
> > - We will add GTimeSpec which is GTimeVal using nanoseconds instead of
> >microseconds (same story with struct timeval vs. struct timespec).
> >The librt interfac
On 2010-10-22 17:06, Ryan Lortie wrote:
> - We will add GTimeSpec which is GTimeVal using nanoseconds instead
> of microseconds (same story with struct timeval vs. struct
> timespec). The librt interfaces provide this level of accuracy so
> it would be a shame
On Fri, Oct 22, 2010 at 11:06 AM, Ryan Lortie wrote:
> Hello
>
> We have an agreement at the hackfest that I will do the following things
> now:
[ ... good stuff ... ]
> We also plan the following for the future ("glib 4.0"):
[ ... more good stuff ... ]
> Comments?
about bloody time!
On Fri, Oct 22, 2010 at 3:02 PM, Havoc Pennington wrote:
> I know this is a completely minor side issue to the point of your
> email (which sounds good overall) but I often find myself writing a
> convenience wrapper around g_get_current_time() that returns a single
> integer. If you do get_time(T
Hi,
On Fri, Oct 22, 2010 at 11:06 AM, Ryan Lortie wrote:
> - We will add GTimeSpec which is GTimeVal using nanoseconds instead of
> microseconds (same story with struct timeval vs. struct timespec).
> The librt interfaces provide this level of accuracy so it would be a
> shame to needle
On Fri, 2010-10-22 at 13:28 -0400, Daniel Macks wrote:
> On Fri, 22 Oct 2010 17:20:45 0200, Ryan Lortie wrote:
> > - we aren't going to bump glib's version number when we release Gtk3
> X constant for Y=3
specifically, X=2 for Y=3
> > - we like glib to have the same version as Gtk in the lon
On Fri, 22 Oct 2010 17:20:45 0200, Ryan Lortie wrote:
On Fri, 2010-10-22 at 16:14 0100, Bastien Nocera wrote:
> > glib 3.0 maybe? We're still discussing changes for glib 2.x, aren't we?
>
> If you accept the following premises:
>
> - we can't break glib API without effectively also break
On Fri, 2010-10-22 at 16:14 +0100, Bastien Nocera wrote:
> glib 3.0 maybe? We're still discussing changes for glib 2.x, aren't we?
If you accept the following premises:
- we can't break glib API without effectively also breaking Gtk API
- we aren't going to bump glib's version number when we
On Fri, 2010-10-22 at 17:06 +0200, Ryan Lortie wrote:
>
> We also plan the following for the future ("glib 4.0"):
>
> - libgthread will stop existing, be folded into libglib and it will
> become impossible to replace the default threading implementation
> for your platform. Threads wil
Hello
We have an agreement at the hackfest that I will do the following things
now:
- Starting immediately, glib will depend on librt (and therefore
libpthread) on systems that have it.
- We will add GTimeSpec which is GTimeVal using nanoseconds instead of
microseconds (same story wi
14 matches
Mail list logo
