APR 1.0.0 Goes Gold 111
cliffwoolley writes "After several years of development, the Apache Portable Runtime, which is the portability library underlying the Apache HTTP Server 2.x, has finally reached its own 1.0.0 release. If you want to write a portable app without the headaches, APR is the way to do it. Grab a copy and check it out. The full announcement is here."
Re:first post (Score:1)
It is the first post.
It has "first post" as subject.
The only content in the post is "first post"
I think that qualifies as redundant.
Re:first post (Score:1)
Re:Yes, but... (Score:1)
Re:I've been using for some time now (Score:3, Informative)
So APR was designed to work in servers: it has support for memory pools, filesystems routines, network lacking in GLib. But GLib has support for GObjects, signals which are used heavily in GTK.
So if you're writing a portable server-side application in C/C++ then APR is for you.
PS: Subversion [tigris.org] (the great VCS) uses APR.
Re:I've been using for some time now (Score:2)
One thing APR is not good for is interaction with other compatibility frameworks: I've been hacking together a Ruby API for Subversion VCS and it's been a bit of a pain to integrate because of the memory allocation.
Re:I've been using for some time now (Score:2)
I am guesing APR is not just for someone who wants to write a custom quick webserver but also for appliances and devices. Most embedded hardware runs custom os's.
My guess is with APR we are going to see custom httpd's from everything to Atari's to old Newtons.
Re:I've been using for some time now (Score:2)
APR (Score:4, Interesting)
Re:APR (Score:5, Informative)
APR is for servers, SDL is for games.
Re:APR (Score:4, Informative)
Re:APR (Score:2, Informative)
Simple DirectMedia Layer supports Linux, Windows, BeOS, MacOS Classic, MacOS X, FreeBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. There is also code, but no official support, fo
Re:APR (Score:5, Insightful)
Re:APR (Score:5, Interesting)
NSPR (Netscape Portable Runtime) http://www.mozilla.org/projects/nspr/index.html [mozilla.org]
ACE (Adaptive Communication Environment http://www.cs.wustl.edu/~schmidt/ACE.html [wustl.edu]
wxWidgets http://www.wxwidgets.org [wxwidgets.org]
Those are just a few, there are others out there as well
Choosing one to use is a difficult exercise. The important things to consider are what you want to use it for and how it fits in with your existing software and experience.
If you'll be doing GUI programming, wxWidgets is a good way to go. In addition to the file io/threads/networking portability you get GUI portability as well. The NSPR fits into this area as well.
The APR is obviously a well tried and proven framework, since the Apache HTTP server uses it. If you want cross platform server software, APR is probably a good choice. NSPR fits in this area as well.
The biggest consideration when choosing one of these libraries is how well you can pick it up and understand it. If you look at the API and it doesn't make any sense to you, it won't be pleasant to integrate with it. Documentation varies in quantity and quality. Also, how well supported is the library by the development community?. (Actually not much of an issue for APR,NSPR and wxWidgets as they are all very actively maintained and used).
On another note, it certainly would be nice to get more of a standardized set of cross platform libraries on the scale of the Java API. There's no reason why this can't be done. Most of the pieces are already out there. It's too bad someone hasn't yet taken the effort to integrate all of this stuff into a super library for GUI, networking, io, threads, email, video, blah blah blah...
Perhaps I'll have to get started on that...Re:APR (Score:3, Funny)
Do you mean something like Java?
Re:APR (Score:3, Funny)
Super Library(Re:APR) (Score:2, Informative)
It's too bad someone hasn't yet taken the effort to integrate all of this stuff into a super library for GUI, networking, io, threads, email, video, blah blah blah...
---
Well, I and others have built HTTP servers using just the sockets provided in wxWidgets - and it's not that difficult.
As for email - you've got wxSMTP
http://www.frank-buss.de/wxwindows/
Also, one of the core developers wrote an entire cross-platform e-mail program with it
http://mahogany.sourceforge.net/
In addition, wxWidgets supports ev
Re:APR (Score:2, Informative)
Re:APR (Score:2)
Indeed. Important observation.
In addition most libraries impose a way of doing things that might not fit your application. In the C/C++-world this situation often arises. For instance you might want to use two libraries together, that both need to be in charge of thread- or signal handling etc, so you end up kludging together the bits you need and it never feels quite right.
Then, of
Re:APR (Score:1)
Re:APR (Score:3, Informative)
java-ish? (Score:4, Insightful)
This is competition for java?
Sorry... can somebody give me some insight on what this is?
Re:java-ish? (Score:5, Informative)
Re:java-ish? (Score:2)
Neat! (Score:1, Insightful)
Of course, it may also remain relatively obscure and unused. Given the attention they've paid to detail on it, that would be a shame, imho.
-Matt
It is NOT java! (Score:3, Informative)
Re:Neat! (Score:1)
I didn't suggest that it was a virtual machine. In fact, in my post, I clearly identified it as a 'compatibility layer', which is exactly what it is.
Doesn't anybody read anything on Slashdot before posting? Are the Slashdot forums just a bunch of people trying to post/mod/etc. as quickly as possible in a ridiculous attempt to collect karma?
*sigh*
-Matt
Re:Neat! (Score:2)
With few exceptions. You would wonder if they shouldent just code some fame to bring up the primary linked site with a 30 second timer before they can read or post to the forums.
Realy though all this java talk dosent make a whole lot of sence besides posiby for people that think everything should be java and never have had to write something on a memory constrained system or in assembly.
Re:Neat! (Score:1)
You would wonder if they shouldent just code some fame to bring up the primary linked site with a 30 second timer before they can read or post to the forums.
That would only make the Slashdot effect even worse.
Re:Neat! (Score:1)
Once again - initial knee-jerk thoughts were Apache/Web-centric, naturally there are a thousand million other applications that could benefit from such a library.
Trolls... dunno why I bother responding.
glib? (Score:3, Interesting)
Re:glib? (Score:5, Informative)
Re:glib? (Score:5, Informative)
APR is a library which, at its basic level, provides wrapper functions to syscalls of many different operating systems. Why? because the same syscall on one OS sometimes behaves differently, have bugs, or take slightly different arguments from the same syscall on other OSes.
APR addresses these differences and provides you, the app developer, with a common set of functions.
So if you're say coding your own FTP server project and you main development platform is linux or what have you, if you use APR's wrtite() or APR's sendfile(), you know that your call to that will also work on Solaris, FreeBSD, Darwin, etc... because APR takes care of all the abstraction at compile time.
Re:glib? (Score:4, Informative)
Re:glib? (Score:5, Interesting)
All true. But you didn't mention the other huge thing it does - pools. They're a completely different way of managing memory than other systems use. The Apache people would say they're higher-performance (more locality -> better cache behavior, big groups of stuff can be deallocated at once, etc.), less error-prone (fewer leaks), etc.
And then a bunch of pool-using code. Like string functions that replace the standard C strcpy() and such but return new pool-allocated strings rather than potentially overflowing a buffer.
Re:glib? (Score:1)
Re:glib? (Score:2)
Which license are you referring to? (Score:2)
If you meant a license the Free Software Foundation calls a "free software" license, then there's even more licenses to consider. All this raises the question: which license are you referring to?
apr_pool_t (Score:5, Interesting)
Does glib provide pools-based memory allocation for all its functions?
Somehow, I doubt they do. To me, a good pool-based allocator that handles *everything* is really, really, really freakin' handy. Not only is it cross-platform, but code tends to suffer from fewer memory-allocation-related defects (such as using freed pointers, leaking core, leaking descriptors, etc).
Of course, you have to design your code properly from the outset to take full advantage of hierarchical pools. Apache 1.3 (and presumably 2.x -- I haven't studied the source) are *excellent* examples of code designed to take advantage of pools, and the HTTP request model is almost naturally suited for it as well. Write a few complex modules in C some time, you'll see what I mean.
Now, if only I could could figure out why the APR hash functions are so slow for large tables..
Re:apr_pool_t (Score:1)
Re:apr_pool_t (Score:1)
I see APR as a dupe, the same as NSPR or non-graphical part of Qt.
They at least try to provide some generic portability/utility layer, most of the projects just reimplement it always from the scratch for themselves.
Your "Not only is it cross-platform, but code tends to suffer from fewer
Pools have problems (was Re:apr_pool_t) (Score:5, Interesting)
I wrote a paper about this, and problems with custom (special-purpose) memory allocators in general, called Reconsidering Custom Memory Allocation [umass.edu] (OOPSLA 2002). In it, I also describe a new memory allocation scheme, called reaps . This is a hybrid of regions (pools) and heaps that acts just like pools except you can still free individual objects.
In fact, for a case study, I put reaps into Apache (adding a ap_pfree call), and showed how using reaps made it simple to incorporate a piece of existing C code (namely, bc) into Apache. Without reaps, an invocation consumed 7.4MB of memory (since every free had to be disabled). With reaps, 240KB.
I did send a message to the Apache folks about this a while back, but they balked because the implementation is in C++, rather than C (developed with my Heap Layers [umass.edu] infrastructure)...
-- emery
Emery Berger [umass.edu]
Assistant Professor
Dept. of Computer Science
University of Massachusetts, Amherst
Re:Pools have problems (was Re:apr_pool_t) (Score:1)
While I understand your complaint, there are a *LOT* of projects with this exact same stance. All code must be written in C. Trying to get them to implement code that will lower their audience (not to mention considering some of the new 'differences' in C/C++ syntax in gcc 3.4+ suddenly dropping a piece of C++ code in not only forces users to have a C++ compiler handy, but also might force developers who are used to C syntax to find th
Re:apr_pool_t (Score:1)
P.S. Oh, they can be called hash tables, though with a hash function that returns the same value for all its keys ;-)
Re:apr_pool_t (Score:2)
Usefull... (Score:3, Interesting)
That is a vauge example, but I can see the use in this, and if it becomes common it will be trivial to move web apps between servers, upgrades, etc.
I like this, they aren't trying to give us a whole new language to use, but instead a tool to use with our other existing tricks and tools.
Also the quote on the botom of the page is quite appropriate, "My folks didn't come over on the Mayflower, but they were there to meet the boat."
Yipee! (Score:4, Interesting)
Re:Yipee! (Score:1)
You're missing that APR 1.0.0 is not compatible with APR 0.9.x.
So Subversion cannot upgrade to APR 1.0.0 without breaking binary compatibility, which the Subversion people have guaranteed not to do before Subversion 2.0.0.
Also, Subversion depends on the Apache web server, so it must use the same version of APR as the Apache web server. AFAIK the web server is still using APR 0.9.x.
Re:Yipee! (Score:4, Informative)
I.E. Subversion's compatability guarantees are only good to the degree that you don't go changing major versions of the libraries.
You are correct that Apache 2.0.x will continue using APR 0.9.x, but Apache 2.2.x (currently called 2.1.x) will use APR 1.0.0. If we enforce the major of APR we can only function with Apache 2.0.x, which is not a requirement we really want to limit ourselves to.
Re:Yipee! (Score:2)
While thinking about version numbers, I wonder what awaits us in APR 2.0? Most of the common portability concerns seemd to have been wrapped up pretty well in APR 1.0 (for the basic features Apache needed). What's left?
Some info on APR ... (Score:5, Informative)
First of all, APR is not a virtual machine or bytecode interpreter like that of .NET common language runtime or JVM. APR is a library (collection of functions) written in C, for C programs. It contains a lot of wrappers to the real standard C library functions, because some conventions of standard library still varies from OS to OS.
For example, the path separator is different in Unix ("/"), Windows ("\"), MacOS (":" - pre X, but also Finder in OS X). Another example is loading dynamically linked libraries (DSO in APR speech). Yet another example is threads.
Besides wrappers, APR has its own memory management routines. APR also adds utility functions not found in the standard library, such as hash table.
By the way, it would be helpful if someone can post a comparison between NSPR (netscape portable runtime) and APR.
Re:Some info on APR ... (Score:5, Informative)
I'm guessing by this stage that both the APR and NSPR are industrial strength libs to write cross-platforms against. Both have similar functionality because both underpin web servers (yes NSPR is used by the AOL/Sun iPlanet webserver, and not just Mozilla).
What it might boil down to in the end is which runtime's licence is most compatible with what you have in mind.
Re:Some info on APR ... (Score:3, Interesting)
Re:Some info on APR ... (Score:2)
Re:Some info on APR ... (Score:2, Informative)
Re:Some info on APR ... (Score:2)
After Firefox 1.0, Mozilla should consider ditching NSPR for APR. The engineering and QA time spent on NSPR (which is pretty much done/frozen) can be redirected to APR. That work would benefit the open-source community, but Mozilla would also benefit from other people fixing bugs in APR.
GLib (Score:2)
Looking at the API it seems that GLib is a bit easier to use, while APR has some features that may lead to better performance, in particular memory pools (GLib does not have it, so all memory allocation are done by malloc(), saving a parameter but also losing a little flexibility).
Both are quite complete; but f
Re:Did they just say? (Score:4, Informative)
apr-0.9.4_9
The Apache Group's Portability Library
Maintained by: rodrigc@crodrigues.org
Requires: autoconf-2.59_2, automake-1.8.5_2, expat-1.95.8, gettext-0.13.1_1, gmake-3.80_2, libiconv-1.9.2_1, libtool-1.5.8, m4-1.4.1, perl-5.8.5
Multi-threading isn't that simple (Score:5, Interesting)
Also, doing condvars on windows isn't that easy as Douglas Schmidt writes up here [wustl.edu].
Writing portable thread libraries seems to be a popular activity. It would be nice if the authors of those packages documented that they were aware of the issues as a first step in convincing those of us who know about those issues that they know what they are doing. Yeah, I know that the Apache authors are considered experts, but it wouldn't be the first time some rather well known experts got tripped up on multi-threading.
Follow up - I took a quick look at the source. (Score:5, Insightful)
For the win32 version of condvar, I don't think a win32 Event isn't going to hack it. The current logic allows a condvar to remain signaled until the all waiters have woken up and have decremented the use count to zero. This could lead to a lot of spurious wakeups if some waiting thread takes it time to wake up. The APR authors need to read that Schmidt document I mentioned earlier and maybe also look at Schmidt's ACE project [wustl.edu] and see how he did it.
This is not a comprehensive critique as I only took a cursory look but what I did see indicates that APR needs some more work.
Re:Follow up - I took a quick look at the source. (Score:2)
Dropping a link to Schmidt's work in there might not be a bad means of stealth education, either.
Re:Follow up - I took a quick look at the source. (Score:3, Insightful)
I don't know enough in this field to help, but if somone sent me some details on any project I'm working on which allows me to improve it, I'd be greatful, though not likely to give you pizza tokens
Re:Follow up - I took a quick look at the source. (Score:1)
Interested, but confused by Apache License 2.0 (Score:4, Interesting)
If I *statically* link to the APR in a commercial software product, what are the consequences? Especially when the commercial software is distributed in binary form only.
http://www.apache.org/licenses/LICENSE-2.0
Re:Interested, but confused by Apache License 2.0 (Score:4, Informative)
By my reading of the liscence, it makes absolutly no distinction between static and dynamic linking. Therefore, the only way that it could cause a difference is within the definition of a 'derived work'. To quote the licence:
If you link, or bind by name, to the interfaces of the Work, then your code is not a derived work. Thus, the only applicable terms in the licence are those that govern use and distribution of the code. The licence grants you the right to distribute in source or object form the work.
Accordingly, my reading is that this is semantically virtually equivlent to the BSD licence for case specified (and, in fact, the same as BSD for pretty much any case of use and distribution).
Short answer: Stick a mention of it in the NOTICE text file, tell people what liscene the Work (in this case the APR) was under, and go ahead.
Interestingly, this licence would, as I read it, allow you to make a derived work, and redistribute that in binary form only. It doesn't grant you the right to change liscence, or apply restrictions, so a Derived Work wouldn't work as a commerical product (as the first purachaser can redisribute it).
But, as it specifically excludes linking to the interfeces specified, then for a Work which is a library [0], the only clause that imparts any restriction is 4(d) [1]
In fact, I can see no part of the liscence that would prevent one from taking a program under this liscence, creating a Derived Work that is that program implemented as a library, with well defined interfaces, and then linking to said library from a commercial/closed program. There is no requirement to publish Derived Works [2]. The only mildly non-obvious outcome is that if the library was extracted from the final disribution, the licence allows for its free distribution and use, which is not a restriction.
Of course, if this is for commerical software, you'll have the money to speak to a lawyer licence to practice in your juristriction first.
[0] And where that library is used unmodified
[1] And the expiration of patent licences in event of you issuing a patent suit.
[2] Only that you make any changes clear if you do publish.
Yet another library for an obsolete language (Score:1, Troll)
Re:Yet another library for an obsolete language (Score:5, Informative)
There is alot of anti c++ sentiment in the unix community because of that.
Re:Yet another library for an obsolete language (Score:1, Insightful)
http://tinyurl.com/605v
Re:Yet another library for an obsolete language (Score:3, Interesting)
Re:Yet another library for an obsolete language (Score:2)
However many programs like the Linux kernal are hard coded for gnu specific features.
But for general coding its inexpensive and quite good.
Re:Yet another library for an obsolete language (Score:2)
I disagree; I think the current version is a fine C++ compiler. What's wrong with it?
Re:Yet another library for an obsolete language (Score:1)
Measure the execution time of a typical C++ program as compiled into an executable. It appears that Billly Gates and qbwiz claim that other vendors' proprietary C++ compilers have a much bigger speed gain over g++ than their C compilers have over gcc.
Re:Yet another library for an obsolete language (Score:2)
MS VC++ is a good one and so is watcom C++ and Borland.
None are ported to Unix.
IF you look at the resulted assembly code you will see many many unoptimized code that MS VC++ and Borland would optimize by default.
Re:Yet another library for an obsolete language (Score:2, Interesting)
A good C++ programmer wont use those things, just like a good C programmer wont do stupid stuff in C.
But C++ is not inherently safer than C, it's just as dangerous as C and has the added bonus of being complicated, unweildy and inconsistent.
Where every byte counts (Score:1)
there is no reason for new apps to be written in C.
By "new apps" do you mean this to include "new versions of g++" as well? If so, then how would you recommend bootstrapping a C++ compiler on a system with only GCC?
language features and the STL reduce the need for explicit dynamic memory allocation
To a developer who has to fit algorithms and data structures into a handheld computer's 32 KB of fast RAM when all other RAM in the system has horrible wait state behavior, every byte still counts. I've
Like Core Foundation? (Score:4, Interesting)
- Scott
Uses Apache license (Score:1)