On Mon, Feb 28, 2011 at 15:12, Richard Hipp wrote:
> On Mon, Feb 28, 2011 at 8:36 AM, Paweł Hajdan, Jr. <
> phajdan...@chromium.org> wrote:
>
>>
>> I remember a part of earlier discussion that there is a problem with
>> journal and possibly other auxiliary file
2011/2/28 Richard Hipp
> On Mon, Feb 28, 2011 at 7:39 AM, Paweł Hajdan, Jr. <
> phajdan...@chromium.org> wrote:
>
>> I'd like to add an equivalent of fdopen to the sqlite's VFS (
>> http://www.sqlite.org/c3ref/vfs.html). The signature would similar to
>
I'd like to add an equivalent of fdopen to the sqlite's VFS (
http://www.sqlite.org/c3ref/vfs.html). The signature would similar to this:
int (*xFdOpen)(sqlite3_vfs*, int fd, sqlite3_file*, int flags, int
*pOutFlags);
This would be needed to cleanly implement fd-passing in Chromium, from
the brow
On Fri, Oct 8, 2010 at 15:28, sjtirtha wrote:
> 1. setup an development environment for SQLite (I'm using Ubuntu)
>Do you have any preference which editor or IDE should I use?
It's very easy. Download the sources, compile the "standard" way
(./configure; make). Any editor is fine.
_
On Tue, Aug 31, 2010 at 19:51, Richard Hipp wrote:
> My suggestion is that you make a copy of the os_unix.c source file (call it
> chromium_vfs.c or anything else that you like) and apply your edits to that
> copy.
FYI, that's what finally happened.
_
place.
> They are untested and unsupported. We'll get around to patching them, if
> you insist, but right now we are busy trying to 3.7.1 out the door.
>
> On Wed, Aug 18, 2010 at 4:41 PM, Paweł Hajdan, Jr.
> wrote:
>
> > On Tue, Aug 10, 2010 at 13:16, Paweł Haj
On Tue, Aug 31, 2010 at 10:51, Richard Hipp wrote:
> My suggestion is that you make a copy of the os_unix.c source file (call it
> chromium_vfs.c or anything else that you like) and apply your edits to that
> copy. Since you started with an exact copy of the original os_unix.c
> source
> file, y
2010/8/31 Richard Hipp
> os_unix.c is very unlikely to change in ways that you care about.
I think the biggest concern is just copying that code, please see
http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/7f8e9bf0f034322f/b26e422d4aa711c7.
I think that keeping it
On Tue, Aug 31, 2010 at 10:51, Richard Hipp wrote:
> My suggestion is that you make a copy of the os_unix.c source file (call it
> chromium_vfs.c or anything else that you like) and apply your edits to that
> copy. Since you started with an exact copy of the original os_unix.c
> source
> file, y
On Fri, Aug 27, 2010 at 18:27, Paweł Hajdan, Jr. wrote:
>
>
>> At start-time, simply call sqlite3_vfs_register() to register your
>> customized VFS with SQLite.
>>
>
> That's what our implementation effectively does, see
> http://trac.webkit.org/brows
On Fri, Aug 27, 2010 at 04:58, Richard Hipp wrote:
> The VFS interface is published, stable, and documented. I think the VFS is
> the interface you should be using.
>
> You do not have to patch os_unix.c. Leave it unchanged.
Sounds good to me. This is one of my goals - to avoid those custom p
Please take a look at chromium_sqlite3 functions in
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/sqlite/src/src/os_unix.c?view=markup
They are needed because in Chrome the browser process will pass a file
descriptor to the child renderer process instead of a file path. Here's the
co
After updating the tests run fine now. Thanks for the quick update!
By the way, I usually avoid having "." in the PATH for security reasons.
On Fri, Aug 20, 2010 at 05:30, Dan Kennedy wrote:
>
> On Aug 20, 2010, at 6:07 AM, Paweł Hajdan, Jr. wrote:
>
> > I updated to l
I updated to latest fossil version, ran make distclean, ./configure, make,
make test and got this:
avtrans-9.19.4-5116... Ok
avtrans-9.19.5-5116... Ok
avtrans-9.20.1-5640... Ok
avtrans-9.20.2-5640... Ok
avtrans-10.1... Ok
avtrans.test-closeallfiles... Ok
avtrans.test-sharedcachesetting... Ok
Time:
On Tue, Aug 10, 2010 at 13:16, Paweł Hajdan, Jr. wrote:
> Now, how about fts1 and fts2? The original chromium patch is at
> http://codereview.chromium.org/174387 . Could you take a look and suggest
> a way to upstream those fixes to SQLite?
>
Ping about the above. Or have the fixes
possible?
On Wed, Aug 11, 2010 at 23:23, Damian Pietras wrote:
> On Tue, Aug 10, 2010 at 05:46:26PM -0700, Paweł Hajdan, Jr. wrote:
> > So this is another chromium patch I'd like to submit:
> >
> http://src.chromium.org/viewvc/chrome/trunk/src/third_party/sqlite/preload-c
So this is another chromium patch I'd like to submit:
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/sqlite/preload-cache.patch?revision=26596&view=markup
I'm not the author of that one, but the main idea seems to be that with
preloading we get better performance with many scenarios c
does it need to be changed to
> > >
> > >ch = (ch>='A' && ch<='Z') ? ch - 'A' + 'a' : ch;
> > >
> > > There is only one such instance of code remaining in FTS3 (at
> > > fts3_tokenizer1.c:196) bu
On Wed, Aug 4, 2010 at 15:23, Paweł Hajdan, Jr. wrote:
> I'm attaching a suggested patch to fix locale-unsafe usage of tolower in
> FTS code. The goal is to make Chromium closer to the upstream, so if you
> have a better solution, that's great.
Oh, I have just noticed th
On Wed, Aug 4, 2010 at 16:30, Scott Hess wrote:
> You should probably pull the current SQLite code and make sure the
> patch even applies, and if not, check to make sure that the problem
> hasn't already been fixed. ext/fts3 should no longer have the flaw in
> question, as that code was heavily
I'm attaching a suggested patch to fix locale-unsafe usage of tolower in FTS
code. The goal is to make Chromium closer to the upstream, so if you have a
better solution, that's great.
This is upstreaming a Chromium patch
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/sqlite/safe-tolow
On Thu, Jul 29, 2010 at 22:53, Dan Kennedy wrote:
> Looks like it was fixed for 3.6.22:
>
> http://www.sqlite.org/src/ci/c34cf23efb
Thank you. I have changed chromium's copy of sqlite to contain the above
version of the code, so we're closer to upstream now.
__
I'm attaching a suggested patch to verify number of arguments
in icuRegexpFunc. Please review it.
This is upstreaming of
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/sqlite/icu-regexp.patch?revision=34807&view=markup
According to the commit message from above, it has been reported
On Thu, Jul 29, 2010 at 16:34, Richard Hipp wrote:
> The test suite now requires Tcl 8.5. You appear to be running Tcl 8.4.
>
That's right. After upgrading from tcl8.4 to tcl8.5 the tests run just fine.
Thanks!
___
sqlite-users mailing list
sqlite-us
I'm planning to contribute some patches (upstreaming patches Chromium
project applies to its local copy of sqlite).
I've checked out the fossil repository, configured and compiled sqlite, and
tried running "make test" (I didn't make any changes).
I'm pasting below the test result and some fossil
25 matches
Mail list logo
