[pacman-dev] [PATCH] small fix in bindings directory
-- Roman Kyrylych (Роман Кирилич)
On 10/26/06, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
-- Roman Kyrylych (Роман Кирилич)
Just to make this easier for all mail clients - can you send patches like this as plaintext directly in the mail? diff format handles this perfectly, as it ignores all text above the diff.
AG> On 10/26/06, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
-- Roman Kyrylych (Роман Кирилич)
AG> Just to make this easier for all mail clients - can you send patches AG> like this as plaintext directly in the mail? diff format handles this AG> perfectly, as it ignores all text above the diff. I found that russian utf8 text not handled properly by at least some mail servers (and may be clients). I sent AUR translation diff to paul<at>archlinux.org as atached file and after several tries I gzip it to avoid data corruption... But I still do not know what cause this problem...
SP> I found that russian utf8 text not handled properly by at least some mail SP> servers (and may be clients). SP> I sent AUR translation diff to paul<at>archlinux.org as atached file and SP> after several tries I gzip it to avoid data corruption... SP> But I still do not know what cause this problem... Of cause if diff contains only ascii, it can be used safely
26 Oct 2006 19:48:18 +0400, Sergej Pupykin <ps@lx-ltd.ru>:
SP> I found that russian utf8 text not handled properly by at least some mail SP> servers (and may be clients).
SP> I sent AUR translation diff to paul<at>archlinux.org as atached file and SP> after several tries I gzip it to avoid data corruption...
SP> But I still do not know what cause this problem...
Of cause if diff contains only ascii, it can be used safely
Should I remove my sign with Cyrillic UTF-8 chars from messages with patches then? -- Roman Kyrylych (Роман Кирилич)
On 10/26/06, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
26 Oct 2006 19:48:18 +0400, Sergej Pupykin <ps@lx-ltd.ru>:
SP> I found that russian utf8 text not handled properly by at least some mail SP> servers (and may be clients).
SP> I sent AUR translation diff to paul<at>archlinux.org as atached file and SP> after several tries I gzip it to avoid data corruption...
SP> But I still do not know what cause this problem...
Of cause if diff contains only ascii, it can be used safely
Should I remove my sign with Cyrillic UTF-8 chars from messages with patches then?
Naw, as long as it's not in the diff - and even then it would still work just won't DISPLAY right. diff's are bounded. It has a beginning "+++ ---" and then it says "use the next Y lines". You can have as much garbage as you want above and below them. This was done intentionally, so that diffs could be included directly in emails.
2006/10/26, Aaron Griffin <aaronmgriffin@gmail.com>:
Should I remove my sign with Cyrillic UTF-8 chars from messages with patches then?
Naw, as long as it's not in the diff - and even then it would still work just won't DISPLAY right. diff's are bounded. It has a beginning "+++ ---" and then it says "use the next Y lines". You can have as much garbage as you want above and below them. This was done intentionally, so that diffs could be included directly in emails.
OK, so I will include short diffs right into the message and long and complex compress with gzip. Right? [offtopic on] BTW, about complex patches - I have a patch from Martin Devera that adds support for gdbm database backend to pacman 2.9.8. I suggested him to contact VMiklos for help in inclusion it in pacman, but I don't know if he did that. If I adapt it for Pacman 3 API is there a chance it will be included at least in CVS/DARCS? [/offtopic off] -- Roman Kyrylych (Роман Кирилич)
On 10/26/06, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
[offtopic on] BTW, about complex patches - I have a patch from Martin Devera that adds support for gdbm database backend to pacman 2.9.8. I suggested him to contact VMiklos for help in inclusion it in pacman, but I don't know if he did that. If I adapt it for Pacman 3 API is there a chance it will be included at least in CVS/DARCS? [/offtopic off]
There's no chance that would get included in pacman 2.9.8 - it will die soon. Converting it to pacman3 is entirely doable and it's already setup to do so. You should be able to copy be_files.c to be_gdbm.c and consume the interface provided there. FTR 'be_' means 'backend'. I still need to add compile-time flags for selecting a backend, but as we only provide _files at the moment, there's no need. I worked on a 'compressed' backend that required no changes, but read directly from the downloaded db files... it caused problems on the local db, however, so I never completed it (yet). As for backend schemes, I think we need to discuss avenues of attack here. The files backend is painfully slow on ext filesystems (11 seconds to parse [community]). There are many users touting a database backend as a good idea (I highly disagree), and if we do this, we NEED a generic layer to support any sane database format, not just one specific thing. Using a flat-file database is a better option, but here people seem to think sqlite is a good idea (it's not) - there are many flat-file schemes that can drastically outperform sqlite. There are many many other options, and I think it's worth at least _supplying_ multiple backends, even if they're not used. So gdbm is cool.
2006/10/26, Aaron Griffin <aaronmgriffin@gmail.com>:
On 10/26/06, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
[offtopic on] BTW, about complex patches - I have a patch from Martin Devera that adds support for gdbm database backend to pacman 2.9.8. I suggested him to contact VMiklos for help in inclusion it in pacman, but I don't know if he did that. If I adapt it for Pacman 3 API is there a chance it will be included at least in CVS/DARCS? [/offtopic off]
There's no chance that would get included in pacman 2.9.8 - it will die soon.
Converting it to pacman3 is entirely doable and it's already setup to do so. You should be able to copy be_files.c to be_gdbm.c and consume the interface provided there.
FTR 'be_' means 'backend'. I still need to add compile-time flags for selecting a backend, but as we only provide _files at the moment, there's no need.
I worked on a 'compressed' backend that required no changes, but read directly from the downloaded db files... it caused problems on the local db, however, so I never completed it (yet).
As for backend schemes, I think we need to discuss avenues of attack here. The files backend is painfully slow on ext filesystems (11 seconds to parse [community]). There are many users touting a database backend as a good idea (I highly disagree), and if we do this, we NEED a generic layer to support any sane database format, not just one specific thing. Using a flat-file database is a better option, but here people seem to think sqlite is a good idea (it's not) - there are many flat-file schemes that can drastically outperform sqlite.
There are many many other options, and I think it's worth at least _supplying_ multiple backends, even if they're not used. So gdbm is cool.
Maybe we should start separate thread for this? Personally, I think sqlite will be the best choice because of: 1) it's small 2) it's fast 3) it's embedable 4) it offers full power of SQL99 (with ACID transactions!!!) 5) it's public domain! :-D -- Roman Kyrylych (Роман Кирилич)
On Thu, Oct 26, 2006 at 10:14:50PM +0300, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
I suggested him to contact VMiklos for help in inclusion it in pacman, but I don't know if he did that.
no, he never did so udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
2006/10/26, VMiklos <vmiklos@frugalware.org>:
On Thu, Oct 26, 2006 at 10:14:50PM +0300, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
I suggested him to contact VMiklos for help in inclusion it in pacman, but I don't know if he did that.
no, he never did so
The patch was originally submitted here: http://bugs.archlinux.org/task/5328 I want to try to adapt it for pacman3 API, but you are more experienced so you may do this faster, if you have time and wish. ;-) -- Roman Kyrylych (Роман Кирилич)
On Thu, Oct 26, 2006 at 11:33:20PM +0300, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
The patch was originally submitted here: http://bugs.archlinux.org/task/5328 I want to try to adapt it for pacman3 API, but you are more experienced so you may do this faster, if you have time and wish. ;-)
thanks for the link. anyway i'm totally unfamiliar with gdbm + krix prefers sqlite, so.. we'll see udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org
2006/10/27, VMiklos <vmiklos@frugalware.org>:
On Thu, Oct 26, 2006 at 11:33:20PM +0300, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
The patch was originally submitted here: http://bugs.archlinux.org/task/5328 I want to try to adapt it for pacman3 API, but you are more experienced so you may do this faster, if you have time and wish. ;-)
thanks for the link. anyway i'm totally unfamiliar with gdbm + krix prefers sqlite, so.. we'll see
I agree with krix. :-p Anyway I'll try to adapt gdbm, even if someone's work will be better. This will help me to learn pacman internals. -- Roman Kyrylych (Роман Кирилич)
2006/10/26, Aaron Griffin <aaronmgriffin@gmail.com>:
Just to make this easier for all mail clients - can you send patches like this as plaintext directly in the mail? diff format handles this perfectly, as it ignores all text above the diff.
Of course. I will do that now. -- Roman Kyrylych (Роман Кирилич)
participants (4)
-
Aaron Griffin
-
Roman Kyrylych
-
Sergej Pupykin
-
VMiklos