Updated Win64 binaries for Vim 7.0.195
195 patches have been issued for Vim 7.0. I have updated the x64 (amd64) binaries for Win64. These allow you to run Vim natively on Win64. I have also fixed the installer and the Edit with Vim shell extension. The shell extension allows you to right-click on a file in Windows Explorer and be able to open it in Gvim. To install Vim, first visit http://www.georgevreilly.com/vim/ and download the latest zipfile. This 17MB file contains all the files you need for a full installation, including the latest Vim runtime. Unzip the zipfile into a directory whose name ends in |vim|, such as |C:\Program Files\Vim|, |D:\vim|, or |C:\mytools\vim|. This will create a |vim70| subdirectory, containing all the files. Start a |cmd.exe| window, |cd ...\vim\vim70|, then run |install|, the command-line installer. This will offer you a series of choices. You can probably just type |d| to do it. To uninstall Vim, use |uninstall.exe| in the same directory. I will not supply IA64 binaries unless specifically requested. -- Hello, I must be going. -- Groucho Marx (1890-1977) (Get Witty Auto-Generated Signatures from http://SmartBee.org) George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog
Re: Vim + MzScheme on Ubuntu
[Moving this to vim-dev] Taylor Venable wrote: On Wed, 07 Feb 2007 00:08:29 -0800 George V. Reilly [EMAIL PROTECTED] wrote: I tried to build Vim with MzScheme support on Ubuntu a few months ago and couldn't figure out what I needed to do to get MzScheme included in Vim. I got everything all the other supported languages working. Can you summarize what you did? This took a little playing around with, because the configure script thinks that you've got all your PLT stuff installed in the same place, which on Ubuntu isn't the case. The MzScheme packages on Ubuntu install some stuff into /usr/lib/plt and the include files into /usr/include/plt. Configure needs to know about both of these paths, but only allows you to specify one, using --with-plthome, which you should set to /usr/lib/plt. Then inside this directory create a symlink called include which points to /usr/include/plt. You shouldn't need any packages other than mzscheme (at least, I didn't need any that weren't already installed). It was kind of a tricky process in total, so I chronicled my adventures in compiling Vim for Xubuntu on my website. I used Aap to fetch the source, but the standard make procedure to install it. Here's the URL: http://www.metasyntax.net/?section=unixpage=vim#xubuntu Please let me know if you notice that I've missed anything important. Thanks, Taylor. The net change for me on Kubuntu was sudo ln -s /usr/include/plt/ /usr/lib/plt/include and adding export CONF_OPT_PLTHOME='--with-plthome=/usr/lib/plt' to my copy of Tony's myenviro shell script. Tony, Taylor's instructions should work on any *buntu variant. Bram, 'make install' fails because there are no *.vim files in runtime/spell. I'm using the latest stuff out of Subversion *except* for the runtime files, which are fetched with Tony's rsync invocation: rsync -avzcP --delete --exclude=/dos/ ftp.nluug.nl::Vim/runtime/ ./runtime/ I hacked around this by 'cp /dev/null runtime/spell/zzz.vim' Remind me again why the runtime files are so badly out of date in Subversion. Kdiff3 says that there are over 600 file-level differences between the svn runtime and the nluug runtime. -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog The biggest mistake is not learning from all your other mistakes.
Win64-related patches
* Win64 changes to make code compile cleanly: eval.c, misc2.c, if_ole.*
* Fixed install.exe bug
* Fixed annoying warning from Explorer about gvimext.dll
* Fixed gvim.exe.mnf to be cross-platform. No longer needs to be generated
from Make_mvc.mak
* Re-fixed spell.c so that it works with VC6. Unit tests go into an infinite
loop otherwise.
* Updated INSTALLpc.txt to reflect that Visual C++ 2005 Express Edition is
now free forever, recommending it over the VC 2003 Toolkit.
* Cleaned up Make_mvc.mak, incorporating (and fixing) recent patches from
Alexei Alexandrov and Mike Williams
* Added mkdist.bat to copy all of the installable files to vim70 directory,
where they are zipped up, for later installation on Win64 or Win32.
* Made a futile attempt to get gvim.nsi building. Just building.
Never mind running on Win64.
* Fixed a bug in test60: test60.ok must have Unix line endings
I have tested this code with the VS 98 (VC6), VS .NET 2003 (VC 7.1),
VS 2003 Toolkit (VC 7.1), Visual Studio 2005 (VC8), Visual Studio 2005
Express Edition (VC 8), and the VS 2005 x64 cross-compiler.
I'll re-test the Win64 binaries on a borrowed AMD64 machine at work
tomorrow.
As of yesterday, I was able to use install.exe to successfully install
gvim and register gvimext.dll, giving the Edit with Vim entry in
the Explorer context menu. Once everything is retested, I'll make fresh
Win64 binaries available.
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim -register',
and watch it crash while trying to display an error message.
--
/George V. Reilly [EMAIL PROTECTED]
http://www.georgevreilly.com/blog
The biggest mistake is not learning from all your other mistakes.
Index: src/dosinst.c
===
--- src/dosinst.c (revision 209)
+++ src/dosinst.c (working copy)
@@ -1365,7 +1365,7 @@
printf(Creating \Edit with Vim\ popup menu entry\n);
- fprintf(fd, HKEY_CLASSES_ROOT\\CLSID\\%s\n, vim_ext_clsid);
+ fprintf(fd, [HKEY_CLASSES_ROOT\\CLSID\\%s]\n, vim_ext_clsid);
fprintf(fd, @=\%s\\n, vim_ext_name);
fprintf(fd, [HKEY_CLASSES_ROOT\\CLSID\\%s\\InProcServer32]\n,
vim_ext_clsid);
Index: src/eval.c
===
--- src/eval.c (revision 209)
+++ src/eval.c (working copy)
@@ -991,13 +991,13 @@
char_u *value;
int value_len;
{
-size_t len;
+int len;
if (redir_lval == NULL)
return;
if (value_len == -1)
- len = STRLEN(value); /* Append the entire string */
+ len = (int)STRLEN(value); /* Append the entire string */
else
len = value_len; /* Append only value_len characters */
Index: src/gvim.exe.mnf
===
--- src/gvim.exe.mnf (revision 209)
+++ src/gvim.exe.mnf (working copy)
@@ -1,8 +1,8 @@
?xml version=1.0 encoding=UTF-8 standalone=yes?
assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0
assemblyIdentity
-processorArchitecture=X86
-version=6.2.0.0
+processorArchitecture=*
+version=7.0.0.0
type=win32
name=Vim
/
@@ -15,7 +15,7 @@
version=6.0.0.0
publicKeyToken=6595b64144ccf1df
language=*
-processorArchitecture=X86
+processorArchitecture=*
/
/dependentAssembly
/dependency
Index: src/GvimExt/Makefile
===
--- src/GvimExt/Makefile (revision 209)
+++ src/GvimExt/Makefile (working copy)
@@ -23,7 +23,7 @@
gvimext.obj: gvimext.h
.cpp.obj:
-$(cc) $(cflags) -DFEAT_GETTEXT $(cvarsdll) $*.cpp
+$(cc) $(cflags) -DFEAT_GETTEXT $(cvarsmt) $*.cpp
gvimext.res: gvimext.rc
$(rc) $(rcflags) $(rcvars) gvimext.rc
Index: src/if_ole.cpp
===
--- src/if_ole.cpp (revision 209)
+++ src/if_ole.cpp (working copy)
@@ -107,7 +107,7 @@
STDMETHOD(SendKeys)(BSTR keys);
STDMETHOD(Eval)(BSTR expr, BSTR *result);
STDMETHOD(SetForeground)(void);
-STDMETHOD(GetHwnd)(UINT *result);
+STDMETHOD(GetHwnd)(UINT_PTR *result);
private:
// Constructor is private - create using CVim::Create()
@@ -288,9 +288,9 @@
}
STDMETHODIMP
-CVim::GetHwnd(UINT *result)
+CVim::GetHwnd(UINT_PTR *result)
{
-*result = (UINT) s_hwnd;
+*result = (UINT_PTR) s_hwnd;
return S_OK;
}
Index: src/if_ole.h
===
--- src/if_ole.h (revision 209)
+++ src/if_ole.h (working copy)
@@ -79,7 +79,7 @@
virtual HRESULT STDMETHODCALLTYPE SetForeground( void) = 0;
virtual HRESULT STDMETHODCALLTYPE GetHwnd(
- /* [retval][out] */ UINT __RPC_FAR *result) = 0;
+ /* [retval][out] */ UINT_PTR __RPC_FAR *result) = 0;
};
@@ -143,7 +143,7 @@
HRESULT ( STDMETHODCALLTYPE __RPC_FAR *GetHwnd )(
IVim __RPC_FAR * This,
- /* [retval][out] */ UINT __RPC_FAR *result
Vim + MzScheme on Ubuntu
Taylor Venable wrote: Well, after a lot of playing around (tracking down dependencies in Ubuntu) I finally got everything I needed and built Vim + all patches (resulting in 7.0.192 as of tonight) from source. Still no luck, though; it has exactly the same problems. ... Thanks for the ideas though. It feels good to have a custom-built version of Vim, and now with MzScheme support, too! Still... it would be nice to know why this is not working. I tried to build Vim with MzScheme support on Ubuntu a few months ago and couldn't figure out what I needed to do to get MzScheme included in Vim. I got everything all the other supported languages working. Can you summarize what you did? -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog The biggest mistake is not learning from all your other mistakes.
Re: Vim + MzScheme on Ubuntu
A.J.Mechelynck wrote: George V. Reilly wrote: Taylor Venable wrote: Well, after a lot of playing around (tracking down dependencies in Ubuntu) I finally got everything I needed and built Vim + all patches (resulting in 7.0.192 as of tonight) from source. Still no luck, though; it has exactly the same problems. ... Thanks for the ideas though. It feels good to have a custom-built version of Vim, and now with MzScheme support, too! Still... it would be nice to know why this is not working. I tried to build Vim with MzScheme support on Ubuntu a few months ago and couldn't figure out what I needed to do to get MzScheme included in Vim. I got everything all the other supported languages working. Can you summarize what you did? I couldn't build it either but I'm on SuSE. Do you have both mzscheme and mzscheme-devel (or whatever name those packages are called) installed on your system? If (or once) you do, the configuration script shown on my howto page ought to pick it up automagically. Best regards, Tony. I've installed the mzscheme, drscheme, and slib packages, which is insufficient. There doesn't appear to be a working mzscheme-dev package for Ubuntu Edgy and mzscheme-devel is not a valid package. [EMAIL PROTECTED]:/opt/vim/vim7/src$ sudo apt-get install mzscheme-dev Reading package lists... Done Building dependency tree Reading state information... Done Package mzscheme-dev is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: mzscheme E: Package mzscheme-dev has no installation candidate I'm using your (Tony's) myenviro script, so --enable-mzschemeinterp is being passed to configure. For the record, I also need the libncurses5-dev, libxt-dev, and libgtk2.0-dev packages to get gvim compiling at all on Ubuntu. /George
Re: Vim 7 performance notes
Alexei Alexandrov wrote: I've also noticed that Vim spends somewhat significant time on startup loading spell files (I have 2 languages in my .vimrc: set spelllang=en,ru). The time is mostly spent in EnterCriticalSection/LeaveCriticalSection with getc() upper the stack. The reason for this is CRT blocking since the runtime is multithreaded. It's Windows, but on Linux it should be similar. As far as I understand, Vim doesn't access the spell file from multiple threads. Thus, the situation can be improved a lot: on Linux by using getc_unlocked. On Windows, starting VS 2005 there is a function _getc_nolock. Before VS 2005 this function can be emulated by macro: #define _getc_nolock(_stream) (--(_stream)-_cnt = 0 ? \ 0xff *(_stream)-_ptr++ : _filbuf(_stream)) By switching to non-blocking getc() in spell.c I was able to reduce Vim startup time from about 0.9 seconds to about 0.7 seconds. How did you measure the time in EnterCriticalSection and LeaveCriticalSection? If there's no lock contention, these routines are little more than InterlockedIncrement and InterlockedDecrement, without a kernel transition or blocking. If the lock is already held, then by definition, EnterCriticalSection has to block until the lock is available. Similarly, if LeaveCriticalSection detects that there are other callers waiting, it will signal one of the waiters. In other words, if you're seeing significant time in Enter/LeaveCS, I can think of two causes. Either your measurement tool has perturbed the results, or there really is some multithreaded lock contention. The former seems more likely, as Vim is single-threaded, but who knows what some DLLs in the Vim process might be doing. I would be vary wary of using the _getc_nolock macro until we understand why you are seeing those results. -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog The biggest mistake is not learning from all your other mistakes.
Re: Vim 7 performance notes
Yakov Lerner wrote: On 2/4/07, Yakov Lerner [EMAIL PROTECTED] wrote: On 2/4/07, Alexei Alexandrov [EMAIL PROTECTED] wrote: Gnu malloc (glibc) is exceptionally fast, iirc. It is possible to benchmark the malloc speed during the ./configure time. And auto-select the initital size depending on the results. The procmail this similar technique in configure: It automatically benchmarks it's own builtin strstr() vs system's strstr() and selects the one which is faster. In this particular case the speed of malloc is not the only factor. Big fraction of time is spent in memset() while initializing the array with zeros. That's why I thought that it's reasonable to benchmark malloc() relative to the time it takes to memset() that same area. (When benchmarking, you need to know what to compare it to). If you compare time it takes to malloc N bytes to the time it takes to memset() same N bytes, you can tell the speed of malloc *relative* to the time of memset()ting same size. So you will automatically know which one is realtively more expensive, the memset() or the malloc(). And then maybe the optimal initial size will be size where memset() time is equal to the malloc() time ? The break-even, so to say, in which neither of two time dominates the other ? memset() is an O(N) operation. Its running time has to be proportional to N because it has to touch every single byte. If the pagefile gets involved, it's still O(N), but with a much larger constant. malloc()'s running time is much harder to say anything about. Not only can it vary widely between different implementations, it also depends upon the state of the system. Is the heap fragmented? Is it suffering from lock contention? (Not a problem with single-threaded apps like Vim.) Is the memory already in the process's working set, or does malloc have to ask the OS for more pages? Is the system under intense memory pressure and will the malloc() operation cause paging to disk? Finally, malloc(N) is probably independent of N. It has to find a free entry of size N in its data structures, which is very dependent on both the implementation and the preceding factors. Benchmarking malloc() in ./configure is not likely to tell you very much about its performance in a workload you care about. -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog The biggest mistake is not learning from all your other mistakes.
Re: Convert2HTML Again
[Resending because Thunderbird sent the original email in HTML, which vim.org promptly bounced. Grrr.] Steve Hall wrote: On Sun, 2006-09-24 at 16:41 +0200, A.J.Mechelynck wrote: Steve Hall wrote: On Sun, 2006-09-24 at 00:31 +0200, Michael Schaap wrote: I beg you, please don't hardcode Courier New! [snip] It's not just the proper way, it's the first thing discussed in the specification: http://www.w3.org/TR/REC-CSS2/fonts.html#font-specification It is said nowhere in that document that a generic-family should be the only element in a font-face specification. [snip] In fact that W3C document mentions selecting a font by a single string only to dismiss it as inappropriate because of lack of standardization. My point was that the generic families were designed for an obvious reason...to fall back to something that works everywhere. Why wouldn't we want Vim to work just this way? Designers, not converters, should select font faces. If the converter is going to attempt to select one, than it had better do a good job of understanding what platform I am writing for, what fonts are available for that platform, and selecting one that follows my intentions within all the details of that specification. Whatever is chosen should be compatible with CSS, allowing the designer to specify a font for pre or #vim-pre (or whatever the class is). -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog The biggest mistake is not learning from all your other mistakes.
Re: Convert2HTML Again
Edward L. Fox wrote:
But we should change one thing before we include this patch into the
official version. In the patch file, line 97:
+execute normal! A\npre { font-family: courier; color: . s:fgc
. ; background-color: . s:bgc . ; }\e
Should be:
+execute normal! A\npre { font-family: Courier, monospace; color:
. s:fgc . ; background-color: . s:bgc . ; }\e
As W3C suggested, every font-family indication must finish with a
*GENERIC* font family name, possible values are serif, sans-serif
or monospace. So I added monospace here.
I'd like to request that the wretchedly ugly Courier font *NOT* be
hardcoded in to 2html.vim. I always end up removing it when I use 2html.
The font-family should either be just monospace or allow a global
variable to set the font.
(Under Windows, Courier is the bitmapped font with the hexagonal letter
forms and Courier New is the less ugly Truetype font with the spindly
strokes. For a picture of the two fonts, see
http://www.georgevreilly.com/courier.png
Under Kubuntu, Courier looks a lot more like Courier New.)
--
/George V. Reilly [EMAIL PROTECTED]
http://www.georgevreilly.com/blog
The biggest mistake is not learning from all your other mistakes.
Re: virus-laden emails from someone on the Vim list
To make this a little more concrete, here's some data from the last few such emails that I've received. First, typical headers: From - Thu Jul 6 18:56:35 2006 X-Account-Key: account2 X-UIDL: 1152233907.18606.mta6-4 X-Mozilla-Status: 0001 X-Mozilla-Status2: 1000 Return-Path: [EMAIL PROTECTED] Delivered-To: george:[EMAIL PROTECTED] X-OB-Received: from unknown (192.168.9.207) by 192.168.8.190; 7 Jul 2006 00:58:27 - Received: from 30013-2004-0009.com (unknown [203.229.175.114]) by spf6-3.us4.outblaze.com (Postfix) with SMTP id 1D21C10DADB for [EMAIL PROTECTED]; Fri, 7 Jul 2006 00:58:22 + (GMT) Date: Fri, 07 Jul 2006 09:58:30 +0900 To: George [EMAIL PROTECTED] From: Agiorgio [EMAIL PROTECTED] Subject: Avis Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/mixed; Next, the IP addresses and the purported senders: 221.163.190.71 - Tal [EMAIL PROTECTED] 203.229.175.114 - Agiorgio [EMAIL PROTECTED] 218.155.24.56 - Tal [EMAIL PROTECTED] 210.222.7.64 - Slouken [EMAIL PROTECTED] 211.192.1.102 - Eljay [EMAIL PROTECTED] 214.180.5.118 - Tal [EMAIL PROTECTED] The last IP address is in Estonia; the rest are in Korea. Can anyone take this further? -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog George V. Reilly wrote: [CCing the Vim and Vim-Dev lists. Not that it did any good the last time I raised this subject.] It is NOT me, dammit! Someone on the Vim list is infected with a virus that trawls through his address book and forges the From address. I too get dozens of virus-laden emails every week that purport to be from various people on the Vim list. Bram, Henk, Arpaffdy, and my own name are some of the names that I see regularly. This has been going on for at least two years :-( This laptop has been running a fresh install of Ubuntu 6.06 for the last four weeks, so if you've seen any mails from me in that interval, it definitely wasn't me. And I run antivirus and antispyware software when I'm running Windows, and I keep the signatures up to date. Vimmers, for the love of God, download antivirus and antispyware software, and run a scan on your machines. Windows users, start here: http://www.microsoft.com/athome/security/default.mspx /George @ Rocteur CC wrote: I can't believe it, is this really you. I receive at least 5 spams a week from your email address. I can't believe it, is this a legitimate mail from you ? I'll be damned, the worlds biggest spammer is from the VIM list.. I didn't realize.. Virus, worms, spam, you name it, I get it from your address, I always thought it was a phony email address and now I see it is a real one.. Can you not do something about this ? Anyway, I have hundreds of spam mail from you and it was a shock to see one that was not spam.. Jerry On 06 Jul 2006, at 21:10, George Reilly wrote: [snip]
virus-laden emails from someone on the Vim list
[CCing the Vim and Vim-Dev lists. Not that it did any good the last time I raised this subject.] It is NOT me, dammit! Someone on the Vim list is infected with a virus that trawls through his address book and forges the From address. I too get dozens of virus-laden emails every week that purport to be from various people on the Vim list. Bram, Henk, Arpaffdy, and my own name are some of the names that I see regularly. This has been going on for at least two years :-( This laptop has been running a fresh install of Ubuntu 6.06 for the last four weeks, so if you've seen any mails from me in that interval, it definitely wasn't me. And I run antivirus and antispyware software when I'm running Windows, and I keep the signatures up to date. Vimmers, for the love of God, download antivirus and antispyware software, and run a scan on your machines. Windows users, start here: http://www.microsoft.com/athome/security/default.mspx /George @ Rocteur CC wrote: I can't believe it, is this really you. I receive at least 5 spams a week from your email address. I can't believe it, is this a legitimate mail from you ? I'll be damned, the worlds biggest spammer is from the VIM list.. I didn't realize.. Virus, worms, spam, you name it, I get it from your address, I always thought it was a phony email address and now I see it is a real one.. Can you not do something about this ? Anyway, I have hundreds of spam mail from you and it was a shock to see one that was not spam.. Jerry On 06 Jul 2006, at 21:10, George Reilly wrote: Adding the Vim Users mailing list, because I can't answer these completely. - Original Message - From: Richard Dooling [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: gvim on windows xp Date: Thu, 6 Jul 2006 12:53:12 -0500 Dear George: I am a new convert to gvim. Trying to use it on Windows XP. I am primarily a novelist, but a recent convert to Python, also. I intend to use gvim mainly as a text editor. Two things: (1) Is there a way to have a soft border or offset on the left, so that the text is not flush against the left window border? I've searched for hours with no luck. Autoindent would put an actual space in there (which I wouldn't want). I don't know of anything that will do exactly what you want, but :set number might help. (2) Is there a plug-in file especially for text? Already configured for 79 spaces with linebreak etc already set. I'm sure there must be something useful out there at vim.org. I have In text files, always limit the width of text to 75 characters autocmd BufNewFile,BufRead *.txt,*.htm,*.html setlocal tw=75 in my _vimrc. Thank you so much for any help. Richard Dooling /rd http://dooling.com --/George V. Reilly mailto:[EMAIL PROTECTED] http://www.georgevreilly.com/blog/ -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog
Re: Vim 7.0 x64
Andre Godoi wrote: Dear George! Thank you very much for the 64-bits binaries of Vim. I have just installed Windows XP x64 and your version of Vim. The only thing I couldn't do is install the Edit with Vim... entry on the right-click pop-up. I did what you described, I've set a %VIM% variable to where my Vim was uncompressed and ran install.exe. The option 14 says it will install the right-click context menu, but it doesn't. Is there anything I could do to solve it? That right-click context menu was very useful. =) Thank you very much for your attention and for your help. Andre Godoi I'm sorry, but I don't have access to a Win64 system at the moment, so there's no easy way for me to check out what you're saying. I don't know if it's a problem with the installer or with gvimext.dll. You may be able to get what you want by creating a vim.reg file with contents like this: REGEDIT4 [HKEY_CLASSES_ROOT\*\Shell\Open with Vim\command] @=\c:\\Program Files\\Vim\\vim70\\gvim.exe\ \%1\ I think a similar issue came up on the Vim Developers list recently, so I'm CCing that. -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog
clipboard + unnamed register under X11
On Windows, I've long been used to having clipboard=unnamed, which ensures that all deletes, yanks, and puts go to or come from the clipboard by default. Is it possible to achieve this effect under X? I keep forgetting to prefix commands with +, which is awkward to type. I'd prefer not to remap a ton of commands. -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog
Re: svn, cvs
Suresh Govindachar wrote: The reason for fetching from cvs is to avoid having to patch. (and the reason for not using svn is that svn is out-of-date, and svn differes from Bram's cvs by CR/LF in some files). There were concerns about switching over to Subversion when we first started using it a few months ago, just before Vim 7.0 released. Are those concerns still valid? -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog
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
Re: Upgrading VIM on Ubuntu
... no checking for tgetent in -ltermcap... no checking for tgetent in -lcurses... no no terminal library found checking for tgetent()... configure: error: NOT FOUND! You need to install a terminal library; for example ncurses. Or specify the name of the library with --with-tlib. -- /George V. Reilly
