Fixing bugs in Vim

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Fixing bugs in Vim

Martin Toft
Hi,

I'm participating in Google's Summer of Code (GSoC) program, where my
mission is to fix bugs in Vim.  I have written a huge post about my work
so far on my GSoC-blog:

http://gsoc.martintoft.dk/

Enjoy :-)

Best regards,
Martin

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing bugs in Vim

Edward L. Fox

Hi Martin and Bram,

On 8/4/07, Martin Toft <[hidden email]> wrote:
> Hi,
>
> I'm participating in Google's Summer of Code (GSoC) program, where my
> mission is to fix bugs in Vim.  I have written a huge post about my work
> so far on my GSoC-blog:

Do you think the trunk of the Svn repository will be a good place for
storing those *bleeding edge* code? If anyone geeky or nurdy enough
would like to try out the latest bugs fixing or would like to help
doing some testing, they could check them out from the trunk. While
the branches/vim7.1 will still be the latest "stable" version for
average users.

"Sometimes (almost always, hehe) Bram tells me that he has changed
something before committing a patch, and I don't "backport" those
changes to the files on this site."

I can do the "backports" for you, if you like. I will be a good IT
supporter. :-)

>
> http://gsoc.martintoft.dk/
>
> Enjoy :-)
>
> Best regards,
> Martin
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFGs6agEtBnr8BYnZ4RAhfQAKDqnkTzdOprjBHlJm52x7g+jFdYIACggDip
> f0+bVpeBWfMWw6en+vgDUFY=
> =DGJa
> -----END PGP SIGNATURE-----
>
>

Regards,

Edward L. Fox

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Fixing bugs in Vim

Bram Moolenaar


Edward L. Fox wrote:

> Hi Martin and Bram,
>
> On 8/4/07, Martin Toft <[hidden email]> wrote:
> > Hi,
> >
> > I'm participating in Google's Summer of Code (GSoC) program, where my
> > mission is to fix bugs in Vim.  I have written a huge post about my work
> > so far on my GSoC-blog:
>
> Do you think the trunk of the Svn repository will be a good place for
> storing those *bleeding edge* code? If anyone geeky or nurdy enough
> would like to try out the latest bugs fixing or would like to help
> doing some testing, they could check them out from the trunk. While
> the branches/vim7.1 will still be the latest "stable" version for
> average users.
>
> "Sometimes (almost always, hehe) Bram tells me that he has changed
> something before committing a patch, and I don't "backport" those
> changes to the files on this site."
>
> I can do the "backports" for you, if you like. I will be a good IT
> supporter. :-)

In my opinion the Vim SVN repository is for the official version of Vim
only.  Adding things there that are experiments or patches that will
later become official causes confusion.

There are plenty of other places where you can make your experimental
code available to others, in various forms.  www.sourceforge.net and
code.google.com are two examples.  You can setup your own project for
yourself or work together with a group.

--
Where do you want to crash today?

 /// Bram Moolenaar -- [hidden email] -- 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    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Fixing bugs in Vim

Martin Toft
In reply to this post by Edward L. Fox
Hi Edward,

first -- thanks for your interest in my work :-)

On Sat, Aug 04, 2007 at 06:04:02PM +0800, Edward L. Fox wrote:

> Hi Martin and Bram,
>
> On 8/4/07, Martin Toft <[hidden email]> wrote:
> > Hi,
> >
> > I'm participating in Google's Summer of Code (GSoC) program, where
> > my mission is to fix bugs in Vim.  I have written a huge post about
> > my work so far on my GSoC-blog:
>
> Do you think the trunk of the Svn repository will be a good place for
> storing those *bleeding edge* code? If anyone geeky or nurdy enough
> would like to try out the latest bugs fixing or would like to help
> doing some testing, they could check them out from the trunk. While
> the branches/vim7.1 will still be the latest "stable" version for
> average users.
Yeah, that could be a good place, but I'm very satisfied with the way
things are done at the moment (I send patches to Bram, he looks through
them and eventually commits them).  After all, my patches should be
mostly bug fixes, so ideally they should be easy to verify.

Geeky and nurdy people (like myself :-) are more than welcome to
download the patches from my site, try them out and give me feedback.
The site's disclaimer should just indicate that I'm not promising to
support this.

> "Sometimes (almost always, hehe) Bram tells me that he has changed
> something before committing a patch, and I don't "backport" those
> changes to the files on this site."
>
> I can do the "backports" for you, if you like. I will be a good IT
> supporter. :-)

Thanks for your offer, but I really don't think it is needed.  So far,
the commit-time changes hasn't been critical.  It has mostly been
compiler warnings and missing prototypes for cproto.

Again, thanks for your interest.  I'm sorry to, sort of, turn your
offers down like this.

Best regards,
Martin

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Fixing bugs in Vim

JohnBeckett
In reply to this post by Martin Toft

Martin Toft wrote:
> I'm participating in Google's Summer of Code (GSoC) program,
> where my mission is to fix bugs in Vim.  I have written a
> huge post about my work so far on my GSoC-blog:
>
> http://gsoc.martintoft.dk/

Congratulations Martin - that's a great result.

When you run out of things to do<g>, let me know so I can explain how Vim
needs to be able to detect large files (>2GB) on 32-bit systems that have
large file support!

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Fixing bugs in Vim

Martin Toft
On Sat, Aug 04, 2007 at 11:20:47PM +1000, John Beckett wrote:
> Congratulations Martin - that's a great result.

Thanks :-)  I plan to do a lot more, though.

> When you run out of things to do<g>, let me know so I can explain how
> Vim needs to be able to detect large files (>2GB) on 32-bit systems
> that have large file support!

Hehe, that sounds pretty complex and extensive.

Martin

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fixing bugs in Vim

Edward L. Fox
In reply to this post by Bram Moolenaar

Hi Bram,

On 8/4/07, Bram Moolenaar <[hidden email]> wrote:
> [...]
> In my opinion the Vim SVN repository is for the official version of Vim
> only.  Adding things there that are experiments or patches that will
> later become official causes confusion.

At first, the SVN repository contained only one top-level directory
named "vim7". Because the development of Vim is in pure "linear" mode,
that is, without any branches. So I didn't add any "trunk", "tags" or
"branches", as most of the other SVN repositories do at that time.

But when Vim 7.1 began to Beta, many people complained for the
none-standard directory structure so I added "trunk", "branches" and
"tags".

So far till now, the all operations I did to the "trunk" is just
"Merged from the latest developing branch". It's quite boring and
makes no good to any one at all. I keep doing such useless job only
because I'm still in hope that one day the "trunk" directory will be
used by some intelligent developer.

If such dream will never come true, do you think we should remove the
"trunk" directory now? Waiting for your response...

> There are plenty of other places where you can make your experimental
> code available to others, in various forms.  www.sourceforge.net and
> code.google.com are two examples.  You can setup your own project for
> yourself or work together with a group.

Well, I don't think I need to branch out into a new project. Firstly,
I don't consider myself a competent developer to maintain such a big
project. Secondly, I don't have enough time to do such a heavy job.
Thirdly, if I had enough time and ability, I would rather join the
Yzis team than branch out because the former is much more exciting.

OK, I admit that I don't have such ability so I would just continue
doing my own work here - supporting the intelligent developers without
any more complaint.

> [...]


Be In Peace,

Edward L. Fox

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

RE: Fixing bugs in Vim

JohnBeckett
In reply to this post by Martin Toft

Martin Toft wrote:
>> Vim needs to be able to detect large files (>2GB) on 32-bit
>> systems that have large file support!
>
> Hehe, that sounds pretty complex and extensive.

FYI (and in case it catches anyone's interest here), the code is
very easy.

The trick would be to put the code into the complex Vim
distribution without breaking stuff.

Here is a quick sample of how to get the size of a large file
(>2GB) on a 32-bit system that supports large files. The trick
would be to handle systems that do NOT support large files.

#if defined(__linux)
# define _LARGEFILE64_SOURCE
#elif defined(_WIN32)
# define off64_t    __int64
# define stat64     _stati64
#else
/* ??? */
#endif

#include <sys/types.h>
#include <sys/stat.h>

int main(int argc, char *argv[])
{
    off64_t size;
    struct stat64 sb;
    if ( argc != 2 || stat64(argv[1], &sb) != 0 )
        return 1;
    size = sb.st_size >> 20;    /* size in megabytes */
    return (int)size;
}

I'm not suggesting you take this on ... sticking to your
schedule would be best. But others here might want to have a
look at it because the current situation is that Dr.Chip has a
great plugin to make Vim handle large files gracefully, but it
can't actually detect really large files...

We were discussing this when the old mailing list broke.

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---