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
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 @@
@@ -15,7 +15,7 @@
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
-processorArchitecture="X86"
+processorArchitecture="*"
/>
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);
+ /* [retval][out] */ UINT_PTR __RPC_FAR *result);
END_INTERFACE
} IVimVtbl;
@@ -236,7 +236,7 @@
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=unix&page=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.
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: Compilation error with -D EXITFREE
[Previous copy was bounced by vim.org because it wasn't plaintext. Sorry for any duplicates.] George V. Reilly wrote: Bram Moolenaar wrote: Alexei Alexandrov wrote: Do I understand it correct that EXITFREE define in Vim source code can be used to make sure all resources are cleaned up on exit (and those which are not should be treated as leaks)? To be able to use it on Windows I had to do the following changes: Thanks for the patch. I never tried EXITFREE on Win32. What memory checker to you use with it? Aren't there Win32-specific things that need to be freed? Windows will release any outstanding memory or handles allocated by a program when the program exits, so this is redundant. It may be useful for detecting leaks, however. -- /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: Building +perl and +mzscheme on Ubuntu
A.J.Mechelynck wrote: George V. Reilly wrote: I'm trying to build a full-featured Vim 7.076 on Ubuntu 6.06. I have all the packages listed at http://packages.ubuntulinux.org/edgy/editors/vim-full as well as libncurses5-dev, libxt-dev, libgtk2.0-dev to build a basic Gvim, and mzscheme, ruby1.8-dev, tcl8.4-dev which suffices to build +ruby, +python, and +tcl, but not +perl or +mzscheme. [snip] What are the magic invocations? The following script, which I "source" in bash before compiling (using the bash "source" or "." command -- just running it isn't enough) includes most of the optional features -- IF the right software libraries are installed: I should have mentioned that I was using the bash script from your Compiling Howto for Unix at http://users.skynet.be/antoine.mechelynck/vim/compunix.htm You must also have the "development" packages for anything you want to include. I'm not sure how they are called on Ubuntu, but on SuSE it's e.g. perl-devel to be able to compile with perl. I can see you have the development packages for ruby and tcl. I suspect you haven't installed those for perl and mzscheme. Adding libperl-dev got me +perl. I still haven't figured out +mzscheme. Oh, and by the way, the latest bugfix is 7.0.083 at the moment. Yeah, but 7.0.076 is the latest stuff in Subversion. -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog The biggest mistake is not learning from all your other mistakes. Please sponsor me for the AIDS Walk: http://georgevreilly.com/aidswalk
Building +perl and +mzscheme on Ubuntu
I'm trying to build a full-featured Vim 7.076 on Ubuntu 6.06. I have all the packages listed at http://packages.ubuntulinux.org/edgy/editors/vim-full as well as libncurses5-dev, libxt-dev, libgtk2.0-dev to build a basic Gvim, and mzscheme, ruby1.8-dev, tcl8.4-dev which suffices to build +ruby, +python, and +tcl, but not +perl or +mzscheme. Here's the relevant output from 'make reconfig': checking --enable-mzschemeinterp argument... yes checking --with-plthome argument... "no" checking PLTHOME environment var... "not set" checking for mzscheme... /usr/bin/mzscheme checking MzScheme install prefix... checking --enable-perlinterp argument... yes checking for perl... /usr/bin/perl checking Perl version... OK checking if compile and link flags for Perl are sane... no: PERL DISABLED What are the magic invocations? -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog The biggest mistake is not learning from all your other mistakes. Please sponsor me for the AIDS Walk: http://georgevreilly.com/aidswalk
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 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
Re: Patch: gvimext.dll don't find MSVCR80.dll when built with VC8. No context menu entries.
Bram Moolenaar wrote: Mathias Michaelis wrote: Patch 7.0.Make_GvimExt Problem:On Windows, when GvimExt is built with Microsoft Visual Studio 2005, the context menu item "Edit with vim" doesn't appear in Explorer. Reason: GvimExt.dll cannot be loaded, because it is not prepared to the Windows Side by Side Components subsystem and so cannot find the C Runtime library in MSVCR80.dll. Solution: A manifest file is created by the linker. Embed it into the resources of GvimExt.dll. Files: src/GvimExt/Makefile I'm glad you managed to find a fix for this. I don't have this compiler. Can someone with MSVC 2005 verify this works properly? Is this the whole solution or does something else need to be changed? Send me the patch and I'll try it out. -- /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
ses... no checking for tgetent in -ltermlib... 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
Re: Guitab: font size
> Bram Moolenaar schrieb: >> Georg Dahn wrote: >> >>> Since I am working on a laptop with a 1400x1050 display, the fonts I am >>> using are rather large. That is, the menu font has a size of 11 pixel. >>> The problem is, that on inactive Guitabs, which use the size of the >>> menu >>> as its text size, the text gets cut a little bit. The largest font size >>> seems to be 10 pixel. >>> >>> I have not found an option to configure this. Is there a possibility >>> other than changing the code or the menu font? >> >> What system are you using? Georg Dahn wrote: > > I am using Windows XP. I want to add, that this is more an esthetical > Problem than a functional. It is still readable, but the lower parts > of letters like g, p, j and braces are cut. What system font size are you using? Right-click on a blank spot on your desktop, Properties, Appearance, Font size. Do you have similar problems with the tabbar on other Windows apps, such as the aforementioned Display Properties dialog? The Win32 tabbar is just using built-in common controls. -- /George V. Reilly [EMAIL PROTECTED] http://www.georgevreilly.com/blog BASIC By All Standards It's Changing (Get Witty Auto-Generated Signatures from http://SmartBee.org)
