Re: Vim + MzScheme on Ubuntu

2007-02-11 Thread George V. Reilly

[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

2007-02-11 Thread George V. Reilly

* 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

2007-02-06 Thread George V. Reilly

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

2006-09-24 Thread George V. Reilly
[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

2006-09-23 Thread George V. Reilly

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

2006-07-05 Thread George V. Reilly

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

2006-06-17 Thread George V. Reilly

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?

2006-06-11 Thread George V. Reilly

(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

2006-06-05 Thread George V. Reilly
... 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