RFC: bigger '--with-features' than huge (incl interpreters)
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)
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. :-)
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. :-)
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. :-)
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
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
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
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
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