While we are on the IO issue, any ideas how can we transform Perl file
glob into apr_file_t? apr_file_t is an opaque struct and currently I see
no way to convert to apr_file_t other than its apr_file_open function
which requires the filepath to be opened, so you cannot dup the opened
fh like w
On Tue, 18 Dec 2001, Stas Bekman wrote:
> So shell we put your last temp patch in before we get this done, and
> turn the todo sub-test normal? Or should we just get the ground ready
> for Apache::PerlIO?
can't just put the patch in since flags will be different on certain
platforms. and for o
Doug MacEachern wrote:
> On Tue, 18 Dec 2001, Stas Bekman wrote:
>
> correction from my last message: 4 bytes is a 32 bit int
>
>
>>So is this a p5p call?
>>
>
> i doubt p5p would go for it, but if you want to ask, go for it.
I can I'll ask while following up on my bug report.
> we ca
On Tue, 18 Dec 2001, Stas Bekman wrote:
correction from my last message: 4 bytes is a 32 bit int
> So is this a p5p call?
i doubt p5p would go for it, but if you want to ask, go for it.
we can work around it, even for Apache::PerlIO. we can generate a
modperl_largefile.h that defines the ripp
Doug MacEachern wrote:
> the problem is that since we rip out largefile flags on the modperl side,
> Off_t is 4 bytes (16 bit int), whereas on the perl side Off_t is 8 bytes
> (64 bit int). for testing, add the largefile flags (as reported by
> perl -V:ccflags_uselargefiles) like the diff below.
the problem is that since we rip out largefile flags on the modperl side,
Off_t is 4 bytes (16 bit int), whereas on the perl side Off_t is 8 bytes
(64 bit int). for testing, add the largefile flags (as reported by
perl -V:ccflags_uselargefiles) like the diff below.
we could solve this on the modp
Doug MacEachern wrote:
> On Tue, 18 Dec 2001, Stas Bekman wrote:
>
>
>>Yes, that requires the lower layer's cooperation (which I cannot get),
>>i.e. access to its buffer.
>>
>
> could you turn off apr_file_t buffering and use PerlIOBuf buffering
> instead?
I think yes, I think actually that'
On Tue, 18 Dec 2001, Stas Bekman wrote:
> Yes, that requires the lower layer's cooperation (which I cannot get),
> i.e. access to its buffer.
could you turn off apr_file_t buffering and use PerlIOBuf buffering
instead?
-
To
>>There is a certain level of urgency on shaking well our PerlIO demands,
>>because 5.8.0 seems to come out any moment now. And it'll really suck if
>>there will be changes needed once 5.8.0 is released. I wish apr folks
>>would answer my question about exposing the apr's read buffer, so we c
On Tue, 18 Dec 2001, Stas Bekman wrote:
> talking about style nits, when initialization should be:
i guess it is habit. i do it only when initializing number variables in
declarations:
int i=0;
and in for loops:
for (i=0;
but wouldn't complain about having spaces in either.
On Tue, 18 Dec 2001, Stas Bekman wrote:
> 1. how did you detect it? (in-head detector, or something that I could
> have used too?)
in-head.
> 2. why there was a memory leak here.
a newAV() was created and never released.
---
On Tue, 18 Dec 2001, Stas Bekman wrote:
> You mean older bleadperls aren't back compat with 5.6.1's IO?
no bleedperls are compat with 5.6.1's IO.
older bleedperls are not compat with new bleedperls.
> I guess this requirement can go away once 5.8.0 is released.
right.
> There is a certain
[EMAIL PROTECTED] wrote:
> dougm 01/12/17 19:40:02
>
> Modified:xs/Apache/SubProcess Apache__SubProcess.h
> Log:
> avoid calling av_len() more than once.
> switch from using av_len() to AvFILLp
> add av_items variable to avoid (-1 + 2) when there is no av_argv
>
> Revisi
[EMAIL PROTECTED] wrote:
> dougm 01/12/17 19:24:49
>
> Modified:xs/Apache/SubProcess Apache__SubProcess.h
> Log:
> plug av_argv memory leak
>
> Revision ChangesPath
> 1.3 +3 -1 modperl-2.0/xs/Apache/SubProcess/Apache__SubProcess.h
>
> Index: Apache__Su
[EMAIL PROTECTED] wrote:
> dougm 01/12/17 19:21:22
>
> Modified:xs/Apache/SubProcess Apache__SubProcess.h
> Log:
> a few style fixups and comments
> +if (!(*script_in = procnew->in)) {
> +/* XXX: this needs to be Perl_croak(aTHX_ ...)
> + * or go away s
Doug MacEachern wrote:
> On Tue, 18 Dec 2001, Stas Bekman wrote:
>
>
>>why would Apache::SubProcess be unavailable? It works with bleadperl and
>>with some more investigation will work with 5.6.1. Only APR::PerlIO
>>requires the latest bleadperl.
>>
>
> see commit about compiling APR::PerlI
On Tue, 18 Dec 2001, Stas Bekman wrote:
> why would Apache::SubProcess be unavailable? It works with bleadperl and
> with some more investigation will work with 5.6.1. Only APR::PerlIO
> requires the latest bleadperl.
see commit about compiling APR::PerlIO with older bleedperls.
the 5.6.1 fal
[EMAIL PROTECTED] wrote:
> dougm 01/12/17 16:23:03
>
> Modified:t/response/TestApache subprocess.pm
> Log:
> skip subprocess test unless Apache::SubProcess is available
why would Apache::SubProcess be unavailable? It works with bleadperl and
with some more investigation will w
Doug MacEachern wrote:
> On Sat, 15 Dec 2001, Stas Bekman wrote:
>
>
>>Issues:
>>- optional functions use explodes during compilation under 5.6.1 (have no
>> idea why, it compiles cleanly with bleadperl)
>>
>
> if it requires PerlIO anyhow, just use the same #ifdef PERLIO_LAYERS
> around the
19 matches
Mail list logo
