-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 13/10/2014 22:15, Jakub Zelenka a écrit :
> Hi,
>
> We have 2 alternative extensions
>>
>> - - jsonc the older one, probably not perfect, but used in a lot
>> of downstream distributions
>>
>> - - jsond the recent one
>>
>>
>> I think it is tim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 05/12/2014 17:17, Scott Arciszewski a écrit :
> Hi PHP Internals,
>
> I've been trying to get in contact with the maintainers of
> libmcrypt, but every response I've gotten was, "Oh, I haven't been
> a part of that for years."
>
> http://sourcefor
Hi!
> On 9 Dec 2014, at 23:31, Josh Watzman wrote:
>
>> 2) It’d probably be better if you made a language specification patch
>> before, not after, the RFC is accepted. Having to specify the syntax and
>> semantics formally can make what the operator does clearer and help to spot
>> issues. P
On Dec 9, 2014, at 3:18 PM, Andrea Faulds wrote:
>> On 9 Dec 2014, at 23:07, Josh Watzman wrote:
>>
>> Hey internals! A useful feature that Hack picked up in the last few months
>> are "nullsafe calls", a way of propagating failure forward in a series of
>> chained method calls to the end of
> On 9 Dec 2014, at 23:07, Josh Watzman wrote:
>
> Hey internals! A useful feature that Hack picked up in the last few months
> are "nullsafe calls", a way of propagating failure forward in a series of
> chained method calls to the end of the whole computation, getting rid of a
> lot of the b
Hey internals! A useful feature that Hack picked up in the last few months are
"nullsafe calls", a way of propagating failure forward in a series of chained
method calls to the end of the whole computation, getting rid of a lot of the
boilerplate in the middle. I think the feature would be a goo
> On 9 Dec 2014, at 19:45, Marc Bennewitz wrote:
>
>
> Am 09.12.2014 um 20:03 schrieb Sara Golemon:
>> On Tue, Dec 9, 2014 at 10:58 AM, Marc Bennewitz wrote:
>>> Is it possible to make a zval persistent?
>>>
>> Nope.
>>
> Why?
>
> There is a reference counter, which should be increased on p
Am 09.12.2014 um 20:03 schrieb Sara Golemon:
On Tue, Dec 9, 2014 at 10:58 AM, Marc Bennewitz wrote:
Is it possible to make a zval persistent?
Nope.
Why?
There is a reference counter, which should be increased on put a value
into persistence and on removing a value from persistence decrea
On 9 December 2014 16:43:52 GMT, Nicolas Grekas
wrote:
>Indeed. A non-function version of debug_zval_dump which could do this
>on
>> any variable would be even better (if I read it right, your function
>only
>> works on array members?)
>>
>
>Not sure this is required: any variable can be put in
On Tue, Dec 9, 2014 at 10:58 AM, Marc Bennewitz wrote:
> Is it possible to make a zval persistent?
>
Nope.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
Is it possible to make a zval persistent?
Currently I only found persistent resources or internal references used
in objects.
It would be very great for some userland applications to make a value
persistent whatever type it is.
Like the internal global "persistent_list" but this one
Hi Derick,
> On 9 Dec 2014, at 16:54, Derick Rethans wrote:
>
>> On Tue, 9 Dec 2014, Andrea Faulds wrote:
>>
>> I think \x{} is misleading anyway - \xXX is always
>> single-byte/character, yet Unicode code points can’t be represented in
>> PHP strings as single bytes when encoded in UTF-
On Tue, 9 Dec 2014, Andrea Faulds wrote:
> I think \x{} is misleading anyway - \xXX is always
> single-byte/character, yet Unicode code points can’t be represented in
> PHP strings as single bytes when encoded in UTF-8 (unless they’re
> below U+0100, of course).
You mean below U+0080 surel
> t would not be a BC break to completely change the output
I agree! This could be as simple as removing the XOR for the first part of
the hash string (the first 16 chars) and expose the internal object's
handle there. This is already leaked by the output of var_dump so not a pb
imho. And BC is
Lester Caine wrote on 09/12/2014 16:00:
On 09/12/14 15:30, Rowan Collins wrote:
Lester Caine wrote on 09/12/2014 15:07:
On 09/12/14 14:07, Andrea Faulds wrote:
On 9 Dec 2014, at 13:35, Lester Caine wrote:
On 09/12/14 13:07, Andrea Faulds wrote:
On 9 Dec 2014, at 08:15, Lester Caine wrote
On 09/12/14 15:30, Rowan Collins wrote:
> Lester Caine wrote on 09/12/2014 15:07:
>> On 09/12/14 14:07, Andrea Faulds wrote:
On 9 Dec 2014, at 13:35, Lester Caine wrote:
> On 09/12/14 13:07, Andrea Faulds wrote:
>
>> On 9 Dec 2014, at 08:15, Lester Caine wrote:
>>
>>
Hi,
On Mon, December 8, 2014 20:42, Ángel González wrote:
> On 03/12/14 10:22, Anatol Belski wrote:
>
>> I meant that as well, to the time it's merged all the TSRMLS_* thingies
>> should be removed. I kept them only while developed and now for the
>> RFC so
>> the diff shows the only change done,
Nicolas Grekas wrote on 09/12/2014 14:39:
Hi Rowan,
In order to get an object's id, I use a trick that works for now:
https://github.com/symfony/symfony/blob/2.6/src/Symfony/Component/VarDumper/Cloner/VarCloner.php#L258-L282
This seems like a very elaborate piece of revers
Lester Caine wrote on 09/12/2014 15:07:
On 09/12/14 14:07, Andrea Faulds wrote:
On 9 Dec 2014, at 13:35, Lester Caine wrote:
On 09/12/14 13:07, Andrea Faulds wrote:
On 9 Dec 2014, at 08:15, Lester Caine wrote:
If ICU is to be adopted as the base for unicode support, then surely
everything
Andrea Faulds wrote on 09/12/2014 14:10:
On 9 Dec 2014, at 13:23, Rowan Collins wrote:
Xinchen Hui wrote on 09/12/2014 03:39:
but I suggest change it to "expects parameter 1 to be long,
double(which is beyond long range) given in %s on line %d"
Note that in master, the messages have been chan
On 09/12/14 14:07, Andrea Faulds wrote:
>
>> On 9 Dec 2014, at 13:35, Lester Caine wrote:
>>
>>> On 09/12/14 13:07, Andrea Faulds wrote:
>>>
On 9 Dec 2014, at 08:15, Lester Caine wrote:
If ICU is to be adopted as the base for unicode support, then surely
everything else shoul
Hi Rowan,
In order to get an object's id, I use a trick that works for now:
>> https://github.com/symfony/symfony/blob/2.6/src/Symfony/
>> Component/VarDumper/Cloner/VarCloner.php#L258-L282
>>
>
> This seems like a very elaborate piece of reverse engineering
Right, and I made the claim for this
> On 9 Dec 2014, at 13:23, Rowan Collins wrote:
>
> Xinchen Hui wrote on 09/12/2014 03:39:
>> but I suggest change it to "expects parameter 1 to be long,
>> double(which is beyond long range) given in %s on line %d"
>
> Note that in master, the messages have been changed to (correctly) not
> m
> On 9 Dec 2014, at 13:35, Lester Caine wrote:
>
>> On 09/12/14 13:07, Andrea Faulds wrote:
>>
>>> On 9 Dec 2014, at 08:15, Lester Caine wrote:
>>>
>>> If ICU is to be adopted as the base for unicode support, then surely
>>> everything else should follow those rules?
>>> \u and \U
On 09/12/14 13:07, Andrea Faulds wrote:
>
>> On 9 Dec 2014, at 08:15, Lester Caine wrote:
>>
>> If ICU is to be adopted as the base for unicode support, then surely
>> everything else should follow those rules?
>> \u and \U are defined along with \x{hh} so does it make
>> sense to
Xinchen Hui wrote on 09/12/2014 03:39:
but I suggest change it to "expects parameter 1 to be long,
double(which is beyond long range) given in %s on line %d"
Note that in master, the messages have been changed to (correctly) not
mention the C types, only the PHP ones, so it would be more like
> On 9 Dec 2014, at 08:15, Lester Caine wrote:
>
> If ICU is to be adopted as the base for unicode support, then surely
> everything else should follow those rules?
> \u and \U are defined along with \x{hh} so does it make
> sense to add something which is not part of ICU?
Er, w
Hi!
> On 9 Dec 2014, at 03:39, Xinchen Hui wrote:
>
> Hey:
> that will confuse people, why 12.2 is okey (it's also a double value).
>
> anyway, I am not a native english speaker, not sure what is the most
> proper warning message.
>
> but I suggest change it to "expects parameter 1 to be long
Nicolas Grekas wrote on 09/12/2014 09:31:
Hi
this is a proposal to add new function to PHP core: spl_object_id()
IMHO this is a good idea: currently, var_dump has this super-power (and
super-useful) capability of outputting a number that ease recognizing
identical objects in dumps. This power s
Hi
this is a proposal to add new function to PHP core: spl_object_id()
>
IMHO this is a good idea: currently, var_dump has this super-power (and
super-useful) capability of outputting a number that ease recognizing
identical objects in dumps. This power should be transferred to userland
devs so
On 09/12/14 02:44, Andrea Faulds wrote:
>> Maybe there should be more elaboration on why PHP itself should go with
>> > the \u{} ECMAScript representaton, thus introducing a syntax disparity
>> > with our most major string handling extension.
> Well, PCRE does what it does probably because of i
31 matches
Mail list logo
