Re: reltime() low part incorrect in win32?
(Moving the non-developer list to BCC.) Eric Arnold wrote: I'm trying to understand what I'm seeing with the msec timing on win32 (cygwin). Inside the debugger, I'm seeing: (gdb) p tm_delta $1 = {u = {LowPart = 2434313347, HighPart = 896}, {LowPart = 2434313347, HighPart = 896}, QuadPart = 3850725010563} (gdb) n 180 n1 = tm_delta.HighPart; (gdb) 181 n2 = tm_delta.LowPart; (gdb) p n1 $4 = 895 (gdb) p n2 $2 = -1860653949 And in Vim: :echo reltime() [895, -162159878] So is this a bug? Internally, the low part of theproftime_T structure is positive, and it shows up externally as negative. I checked, and as far as I can tell, the LowPart is a win32 LARGE_INTEGER, which is 8 bytes, which is trying to be stuffed into a "long" which is 4 bytes. I think the right answer is a "double", but I'm not real sure about how win32 stuff works (since WhyTF has it defined a special LARGE_INTEGER type?). If you go look at the definition of LARGE_INTEGER in the Windows headers, you'll see that it's a union of a 64-bit integer (QuadPart) and two 32-bit integers (HighPart, LowPart). It has to be a LARGE_INTEGER because the profiler uses QueryPerformanceCounter() to get the most accurate results, and that's what QPF uses. LARGE_INTEGERs date from the early 90s, when many compilers didn't support intrinsic 64-bit operations. The value you actually want is QuadPart. However, this is calibrated in system-dependent ticks, which are generally, but not always, equal to the frequency of your CPU. To convert QuadPart to milliseconds, multiply QuadPart by 1000/Frequency, where Frequency is the result of a call to QueryPerformanceFrequency(). -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog
reltime() low part incorrect in win32?
I'm trying to understand what I'm seeing with the msec timing on win32 (cygwin). Inside the debugger, I'm seeing: (gdb) p tm_delta $1 = {u = {LowPart = 2434313347, HighPart = 896}, {LowPart = 2434313347, HighPart = 896}, QuadPart = 3850725010563} (gdb) n 180 n1 = tm_delta.HighPart; (gdb) 181 n2 = tm_delta.LowPart; (gdb) p n1 $4 = 895 (gdb) p n2 $2 = -1860653949 And in Vim: :echo reltime() [895, -162159878] So is this a bug? Internally, the low part of theproftime_T structure is positive, and it shows up externally as negative. I checked, and as far as I can tell, the LowPart is a win32 LARGE_INTEGER, which is 8 bytes, which is trying to be stuffed into a "long" which is 4 bytes. I think the right answer is a "double", but I'm not real sure about how win32 stuff works (since WhyTF has it defined a special LARGE_INTEGER type?). I don't know about unix, but it might have the same problem if tv_usec is a double. P.S. "profile_cmp()" is returning an "int" instead of a "double", so it's wonky also.
Re: Regression in gvim 7.0.00x
* On Thu, May 25, 2006 at 11:02:29PM -0400, Benji Fisher <[EMAIL PROTECTED]> wrote: > On Thu, May 25, 2006 at 03:17:54PM +0200, Luc Hermitte wrote: > > * On Thu, May 25, 2006 at 08:30:52AM -0400, Benji Fisher <[EMAIL > > PROTECTED]> wrote: > > > > > --- fixes and changes since Vim 7.0f --- > > > [...] > > > Prevent that using CTRL-R = in Insert mode can start Visual mode. > > > > Must I understand that the workaround I've found won't work in the > > future ? (the workaround consists in returning > > gv to i_CTRL-R=) > > AFAIK this will continue to work. The change is what you already > noticed (I think): if = calls a function, and that function > changes the mode, that will not be respected. It is OK if the > function returns characters that change the mode. > > You might also have a look at > > :help :map-expression > > I have not played with it yet, but I think the idea is to give a > simpler alternative to certain = constructions. I'd rather not use it for the moment. The plugin, with which I had the problem, does not use any Vim 7 new feature. In a year or so, I'll gradually drop the backward compatibility as new features are implemented, or bug fixed. Thanks for your help Benji. -- Luc Hermitte http://hermitte.free.fr/vim/