Angus Leeming wrote:
> Thanks, Jürgen. Are you sure that you need to add the #include to the .h
> file?
No.
> Does the attached not work?
Yes, it works.
Jürgen
Angus Leeming wrote:
> Thanks, Jürgen. Are you sure that you need to add the #include to the .h
> file? Does the attached not work?
I had the same problem, and this fix works for me.
Georg
de
+#include
#include
#include
-#include
+#if ! defined (_WIN32)
+# include
+#endif
#include
#include
Index: src/support/forkedcontr.C
=======
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/forkedcontr.C,v
retrievi
Juergen Spitzmueller wrote:
> I get (on Linux):
>
> filetools.C: In function `const lyx::support::cmd_ret
> lyx::support::RunCommand(const std::string&)':
> filetools.C:1065: error: `sigemptyset' undeclared (first use this function)
> filetools.C:1065: error: (Each undeclared identifier is repor
edcontr.lo -MD -MP -MF .deps/forkedcontr.Tpo -c
> ../../../lyx/src/support/forkedcontr.C -o forkedcontr.o
> ../../../lyx/src/support/forkedcontr.C:33: error: `signal' not declared
> make[5]: *** [forkedcontr.lo] Error 1
I get (on Linux):
filetools.C: In function `const lyx::support::cmd
../../../lyx/src/support/forkedcontr.C -o forkedcontr.o
../../../lyx/src/support/forkedcontr.C:33: error: `signal' not declared
make[5]: *** [forkedcontr.lo] Error 1
-02-25 Alfredo Braunstein <[EMAIL PROTECTED]>
+ * forkedcontr.C (timer): remove bogus continue
+
+2003-02-25 Alfredo Braunstein <[EMAIL PROTECTED]>
+
* forkedcallqueue.[Ch]: added
2003-02-25 Alfredo Braunstein <[EMAIL PROTECTED]>
In
On Tue, Feb 25, 2003 at 06:25:11PM +0100, Alfredo Braunstein wrote:
> I have still two mid-sized patches : The first one to add the sequential
> background loader, the second one to eliminate the Bufferview from
> GraphicsLoader and friends which is not used anymore. (including
> Loader::startLoa
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
>> Alfredo Braunstein wrote:
>>
>>> Angus, I think you should change the continue into a break, otherwise
>>> you won't 'move on' at all ;).
>>
>> Not a break of course, I think we have only to eliminate the continue...
>> Should I make a patch
Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
>> Angus, I think you should change the continue into a break, otherwise you
>> won't 'move on' at all ;).
>
> Not a break of course, I think we have only to eliminate the continue...
> Should I make a patch?
Yes please. You are obviously
Alfredo Braunstein wrote:
> Angus, I think you should change the continue into a break, otherwise you
> won't 'move on' at all ;).
Not a break of course, I think we have only to eliminate the continue...
Should I make a patch?
ALfredo
Angus, I think you should change the continue into a break, otherwise you
won't 'move on' at all ;).
remove_it = true;
} else if (waitrpid == 0) {
// Still running. Move on to the next child.
continue;
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> No, I like your way. I just like explanations too. I'll make the change.
>
> Sorry if I was rude. I have searched this bug for a while. (it keeped
> giving me "Timeout::start: already running" while loading images, and I
> was convinced that
Angus Leeming wrote:
> No, I like your way. I just like explanations too. I'll make the change.
Sorry if I was rude. I have searched this bug for a while. (it keeped giving
me "Timeout::start: already running" while loading images, and I was
convinced that it was LoaderQueue's timer: I have had t
Alfredo Braunstein wrote:
> The problem is not the erase in timer(), but the erase in kill().
>
> If want to do it this way, I think you will have to modify the kill()
> method, making not to erase elements of the list, but to put them to zero.
>
> Or... why you don't like my way? Efficiency?
No
Hi Angus,
Angus Leeming wrote:
> Ooo, that's devious. In that case I think we really need a two pass
> algorithm:
>
> ListType::iterator it = forkedCalls.begin();
> ListType::iterator end = forkedCalls.end();
> for (; it != end; ++it) {
> bool remove_
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> I don't see the bug. You return to the start of the list, I move to the
>> next itme in the list. The 'prev' stuff is safe if ugly, as I understand
>> list.
>
> Sorry, I was away.
> What if for instance, *prev has dissapeared in the time bein
Angus Leeming wrote:
> I don't see the bug. You return to the start of the list, I move to the
> next itme in the list. The 'prev' stuff is safe if ugly, as I understand
> list.
Sorry, I was away.
What if for instance, *prev has dissapeared in the time being? (because of
multiple calls to kill()
On Tue, Feb 25, 2003 at 12:10:29PM +, Angus Leeming wrote:
> while (it != end) {
this is what I always do. It's a bit ugly, but I'm not all sure your
code before is strictly allowed ...
john
John Levon wrote:
> On Tue, Feb 25, 2003 at 11:33:07AM +, Angus Leeming wrote:
>
>> > - ListType::iterator prev = it;
>> > - --prev;
>> > forkedCalls.erase(it);
>> > - it = prev;
>>
>> I don't see the bu
On Tue, Feb 25, 2003 at 11:33:07AM +, Angus Leeming wrote:
> > - ListType::iterator prev = it;
> > - --prev;
> > forkedCalls.erase(it);
> > - it = prev;
>
> I don't see the bug. You return to the start of
Alfredo Braunstein wrote:
> I've added the explanation in a comment.
>
> --- forkedcontr.C 2003/02/13 16:53:14 1.7
> +++ forkedcontr.C 2003/02/25 10:26:02
> @@ -130,19 +130,19 @@
> }
>
> if (remove_it) {
> -
I've added the explanation in a comment.
--- forkedcontr.C 2003/02/13 16:53:14 1.7
+++ forkedcontr.C 2003/02/25 10:26:02
@@ -130,19 +130,19 @@
}
if (remove_it) {
- // Emit signal and remove the item from the
23 matches
Mail list logo
