On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev wrote:
> Hi!
>
>> Libmcrypt is a dead cow but not much of a threat for now. On the other
>> hand cclient is dangerous, it should have been removed long time ago
>> already.
>
> I'm not sure - what is the dangerous part? Are you referring to some
>
Am 04.02.2015 um 08:25 schrieb Dmitry Stogov:
> The idea of that RFC was an ability to have zero-cost assert().
But an assert() is still in the body of a function or method and
not part of its signature. That is what I want scalar type
declarations for.
--
PHP Internals - PHP Runtime Develop
The idea of that RFC was an ability to have zero-cost assert().
DbC is a much more bigger feature, it is interesting, but requires
significant work.
Thanks. Dmitry.
On Wed, Feb 4, 2015 at 10:11 AM, François Laupretre
wrote:
> > De : Dmitry Stogov [mailto:dmi...@zend.com]
> > Hi Yasuo,
> >
>
Hi!
Our header() function supports multiline HTTP headers, which are allowed
by RFC 2616. However, newer RFC -
https://tools.ietf.org/html/rfc7230#section-3.2.4 - deprecates them and
says:
Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line wi
> De : Cesar Rodas [mailto:ce...@rodas.me]
> I have a doubt, is it efficient include/require files from a source
> different than the "real file system" a stream wrapper class? My
> question is, would the op-code cache work as it would when reading a
> file form the filesystem?
I understand your q
> De : Dmitry Stogov [mailto:dmi...@zend.com]
> Hi Yasuo,
>
> You probably talk about https://wiki.php.net/rfc/expectations
> I wasn't the author of idea, I just helped with thoughts and implantation.
> I think it may be useful for PHP7.
In accordance with Yasuo's suggestions, couldn't we conside
Hi!
> Libmcrypt is a dead cow but not much of a threat for now. On the other
> hand cclient is dangerous, it should have been removed long time ago
> already.
I'm not sure - what is the dangerous part? Are you referring to some
published CVEs or other reports? Then it would be useful to list them
On Feb 4, 2015 1:51 PM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > And at list this one living native PHP implementation
> > https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
> > more library links in the older thread link above).
>
> This is part of Horde with 9 listed depende
On Feb 4, 2015 1:30 PM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> I am kind of surprised that RFC about removing whole extensions has
> "Backward Incompatible Changes" listed as "None". Really? No BC impact
> whatsoever by removing imap and mcrypt? Literally nobody ever anywhere
> is using it?
>
> >
Hi!
> And at list this one living native PHP implementation
> https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and
> more library links in the older thread link above).
This is part of Horde with 9 listed dependencies and 9 suggested ones,
and probably also sub-dependencies. It
Hi!
> About $php_errormsg , we have error_get_last().
> About $http_response_headers, we have no replacement.
>
> Why not get rid of both ?
I agree. Magically appearing variables are bad design and if we can get
rid of them, PHP 7 is the time.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Inte
Hi!
> We keep discussing how to improve security, make php safer by default, etc.
> But for IMAP, you basically open the door with a big shield saying "come
> in, we have free cooking and you can do almost all you want inside via this
> door". This is insane. If it was only up to me I would kick i
Hi!
I am kind of surprised that RFC about removing whole extensions has
"Backward Incompatible Changes" listed as "None". Really? No BC impact
whatsoever by removing imap and mcrypt? Literally nobody ever anywhere
is using it?
> - ext/imap and ext/mcrypt: while I realise that the underlying
> lib
> De : Xinchen Hui [mailto:larue...@php.net]
> > I don't understand how you can delete the resource if you remove the
> handle from the zend_resource struct. Or would you store the index
> elsewhere ?
>
> if you use HashTable , yes, it's hard to get rid of it, but we can
> hidden it from user lan
Hi!
> as you can see, we use "r" to receive a IS_RESOURCE type, that
> means, check the type in ZEND_FETCH_RESOURCE is overhead..
Except that some functions could receive "z" and decide if it's the
resource or not afterwards... But I guess you could rely on the code
that decides it to check.
>De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>On Tue, Feb 3, 2015 at 2:00 AM, François Laupretre
>wrote:
>Opening the vote for :
> https://wiki.php.net/rfc/cyclic-replace
> I guess you mean discussion?
Actually, I wanted to open the vote, as discussion took pl
Am 04.02.2015 um 06:44 schrieb Dmitry Stogov:
> What do you think about using only lowercase type names for scalar type
> hints? In this case we won't have to introduce any limitations.
This would be inconsistent with the rest of PHP being case-insensitive
and only lead to confusion.
--
PHP I
Hi Dmitry,
On Wed, Feb 4, 2015 at 2:36 PM, Dmitry Stogov wrote:
> You probably talk about https://wiki.php.net/rfc/expectations
> I wasn't the author of idea, I just helped with thoughts and implantation.
> I think it may be useful for PHP7.
Thank you for the info.
It would be great to have it
Hi Andrea,
In you proposal you disable declaration of classes with names, that may be
used for scalar type hints - Int, Float, ...
What do you think about using only lowercase type names for scalar type
hints?
In this case we won't have to introduce any limitations.
function foo(int $a) // expe
Hi Yasuo,
You probably talk about https://wiki.php.net/rfc/expectations
I wasn't the author of idea, I just helped with thoughts and implantation.
I think it may be useful for PHP7.
Thanks. Dmitry.
On Tue, Feb 3, 2015 at 11:12 PM, Yasuo Ohgaki wrote:
> Hi Dmitry,
>
> On Mon, Feb 2, 2015
On Tue, Feb 3, 2015 at 7:14 PM, Andrea Faulds wrote:
> Hi Dmitry,
>
> > On 3 Feb 2015, at 04:07, Dmitry Stogov wrote:
> >
> > I have similar opinion. Strict typing looks foreign for PHP.
>
> It is in a way, yes. PHP has traditionally been “weakly-typed” everywhere.
>
> That being said, we’re not
Hey:
On Tue, Feb 3, 2015 at 12:37 AM, François Laupretre
wrote:
>> De : Xinchen Hui [mailto:larue...@php.net]
>> furthermore, I'd like to discuss remove the handle in zend_resource struct..
>>
>> it may breaks some usage (use resource as long/double/string)
>>
>>case IS_RESOURCE: {
>>
Hey:
On Mon, Feb 2, 2015 at 1:34 PM, Xinchen Hui wrote:
> Hey:
>
> we used to use lval of zval as a handle to access resource type..
>
> but now, we introduced a new type IS_RESOURCE, which make the
> handle(id) sort of redundant .
>
> further more, the common usage when handling r
Hi Cesar,
On 4 February 2015 at 07:26, Cesar Rodas wrote:
> Hi Guys,
>
> I have a doubt, is it efficient include/require files from a source
> different than the "real file system" a stream wrapper class? My
> question is, would the op-code cache work as it would when reading a
> file form the f
"Anatol Belski" in php.internals (Mon, 2 Feb 2015 20:11:20 +0100):
>properly after the voting phase the
>https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
>voting. Each item is voted separately.
ext/ereg needs a fix before it can be moved to PECL. The TS build
--with-ereg=shared
Hi Pierre,
On Wed, Feb 4, 2015 at 9:08 AM, Pierre Joye wrote:
> Please add them (and maybe example migration code) to UPGRADING.INTERNALS
Got it!
I'll add it to UPGRADING soon.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
On Thu, Dec 11, 2014 at 5:10 PM, Derick Rethans wrote:
> On Wed, 10 Dec 2014, Andrea Faulds wrote:
>
>> > On 10 Dec 2014, at 06:33, Remi Collet wrote:
>> >
>> > Having a dead upstream for crypto API is a critical issue :(
>> >
>> > FYI some downstream (ex RHEL) don't even provide this library.
>>
my fault, did not commit the change :D
It should be fine now.
On Wed, Feb 4, 2015 at 3:21 AM, Jakub Zelenka wrote:
> Hello,
>
> On Mon, Feb 2, 2015 at 9:45 AM, Pierre Joye wrote:
>>
>> found and added, php-src :)
>>
>> Thanks for your work!
>>
>
> Thanks for adding that. Unfortunately I just tr
On 03/02/15 22:35, Andrea Faulds wrote:
>> Currently we have a problem with the size of integers, but simply
>> > ignoring that there are limits is not the may to fix that problem.
> This RFC doesn’t ignore that there are limits. Arbitrary-precision integers
> are, naturally, bounded by available
"Anatol Belski" in php.internals (Tue, 3 Feb 2015 09:11:18 +0100):
>Hi Michael,
>
>On Tue, February 3, 2015 08:31, Michael Wallner wrote:
>> On 3 Feb 2015 08:10, "Adam Harvey" wrote:
>
>> I understand your thoughts. How about if we do for mcrypt what we did for
>> mhash, I.e. implement a compatibl
On Feb 4, 2015 2:51 AM, "Yasuo Ohgaki" wrote:
> I added comments to ext/session/mod_files.c for save handler developers.
> Please refer to it also.
Please add them (and maybe example migration code) to UPGRADING.INTERNALS
Thanks!
On 03/02/15 20:55, Leigh wrote:
> On 3 February 2015 at 23:26, Cesar Rodas wrote:
>> Hi Guys,
>>
>> I have a doubt, is it efficient include/require files from a source
>> different than the "real file system" a stream wrapper class? My
>> question is, would the op-code cache work as it would when
On 3 February 2015 at 23:26, Cesar Rodas wrote:
> Hi Guys,
>
> I have a doubt, is it efficient include/require files from a source
> different than the "real file system" a stream wrapper class? My
> question is, would the op-code cache work as it would when reading a
> file form the filesystem?
>
Hi Guys,
I have a doubt, is it efficient include/require files from a source
different than the "real file system" a stream wrapper class? My
question is, would the op-code cache work as it would when reading a
file form the filesystem?
Cheers,
--
César D. Rodas
Open Source developer
+595-983-1
On 3 February 2015 21:49:28 GMT, Lester Caine wrote:
>On 03/02/15 16:44, Andrea Faulds wrote:
>> Sure, but I don’t think we shouldn’t cripple the language merely for
>the sake of really low-end embedded devices. Also, I’m not convinced
>that the overhead, at least in terms of file size, is really
> On 3 Feb 2015, at 21:49, Lester Caine wrote:
>
> On 03/02/15 16:44, Andrea Faulds wrote:
>> Sure, but I don’t think we shouldn’t cripple the language merely for the
>> sake of really low-end embedded devices. Also, I’m not convinced that the
>> overhead, at least in terms of file size, is re
Hi Sven,
> On 3 Feb 2015, at 19:07, Sven Drieling wrote:
>
> What about scalar type declaration in userland?
It’s one of many suggestions. I really, really don’t think it’s a good idea.
Rather than having two models (as the RFC suggests), we’d have n models, where
n is the number of existent
On 3 February 2015 06:59:06 GMT, Alexander Lisachenko
wrote:
>I want to add a link here to the Java article about Value Types, this
>information is quite interesting:
>http://cr.openjdk.java.net/~jrose/values/values-0.html
>
>Probably, immutable value objects will be soon in Java world according
On 03/02/15 16:44, Andrea Faulds wrote:
> Sure, but I don’t think we shouldn’t cripple the language merely for the sake
> of really low-end embedded devices. Also, I’m not convinced that the
> overhead, at least in terms of file size, is really that big of an issue.
'I don’t think we should crip
Hi all,
On Wed, Feb 4, 2015 at 5:23 AM, Thomas Bley wrote:
> function addVat($amount) {
> validateAmount($amount);
> return round($amount*1.19, 2);
> }
>
> function validateAmount($amount) {
> if (!is_int($amount) && !is_float($amount)) {
> throw new InvalidArgumentException('Argument
On Tue, Feb 3, 2015 at 10:44 AM, Andrea Faulds wrote:
>
> > On 3 Feb 2015, at 14:49, Lester Caine wrote:
> >
> > On 03/02/15 14:03, Andrea Faulds wrote:
> >> But I don’t consider 0.25MB extra to be such a problem in practice. The
> PHP binary is already huge, and every system running PHP will ha
On 03/02/15 19:59, Martin Keckeis wrote:
> Please get this mayor feature finally into the core
> In the current century a real 64bit support is not discussable anymore...
Martin this has NOTHING to do with getting 64 bit support into core.
That has already been achieved by the introduction of
I would prefer:
function addVat($amount) {
validateAmount($amount);
return round($amount*1.19, 2);
}
function validateAmount($amount) {
if (!is_int($amount) && !is_float($amount)) {
throw new InvalidArgumentException('Argument amount must be of the type
int|float, '.gettype($amount).'
Hello,
On Mon, Feb 2, 2015 at 9:45 AM, Pierre Joye wrote:
> found and added, php-src :)
>
> Thanks for your work!
>
>
Thanks for adding that. Unfortunately I just tried to push it and it
rejected me :) :
[jakub@localhost master]$ git push upstream master
Counting objects: 261, done.
Delta compr
Hi Dmitry,
On Mon, Feb 2, 2015 at 6:12 PM, Dmitry Stogov wrote:
> could you please write down few use cases, when strict scalar type hints
> are really useful.
>
I'm not opposing to have scalar type hints, but assertion can do better job
for it. I think you have proposed assert() w/o runtime ov
Am 03.02.2015 17:44 schrieb "Andrea Faulds" :
>
>
> > On 3 Feb 2015, at 14:49, Lester Caine wrote:
> >
> > On 03/02/15 14:03, Andrea Faulds wrote:
> >> But I don’t consider 0.25MB extra to be such a problem in practice.
The PHP binary is already huge, and every system running PHP will have
ample m
Hi Rasmus,
On Wed, Feb 4, 2015 at 1:20 AM, Rasmus Lerdorf wrote:
> Hey Yasuo, I noticed that you removed the invalid_session_id boolean
> from php_session.h. For extensions that do:
>
> PS(invalid_session_id) = 1;
>
> what is the new way for them?
>
At first, PS(invalid_session_id) was never
Am Mon, 02 Feb 2015 23:38:21 +0100
schrieb Christoph Becker :
Hallo,
> >> addVat(-1);
>
> Well, my point was that even a strict type system doesn't necessarilly
> catch all erroneous/undesired arguments. Even if addVat() properly
> handles negative numbers, and maybe even zeroes, there are fun
Hi Lester,
On Tue, February 3, 2015 15:49, Lester Caine wrote:
> On 03/02/15 14:03, Andrea Faulds wrote:
>
>> But I don’t consider 0.25MB extra to be such a problem in practice. The
>>
> PHP binary is already huge, and every system running PHP will have ample
> memory.
>
> Yes one approach is 'com
> De : Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> > Don't we already have this problem with chrooted FPM? I haven't tested it
> more recently, but last time I tried, opcache would fail to invalidate the
> cache
> after updating the file. Worked fine with a non-chroot environment. Not
> sure if t
> On 3 Feb 2015, at 14:49, Lester Caine wrote:
>
> On 03/02/15 14:03, Andrea Faulds wrote:
>> But I don’t consider 0.25MB extra to be such a problem in practice. The PHP
>> binary is already huge, and every system running PHP will have ample memory.
>
> Yes one approach is 'computers are getti
> On 3 Feb 2015, at 16:22, Leigh wrote:
>
> On 3 February 2015 at 15:02, Andrea Faulds wrote:
>>
>> Why would it be promoted?! The high bit is the 63rd bit. It fits within a
>> long.
>
> because
>
> On 3 February 2015 at 16:08, Andrea Faulds wrote:
>>
>> $ sapi/cli/php -r '$x = 1 << 63; d
On 02/02/2015 07:35 PM, David Muir wrote:
>
>
>> On 3 Feb 2015, at 3:49 am, Rasmus Lerdorf wrote:
>>
>>> On 02/02/2015 08:38 AM, François Laupretre wrote:
>>> Hi,
>>>
>>> Opening the vote for :
>>>
>>> https://wiki.php.net/rfc/streams-is-cacheable
>>>
>>> This RFC proposes a generic way for opco
On 3 February 2015 at 15:02, Andrea Faulds wrote:
>
> Why would it be promoted?! The high bit is the 63rd bit. It fits within a
> long.
because
On 3 February 2015 at 16:08, Andrea Faulds wrote:
>
> $ sapi/cli/php -r '$x = 1 << 63; debug_zval_dump($x);'
> bigint(9223372036854775808) refcount(2)
Hey Yasuo, I noticed that you removed the invalid_session_id boolean
from php_session.h. For extensions that do:
PS(invalid_session_id) = 1;
what is the new way for them?
-Rasmus
signature.asc
Description: OpenPGP digital signature
Hi Dmitry,
> On 3 Feb 2015, at 04:07, Dmitry Stogov wrote:
>
> I have similar opinion. Strict typing looks foreign for PHP.
It is in a way, yes. PHP has traditionally been “weakly-typed” everywhere.
That being said, we’re not always weakly-typed (there are strict type checks in
some places),
> On 3 Feb 2015, at 15:12, Leigh wrote:
>
> On 3 February 2015 at 15:02, Andrea Faulds wrote:
>> Why would it be promoted?! The high bit is the 63rd bit. It fits within a
>> long.
>>
>
> I'm assuming your bigint implementation would want to respect signage.
>
> When does it promote? 63rd to
> On 03 02 2015, at 10:33, Julien Pauli wrote:
>
> $HTTP_RAW_POST_DATA could as well disappear (made deprecated as of 5.6).
>
This is already gone in master, which reminds me of the missing UPGRADING note.
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
On 3 February 2015 at 15:02, Andrea Faulds wrote:
> Why would it be promoted?! The high bit is the 63rd bit. It fits within a
> long.
>
I'm assuming your bigint implementation would want to respect signage.
When does it promote? 63rd to preserve signage?
4611686018427387904 // 1 << 62 - int
92
On 2/3/15 3:33 AM, Julien Pauli wrote:
On Mon, Feb 2, 2015 at 6:19 PM, Ferenc Kovacs wrote:
About $php_errormsg , we have error_get_last().
About $http_response_headers, we have no replacement.
Well, we sort of do. You can get header information from the http
context stream metadata:
> On 3 Feb 2015, at 14:59, Leigh wrote:
>
> On 3 February 2015 at 14:49, Andrea Faulds wrote:
>> It’s not “broken”, the behaviour is just different to account for it now
>> being an arbitrary-precision type.
>>
>
> That's pretty much the definition of a BC issue.
Sure, it’s a BC break if yo
On 3 February 2015 at 14:49, Andrea Faulds wrote:
> It’s not “broken”, the behaviour is just different to account for it now
> being an arbitrary-precision type.
>
That's pretty much the definition of a BC issue.
> Also, the bigint changes only affect you if you’re dealing with large
> integer
Hi,
> On 3 Feb 2015, at 14:43, Leigh wrote:
>
> On 3 February 2015 at 14:36, Andrea Faulds wrote:
>> I don’t know where you got that idea. The binary ops are consistent - they
>> aren’t constrained by register size like in previous PHP versions, but
>> they’re still completely consistent.
>>
On 03/02/15 14:03, Andrea Faulds wrote:
> But I don’t consider 0.25MB extra to be such a problem in practice. The PHP
> binary is already huge, and every system running PHP will have ample memory.
Yes one approach is 'computers are getting faster with lots of memory'
... and for servers this is n
On 3 February 2015 at 14:36, Andrea Faulds wrote:
> I don’t know where you got that idea. The binary ops are consistent - they
> aren’t constrained by register size like in previous PHP versions, but
> they’re still completely consistent.
>
php -r 'var_dump(1 << 65);'
int(2)
Rotate left gets b
On 3 Feb 2015, at 14:15, Leigh wrote:
>
> On 3 February 2015 at 13:54, Andrea Faulds wrote:
>> Hi Leigh,
>>
>>> On 3 Feb 2015, at 13:51, Leigh wrote:
>>> No idea. Personally I'm opposed to the bigints implementation because
>>> of the implicit type auto-promotion.
>>
>> Huh? There’s no type p
On 3 February 2015 at 13:54, Andrea Faulds wrote:
> Hi Leigh,
>
>> On 3 Feb 2015, at 13:51, Leigh wrote:
>> No idea. Personally I'm opposed to the bigints implementation because
>> of the implicit type auto-promotion.
>
> Huh? There’s no type promotion from a userland perspective, it’s entirely a
Hi Lester,
> On 3 Feb 2015, at 08:56, Lester Caine wrote:
>
> On 02/02/15 23:50, Andrea Faulds wrote:
>>> Since a clean 64bit build of PHP does not need anything other than
'integer' to support 64bit BIGINT SQL numbers, loading 32bit builds with
an overly heavy solution is just not rig
Hi Leigh,
> On 3 Feb 2015, at 13:51, Leigh wrote:
>
> On 3 February 2015 at 13:25, Andrea Faulds wrote:
>> Hmm, how would this interact with bigints? Does it rely on fixed-width
>> integers, as it appears to? :/
>
> No idea. Personally I'm opposed to the bigints implementation because
> of th
On 3 February 2015 at 13:25, Andrea Faulds wrote:
> Hmm, how would this interact with bigints? Does it rely on fixed-width
> integers, as it appears to? :/
No idea. Personally I'm opposed to the bigints implementation because
of the implicit type auto-promotion.
--
PHP Internals - PHP Runtime
>>> is called a logical right shift (in contrast to the arithmetic right shift
>>> >>). This would be a good addition.
$op1 >>> $op2 is equivalent to ($op1 >> $op2) & (PHP_INT_MAX >> $op2 - 1)
== Original ==
From: Leigh
To: internals@lists.php.net
Date: Tue, 03 Feb 2015 14:24:07
Hi Leigh,
> On 3 Feb 2015, at 13:20, Leigh wrote:
>
> Hi list,
>
> How do we feel about a zero-fill right shift operator?
>
> PHPs current right shift operator preserves signage, but this is not
> always desirable.
>
> I propose the same syntax as JavaScript for this: >>>
>
> php -r 'var_dum
> This will introduce a T_SHRZF token and corresponding opcode. Targeting PHP 7.
That should have been T_SRZF, and I suppose I would also have to add
">>>=" (T_SRZF_EQUAL) which looks nasty, but should be included for
completeness.
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
Hi list,
How do we feel about a zero-fill right shift operator?
PHPs current right shift operator preserves signage, but this is not
always desirable.
I propose the same syntax as JavaScript for this: >>>
php -r 'var_dump(-256 >> 8);'
int(-1)
php -r 'var_dump(-256 >>> 8);'
int(16777215)
This
On 03/02/15 12:37, Rowan Collins wrote:
> For what it's worth, we've been running a Linux + MS SQL setup for
> around 10 years, due to a previous migration from Classic ASP to PHP. We
> originally used ext/mssql, and moved to ext/pdo_dblib with PHP 5.4
> (previous versions didn't support nextRowset
Pierre Joye wrote on 03/02/2015 09:14:
On Feb 3, 2015 4:06 PM, "Lester Caine" wrote:
On 03/02/15 08:44, Matteo Beccati wrote:
Marius Adrian Popa has stated to maintain both, and looks like there
several active users who will use that. So going by that, it's not
being
voted on these exts.
I
On Feb 3, 2015 1:08 PM, "Andrey Andreev" wrote:
>
> Hi,
>
> On Mon, Feb 2, 2015 at 7:58 PM, François Laupretre
wrote:
> >> De : Andrey Andreev [mailto:n...@devilix.net]
> >>
> >> I seem to have missed the new parameter (and constants) addition
> >> during the discussion ... sorry to say this, but
Hi,
On Mon, Feb 2, 2015 at 7:58 PM, François Laupretre wrote:
>> De : Andrey Andreev [mailto:n...@devilix.net]
>>
>> I seem to have missed the new parameter (and constants) addition
>> during the discussion ... sorry to say this, but that one would
>> probably fail the RFC.
>
> Mmh... I don't lik
Hi Francois,
On Tue, Feb 3, 2015 at 2:00 AM, François Laupretre
wrote:
> Opening the vote for :
>
> https://wiki.php.net/rfc/cyclic-replace
>
> This RFC adds support in str_replace() and str_ireplace() for the
> combination of
> (string needle, array replace). In this case, each occurrence of th
On Tue, Feb 3, 2015 at 10:33 AM, Julien Pauli wrote:
> On Mon, Feb 2, 2015 at 6:19 PM, Ferenc Kovacs wrote:
>
>> On Tue, Dec 2, 2014 at 11:28 AM, Ferenc Kovacs wrote:
>>
>> >
>> >
>> > On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins
>> > wrote:
>> >
>> >> On 1 December 2014 22:28:04 GMT, Ralph S
On Mon, Feb 2, 2015 at 6:19 PM, Ferenc Kovacs wrote:
> On Tue, Dec 2, 2014 at 11:28 AM, Ferenc Kovacs wrote:
>
> >
> >
> > On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins
> > wrote:
> >
> >> On 1 December 2014 22:28:04 GMT, Ralph Schindler <
> >> ra...@ralphschindler.com> wrote:
> >> >Hi all,
> >
On 03/02/15 09:14, Pierre Joye wrote:
>> I wonder if ANY mssql users have noticed that they may be left out of
>> PHP7 ... I suspect that may actually have a bigger user base than the
>> paid for 'Interbase' yet it's got no support here.
>
> For mssql, most of them (while we see more and more requ
Hi Stas,
On Tue, Feb 3, 2015 at 5:04 AM, Stanislav Malyshev
wrote:
> I see you've added test for #61470 to 5.5 and up. But this test is
> failing on CI. Could you please look into it and fix it or revert it
> until it works?
>
Sorry, it was my mistake.
It seems I should have run tests on my per
On Feb 3, 2015 4:06 PM, "Lester Caine" wrote:
>
> On 03/02/15 08:44, Matteo Beccati wrote:
> >> Marius Adrian Popa has stated to maintain both, and looks like there
> >> several active users who will use that. So going by that, it's not
being
> >> voted on these exts.
> >
> > I must have missed th
OPcache will bring nothing to dev env, except possible failures and WTFs.
So I suggest not enabling it in development php.ini.
Julien.P
On Tue, Feb 3, 2015 at 6:59 AM, Pierre Joye wrote:
> On Feb 3, 2015 11:26 AM, "Xinchen Hui" wrote:
> >
> > Hey:
> >
> > opcache is disabled by defaul
On 03/02/15 08:44, Matteo Beccati wrote:
>> Marius Adrian Popa has stated to maintain both, and looks like there
>> several active users who will use that. So going by that, it's not being
>> voted on these exts.
>
> I must have missed that, sorry for the noise.
This is a bit of the problem here.
On 02/02/15 23:50, Andrea Faulds wrote:
>> Since a clean 64bit build of PHP does not need anything other than
>> > 'integer' to support 64bit BIGINT SQL numbers, loading 32bit builds with
>> > an overly heavy solution is just not right!
> I don’t see how it’s “overly heavy”. Bear in mind that sever
On Feb 3, 2015 2:10 PM, "Adam Harvey" wrote:
>
> On 3 February 2015 at 03:11, Anatol Belski wrote:
> > properly after the voting phase the
> > https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
> > voting. Each item is voted separately. The voting ends on 2015-02-09 at
> > 21:00
On 03/02/2015 09:39, Anatol Belski wrote:
Marius Adrian Popa has stated to maintain both, and looks like there
several active users who will use that. So going by that, it's not being
voted on these exts.
I must have missed that, sorry for the noise.
Cheers
--
Matteo Beccati
Development & Co
Hi Matteo,
On Tue, February 3, 2015 09:09, Matteo Beccati wrote:
> On 02/02/2015 20:21, Lester Caine wrote:
>
>> On 02/02/15 19:11, Anatol Belski wrote:
>>
>>> properly after the voting phase the
>>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
>>> voting. Each item is vote
Hi Michael,
On Tue, February 3, 2015 08:31, Michael Wallner wrote:
> On 3 Feb 2015 08:10, "Adam Harvey" wrote:
> I understand your thoughts. How about if we do for mcrypt what we did for
> mhash, I.e. implement a compatible layer on top of openssl? I have not
> checked if it's even possible yet
On 02/02/2015 20:21, Lester Caine wrote:
On 02/02/15 19:11, Anatol Belski wrote:
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.
I feel this is totally ou
Hi Adam,
thanks for the explanations.
On Tue, February 3, 2015 08:10, Adam Harvey wrote:
> On 3 February 2015 at 03:11, Anatol Belski wrote:
>
>> properly after the voting phase the
>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
>> voting. Each item is voted separately.
93 matches
Mail list logo
