On Jun 5 10:15, Warren Young wrote:
> On 6/4/2013 02:48, Corinna Vinschen wrote:
> >On Jun 3 11:36, Warren Young wrote:
> >>Could you add an O_MAND open(2) option as well to turn on the same
> >>feature? This will avoid a race condition.
> >
> >If you call F_LCK_MANDATORY right after open in the
On 6/4/2013 02:48, Corinna Vinschen wrote:
On Jun 3 11:36, Warren Young wrote:
Could you add an O_MAND open(2) option as well to turn on the same
feature? This will avoid a race condition.
If you call F_LCK_MANDATORY right after open in the opening routine,
there won't be (much of) a race.
On Jun 3 11:36, Warren Young wrote:
> On 6/2/2013 04:31, Corinna Vinschen wrote:
> >I dropped the F_MDLCK idea. Instead I implemented a specific fcntl code
> >to switch to mandatory locking on a file descriptor:
> >
> > fcntl (fd, F_LCK_MANDATORY, 1);
>
> Could you add an O_MAND open(2) option
On 6/2/2013 04:31, Corinna Vinschen wrote:
I just applied a patch to implement mandatory locking.
Thank you!
It also supports
F_GETLK, with limited usability due to Windows restrictions, as I
explained in other mail.
It is what it is.
A haiku:
Yesterday it worked.
Today it is not
On Jun 3 10:38, Achim Gratz wrote:
> Corinna Vinschen cygwin.com> writes:
> > The result of removing colspan is a more narrow table, which doesn't
> > match the width of the headline. Afaics, a colspan=6 for the daily
> > headline containing date/changelog/diff would look better, wouldn't it?
>
Corinna Vinschen cygwin.com> writes:
> > The result of removing colspan is a more narrow table, which doesn't
> > match the width of the headline. Afaics, a colspan=6 for the daily
> > headline containing date/changelog/diff would look better, wouldn't it?
OK, got it - disregard my other mail.
Corinna Vinschen cygwin.com> writes:
> The result of removing colspan is a more narrow table, which doesn't
> match the width of the headline. Afaics, a colspan=6 for the daily
> headline containing date/changelog/diff would look better, wouldn't it?
It seems we aren't looking at the same table.
On Jun 3 12:32, Corinna Vinschen wrote:
> On Jun 3 10:21, Achim Gratz wrote:
> > Corinna Vinschen cygwin.com> writes:
> > > The colspan=3 is for the cell containing the filesize.
> >
> > Yes, and it should be eliminated. I guess formerly the header line with the
> > snapshot date had multiple
On Jun 3 10:21, Achim Gratz wrote:
> Corinna Vinschen cygwin.com> writes:
> > The colspan=3 is for the cell containing the filesize.
>
> Yes, and it should be eliminated. I guess formerly the header line with the
> snapshot date had multiple cells, but now it has just one.
>
> > There's no col
Corinna Vinschen cygwin.com> writes:
> The colspan=3 is for the cell containing the filesize.
Yes, and it should be eliminated. I guess formerly the header line with the
snapshot date had multiple cells, but now it has just one.
> There's no colspan for the cell with the filename, afaics.
No,
On Jun 3 09:53, Achim Gratz wrote:
> Corinna Vinschen cygwin.com> writes:
> > > BTW, on the webpage with the snapshots the 'colspan="3"' should be
> > > removed in the table cells for the file names.
> >
> > I'm not a web designer, so, why?
>
> The cell with the snapshot date specifies 'colspan
Corinna Vinschen cygwin.com> writes:
> > BTW, on the webpage with the snapshots the 'colspan="3"' should be
> > removed in the table cells for the file names.
>
> I'm not a web designer, so, why?
The cell with the snapshot date specifies 'colspan="4"' and the other rows
have four columns, so the
On Jun 3 08:03, Achim Gratz wrote:
> Corinna Vinschen cygwin.com> writes:
> > Please give the 32 bit snapshot a try ASAP. I intend to release 1.7.19
> > very soon, probably tomorrow or Tuesday.
>
> Have it installed now, but I can't give it much testing before the end of
> the week.
>
> BTW, o
Corinna Vinschen cygwin.com> writes:
> Please give the 32 bit snapshot a try ASAP. I intend to release 1.7.19
> very soon, probably tomorrow or Tuesday.
Have it installed now, but I can't give it much testing before the end of
the week.
BTW, on the webpage with the snapshots the 'colspan="3"' s
On Jun 2 12:31, Corinna Vinschen wrote:
> [...]
> fcntl (fd, F_LCK_MANDATORY, 1);
> [...]
> I'm just about to generate a 2013-06-02 developer snapshot for 32 bit,
> a 64 bit DLL will follow tomorrow.
64 bit test release 1.7.19-9 uploaded.
> Please give the 32 bit snapshot a try ASAP. I intend
Hi Warren,
On Jun 1 12:57, Corinna Vinschen wrote:
> If F_MDLCK is not such a bright idea, maybe another fcntl is? Something
> along these lines:
>
> fd = open ("my.db", ...);
> #ifdef __CYGWIN__
> fcntl (fd, F_SETLK_MAND, 1);
> #endif
>
> As for the user, we could add the g+S,g-x
On Jun 1 13:35, Corinna Vinschen wrote:
> On Jun 1 12:57, Corinna Vinschen wrote:
> > There's a lot to recommend not using mandatory locking at all, unless in
> > very limited circumstances where interoperability with native
> > applications using mandatory locking is required. For one thing, th
On Jun 1 12:57, Corinna Vinschen wrote:
> There's a lot to recommend not using mandatory locking at all, unless in
> very limited circumstances where interoperability with native
> applications using mandatory locking is required. For one thing, this
> doesn't occur very often, since mandatory re
On May 31 14:19, Warren Young wrote:
> On 5/31/2013 13:58, Warren Young wrote:
> >
> >The SQLite code prefers POSIX advisory locks, but it can fall back to
> >BSD locks if it has to.
>
> Just to clarify, when I say "POSIX locks" I always mean new style
> fcntl() locks. There are no calls to lockf
On May 31 13:58, Warren Young wrote:
> On 5/31/2013 03:22, Corinna Vinschen wrote:
> >On May 30 18:56, Warren Young wrote:
> >>1. We continue waiting for someone to to implement a per-process or
> >>per-subtree mandatory locking feature in Cygwin, so that "Unix mode"
> >>SQLite on Cygwin can be con
On 2013-05-31 13:45, Warren Young wrote:
On 5/30/2013 22:23, Yaakov (Cygwin/X) wrote:
I can confirm that -DSQLITE_TEMP_STORE=2 is enough to fix
monotone on its own.
I have updated my build accordingly, plus added two more configuration
options, and a patch for the manpage, from Fedora. Can *th
On 5/31/2013 13:58, Warren Young wrote:
The SQLite code prefers POSIX advisory locks, but it can fall back to
BSD locks if it has to.
Just to clarify, when I say "POSIX locks" I always mean new style
fcntl() locks. There are no calls to lockf() in sqlite3.c.
I'm not sure why it doesn't ju
On 5/31/2013 03:22, Corinna Vinschen wrote:
On May 30 18:56, Warren Young wrote:
1. We continue waiting for someone to to implement a per-process or
per-subtree mandatory locking feature in Cygwin, so that "Unix mode"
SQLite on Cygwin can be configured to cooperate with native SQLite.
What kin
On 5/30/2013 22:23, Yaakov (Cygwin/X) wrote:
I can confirm that -DSQLITE_TEMP_STORE=2 is enough to fix
monotone on its own.
I have updated my build accordingly, plus added two more configuration
options, and a patch for the manpage, from Fedora. Can *this* get into
the distro package?
I don't
On May 30 18:56, Warren Young wrote:
> 1. We continue waiting for someone to to implement a per-process or
> per-subtree mandatory locking feature in Cygwin, so that "Unix mode"
> SQLite on Cygwin can be configured to cooperate with native SQLite.
What kind of locking does sqlite use on Cygwin:
[
Yaakov (Cygwin/X users.sourceforge.net> writes:
> Yes, I can now confirm that (the lack of) SQLITE_OS_UNIX is the culprit.
[...]
> If it's a choice between Cygwin programs functioning correctly (in this
> case, mtn clone), and allowing interoperability with Windows programs,
> there is NO QUESTI
On 2013-05-30 05:27, Achim Gratz wrote:
Yaakov (Cygwin/X users.sourceforge.net> writes:
This was working properly with my 3.7.15.2 x64 package, as well as with
a self-built 3.7.17. I don't know if it's a question of configuration
options or a bug in that version. Here's how I have built sqlit
On 5/30/2013 16:36, Yaakov (Cygwin/X) wrote:
DON'T BREAK Cygwin programs for the sake of those NOT USING Cygwin.
Where did you get the idea that my stance favors those not using Cygwin?
My choice favors those who want to use Cygwin *and* native Windows
programs, together. That's approximatel
On 2013-05-30 12:02, Warren Young wrote:
On 5/30/2013 04:27, Achim Gratz wrote:
Yaakov (Cygwin/X users.sourceforge.net> writes:
This was working properly with my 3.7.15.2 x64 package, as well as with
a self-built 3.7.17. I don't know if it's a question of configuration
options or a bug in tha
On 5/30/2013 04:27, Achim Gratz wrote:
Yaakov (Cygwin/X users.sourceforge.net> writes:
This was working properly with my 3.7.15.2 x64 package, as well as with
a self-built 3.7.17. I don't know if it's a question of configuration
options or a bug in that version. Here's how I have built sqlite
Yaakov (Cygwin/X users.sourceforge.net> writes:
> This was working properly with my 3.7.15.2 x64 package, as well as with
> a self-built 3.7.17. I don't know if it's a question of configuration
> options or a bug in that version. Here's how I have built sqlite3:
You are defining "SQLITE_OS_UN
Warren,
I'm having a problem with my newly built monotone packages on both x86
and x64:
mtn: warning: recoverable 'system' error while processing peer
mtn://monotone.ca/monotone: 'error: sqlite error: SQL logic error or
missing database'
mtn: error: processing failure while talking to peer
32 matches
Mail list logo
