On 29.12.2009, at 00:25, Ralph Schindler wrote:
> Bump.
>
> I really think we need to think about this problem that Lukas has brought up.
>
> Now that the magic words have come up ('counting stat calls'), can we get
> someone to weight in on the possibility of both having some kind of
> inclu
Bump.
I really think we need to think about this problem that Lukas has
brought up.
Now that the magic words have come up ('counting stat calls'), can we
get someone to weight in on the possibility of both having some kind of
include_path resolver in the 5.3 branch, and it's impact of stat c
On Wed, Dec 9, 2009 at 2:04 AM, Stanislav Malyshev wrote:
> Hi!
>
> I think stream_resolve_include_path() should be changed to work through
> zend_resolve_path, in any case. Also, what is the reason it can't be in 5.3
> too?
> I'd like to both fix stream_resolve_include_path() and get it into 5.3,
Hi!
I think stream_resolve_include_path() should be changed to work through
zend_resolve_path, in any case. Also, what is the reason it can't be in
5.3 too?
I'd like to both fix stream_resolve_include_path() and get it into 5.3,
any objections to that?
If that was done, only problem with usi
On 22.11.2009, at 18:01, Lukas Kahwe Smith wrote:
> I have updated the current RFC accordingly:
> http://wiki.php.net/rfc/autoload_include
>
> So there are three approaches listed in the RFC:
> 1) http://wiki.php.net/rfc/autoload_include#proposal
> add a new alternative to include, which works t
Lukas Kahwe Smith wrote:
> Finally optionally include in your vote if would like to see this feature
> added to 5.3.2 or if it should wait for the next minor/major version update
> instead.
+0 on version to include this in, sorry I forgot to include that in my vote.
Greg
--
PHP Internals - PH
Lukas Kahwe Smith wrote:
> So there are three approaches listed in the RFC:
> 1) http://wiki.php.net/rfc/autoload_include#proposal
> add a new alternative to include, which works the same except that for
> missing files it returns null and on success it returns the file location
> (unless the fil
On 22.11.2009, at 18:01, Lukas Kahwe Smith wrote:
> So there are three approaches listed in the RFC:
> 1) http://wiki.php.net/rfc/autoload_include#proposal
> add a new alternative to include, which works the same except that for
> missing files it returns null and on success it returns the file
On 11.11.2009, at 14:50, Greg Beaver wrote:
> stream_resolve_include_path() as currently constructed could not be
> intercepted, and is actually unable to process an include_path that
> contains streams. I'm guessing it was written long before PHP 5.3.
> This could be easily fixed by having str
IIRC, Sara created this as a proof of concept to a reoccurring question
of why filesystem functions don't have an include include_path argument.
Many members argued (and for good merit), that any fs operations
should not include the include_path. It was put into trunk and
forgotten about, but
Hi!
Isn't this what stream_resolve_include_path does?
I wasn't even aware it was there (it being undocumented doesn't help a
lot). And it is listed as PHP 6 only. I guess if we fix it to work
correctly and backport to 5.3 (or even 5.2?) it may just work for
frameworks.
--
Stanislav Malyshe
On 11.11.2009, at 14:50, Greg Beaver wrote:
Lukas Kahwe Smith wrote:
On 11.11.2009, at 11:44, Mikko Koppanen wrote:
On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith
so a byte code cache should cache the resolution of the path thereby
speeding up the subsequent call to include?
strea
Lukas Kahwe Smith wrote:
>
> On 11.11.2009, at 11:44, Mikko Koppanen wrote:
>
>> On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith
>> wrote:
>>>
>>> On 11.11.2009, at 01:50, Greg Beaver wrote:
>>>
if (can_include($file)) {
include $file;
}
>>>
>>>
>>> I am sure you focused on th
On 11.11.2009, at 11:44, Mikko Koppanen wrote:
On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith > wrote:
On 11.11.2009, at 01:50, Greg Beaver wrote:
if (can_include($file)) {
include $file;
}
I am sure you focused on the technical aspects. Just wanted to say
that for
a name "can" i
On Wed, Nov 11, 2009 at 10:00 AM, Lukas Kahwe Smith wrote:
>
> On 11.11.2009, at 01:50, Greg Beaver wrote:
>
>> if (can_include($file)) {
>> include $file;
>> }
>
>
> I am sure you focused on the technical aspects. Just wanted to say that for
> a name "can" is not ideal, because there is no gura
On 11.11.2009, at 01:50, Greg Beaver wrote:
if (can_include($file)) {
include $file;
}
I am sure you focused on the technical aspects. Just wanted to say
that for a name "can" is not ideal, because there is no gurantee that
the file will not have syntax errors. As such something with
On 11.11.2009, at 10:47, Richard Quadling wrote:
2009/11/11 Lukas Kahwe Smith :
[snip]
Would using a userland-based set_error_handler() be of use here?
If, under normal circumstances, blind include() is what is used, then
trapping the error when it fails would be when you could test for
wha
2009/11/11 Lukas Kahwe Smith :
> [snip]
Would using a userland-based set_error_handler() be of use here?
If, under normal circumstances, blind include() is what is used, then
trapping the error when it fails would be when you could test for
whatever it is you want to test for?
Richard.
--
--
Perhaps better would be to introduce a function:
if (can_include($file)) {
include $file;
}
opcode caches could easily snag this, as we could provide a simple
hook the way we do with stream_resolve_path(). That would actually
make a 0-stat smart autoloader a possibility. Just in case i
Hi!
Yes, but let's not forget we're talking about making this:
While with proper caching, it can be 0 filesystem accesses.
if (can_include($file)) {
include $file;
}
That's exactly what I was proposing - to have function to find file in
include path and probably return the resulting f
Stanislav Malyshev wrote:
> Hi!
>
>> A good point. Fortunately, most streams do store the filename in the
>> stream struct, so this would still probably be possible in the majority
>> of cases. If not available, the original requested filename is used
>> (the one from the fopen call), so opcode c
Hi!
A good point. Fortunately, most streams do store the filename in the
stream struct, so this would still probably be possible in the majority
of cases. If not available, the original requested filename is used
(the one from the fopen call), so opcode caches probably could just use
that.
T
Stanislav Malyshev wrote:
> Hi!
>
>>> This would break security distinction between file ops and include ops,
>>> when URLs are allowed for open but not include.
>
> Additional thing - it probably would be a problem for bytecode caches,
> since they'd have to:
> a. watch all file opens, in case som
Hi!
This would break security distinction between file ops and include ops,
when URLs are allowed for open but not include.
Additional thing - it probably would be a problem for bytecode caches,
since they'd have to:
a. watch all file opens, in case some of these will later be used for
inclu
Stanislav Malyshev wrote:
> Hi!
>
>> Alternatively include() could be extended to allow resources, so the
>> above would turn info
>>
>> if ($fp = @fopen($file, 'r', true)) {
>> include($fp);
>> fclose($fp);
>> }
>
> This would break security distinction between file ops and include ops,
Stanislav Malyshev wrote:
> Hi!
>
>> Alternatively include() could be extended to allow resources, so the
>> above would turn info
>>
>> if ($fp = @fopen($file, 'r', true)) {
>> include($fp);
>> fclose($fp);
>> }
>
> This would break security distinction between file ops and include ops,
Hi!
Alternatively include() could be extended to allow resources, so the
above would turn info
if ($fp = @fopen($file, 'r', true)) {
include($fp);
fclose($fp);
}
This would break security distinction between file ops and include ops,
when URLs are allowed for open but not inc
On 10.11.2009, at 18:40, Mark Skilbeck wrote:
What's the problem with file_exists() ?
i have explained this in the RFC. for one it does not support the
include path setting. furthermore this does not solve the race
condition and requires more FS operations than my proposal would.
regar
Lukas Kahwe Smith wrote:
Ahoi,
I have written an RFC for a more efficient solution to get rid of the
common fopen() hack inside autoloaders:
if ($fp = @fopen($file, 'r', true)) {
fclose($fp);
include $file;
}
Here is the gist of the proposal:
In order to solve the above issues this RFC propos
Lukas Kahwe Smith wrote:
> I have written an RFC for a more efficient solution to get rid of the
> common fopen() hack inside autoloaders:
> if ($fp = @fopen($file, 'r', true)) {
> fclose($fp);
> include $file;
> }
>
> Here is the gist of the proposal:
> In order to solve the above issues this RFC
30 matches
Mail list logo
