Re: Apache Portable Runtime

[Peter Odding <xolox@...>]

Mike Pall:
> Ick, please no. If anyone absolutely needs microsecond precision
> timing, then the last thing they need is one object allocation
> per query (taking quite a few microseconds ...).  :-)
Good point. The library will use plain numbers. I can add the boxed date 
implementation separately.

> Avoid falling into the BDUF trap.
Thanks for the advice. Hadn't seen `BDUF' before.. For now my plan is to write a 
library high level enough to be safe and fit the style of Lua but low level 
enough to be useful for most things APR is capable of (once I've finished 
binding the useful modules).

Rici Lake:
> The point of using a language like Lua, in my opinion, is: ease of use,
> avoidance of bugs, and rapidity of development. Fast execution is way down the
> list (my list, anyway). So a good interface, in my view, should promote those
> virtues, and only then try to do so as efficiently as possible.
I agree that a good interface is more important than speed. However I'm also 
considering that one can create a high level interface from a low level one but 
not (always) vice versa (see BDUF above :-).

Thanks for the performance comparison. I should know not to optimize before 
actual benchmarking; I get carried away sometimes :P. When I see hardware -> 
operating system -> apache portable runtime -> lua-apr -> lua, I worry about the 
many layers of abstraction. For example a lot of APR functions use memory pools 
for strings but Lua also uses interned strings, which means every string exists 
twice in memory. I guess this is the price to pay for portability and safe API's.

> Mike's suggestion is not bad, but it will prove to be awkward when you want to
> save the entire stat structure, in which case a table will prove to have been
> better.
Mike's suggestion contained three calls of which the first returns a table with 
string keys. Did you miss that one or are you referring to something else?

I've rewritten the stat binding to follow the interface Mike suggested. When 
multiple values are returned unavailable values are nil to preserve the order. 
I've also added the function apr.lstat, which doesn't follow symlinks (apr.stat 
with a boolean true upvalue to distinguish the calls).

Roberto Ierusalimschy:
> Maybe you may want to add yet another option:
> Explicit table given: return that table with all (named) properties.
> ...
Following your suggestion I added this option. On second thought however the 
interface Mike suggested seems flexible enough so I've removed this option 
again. Otherwise the manual entry would get rather long and confusing.

Luiz Henrique de Figueiredo:
>> Explicit table given: return that table with all (named) properties.
>
> This is implemented in the version of lposix that I've posted here. Here is
> the relevant code:
> ...
The function pointer argument to doselection confused me at first because I only 
saw it used with one value ~:). After looking through the lposix source I see 
you've made good use of this code. I'll try to do the same. Thanks!

 - Peter

PS. Sorry for the late reply; I'm doing a 5 month internship, I leave the house 
at 6:45 in the morning and return between 19:00 and 20:30. And then there's 
still the stuff I need to do for college :-\. Currently I work on Lua-APR mostly 
in the weekends :-)