I believe Platforms that have no one around to support should be
removed (svn history will always be there, and they can always be
rebuilt). In APR especially the operating systems with different
implementations, I would prefer to just remove them if no one wants to
keep things up in sync.
A quick status update:
1. the trunk should build using the autoconf-based buildsystem;
buildconf, configure, make as normal. Bug reports about problems there
are welcome (send them to the list).
2. the new pool implementation seems to basically work (as in, passes
the test suite), but we're
Thanks to everyone for suggesting the solutions,
I tried, as proposed by various users and developers in response to my
query, using the -Ipath of apr-$installedversion-config. That too did not
work. Finally I managed to serve my purpose using gcc command, executing
apr-$installedversion-config
Paul Querna wrote:
I believe Platforms that have no one around to support should be
removed (svn history will always be there, and they can always be
rebuilt). In APR especially the operating systems with different
implementations, I would prefer to just remove them if no one wants to
keep
On 26 Mar 2009, at 10:03, Paul Querna wrote:
I believe Platforms that have no one around to support should be
removed (svn history will always be there, and they can always be
rebuilt). In APR especially the operating systems with different
implementations, I would prefer to just remove them
On Thu, Mar 26, 2009 at 6:03 AM, Paul Querna p...@querna.org wrote:
Please respond with the Platforms you as a /developer/ are willing to
support in APR-2.x.
Supporting os390 here.
--
Eric Covener
cove...@gmail.com
Just did some quick bench of the current trunk,
and the results are not very much encouraging.
static void test_performance(abts_case *tc, void *data)
{
apr_status_t rv;
int i;
void *m;
apr_time_t end, now = apr_time_now();
for (i = 0; i 100; i++) {
apr_pool_t
Mladen Turk wrote:
Just did some quick bench of the current trunk,
and the results are not very much encouraging.
Inner loops are even worse.
Calling 1 x 32 bytes allocations
is more then 10 times slower.
This takes less then a second on my box to finish
with apr 1.4 and 11 seconds with
On Thu, Mar 26, 2009 at 11:03 AM, Paul Querna p...@querna.org wrote:
I am personally willing to develop for:
- FreeBSD = 7.0-release
Mac OS X 10.5+. -- justin
Paul Querna wrote:
I believe Platforms that have no one around to support should be
removed (svn history will always be there, and they can always be
rebuilt). In APR especially the operating systems with different
implementations, I would prefer to just remove them if no one wants to
keep
Attached is a program that you can use for this.
please upgrade to trunk, i've eliminated some callocs, and switched
them to malloc where possible.
compile with:
gcc -o pspeed13 `apr-1-config --link-ld --cppflags--cflags
--includes--ldflags--libs ` poolspeed.c
poolspeed.c
Hi,
As specified in http://apr.apache.org/projects.html, I am writing to see my
project listed as using APR.
The project is named managelogs. The URL is http://managelogs.tekwire.net. It
is a log processing program to be used as an alternative to rotatelogs. It
provides a number of new
OSX 10.5.6 (MBP, Intel Core 2 2.8 Ghz):
APR 1.3: 66583433
APR 2.0: 211770082 (+318%)
FreeBSD 7.1-STABLE (amd opterons; people.apache.org):
APR 1.3: 242582048
APR 2.0: 537562071 (+221%)
Solaris 10 (sparc t2000; eos.apache.org):
APR 1.3: 425809665
APR 2.0: 1344579431 (+315%)
I'd be interested in
Paul Querna wrote:
Attached is a program that you can use for this.
please upgrade to trunk, i've eliminated some callocs, and switched
them to malloc where possible.
compile with:
gcc -o pspeed13 `apr-1-config --link-ld --cppflags--cflags
--includes--ldflags--libs `
Paul Querna wrote:
Attached is a program that you can use for this.
please upgrade to trunk, i've eliminated some callocs, and switched
them to malloc where possible.
compile with:
gcc -o pspeed13 `apr-1-config --link-ld --cppflags--cflags
--includes--ldflags--libs `
Paul, did you actually mean to collect votes for various UNIX platforms, or
to deprecated things like Netware, BeOS, and OS/2?
As you likely know, maintaining support for, say, Solaris 8 is probably
about as hard as maintaining support for AIX and sure shouldn't be disabled
were that the case.
On Thu, Mar 26, 2009 at 3:12 PM, Wes Garland w...@page.ca wrote:
Paul, did you actually mean to collect votes for various UNIX platforms, or
to deprecated things like Netware, BeOS, and OS/2?
Yes, in the end I wanted to see if anyone actually cares about
Netware, BeOS, or OS/2.
I suspect the
FreeBSD 7.1-STABLE (amd opterons; people.apache.org):
APR 1.3: 242582048
APR 2.0: 537562071 (+221%)
Same FreeBSD 7.1 machine, using tcmalloc[1]
APR 1.3: 243307182
APR 2.0: 214131712 (-22%)
I think we should consider bundling tcmalloc, or making it a compile
time option.
This shows that many
On Thu, Mar 26, 2009 at 11:03 AM, Paul Querna p...@querna.org wrote:
I believe Platforms that have no one around to support should be
removed (svn history will always be there, and they can always be
rebuilt). In APR especially the operating systems with different
implementations, I would
Hi,
I've got Cygwin's libapr1 1.3.3-1
I've built Ganglia (3.1.0) from source and it works.
I then modify this line of code in gmond.c, adding the flag
APR_POLLSET_THREADSAFE:
apr_pollset_create(listen_channels, total_listen_channels,
global_context, APR_POLLSET_THREADSAFE);
Now, after
On Thu, Mar 26, 2009 at 03:10:56PM +0100, Mladen Turk wrote:
What's the point?
The null hypothesis is: modern malloc implementations do exactly the
same optimisation work (e.g. maintaining freelists) that we duplicate in
APR pools. By avoiding that duplication, and relying on malloc
Paul Querna wrote:
FreeBSD 7.1-STABLE (amd opterons; people.apache.org):
APR 1.3: 242582048
APR 2.0: 537562071 (+221%)
Same FreeBSD 7.1 machine, using tcmalloc[1]
APR 1.3: 243307182
APR 2.0: 214131712 (-22%)
I think we should consider bundling tcmalloc, or making it a compile
time
Joe Orton wrote:
On Thu, Mar 26, 2009 at 03:10:56PM +0100, Mladen Turk wrote:
What's the point?
The null hypothesis is: modern malloc implementations do exactly the
same optimisation work (e.g. maintaining freelists) that we duplicate in
APR pools. By avoiding that duplication, and relying
Joe Orton wrote:
On Thu, Mar 26, 2009 at 03:10:56PM +0100, Mladen Turk wrote:
What's the point?
The null hypothesis is: modern malloc implementations do exactly the
same optimisation work (e.g. maintaining freelists) that we duplicate in
APR pools. By avoiding that duplication,
On Thu, Mar 26, 2009 at 6:05 PM, Branko Čibej br...@xbc.nu wrote:
Paul Querna wrote:
FreeBSD 7.1-STABLE (amd opterons; people.apache.org):
APR 1.3: 242582048
APR 2.0: 537562071 (+221%)
Same FreeBSD 7.1 machine, using tcmalloc[1]
APR 1.3: 243307182
APR 2.0: 214131712 (-22%)
I think we
Paul Querna wrote:
On Thu, Mar 26, 2009 at 6:05 PM, Branko Čibej br...@xbc.nu wrote:
We have JNI bindings for Subversion, which uses APR, whose packaging and
compilation options we don't control. *boom*
That is only talking about loading tcmalloc using the normal library.
you can compile
On Thu, Mar 26, 2009 at 3:54 PM, daniel.poc...@barclayscapital.com wrote:
I've got Cygwin's libapr1 1.3.3-1
I've built Ganglia (3.1.0) from source and it works.
I then modify this line of code in gmond.c, adding the flag
APR_POLLSET_THREADSAFE:
apr_pollset_create(listen_channels,
APR_POLLSET_THREADSAFE isn't supported with all
implementations. I expect that apr_pollset_create() is
returning APR_ENOTIMPL, and the crash is due to an
uninitialized pollset.
Excellent point - I should have checked for a return code, there are a
few cases like this in Ganglia where the
On Thu, Mar 26, 2009 at 8:24 PM, daniel.poc...@barclayscapital.com wrote:
APR_POLLSET_THREADSAFE isn't supported with all
implementations. I expect that apr_pollset_create() is
returning APR_ENOTIMPL, and the crash is due to an
uninitialized pollset.
Excellent point - I should have
I've now added this check, and apr_pollset_create is returning
APR_SUCCESS
The seg fault only occurs after the first socket is added to the
pollset, maybe there is another place where return
codes are ignored?
Hmmm... I see that poll() or select()-based
Paul Querna wrote:
On Thu, Mar 26, 2009 at 6:05 PM, Branko Čibej br...@xbc.nu wrote:
Paul Querna wrote:
FreeBSD 7.1-STABLE (amd opterons; people.apache.org):
APR 1.3: 242582048
APR 2.0: 537562071 (+221%)
Same FreeBSD 7.1 machine, using tcmalloc[1]
APR 1.3: 243307182
Well thnx guys...
I tried, as proposed by various users and developers in response to my
query, using the -Ipath of apr-$installedversion-config. That too did not
work. Finally I managed to serve my purpose using gcc command, executing
apr-$installedversion-config file (ie apr-1-config
On Thu, 2009-03-26 at 21:32 +0100, Branko Čibej wrote:
Maybe it's just me, but all that seems like a monumental waste of
time.
I don't really have the right to comment here, because I put zero effort
into this, but it does look that way, doesn't it?
On the other hand, there are patches that
On Thu, 2009-03-26 at 13:09 +0100, LAUPRETRE François (P) wrote:
The project is named managelogs. The URL is
http://managelogs.tekwire.net.
It's been added to the open source section. It should appear shortly. If
something is not correct, let me know and I'll fix.
Thank you for you submission!
2009/3/26 Branko Čibej br...@xbc.nu:
Maybe it's just me, but all that seems like a monumental waste of time.
If we can't beat the old system by COB tomorrow consistently, then I
think we can simply revert it or we add tcmalloc as a compile-time
option if it's not too complex to use that. Either
35 matches
Mail list logo
