Hi Jari,
- "Jari Häkkinen" a écrit :
> Great, I haven't had an opportunity to run the new version yet. I took
> time to compile though, and there is a problem compiling terrasync.cxx
> on mac because of Apples typedef of the signal handler. I attached a
> small fix.
Your mail remind me I ha
Great, I haven't had an opportunity to run the new version yet. I took
time to compile though, and there is a problem compiling terrasync.cxx
on mac because of Apples typedef of the signal handler. I attached a
small fix.
Jari
On 2/28/10 5:51 PM, Alex Perry wrote:
Attached patch replaces
Frederic Bouvier wrote:
> Anyway, I won't be able to commit anything until this evening (CET time).
No problem,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
Hi Martin,
- "Martin Spott" a écrit :
> I'm expieriencing difficulties to compile 'terrasync' after the
> latest
> patch. While PLIB's socket seems to be the target, the type "socket"
> interferes with the system headers:
>
> g++ -g -O3 -march=opteron -DHAVE_CONFIG_H -I. -I../../src/Include
I sent much the same thing in a patch to Fred. I suspect that he
didn't notice because it is called winsocket on Windows.
On Mon, Mar 1, 2010 at 2:38 AM, Martin Spott wrote:
> I'm expieriencing difficulties to compile 'terrasync' after the latest
> patch. While PLIB's socket seems to be the targ
ooops !
Martin Spott wrote:
> @@ -295,7 +295,7 @@
> write(1, msg, sizeof(msg) - 1);
> terminating = true;
> signal(param, prior_signal_handlers[param]);
> -socket.close();
> +netSsocket.close();
^^
Sorry,
Martin.
--
Unix _IS_ user friendly - it's jus
I'm expieriencing difficulties to compile 'terrasync' after the latest
patch. While PLIB's socket seems to be the target, the type "socket"
interferes with the system headers:
g++ -g -O3 -march=opteron -DHAVE_CONFIG_H -I. -I../../src/Include
-I/usr/include/subversion-1 -I/usr/include/apr-1.0 -
Alex,
Terrasync doesn't stop itself if nothing comes from the socket. I am
going to make it global and close it in the handler.
-Fred
Le 28/02/2010 17:51, Alex Perry a écrit :
> Attached patch replaces the stream with a single direct call to
> write() inside the signal handler; someone Windows b
On Sun, Feb 28, 2010 at 3:59 AM, Tim Moore wrote:
> Whoops, I'm a bit late with my comments, but all the same...
>
> You can't safely use C++ stream functions in a signal handler.
Drat, true. A simple write() would be fine, given what I'm using it for.
> Why does terrasync need to be protected
Attached patch replaces the stream with a single direct call to
write() inside the signal handler; someone Windows based might want to
give it a look before committing. I also removed references to std::
which are they're superfluous after "using namespace" directive at the
top.
On Sun, Feb 28, 2
Whoops, I'm a bit late with my comments, but all the same...
You can't safely use C++ stream functions in a signal handler.
Why does terrasync need to be protected from interruption like this? Does
the SVN update really get corrupted if it is interrupted?
Tim
On Sun, Feb 28, 2010 at 6:50 AM, Al
Commited. Thanks
-Fred
Le 28/02/2010 09:28, Alex Perry a écrit :
> Done. Also added the modified source file.
>
> On Sun, Feb 28, 2010 at 12:09 AM, Frederic Bouvier wrote:
>
>> Hi Alex,
>> Please resend this patch gzip and attached. I can't use it as it is.
>>
-
Done. Also added the modified source file.
On Sun, Feb 28, 2010 at 12:09 AM, Frederic Bouvier wrote:
> Hi Alex,
> Please resend this patch gzip and attached. I can't use it as it is.
>
> -Fred
>
>
> --
> Download Intel®
Hi Alex,
Please resend this patch gzip and attached. I can't use it as it is.
-Fred
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune a
14 matches
Mail list logo
