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
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: 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: 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: 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