Hi!
FYI, it seems pear.php.net <http://pear.php.net/> https certificate expired
today:
ERROR: The certificate of ‘pear.php.net’ is not trusted.
ERROR: The certificate of ‘pear.php.net’ has expired.
The certificate has expired.
(confirmed by checking it using a browser)
BR,
Jocelyn Fo
Are using it without really knowing it
2) Could experienced a major performance impact because of that, but don’t
really understand why
So deprecating it will at least lead to disabling by default the option in
those software, which is good :)
--
Jocelyn Fournier
Founder
M : +33 6 51 21 54 10
y the
problem.
Thanks !
Jocelyn
Le 04/10/2014 23:58, jocelyn fournier a écrit :
Hi,
It would perhaps be great to communicate on this nasty bug on the PHP
website ?
For example code based on amqplib + ssl
(https://github.com/videlalvaro/php-amqplib) is not working anymore as
well, and it could
Hi,
It would perhaps be great to communicate on this nasty bug on the PHP
website ?
For example code based on amqplib + ssl
(https://github.com/videlalvaro/php-amqplib) is not working anymore as
well, and it could be a headache to figure out why it's not working. I
assume a lot more libs coul
Hi Stas,
Actually I would love flushing ob_start() in my own shutdown function,
but since my application is a library called in auto_prepend_file, I
have to protect ob_start() from being flushed too early by some wrong
code in the client application.
Hence I'm removing the PHP_OUTPUT_HANDLER_C
Hi,
One line fix, nice :)
A quick question about how resources are freed :
if some variables are computed inside a singleton and read through a
myclass::instance()->get_my_variable(), should we expect to have those
variables available when calling ob_start() callbacks ?
From experiment, they
Hi,
Another possible behaviour would be to trigger a fatal when trying to
access a partially destroyed object in ob_start.
It took me a while to actually figure out why the memory was corrupted
when doing stuff in ob_start() (even before playing with the AMQP lib).
Having a fatal would allow me
The translations for other langages are currently misleading as well,
since it still mentions PHP5.6 is under development.
e.g. :
http://php.net/manual/fr/migration56.php
http://php.net/manual/de/migration56.php
...
Thanks,
Jocelyn
Le 29/08/2014 02:43, Alain Williams a écrit :
I notice t
Hi,
If https://bugs.php.net/bug.php?id=67644 could be fixed in 5.4.33 (and
5.5 as well) it would be really great !
Thanks,
Jocelyn
Le 28/08/2014 23:13, Stas Malyshev a écrit :
Hi!
5.6.0 has been released, and first thing I'd like to congratulate all
who participated in it with this great
Hi Laruence,
I do think that some people simply doesn't like phpng (for reasons mostly
not on technical grounds), and they are bringing up any issue which can
hinder the acceptance of phpng.
But I also think that documentation is important, and the reasoning that it
isn't based on the fact tha
Hi,
Le 14/07/2014 15:19, Andrey Andreev a écrit :
Hi,
On Mon, Jul 14, 2014 at 4:12 PM, Alexey Zakhlestin wrote:
Some people talk about inconsistency, which is introduced by reusing same syntax for
"strict parameter types" and "scalar parameter casts”. There’s some truth there.
Let’s use diff
Le 13/07/2014 18:15, Rowan Collins a écrit :
On 13/07/2014 17:09, Jocelyn Fournier wrote:
If "type hint" is doing exactly the same than explicit cast, it should
not fail on wants_array('abc'), but give a warning about the implicit
cast conversion.
Agreed, but that'
Le 13/07/2014 17:51, Rowan Collins a écrit :
On 13/07/2014 16:35, Jocelyn Fournier wrote:
That seems both inconsistent and less useful than a hybrid juggling +
validation approach.
Than means you find currently inconsistant than
$foo = (int) 'abc';
works but not
$bar = (ob
Le 13/07/2014 17:17, Rowan Collins a écrit :
On 13/07/2014 15:59, Jocelyn Fournier wrote:
From my point of view, if the type annotations are doing implicit cast
(with or without E_NOTICE/E_STRICT warning), they should behave
exactly the same than an explicit cast. If it behaves differently
Le 13/07/2014 17:01, Andrea Faulds a écrit :
On 13 Jul 2014, at 15:59, Jocelyn Fournier wrote:
From my point of view, if the type annotations are doing implicit cast (with
or without E_NOTICE/E_STRICT warning), they should behave exactly the same than
an explicit cast. If it behaves
Le 13/07/2014 16:41, Zeev Suraski a écrit :
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Sunday, July 13, 2014 5:34 PM
To: Zeev Suraski
Cc: Nikita Popov; PHP internals
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 13 Jul 2014, at 15:3
Le 13/07/2014 15:58, Andrea Faulds a écrit :
On 13 Jul 2014, at 14:54, Jocelyn Fournier wrote:
Ok, in this case I would suggest always displaying a warning in E_STRICT since
it's the whole purpose of the strict mode :)
Isn’t E_STRICT more for compile-time stuff? I’d think E_NOTICE
Le 13/07/2014 15:17, Andrea Faulds a écrit :
On 13 Jul 2014, at 14:13, Jocelyn Fournier wrote:
Actually displaying a warning in E_STRICT but still doing the implicit cast
would not change the function signature.
Sure. What I meant was more that we’re changing expectations based on
Hi,
Le 13/07/2014 14:56, Andrea Faulds a écrit :
On 13 Jul 2014, at 13:50, Jocelyn Fournier wrote:
Would it possible to control the implicit casting through a PHP variable ? (or
perhaps modify E_STRICT to display a warning if this kind of implicit cast is
done ?)
No. I mean, yes, it’s
Hi,
Would it possible to control the implicit casting through a PHP variable
? (or perhaps modify E_STRICT to display a warning if this kind of
implicit cast is done ?)
I mean specifying explicitly a type is often useful to make sure the
proper type is passed to the function, and there's no bu
thing completely different, but with the
same name as the "old" PHP 6. However I'm not convinced "7" is the right
choice, perhaps a radical change in version number would be better ?
--
Jocelyn Fournier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
21 matches
Mail list logo
