We forgot to discuss this at the last telecon - GP, would you please ensure it
is on next week's agenda?
FWIW: I agree that this should not have been committed. We need to stop doing
local patches to public packages and instead focus on getting them into the
upstream (which has still not been c
Not that I can find.
-Nathan
From: devel-boun...@open-mpi.org [devel-boun...@open-mpi.org] on behalf of Jeff
Squyres [jsquy...@cisco.com]
Sent: Tuesday, May 01, 2012 7:29 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] libevent socket code
Is there
> probably never will). The other two may be a little trickier to fix.
>>
>> -Nathan
>>
>> Excuse the terribly reply format. OWA sucks.
>>
>> From: devel-boun...@open-mpi.org [devel-boun...@open-mpi.org] on behalf of
>&
[devel-boun...@open-mpi.org] on behalf of
> Ralph Castain [r...@open-mpi.org]
> Sent: Monday, April 30, 2012 2:55 PM
> To: Open MPI Developers
> Subject: Re: [OMPI devel] libevent socket code
>
> Can you send me a copy of the warnings, or tell me which machine at LANL is
[devel-boun...@open-mpi.org] on behalf of
Ralph Castain [r...@open-mpi.org]
Sent: Monday, April 30, 2012 2:55 PM
To: Open MPI Developers
Subject: Re: [OMPI devel] libevent socket code
Can you send me a copy of the warnings, or tell me which machine at LANL is
generating them? I'm working on
Can you send me a copy of the warnings, or tell me which machine at LANL is
generating them? I'm working on libevent now (found a bug they are helping
with) and can take a look at it.
On Apr 25, 2012, at 11:05 AM, Nathan Hjelm wrote:
> Let me take a look. The code in question is in evutil.c an
Let me take a look. The code in question is in evutil.c and bufferevent_sock.c
. If there is no option we might be able to get away with just removing these
files from the Makefile.am.
-Nathan
On Wed, 25 Apr 2012, Jeff Squyres wrote:
On Apr 25, 2012, at 12:50 PM, Ralph Castain wrote:
Can't
On Apr 25, 2012, at 12:50 PM, Ralph Castain wrote:
> Can't it be done with configuring --without-libevent-sockets or some such
> thing? I really hate munging the code directly as it creates lots of support
> issues and makes it harder to upgrade.
If there's a libevent configure option we should
Can't it be done with configuring --without-libevent-sockets or some such
thing? I really hate munging the code directly as it creates lots of support
issues and makes it harder to upgrade.
On Apr 25, 2012, at 10:45 AM, Nathan Hjelm wrote:
> Anyone object if I #if 0 out all the socket code in
/jsquyres appreciates phargroves debugging mojo
On Feb 15, 2012, at 5:17 PM, Paul H. Hargrove wrote:
> The following 1-line change resolves the problem for me, and I see no
> potential down-side to it:
>
> --- openmpi-1.7a1r25927/opal/mca/event/libevent2013/libevent2013_module.c~
> 2012
Thanks, Ralph.
Your commit missed the nightly tarball, but the configure logic to
exclude the rank_file component was in there.
So, I dropped the new libevent2013_module.c into tonight's tarball
(1.7a1r25937).
My build configured --without-hwloc now PASSes "make all install check
clean".
And
Thanks Paul. I modified the patch a bit to silence some warnings, but added
it to the trunk.
On Wed, Feb 15, 2012 at 2:17 PM, Paul H. Hargrove wrote:
> The following 1-line change resolves the problem for me, and I see no
> potential down-side to it:
>
> --- openmpi-1.7a1r25927/opal/mca/**event/
The following 1-line change resolves the problem for me, and I see no
potential down-side to it:
---
openmpi-1.7a1r25927/opal/mca/event/libevent2013/libevent2013_module.c~
2012-02-15 14:11:22.274734667 -0800
+++
openmpi-1.7a1r25927/opal/mca/event/libevent2013/libevent2013_module.c
Looks good, thanks!
Brian
On 7/14/11 1:12 AM, "Ralph Castain" wrote:
>Should be fixed in r24902 - let me know.
>
>
>On Jul 12, 2011, at 4:30 PM, Barrett, Brian W wrote:
>
>> On 7/12/11 4:21 PM, "Ralph Castain" wrote:
>>
>>> On Jul 12, 2011, at 12:29 PM, Barrett, Brian W wrote:
>>>
On 7/
Should be fixed in r24902 - let me know.
On Jul 12, 2011, at 4:30 PM, Barrett, Brian W wrote:
> On 7/12/11 4:21 PM, "Ralph Castain" wrote:
>
>> On Jul 12, 2011, at 12:29 PM, Barrett, Brian W wrote:
>>
>>> On 7/11/11 4:31 PM, "Ralph Castain" wrote:
>>>
On Jul 11, 2011, at 2:51 PM, Barre
On 7/12/11 4:21 PM, "Ralph Castain" wrote:
>On Jul 12, 2011, at 12:29 PM, Barrett, Brian W wrote:
>
>> On 7/11/11 4:31 PM, "Ralph Castain" wrote:
>>
>>> On Jul 11, 2011, at 2:51 PM, Barrett, Brian W wrote:
>>>
Hi all -
When libevent was made its own component last fall, it appe
On Jul 12, 2011, at 12:29 PM, Barrett, Brian W wrote:
> On 7/11/11 4:31 PM, "Ralph Castain" wrote:
>
>> On Jul 11, 2011, at 2:51 PM, Barrett, Brian W wrote:
>>
>>> Hi all -
>>>
>>> When libevent was made its own component last fall, it appears that the
>>> function renames and visibility set
On 7/11/11 4:31 PM, "Ralph Castain" wrote:
>On Jul 11, 2011, at 2:51 PM, Barrett, Brian W wrote:
>
>> Hi all -
>>
>> When libevent was made its own component last fall, it appears that the
>> function renames and visibility settings were lost. This is proving
>> rather problematic for a projec
On Jul 11, 2011, at 2:51 PM, Barrett, Brian W wrote:
> Hi all -
>
> When libevent was made its own component last fall, it appears that the
> function renames and visibility settings were lost. This is proving
> rather problematic for a project I'm trying to get running with the trunk
> which
Okay, we seem to have this fixed finally. I've confirmed that the libevent 2.0
upgrade is working. Jeff and I plan to do some further cleanup of the configure
integration, but that will be transparent to operations.
So please check the system out:
http:/bitbucket.org/rhc/ompi-lib2
and let me k
Hold off on this a little. I discovered a problem with the stupid build system
again that is causing libevent to try and install when it shouldn't. Afraid
I'll have to wait for help from the "build guru" when he returns.
I'll update you when the build system allows us to continue.
Ralph
On Sep
George,
I made some tests with the libevent but probably I´m doing something
wrong... because it does not work.
struct timeval time;
opal_event_t *ev;
ev = (opal_event_t*)malloc(sizeof(opal_event_t));
opal_evtimer_set(ev, my_func, NULL);
time.tv_sec = 10;
time.tv_usec = 0;
opal_evtimer_add(ev
Leonardo,
All events generated by the libevent are catched internally by the
ompi library, but are not propagated until the next call to
opal_progress. If you want to use alarms that trigger outside the
opal_progress you will have to deal directly with the libevent (and
not use ORTE_TIMER
23 matches
Mail list logo
