[PHP-DEV] Bugs assigned to cellog

Hi, I will be unable to fix even the smallest bugs assigned to me, it would of great assistance if a developer who has both time and a reliable Internet connection would step in and fix them. The phar.phar bug should be easy. The tar/zip difference needs a sample zip that does not work and the o

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/phar/tests ini_set.phpt

Hannes Magnusson wrote: > What about 5.2? I thought the extension was supposed to work fine > there too (at least there are bunch of tests that skip with the reason > "needs 5.2"). So you have three branches in pecl? HEAD, PHP_5_3 and > PHP_5_2? > (Not that fix is required in 5.2, everyone who did

[PHP-DEV] problem with include_path and write-based file functions

Hi, This bug: http://bugs.php.net/bug.php?id=46680 uncovers 2 larger issues. 1) Where should a function like file_put_contents() create its file if it doesn't already exist and FILE_USE_INCLUDE_PATH is specified? The test for this is ext/standard/file/file_put_contents_variation4.phpt and a fe

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/phar/tests ini_set.phpt

Hannes Magnusson wrote: > bjori Tue Dec 9 13:02:40 2008 UTC > > Modified files: (Branch: PHP_5_3) > /php-src/ext/phar/tests ini_set.phpt > Log: > MFH: fix test > > > http://cvs.php.net/viewvc.cgi/php-src/ext/phar/tests/ini_set.phpt?r1=1.4.2.1&r2=1.4.2.2&dif

Re: [PHP-DEV] Re: Namespace resolution rules has been changed?

David Grudl wrote: > Try to answer the question: what is the $obj instance of? > > namespace foo; > $obj = $factory->loadClass('bar\class'); bar\class dynamic class names are always FQN. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/uns

Re: [PHP-DEV] Re: Namespace resolution rules has been changed?

Stan Vassilev | FM wrote: >> Hi Marcin, >> >> Stan also requested this, so it should be considered as a possibility. >> >> Personally, I would rather not introduce this land mine. It requires >> the user to do an implicit prepending of namespace name ("foo") to "bar" >> in the use statement as wel

[PHP-DEV] Re: Namespace resolution rules has been changed?

Marcin Kurzyna wrote: > > namespace foo; > > use bar as A; /// ->resolves as A == \foo\bar > use \bar as B; /// ->resolves as B == \bar > > ?> Hi Marcin, Stan also requested this, so it should be considered as a possibility. Personally, I would rather not introduce this land mine. It req

[PHP-DEV] Re: Namespace resolution rules has been changed?

Jaroslav Hanslík wrote: > David Grudl napsal(a): >> Hello! >> >> This code leads to fatal error: Class 'Nette\Loaders\Nette\Object'. Is >> it a bug in current implementation or namespace resolution rules has >> been changed? >> >> namespace Nette; >> >> class Object >> >> {} >> >> namespace Nette\L

[PHP-DEV] karma request

Hi, I'd like to request karma for ZE in order to do minor bugfixes and refactoring. I have no intention to commit any feature changes or major commits, and am perfectly happy writing patches for these to be reviewed by the big guns. Thanks, Greg -- PHP Internals - PHP Runtime Development Maili

Re: [PHP-DEV] [PATCH] bracketed namespace declarations

Steph Fox wrote: > Hey Greg, > >> Remember, the patch I'm proposing would only be necessary for people >> using un-namespaced code combined with namespaced code (already a bad >> idea) *and* scattering "use" statements throughout the global code. > > If it's 'already a bad idea', why support it?

Re: [PHP-DEV] [PATCH] bracketed namespace declarations

Stan Vassilev | FM wrote: > // global, scope 1 > > namespace { // global, scope 2 } > > // global, scope 1 > > namespace { // global, scope 3 } > > // global, scope 1 > > namespace foo\bar { // foo\bar, scope 4 } > > // global, scope 1 > ?> I am afraid I must shed my generally congenial pu

[PHP-DEV] [PATCH] bracketed namespace declarations

Hi, Stas and company decided that they wanted namespaces to have two legal syntax choices: 1) single namespace per file: 2) multiple namespaces per file: I've implemented these two syntax options in a patch found at http://pear.php.net/~greg/bracketed.patch.txt based on earlier work of Dmit

Re: [PHP-DEV] Call it: allow reserved words in a class or not?

Dan wrote: > Quite. > > It does appear as though, as a group, that you're struggling with the entire > concept of namespaces. As demonstrated by this discussion, the resolution > issues, the separator farce, and so on. > > It may be due to weaknesses in the PHP engine as a whole, I don't know...

[PHP-DEV] fixing opcode modification in namespace implementation

Hi, I assigned this to helly arbitrarily, but wanted to make sure that Stas and Dmitry also see it. This should be fixed ASAP. The opcode modification was easy to fix, since we weren't using op1. I also fixed a cosmetic issue Dmitry wanted fixed, which was replacing the non-verbose 1 and 2 used

Re: [PHP-DEV] Re: Namespace Resolution

Lukas Kahwe Smith wrote: > > On 04.11.2008, at 18:43, Ryan Panning wrote: > >> Just to make my post clear, I'm in favor of this approach for >> non-qualified calls in a namespace. >> >> 1. global >> 2. autoload >> 3. fail > > > A couple of us (Hannes, Stas, Derick, Matt Wilson and I) were just

[PHP-DEV] Re: 5.3+ build broken, see compile log

Pierre Joye wrote: > Hi, > > A commit in the last 24 hours breaks the builds: > > d:\php-sdk\snap_5_3\vc9\x86\snap53_vc9\zend\zend_vm_execute.h(2735) : > error C2036: 'void *' : unknown size > d:\php-sdk\snap_5_3\vc9\x86\snap53_vc9\zend\zend_vm_execute.h(10445) : > error C2036: 'void *' : unknown

Re: [PHP-DEV] namespace separator and whining

Lukas Kahwe Smith wrote: > > On 04.11.2008, at 17:15, Gregory Beaver wrote: > >> In other words, it is perfectly all right to have a different name >> resolution for classes than we have for functions and constants because >> of this different expectation. It i

Re: [PHP-DEV] namespace separator and whining

Christian Schneider wrote: > Lukas Kahwe Smith wrote: >> one could also do >> 1) ns >> 2) global >> 3) autoload > > I'm in favour of this (if it avoids performance problems) as I don't see > a problem with giving global priority over autoload. Hi, This is the current name resolution. The proble

[PHP-DEV] Re:

David Grudl wrote: > I hope it is only very bad joke :-( > > > namespace myNamespace; > > class theLoader > { >function load($class) { ... } > } > > > // somewhere else > spl_autoload_register(array("myNamespace\theLoader", "load")); > -> registers myNamespaceheLoader::load() Fortunately,

Re: [PHP-DEV] UltraSimple Namespace Solution

Nathan Rixham wrote: > seen. Personally though I'd love to see stas' #1 get implemented and > "->" used for all functions in a namespace so.. > one::step::two(); //always static method of class > one::step->two(); //always function of namespace. > > But it's still ambiguous (only in a rarely thoug

Re: [PHP-DEV] my last attempt at sanity with namespaces

Stanislav Malyshev wrote: > Hi! > >> Yes, but most times when there is conflict it will be between two >> sets of code. So importing someone else's namespace explicitly and >> giving it a new name is a good call IMHO. > > If you have two distinct sets of code, why you use same namespace for > both

[PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work

Hi again, I was asked to explain why I hadn't included ClassName->Method(); in the list of ideas that solve the ambiguity problem. I added a brief section to the RFC that does so: http://wiki.php.net/rfc/namespaceissues#why_stas_s_proposed_solution_doesn_t_work Thanks, Greg -- PHP Internals -

[PHP-DEV] turn off gcov for php 4.4?

Hi all, Isn't it time to retire PHP 4.4 in gcov.php.net? It's just wasted resources for that version Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] question on how to solve major stream filter design flaw

Marcus Boerger wrote: > The filters need an input state and an output state. And they need to > respect the the fact that number of requested bytes does not necessarily > mean reading the same amount of data on the other end. In fact the output > side does generally not know whether less, the same

[PHP-DEV] question on how to solve major stream filter design flaw

Hi, I'm grappling with a design flaw I just uncovered in stream filters, and need some advice on how best to fix it. The problem exists since the introduction of stream filters, and has 3 parts. 2 of them can probably be fixed safely in PHP 5.2+, but I think the third may require an internal red

Re: [PHP-DEV] namespace issues

Vesselin Kenashkov wrote: > I'm -1 for "removing constants and functions from the namespaces". As I > wrote already in another thread, is it possible to have a fatal error thrown > when the engine detects an ambiguity situation? Are there any logical (i > mean from OOP point of view) or internals (

[PHP-DEV] Re: Disable PHAR by default

Jani Taskinen wrote: > Seems like PHAR causes quite unexpected things, f.e. > http://bugs.php.net/bug.php?id=46194 where PHP crashes if file does not > exist. Please, can this crap be disabled by default (ALWAYS) and only > those who actually need it can enable it? Hi Jani, Classic overreacting,

Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant

Daniel Convissor wrote: > On Mon, Sep 22, 2008 at 08:07:10PM +0400, Dmitry Stogov wrote: > >> Yes. Changing :: into any other separator solves the functions/static >> methods and constants ambiguity, but it also breaks intuitive syntax. > > Which is more important? Considering there have been th

Re: [PHP-DEV] true namespaces, yet another point of view

Lukas Kahwe Smith wrote: > > On 24.09.2008, at 01:17, Guilherme Blanco wrote: > >> For those that do not understand very well the explanation of jvlad... >> >> He's suggesting to change the class struct to be an scope struct, and >> have a property that tells if it's a namespace or a class, and r

Re: [PHP-DEV] alpha3

jvlad wrote: >> Adding support for functions, constants and even variables is actually >> quite do-able with the solution I suggested (different separator between >> namespace name and function/constant/variable name) and can be added >> easily. > >> Adding support for functions, constants and ev

Re: [PHP-DEV] solving the namespace conflict issues between function/staticmethod class constant/ns constant

Dmitry Stogov wrote: > Hi Greg, > > Greg Beaver wrote: > >> Lupus Michaelis wrote: >> >>> Larry Garfield a écrit : >>> >>> I agree that #5 seems like the best solution. The problem is caused by the double meaning of ::. All of the other solutions feel like bandaids.

Re: [PHP-DEV] solving the namespace conflict issues between function/static method class constant/ns constant

Larry Garfield wrote: > On Saturday 20 September 2008 6:43:41 pm Richard Quadling wrote: > 5) a simply syntax change to namespaces, introducing a new concept: namespace element. A namespace element is a class, function or constant defined within a namespace declaration: >>

[PHP-DEV] Re: Namespaced function vs static method in global class

Ionut Gabriel Stan wrote: > echo Test::foo(); // outputs namespace function > echo ''; > echo ::Test::foo(); // outputs namespace function > My questions are: > > 1. How should I call the static method foo in the global class Test (except > for call_user_func) > 2. How should I call the sta

[PHP-DEV] Re: [PATCH] Re: [PHP-DEV] namespace examples (solving name resolutionorderissues)

Stanislav Malyshev wrote: > Hi! > >> In other words, there is simply no comparison. Userspace class usage >> outnumbers internal class usage by an order of magnitude in typical OO >> PHP code. > > I didn't claim userspace class usage outnumbers internal class usage > or otherwise. What I claimed i

[PHP-DEV] Re: [PATCH] Re: [PHP-DEV] namespace examples (solving name resolutionorderissues)

Stanislav Malyshev wrote: > Hi! > >> The caching is at runtime. Basically, it's in executor_globals, and so >> is not linked to any opcode array (I couldn't figure out any other >> globally accessible storage location). It works like an associative >> array. If file X.php loads XMLReader in nam

[PHP-DEV] Re: Scoping of "use" statements and a strategy for 5.3/6.0 release of namespace

Hi Stan, I realized I missed 2 of your points, response below: Stan Vassilev | FM wrote: > Hi, > > Multiple namespaces per file were introduced to allow certain > workflows in PEAR and frameworks like Symphony which can combine > multiple classes and namespaces in a single package. > > They wor

[PHP-DEV] Re: [PATCH] Re: [PHP-DEV] namespace examples (solving name resolutionorder issues)

Hi, This is the 2nd of two exchanges that occurred off-list that Stas and I would like to put back on-list. Greg === Stanislav Malyshev wrote: > > Hi! > > >> >> Basically, the patch does 2 things >> >> >> >> 1) resolution order is changed to: >> >> >> >> foo.php: >> >> $a = new foo(); >> >> a) do

[PHP-DEV] Re: [PATCH] Re: [PHP-DEV] namespace examples (solving name resolutionorder issues)

Stas and I continued our discussion off list, and decided to pop it back on the list, so here is 1 message, another to follow. Greg === Stanislav Malyshev wrote: > > Hi! > > >> >> ...the message you replied to? > > > > I must be missing something here. In my last reply, I raised a number > > of p

[PHP-DEV] Re: namespace RFC

Lukas Kahwe Smith wrote: > Hello all, > > All the recent discussions about namespaces, have left many of us > wondering if our implementation is rock solid or not. However the > discussions were not really well organized. This is why I am thankful > that Marcus and Felipe have spend the better par

Re: [PHP-DEV] Inconsistencies in 5.3

Lukas Kahwe Smith wrote: > > On 13.08.2008, at 22:18, Stanislav Malyshev wrote: > >> Simply include a script from two locations with different namespaces >> or one >>> >>> with namespace and the otherone without. >> >> I'm afraid you misunderstand how namespaces work. As I explained >> numerous t

Re: [PHP-DEV] enabling everything by default

Antony Dovgal wrote: > On 01.08.2008 14:11, Antony Dovgal wrote: >> I can agree that disabling something that was already enabled in 5.2 >> might create some confusion, but why enable scarcely created >> extensions by default, especially if they are known to cause lost of >> obscure problems in the

[PHP-DEV] Re: simple solution to another namespace conundrum?

Jessie Hernandez wrote: > Hi Greg, > > How is this different from my original proposal > (http://news.php.net/php.internals/34097, > http://news.php.net/php.internals/34097)? > > The patch committed only affects non-namespaced code, your proposal affected all code. In other words, this always wor

[PHP-DEV] Re: simple solution to another namespace conundrum?

Dmitry Stogov wrote: > Looks fine, but probably we should emit error only if class declared in > the same source file. > > Thanks. Dmitry. > Great, didn't realize how easy this would be. Attached patch does this, but requires another test: 067.php.inc: --TEST-- 067: Name ambiguity (import n

[PHP-DEV] simple solution to another namespace conundrum?

Hi, You probably have seen Derick's blog post http://www.derickrethans.nl/namespaces_in_php.php It occurred to me today that there might be a simple, elegant solution to this problem. First, let's imagine someone writes this code: Now, in PHP 5.4, we introduce an internal class "Closure" and

[PHP-DEV] interesting update on phar performance

Hi all, I decided to run my standard phpMyAdmin test without APC enabled and got startling results from siege: Date & Time, Trans, Elap Time, Data Trans, Resp Time, Trans Rate, Throughput, Concurrent,OKAY, Failed 2008-06-20 02:02:35,915, 60.01, 1, 0.98,

[PHP-DEV] Re: FastArray, great addition

Pierre Joye wrote: > hi all, > > As you noticed already PHP finally got simple C-like array, thanks to > Etienne and Tony for their great work! > > My only wish is to actually respect the informal decision we took a > while back, to do not use "fast", "improved", "better" or similar > wording in

[PHP-DEV] heads up: new people in power at PEAR

Hi, For the past year, I have been representing PEAR as its president, but decided not to seek re-election in order to pursue more heavily development on phar and pyrus. As of today, we finished our second set of elections, and I'm happy to announce that David Coallier will be taking my place as

[PHP-DEV] potential shutdown order issue

Hi, I'm getting errors of hashtable already destroyed when running phpMyAdmin with PHP 5.3, and (of course), thinking this is a phar issue, I've traced through and found a problem in the shutdown order. Basically, php_request_shutdown() calls zend_deactivate() which calls zend_destroy_rsrc_list(&

[PHP-DEV] phar development update

Hi all, A quick note on significant improvements to phar committed recently: * tar-based archives now fully support metadata and signatures, bringing them in line with more of the features of phar-based phar archives. * true asymmetric signing support using OpenSSL private/public key pairs * p

[PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_alloc.h

Matt Wilmas wrote: > mattwil Fri Jun 13 04:16:59 2008 UTC > > Modified files: (Branch: PHP_5_3) > /ZendEngine2 zend_alloc.h > Log: > MFH: Add pestrndup() Thanks Matt Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: h

[PHP-DEV] [PATCH] add pestrndup

Hi, I need this patch committed ASAP to PHP_5_3 zend_alloc.h, as the commit I just made for ext/phar depends on it (oops). Could someone help me out? Thanks :), Greg Index: zend_alloc.h === RCS file: /repository/ZendEngine2/zend_all

[PHP-DEV] missing pestrndup

Hi, Is there any reason pestrndup is missing from PHP 5.3's zend_alloc.h but is present in HEAD? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CVS Account Request: baptiste750

Hannes Magnusson wrote: > On Wed, Jun 11, 2008 at 22:15, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: >> Actually, checking through my group@ archive, I don't see 2 messages from >> you. The only one I see from you is one from June 9 complaining that your >> cvs account wasn't granted. I see that so

[PHP-DEV] Re: Calling original function from an overloaded function

Christoph Dorn wrote: > I have been looking at xdebug and have figured out how to overload a > function. As a test I have overloaded the var_dump function. > > Now how do I call the original var_dump function from my implementation? > Borrowing from OO terminology I have subclassed the var_dump me

Re: [PHP-DEV] [PATCH] fix building openssl shared on unix in 5.3

Pierre Joye wrote: > hi Greg, > > Please commit it, thanks for the patch! > > Someone with ZendEngine2 karma will need to commit. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] fix building openssl shared on unix in 5.3

Hi, I was trying to test building openssl shared, and ran into an unexported symbol issue because the arginfo constant arrays are never exported for dll/so use. Could someone check out this patch and make sure it doesn't fubar windows in particular? The same patch will apply in all branches just

[PHP-DEV] Re: Short syntax for array literals [...]

I've thought about allowing [] for a while and personally have come up with my own litmus test for new features. 1) is the syntax missing from the language? 2) if so, does the syntax add missing functionality or significant maintenance benefit? 2) if not, does the new syntax add significant value?

Re: [PHP-DEV] magic quotes finale

Rasmus Lerdorf wrote: > I see absolutely no reason to force people to go through and change: > > if(!get_magic_quotes_gpc()) > > to: > > if (!function_exists('get_magic_quotes_gpc') || !get_magic_quotes_gpc()) > > when there is no technical reason to force them to do so. It is slower, > more v

[PHP-DEV] HEADS UP: phar now enabled statically by default

Hi, I've reversed my initial patch enabling phar as shared by default, and instead now enable it statically by default. I was able to solve the dependency on zlib/bz2 I noted in my last message through some very simple logic, and testing confirms that phar can be built statically with zlib/bz2 sh

Re: [PHP-DEV] Re: 5.3 Namespace resolution rules suggestions

Stanislav Malyshev wrote: > Hi! > >> $classes = ::get_declared_classes(); >> $classes = ::array_merge($classes, ::get_declared_interfaces()); >> $this->classes = ::array_flip($classes); >> unset($this->classes['NSParser::Parser']); >> $functions = ::get_defin

Re: [PHP-DEV] Re: 5.3 Namespace resolution rules suggestions

Stan Vassilev | FM wrote: > Hi, > > I'd like to nudge the discussion back to issues with the resolution > rules that we're discovering :) > The actual char(s) used can only be mildly annoying to some (at worst), > compared. > > Can we please agree on those (or explain why you'd not): > > 1) func

[PHP-DEV] Re: 5.3 Namespace resolution rules suggestions

Nathan Rixham wrote: > Ryan Panning wrote: >> Jessie Hernandez wrote: >> > Hi Stan, >> > >> > I made a proposal and patch a few months ago... >> >> The developers should really take a serious look at this issue or it >> will come back to haunt them later. I'm not sure why no one seems >> comment

[PHP-DEV] Re: Please help about zend engine

Andreas K Santoso wrote: > Hello sir/ma'am > > My name is andre from Indonesia. I am a student of a university, and > i'm doing my thesis. I subscribe to this list to look for some help. > Oh by the way, my thesis is about PHP file encryption. So i need to > decrypt the file when it's accessed an

[PHP-DEV] phar enabled by default as of now

Hi, I just committed to ext/phar's config.m4/w32 to make phar enabled by default as a shared extension. This is a better default setting than building phar in statically, as phar has optional dependencies on the zlib and bz2 extensions to enable compressed phar archives. If phar is built statica

[PHP-DEV] objection to enabling phar for testing in 5.3?

Hi, I wonder if there is any objection to this plan: 1) enable phar by default for the PHP 5.3 betas, so that it can receive full testing 2) before RC1, do the formal vote on whether it should be enabled by default in the release This way, phar can be tested for the possibility of enabling, but

Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar

Richard Quadling wrote: > 2008/5/13 Antony Dovgal <[EMAIL PROTECTED]>: > >> On 13.05.2008 01:45, Gregory Beaver wrote: >> >>> Thanks to all who have contributed, particularly Marcus, Steph, Lars, >>> and the o

Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar

Steph Fox wrote: > Hi Hannes, > >> Munch better, only 42 failures now. >> 001+ Content-type: text/html; charset=utf-8 >> 001- Content-type: text/html >> >> Looks like all of them are failing like this. > > That's really not a lot to go on. Which are 'all of them'? The > frontcontrollers? I would g

[PHP-DEV] [HEADS UP] pecl/phar is now ext/phar

Hi, It's time for helly's birthday present from me (and indirectly, Derick, who did the cp -r) :). As Johannes requested, pecl/phar has been copied to php-src/ext/phar, development will continue there. I suspect there may need to be some changes at gcov.php.net to keep things running smoothly, s

[PHP-DEV] [PATCH] major bug in mmap of lexer

Hi, Today while testing phar with phpMyAdmin, I was getting a really weird error - one of the files was turning into a series of Z's, munging the entire display. Thinking it was a phar issue, I instead tracked it down to a major problem in an edge case of zend_stream_fixup(). For files that are

Re: [PHP-DEV] php_stream_display_wrapper_errors issue

Pierre Joye wrote: > Hi Greg, > > On Mon, Apr 14, 2008 at 12:17 AM, Gregory Beaver <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> If a stream wrapper does not log errors, by default, we grab >> strerror(errno) to figure out the error message, but this

[PHP-DEV] php_stream_display_wrapper_errors issue

Hi, If a stream wrapper does not log errors, by default, we grab strerror(errno) to figure out the error message, but this is not a good idea for any wrapper but plain_wrapper for the obvious reason that errno is not used by wrappers that don't use sys calls. Is this patch against 5.3 acceptable

Re: [PHP-DEV] spl documentation

Philip Olson wrote: > >>> On 11/04/2008, Alexey Zakhlestin <[EMAIL PROTECTED]> wrote: I noticed, that http://www.php.net/~helly/php/ext/spl/was updated almost a year ago. Is the newer version available anywhere? >>> >>> Good point,

[PHP-DEV] phar API update

Hi, A quick update on Phar's API for those who are keeping score: 1) Phar->isWritable() now works properly and does what Liz was hoping: tells you whether you can actually modify the phar archive by looking at the archive's file perms as well as phar.readonly 2) PharFileInfo->getContent() added t

[PHP-DEV] $phar->isWritable() works now too

Hi, I re-read the messages, and realized I had misunderstood what was being requested, although it did pay off in finding a subtle bug in is_writeable() for files within a phar. I just implemented Phar->isWritable(), which can be used to detect the right combination of file permissions, archive t

[PHP-DEV] phar['blah.php']->isWritable() works now

Hi, There were some rumblings about wanting a way to detect whether a specific file/archive was writeable. I made some small changes to the way we detect this when the ini setting is changed, and added a test. Now the existing isWritable() from SplFileInfo always works properly for Phar. In add

[PHP-DEV] phar API update

Hi, I've just implemented these features: 1) new getContents() method allows directly retrieving file contents. Here is a full-circle example: getContents(); ?> 2) addFile/addEmptyDir/addFromString. API is identical to ext/zip addEmptyDir('hello'); var_dump($phar['hello']->isDir()); $phar->add

Re: [PHP-DEV] practical phar considerations

Steph Fox wrote: > Hi Greg, > >> What I would like to do, however, is to rethink offsetSet(). I think >> that we should introduce a property of PharFileInfo called "content" >> that is read/write, and can be used to perform the equivalent of >> file_get_contents()/file_put_contents(). This will

Re: [PHP-DEV] practical phar considerations

Pierre Joye wrote: > Hi, > > On Wed, Apr 9, 2008 at 6:48 AM, Gregory Beaver <[EMAIL PROTECTED]> wrote: > > >> For other examples, take a look at at >> ext/zip. There is no support for opendir() in the stream wrapper of >> ext/zip because it requires t

Re: [PHP-DEV] practical phar considerations

Lars Strojny wrote: > Hi Greg, > > Am Samstag, den 29.03.2008, 17:58 -0500 schrieb Greg Beaver: > [...] >> If one uses file_put_contents('/path/to/this/file', 'hi') and >> '/path/to/this' does not exist, there is an error. The same is true of >> fopen, regardless of mode. mkdir() even fails un

[PHP-DEV] Re: CVS Account Request: mimmi

Thomas Mueller wrote: > distributing a new package Which package? For what? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

Marcus Boerger wrote: > Hello Gregory, > > + for (p = ptr; isalnum((int)*p) || *p == '+' || *p == '-' || > *p == '.'; p++); > + /* p - ptr > 1 allows us to skip things like "C:\whatever" */ > + if ((*p == ':') && (p - ptr > 1) && (path_len - (p - path) >

Re: [PHP-DEV] Re: [RFC] Namespace syntax decision

Marcus Boerger wrote: > language out there that is in use and has anything like that. And even more > scary to me, you did not solve anything by this because people still could > write code prior to the namespace keyword. So no matter what we are screwed ? [EMAIL PROTECTED]:~/workspace/php5$ cat

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

Marcus Boerger wrote: > Hello Gregory, > > Tuesday, March 25, 2008, 8:01:56 PM, you wrote: > >> Stanislav Malyshev wrote: stream wrapper. Here is an example: oops.broken://UNC/path >>> I wonder if .://UNC/path is treated as "."+//UNC/path (and the same >>> for ..). It should anywa

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

Stanislav Malyshev wrote: >> stream wrapper. Here is an example: >> >> oops.broken://UNC/path > > I wonder if .://UNC/path is treated as "."+//UNC/path (and the same > for ..). It should anyway :) However I'm not too worried without > pathes like foo.bar - not likely to have path without any slash

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

Dmitry Stogov wrote: > I hope it's the last iteration, but check me anyway. > The patch is based on latest Gregory's patch. > > - optimized out strncpy() calls > - zend_resolve_path() replaced with php_resolve_path() > - improved php_resolve_path() to resolve "file://..." > - fixed possible double-

Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing

Steph Fox wrote: > What a horrible name :) How about pecl_graveyard? siberia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

Stanislav Malyshev wrote: >> this would unfortunately break UNC paths on unix, which start with //. > > Unix has UNC paths? Beats me, I'm sure posix-based systems don't, but it is called "Uniform Naming Convention" so it's possible somebody might implement it (http://en.wikipedia.org/wiki/Path_(

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

Dmitry Stogov wrote: > > > Gregory Beaver wrote: >> Dmitry Stogov wrote: >>> REALPATH_FAILED looks like a hack :( >>> PHP itself doesn't need it at all, according to your patch >>> php_stream_open() may just return NULL immediately instead of sett

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

Dmitry Stogov wrote: > REALPATH_FAILED looks like a hack :( > PHP itself doesn't need it at all, according to your patch > php_stream_open() may just return NULL immediately instead of setting > of this flag. > However I am not sure that it will work for all cases. The fact that > we cannot resolve

Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing

Steph Fox wrote: > Hello Pierre, > >>> Aside from Pierre's arguments in favour of using package.xml to set the >>> extension version (which 3 PECL extensions - two of them Pierre's - >>> do at >>> present), does anyone have any objection to the proposal at >>> http://wiki.php.net/rfc/peclversi

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

Marcus Boerger wrote: > Hello Gregory, > > Monday, March 24, 2008, 2:28:00 PM, you wrote: > > >> Index: main/fopen_wrappers.c >> === >> RCS file: /repository/php-src/main/fopen_wrappers.c,v >> retrieving revision 1.175.2.3.2.13.2.9

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

Dmitry Stogov wrote: > Hi Greg, > > In your second patch you forgot "break", so it couldn't work. > I don't see any reason in second patch at all, because you call > php_resolve_patch() from _php_stream_open_wrapper_ex() anyway. > > The bad thing with the first part that it calls realpath() functio

Re: [PHP-DEV] short_open_tag

Stefan Walk wrote: > Johannes Schlüter schrieb: >> Now we have the big issue: Do we want to have short open tags forever? >> Well, without tooo much thinking my idea would be to drop "> "> make it simple to do templating using PHP, on the other hand when not >> echo'ing stuff you already have to wr

Re: [PHP-DEV] Re: [RFC] Namespace syntax decision

Felipe Pena wrote: > Em Sex, 2008-03-21 às 17:01 -0500, Gregory Beaver escreveu: >>> 1) namespace foo { } >> This is acceptable if nothing can exist outside namespace foo {} except >> declare and other namespace declarations. >> > > Indeed! > >

[PHP-DEV] Re: [RFC] Namespace syntax decision

Marcus Boerger wrote: > Hello Internals, > > we all were asked to stop discussing syntax of namespaces as we were told > that we would decide after the namespace functionality was fully implemented. > Now I think that the functionallity is pretty much settled we should > revisit the syntax. We a

[PHP-DEV] Re: [RFC] Namespace syntax decision

Marcus Boerger wrote: > Hello Internals, > > we all were asked to stop discussing syntax of namespaces as we were told > that we would decide after the namespace functionality was fully implemented. > Now I think that the functionallity is pretty much settled we should > revisit the syntax. We a

Re: [PHP-DEV] REMINDER - stream wrappers in include_path

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

[PHP-DEV] REMINDER - stream wrappers in include_path

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

[PHP-DEV] [PATCH] fast streams support in include_path

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

Re: [PHP-DEV] profiling followup on addition of streams to include_path - it's *faster*

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

  1   2   3   >