Hi Alexei Alexandrov, you wrote:

>
> The program which confirms these numbers is attached.
>
Forgot the attachment.

--
Alexei Alexandrov

Dnia ¶roda 07 luty 2007, Alexei Alexandrov napisa³:
> Hi Mikolaj Machowski, you wrote:
> > Nice work. Could you send or place somewhere patches? I'd like to test
> > them on more complex regexps.
>
> Here it is. Note that the biggest speed-up is observed when regexp is
> matched a lot of times. The regexp mechanism itself is not affected at
> all here - so if you have one regexp which runs very long you won't
> probably notice any major difference.

When testing it with VST it gave 3.4% speed improvements (the same
metodology - 3 tests before and after, choose the best results).

m.

Hi All!

Here is a patch for make_mvc.mak file which is used to build Vim on Windows. The
changes are the following:

1. I had to add "!undef NODEBUG" in one place to make debug configuration
working as needed. Before this change the debug configuration did the same as
release.

2. /ZI (not /Zi) should be used in debug configuration. /ZI creates much more
useful PDB - with just /Zi you will not be able to look at the values of
variables which are currently in registers. Because of adding /ZI I had to
remove /incremental:no from linker flags (don't know exact implications of this
- probably it's good idea to still have it in release configuration).

3. I removed /nodefaultlib switch whenever possible. Having it is a bad idea by
itself - often indicates a dangerous CRT mix. I removed /nodefaultlib to support
Intel Compiler, in fact. Now I can use just command

nmake -f Make_mvc.mak ... CC=icl

to compile Vim with Intel Compiler. With /nodefaultlib it won't work, because
Intel Compiler adds to object files information about additonal static library
which executable need to link with. Of course, it can be solved by checking "if
it's Intel Compiler then link with this addditional library", but avoiding
/nodefaultlib is a good idea anyway.

--
Alexei Alexandrov

Hi Mikolaj Machowski, you wrote:

>
> When testing it with VST it gave 3.4% speed improvements (the same
> metodology - 3 tests before and after, choose the best results).
>

Well, it's not that much but it's still positive result. :-)

--
Alexei Alexandrov

On 2/8/07, Alexei Alexandrov <alexei.alexandrov@...> wrote:

> > When testing it with VST it gave 3.4% speed improvements (the same
> > metodology - 3 tests before and after, choose the best results).

> Well, it's not that much but it's still positive result. :-)

Considering how intense these computations are and how often they are
performed (probably the most time-consuming part of Vim), any
improvement will help a lot.

It's nice to see people alongside Bram working on improving Vim.  Your
work is highly appreciated (as well ;-).

   nikolai

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.

I would not assume it's similar until there is proof.

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

This sounds like a bug in getc().  It should know that only one thread
is reading the file and skip the locking.  I don't think we should fix
library bugs in Vim, unless it's crashing or another significant problem.

Perhaps you can already get a big increase by not compiling for
debugging?  With MSVC this usually has a big impact.  Also largely
defeats profiling with debugging enabled.

--
From "know your smileys":
  :-E Has major dental problems

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Alexei Alexandrov wrote:

> Here is a patch for make_mvc.mak file which is used to build Vim on
> Windows. The changes are the following:
>
> 1. I had to add "!undef NODEBUG" in one place to make debug
> configuration working as needed. Before this change the debug
> configuration did the same as release.
>
> 2. /ZI (not /Zi) should be used in debug configuration. /ZI creates
> much more useful PDB - with just /Zi you will not be able to look at
> the values of variables which are currently in registers. Because of
> adding /ZI I had to remove /incremental:no from linker flags (don't
> know exact implications of this - probably it's good idea to still
> have it in release configuration).
>
> 3. I removed /nodefaultlib switch whenever possible. Having it is a
> bad idea by itself - often indicates a dangerous CRT mix. I removed
> /nodefaultlib to support Intel Compiler, in fact. Now I can use just
> command
>
> nmake -f Make_mvc.mak ... CC=icl
>
> to compile Vim with Intel Compiler. With /nodefaultlib it won't work,
> because Intel Compiler adds to object files information about
> additonal static library which executable need to link with. Of
> course, it can be solved by checking "if it's Intel Compiler then link
> with this addditional library", but avoiding /nodefaultlib is a good
> idea anyway.

With Make_mvc.mak we have had many problems with fixes for one system
that break it for another system.  Thus I'm asking everybody to test
this first.

--
From "know your smileys":
  :.-( Crying

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

On 08/02/2007 19:27, Alexei Alexandrov wrote:
> Hi All!
>
> Here is a patch for make_mvc.mak file which is used to build Vim on
> Windows. The changes are the following:
>
> 1. I had to add "!undef NODEBUG" in one place to make debug
> configuration working as needed. Before this change the debug
> configuration did the same as release.
>
> 2. /ZI (not /Zi) should be used in debug configuration. /ZI creates
> much more useful PDB - with just /Zi you will not be able to look at
> the values of variables which are currently in registers. Because of
> adding /ZI I had to remove /incremental:no from linker flags (don't
> know exact implications of this - probably it's good idea to still
> have it in release configuration).

Removing incremental:no will result in a larger executable due to the
linker adding padding.  A quick check shows removing this option has no
effect so it looks like it had no effect in the first place.

It is moot whether distributing executables with debug information is
useful - for VC builds, without the .pdb file (and the source in the
right place) it is pretty useless.

> 3. I removed /nodefaultlib switch whenever possible. Having it is a
> bad idea by itself - often indicates a dangerous CRT mix. I removed
> /nodefaultlib to support Intel Compiler, in fact. Now I can use just
> command
>
> nmake -f Make_mvc.mak ... CC=icl
>
> to compile Vim with Intel Compiler. With /nodefaultlib it won't work,
> because Intel Compiler adds to object files information about
> additonal static library which executable need to link with. Of
> course, it can be solved by checking "if it's Intel Compiler then
> link with this addditional library", but avoiding /nodefaultlib is a
> good idea anyway.

There is a possible issue with VC8 if VIM is linked against any
libraries that require libc.lib - this is no longer part of VC8 builds
and will cause a problem.  However, VIM does not seem to currently link
against any such libraries (or at least the couple of builds I do) so it
seems ok to remove.

Mike
--
Don't worry about temptation - as you grow older, it starts avoiding you.

Hi Bram Moolenaar, you wrote:

>> It's Windows, but on Linux it should be similar.
>
> I would not assume it's similar until there is proof.
>
Of course. I'm going to investigate it there.

>
> This sounds like a bug in getc().  It should know that only one thread
> is reading the file and skip the locking.  I don't think we should fix
> library bugs in Vim, unless it's crashing or another significant problem.
>
It can't be a bug. I might be missing what you mean, but I can't see how it can
know that only one thread is reading a file. It doesn't have a clue whether you
gave this FILE * to other threads or not. It tries to be lightweight - as I
described in a separate mail it uses InterlockedIncrement/Decrement but they are
not that lightweight - they don't require switching to kernel mode but still
take about 200 cycles of CPU each.

The only optimization that I see could be avoiding blocking (and even trying to
block) in case if there is only one thread in current process and if there is
guarantee that this particular call is guaranteed not to create any threads. But
1) it still may be expensive and 2) Vim has some background threads anyway,
probably.

> Perhaps you can already get a big increase by not compiling for
> debugging?  With MSVC this usually has a big impact.  Also largely
> defeats profiling with debugging enabled.
>
I do _all_ performance measurements using optimized version of binary with
symbols. This is just a must for performance tuning.

--
Alexei Alexandrov

Alexei Alexandrov wrote:

> > This sounds like a bug in getc().  It should know that only one thread
> > is reading the file and skip the locking.  I don't think we should fix
> > library bugs in Vim, unless it's crashing or another significant problem.
> >
> It can't be a bug. I might be missing what you mean, but I can't see
> how it can know that only one thread is reading a file. It doesn't
> have a clue whether you gave this FILE * to other threads or not. It
> tries to be lightweight - as I described in a separate mail it uses
> InterlockedIncrement/Decrement but they are not that lightweight -
> they don't require switching to kernel mode but still take about 200
> cycles of CPU each.
>
> The only optimization that I see could be avoiding blocking (and even
> trying to block) in case if there is only one thread in current
> process and if there is guarantee that this particular call is
> guaranteed not to create any threads. But 1) it still may be expensive
> and 2) Vim has some background threads anyway, probably.

Hmm, getc() is apparently preparing for the worst and isn't optimized
for the 98% of the situations where there is only one thread reading
from the fd.  With the result that the, very often used, getc() is slow.

Besides using getc_unlocked() we could use read() and do our own
buffering.  That can't bee very complicated.  And we don't need to
figure out if the getc_unlocked() function is available.


--
hundred-and-one symptoms of being an internet addict:
102. When filling out your driver's license application, you give
      your IP address.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Hi Bram Moolenaar, you wrote:

>
> It sounds like keeping only 1024 bytes would already work for most
> situations.  That would be an acceptable amount to keep allocated at
> all times.  So why don't we use this as the initial size, and when it
> grows larger we free it when finished.  The growth size can be doubled
> each time perhaps.
>

I chose 8192/16384 pair because it's the closest to original 10000 bytes. 10000
itself would also be fine but I like round numbers...

The patch with changes which, I think, close to what you describe above is
attached. Could you please take a look at it?

>
> Right, this may happen and stack size wil greatly depend on the line
> length.
>
...
>
> That's very useful, thanks for diving into this.
>

My pleasure.

--
Alexei Alexandrov

Upgraded from novell-SUSE Linux 9.3 to openSUSE 10.2
My Vim compiled under 9.3 refuses to load: "perl.so not found".
Recompiled (with make reconfig, same feature set).
The new executable runs (with -ruby but I'll try to see about that).
The display (with the same 'guifont') is *much* more good-looking (crisper). I
don't know why. Different antialias settings maybe.

Happy Vimming!
Tony.
--
Seleznick's Theory of Holistic Medicine:
	 Ice Cream cures all ills.

Alexei Alexandrov wrote:

> Hi Bram Moolenaar, you wrote:
>
> >
> > It sounds like keeping only 1024 bytes would already work for most
> > situations.  That would be an acceptable amount to keep allocated at
> > all times.  So why don't we use this as the initial size, and when it
> > grows larger we free it when finished.  The growth size can be doubled
> > each time perhaps.
>
> I chose 8192/16384 pair because it's the closest to original 10000
> bytes. 10000 itself would also be fine but I like round numbers...
>
> The patch with changes which, I think, close to what you describe
> above is attached. Could you please take a look at it?

It's starting to look better, less disadvantages and should still give a
fair speedup.

10000 bytes is OK for when it's going to be freed again soon.  If you
want to keep the memory allocated something less would be more
appropriate.  And thus you need to start low, but could increase it in
larger steps (since it's going to be freed on return anyway).

The growarray is used in lots of places.  Adding another field to it
will cause more memory to be used.  Isn't it easier to make another
version of ga_grow() that increases the growsize when allocating another
block?

Instead of doubling each time, which is going to be big chunks quickly,
another way would be to first allocate one block at the start size of
about 1000 bytes, then set the growsize to 10000.  So we grow at the
same speed as before.  Then no extra field or function is needed, it's
local change in the regexp code.

Something like:
     if (regstack.ga_data == NULL)
     {
	     ga_init2(®stack, 1, 1000);
	     ga_grow(®stack, 1);
     }
     regstack.ga_growsize = 10000;

I do wonder if the memory needs to be cleared when re-using the
allocated memory.  Can you check that?

--
A meeting is an event at which the minutes are kept and the hours are lost.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

[Moving this to vim-dev]

Taylor Venable wrote:
> On Wed, 07 Feb 2007 00:08:29 -0800
> "George V. Reilly" <george@...> 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  george@...
http://www.georgevreilly.com/blog
The biggest mistake is not learning from all your other mistakes.

Hello,

I use gvim 7.0 patched 1-164. When doing :tabedit in a single tab buffer,
tabs on the top appear and the window is resized so that text area is the
same. However, when the window cannot be grown vertically (which is the case
for (vertically) maximized window or fullscreen), vim still keeps total
buffer height, which makes the bottom part (command line) of the buffer
invisible - until the window size is changed, vim is notified of the change
and calculates buffer height properly, taking tabs into account. (It doesn't
happen for vim running in terminal).

I am unable to provide a patch for the moment; if it is a known issue, I am
very sorry for duplicating the report.

Regards, Vaclav

Vaclav wrote:

> I use gvim 7.0 patched 1-164. When doing :tabedit in a single tab buffer,
> tabs on the top appear and the window is resized so that text area is the
> same. However, when the window cannot be grown vertically (which is the case
> for (vertically) maximized window or fullscreen), vim still keeps total
> buffer height, which makes the bottom part (command line) of the buffer
> invisible - until the window size is changed, vim is notified of the change
> and calculates buffer height properly, taking tabs into account. (It doesn't
> happen for vim running in terminal).
>
> I am unable to provide a patch for the moment; if it is a known issue, I am
> very sorry for duplicating the report.

What system?  If Unix: what GUI?

--
hundred-and-one symptoms of being an internet addict:
104. When people ask about the Presidential Election you ask "Which country?"

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

George V. Reilly wrote:

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

The Subversion repository contains Vim 7.0 plus all the patches.  For
the runtime files I don't make patches, they would be huge.  There is an
exception for important things or changes related to source code
changes, these are included in patches.  This may cause a few conflicts,
these can be ignored.

The runtime files can be obtained from the ftp site.  However, the spell
files are in a different directory.  It's a separate place, beccause the
files are huge and you probably only want to get the few you need.  They
are not updated often anyway.

I think the best method is to obtain all the files from subversion and
then get the latest runtime files with rsync.  Get spell files manually
(this can be done automatically if you use a language for the first
time).

--
hundred-and-one symptoms of being an internet addict:
103. When you find yourself in the "Computer" section of Barnes & Noble
      enjoying yourself.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Dnia niedziela 11 luty 2007, A.J.Mechelynck napisa³:
> Upgraded from novell-SUSE Linux 9.3 to openSUSE 10.2
> My Vim compiled under 9.3 refuses to load: "perl.so not found".
> Recompiled (with make reconfig, same feature set).

Different versions of Perl I suppose.

> The new executable runs (with -ruby but I'll try to see about that).
> The display (with the same 'guifont') is *much* more good-looking
> (crisper). I don't know why. Different antialias settings maybe.

Newer GTK.

m.

Hi,

vim-mac stripped the attachment again. I hope it comes through on
this list.

Anfang der weitergeleiteten E-Mail:

> Von: Nicolas Weber <nicolasweber@...>
> Datum: 11. Februar 2007 21:13:53 MEZ
> An: vim mac <vim-mac@...>
> Betreff: mac gui tabline v5
>
> Hi everyone,
>
> Michael Wookey suggested that the size of the gui tabline drawer
> should be changable. I agree and added this to the patch. It's the
> only change (except that this patch is for the current svn
> version). With this patch you can drag the edge of the drawer to
> change its size.
>
> If you make the drawer to small, it'll disappear (like in all apps
> where you can resize the drawer). To bring it back, open a tab (or
> close a tab) or call :set showtabline=1 or :set showtabline=2. If
> you want it hidden, call :set showtabline=0, just as before.
>
> Apply in vim's root directory.
>
> If you like this patch and want it included in Vim, then speak up!
> Tell Bram (preferably via this list) that you like this patch and
> that it works for you. Likewise, if you don't like it, speak up as
> well :-P
>
> Bye,
> Nico
>
>

> If you make the drawer to small, it'll disappear (like in all apps
> where you can resize the drawer). To bring it back, open a tab (or
> close a tab) or call :set showtabline=1 or :set showtabline=2. If you
> want it hidden, call :set showtabline=0, just as before.

Also, if the drawer closes by making its width too small (as expected),
it will become visible again if you switch to a different tab via the
various tab switching commands such as :tabnext, :tabprevious and
others.

Thanks,

Michael

[Bram, sorry for sending to your personal address by accident for the first
time]
  > What system?  If Unix: what GUI?

Sorry for not mentioning that. I am running the gnome GUI on Linux. I
double-checked on a different machine to exclude the influence of the
breakindent patch that is also applied. It seems that it works differently
with Metacity WM than with the Xfce window manager (running the same program
locally is different from running it remotely); also, the machine with
Metacity is xinerama-doublehead, which may make some bugs in the WM code
show up. I will install a clean version here and try to determine if it is
really a vim bug.

Regards, Vaclav

* 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  george@...
http://www.georgevreilly.com/blog
The biggest mistake is not learning from all your other mistakes.

Dear Vim users,

I will be doing a presentation on Vim, here is the announcement again:


Open Source Developers @ Google Speaker Series: Bram Moolenaar

Tuesday, February 13, 19.00h (7 pm)

Title: Seven habits for effective text editing, 2.0.


Bram's presentation will give an overview of several ways to effectively
use Vim to edit programs, structured text and documentation.

Please join us for Bram's presentation if you're in the area. Doors will
open at 6:30 PM and Bram will begin speaking at 7:00 PM. Refreshments
will be served; please plan to sign in at Building 41 reception (aka
lobby) when you arrive.


More information:
http://google-code-updates.blogspot.com/2007/02/open-source-developers-google-sp\
eaker.html

For instructions how to get there click on "Mountain View headquarters".
Pay attention to the building number: 41, there are many Google
buildings :-).

To be clear: this presentation is open to everyone.

Hope to meet you there!

:wq

--
hundred-and-one symptoms of being an internet addict:
107. When using your phone you forget that you don't have to use your
      keyboard.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

George Reilly wrote:

> * 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.

Great, thanks.  I'll add this to the todo list and await comments.

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

Should be easy to fix...

--
hundred-and-one symptoms of being an internet addict:
108. While reading a magazine, you look for the Zoom icon for a better
      look at a photograph.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Bernhard Walle wrote:
> * A.J.Mechelynck <antoine.mechelynck@...> [2007-02-12 02:47]:
>> Bernhard Walle wrote:
>>> Hello,
>>>
>>> after I installed netrw 107 in my ~/.vim, I cannot browse a directory
>>> which
>>>
>>>        :e /path/to/dir
>>>
>>> any more. That's annoying because also bookmarks don't work in the
>>> directory browser and there are some other problems. Can somebody
>>> help? Thanks!
>> Works for me on openSUSE Linux 10.2 using:
>>
>> VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 11 2007 01:13:11)
>> Included patches: 1-192
>> Compiled by antoine.mechelynck@...
>> Huge version with GTK2-GNOME GUI.  Features included (+) or not (-):
>> [...]
>>
>> $VIMRUNTIME/plugin/netrwPlugin.vim dated Jul 18, 2006
>> $VIMRUNTIME/autoload/netrw.vim v107 dated Jan 03, 2007
>> $VIMRUNTIME/autoload/netrwFileHandlers.vim v9 dated May 30, 2006
>> $VIMRUNTIME/autoload/netrwSettings.vim v9a ASTRO-ONLY dated Jul 28, 2006
>
> but that's vim compiled by yourself and netrw.vim not installed in
> $HOME, right?
>
> Maybe someone could help to tell me what code registers at vim to run
> as directory handler?
>
>
>
>        Bernhard

It's Vim compiled by myself, from no other sources than Bram's official ones
(including 192 "official" patches).

I didn't need to install netrw under ~/.vim because updating my runtime files
from the official Vim site upgraded my netrw (under $VIMRUNTIME) to v107: see
the 2nd of the fout netrw-related pathfilenames above.

If you're on Linux and have the Vim sources installed, you can do the following:

1) Remove all netrw files from ~/.vim and $VIM/vimfiles
2) cd to the top "build" directory, e.g.
   cd ~/.build/vim/vim70
3)
   rsync -avzcP --delete --exclude="/dos/" ftp.nluug.nl::Vim/runtime/ ./runtime/
4)
   cd src
   make installruntime
5) Check that you have no other "netrw" files in the "production" directories
(those listed in 'runtimepath' and their subdirs) than the four listed above
(or newer versions of the same).

Best regards,
Tony.
--
A sense of humor keen enough to show a man his own absurdities will
keep him from the commission of all sins, or nearly all, save those
that are worth committing.
		 -- Samuel Butler

Vaclav wrote:

> [Bram, sorry for sending to your personal address by accident for the first
> time]
>  > What system?  If Unix: what GUI?
>
> Sorry for not mentioning that. I am running the gnome GUI on Linux. I
> double-checked on a different machine to exclude the influence of the
> breakindent patch that is also applied. It seems that it works differently
> with Metacity WM than with the Xfce window manager (running the same program
> locally is different from running it remotely); also, the machine with
> Metacity is xinerama-doublehead, which may make some bugs in the WM code
> show up. I will install a clean version here and try to determine if it is
> really a vim bug.

I assume you are using GTK then.  If you use GTK + Gnome then try
recompiling Vim without Gnome.  The Gnome libraries introduce some
problems.

The window manager may do things that Vim can't handle.  Whether that's
the fault of the window manager or Vim is hard to decide.

--
Nobody will ever need more than 640 kB RAM.
		 -- Bill Gates, 1983
Windows 98 requires 16 MB RAM.
		 -- Bill Gates, 1999
Logical conclusion: Nobody will ever need Windows 98.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Patch 7.0.193
Problem:    Using --remote or --remote-tab with an argument that matches
             'wildignore' causes a crash.
Solution:   Check the argument count before using ARGLIST[0].
Files:      src/ex_cmds.c


*** ../vim-7.0.192/src/ex_cmds.c Tue Sep  5 18:28:45 2006
--- src/ex_cmds.c Tue Feb 13 03:47:52 2007
***************
*** 6967,6972 ****
--- 6967,6980 ----
        */
       set_arglist(eap->arg);

+     /*
+      * Expanding wildcards may result in an empty argument list.  E.g. when
+      * editing "foo.pyc" and ".pyc" is in 'wildignore'.  Assume that we
+      * already did an error message for this.
+      */
+     if (ARGCOUNT == 0)
+  return;
+
   # ifdef FEAT_WINDOWS
       if (cmdmod.tab)
       {
*** ../vim-7.0.192/src/version.c Wed Feb  7 03:42:37 2007
--- src/version.c Tue Feb 13 03:47:08 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     193,
   /**/

--
hundred-and-one symptoms of being an internet addict:
113. You are asked about a bus schedule, you wonder if it is 16 or 32 bits.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Patch 7.0.194
Problem:    Once an ml_get error is given redrawing part of the screen may
             cause it again, resulting in an endless loop.
Solution:   Don't give the error message for a recursive call.
Files:      src/memline.c


*** ../vim-7.0.193/src/memline.c Wed Feb  7 03:42:37 2007
--- src/memline.c Tue Feb 13 03:56:00 2007
***************
*** 2054,2066 ****
       linenr_T lnum;
       int  will_change;  /* line will be changed */
   {
!     bhdr_T    *hp;
!     DATA_BL *dp;
!     char_u  *ptr;

       if (lnum > buf->b_ml.ml_line_count) /* invalid line number */
       {
!  EMSGN(_("E315: ml_get: invalid lnum: %ld"), lnum);
   errorret:
  	 STRCPY(IObuff, "???");
  	 return IObuff;
--- 2054,2074 ----
       linenr_T lnum;
       int  will_change;  /* line will be changed */
   {
!     bhdr_T *hp;
!     DATA_BL *dp;
!     char_u *ptr;
!     static int recursive = 0;

       if (lnum > buf->b_ml.ml_line_count) /* invalid line number */
       {
!  if (recursive == 0)
!  {
! 	    /* Avoid giving this message for a recursive call, may happen when
! 	     * the GUI redraws part of the text. */
! 	    ++recursive;
! 	    EMSGN(_("E315: ml_get: invalid lnum: %ld"), lnum);
! 	    --recursive;
!  }
   errorret:
  	 STRCPY(IObuff, "???");
  	 return IObuff;
***************
*** 2088,2094 ****
  	  */
  	 if ((hp = ml_find_line(buf, lnum, ML_FIND)) == NULL)
  	 {
! 	    EMSGN(_("E316: ml_get: cannot find line %ld"), lnum);
  	     goto errorret;
  	 }

--- 2096,2109 ----
  	  */
  	 if ((hp = ml_find_line(buf, lnum, ML_FIND)) == NULL)
  	 {
! 	    if (recursive == 0)
! 	    {
! 	 /* Avoid giving this message for a recursive call, may happen
! 		 * when the GUI redraws part of the text. */
! 	 ++recursive;
! 	 EMSGN(_("E316: ml_get: cannot find line %ld"), lnum);
! 	 --recursive;
! 	    }
  	     goto errorret;
  	 }

*** ../vim-7.0.193/src/version.c Tue Feb 13 03:49:01 2007
--- src/version.c Tue Feb 13 03:59:22 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     194,
   /**/

--
hundred-and-one symptoms of being an internet addict:
114. You are counting items, you go "0,1,2,3,4,5,6,7,8,9,A,B,C,D...".

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Patch 7.0.195
Problem:    When a buffer is modified and 'autowriteall' is set, ":quit"
             results in an endless loop when there is a conversion error while
             writing. (Nikolai Weibull)
Solution:   Make autowrite() return FAIL if the buffer is still changed after
             writing it.
Files:      src/ex_cmds2.c


*** ../vim-7.0.194/src/ex_cmds2.c Tue Jan 16 21:31:38 2007
--- src/ex_cmds2.c Tue Feb 13 06:11:28 2007
***************
*** 1242,1255 ****
       buf_T *buf;
       int  forceit;
   {
       if (!(p_aw || p_awa) || !p_write
   #ifdef FEAT_QUICKFIX
!  /* never autowrite a "nofile" or "nowrite" buffer */
!  || bt_dontwrite(buf)
   #endif
!  || (!forceit && buf->b_p_ro) || buf->b_ffname == NULL)
  	 return FAIL;
!     return buf_write_all(buf, forceit);
   }

   /*
--- 1242,1263 ----
       buf_T *buf;
       int  forceit;
   {
+     int  r;
+
       if (!(p_aw || p_awa) || !p_write
   #ifdef FEAT_QUICKFIX
! 	    /* never autowrite a "nofile" or "nowrite" buffer */
! 	    || bt_dontwrite(buf)
   #endif
! 	    || (!forceit && buf->b_p_ro) || buf->b_ffname == NULL)
  	 return FAIL;
!     r = buf_write_all(buf, forceit);
!
!     /* Writing may succeed but the buffer still changed, e.g., when there is a
!      * conversion error.  We do want to return FAIL then. */
!     if (buf_valid(buf) && bufIsChanged(buf))
!  r = FAIL;
!     return r;
   }

   /*
***************
*** 1472,1477 ****
--- 1480,1487 ----
  	 if (buf == NULL)    /* No buffers changed */
  	     return FALSE;

+  /* Try auto-writing the buffer.  If this fails but the buffer no
+ 	 * longer exists it's not changed, that's OK. */
  	 if (check_changed(buf, p_awa, TRUE, FALSE, TRUE) && buf_valid(buf))
  	     break;     /* didn't save - still changes */
       }
*** ../vim-7.0.194/src/version.c Tue Feb 13 04:03:05 2007
--- src/version.c Tue Feb 13 06:18:28 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     195,
   /**/

--
hundred-and-one symptoms of being an internet addict:
115. You are late picking up your kid from school and try to explain
      to the teacher you were stuck in Web traffic.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

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

This seems to fix the bug...

Index: src/message.c
===================================================================
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
       * If 'verbosefile' is set write message in that file.
       * Must come before the rest because of updating "msg_col".
       */
-    if (*p_vfile != NUL)
+    if (p_vfile && *p_vfile != NUL)
 	 verbose_write(s, maxlen);

      if (redir_fd != NULL
Index: src/misc2.c
===================================================================
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
 	 return NULL;
      }
  #endif
-    while ((b = *p) != NUL)
+    while (p && (b = *p) != NUL)
      {
 	 if (b == c)
 	     return p;