melfar a écrit :
Hey,
Yep, I think there might be some caveats to that change.
The original patch did not work on methods, so I've fixed that and also
made the return value an rvalue, so that you can't attempt to modify the
temporary value, the zend_check_writable_variable guard will yield an
Hi,
By looking at the php6 gc I guess you introduce a mark and sweep gc.
Looking at the *_root function, it also seems that you have a
generational mark sweep gc.
I have a couple of question :
How many generation do you have?
What is the meaning of the different color (black, white,
I'm trying to debug a segfault that's occuring in an extension I'm
developing (phpgksu - PHP wrapper for libgksu2). On the PHP site it says
that if I have PHP configured with --enable-debug (which I do) then
whenever PHP crashes a core file should be created in the same directory
the file is
On 10 Nov 2009, at 13:55, Mark Skilbeck wrote:
I'm trying to debug a segfault that's occuring in an extension I'm
developing (phpgksu - PHP wrapper for libgksu2). On the PHP site it
says that if I have PHP configured with --enable-debug (which I do)
then whenever PHP crashes a core file
On 10.11.2009 16:55, Mark Skilbeck wrote:
I'm trying to debug a segfault that's occuring in an extension I'm
developing (phpgksu - PHP wrapper for libgksu2). On the PHP site it says
that if I have PHP configured with --enable-debug (which I do) then
whenever PHP crashes a core file should
Scott MacVicar wrote:
On 10 Nov 2009, at 13:55, Mark Skilbeck wrote:
I'm trying to debug a segfault that's occuring in an extension I'm
developing (phpgksu - PHP wrapper for libgksu2). On the PHP site it
says that if I have PHP configured with --enable-debug (which I do)
then whenever PHP
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 proposes the addition of a
include_silent is the name I though most intuitive once I finished to
read the RFC.
But it may not be the best too. It just need to be verbose.
Cheers,
On Tue, Nov 10, 2009 at 2:45 PM, Lukas Kahwe Smith m...@pooteeweet.org wrote:
Ahoi,
I have written an RFC for a more efficient solution to
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
On Tue, 10 Nov 2009, Mathieu Suen wrote:
By looking at the php6 gc I guess you introduce a mark and sweep gc.
Looking at the *_root function, it also seems that you have a generational
mark sweep gc.
I have a couple of question :
How many generation do you have?
What is the meaning
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
On 10.11.2009, at 18:40, Mark Skilbeck markskilb...@gmail.com 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
Hi!
Whilst you are all thinking about this, how about ...
$value = (function(){return $x;})();
I tried implementing that but it's not straightforward because you need
to keep the result of first call while everything inside () is
calculated (which can be any number of expressions including
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
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,
when URLs are
As stated in the RFC, I am not happy with the name autoload_include.
Suggestions welcome!
That reminds me of the set theory...
how about:
contain $file;
or
superset $file;
there are also the not so original (as found in many other languages)
keywords import / load.
Best,
~IF.
--
PHP
Hi!
In order to solve the above issues this RFC proposes the addition of a new
construct/function for now called “autoload_include” for lack of a better
name that largely behaves like the “include” does today with the following
differences, that when the include failed because of a missing file
On 10.11.2009, at 19:49, Stanislav Malyshev wrote:
Hi!
In order to solve the above issues this RFC proposes the addition
of a new
construct/function for now called “autoload_include” for lack of a
better
name that largely behaves like the “include” does today with the
following
Hi!
yes that would solve the issue partially. the race condition would still
remain, but its admitedly a rare case .. well I guess not so rare if you
I would have hard time thinking of application that deletes its own
include files frequently from other processes and we are supposed to
On 10.11.2009, at 20:07, Stanislav Malyshev wrote:
Hi!
yes that would solve the issue partially. the race condition would
still remain, but its admitedly a rare case .. well I guess not so
rare if you
I would have hard time thinking of application that deletes its own
include files
Hi!
there are many approaches to caching, one of which is delete to
invalidate and regenerate before the next use. again as the RFC makes it
clear .. the purpose is to be able to differentiate between a syntax
error and a missing file.
If you writing your own cache basing on includes, you
On 10.11.2009, at 20:38, Stanislav Malyshev wrote:
there are many approaches to caching, one of which is delete to
invalidate and regenerate before the next use. again as the RFC
makes it clear .. the purpose is to be able to differentiate
between a syntax error and a missing file.
If
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,
when URLs are
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
Hi!
ok .. so your objection to the RFC is solely because it introduces a new
language construct?
No, my objection is that it is not necessary to introduce a language
construct, and the construct introduced is not the right one. If
frameworks want to find out if file exists or get its name -
On 10.11.2009, at 21:31, Stanislav Malyshev wrote:
ok .. so your objection to the RFC is solely because it introduces
a new language construct?
No, my objection is that it is not necessary to introduce a language
construct, and the construct introduced is not the right one. If
Hi!
They dont want to determine if a file exists. They want to be able to
handle the case of a missing file being included differently than a
syntax error. Since php core does not provide such features, the only
Let's see why they need to handle missing file being included
differently? Or,
Le Tue, 10 Nov 2009 21:56:47 +0100, Lukas Kahwe Smith a écrit :
On 10.11.2009, at 21:31, Stanislav Malyshev wrote:
ok .. so your objection to the RFC is solely because it introduces a
new language construct?
No, my objection is that it is not necessary to introduce a language
construct,
On 10.11.2009, at 22:41, Alban wrote:
I think if PHP throws exception instead of warning/error then this
problem will not have existence reason :
sure with exceptions we could provide more contextual information and
also give a local way to handle the situation locally. that being said
On 10.11.2009, at 22:28, Stanislav Malyshev wrote:
Hi!
They dont want to determine if a file exists. They want to be able
to handle the case of a missing file being included differently
than a syntax error. Since php core does not provide such features,
the only
Let's see why they
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 some of these
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.
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 caches
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
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
35 matches
Mail list logo
