RFC: bigger '--with-features' than huge (incl interpreters)

2006-09-08 Thread Yakov Lerner

Hello,

The biggest build size that exists now (the --with-features) is 'huge'.
This 'huge' still does not include interpreters.

What does public and Bram think about adding another build size
('extra-huge') that includes [all] interpreters ?
What is your feeback ?

Yakov

Possible namings: 'all', 'jumbo', 'giant', 'everything', 'huge+interp',
 'xxl', 'colossal', 'tremendous', 'gigantic',
'enormous',
 'ohmygod', 'extra-huge'

My reasoning behind 'xxl' is this: current build sizes are {tiny,
small, normal, big, huge}.
'Big' is like  'large'. Thus 'huge' (next grade after big/large)
corresponds to 'xl'
(extra large). Then next grade after huge/xl is xxl. Then it is easy to
add xxxl, l, etc.


Re: RFC: bigger '--with-features' than huge (incl interpreters)

2006-09-08 Thread A.J.Mechelynck

Yakov Lerner wrote:

Hello,

The biggest build size that exists now (the --with-features) is 'huge'.
This 'huge' still does not include interpreters.

What does public and Bram think about adding another build size
('extra-huge') that includes [all] interpreters ?
What is your feeback ?

Yakov

Possible namings: 'all', 'jumbo', 'giant', 'everything', 'huge+interp',
 'xxl', 'colossal', 'tremendous', 'gigantic',
'enormous',
 'ohmygod', 'extra-huge'

My reasoning behind 'xxl' is this: current build sizes are {tiny,
small, normal, big, huge}.
'Big' is like  'large'. Thus 'huge' (next grade after big/large)
corresponds to 'xl'
(extra large). Then next grade after huge/xl is xxl. Then it is easy to
add xxxl, l, etc.



I don't think interpreters belong in a linear scheme tiny - small - 
normal - large - huge - huge with interpreters.


After all, I suppose that one might want interpreters but not profiling, 
perl without python, ruby and TCL but not Scheme, etc. IMO 
inclusion/exclusion of interpreters should be independent of other 
features -- and therefore manual.


For Unix users who want the biggest Vim they can make with the installed 
software they have, there is a bash script on my Unix HowTo page 
http://users.skynet.be/antoine.mechelynck/vim/compunix.htm which will 
enable everything in configure. Then configure will turn off any 
features for which the required software is not found. To use that 
script, copy it to the parent of your src/ directory, change the 
compiled-by line and anything else you want to change, and use the 
source (or .) command in bash before running make (make will 
invoke configure if it hasn't yet been run; if you change the configure 
options or install/uninstall relevant software you should make 
reconfig in the src/ directory -- that will clear the configure cache, 
run configure, and then proceed to compile and link). Just giving the 
script's name at the prompt isn't enough because in that case, 
environment variables won't stick.


For Windows users, my Windows HowTo explains how to do it but it isn't 
as straightforward as on Unix because configure isn't used on Windows: 
see http://users.skynet.be/antoine.mechelynck/vim/compile.htm . In 
particular, Windows users who want to include interpreted languages must 
tell make by means of environment variables where the interpreters are 
found, what version they have, and that dynamic linking is desired. 
Also, on Windows a different makefile is used for each different 
compiler (MSVC, BCC32, Cygwin gcc, MinGW32 gcc, ...).



Best regards,
Tony.


Hello! Well Met! And a possible bug. :-)

2006-09-08 Thread Mark Manning
I believe I may have found an obscure bug.  It is not a harmful bug.  It 
does not make VIM crash or do weird things.  (Well, sort-of.)  :-)


Here is how to reproduce it:

First you have to have a lot of open and close braces (}).  They 
do not have to be on the same line and in fact, this bug shows up better 
if they are on separate lines.  For example:  This happened while I was 
writing some Perl code and I had a lot of IF statements with their 
trailing braces.  These were inside of a subroutine so the last line of 
the subroutine is, of course a brace.  There were lots of subroutines 
and I was cleaning up code by separating out the subroutines into 
separate files.  So my code originally looked like this:


main
   .
   .
   .
sub a
{
   if(){
  if(){
  }
   }
}

sub b
{
   more stuff
   if(){
  if(){
  }
   }
}

and so on...

Ok.  So the problem happens when you delete sub b and then hit the 
dd key to delete the blank line between sub a's ending close brace 
and where sub b's starting line was.  When you do this VIM pops up 
onto the end of the brace for sub a.  The thing is, is that the cursor 
isn't _on_ the close brace - it is next to the close brace.  So if you 
then do a % VIM pops to the middle of the file rather than to the open 
brace like it should do.  (ie: Match braces.)


Like I said - it's not a terrible problem, it doesn't crash VIM, it's 
just a what the heck!? kind of thing and it took me a while to realize 
that I was not doing something myself wrong and that it had more to do 
with how VIM treated the deletion of the other line and where it put the 
cursor afterwards.


However, this also brings up the next thing.  If, after deleting the 
blank line you type the $ key, the curse will pop to the correct 
location (ie:on the close brace).  Does this mean that the cursor is 
actually beyond the end of the line at that point?  Could this cause 
other problems with VIM?


Anyway, just a short note.  Other than this, VIM works fine.  Here is my 
system information:


Two separate versions of VIM are doing this.

Version #1 of VIM:
VIM v6.1
Windows XP Pro
512MB of memory
250GB hard drive (lots of space)
Editing standard text files.

Version #2 of VIM:
Vim v7.0.1
Cygwin via Windows XP Pro
Same system so same everything else.


Re: Hello! Well Met! And a possible bug. :-)

2006-09-08 Thread Yakov Lerner

On 9/8/06, Mark Manning [EMAIL PROTECTED] wrote:

I believe I may have found an obscure bug.  It is not a harmful bug.  It
does not make VIM crash or do weird things.  (Well, sort-of.)  :-)

Here is how to reproduce it:

First you have to have a lot of open and close braces (}).  They
do not have to be on the same line and in fact, this bug shows up better
if they are on separate lines.  For example:  This happened while I was
writing some Perl code and I had a lot of IF statements with their
trailing braces.  These were inside of a subroutine so the last line of
the subroutine is, of course a brace.  There were lots of subroutines
and I was cleaning up code by separating out the subroutines into
separate files.  So my code originally looked like this:

main
.
.
.
sub a
{
if(){
   if(){
   }
}
}

sub b
{
more stuff
if(){
   if(){
   }
}
}

and so on...

Ok.  So the problem happens when you delete sub b and then hit the
dd key to delete the blank line between sub a's ending close brace
and where sub b's starting line was.  When you do this VIM pops up
onto the end of the brace for sub a.  The thing is, is that the cursor
isn't _on_ the close brace - it is next to the close brace.  So if you
then do a % VIM pops to the middle of the file rather than to the open
brace like it should do.  (ie: Match braces.)

Like I said - it's not a terrible problem, it doesn't crash VIM, it's
just a what the heck!? kind of thing and it took me a while to realize
that I was not doing something myself wrong and that it had more to do
with how VIM treated the deletion of the other line and where it put the
cursor afterwards.

However, this also brings up the next thing.  If, after deleting the
blank line you type the $ key, the curse will pop to the correct
location (ie:on the close brace).  Does this mean that the cursor is
actually beyond the end of the line at that point?  Could this cause
other problems with VIM?

Anyway, just a short note.  Other than this, VIM works fine.  Here is my
system information:

Two separate versions of VIM are doing this.

Version #1 of VIM:
VIM v6.1
Windows XP Pro
512MB of memory
250GB hard drive (lots of space)
Editing standard text files.

Version #2 of VIM:
Vim v7.0.1
Cygwin via Windows XP Pro
Same system so same everything else.



I tried what you describe in vim7.0.91, and the cursor is
right on the closing brace after dd, not after.
Maybe you should upgdare to the latest vim7.

Yakov


Re: Hello! Well Met! And a possible bug. :-)

2006-09-08 Thread Charles E Campbell Jr

Mark Manning wrote:

First you have to have a lot of open and close braces (}). 
..snip..


Ok.  So the problem happens when you delete sub b and then hit the 
dd key to delete the blank line between sub a's ending close brace 
and where sub b's starting line was.  When you do this VIM pops up 
onto the end of the brace for sub a.  The thing is, is that the 
cursor isn't _on_ the close brace - it is next to the close brace.  So 
if you then do a % VIM pops to the middle of the file rather than to 
the open brace like it should do.  (ie: Match braces.)


Like I said - it's not a terrible problem, it doesn't crash VIM, it's 
just a what the heck!? kind of thing and it took me a while to 
realize that I was not doing something myself wrong and that it had 
more to do with how VIM treated the deletion of the other line and 
where it put the cursor afterwards.



..snip..

What does

 :echo ve

show?

Regards,
Chip Campbell



Re: Patch 7.0.082

2006-09-08 Thread Hari Krishna Dara

On Tue, 5 Sep 2006 at 5:19pm, Hari Krishna Dara wrote:


 On Mon, 4 Sep 2006 at 9:50pm, Bram Moolenaar wrote:

 
  Hari Krishna Dara wrote:
 
I wrote:
   
 Patch 7.0.082
 Problem:Calling a function that waits for input may cause List
and
   Dictionary arguments to be freed by the garbage collector.
 Solution:   Keep a list of all arguments to internal functions.
 Files:src/eval.c
   
I vaguely recall that some people were having unreproducible crashes
when using input() or inputlist().  This patch should solve that.
   
What happened was that the garbage collector didn't see the arguments
to
internal functions, thus would free List and Dict arguments that are
still in use.  That leads to a double free later.  The garbage
collector
only does it's work when the user doesn't type for a little while, that
made it unpredictable when it would happen.
  
   Can this happen during the debug session also? Like, when you do echo
   on lists? I am seeing that while debugging scripts that use Lists for
   sometime, Vim almost always crashes. Sometimes, I also start seeing
   internal errors related to List access (sorry, I didn't notedown the
   numbers) before it crashes.
 
  Yes, this could also happen in debug mode.  If you don't type something
  for 'updatetime' seconds the garbage collector is invoked.
 
  But the fix is only for when you pass a List or Dictionary to an
  internal function.  User functions were already OK.
 
  Hmm, now that I think of it you could get problems with a command like
  this:
 
  :echo [1, 2, 3, ..., 2000]
 
  If you get the more prompt the garbage collector might delete the list
  before it's completely echoed.  I'll look into that.
 

 This is probably what I was doing during the debugging. I will try to
 notice if an :echo on a list in a long running debug session is what is
 causing the crash.

I hit the error while debugging again. I did an echo on a list and did a
quit after a few seconds. Instead of debug session aborting
immediately, I got this below error:

E685: Internal error: clear_tv()

And it continued executing after that with several errors all seem to be
because of corrupted list. The list that I echoed is no longer treated
as a List type and function calls such as sort() that I had after that
resulted in errors. A subsequent quit worked and aborted the debug
session. If I had continued executing debug commands, I am pretty sure
that it would have resulted in a Vim crash.

-- 
Thanks,
Hari

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


Re: Patch 7.0.082

2006-09-08 Thread Bram Moolenaar

Hari Krishna Dara wrote:

   Hmm, now that I think of it you could get problems with a command like
   this:
  
 :echo [1, 2, 3, ..., 2000]
  
   If you get the more prompt the garbage collector might delete the list
   before it's completely echoed.  I'll look into that.
 
  This is probably what I was doing during the debugging. I will try to
  notice if an :echo on a list in a long running debug session is what is
  causing the crash.
 
 I hit the error while debugging again. I did an echo on a list and did a
 quit after a few seconds. Instead of debug session aborting
 immediately, I got this below error:
 
 E685: Internal error: clear_tv()
 
 And it continued executing after that with several errors all seem to be
 because of corrupted list. The list that I echoed is no longer treated
 as a List type and function calls such as sort() that I had after that
 resulted in errors. A subsequent quit worked and aborted the debug
 session. If I had continued executing debug commands, I am pretty sure
 that it would have resulted in a Vim crash.

Hopefully this happened before applying patch 7.0.084 !?

-- 
ARTHUR:  Shut up!  Will you shut up!
DENNIS:  Ah, now we see the violence inherent in the system.
ARTHUR:  Shut up!
DENNIS:  Oh!  Come and see the violence inherent in the system!
 HELP! HELP!  I'm being repressed!
  The Quest for the Holy Grail (Monty Python)

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///


Re: Vimdiff Oddity

2006-09-08 Thread Bram Moolenaar

Bill McCarthy wrote:

 To better understand what vimdiff is doing (and why it is so
 slow), I had my shell (4NT under WinXP) keep a log showing
 me just what was requested. [Note: I use '!' instead of ''
 for redirection because my 4NT is set to not overwrite
 existing files unless explicitly told to do so.]
 
 Invoking vimdiff with:  gvim -d file1 file2
 
 I can see that the following 3 shell requests are made:
 
 diff -a VIo2A3F.tmp VIn2A40.tmp !VId2A41.tmp
 diff -a --binary VIo2A3F.tmp VIn2A40.tmp !VId2A41.tmp
 diff -a --binary VIo2A3F.tmp VIn2A40.tmp !VId2A41.tmp
 
 The log shows about 4 seconds between commands.
 
 I would have thought that the first diff would provide
 enough information.  What is the purpose of the other two?

Vim first tests to see if executing diff works, with the -a and --binary
arguments.  Finally it does the actual diff.

This should take a fraction of a second.  4 seconds indicates that there
is something wrong in your setup.  Perhaps caused by 4NT.  Try using
another shell.

-- 
ARTHUR:  Bloody peasant!
DENNIS:  Oh, what a give away.  Did you here that, did you here that, eh?
 That's what I'm on about -- did you see him repressing me, you saw it
 didn't you?
  The Quest for the Holy Grail (Monty Python)

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///


Re: Patch 7.0.082

2006-09-08 Thread Hari Krishna Dara

On Fri, 8 Sep 2006 at 11:11pm, Bram Moolenaar wrote:


 Hari Krishna Dara wrote:

Hmm, now that I think of it you could get problems with a command like
this:
   
:echo [1, 2, 3, ..., 2000]
   
If you get the more prompt the garbage collector might delete the
list
before it's completely echoed.  I'll look into that.
  
   This is probably what I was doing during the debugging. I will try to
   notice if an :echo on a list in a long running debug session is what is
   causing the crash.
 
  I hit the error while debugging again. I did an echo on a list and did a
  quit after a few seconds. Instead of debug session aborting
  immediately, I got this below error:
 
  E685: Internal error: clear_tv()
 
  And it continued executing after that with several errors all seem to be
  because of corrupted list. The list that I echoed is no longer treated
  as a List type and function calls such as sort() that I had after that
  resulted in errors. A subsequent quit worked and aborted the debug
  session. If I had continued executing debug commands, I am pretty sure
  that it would have resulted in a Vim crash.

 Hopefully this happened before applying patch 7.0.084 !?


Yes, sorry I intend to mention that and forgot. But I thought you are
still going to look at more cases that might cause the bug that you were
originally trying to patch. Do you think this patch already covers the
cases that might arise during debugging as well?

-- 
Thanks,
Hari

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com