[ANN] Vim for Windows build, contains all 3rd party dependencies

[Shiny Bling]

Hi,

I just released the first VIM installer which contains all(hopefully) 3rd party dependencies.

I have been using VIM on Windows for a while but I only recently started using 'more recent' plugins. I ran into issues because quite often, the plugins were written in some popular scripting language (ruby, python, ...) So I ventured to hunt down required libraries but to get it fully working turned out to be quite painful. It is not only about installing required dlls, but also about making sure they actually work.

I can only imagine that for a casual VIM user, this is close to impossible to get working.

So I decided to build VIM with all 3rd party dependencies myself in hope that it will be useful for others as well.

This really is a build with the dependencies built as well, not just them being bundled in. Which in turn means that they share compiler optimisation flags. It is possible to build it with, for instance, AVX instruction set (modern Intel CPUs).

The installer for Win7 and whole repository can be found at https://bitbucket.org/kybu/vim-for-windows-single-drop

The repository is structured in a way which allows for continuous updating of the 3rd party dependencies. I will go into more detail later on in the readme file.

Please let me know whether any of you find my effort useful.

Thanks,
kybu

[Fernando Basso]

I do because although my preferred OS is Linux, I am forced to use windows at my current job and your project will greatly help and simplify things for me. I really appreciate your effort. Thanks a lot.

[Shiny Bling]

Glad to hear that. I had been focusing on creating the installer before I announced it here, but now I am going to update 3rd party dependencies so there will be another installer in about a week or so.

[Kevin O'Gorman]

Me too.  I hate wordpad.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kevin O'Gorman

#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.

[Shiny Bling]

There is a newer installer at http://bitbucket.org/kybu/vim-for-windows-single-drop/downloads/vim-single-drop-7.4.560.exe

The important addition is vimproc (asynchronous execution library) which wasn't there in the previous installer. It requires a native extension being built so I included it.

Other than that:
- Vim was updated to 7.4.560
- Ruby was updated to 2.1.5
- Perl was updated to 5.20.1
- Python was updated to 3.4.2
- SQLite was updated to 3.8.7.4

Enjoy,
kybu

[Steve Hall]

On Wed, Dec 31, 2014 at 10:51 AM, Shiny Bling <kybu...@gmail.com> wrote:

>

> There is a newer installer at

> http://bitbucket.org/kybu/vim-for-windows-single-drop/downloads/vim-single-drop-7.4.560.exe

Do you have a :version of this anywhere? I've been maintaining a

Windows build for over eight years here: 

https://sourceforge.net/projects/cream/files/Vim/

But over the last few years, there have been build issues with a

number of the features. Recently, most of these have been fixed, but I

still lack the following:

  -directx -dnd -ebcdic -footer -hangul_input -mzscheme -ole

  -postscript -profile -sniff -sun_workshop -tag_any_white -tcl

  -termresponse -tgetent -xfontset -xim -xpm_w32 -xterm_save

I'm particularly curious if you've solved +mzscheme or +tcl.

-- 

Steve Hall  [ digitect dancingpaper com ]

Cream for Vim  http://cream.SourceForge.net

SteveHallArchitecture http://SteveHallArchitecture.com

[Дарио Ѓорѓевски]

Another possible alternative: https://tuxproject.de/projects/vim/
Windows users may also find this useful: http://sourceforge.net/projects/msys2/

31.12.2014, 16:52, "Shiny Bling" <kybu...@gmail.com>:

[Shiny Bling]

On Wednesday, 31 December 2014 17:41:50 UTC+1, Steve Hall wrote:
> On Wed, Dec 31, 2014 at 10:51 AM, Shiny Bling <kybu...@gmail.com> wrote:
> >
> > There is a newer installer at
> > http://bitbucket.org/kybu/vim-for-windows-single-drop/downloads/vim-single-drop-7.4.560.exe
>
>
> Do you have a :version of this anywhere? I've been maintaining a
> Windows build for over eight years here: 
> https://sourceforge.net/projects/cream/files/Vim/

Here it goes:

Huge version with GUI. Features included (+) or not (-):
+acl +digraphs +libcall +profile +textobjects
+arabic -directx +linebreak -python +title
+autocmd -dnd +lispindent +python3 +toolbar
+balloon_eval -ebcdic +listcmds +quickfix +user_commands
+browse +emacs_tags +localmap +reltime +vertsplit
++builtin_terms +eval +lua +rightleft +virtualedit
+byte_offset +ex_extra +menu +ruby +visual
+cindent +extra_search +mksession +scrollbind +visualextra
+clientserver +farsi +modify_fname +signs +viminfo
+clipboard +file_in_path +mouse +smartindent +vreplace
+cmdline_compl +find_in_path +mouseshape -sniff +wildignore
+cmdline_hist +float +multi_byte +startuptime +wildmenu
+cmdline_info +folding +multi_lang +statusline +windows
+comments -footer -mzscheme -sun_workshop +writebackup
+conceal +gettext/dyn +netbeans_intg +syntax -xfontset
+cryptv -hangul_input +ole +tag_binary -xim
+cscope +iconv/dyn +path_extra +tag_old_static -xterm_save
+cursorbind +insert_expand +perl -tag_any_white +xpm_w32
+cursorshape +jumplist +persistent_undo -tcl
+dialog_con_gui +keymap -postscript -tgetent
+diff +langmap +printer -termresponse

>
> But over the last few years, there have been build issues with a
> number of the features. Recently, most of these have been fixed, but I
> still lack the following:
>
>
>   -directx -dnd -ebcdic -footer -hangul_input -mzscheme -ole
>   -postscript -profile -sniff -sun_workshop -tag_any_white -tcl
>   -termresponse -tgetent -xfontset -xim -xpm_w32 -xterm_save

Thanks for pointing these out. I have got xpm_w32, others haven't been included in my build. I would say quite a few are irrelevant on Windows. For instance xfontsel, xim, sun_workshop. I will look at the rest and see what could be built.

>
> I'm particularly curious if you've solved +mzscheme or +tcl.

I can try, even though I can't imagine anyone lusting for TCL ;)

BTW thanks for your Cream build, I used it for a while.

[Shiny Bling]

On Wednesday, 31 December 2014 18:11:47 UTC+1, Дарио Ѓорѓевски wrote:
> Another possible alternative: https://tuxproject.de/projects/vim/

My main reason doing the build is that Vim Windows builds like the above don't include 3rd party dependencies(ruby, python, ...). You have to install them yourself. I needed ruby for some plugin and when I added it, the whole Vim process was crashing. There was also a case, when I downloaded some Vim build and it required Ruby version, which was not yet released at http://rubyinstaller.org/

This build includes these dependencies, so you don't need to copy any dlls from who knows where, etc ...

Also, I had to modify Vim and Ruby source code (not makefiles) to actually get them working properly.

When I started I thought it would be just a matter of compiling it all but it turned out to be quite long endeavour.

kybu

[Steve Hall]

On Wed, Dec 31, 2014 at 12:41 PM, Shiny Bling <kybu...@gmail.com> wrote:

> 

> My main reason doing the build is that Vim Windows builds like the

> above don't include 3rd party dependencies(ruby, python, ...). You

> have to install them yourself. I needed ruby for some plugin and when

> I added it, the whole Vim process was crashing. There was also a case,

> when I downloaded some Vim build and it required Ruby version, which

> was not yet released at http://rubyinstaller.org/

You can use the dynamic flags for several dependencies to avoid this.

My builds use them for these major ones:

  +gettext/dyn

  +iconv/dyn

  +lua/dyn

  +multi_byte_ime/dyn

  +perl/dyn

  +python/dyn

  +python3/dyn

  +ruby/dyn

> Also, I had to modify Vim and Ruby source code (not makefiles) to

> actually get them working properly.

The Cream builds are always vanilla, depending on an upstream fix on

build or feature bugs. Sometimes I'm motivated to track them down

myself, but usually they are simply omitted. :)

> When I started I thought it would be just a matter of compiling it

> all but it turned out to be quite long endeavour.

You've got that right! I maintain a DOS batch script for everything

from the download/update to the NSIS installer build. Over the years

it has grown to 1,300 lines!

[Shiny Bling]

On Wednesday, 31 December 2014 19:51:20 UTC+1, Steve Hall wrote:
> On Wed, Dec 31, 2014 at 12:41 PM, Shiny Bling <kybu...@gmail.com> wrote:
> > 
> > My main reason doing the build is that Vim Windows builds like the
> > above don't include 3rd party dependencies(ruby, python, ...). You
> > have to install them yourself. I needed ruby for some plugin and when
> > I added it, the whole Vim process was crashing. There was also a case,
> > when I downloaded some Vim build and it required Ruby version, which
> > was not yet released at http://rubyinstaller.org/
>
>
> You can use the dynamic flags for several dependencies to avoid this.
> My builds use them for these major ones:
>
>
>   +gettext/dyn
>   +iconv/dyn
>   +lua/dyn
>   +multi_byte_ime/dyn
>   +perl/dyn
>   +python/dyn
>   +python3/dyn
>   +ruby/dyn

In order for that to work reliably, the end user has to install exact dlls which were used during the build. Otherwise, Vim can crash if there are compiler ABI incompatibilities(mingw vs Microsoft compiler) or incompatible function signature changes in the dlls. Let alone the fact, that the end user has to install dlls of languages he might have no idea about only because they are required by plugins. I think that for a smooth experience, it should be all distributed together. That is how it works in Linux distributions.

>
> > When I started I thought it would be just a matter of compiling it
> > all but it turned out to be quite long endeavour.
>
>
> You've got that right! I maintain a DOS batch script for everything
> from the download/update to the NSIS installer build. Over the years
> it has grown to 1,300 lines!

I can feel your pain ;)

kybu

[Justin M. Keyes]

On Thu, Jan 1, 2015 at 12:37 PM, Shiny Bling <kybu...@gmail.com> wrote:
> On Wednesday, 31 December 2014 19:51:20 UTC+1, Steve Hall wrote:
>> On Wed, Dec 31, 2014 at 12:41 PM, Shiny Bling <kybu...@gmail.com> wrote:
>> >
>> > My main reason doing the build is that Vim Windows builds like the
>> > above don't include 3rd party dependencies(ruby, python, ...). You
>> > have to install them yourself. I needed ruby for some plugin and when
>> > I added it, the whole Vim process was crashing. There was also a case,
>> > when I downloaded some Vim build and it required Ruby version, which
>> > was not yet released at http://rubyinstaller.org/
>>
>>
>> You can use the dynamic flags for several dependencies to avoid this.
>> My builds use them for these major ones:
>>
>>
>> +gettext/dyn
>> +iconv/dyn
>> +lua/dyn
>> +multi_byte_ime/dyn
>> +perl/dyn
>> +python/dyn
>> +python3/dyn
>> +ruby/dyn
>
> In order for that to work reliably, the end user has to install exact dlls which were used during the build. Otherwise, Vim can crash if there are compiler ABI incompatibilities(mingw vs Microsoft compiler) or incompatible function signature changes in the dlls. Let alone the fact, that the end user has to install dlls of languages he might have no idea about only because they are required by plugins. I think that for a smooth experience, it should be all distributed together. That is how it works in Linux distributions.

Well, except that python/ruby/etc are managed by the package manager.
Windows 10 will ship with a package manager:

https://github.com/OneGet/oneget

So hopefully the situation will improve.


However, vim-single-drop is a great effort. I tried it and didn't find
any problems with it, except that it doesn't ship with luajit.
http://files.kaoriya.net/vim/ ships with luajit, and the performance
difference for lua-heavy plugins like unite.vim is significant.

What is your strategy for scenarios where users what to install
python/ruby packages with pip/gem? What happens when they update
vim-single-drop? What happens if they have ruby or python already
installed and on their $PATH, and expect some package to be available,
but it isn't because vim-single-drop uses a different site-packages,
etc.?



Justin M. Keyes

[Peter Vrabel]

On 01/01/2015 23:11, Justin M. Keyes wrote:
> On Thu, Jan 1, 2015 at 12:37 PM, Shiny Bling <kybu...@gmail.com> wrote:
>> On Wednesday, 31 December 2014 19:51:20 UTC+1, Steve Hall wrote:
>>> On Wed, Dec 31, 2014 at 12:41 PM, Shiny Bling <kybu...@gmail.com> wrote:
>>>> My main reason doing the build is that Vim Windows builds like the
>>>> above don't include 3rd party dependencies(ruby, python, ...). You
>>>> have to install them yourself. I needed ruby for some plugin and when
>>>> I added it, the whole Vim process was crashing. There was also a case,
>>>> when I downloaded some Vim build and it required Ruby version, which
>>>> was not yet released at http://rubyinstaller.org/
>>>
>>> You can use the dynamic flags for several dependencies to avoid this.
>>> My builds use them for these major ones:
>>>
>>>
>>> +gettext/dyn
>>> +iconv/dyn
>>> +lua/dyn
>>> +multi_byte_ime/dyn
>>> +perl/dyn
>>> +python/dyn
>>> +python3/dyn
>>> +ruby/dyn
>> In order for that to work reliably, the end user has to install exact dlls which were used during the build. Otherwise, Vim can crash if there are compiler ABI incompatibilities(mingw vs Microsoft compiler) or incompatible function signature changes in the dlls. Let alone the fact, that the end user has to install dlls of languages he might have no idea about only because they are required by plugins. I think that for a smooth experience, it should be all distributed together. That is how it works in Linux distributions.
> Well, except that python/ruby/etc are managed by the package manager.

True, managed by the package manager and the whole system is compiled
with same compiler version and system libraries. Unlike on Windows,
where you need at least redistributable runtimes for each Visual Studio
version installed programs were compile with. I don't think OneGet will
change that. More likely, there will be packages like vim-mingw and
vim-msvc depending on a compiler the package was compiled with.

> Windows 10 will ship with a package manager:
>
> https://github.com/OneGet/oneget
>
> So hopefully the situation will improve.
>
>
> However, vim-single-drop is a great effort. I tried it and didn't find
> any problems with it, except that it doesn't ship with luajit.
> http://files.kaoriya.net/vim/ ships with luajit, and the performance
> difference for lua-heavy plugins like unite.vim is significant.

Thanks for a heads-up, I didn't know about unite.vim nor luajit. I will
add them in.

> What is your strategy for scenarios where users what to install
> python/ruby packages with pip/gem?

I was already thinking about it and a solution could be to include the
3rd party
dependencies completely, with all executables, etc ...

> What happens when they update vim-single-drop?

Good question, I haven't thought of this one yet.

> What happens if they have ruby or python already
> installed and on their $PATH, and expect some package to be available,
> but it isn't because vim-single-drop uses a different site-packages,
> etc.?

Well, at that moment they realise this vim build does not use those ;)
Maybe in reality it won't be an issue as most plugins don't have heavy
dependencies.
And if it is so, users can use gem/pip included into the vim build, as
mentioned above, to install missing dependencies.

kybu

[Shiny Bling]

On Thursday, 1 January 2015 23:12:24 UTC+1, Justin M. Keyes wrote:
>
> However, vim-single-drop is a great effort. I tried it and didn't find
> any problems with it, except that it doesn't ship with luajit.
> http://files.kaoriya.net/vim/ ships with luajit, and the performance
> difference for lua-heavy plugins like unite.vim is significant.

I put together another installer and it can be downloaded at https://bitbucket.org/kybu/vim-for-windows-single-drop/downloads/vim-single-drop-7.4.560_2.exe

Changes:
1. Two new Vim features are turned on: directx and postscript.
2. DirectX renderer is turned on by default. See $VIM/vimrc
3. LuaJIT 2.0.3 is used instead of pure Lua, so that will help with lua-heavy plugins. I tried unite.vim and it works just fine.
4. libiconv 1.14 is included in case anyone needs character conversions other than utf-8.
5. Molokai colour scheme from https://github.com/tomasr/molokai is included and set by default.
6. Everything was compiled with SSE2 instruction set enabled.

Any other hint what could be included? Some plugin which is tricky to get working on Windows? Thanks.

kybu

[Дарио Ѓорѓевски]

The author claims that YouCompleteMe is tricky to get working under Windows: https://github.com/Valloric/YouCompleteMe

Are your compiles 32- or 64-bit?

02.01.2015, 16:42, "Shiny Bling" <kybu...@gmail.com>:

[Shiny Bling]

On Friday, 2 January 2015 18:28:19 UTC+1, Дарио Ѓорѓевски wrote:
> The author claims that YouCompleteMe is tricky to get working under Windows: https://github.com/Valloric/YouCompleteMe
>
> Are your compiles 32- or 64-bit?

32bit. Is there any real advantage having 64 build?

kybu

[Дарио Ѓорѓевски]

Other than the usual, no, there is none. I was just asking.

02.01.2015, 18:46, "Shiny Bling" <kybu...@gmail.com>:

[Shiny Bling]

On Friday, 2 January 2015 18:48:23 UTC+1, Дарио Ѓорѓевски wrote:
> Other than the usual, no, there is none. I was just asking.

Likewise. I am not an advanced Vim user so I could be not aware of certain pros and cons ;)

[Ben Fritz]

I started self-compiling 64-bit, mainly because there is a server at work I use for a couple web services I administer, which is running Windows Server 2008 R2 and does not include the WOW64 system (and thus cannot run 32-bit binaries).

But I doubt very many people need a fully-featured Vim with all dependency DLLs for that. I think I haven't updated that install since sometime late in Version 7.3.x.

The other advantage is when using :! to run some standard system utilities like chcp which are not on the 32-bit path by default. But there are workarounds for that.

That, and you can install 64-bit versions of the dependency DLLs. But you've gotten rid of that sort of concern.

List of other reasons here, mostly not all that compelling: http://vim.wikia.com/wiki/Where_to_download_Vim

[Shiny Bling]

Thanks, I leave the 64bit build for later then.

[Suresh Govindachar]

Not sure what is meant by "contains all 3rd party dependencies" -- are
perl/python support via static linking?

I believe the dynamic perl/python support embedded into Vim needs to be
the same as the dynamic perl/python library available in the system.
The user of perl/python might have installed 64 bit version in order to
support large data sizes.

No idea what will happen if version of perl/python provided via this
"complete" build is different from version of perl/python in the system.

--Suresh

[Bram Moolenaar]

Generally there isn't much advantage in a 64 bit build and it uses more
memory. What is more important is that all the interfaces work
correctly. There were problems with the "open with Vim" menu when using
32 bit Vim on a 64 bit windows, but I believe that's solved.

I don't have time to maintain a Windows build myself. So far the Cream
version was a good second choice for users who want a recent Vim.
Including the required .dll files makes installing a Vim with many
features a lot simpler. Perhaps I should add a link to this version on
the vim download page?

Feedback from users who tried this version is welcome.

--
Micro$oft: where do you want to go today?
Linux: where do you want to go tomorrow?
FreeBSD: are you guys coming, or what?

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Peter Vrabel]

On 04/01/2015 15:48, Bram Moolenaar wrote:
> Shiny Bling wrote:
>
>> On Friday, 2 January 2015 18:28:19 UTC+1, Дарио Ѓорѓевски wrote:
>>> The author claims that YouCompleteMe is tricky to get working under Windows: https://github.com/Valloric/YouCompleteMe
>>>
>>> Are your compiles 32- or 64-bit?
>> 32bit. Is there any real advantage having 64 build?
> Generally there isn't much advantage in a 64 bit build and it uses more
> memory. What is more important is that all the interfaces work
> correctly. There were problems with the "open with Vim" menu when using
> 32 bit Vim on a 64 bit windows, but I believe that's solved.
>
> I don't have time to maintain a Windows build myself. So far the Cream
> version was a good second choice for users who want a recent Vim.
> Including the required .dll files makes installing a Vim with many
> features a lot simpler. Perhaps I should add a link to this version on
> the vim download page?

Link on the download page would be awesome!

I haven't had much trouble with Vim build system. It has been all the
dependencies around. For example libffi,
which is needed by at least ruby is compiled using cygwin and its gcc.
However, libffi provides a shell script,
which acts as a replacement for gcc. It translates gcc options for
Visual Studio compiler. Quite dodgy.

I managed to fully automate the compilation of it all. It wouldn't be
hard to automate it even further and create
the Vim installer with every new Vim patch to provide the most recent
Vim for Windows.

Also, the repository uses concept of the 'vendor branch', so updates to
more recent versions of Vim or any other
dependency is very easy (unless there are massive changes). So it is
easy to maintain.

kybu

[George V. Reilly]

On Sun, Jan 4, 2015 at 6:48 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:

Shiny Bling wrote:

> On Friday, 2 January 2015 18:28:19 UTC+1, Дарио Ѓорѓевски  wrote:
> > The author claims that YouCompleteMe is tricky to get working under Windows: https://github.com/Valloric/YouCompleteMe
> >
> > Are your compiles 32- or 64-bit?
>
> 32bit. Is there any real advantage having 64 build?

Generally there isn't much advantage in a 64 bit build and it uses more
memory.  What is more important is that all the interfaces work
correctly.  There were problems with the "open with Vim" menu when using
32 bit Vim on a 64 bit windows, but I believe that's solved.

I don't have time to maintain a Windows build myself.  So far the Cream
version was a good second choice for users who want a recent Vim.
Including the required .dll files makes installing a Vim with many
features a lot simpler.  Perhaps I should add a link to this version on
the vim download page?

e Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

​I used to maintain https://code.google.com/p/vim-win3264/, but I've stopped updating it as (a) it's been several years since I switched over to Macs and (b) there are very few cases where you *need* a 64-bit Vim. Best to concentrate on getting a really good, comprehensive 32-bit build.

-- 

/George V. Reilly  geo...@reilly.org  Twitter: @georgevreilly

http://georgevreilly.github.io/

[Ben Fritz]

On Sunday, January 4, 2015 2:33:09 PM UTC-6, George V. Reilly wrote:
>
> ​I used to maintain https://code.google.com/p/vim-win3264/, but I've stopped updating it as (a) it's been several years since I switched over to Macs and (b) there are very few cases where you *need* a 64-bit Vim. Best to concentrate on getting a really good, comprehensive 32-bit build.
>

So, this project is abandoned? Should we remove it from http://vim.wikia.com/wiki/Where_to_download_Vim?

[Ben Fritz]

On Sunday, January 4, 2015 10:58:16 AM UTC-6, Shiny Bling wrote:
> On 04/01/2015 15:48, Bram Moolenaar wrote:
> >
> > I don't have time to maintain a Windows build myself. So far the Cream
> > version was a good second choice for users who want a recent Vim.
> > Including the required .dll files makes installing a Vim with many
> > features a lot simpler. Perhaps I should add a link to this version on
> > the vim download page?
> Link on the download page would be awesome!
>

If you're committed to keeping this build going, feel free to add it here as well: http://vim.wikia.com/wiki/Where_to_download_Vim

[Steve Hall]

On Mon, Jan 5, 2015 at 10:36 AM, Ben Fritz <fritzo...@gmail.com> wrote:

> 

> If you're committed to keeping this build going, feel free to add it

> here as well: http://vim.wikia.com/wiki/Where_to_download_Vim

The link already there needs to be corrected to include the Vim/ subdirectory:

http://sourceforge.net/projects/cream/files/Vim/

Nobody should get Cream in their Vim unless they want it.

[Alessandro Antonello]

Hi,

I'm having a little problem running this GVim Single Drop distribution. The process hangs before anything is shown in the screen. I try to find the issue and it is in the Python. There is a debugging output from the Python module as follows:

00000001 0.00000000 [2168] Fatal Python error:

00000002 0.00003686 [2168] Py_Initialize: can't initialize sys standard streams

00000003 0.00007543 [2168]

I tried to search for the miss behaving function in the 'lib' directory (grep'ing it) but I couldn't find it. I don't know Python much. I also tried to see if there is a file or folder called 'streams' on the 'lib' directory, but seems that it don't.

I'm using Windows 7, 64 bits.

Anyone got this problem already?

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---

You received this message because you are subscribed to the Google Groups "vim_use" group.

[Peter Vrabel]

On 06/01/2015 15:13, Alessandro Antonello wrote:

Hi,

I'm having a little problem running this GVim Single Drop distribution. The process hangs before anything is shown in the screen. I try to find the issue and it is in the Python. There is a debugging output from the Python module as follows:

00000001 0.00000000 [2168] Fatal Python error:

00000002 0.00003686 [2168] Py_Initialize: can't initialize sys standard streams

00000003 0.00007543 [2168]

I tried to search for the miss behaving function in the 'lib' directory (grep'ing it) but I couldn't find it. I don't know Python much. I also tried to see if there is a file or folder called 'streams' on the 'lib' directory, but seems that it don't.

Hm, that means that it can't initialize standard input, output and error streams. Let me google that error. I test my builds on a clean Win 7 x64 installation to avoid obvious build failures, but there still might be some issues lurking.

You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/l8TY2EiXNwk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+u...@googlegroups.com.

[Peter Vrabel]

On 06/01/2015 15:13, Alessandro Antonello wrote:

Hi,

I'm having a little problem running this GVim Single Drop distribution. The process hangs before anything is shown in the screen. I try to find the issue and it is in the Python. There is a debugging output from the Python module as follows:

00000001 0.00000000 [2168] Fatal Python error:

00000002 0.00003686 [2168] Py_Initialize: can't initialize sys standard streams

00000003 0.00007543 [2168]

I tried to search for the miss behaving function in the 'lib' directory (grep'ing it) but I couldn't find it. I don't know Python much. I also tried to see if there is a file or folder called 'streams' on the 'lib' directory, but seems that it don't.

I'm using Windows 7, 64 bits.

Anyone got this problem already?

Would you mind creating an issue on bitbucket? https://bitbucket.org/kybu/vim-for-windows-single-drop/issues?status=new&status=open

It might be useful for others in case they are not subscribed to this mailing list.

I had a feeling I saw this problem earlier. I actually fixed it in this commit: https://bitbucket.org/kybu/vim-for-windows-single-drop/commits/0ff977e5eee17b6d3ff0f72cccce499edc25026a so it might be a different issue.

You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/l8TY2EiXNwk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+u...@googlegroups.com.

[Alessandro Antonello]

Ok. I created an issue on bitbucket.

I also forked the repository. I will try to investigate this issue deeper.

[Salman Halim]

On Sat, Dec 27, 2014 at 4:47 PM, Shiny Bling <kybu...@gmail.com> wrote:

Hi,

I just released the first VIM installer which contains all(hopefully) 3rd party dependencies.

I have been using VIM on Windows for a while but I only recently started using 'more recent' plugins. I ran into issues because quite often, the plugins were written in some popular scripting language (ruby, python, ...) So I ventured to hunt down required libraries but to get it fully working turned out to be quite painful. It is not only about installing required dlls, but also about making sure they actually work.

I can only imagine that for a casual VIM user, this is close to impossible to get working.

So I decided to build VIM with all 3rd party dependencies myself in hope that it will be useful for others as well.

This really is a build with the dependencies built as well, not just them being bundled in. Which in turn means that they share compiler optimisation flags. It is possible to build it with, for instance, AVX instruction set (modern Intel CPUs).

The installer for Win7 and whole repository can be found at https://bitbucket.org/kybu/vim-for-windows-single-drop

The repository is structured in a way which allows for continuous updating of the 3rd party dependencies. I will go into more detail later on in the readme file.

Please let me know whether any of you find my effort useful.

Thanks,
  kybu

Hello,

A while ago, I reported that I was unable to keep using regular yanks with 'clipboard' set to 'unnamed' because I wasn't seeing anything outside Vim (the problem started happening after Vim 7.4.3xx). Windows 7. I figured that it must be a quirk of my build process (MingW) so downloaded this installation. Same problem: yanking anything without explicitly prefixing it with "* doesn't put it on the system clipboard.

A few other people had seen this at the time, also, but I guess none of them were developers so it never got resolved. If someone has any idea where in the source code I might look for clipboard or yank operations, I'd be appreciative of the pointer as it's preventing me from upgrading to a newer Vim distribution.

Thank you.

--

 
Salman

I, too, shall something make and glory in the making.

[Shiny Bling]

New installer 7.4.580_1 is out

https://bitbucket.org/kybu/vim-for-windows-single-drop/downloads/vim-single-drop-7.4.580_1.exe

[Shiny Bling]

On Tuesday, 13 January 2015 04:53:30 UTC+1, Salman Halim wrote:
> Hello,
>
> A while ago, I reported that I was unable to keep using regular yanks with 'clipboard' set to 'unnamed' because I wasn't seeing anything outside Vim (the problem started happening after Vim 7.4.3xx). Windows 7. I figured that it must be a quirk of my build process (MingW) so downloaded this installation. Same problem: yanking anything without explicitly prefixing it with "* doesn't put it on the system clipboard.
>
> A few other people had seen this at the time, also, but I guess none of them were developers so it never got resolved. If someone has any idea where in the source code I might look for clipboard or yank operations, I'd be appreciative of the pointer as it's preventing me from upgrading to a newer Vim distribution.

I am afraid I can't help with this as I am not a Vim developer. I just maintain this Windows build. Maybe you could report a bug to the Vim bug tracker given that it is now clear, that is not related to mingw nor Visual Studio compiler.

kybu

[Shiny Bling]

On Wednesday, 31 December 2014 17:41:50 UTC+1, Steve Hall wrote:
> On Wed, Dec 31, 2014 at 10:51 AM, Shiny Bling <kybu...@gmail.com> wrote:
> >
> > There is a newer installer at
> > http://bitbucket.org/kybu/vim-for-windows-single-drop/downloads/vim-single-drop-7.4.560.exe
>
>
> Do you have a :version of this anywhere? I've been maintaining a
> Windows build for over eight years here: 
> https://sourceforge.net/projects/cream/files/Vim/
>
>
>
> But over the last few years, there have been build issues with a
> number of the features. Recently, most of these have been fixed, but I
> still lack the following:
>
>
>   -directx -dnd -ebcdic -footer -hangul_input -mzscheme -ole
>   -postscript -profile -sniff -sun_workshop -tag_any_white -tcl
>   -termresponse -tgetent -xfontset -xim -xpm_w32 -xterm_save
>
>
> I'm particularly curious if you've solved +mzscheme or +tcl.

I tried to compile just mzscheme (called Racket these days) and it seems to be buggy. When I run it, it spins in a loop and steadily increases its memory footprint.

kybu

[Shiny Bling]

FYI I just released 7.4.657 with Command-T plugin and ruby upgraded to 2.2.1.

It can be downloaded from
https://bitbucket.org/kybu/vim-for-windows-single-drop/downloads/vim-single-drop-7.4.657_1.exe

[Jon Schoning]

Thanks for doing these builds! Also really appreciate that now with DirectX enabled, the fonts look "much" better.

[pmu]

Hi Peter,

Thanks a lot. I've been using it for past 3-4 days. Amazing. Fonts really do
look better, it feels faster. Great work.

Regards,

Pritesh.



--
View this message in context: http://vim.1045645.n5.nabble.com/ANN-Vim-for-Windows-build-contains-all-3rd-party-dependencies-tp5723498p5724475.html
Sent from the Vim - General mailing list archive at Nabble.com.

[Peter Vrabel]

You are welcome! Bear in mind that the most gratitude should go to the
vim developers though ;)

I was myself surprised how much better fonts look with DirectX enabled.
I am using this font which looks amazing :
http://damieng.com/blog/2008/05/26/envy-code-r-preview-7-coding-font-released

kybu

[Christian Brabandt]

Hm, I have never used the new renderoption. So I just tried it
:set encoding=utf8
:set guifont=Envy_Code_R:h11:cANSI
:set rop=type:directx

And suddenly, no text is rendered at all. I can make this go away typing
blindly
:set rop=

(System Vim 7.4.662 from https://tuxproject.de/projects/vim/, Windows 7)
Am I missing something here? Is this a bug?

Best,
Christian

[Christian Brabandt]

I am suspecting, this is because I use some fonts, that I can't install
on my work station
(due to restricted access rights) and therefore I have to use
registerfonts (a small utility
that makes them available for the current session to load those fonts,
available here:
http://www.dailygyan.com/2008/05/how-to-install-fonts-in-windows-without.html
).
Because it works with the standard default fonts in Windows.

Best,
Christian

[Charles Cooper]

On Thursday, March 26, 2015 at 3:24:43 AM UTC-4, Christian Brabandt wrote:
> Hm, I have never used the new renderoption. So I just tried it
> :set encoding=utf8
> :set guifont=Envy_Code_R:h11:cANSI
> :set rop=type:directx
>
> And suddenly, no text is rendered at all. I can make this go away typing
> blindly
> :set rop=
>

> Am I missing something here? Is this a bug?

Have had good luck using the following setting copied from one of the posts around the time the option was introduced

set renderoptions=type:directx,gamma:1.0,contrast:0.2,level:1.0,geom:1,renmode:5,taamode:1

[Pritesh Ugrankar]

Hi,

Agreed. The Vim Developers are doing an awesome job. And so are folks like you who are doing tweaks to it to make it awesome.

By the way, I tried another setting given in the group:

set renderoptions=type:directx,gamma:1.0,contrast:0.2,level:1.0,geom:1,renmode:5,taamode:1

And the rendering is even better!!

Regards,

pritesh

[Bram Moolenaar]

I have been wondering: In this time of fast internet connections and big
harddisks: Should we make this all-in-one installation the default?
Does that make users happy or will the scream?
In other words: who would NOT want this?

--
BROTHER MAYNARD: Armaments Chapter Two Verses Nine to Twenty One.
ANOTHER MONK: And St. Attila raised his hand grenade up on high saying "O
Lord bless this thy hand grenade that with it thou mayest
blow thine enemies to tiny bits, in thy mercy. "and the Lord
did grin and people did feast upon the lambs and sloths and
carp and anchovies and orang-utans and breakfast cereals and
fruit bats and...
BROTHER MAYNARD: Skip a bit brother ...
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Steve Hall]

On Fri, Mar 27, 2015 at 8:43 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:

>

> I have been wondering: In this time of fast internet connections and big

> harddisks: Should we make this all-in-one installation the default?

> Does that make users happy or will the scream?

> In other words: who would NOT want this?

I see thousands of downloads of each Cream installer. It would be great if the DirectX would build on Cygwin! :)

[Christian Brabandt]

Hi Bram!

On Fr, 27 Mär 2015, Bram Moolenaar wrote:

>
> Pritesh Ugrankar wrote:
>
> > Agreed. The Vim Developers are doing an awesome job. And so are folks
> > like you who are doing tweaks to it to make it awesome.
> >
> > By the way, I tried another setting given in the group:
> >
> > set
> > renderoptions=type:directx,gamma:1.0,contrast:0.2,level:1.0,geom:1,renmode:5,taamode:1
> >
> > And the rendering is even better!!
>
> I have been wondering: In this time of fast internet connections and big
> harddisks: Should we make this all-in-one installation the default?
> Does that make users happy or will the scream?
> In other words: who would NOT want this?

I haven't tried this, but does it work without installing anything but
just unzip it somewhere and it will just work™? That is a requirement
for me, as I have some workstations, where I can't install anything.

Also can we then have a place to download from, that is not
bitbucket/github as those sites are forbidden for my workstations (Those
site have been classified as online storage and access is not allowed")

Best,
Christian
--
Nimmt man das Vaterland an den Schuhsohlen mit?
-- Georges Jacques Danton

[Bram Moolenaar]

I imagine we provide both a .zip file and an installer.
The .zip file you can unpack in a directory somewhere, then invole
gvim.exe there. The installer would follow the usual MS-Windows
procedure, so that you can easily uninstall it.

These days we should also have an upgrade check somehow...

--
LAUNCELOT: Isn't there a St. Aaaaarrrrrrggghhh's in Cornwall?
ARTHUR: No, that's Saint Ives.

[Pritesh Ugrankar]

Hi Bram,

Yes that would be a good idea. As mentioned before, the Windows users are really at a disadvantage at times as its not a platform that's as tweakable as Linux. So giving a single drop file with all the goodies plus a zip file would be a great idea. Upgrade Check would be awesome. If it would work out, we would have an official version of "all inclusive" Vim, which would really be great.

On another note, I was just diffing some server side outputs that consisted of about 200 storage devices being checked side by side (before and after reboot). After that I had to do some search and replace. A colleague of mine who used to call me "crazy" for using Vim is now fervently downloading and learning Vim :). The search and replace really badly stumped and hooked him.

Regards,

Pritesh Ugrankar.

[Dan Wierenga]

On Fri, Mar 27, 2015 at 5:43 AM, Bram Moolenaar <Br...@moolenaar.net> wrote:

I have been wondering: In this time of fast internet connections and big
harddisks: Should we make this all-in-one installation the default?
Does that make users happy or will the scream?
In other words: who would NOT want this?

That would be fantastic.  This "Single Drop Vim" is missing the console version (vim.exe) and its associated .bat files, so while it's a great gvim experience, it's still not the total solution.

-Dan

[Bram Moolenaar]

For the console version there already is a .zip file. Well, you need to
get two files:

9229662 vim74rt.zip V7.4 runtime files
1140124 vim74w32.zip V7.4 bin Windows NT/XP console

Obviously these are outdated. And including this in the "one size fits
all" archive is probably easier.


--
"When I die, I want a tombstone that says "GAME OVER" - Ton Richters