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
https://github.com/open-mpi/ompi/pull/6784 went in while I was on vacation.
I'm a little confused; I thought we no longer patched libevent locally? This
is certainly going to be a problem as we move to external dependencies; we
won't have a way of pulling in this change (whether using the bund
Per the telecon today, I updated libevent to the 2.0.22-stable release as there
is a bug fix of a race condition when using event_active, which we use in a lot
of places.
Remember to "rm -rf opal/mca/event/libevent2021” after you pull the update as
the stale directory will remain.
Ralph
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
Anyone object if I #if 0 out all the socket code in libevent. We see lots of
static compilation warnings because of that code and nothing in openmpi uses it.
-Nathan
/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
Here is a bit more on this.
When I configure w/ only a --prefix and CFLAGS=-save-temps, I can
examine libevent2013_module.i which contains the following:
# 7 "../../../../../opal/mca/event/libevent2013/libevent2013_module.c" 2
# 1
"../../../../opal/mca/hwloc/hwloc132/hwloc/include/private/auto
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
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 uses libev (which provides a libevent compatibility layer). It
wor
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
Hi all
As mentioned on the telecons and in prior mails, I have been working on
updating the event library to libevent 2.0. While doing so, I have
significantly simplified the integration so that we can perform such updates
much quicker/easier in the future. Basically, it now requires simply unp
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
Hi All,
Does the libevent works with an application which does not communicate?
i.e. I have an application which does not receive or send messages for a
long time, but on the PML layer a have defined some event using the
ORTE_TIMER_EVENT(time, func) macro. This macro will be should be called
Per the RFC posted yesterday, we plan to merge in the new libevent
over this upcoming weekend. Please test the /tmp-public/libevent-
merge SVN branch!
For convenience, I have posted a tarball from this branch if it would
make it easier for you to test:
http://www.open-mpi.org/~jsquyre
FYI: since I was the one who stirred up the hornet's nest a while
ago :-), I thought I'd update everyone -- we're actually *not* going
to use libev anymore. We're simply going to update to a newer version
of libevent, which seems to have all the things that we care about
(better performanc
32 matches
Mail list logo
