-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 11/01/2015 10:37, Remi Collet a écrit :
> Le 08/01/2015 18:30, Julien Pauli a écrit :
>> Hello
>
>> PHP 5.5.21 RC1 is available for testing.
>
> Trying to understand why Horde_Imap_Client test suite start to
> fail with PHP 5.5.21RC1 and 5.6.5RC1.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 11/01/2015 18:27, Jakub Zelenka a écrit :
> Hi,
>
> This rfc about replacing json with jsond is under discussion.
>
> https://wiki.php.net/rfc/jsond
>
+1
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - h
On Sun, Jan 11, 2015 at 7:44 PM, François Laupretre
wrote:
> - Extension exposes only PHP functions and constants (no OO),
> - Each PHP function argument must accept a scalar, an array, or both ('mixed'
> case).
> - one or more PHP function arguments can be optional
> - PHP function arguments can
On Jan 12, 2015 10:44 AM, "François Laupretre" wrote:
>
> > De : François Laupretre [mailto:franc...@tekwire.net]
> >
> > If you agree, I propose this as a base to refine:
> >
> > - Extension exposes only PHP functions and constants (no OO),
> > - Each PHP function argument must accept a scalar, a
> De : François Laupretre [mailto:franc...@tekwire.net]
>
> If you agree, I propose this as a base to refine:
>
> - Extension exposes only PHP functions and constants (no OO),
> - Each PHP function argument must accept a scalar, an array, or both ('mixed'
> case).
> - one or more PHP function argu
Hey:
On Mon, Jan 12, 2015 at 1:27 AM, Jakub Zelenka wrote:
> Hi,
>
> This rfc about replacing json with jsond is under discussion.
>
> https://wiki.php.net/rfc/jsond
>
> I have finally done some benchmarks. You can find a link in the RFC.
>
> It's been extensively tested for the last few months
Hi!
> Also, FWIW, anyone who used the Suhosin patch couldn’t use srand()
> because it disabled it.
And? You can disable any function in PHP, that doesn't mean anything.
> Because if we don’t break it, people will continue to rely on it, and
> this binds our hands for future versions.
Sorry, tha
Hi,
> On 12 Jan 2015, at 01:20, Stanislav Malyshev wrote:
>
>> The manual explicitly guarantees that code should not rely on the
>> random number generator being predictable.
>
> Where exactly does it say that? The only note I've found is this:
> http://php.net/manual/en/function.mt-srand.php
>
Hey,
> On 12 Jan 2015, at 01:12, Stanislav Malyshev wrote:
>
>> * Get rid of rand(), srand() and getrandmax() * Rename mt_rand(),
>> mt_srand() and mt_getrandmax() to rand(), srand(), and getrandmax()
>> but add mt_* aliases for backwards-compatibility
>
> This means rand() and mt_rand() would
Hi!
> The manual explicitly guarantees that code should not rely on the
> random number generator being predictable.
Where exactly does it say that? The only note I've found is this:
http://php.net/manual/en/function.mt-srand.php
5.2.1 The Mersenne Twister implementation in PHP now uses a new
Hi!
> * Get rid of rand(), srand() and getrandmax() * Rename mt_rand(),
> mt_srand() and mt_getrandmax() to rand(), srand(), and getrandmax()
> but add mt_* aliases for backwards-compatibility
This means rand() and mt_rand() would do the same. That however assumes
that OS's libc random-number fu
On Jan 12, 2015 8:08 AM, "Andrea Faulds" wrote:
>
> Hey Stas,
>
> > On 12 Jan 2015, at 01:03, Stanislav Malyshev
wrote:
> >
> > Having new, better API is fine. Breaking existing working code because
> > new, better API is possible, is not fine.
>
> The manual explicitly guarantees that code shoul
Hey Stas,
> On 12 Jan 2015, at 01:03, Stanislav Malyshev wrote:
>
> Having new, better API is fine. Breaking existing working code because
> new, better API is possible, is not fine.
The manual explicitly guarantees that code should not rely on the random number
generator being predictable.
I
Hi Yasuo,
> On 12 Jan 2015, at 00:55, Yasuo Ohgaki wrote:
>
> It works, but I prefer to have procedural API also (and OO API if it is
> needed.)
> I like multi paradigm programming language.
I don’t see the point of a “procedural API” here, it’d just be a set of thin
wrappers around the OOP
Hi!
> Something like this, maybe:
>
> $numgen = new RandomNumberGenerator(RAND_MERSENNE_TWISTER, time()); //
> could auto-seed with time()
> $randInt1 = $numgen->getInt(0, 100); // gets random integer and advances
> this generator
> list($randInt2, $numgen) = $numgen->newGetInt(0, 1
Hi Andrea,
On Mon, Jan 12, 2015 at 9:05 AM, Andrea Faulds wrote:
> > On 11 Jan 2015, at 23:56, Jordi Boggiano wrote:
> >
> > On 11/01/2015 22:12, Andrea Faulds wrote:
> >> * Make mt_srand() and srand() do nothing and produce a deprecation
> notice
> >
> > That is the only point with which I d
Hi all,
On Mon, Jan 12, 2015 at 7:12 AM, Andrea Faulds wrote:
> * Use a 64-bit random number generation algorithm on 64-bit platforms
> (or invoke the 32-bit generator twice)
Comment for those who does not know 64 bit version of MT rand, please read
http://www.math.sci.hiroshima-u.ac.jp/~m-
On Jan 12, 2015 4:42 AM, "François Laupretre" wrote:
>
> > De : Pierre Joye [mailto:pierre@gmail.com]
> >
> > I have a working proof of concept using something like:
> >
> > > function u_foo() {
> > }
> > ?>
> > native
> > void foo()
> > {
> > printf("Hello from native!");
> > }
> > ?>
Hey Leigh,
> On 12 Jan 2015, at 00:23, Leigh wrote:
>
> On 11 January 2015 at 22:12, Andrea Faulds wrote:
>> * Get rid of rand(), srand() and getrandmax()
>> * Rename mt_rand(), mt_srand() and mt_getrandmax() to rand(), srand(), and
>> getrandmax() but add mt_* aliases for backwards-compatib
On 11 January 2015 at 22:12, Andrea Faulds wrote:
>
> * Get rid of rand(), srand() and getrandmax()
> * Rename mt_rand(), mt_srand() and mt_getrandmax() to rand(), srand(), and
> getrandmax() but add mt_* aliases for backwards-compatibility
Also, this breaks all code currently using rand() a
On 11 January 2015 at 22:12, Andrea Faulds wrote:
> * Get rid of rand(), srand() and getrandmax()
> * Rename mt_rand(), mt_srand() and mt_getrandmax() to rand(), srand(), and
> getrandmax() but add mt_* aliases for backwards-compatibility
> * Make mt_srand() and srand() do nothing and produ
Hey Yasuo and Jordi,
> On 11 Jan 2015, at 23:56, Jordi Boggiano wrote:
>
> On 11/01/2015 22:12, Andrea Faulds wrote:
>> * Make mt_srand() and srand() do nothing and produce a deprecation notice
>
> That is the only point with which I disagree. Looking at
> http://3v4l.org/FLHBV we see that w
Hi Andrea,
On Mon, Jan 12, 2015 at 7:12 AM, Andrea Faulds wrote:
> * Get rid of rand(), srand() and getrandmax()
> * Rename mt_rand(), mt_srand() and mt_getrandmax() to rand(), srand(),
> and getrandmax() but add mt_* aliases for backwards-compatibility
> * Make mt_srand() and srand() do n
Overall it's a good plan IMO and it would clean things up for sure. On
the other hand if we don't remove old docs it will just make the docs
pages even more complex since the docs for rand() will highly depend on
which PHP version is used.
On 11/01/2015 22:12, Andrea Faulds wrote:
* Make m
Hey Stelian,
> On 11 Jan 2015, at 22:43, Stelian Mocanita wrote:
>
> All this sounds really good, and I am all for uniformity when the downsides
> are not too much to handle. I would have one suggestion though, and that
> would be to add deprecation notices on every "mt_" alias so in time they
All this sounds really good, and I am all for uniformity when the downsides
are not too much to handle. I would have one suggestion though, and that
would be to add deprecation notices on every "mt_" alias so in time they
can be safely removed and cleaning everything up.
On Sun, Jan 11, 2015 at 11
> De : Andrea Faulds [mailto:a...@ajf.me]
>
> Would that sound good?
That sounds very good to me :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hey internals,
As we’re moving to clean some things up in PHP 7, I think it might be worth
looking at the rand()/mt_rand() situation.
Currently, we have two standard-library functions to obtain a random number:
rand() and mt_rand(). rand() uses the C standard library function, which on
many st
> De : Pierre Joye [mailto:pierre@gmail.com]
>
> I have a working proof of concept using something like:
>
> function u_foo() {
> }
> ?>
> native
> void foo()
> {
> printf("Hello from native!");
> }
> ?>
> ... some other codes.
> ?>
In your example, I don't see how you execute the foo
> De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon
>
> And this is one of the things I love about HHVM's current extension
> API, so yeah I'd like to bring some elements of that in if possible.
> At one extreme it means changes to the lexer/parser, and the other end
> it m
Hey Jakub,
> On 11 Jan 2015, at 20:10, Jakub Zelenka wrote:
>
> Let's first show an example and make clear what the whole thing:
> http://3v4l.org/2D72Q
>
> As you can see, the first type (07, 0xff, .1 and -.1) examples are really
> inconsistent and give a different results if there are in the
Good night,
I want a git account to update the web-gtk page
(http://git.php.net/?p=web/gtk.git;a=summary).
And to continue the development of php-gtk
(http://git.php.net/?p=php/gtk-src.git;a=summary)
Also to create new manuals for the php-gtk
(http://git.php.net/?p=doc/gtk.git;a=summary)
Thank y
Hi,
On Sun, Jan 11, 2015 at 7:07 PM, Paul Dragoonis wrote:
>
> I feel if we need to make a minor BC break to get this in, then go with it
> for PHP 7.
>
Yes, it's proposed only for PHP 7 as declared in the RFC
> I do think that if it's possible for you to detect when users supply this
> invalid
On 11 Jan 2015 17:28, "Jakub Zelenka" wrote:
>
> Hi,
>
> This rfc about replacing json with jsond is under discussion.
>
> https://wiki.php.net/rfc/jsond
>
> I have finally done some benchmarks. You can find a link in the RFC.
>
> It's been extensively tested for the last few months and there is j
On Sun, Jan 11, 2015 at 5:27 PM, Jakub Zelenka wrote:
>
> I feel that this was a bug in the new parser and we must conform to RFC
> 7159 !
>
Typo! I meant of course that it was a bug in the old parser (the current
json extension)... :)
On 11 January 2015 at 17:27, Jakub Zelenka wrote:
>
> I feel that this was a bug in the new parser and we must conform to RFC
> 7159 !
>
I agree. +1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
This rfc about replacing json with jsond is under discussion.
https://wiki.php.net/rfc/jsond
I have finally done some benchmarks. You can find a link in the RFC.
It's been extensively tested for the last few months and there is just one
BC that I'm aware of.
The new parser accepts only flo
I would vote for the first option and entirely deprecate the array to
string conversion. As far as I can see there is no real world use-case for
it and most of the time it does more harm than good.
Stelian
On Sun, Jan 11, 2015 at 2:29 PM, F & N Laupretre
wrote:
> Hi,
>
> A new RFC for PHP7 : ht
On Sun, Jan 11, 2015 at 9:08 AM, Pierre Joye wrote:
> Ideally I like to include that in pickle, so one can package a release
> from the PHP files/repo to generate the resulting extension package.
I need to be more clear here :)
I like to have this in pickle, so the same package can be used to
i
On Sun, Jan 11, 2015 at 8:40 AM, Sara Golemon wrote:
> On Sat, Jan 10, 2015 at 11:18 PM, Pierre Joye wrote:
>> More than adding a new layer, I would love to see something similar to
>> hhvm or Zephir available by default. If C is used, then only the
>> relevant parts have to be implement by the d
On Sun, Jan 11, 2015 at 2:24 AM, Lester Caine wrote:
> On 11/01/15 04:08, Sara Golemon wrote:
>> My idea is to cover *most* (but not all) extensions with a narrower,
>> simplified API. As you say, many interactions fall into the "marshal
>> this engine value to a C type as needed". This can cate
On Sat, Jan 10, 2015 at 11:18 PM, Pierre Joye wrote:
> More than adding a new layer, I would love to see something similar to
> hhvm or Zephir available by default. If C is used, then only the
> relevant parts have to be implement by the developers, skipping all
> the over complicated data manglin
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
>>> On Sun, Jan 11, 2015 at 3:36 PM, Pierre Joye wrote:
>>> Well, the feature list for PHP7 is not closed yet. I hope new attractive
>>> features will be added soon because, otherwise, it will
>>> be very hard to sell.
> De : Pierre Joye [mailto:pierre@gmail.com]
>
> More than adding a new layer, I would love to see something similar to
> hhvm or Zephir available by default. If C is used, then only the
> relevant parts have to be implement by the developers, skipping all
> the over complicated data mangling,
Hi,
A new RFC for PHP7 : https://wiki.php.net/rfc/array-to-string
Not implemented yet, but the PR is available for comments :
https://github.com/php/php-src/pull/991
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11/01/15 04:08, Sara Golemon wrote:
> My idea is to cover *most* (but not all) extensions with a narrower,
> simplified API. As you say, many interactions fall into the "marshal
> this engine value to a C type as needed". This can cater to the
> bread-and-butter of PHP extensions very well.
H
On Sat, Jan 10, 2015 at 9:16 AM, Pierre Joye wrote:
> On Sun, Jan 4, 2015 at 3:52 AM, Benjamin Eberlei
> wrote:
> > Hey everyone,
> >
> > I want to open discussion on my RFC to strengthen the ability of
> extensions
> > to provide functionality to developers in both C **and** PHP code.
> >
> > F
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 08/01/2015 18:30, Julien Pauli a écrit :
> Hello
>
> PHP 5.5.21 RC1 is available for testing.
Trying to understand why Horde_Imap_Client test suite start to fail
with PHP 5.5.21RC1 and 5.6.5RC1.
This seeems related to
http://git.php.net/?p=php-s
Am 11.01.2015 um 09:03 schrieb Ferenc Kovacs:
> There is https://github.com/nikic/php-ast
Aha! Thanks for the pointer, Ferenc. Can we get this bundled with
PHP 7 (and enabled by default)?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.ph
2015.01.11. 7:55 ezt írta ("Sebastian Bergmann" ):
>
> Am 25.08.2014 um 19:39 schrieb Nikita Popov:
> > I don't know if I will be implementing that ext myself. In any case,
before
> > that can happen I will have to create another RFC for converting parse
> > errors into exceptions and making sure w
50 matches
Mail list logo
