Andi Gutmans wrote:
> Hi Johannes, Our preference would be to stick to "import" because I
> think the perception many will have of "use" is that it also includes
> files (just based on some other languages). That said I agree that
> compatibility would be an issue here. In fact it's even somewhat o
Hi all,
Could someone point me to the message(s) explaining why the executor is
unstable when an exception is thrown in __autoload()?
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
I spent a while tonight tinkering with the parser to try to figure out
how to allow it to use T_IMPORT as well as T_STRING for method names,
and quickly came to the conclusion that this causes way more trouble
than it is worth. However, in a moment of inspiration, I realized that
a minor chan
Gregory Beaver wrote:
> ===
> RCS file: /repository/php-src/run-tests.php,v
> retrieving revision 1.226.2.37.2.35
> diff -u -r1.226.2.37.2.35 run-tests.php
> --- run-tests.php 14 Sep 2007 15:28:03 -
Hi again,
The attached patches for PHP 5.3 and PHP 6 add in_class_exists(). The
function is intended to be used in __autoload(). The following test
script demonstrates its usage:
outputting:
bool(false)
bool(false)
bool(true)
bool(false)
The purpose is to allow an autoload handler to detect
Benjamin Schulz wrote:
> On 02.10.2007, at 22:04, Stanislav Malyshev wrote:
>
>
>>> >> import ::Exception as Notused;
>>> import Foo::Exception;
>>> ?>
>>>
>>
>> I wouldn't actually recommend using such code. If you have
>> Foo::Exception just use Foo::Exception - it's short enough :)
>>
>
> And
Johannes Schlüter wrote:
> The only need I see is mocking objects for a unit test. This is usually
> done on a test system so installing such an extension shouldn't be to
> hard (especially for somebody who is able to do unit tests using mock
> objects...)
This is unnecessary in a well-designed p
Stanislav Malyshev wrote:
>> to use die() or some other method of terminating execution. A user
>> calling class_exists() clearly expects a return from autoload, whereas a
>> user instantiating an object will expect a fatal error if the class
>> cannot be found.
>
> This is true, but __autoload sh
Dmitry Stogov wrote:
> In your example :
>
> namespace Foo;
> import Blah::Exception;
> $a = new Exception;
> ?>
>
> "new Exception" refer to "Blah::Exception" and will fail if such class
> doesn't exists.
>
> "import Blah::Exception" creates an alias with short name "Exception" only
> for curr
Dmitry Stogov wrote:
> In your example :
>
> namespace Foo;
> import Blah::Exception;
> $a = new Exception;
> ?>
>
> "new Exception" refer to "Blah::Exception" and will fail if such class
> doesn't exists.
>
> "import Blah::Exception" creates an alias with short name "Exception" only
> for curr
Patches added to http://bugs.php.net/28261, and I re-opened the bug.
Greg
Gregory Beaver wrote:
> Hi,
>
> I spent a while tonight tinkering with the parser to try to figure out
> how to allow it to use T_IMPORT as well as T_STRING for method names,
> and quickly came to the concl
Marcus Boerger wrote:
> Hello Greg,
>
> I think Johannes has a point here. It is doable in PHP already and you
> don't hit a performance issue here as you are showing the message only
> when the class is not present. That is just add Johanne' code after you
> know that your autoload was responsi
Marcus Boerger wrote:
> Hello Alexey,
>
> that is probably but i wouldn't like it. I think we are going to make it
> to complex, to Java like. Keep it simple. The only bad thing is a bit of
> a slowdown - eventually - where not loading all classes always by include
> isn't slower anyway. Tha
Stanislav Malyshev wrote:
>> 1) ability to customize the fatal error message
>> 2) knowing whether the class is required or optional
>
> I don't think we should start customizing error messages. The engine
> has a lot of error messages and they are not customized. I see no
> reason why autoloader c
Stanislav Malyshev wrote:
>> Are there already any results on these checks?
>
> Looks like we have the simple patch that allows to use "import" as
> method name, function name and class name. If we didn't discover any
> problems with it then import stays.
Hi,
If you're talking about my patch [1]
Chuck Hagenbuch wrote:
> Hi folks-
>
> I've hit upon something with namespaces and autoloading that I think is
> a little out of order. If you take the attached 3 files, put them in the
> same directory, and run demo.php, you will see this:
>
> Fatal error: Uncaught exception 'Exception' in
> /Us
Chuck Hagenbuch wrote:
> So, if I want a "global" exception, I use ::Exception. If I say
> Exception, then I mean my namespace's Exception with no fallback. And
> if I want another namespace's Exception, I import it (import
> Other::Exception).
I (and PEAR) could live with this. I don't have a p
Chuck Hagenbuch wrote:
> Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
>
>> This is even better than requiring, and makes the intent very clear. I
>> don't think it decreases intuitiveness, on the contrary - from the
>> look of the code it is immediately clear which exception would be used.
>
>
Stanislav Malyshev wrote:
> Hi all!
>
> Since many packages (wordpress, propel, horde, phing, etc.) use "import"
> as either class or function name, and we couldn't find a good solution
> to make it work with import keyword without going into all kinds of
> troublesome hacks, so we are thinking ab
Marcus Boerger wrote:
> Hello Gregory,
>
> even if you can solve it easily your patch will not solve the fact that we
> won't have a token for that keyword the, or am i missing something?
>
> marcus
Hi Marcus,
Just finished the patch (see separate reply), and in my tests, the
keyword still wor
Stanislav Malyshev wrote:
>> Hold off for a bit - I may have a simple solution that solves the
>> problem for class names, method names and functions, have to code the
>> patch tonight first to prove it works.
>
> OK, please send it as soon as you have it :)
Hi,
The attached patch is for PHP 5.3,
Stanislav Malyshev wrote:
>> namespace Foo;
>> import Exception;
>
> Once more, import with one-term argument is a no-op. And will stay so.
> That's why we have the warning.
>
>> I think that either import ::Exception needs to work, or import
>> Exception shouldn't issue a warning.
>
> We'll discus
Giedrius D wrote:
> Hi,
>
> sorry if I missed something but is there any reason to not use keyword "use"?
>
> IMHO allowing keywords in class, method, function, etc. names brings
> more confusion then value.
>
The same confusion that is brought about by allowing keywords as
variable names?
clas
Giedrius D wrote:
> On 10/23/07, Gregory Beaver <[EMAIL PROTECTED]> wrote:
>
>> The same confusion that is brought about by allowing keywords as
>> variable names?
>>
>> > class Test
>> {
>> public $class;
>> }
>>
>> $a =
Hi all,
The patch to implement multiple namespaces per file, and the patch to
remove keyword restrictions for methods appear to have fallen through
the cracks. I would like to encourage at the minimum a review, and
either a "go away" or a commit so we can still pretend that outsider
contributions
Stanislav Malyshev wrote:
> As for multiple namespaces per file, it adds certain complications, both
> syntax-wise and engine-wise, so I'm still not 100% convinced it is worth
> it.
Which are?
Remember, we both found, independently, that combining separate files
yields from a 10-30% performance i
Brian Shire wrote:
>
> On Dec 3, 2007, at 2:17 PM, Stanislav Malyshev wrote:
>
>>> I am a developer on a CMS also which uses the auto-include
>>> functionality to
>>> include many classes over many files. Each request can include up to 30
>>> different files. The speed increase is around the 15%
Brian Shire wrote:
> Hi Greg,
>
> I'm sorry that my message probably did come off as condescending. :-(
> I really just wanted to share some my *own* pitfalls in case it was
> something that might be helpful here.
>
> If you aren't too put off and you are running APC then perhaps we can
> discu
Roman Borschel wrote:
> A small addition:
>
> the exact same test results in the following average times on my dev
> machine:
> with bundled classes: ~0.07s (~2-10 includes)
> without: ~0.10s (~60-80 includes)
>
> Thats ~30ms difference in average. I wanted to post that because the
> results on
Martin Alterisio wrote:
> Sorry to step in uninvited to this discussion, I have some doubts about all
> this, and I'll really appreciate if someone more knowledgeable could
> enlighten my ignorance. The doubts I have are as follows:
>
> 1) Why is performance relevant to whether namespaces are impl
Martin Alterisio wrote:
> I didn't understand. Do you mean that I was wrong? Or that I was right about
> namespaces purpose, but that's only needed in development? Therefore,
> shouldn't the bundling process remove the need for namespaces (i.e. the
> bundling process removes namespaces)?
You can't
Martin Alterisio wrote:
> 2007/12/4, Gregory Beaver <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>>:
>
> Martin Alterisio wrote:
> > 1) Why is performance relevant to whether namespaces are
> implemented one per
> > file or many per file?
Hi,
There's been enough confusion, here's the patch again, this time against
5.3, no tests for clarity
http://pear.php.net/~greg/multi.5.3.patch.txt
This patch allows:
It doesn't allow:
so all code must have a namespace declaration. The sole purpose is to
combine files containing namespace
Martin Alterisio wrote:
> It's also not possible to reliably bundle files even if you could have
> multiple namespaces declarations as, correct me if I'm wrong, import
> statements affect the whole file, there is no way to "unimport", a
> name clash could still occur.
OK, I'll correct you: you're
Martin Alterisio wrote:
> 2007/12/4, Chuck Hagenbuch <[EMAIL PROTECTED]>:
>> Quoting Martin Alterisio <[EMAIL PROTECTED]>:
>>
>>> Knowing that I'll have to strongly encourage the developers to dump that
>>> patch. The namespace declaration shouldn't do more than what it's
>> expected
>>> to do. Why
Derick Rethans wrote:
> With all the above considerations, especially my first point, I still have not
> heard any good reason why namespaces in the current implementation are
> actually
> useful - or what particular case they solve... so I am wondering, are they
> really useful? I come now to th
I used import in my last example instead of use, that was simply a typo,
not trying to open a can of worms.
Sorry,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Derick,
I've been thinking a *lot* about your provocative email in the past
couple of days, and have come to a different conclusion from my original
reply (which, as a reminder stated I saw no problem with removing
namespaces as long as we kept the import facility to alias classes via
use). Af
Matthias Pigulla wrote:
>> 1) recommend all global non-namespaced code that wishes to import
>> namespaced code via "use Namespace::Classname" add a "namespace
>> __php__;" at the top of the file, and that the __php__ namespace be
>> reserved for use by end-user applications.
>
>
>> 5) namespa
Matthias Pigulla wrote:
>> Von: Gregory Beaver [mailto:[EMAIL PROTECTED]
>
>> Exactly - which is why you should never put classes, functions or
>> constants in the __php__ namespace. The convention I am proposing
>> is to only use __php__ for code that *uses* r
Jessie Hernandez wrote:
> Hi Greg,
>
> How about this: any non-namespaced file that uses "use" statements is
> implicitly put into the __php__ namespace (or whatever other name is
> chosen, or having the namespace name be the path of the file)? With
> this, "use" will never import any symbols into
Sam Barrow wrote:
> I agree with this 100%, is this something that could be changed? I don't
> see a reason behind it.
>
> On Sun, 2007-12-09 at 16:24 -0500, Jessie Hernandez wrote:
>
>> internal class/function with the same name.
>>
>> Dmitry, what's the reason this lookup logic wasn't used in
Matthias Pigulla wrote:
>> Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
>
>> But you could achiever the same just by avoiding naming classes the
>> same as internal classes, you surely know which classes are in your
>> own namespace?
> ...
>> Not using names of classes same as internal classe
Hi,
I've been furiously working behind the scenes with Stas and Dmitry, and
have some enhancements to namespaces in the form of 2 patches.
1) multiple namespaces per file
2) use ::name;
1) multiple namespaces per file
This is implemented as such:
The example above shows that imported names a
Sam Barrow wrote:
> Is this patch going to be implemented in the PHP release?
yes, these are patches against cvs.php.net php5 -r PHP_5_3 and HEAD
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ken Stanley wrote:
>
>
> On Dec 11, 2007 6:13 PM, Gregory Beaver <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> The example above shows that imported names are reset at each
> namespace
> declaration. There is no prohibition on t
Jessie Hernandez wrote:
> I just thought of something that might be a solution to the lookup rules
> that we currently have in the namespaces implementation. Whether it's
> good or not, I just wanted to throw it out there. Here goes:
>
> Support a user-defined function named __get_namespace_classe
Jani Taskinen wrote:
> Nice to hear some work is done but I get very annoyed every time I see
> the words "behind the scenes" (or something alike). I guess it was
> because it's impossible to discuss anything on internals without the
> noise coming from "outside"..? Could we finally make this list
Nathan Rixham wrote:
> Hate to bring this one up; I'll be brief!
>
> for instance smarty get's upgraded and has it's own namespace, I have a
> class which extends it, soon to be in my applications namespace which
> implements an interface in my interfaces namespace.. how does one extend
> a class
Hi again,
I am not sure this will make it through the noise *sigh* but I'll give a
try :)
Derick Rethans wrote:
> Hei,
>
> now some patches by Greg and Dmitry made it into CVS, some of the things
> in my mail have been resolved, however, we still need to come up with a
> solution to the 1st and
Dangit, I wasn't finished when that sent (apparently Ctrl-S sends a
message - I was trying to Ctrl-V to paste)
Gregory Beaver wrote:
> Hi again,
>
> I am not sure this will make it through the noise *sigh* but I'll give a
> try :)
>
> Derick Rethans wrote:
>
&g
Hi,
We don't need moderation, we don't need read-only. We need people to
follow a simple common-sense checklist. Before sending a message to
php-internals, ask these questions of yourself:
1) am I angry? yes => do not send your message, do not pass go, do not
collect $200. Wait until tomorrow.
Andrew Mason wrote:
> For those of us who gave up following the namespace debate 150+ emails ago,
> can someone from the core maintainers let the rest of us plebs know if
> namespaces are likely to be included any time soon.
>
> I've been playing with the patches that were provided by moving our
>
Hi all,
As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR). I can say with absolute
certainty that scalar type hints would not make my job easier.
In fact, it would make it harder. Many of the functions I work with
require vari
Alain Williams wrote:
> On Thu, Jan 03, 2008 at 10:36:15PM -0600, Gregory Beaver wrote:
>
>> Hi all,
>>
>> As someone who has dealt with many scripts written by others as well as
>> many of my own in a large-scale project (PEAR). I can say with absolute
>&
Hi,
I'm trying to figure out how to test a feature in the phar extension
that requires the executable test file to be an actual phar archive.
This would be possible if there was some way to load the --FILE--
section from an external file. Would anyone object to adding a new
section to the .phpt
Gregory Beaver wrote:
> Hi,
>
> I'm trying to figure out how to test a feature in the phar extension
> that requires the executable test file to be an actual phar archive.
> This would be possible if there was some way to load the --FILE--
> section from an external file.
Gregory Beaver wrote:
> Gregory Beaver wrote:
>> Hi,
>>
>> I'm trying to figure out how to test a feature in the phar extension
>> that requires the executable test file to be an actual phar archive.
>> This would be possible if there was some way to load th
Marco Tabini wrote:
>
> On 10-Jan-08, at 10:58 AM, Lukas Kahwe Smith wrote:
>> I know that PHP has so far stayed clear of processes and I am fine
>> with keeping it this way. But I really think that some of these flames
>> should best be taken off list into some work group that provides
>> summari
Jeff Griffiths wrote:
> Antony Dovgal wrote:
> ...
>> Well, to me it matters whether the author is going to care of the
>> thing he's proposing or he's going to disappear right after it's
>> implemented.
>
> I didn't realize there was a section of the code flagged 'syntactic
> sugar' and only a fe
Lukas Kahwe Smith wrote:
> Hi,
>
> I think its painfully obvious that a system to manage the voting is
> needed. Like I said, ideally it should also have an email interface.
> People should be able to vote from +1 to -1 and be able to add a
> comment. Notifications should be send to this list abou
Hi all,
I don't have time to fix this now, but FYI, run-tests.php has very odd
behavior if you don't put a space between a switch and its argument, and
should error out. i.e.
php run-tests.php -n -dextension_dir=blah -dextension=blah.so
will ignore every other line. This:
php run-tests.php -n
Marcus Boerger wrote:
> Hello Steph,
>
> so you mean we do not have to confuse our uses by solution 2a becasue we
> only have the minimum subset of zip in phar that ohar actually needs?
>
>
Although phar can be used to create and read any zip archive, it will
automatically add the file ".ph
Pierre Joye wrote:
> Hi Greg,
>
> On Jan 28, 2008 7:52 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>
>>> Current status of phar addresses most of these criticisms:
>>>
>> Looks impressive, great work!
>>
>>
>>> phar implements zip support with native PHP code, enabling some fea
Hi all,
I have been working hard on pecl/phar to address several issues raised
last May when it was first mentioned on the list, and would like to
summarize where phar stands today with regards to those criticisms:
Criticisms:
* non-standard file format
* limited introspection
* no support fo
Stanislav Malyshev wrote:
>> Current status of phar addresses most of these criticisms:
>
> Looks impressive, great work!
>
>> phar implements zip support with native PHP code, enabling some features
>
> I am a bit confused about native PHP code here - we are talking baout
> an extension, right? So
Pierre Joye wrote:
>>> for ext/zip, or zip64, but zip64 would also be trivial to add to phar,
>
> It is already implemented. We are working on portability issues.
> That's why I put the custom stream support as the top priority, it is
> the way to go to solve almost portability issues.
Which is?
Mike wrote:
> Hi Gregory,
>
> Do you have any benchmarks that compare the speed between trying to
> include/require files NOT in a phar archive, compared with calling
> include/require for files inside a phar archive?
>
> I have a large PHP application with about 5000 PHP files and we make
Markus Fischer wrote:
> Hi,
>
> Andi Gutmans wrote:
>> I think if the syntax is confusing we can go for just a single quote as
>> part of the operator which doesn't make it look like just another plain
>> old string, e.g.:
>>
>> $bar =<<<'FOO
>
> Such a thing is not nice for casual string syntax
Hi Andi,
Some things not in the docs that might be useful in your playing with phar:
1) webPhar()'s front controller currently operates on absolute uri for
finding the file requested.
http://localhost/myphar.phar/blah/blah.php/otherstuff will look for
"blah/blah.php/otherstuff" in "myphar.phar".
Hi all,
It's a tad tricky to do run-tests -m on my system, as every PHP call leaks:
==4570== Invalid read of size 8
==4570==at 0x4015B0A: (within /lib/ld-2.6.1.so)
==4570==by 0x400A8F7: (within /lib/ld-2.6.1.so)
==4570==by 0x4006174: (within /lib/ld-2.6.1.so)
==4570==by 0x40085F7:
Rasmus Lerdorf wrote:
> Cristian Rodriguez wrote:
>> 2008/2/1, Marcus Boerger <[EMAIL PROTECTED]>:
>>> - Fix callable/static mess, the following will now all result in a
>>> E_STRICT
>>> . binding a dynamic function as a static callback
>>> . static call of a dynamic function
>>> . i
Hi all,
I'm getting unresolved external symbol xmlXPathCompiledEvalToBoolean
with the latest zip.zip, any plans to update libxml2 to .31 soon in zip.zip?
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Steph Fox wrote:
> Hi Derick,
>
>> I see another issue after reading this, and that is that it makes it
>> much harder for users to depend on specific extensions just being always
>> available by default. It's important for application distributers to
>> have this core set of extensions to rely on
Pierre Joye wrote:
> -1: Restore them and always return FALSE (not 0)
-1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
A short update on improvements to phar
* Phar::webPhar() now works with CGI sapi (endless redirect happened
before)
* Phar::webPhar() now recognizes urls exactly the same way as apache,
so http://localhost/myphar.phar/file.php/extra/stuff will find
"file.php" hidden in the url and retrieve
Marcus Boerger wrote:
> helly Thu Feb 7 18:40:29 2008 UTC
>
> Modified files:
> /php-src README.UNICODE-UPGRADES
> /php-src/main snprintf.c spprintf.c
> Log:
> - Add %Z to *printf
>
> http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE-UPGRADES?r1=1.
Hi,
I'm having a terrible time removing a memory leak in pecl/phar that is
caused by a zval_dtor() call in zlib_filter.c. I think the source of
the problem is that zlib_filter's creation function uses SEPARATE_ZVAL()
to separate from the passed in filter parameters. Unfortunately, I
don't think
Hello all,
Those of you who are saying things like "forget the idiots using
magic_quotes" need to understand more clearly what is being proposed.
NOBODY is proposing keeping magic_quotes.
As of PHP 5.3 and earlier, all applications worth an ounce of anything
must check for and handle magic_quotes
Gregory Beaver wrote:
> Hi Marcus,
>
> FYI, this change:
>
> http://cvs.php.net/viewvc.cgi/php-src/ext/spl/spl_directory.c?view=diff&r1=1.146&r2=1.147
>
> breaks about 20 tests in phar, it's a potentially serious BC break. I
> understand the reasoning behin
Hi Marcus,
FYI, this change:
http://cvs.php.net/viewvc.cgi/php-src/ext/spl/spl_directory.c?view=diff&r1=1.146&r2=1.147
breaks about 20 tests in phar, it's a potentially serious BC break. I
understand the reasoning behind it, but you may find other users up in
arms. The main problem is that thi
Jani Taskinen wrote:
> If those application are written properly, they also have to check for
> the existance of the functions even with current PHP version since it is
> possible to disable them altogether. So it shouldn't matter if they're
> removed for them.. ;)
It's possible to disable any fun
Lars Strojny wrote:
> Hi everyone,
>
> the following patch[1] adds the functions append_include_path() and
> prepend_include_path(). These function are there to make include path
> adjustments easier than it is. Especially append_include_path() is what
> is done most of the time.
>
> The current
Christopher Jones wrote:
>
>
> Steph Fox wrote:
>
>> 1) Distribution woes need to end. With the work Greg's been doing lately
>> on PHP_Archive/Phar, that's very close to being attainable now in the
>> physical 'getting PECL'd extensions out to people' sense, but unless
>> people are running CLI
Christian Schneider wrote:
> So my favourite solution (apart from allowing include in class
> definitions ;-)) would be
> trait foo { ... }
> ...
> class B
> {
> trait foo; # All functions from foo
> trait bar(a); # Only function a from bar
> trait qux(not
Marcus Boerger wrote:
> Hello Lukas,
>
> alright,
>
>'foo as bar' is ok to me and does not even add a new keyword.
> Ignore or any more keywords are bad and I also think that the correct
> would be hide(ing). But as I further more explained it should really be
> something that only marks a
Lukas Kahwe Smith wrote:
>
>> I have been uncomfortable with the current trait suggestions because
>> they occur in the body of the class, whereas extends/implements is
>> outside. I think there is a way to handle this, however.
>
> I dont agree here. traits are different. They do not affect "what
Stefan Marr wrote:
> To get rid of exclude and rename I would like to propose the following:
>
> //Example from the RFC with the cross-over conflict to be solved
> trait A {
> public function smallTalk() {
> echo 'a';
> }
> public function bigTalk() {
> echo 'A';
> }
> }
>
> tr
Lukas Kahwe Smith wrote:
>
> On 26.02.2008, at 04:19, Gregory Beaver wrote:
>
>> My only objection is that this introduces two new keywords, trait and
>> instead. In addition, this can get very awkward if multiple traits
>> (more than 2) implement the same method nam
Marcus Boerger wrote:
Hello Pierre,
Saturday, March 1, 2008, 8:53:26 PM, you wrote:
and yeas after several years of trying to communicate and never gotten
anything back? I have told PREAR development a million times to fix code.
Now not even PEAR code is wrong but it is copied into endless amou
Dmitry Stogov wrote:
> dmitryWed Mar 5 13:34:16 2008 UTC
>
> Modified files: (Branch: PHP_5_3)
> /php-src NEWS
> /php-src/main fopen_wrappers.c fopen_wrappers.h main.c
> /ZendEngine2 zend.c zend.h zend_vm_def.h zend_vm_execute.h
> Log:
>
Johannes Schlüter wrote:
> Hi all,
>
> recently there were quite a few proposals about stuff for 5.3. If we
> implement
> them all we won't finish in a "soonish" time and we get new ideas postponing
> the 5.3 release therefore the following:
>
> - Scanner based on re2c:
> Going to re2c prom
Hi,
I found some time to whip up a quick patch against 5.3.
This patch allows adding stream wrappers to include_path on both windows
and unix. This means one can set an include_path to
".:/usr/local/lib/php:phar:///path/to/ZF.phar/lib" or the windows
equivalent ".;C:\php5;phar://C:/php5/ZF.phar/
Antony Dovgal wrote:
> On 07.03.2008 05:43, Gregory Beaver wrote:
>> Just a quick note: I'd like to consider another possible approach,
>> having pecl/phar synced from stable pecl release.
>
> I'm not sure it's good idea.
> IMO it should go trough much mo
Hi,
When I posted yesterday's patch to add stream support to include_path
(http://news.php.net/php.internals/36031) I mentioned that I suspected
benchmarking would reveal it to be slow. My primary goal is to provide
no impact on current users who are using a traditional include_path,
with a secon
Hi,
php_resolve_path does not exit if passed a stream wrapper, but instead
tries to find it in include_path. This can cause really weird error
messages and breaks pecl/phar completely (and probably other stream
wrappers), so I added stream wrapper detection to the exit shunt in the
start of php_r
Alexey Zakhlestin wrote:
> what about including(_once) by absolute path?
>
Hi,
There is no difference from the existing code for include_once, the
first line of php_resolve_path has a check for IS_ABSOLUTE_PATH, all of
the code I wrote follows this line. Calls to include (no _once) would
add
Hi,
Here's the last attempt at streams support in include_path.
After siccing callgrind on the patch, I'm confident it meets performance
requirements. Even in the worst case, it is significantly faster than
PHP 5.2, and insignificantly slower (1%) than the current CVS.
This patch is optimized
Hi,
Please look at the stream wrappers in include_path patch I posted last week.
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Dmitry Stogov wrote:
> Hi Greg,
>
> I've fixed your patch to work with all functions (fopen,
> file_get_contente).
> Please verify it with ext/phar and then I'll commit it.
>
> Thanks. Dmitry.
>
> Gregory Beaver wrote:
>> Hi,
>>
>> Please loo
1 - 100 of 256 matches
Mail list logo
