Kornel Benko wrote:
> This should not be the case.
> The line configure.ac:177 should define HAVE_LOCKF, but maybe I am
> misunderstanding.
Yes, you are right., I did forget to run autogen.sh. After doing that
lockf() is correctly detected.
Georg
Am Mittwoch, 27. November 2013 um 07:40:52, schrieb Stephan Witt
> Am 25.11.2013 um 22:52 schrieb Vincent van Ravesteijn :
>
> > Stephan Witt schreef op 25-11-2013 17:06:
> >> Am 25.11.2013 um 13:01 schrieb Vincent van Ravesteijn :
> >>
> >>>
> >>> On Mon, Nov 25, 2013 at 11:50 AM, Kornel Benk
Am 25.11.2013 um 22:52 schrieb Vincent van Ravesteijn :
> Stephan Witt schreef op 25-11-2013 17:06:
>> Am 25.11.2013 um 13:01 schrieb Vincent van Ravesteijn :
>>
>>>
>>> On Mon, Nov 25, 2013 at 11:50 AM, Kornel Benko wrote:
>>> Am Montag, 25. November 2013 um 08:22:27, schrieb Vincent van Raves
Am Dienstag, 26. November 2013 um 22:11:31, schrieb Vincent van Ravesteijn
>
> > > > Well, I've seen strange things happen before.
> >
> > > >
> >
> > > > Do we think this is safe enough to keep it in 2.1 now the last
> > beta has
> >
> > > > been released ?
> >
> > >
> >
> > > I'd say for Linu
> > > Well, I've seen strange things happen before.
>
> > >
>
> > > Do we think this is safe enough to keep it in 2.1 now the last beta
has
>
> > > been released ?
>
> >
>
> > I'd say for Linux it is safe if NFS is not used. For NFS
>
> >
http://stackoverflow.com/questions/575328/fcntl-lockf-which-
> > Well, I've seen strange things happen before.
> >
> > Do we think this is safe enough to keep it in 2.1 now the last
beta has
> > been released ?
>
> I'd say for Linux it is safe if NFS is not used. For NFS
>
http://stackoverflow.com/questions/575328/fcntl-lockf-which-is-better-to-
Am Dienstag, 26. November 2013 um 21:33:06, schrieb Georg Baum
> Vincent van Ravesteijn wrote:
>
> > Kornel Benko schreef op 25-11-2013 13:20:
> >>
> >> Am Montag, 25. November 2013 um 13:01:05, schrieb Vincent van
> >> Ravesteijn
> >>
> >> >
> >>
> >> > The problem is that the commit is touchi
Am Dienstag, 26. November 2013 um 21:16:26, schrieb Georg Baum
> Kornel Benko wrote:
>
> > Am Montag, 25. November 2013 um 22:48:11, schrieb Vincent van Ravesteijn
> >
> >> Georg Baum schreef op 25-11-2013 21:09:
> >>
> >> > However, in this particular case, the code has a problem:
> >> > supp
Vincent van Ravesteijn wrote:
> Kornel Benko schreef op 25-11-2013 13:20:
>>
>> Am Montag, 25. November 2013 um 13:01:05, schrieb Vincent van
>> Ravesteijn
>>
>> >
>>
>> > The problem is that the commit is touching very essential code. If
>>
>> > something goes wrong LyX becomes pretty much unusa
Kornel Benko wrote:
> Am Montag, 25. November 2013 um 22:48:11, schrieb Vincent van Ravesteijn
>
>> Georg Baum schreef op 25-11-2013 21:09:
>>
>> > However, in this particular case, the code has a problem:
>> > support::fileLock() and support::fileUnlock() behave _very_ differently
>> > dependin
Kornel Benko schreef op 25-11-2013 13:20:
Am Montag, 25. November 2013 um 13:01:05, schrieb Vincent van
Ravesteijn
>
> The problem is that the commit is touching very essential code. If
> something goes wrong LyX becomes pretty much unusable (e.g. if configure
> isn't run anymore).
This
On Tue, Nov 26, 2013 at 2:22 PM, Jürgen Spitzmüller wrote:
> 2013/11/26 Vincent van Ravesteijn
>
> If we postpone the fix for windows, we can use this. I think we will ship
>> LyX 2.2 with Qt5.
>>
>
> BTW is LyX 2.1 with Qt5 already operational?
>
> Jürgen
>
>
Not completely. For instance, we ne
2013/11/26 Vincent van Ravesteijn
> If we postpone the fix for windows, we can use this. I think we will ship
> LyX 2.2 with Qt5.
>
BTW is LyX 2.1 with Qt5 already operational?
Jürgen
>
> Vincent
>
>
On Mon, Nov 18, 2013 at 9:27 PM, Georg Baum
wrote:
> Kornel Benko wrote:
>
> > Hi,
> > can we please have some locking mechanism here?
>
> This would indeed be a good idea.
>
> > While parallel export testing is OK, if the userdir is configured,
> > it is not if started with a fresh created userdi
Am Montag, 25. November 2013 um 22:48:11, schrieb Vincent van Ravesteijn
> Georg Baum schreef op 25-11-2013 21:09:
> > Stephan Witt wrote:
> >
> >> Am 25.11.2013 um 13:01 schrieb Vincent van Ravesteijn :
> >>
> >>> The problem is that the commit is touching very essential code. If
> >>> something
Stephan Witt schreef op 25-11-2013 17:06:
Am 25.11.2013 um 13:01 schrieb Vincent van Ravesteijn :
On Mon, Nov 25, 2013 at 11:50 AM, Kornel Benko wrote:
Am Montag, 25. November 2013 um 08:22:27, schrieb Vincent van Ravesteijn
On Tue, Nov 19, 2013 at 9:55 PM, Kornel Benko wrote:
Am Dienst
Georg Baum schreef op 25-11-2013 21:09:
Stephan Witt wrote:
Am 25.11.2013 um 13:01 schrieb Vincent van Ravesteijn :
The problem is that the commit is touching very essential code. If
something goes wrong LyX becomes pretty much unusable (e.g. if configure
isn't run anymore). We can never be s
Stephan Witt wrote:
> Am 25.11.2013 um 13:01 schrieb Vincent van Ravesteijn :
>
>> The problem is that the commit is touching very essential code. If
>> something goes wrong LyX becomes pretty much unusable (e.g. if configure
>> isn't run anymore). We can never be sure that there is no platform o
Kornel Benko wrote:
> Running 2 lyx processes with the same (and empty) userdir, means the
> configure.py are running parallel building the data in that dir. The
> result is mostly crap.
I believe that the same crap happens if you use a graphical file manager and
drag several files at once onto
Am 25.11.2013 um 13:01 schrieb Vincent van Ravesteijn :
>
>
> On Mon, Nov 25, 2013 at 11:50 AM, Kornel Benko wrote:
> Am Montag, 25. November 2013 um 08:22:27, schrieb Vincent van Ravesteijn
>
> > On Tue, Nov 19, 2013 at 9:55 PM, Kornel Benko wrote:
> >
> > > Am Dienstag, 19. November 2013 u
Am Montag, 25. November 2013 um 13:01:05, schrieb Vincent van Ravesteijn
>
> The problem is that the commit is touching very essential code. If
> something goes wrong LyX becomes pretty much unusable (e.g. if configure
> isn't run anymore).
This cannot happen. You can't construct such a case.
On Mon, Nov 25, 2013 at 11:50 AM, Kornel Benko wrote:
> Am Montag, 25. November 2013 um 08:22:27, schrieb Vincent van Ravesteijn
>
>
> > On Tue, Nov 19, 2013 at 9:55 PM, Kornel Benko wrote:
>
> >
>
> > > Am Dienstag, 19. November 2013 um 21:06:21, schrieb Georg Baum <
>
> > > georg.b...@post.r
Am Montag, 25. November 2013 um 08:22:27, schrieb Vincent van Ravesteijn
> On Tue, Nov 19, 2013 at 9:55 PM, Kornel Benko wrote:
>
> > Am Dienstag, 19. November 2013 um 21:06:21, schrieb Georg Baum <
> > georg.b...@post.rwth-aachen.de>
> > > Kornel Benko wrote:
> > >
> > > > Trying to lock with
On Tue, Nov 19, 2013 at 9:55 PM, Kornel Benko wrote:
> Am Dienstag, 19. November 2013 um 21:06:21, schrieb Georg Baum <
> georg.b...@post.rwth-aachen.de>
> > Kornel Benko wrote:
> >
> > > Trying to lock with
> > > open(lock_file.c_str(), O_CREAT|O_EXCL|O_SYNC|O_RDWR, 0666);
> > > seams to work he
Am Sonntag, 24. November 2013 um 19:05:09, schrieb Vincent van Ravesteijn
> Kornel Benko schreef op 21-11-2013 22:36:
> > > So it is OK for Linux and OS X, but not for Windows. Who is going to
> >
> > > implement the Windows equivalent? Sorry to play the devils advocate
> > again,
> >
> > > but
Kornel Benko schreef op 21-11-2013 22:36:
> So it is OK for Linux and OS X, but not for Windows. Who is going to
> implement the Windows equivalent? Sorry to play the devils advocate
again,
> but I believe these things are important.
ATM, for windows does not change anything.
Until now nobo
Am Donnerstag, 21. November 2013 um 21:31:58, schrieb Georg Baum
> Kornel Benko wrote:
>
> > Am Mittwoch, 20. November 2013 um 00:30:54, schrieb Tommaso Cucinotta
> >
> >>
> >> What about boost::interprocess::file_lock ?
> >>
> >> Note from
> >>
> >>
> http://www.boost.org/doc/libs/1_55_0
Kornel Benko wrote:
> Am Mittwoch, 20. November 2013 um 00:30:54, schrieb Tommaso Cucinotta
>
>>
>> What about boost::interprocess::file_lock ?
>>
>> Note from
>>
>>
http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interprocess/file_lock.html
>>
>> "A file lock can't guarantee synchroni
Am Mittwoch, 20. November 2013 um 19:31:22, schrieb Tommaso Cucinotta
> On 20/11/13 13:46, Kornel Benko wrote:
> > I thought about something I programmed in the past.
> > Using semaphores on shared memory (over mmap() of file from userdir). But
> > it looked like overkill.
>
> You don't need se
On 20/11/13 13:46, Kornel Benko wrote:
> I thought about something I programmed in the past.
> Using semaphores on shared memory (over mmap() of file from userdir). But it
> looked like overkill.
You don't need semaphores over shared memory. The same thing can be achieved by
the far easier
pthre
Am Mittwoch, 20. November 2013 um 00:30:54, schrieb Tommaso Cucinotta
> On 19/11/13 20:55, Kornel Benko wrote:
> > I know. Scott and I are testing with lockf() now.
>
> What about boost::interprocess::file_lock ?
>
> Note from
>
>
> http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interp
On 19/11/13 20:55, Kornel Benko wrote:
> I know. Scott and I are testing with lockf() now.
What about boost::interprocess::file_lock ?
Note from
http://www.boost.org/doc/libs/1_55_0/doc/html/boost/interprocess/file_lock.html
"A file lock can't guarantee synchronization between threads of the
Am Dienstag, 19. November 2013 um 21:06:21, schrieb Georg Baum
> Kornel Benko wrote:
>
> > Trying to lock with
> > open(lock_file.c_str(), O_CREAT|O_EXCL|O_SYNC|O_RDWR, 0666);
> > seams to work here. So no fcntl anymore.
>
> This is not portable either.
>
I know. Scott and I are testing with
Kornel Benko wrote:
> Trying to lock with
> open(lock_file.c_str(), O_CREAT|O_EXCL|O_SYNC|O_RDWR, 0666);
> seams to work here. So no fcntl anymore.
This is not portable either.
Georg
Am Montag, 18. November 2013 um 23:01:49, schrieb Kornel Benko
> Am Montag, 18. November 2013 um 22:29:05, schrieb Kornel Benko
>
> > Am Montag, 18. November 2013 um 21:55:48, schrieb Georg Baum
> >
> > > Kornel Benko wrote:
> > >
> > > > Actually, good idea. Stupid me, I didn't think of it.
Am Montag, 18. November 2013 um 22:29:05, schrieb Kornel Benko
> Am Montag, 18. November 2013 um 21:55:48, schrieb Georg Baum
>
> > Kornel Benko wrote:
> >
> > > Actually, good idea. Stupid me, I didn't think of it.
> > > Still the question stays: Is it portable enough?
> >
> > What exactly do
Am Montag, 18. November 2013 um 21:55:48, schrieb Georg Baum
> Kornel Benko wrote:
>
> > Actually, good idea. Stupid me, I didn't think of it.
> > Still the question stays: Is it portable enough?
>
> What exactly do you mean? Using a file for locking works fine on every OS
> relevant for LyX.
Kornel Benko wrote:
> Actually, good idea. Stupid me, I didn't think of it.
> Still the question stays: Is it portable enough?
What exactly do you mean? Using a file for locking works fine on every OS
relevant for LyX. fnctl/flock is not portable, the actual locking mechanism
needs to be OS dep
Am Montag, 18. November 2013 um 21:27:58, schrieb Georg Baum
> Kornel Benko wrote:
>
> > Hi,
> > can we please have some locking mechanism here?
>
> This would indeed be a good idea.
>
> > While parallel export testing is OK, if the userdir is configured,
> > it is not if started with a fresh
Kornel Benko wrote:
> Hi,
> can we please have some locking mechanism here?
This would indeed be a good idea.
> While parallel export testing is OK, if the userdir is configured,
> it is not if started with a fresh created userdir.
>
> I have a patch implementing it. While this works for me, I
Hi,
can we please have some locking mechanism here?
While parallel export testing is OK, if the userdir is configured,
it is not if started with a fresh created userdir.
I have a patch implementing it. While this works for me, I am unsure,
if this is the right c++ way, or if this is platform inde
41 matches
Mail list logo
