On Wed, 28 Aug 2019 at 10:08, Joe Orton wrote:
>
> On Sat, Aug 24, 2019 at 05:39:17PM +0300, Ivan Zhakov wrote:
> > For what it's worth, I'm -1 on the changes done in r1862071 and
> > r1862435 for the reasons listed above.
> >
> > PS: No idea if I can actually veto changes, because while I'm a
>
On Sat, Aug 24, 2019 at 05:39:17PM +0300, Ivan Zhakov wrote:
> For what it's worth, I'm -1 on the changes done in r1862071 and
> r1862435 for the reasons listed above.
>
> PS: No idea if I can actually veto changes, because while I'm a
> committer on the APR project, I am not in its PMC. But "-1"
On 27.08.2019 11:25, Ruediger Pluem wrote:
>
> On 08/25/2019 04:04 PM, Branko Čibej wrote:
>> On 24.08.2019 16:39, Ivan Zhakov wrote:
>>> On Thu, 25 Jul 2019 at 15:58, Ivan Zhakov wrote:
On Mon, 8 Jul 2019 at 20:05, Ivan Zhakov wrote:
> On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
On 08/25/2019 04:04 PM, Branko Čibej wrote:
> On 24.08.2019 16:39, Ivan Zhakov wrote:
>> On Thu, 25 Jul 2019 at 15:58, Ivan Zhakov wrote:
>>> On Mon, 8 Jul 2019 at 20:05, Ivan Zhakov wrote:
On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
> On Wed, Jul 03, 2019 at 02:43:02PM +0300,
On 24.08.2019 16:39, Ivan Zhakov wrote:
> On Thu, 25 Jul 2019 at 15:58, Ivan Zhakov wrote:
>> On Mon, 8 Jul 2019 at 20:05, Ivan Zhakov wrote:
>>> On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
> They also make the existing old
On Thu, 25 Jul 2019 at 15:58, Ivan Zhakov wrote:
>
> On Mon, 8 Jul 2019 at 20:05, Ivan Zhakov wrote:
> >
> > On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
> > >
> > > On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
> > > > They also make the existing old API unusable for many cases
On Mon, 8 Jul 2019 at 20:05, Ivan Zhakov wrote:
>
> On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
> >
> > On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
> > > They also make the existing old API unusable for many cases thus
> > > making a switch to the new API mandatory, even
On Wed, 3 Jul 2019 at 18:37, Joe Orton wrote:
>
> On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
> > They also make the existing old API unusable for many cases thus
> > making a switch to the new API mandatory, even though it doesn't have
> > to be so (see below).
> >
> > APR 1.x
On 07/03/2019 05:37 PM, Joe Orton wrote:
> On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
>> They also make the existing old API unusable for many cases thus
>> making a switch to the new API mandatory, even though it doesn't have
>> to be so (see below).
>>
>> APR 1.x did not
On Wed, Jul 03, 2019 at 02:43:02PM +0300, Ivan Zhakov wrote:
> They also make the existing old API unusable for many cases thus
> making a switch to the new API mandatory, even though it doesn't have
> to be so (see below).
>
> APR 1.x did not specify that the result of apr_dir_read() has to be
On Tue, 2 Jul 2019 at 13:18, Joe Orton wrote:
>
> On Tue, Jul 02, 2019 at 09:59:20AM +0200, Branko Čibej wrote:
> > On 02.07.2019 08:49, Joe Orton wrote:
> > > On Thu, Jun 27, 2019 at 05:01:56PM +0300, Ivan Zhakov wrote:
> > >> On Tue, 25 Jun 2019 at 17:21, wrote:
> > >>
> > >>> Author: jorton
>
On Tue, Jul 02, 2019 at 08:22:47AM -0500, Greg Stein wrote:
> On Tue, Jul 2, 2019 at 8:04 AM Branko Čibej wrote:
> > Perhaps this is the right time to note (again) that over in Subversion
> > land, we found that functions should take _two_ pool parameters: one for
> > allocating the returned
On Tue, Jul 2, 2019 at 8:04 AM Branko Čibej wrote:
>...
> Perhaps this is the right time to note (again) that over in Subversion
> land, we found that functions should take _two_ pool parameters: one for
> allocating the returned values and one for temporary allocations. This
> is better than
On 02.07.2019 14:04, Joe Orton wrote:
> On Tue, Jul 02, 2019 at 11:18:31AM +0100, Joe Orton wrote:
>> Reading the win32 code a bit more, it is not constant-memory even with
>> the buffer in apr_dir_t, because it can allocate from dir->pool (and
>> even create cleanups!) in the more_finfo() call,
On Tue, Jul 02, 2019 at 11:18:31AM +0100, Joe Orton wrote:
> Reading the win32 code a bit more, it is not constant-memory even with
> the buffer in apr_dir_t, because it can allocate from dir->pool (and
> even create cleanups!) in the more_finfo() call, so I think the current
> behaviour is not
On Tue, Jul 02, 2019 at 09:59:20AM +0200, Branko Čibej wrote:
> On 02.07.2019 08:49, Joe Orton wrote:
> > On Thu, Jun 27, 2019 at 05:01:56PM +0300, Ivan Zhakov wrote:
> >> On Tue, 25 Jun 2019 at 17:21, wrote:
> >>
> >>> Author: jorton
> >>> Date: Tue Jun 25 14:21:56 2019
> >>> New Revision:
On 02.07.2019 08:49, Joe Orton wrote:
> On Thu, Jun 27, 2019 at 05:01:56PM +0300, Ivan Zhakov wrote:
>> On Tue, 25 Jun 2019 at 17:21, wrote:
>>
>>> Author: jorton
>>> Date: Tue Jun 25 14:21:56 2019
>>> New Revision: 1862071
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1862071=rev
>>> Log:
>>>
On Thu, Jun 27, 2019 at 05:01:56PM +0300, Ivan Zhakov wrote:
> On Tue, 25 Jun 2019 at 17:21, wrote:
>
> > Author: jorton
> > Date: Tue Jun 25 14:21:56 2019
> > New Revision: 1862071
> >
> > URL: http://svn.apache.org/viewvc?rev=1862071=rev
> > Log:
> > Add apr_dir_pread(), a variant of
On Tue, 25 Jun 2019 at 17:21, wrote:
> Author: jorton
> Date: Tue Jun 25 14:21:56 2019
> New Revision: 1862071
>
> URL: http://svn.apache.org/viewvc?rev=1862071=rev
> Log:
> Add apr_dir_pread(), a variant of apr_dir_read() which allows callers
> to read a directory with constant memory
19 matches
Mail list logo
