On 20 Apr 2024, at 11:38, Ivan Zhakov wrote:
> In APR 2.0 we merged APR-Util **project** to APR. Which is IMHO a good thing.
At the time, and with time and hindsight, I never understood what the point was
at combining APR and APR-util.
The reason is because...
> But we also merged everything
> On 20 Apr 2024, at 11:38, Ivan Zhakov wrote:
>
> Hi,
>
> In APR 2.0 we merged APR-Util **project** to APR. Which is IMHO a good thing.
Um, apr-util was a separate library, but not really a separate project.
The separation may have been a little OTT, but merging them runs into
"ain't
On 22 Apr 2024, at 12:52, Ivan Zhakov wrote:
>> The question is, is it worth it for such a marginal change?
>> Have you looked in to the practicalities and verified no major stumbling
>> blocks,
>> bearing in mind that developer effort tends to be thin on the ground?
>>
>
> Take the Apache
On Mon, 22 Apr 2024 at 14:41, Graham Leggett wrote:
> On 22 Apr 2024, at 12:52, Ivan Zhakov wrote:
>
> The question is, is it worth it for such a marginal change?
>> Have you looked in to the practicalities and verified no major stumbling
>> blocks,
>> bearing in mind that developer effort
On Sat, Apr 20, 2024 at 12:38:20PM +0200, Ivan Zhakov wrote:
> I would suggest separating APR in different libraries, while keeping them
> in one project/source tree.
>
> Something like that:
> - apr-2
> - apr-dbd-2
> - apr-dbm-2
> - apr-xlate-2 (?)
> - apr-crypto-2
> - apr-xml-2
> - apr-ldap-2
>
On 4/17/24 9:30 AM, Graham Leggett via dev wrote:
> On 17 Apr 2024, at 08:07, Ruediger Pluem wrote:
>
>>> Modified: apr/apr/trunk/util-misc/apu_dso.c
>>> URL:
>>> http://svn.apache.org/viewvc/apr/apr/trunk/util-misc/apu_dso.c?rev=1917050=1917049=1917050=diff
>>>
On 4/22/24 2:46 PM, minf...@apache.org wrote:
> Author: minfrin
> Date: Mon Apr 22 12:46:37 2024
> New Revision: 1917266
>
> URL: http://svn.apache.org/viewvc?rev=1917266=rev
> Log:
> apr_buffer: Redefine size to separate the unsigned size and the
> flag to indicate whether a zero terminated
On 22 Apr 2024, at 14:13, Ruediger Pluem wrote:
>> @@ -322,7 +287,17 @@ APR_DECLARE(int) apr_buffer_ncmp(const a
>> return 1;
>> }
>
> There was a proposal from Yann to simplify the above block to
>
>if (!src) {
>return dst ? 1 : 0;
>}
>if (!dst) {
>
On 18 Apr 2024, at 17:07, Yann Ylavic wrote:
> If so maybe:
>
> typedef struct
> {
>union {
>char *str;
>void *mem;
>} d;
> #if APR_SIZEOF_VOIDP == 8
> # define APR_BUFFER_SIZE_WIDTH 63
> #else
> # define APR_BUFFER_SIZE_WIDTH 31
> #endif
> apr_size_t
On 22 Apr 2024, at 14:05, Ruediger Pluem wrote:
>>> Now the caller needs to allocate memory even if it is not interested in the
>>> error or if there is no error at all.
>>> Wouldn't it be better to add an apu_err_t **err instead (which can be NULL)
>>> and in case of an error allocate an
>>>
On Mon, 22 Apr 2024 at 11:03, Nick Kew wrote:
>
>
> > On 20 Apr 2024, at 11:38, Ivan Zhakov wrote:
> >
> > Hi,
> >
> > In APR 2.0 we merged APR-Util **project** to APR. Which is IMHO a good
> thing.
>
> Um, apr-util was a separate library, but not really a separate project.
>
> By project I
On 22 Apr 2024, at 14:30, Ivan Zhakov wrote:
> Can you confirm why xlate/iconv cannot be moved to a module? (No expectation
> for you to do such a move, just want to understand what makes it impossible).
>>
> I think it can be done in theory, but I see potential problem: API should be
>
Hi all,
Updating the doxygen site at https://apr.apache.org/docs/apr/2.0/modules.html -
is it as simple as replacing the files under
https://svn.apache.org/repos/asf/apr/site/trunk/docs/docs/apr/trunk/ or is
there more to the process than that?
Regards,
Graham
--
On 4/22/24 4:07 PM, Graham Leggett via dev wrote:
> On 22 Apr 2024, at 14:05, Ruediger Pluem wrote:
>
Now the caller needs to allocate memory even if it is not interested in
the error or if there is no error at all.
Wouldn't it be better to add an apu_err_t **err instead
14 matches
Mail list logo
