Hi Greg,
On Mon, Jun 23, 2008 at 5:32 AM, Greg Beaver <[EMAIL PROTECTED]> wrote:
> phar is enabled by default in order to fully test it prior to the first RC.
> I proposed[1] that a final vote be undertaken just prior to the 5.3RC1
> release on phar's ultimate fate.
You misread my question. Why
Generating phar.phar
Unknown parameter '-f' to command pack, check ext/phar/phar.php help
make: *** [ext/phar/phar.phar] Error 1
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internal
Pierre Joye wrote:
hi Greg,
On Sun, Jun 22, 2008 at 10:50 PM, <[EMAIL PROTECTED]> wrote:
Hi,
Steph, look more closely, the libraries are only used if openssl is built
statically. Otherwise, phar directly calls openssl_verify or openssl_sign.
By the way, any reason why phar is buil
Hello,
On Mon, Jun 23, 2008 at 12:44 AM, Jochem Maas <[EMAIL PROTECTED]> wrote:
> Etienne Kneuss schreef:
>>
>> Hello,
>>
>> On Sat, Jun 21, 2008 at 2:51 AM, Stanislav Malyshev <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Hi!
>>>
So, I really would like to revert that foward_static_call stuff and
>
hi Greg,
On Sun, Jun 22, 2008 at 10:50 PM, <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Steph, look more closely, the libraries are only used if openssl is built
> statically. Otherwise, phar directly calls openssl_verify or openssl_sign.
By the way, any reason why phar is built statically by default?
Etienne Kneuss schreef:
Hello,
On Sat, Jun 21, 2008 at 2:51 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
Hi!
So, I really would like to revert that foward_static_call stuff and
implement the parent:: patch instead, while it's still possible.
thoughts?
Didn't we discuss that already? Ad
Hi!
Since 5.0 this would lead to $bar being false and not $array. While it
could be argued that the user should do an explicit cast himself, it was
still a clear BC issue that caused a lot of issues for developers.
Generally I think it would be nice if all functions behaved uniformly
(i.e. z
Hi,
Steph, look more closely, the libraries are only used if openssl is built
statically. Otherwise, phar directly calls openssl_verify or openssl_sign.
Greg
-Original Message-
From: "Steph Fox" <[EMAIL PROTECTED]>
Subj: OpenSSL and Phar
Date: Sun Jun 22, 2008 4:32 pm
Size: 701 by
On 22.06.2008, at 23:21, Stanislav Malyshev wrote:
Hi!
is this in any way related to the parameter parsing API change that
caused the BC break in array_merge() back in PHP 5.0? If so then I
would
I don't really remember about array_merge in detail, but this change
shouldn't (I know, fa
Hi!
is this in any way related to the parameter parsing API change that
caused the BC break in array_merge() back in PHP 5.0? If so then I would
I don't really remember about array_merge in detail, but this change
shouldn't (I know, famous last words :) create any BC break unless you
rely o
On Sun, Jun 22, 2008 at 10:32 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> It seems we don't use the openssl extension API at all in ext/phar, just the
> actual OpenSSL headers and libs. That means Phar with OpenSSL support can be
> both built and run without ext/openssl being built at all, but requ
On Sun, Jun 22, 2008 at 10:32 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> It seems we don't use the openssl extension API at all in ext/phar, just the
> actual OpenSSL headers and libs. That means Phar with OpenSSL support can be
> both built and run without ext/openssl being built at all, but requi
Hi Greg, all,
It seems we don't use the openssl extension API at all in ext/phar, just the
actual OpenSSL headers and libs. That means Phar with OpenSSL support can be
both built and run without ext/openssl being built at all, but requires
third-party libs (under Windows at least - ssleay32.d
On Fri, 20 Jun 2008, Etienne Kneuss wrote:
> To sum up key points about each possibilities:
>
> 1) forward_static_call
> + no need to affect the engine
> - slow, painful
>
> 2) parent:: carries the info while ParentClassName:: doesn't
> + convenient
> + no functionnality lost
> - introduces a di
Hi Etienne,
Am Freitag, den 20.06.2008, 18:04 +0200 schrieb Etienne Kneuss:
[...]
> 2) parent:: carries the info while ParentClassName:: doesn't
> + convenient
> + no functionnality lost
> - introduces a difference between parent:: and classname::, but
> restricted to LSB so no BC break
Thanks fo
Hi Alex, hi Larry,
Am Freitag, den 20.06.2008, 16:33 +0200 schrieb Alexander Wagner:
[...]
> I agree. "use" for both namespaces and closures may not be a good idea.
> Otherwise +1 to this syntax for its low WTF-factor.
> Look like parameters. Behave like parameters.
Probably "reuse" as in "reuse
On Sun, Jun 22, 2008 at 11:18 AM, Pierre Joye <[EMAIL PROTECTED]> wrote:
>>
>> Ok, with the tests being ran we are minimizing the chances of bc break
>> but I agree and extra care should be applied. We'll make sure this
>> care is applied.
>
> http://wiki.php.net/doc/scratchpad/upgrade/53
I will
Hi David,
On Sun, Jun 22, 2008 at 5:09 PM, David Coallier <[EMAIL PROTECTED]> wrote:
>> is this in any way related to the parameter parsing API change that caused
>> the BC break in array_merge() back in PHP 5.0? If so then I would appreciate
>> extra care to be taken to minimize these kinds of B
>
> Ok, with the tests being ran we are minimizing the chances of bc break
> but I agree and extra care should be applied. We'll make sure this
> care is applied.
>
>
And sorry about the email before, I forgot to remove the junk. :)
--
Slan,
David
--
PHP Internals - PHP Runtime Development Mai
2008/6/22 Lukas Kahwe Smith <[EMAIL PROTECTED]>:
>
> On 20.06.2008, at 01:06, Stanislav Malyshev wrote:
>
>> While we nearing the release of 5.3 (hopefully?), there are many functions
>> in the PHP code which still use old parameter parsing API
>> (zend_get_parameters_ex) instead of the new one (ze
On 20.06.2008, at 01:06, Stanislav Malyshev wrote:
While we nearing the release of 5.3 (hopefully?), there are many
functions in the PHP code which still use old parameter parsing API
(zend_get_parameters_ex) instead of the new one
(zend_parse_parameters).
is this in any way related to
21 matches
Mail list logo
