we have that already as part of the rmtools. The only data missing is
the list of branches as json, which is a simple export of the list
avaible in svn. I will add it and that's it.
The rest of the info, builds errors and co (like last available
revision) are already available as json data.
Maybe
Hey there,
I just noticed some inconsistencies in svn usernames used in
SVNROOT/global_avail.
After some shell magic involving sed,grep and diff these names don't
match the 1607 people on master, as of a few minutes ago.
Some are typos I think (sascha -> sas, pierre -> pajoye, ilia -> iliaa)
Hi,
I strongly recommend to submit the Strict session patch for
php-src(HEAD) because the vulnerability of PHP against the session
adoption/fixation attack is annoying issue of the PHP programmers for
many years.
I also suggest to apply this patch for PHP_5_4 after PHP 5.4.0 is
released. For PHP
Hi.
I mentioned this before, and I remembered yesterday when David updated the
README.RELEASE_PROCESS:
http://svn.php.net/viewvc?view=revision&revision=319009 :
Currently bugs.php.net uses the qa.php.net api to decide which PHP branch
are active, so what version should be listed for the bugreports
On Fri, Nov 11, 2011 at 22:43, Edward Z. Yang wrote:
> Excerpts from Rasmus Lerdorf's message of Fri Nov 11 15:45:27 -0500 2011:
>> Well, it is simple enough that we don't really need a patch. However,
>> generally if you want to submit a patch it needs to be against a current
>> svn branch and no
On Fri, Nov 11, 2011 at 10:43 PM, Edward Z. Yang wrote:
>> The other issue with your patch is that you are enabling this for the
>> fpm sapi. I thought we agreed that this should only be in the sapis that
>> supported dl() and those are cgi, cli and embed. And .user.ini doesn't
>> apply to embed,
Excerpts from Rasmus Lerdorf's message of Fri Nov 11 15:45:27 -0500 2011:
> Well, it is simple enough that we don't really need a patch. However,
> generally if you want to submit a patch it needs to be against a current
> svn branch and not an old release. You want to minimize the work people
> wi
hi,
On Fri, Nov 11, 2011 at 9:45 PM, Rasmus Lerdorf wrote:
> The other issue with your patch is that you are enabling this for the
> fpm sapi. I thought we agreed that this should only be in the sapis that
> supported dl() and those are cgi, cli and embed. And .user.ini doesn't
> apply to embed,
Hi internals!
I'd like to get some attention to bug #60039 [1]. It is about the
behavior of array_key_exists with "unusual" keys like floats, bools
and resources. Currently array_key_exists throws a warning if such a
key is passed. isset() on the other hand (and native array accesses in
general) t
Well, it is simple enough that we don't really need a patch. However,
generally if you want to submit a patch it needs to be against a current
svn branch and not an old release. You want to minimize the work people
will need to do to look at your suggested change.
The other issue with your patch i
Hi!
That's unless the spl_autoload_register() api changes and allows to deal with
errors - require(), Exception, ...
Autoloader shouldn't produce external errors - because if it's unable to
load class, others may be able. Also, it'd be quite hard to handle such
errors - you'd have to guard
http://svn.php.net/repository/php/php-src/branches/PHP_5_3
r318957
We also applied it to 5.3.8 release, although we had to fix up the patch
for that. I can port it to 5.4.
Edward
Excerpts from Rasmus Lerdorf's message of Fri Nov 11 14:38:13 -0500 2011:
> Which branch in this patch against? It d
Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk
It is short and simple so I could do it manually, of course, but I'd
like to know what you have been testing it against.
On 11/10/2011 07:14 PM, Edward Z. Yang wrote:
> Here is the proposed patch (sans tests; we did our own man
On Fri Nov 11 12:13 AM, Stas Malyshev wrote:
>
> > - MODE_DEBUG: This one can work together with the other two,
> > allowing a validation of class/interface/trait presence in the file.
> Basically,
> > it requires the file and then checks if the item exists in scope.
>
> Not sure debug adds much
You should always tie a patch to a bug/feature request. Need to know/remember
why the patch was applied in the first place.
On Nov 11, 2011, at 2:32 PM, Edward Z. Yang wrote:
> Well, I'm kind of hoping this patch will go in, so we don't have to bother
> with a bug. I can if you really want me to
Well, I'm kind of hoping this patch will go in, so we don't have to bother
with a bug. I can if you really want me to.
Cheers,
Edward
Excerpts from Christopher Jones's message of Fri Nov 11 14:28:30 -0500 2011:
>
> On 11/10/2011 07:14 PM, Edward Z. Yang wrote:
>
> > The change to zlist_clean is
On 11/10/2011 07:14 PM, Edward Z. Yang wrote:
The change to zlist_clean is necessary because otherwise extension_lists can't
be reused for the second round of extension appliations (since the head and
tail pointers have garbage in them). You should probably take that fix
regardless
of what y
Hi Rasmus:
First, sorry, I don't have currently the time to reiterate all discussions on
these questions.
Please, do me the favor and search the archives for previous discussions.
I believe _all_ points you raise here have been discussed and commented before,
and most of them quite recently.
Si
I keep most of this to other but two comments:
On Fri, 2011-11-11 at 11:00 -0500, Rasmus Schultz wrote:
> Lastly, when you reflect on a trait, it comes back as an instance of
> ReflectionClass. As pointed out, traits are probably more similar to
> interfaces than they are to classes, and they defi
It seems to me, there's a couple of things related to traits that were
missed in this implementation.
Take the following example:
script
terminates
public function addItem($item, $amount=1)
{
echo "Adding {$amount} {$item->getName()} to shopping cart - price =
".($amount * $item->getPric
On Fri, Nov 11, 2011 at 12:17 AM, Rasmus Lerdorf wrote:
> Hey Arpad, looking through the code you added to
> ext/standard/basic_functions.c it looks like you are doing some weird
> key handling in the shutdown function hash.
>
>
Hi Rasmus,
Thanks for the heads up, just fixed these.
Cheers,
Arp
Am 11.11.2011 12:53, schrieb Anthony Ferrara:
Would it not be possible that the autoloader mechanism catch all
exceptions
made by any autoloader which fails to load a class. Only if none of
the
register autoloaders can load the requested class the autoloader
mechanism
throws an AutoloadExcepti
> Yes, but even in that case the autoloader would not be triggered to
> load \Foo_Bar because if you already have used \Foo\Bar previously,
> that would have loaded \Foo_Bar as well.
Well, my original point is that what if both are not defined in the
same file. It's not that far fetched of an ide
2011/11/11 Anthony Ferrara :
[snip]
>> Actually they do not map the same file. Here is the path of each one:
>> new \Foo\Bar\Baz; => [path]/Foo/Bar/Baz.php
>> new \Foo\Bar_Baz; => [path]/Foo/Bar_Baz.php
>
> Well, as David pointed out, they do map to the same file. But even if
> they didn't, the
Anthony Ferrara wrote:
Since you asked me for feedback on how I would suggest improving the
RFC, so here it goes...
Silly question time ...
If I am reading all this correctly we are talking about how something is found
if I have not directly identified that I want to use it?
So if my base fr
Hi
.. snip ..
Hm... so there should never have the normal available?
I need to think over this again then. While I tend to agree with
autoloader never triggering errors or exceptions, the debug mode is
the unique way to notice if user during developer haven't done any
mistake.
Maybe we can only
26 matches
Mail list logo
