Re: [PHP-DEV] Changes to Git commit workflow

[Rasmus Lerdorf]

On Sun, Mar 28, 2021 at 17:15 Sara Golemon  wrote:

> On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella 
> wrote:
>
>> You might consider requiring commits be signed while you're at it.
>>
>>
> I suggested this as well, and even if we don't require it, we should
> STRONGLY encourage it.
>
> I've been signing my commits for several years now, it's not even that
> hard.
>
I think for php-src commits we can require it. For doc and other repos we
can make it optional for now until people are more comfortable with it.

-Rasmus

Re: [PHP-DEV] Typed array properties V2

[Rasmus Lerdorf]

On Sun, Jan 19, 2020 at 4:53 PM Mike Schinkel  wrote:

> Also, Rowan Collins mentioned that checks in Go can be disabled for
> runtime checking; maybe we could support an option that disables said
> checking so that production sites could run w/o checks but we could run
> checks in development, testing and staging. We could also have an option to
> disable checking of array types above a given size of array, maybe
> defaulting to 1024? Clearly both of these would be no worse than what we
> have today.
>

You are getting into static analysis territory here with that. There are
already static analysis tools that do exactly this type of array type
checking during development. For example, there are three type mistakes in
this code:

 1 
 7*/
 8   static function f(array $ints, array $strings):array {
 9   return array_combine($strings, $ints);
10   }
11 }
12 print_r(C::f([3,2,'1'], ['abc', 'def', 42]));

Running Phan on it produces:

array.php:9 PhanTypeMismatchReturn Returning type array but f()
is declared to return array
array.php:12 PhanTypeMismatchArgument Argument 1 ($ints) is
array{0:3,1:2,2:'1'} but \C::f() takes int[] defined at array.php:8
array.php:12 PhanTypeMismatchArgument Argument 2 ($strings) is
array{0:'abc',1:'def',2:42} but \C::f() takes string[] defined at
array.php:8

The code itself would run in production without errors, of course, and
would produce:

Array
(
[abc] => 3
[def] => 2
[42] => 1
)

But at Etsy, at least, this code would never make it to production because
static analysis checks are run by all developers and also run automatically
during staging prior to a production push.

Really expensive checks like this belong at the static analysis stage. And
yes, it would be amazing to have a static analyzer built into PHP, which is
basically what you are asking for here, but that is a huge task and goes
way beyond just this particular check.

-Rasmus

[PHP-DEV] Re: [PHP-CVS] com php-src: Update alloc patch: Zend/zend_alloc.c

[Rasmus Lerdorf]

Crap, brain freeze. Pushed this patch from the wrong window. Reverting.

-Rasmus

On Wed, Oct 23, 2019 at 2:31 PM Rasmus Lerdorf  wrote:

> Commit:5870efbcf5235bb7328fe7cea3b8e2b92fb9fc0d
> Author:Rasmus Lerdorf  Wed, 23 Oct 2019
> 14:31:27 -0700
> Parents:   c744531fff9ee03c027ca3c18b21f3382023ff7e
> Branches:  PHP-7.4
>
> Link:
> http://git.php.net/?p=php-src.git;a=commitdiff;h=5870efbcf5235bb7328fe7cea3b8e2b92fb9fc0d
>
> Log:
> Update alloc patch
>
> Changed paths:
>   M  Zend/zend_alloc.c
>
>
> Diff:
> diff --git a/Zend/zend_alloc.c b/Zend/zend_alloc.c
> index 21ccf850496..a1d3ad680fa 100644
> --- a/Zend/zend_alloc.c
> +++ b/Zend/zend_alloc.c
> @@ -195,6 +195,11 @@ typedef struct  _zend_mm_free_slot zend_mm_free_slot;
>  typedef struct  _zend_mm_chunk zend_mm_chunk;
>  typedef struct  _zend_mm_huge_list zend_mm_huge_list;
>
> +/*
> + * 0 means disabled
> + * 1 means huge pages
> + * 2 means transparent huge pages
> + */
>  int zend_mm_use_huge_pages = 0;
>
>  /*
> @@ -229,6 +234,13 @@ int zend_mm_use_huge_pages = 0;
>   *   2 for 5-8, 3 for 9-16 etc) see zend_alloc_sizes.h
>   */
>
> +/*
> + * For environments where mmap is expensive it can be
> + * worthwhile to avoid mmap/munmap churn by raising
> + * the minimum number of chunks in emalloc
> + */
> +int zend_mm_min_chunks = 0;
> +
>  struct _zend_mm_heap {
>  #if ZEND_MM_CUSTOM
> intuse_custom_heap;
> @@ -462,7 +474,7 @@ static void *zend_mm_mmap(size_t size)
> void *ptr;
>
>  #ifdef MAP_HUGETLB
> -   if (zend_mm_use_huge_pages && size == ZEND_MM_CHUNK_SIZE) {
> +   if (zend_mm_use_huge_pages == 1 && size == ZEND_MM_CHUNK_SIZE) {
> ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE
> | MAP_ANON | MAP_HUGETLB, -1, 0);
> if (ptr != MAP_FAILED) {
> return ptr;
> @@ -669,7 +681,7 @@ static void *zend_mm_chunk_alloc_int(size_t size,
> size_t alignment)
> return NULL;
> } else if (ZEND_MM_ALIGNED_OFFSET(ptr, alignment) == 0) {
>  #ifdef MADV_HUGEPAGE
> -   if (zend_mm_use_huge_pages) {
> +   if (zend_mm_use_huge_pages == 2) {
> madvise(ptr, size, MADV_HUGEPAGE);
> }
>  #endif
> @@ -702,7 +714,7 @@ static void *zend_mm_chunk_alloc_int(size_t size,
> size_t alignment)
> zend_mm_munmap((char*)ptr + size, alignment -
> REAL_PAGE_SIZE);
> }
>  # ifdef MADV_HUGEPAGE
> -   if (zend_mm_use_huge_pages) {
> +   if (zend_mm_use_huge_pages == 2) {
> madvise(ptr, size, MADV_HUGEPAGE);
> }
>  # endif
> @@ -2270,7 +2282,7 @@ void zend_mm_shutdown(zend_mm_heap *heap, int full,
> int silent)
> zend_mm_chunk_free(heap, heap->main_chunk,
> ZEND_MM_CHUNK_SIZE);
> } else {
> /* free some cached chunks to keep average count */
> -   heap->avg_chunks_count = (heap->avg_chunks_count +
> (double)heap->peak_chunks_count) / 2.0;
> +   heap->avg_chunks_count = MAX((heap->avg_chunks_count +
> (double)heap->peak_chunks_count) / 2.0, zend_mm_min_chunks);
> while ((double)heap->cached_chunks_count + 0.9 >
> heap->avg_chunks_count &&
>heap->cached_chunks) {
> p = heap->cached_chunks;
> @@ -2278,6 +2290,7 @@ void zend_mm_shutdown(zend_mm_heap *heap, int full,
> int silent)
> zend_mm_chunk_free(heap, p, ZEND_MM_CHUNK_SIZE);
> heap->cached_chunks_count--;
> }
> +
> /* clear cached chunks */
> p = heap->cached_chunks;
> while (p != NULL) {
> @@ -2759,8 +2772,16 @@ static void alloc_globals_ctor(zend_alloc_globals
> *alloc_globals)
>  #endif
>
> tmp = getenv("USE_ZEND_ALLOC_HUGE_PAGES");
> -   if (tmp && zend_atoi(tmp, 0)) {
> -   zend_mm_use_huge_pages = 1;
> +if (tmp) {
> +   zend_mm_use_huge_pages = zend_atoi(tmp, 0);
> +   if (zend_mm_use_huge_pages > 2) {
> +   zend_mm_use_huge_pages = 1;
> +   }
> +   }
> +
> +   tmp = getenv("USE_ZEND_MIN_CHUNKS");
> +   if (tmp) {
> +   zend_mm_min_chunks = zend_atoi(tmp, 0);
> }
> alloc_globals->mm_heap = zend_mm_init();
>  }
>
>
> --
> PHP CVS Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Error when POST / upload limits are exceeded

[Rasmus Lerdorf]

On Tue, Oct 1, 2019 at 8:25 AM Benjamin Morel 
wrote:

> > Perhaps a more generic $_SERVER['PHP_REQUEST_STATUS'] or something along
> those lines where you'd put the error message from
> https://www.php.net/manual/en/features.file-upload.errors.php as well.
> And add new states for these exceeded limits that aren't caught there. It
> would be nice if you just needed a single check instead of having to look
> for multiple things.
>
> Those are per-file error codes, that belong in each $_FILES entry, while
> the errors I'm talking about affect the whole request, so I'm afraid you
> cannot put these errors in the same place, nor can you extend the existing
> error codes, as they do not have the same scope!
>

I know they are per-file errors. I wrote that code :)

But you could still have a global status that specifies whether an error
occurred or not. Then you can go look for which file it occurred on in the
$_FILES array. The idea is to have a single check that tells you if
everything was fine on the request.

-Rasmus

Re: [PHP-DEV] Error when POST / upload limits are exceeded

[Rasmus Lerdorf]

On Tue, Oct 1, 2019 at 6:32 AM Benjamin Morel 
wrote:

> > We have https://www.php.net/manual/en/features.file-upload.errors.php but
> in general this is not so easy to make more convenient because this runs
> before your PHP code starts to run, so it is not like you can stick it in a
> try/catch.
>
> Hi Rasmus,
>
> These errors are only relevant when you have something in $_FILES, which
> is not always the case I'm afraid:
>
> - when exceeding post_max_size, $_FILES is empty
> - when exceeding max_file_uploads, you don't get entries in $_FILES past
> the nth allowed file
>
> I understand that because all of this happens before userland code is run,
> indeed it's not possible to catch it.
> I also understand that throwing a fatal error in this case would not be
> welcome, as it does not give userland code a chance to inform the user
> about the problem.
>
> What about setting a $_SERVER value in this case? For example:
>
> $_SERVER['CONFIG_LIMIT_EXCEEDED'] = 'post_max_size'
>
> This, together with empty $_POST and $_FILES if any limit is exceeded
> (including max_file_uploads), should be relatively sane behaviour IMO.
>

Perhaps a more generic $_SERVER['PHP_REQUEST_STATUS'] or something along
those lines where you'd put the error message from
https://www.php.net/manual/en/features.file-upload.errors.php as well. And
add new states for these exceeded limits that aren't caught there. It would
be nice if you just needed a single check instead of having to look for
multiple things.

-Rasmus

Re: [PHP-DEV] Error when POST / upload limits are exceeded

[Rasmus Lerdorf]

On Tue, Oct 1, 2019 at 1:00 AM Benjamin Morel 
wrote:

> Hi internals,
>
> One thing that always bugged me is how PHP silently ignores data that
> exceeds the limits defined in php.ini.
>
> For example, posting a form exceeding post_max_size results in empty $_POST
> and $_FILES, with no error message whatsoever. This has bugged a few more
> people than just myself, if I believe this StackOverflow question
>  with 37k views.
>
> Another example is max_file_uploads: if I upload more files that the
> configured value, the subsequent files are silently ignored, and only the
> first n files appear in $_FILES.
>
> I'd like to work on an RFC to make all these errors in PHP 8 (ideally with
> a way to catch the error, but I'm not sure how to do that), but would love
> to get some feedback/ideas before venturing in an RFC.
>

We have https://www.php.net/manual/en/features.file-upload.errors.php but
in general this is not so easy to make more convenient because this runs
before your PHP code starts to run, so it is not like you can stick it in a
try/catch.

-Rasmus

[PHP-DEV] Evolving PHP

[Rasmus Lerdorf]

Lots of drama on internals lately. Not that different from 15-20 years ago.
A couple of things to keep in mind for everyone.

It is not that hard to write a tool that perfectly fits your own needs and
people who are very similar to you in terms of skillset, background and
overall experience. What PHP has always strived to do is to be much broader
than that. Writing a tool that is very approachable to beginners that can
still scale to some of the largest sites in the world is a much harder and
more interesting problem and requires some compromises on both ends.

The people writing the code get to call the shots, for better or worse. In
the beginning I called all the shots. As more people started to contribute
it took me a while to let go and accept contributions I didn't agree with.
We wouldn't be here today if I hadn't done that.

-Rasmus

Re: [PHP-DEV] Re: P++: FAQ

[Rasmus Lerdorf]

On Sat, Aug 10, 2019 at 5:37 AM Andrea Faulds  wrote:

> As the person who initially proposed and implemented strict_types, I
> think this is heading in the wrong direction. Perhaps that directive was
> a mistake, if it will lead to so many attempts inspired by it to
> fragment the language, including this one. Personally, I don't actually
> want a language like C++ or Java. PHP's flexibility is great, and I
> think splitting the language means going in a direction where you are
> forced to have everything be strict or nothing be. PHP++ sounds like
> Hack, but in mainline. I think it'll end up a mess in the long term.
>

Yes, I would suspect it would get a bit weird having a AnythingGoes
vs. NothingGoes barrier in the code like that. Forcing a balance, even
if sometimes the arguments get rather heated (and they were just as
heated, if not more so 20+ years ago), keeps everyone on the same
page and working on the same code-base without the us vs. them
situation that is bound to creep in.

-Rasmus

[PHP-DEV] Re: [PHP-CVS] com php-src: Prepare 7.3.6RC1: NEWS Zend/zend.h configure.ac main/php_version.h

[Rasmus Lerdorf]

Christoph, I think we should merge
http://git.php.net/?p=php-src.git;a=commitdiff;h=5c4d125d4c2976236e2ecddd1d8c6e7b113ec482
into 7.3.6.

-Rasmus

Re: [PHP-DEV] Re: PHP 7.3 dom change?

[Rasmus Lerdorf]

On Tue, Apr 2, 2019 at 2:22 AM Anatol Belski  wrote:

> On Mon, 2019-04-01 at 13:42 -0700, Rasmus Lerdorf wrote:
> > On Mon, Apr 1, 2019 at 9:25 AM Rasmus Lerdorf 
> > wrote:
> >
> > > I've been walking through the PHP 7.2->7.3 ext/dom diffs but I
> > > don't see
> > > what has caused this change: https://3v4l.org/hEmmR
> > > What did I miss?
> > >
> >
> > Tracked it down to this bug fix:  https://bugs.php.net/76285
> >
> Ah, I recall this one now. It was about saveHtml() not respecting
> format, had some follow ups, too. Should be harmless but might breach
> some test. Please ping, if there is a further issue.
>

Yeah, it broke some tests and there is no mention of it in the migration
docs.

-Rasmus

[PHP-DEV] Re: PHP 7.3 dom change?

[Rasmus Lerdorf]

On Mon, Apr 1, 2019 at 9:25 AM Rasmus Lerdorf  wrote:

> I've been walking through the PHP 7.2->7.3 ext/dom diffs but I don't see
> what has caused this change: https://3v4l.org/hEmmR
> What did I miss?
>

Tracked it down to this bug fix:  https://bugs.php.net/76285

-Rasmus

[PHP-DEV] PHP 7.3 dom change?

[Rasmus Lerdorf]

I've been walking through the PHP 7.2->7.3 ext/dom diffs but I don't see
what has caused this change: https://3v4l.org/hEmmR
What did I miss?

-Rasmus

Re: [PHP-DEV] bugs.php.net problems?

[Rasmus Lerdorf]

On Sat, Feb 9, 2019 at 4:17 PM Ben Ramsey  wrote:

> > On Feb 9, 2019, at 18:15, Stanislav Malyshev 
> wrote:
> >
> > Hi!
> >
> > I am trying to access bugs.php.net and I am getting timeouts all the
> > time today (TLS handshake passes, but no content is delivered). Seems to
> > be something wrong with the site? Could somebody check it?
>
>
> I’ve been experiencing the same thing today and yesterday. Traceroute and
> ping returns fine, but anything over port 443 is very slow and times out
> sometimes. At other times, the website loads fast.
>

Are you still seeing this? It is a Digital Ocean VM in NYC1 and I don't see
anything odd aboout it. Are you hitting it over ipv4 or ipv6?

-Rasmus

Re: [PHP-DEV] [RFC] Preloading

[Rasmus Lerdorf]

On Fri, Oct 19, 2018 at 1:17 AM, Dmitry Stogov  wrote:
>
> I would like to start discussion on a Preloadng RFC
> https://wiki.php.net/rfc/preload


I have been playing with this a bit this weekend.

It is tricky to tell if it is working.  I think it would be helpful if the
opcache section on the phpinfo page, and/or opcache_get_status() would have
some way to see which scripts are preloaded.

-Rasmus

Re: [PHP-DEV] [RFC] Preloading

[Rasmus Lerdorf]

On Fri, Oct 19, 2018 at 1:17 AM, Dmitry Stogov  wrote:

> Hi Internals,
>
> I would like to start discussion on a Preloadng RFC
> https://wiki.php.net/rfc/preload
>
> This technology would allow loading some PHP files on server startup and
> make all the defined classes and functions to be permanently available in
> the context of future request (without any includes). Despite of
> performance improvement, this technology is going to be used in conjunction
> with ext/FFI and JIT.
>
>
> The implementation is not 100% complete, it misses support for ZTS,
> because of a error in ZTS interned strings implementation.
>
> I'll try to fix this in nearest week(s).
>

Definitely cool.

I think it is going to make the file-cache more important as deploy
mechanisms are now going to be more likely to do a full cache reset on a
deploy so being able to quickly repopulate the shared memory cache from the
file cache might help lessen the perf hit of the cache reset.

-Rasmus

Re: [PHP-DEV] News and mailing lists were down. Up again?

[Rasmus Lerdorf]

On Tue, Aug 28, 2018 at 2:52 AM, Jan Ehrhardt  wrote:

> https://bugs.php.net/bug.php?id=76743
>
> Are we back?
>

 Hopefully. Watching it closely today.

[PHP-DEV] Re: news.php.net dead?

[Rasmus Lerdorf]

Has been for a while. It is on the same box as lists.php.net which died. We
are working on it.

On Sun, Aug 26, 2018 at 11:40 PM, Stanislav Malyshev 
wrote:

> Hi!
>
> Looks like news.php.net is not responding. Anybody could check what's up
> with this?
>
> Thanks,
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] bugs.php.net downtime

[Rasmus Lerdorf]

Ok, should be fixed now. https://bugs.php.net/bug.php?id=76553 looks good.
But I think between my backup and the conversion I lost a couple of bug
comments from this morning. Sorry about that.

-Rasmus

On Sat, Jul 21, 2018 at 8:31 AM, Rasmus Lerdorf  wrote:

> Uh, ok, something obviously went wrong there. Checking.
>
> On Sat, Jul 21, 2018 at 8:30 AM, Rasmus Lerdorf 
> wrote:
>
>> For future reference, here is what I did to fix the encoding problem:
>>
>> MariaDB [phpbugsdb]> select sdesc from bugdb where id=76553;
>> +---
>> 
>> -+
>> | sdesc
>>
>>|
>> +---
>> 
>> -+
>> | Ð˜Ð¼Ñ Ð¿ÐµÑ€ÐµÐ¼ÐµÐ½Ð½Ð¾Ð¹ может Ñ Ð¾Ð´ÐµÑ€Ð¶Ð°Ñ‚ÑŒ управлÑ
>> ющие
>> |
>> +---
>> 
>> -+
>> 1 row in set (0.00 sec)
>>
>> MariaDB [phpbugsdb]> alter table bugdb drop index email;
>> Query OK, 76298 rows affected (0.85 sec)
>> Records: 76298  Duplicates: 0  Warnings: 0
>>
>> MariaDB [phpbugsdb]> alter table bugdb modify sdesc varbinary(80) NOT
>> NULL DEFAULT '', modify ldesc binary NOT NULL, modify email varbinary(40)
>> NOT NULL DEFAULT '';
>> Query OK, 76298 rows affected, 65535 warnings (0.65 sec)
>> Records: 76298  Duplicates: 0  Warnings: 76091
>>
>> MariaDB [phpbugsdb]> alter table bugdb modify sdesc varchar(80) CHARACTER
>> SET utf8mb4 NOT NULL DEFAULT '', modify ldesc text CHARACTER SET utf8mb4
>> NOT NULL, modify email varchar(40) CHARACTER SET utf8mb4 NOT NULL DEFAULT
>> '';
>> Query OK, 76298 rows affected, 127 warnings (0.57 sec)
>> Records: 76298  Duplicates: 0  Warnings: 127
>>
>> MariaDB [phpbugsdb]> alter table bugdb add FULLTEXT INDEX `email`
>> (`email`,`sdesc`,`ldesc`);
>> Query OK, 76298 rows affected (1.56 sec)
>> Records: 76298  Duplicates: 0  Warnings: 0
>>
>> MariaDB [phpbugsdb]> select sdesc from bugdb where id=76553;
>> +---
>> ---+
>> | sdesc
>>  |
>> +---
>> ---+
>> | Имя переменной может содержать управляющие
>>   |
>> +---
>> ---+
>> 1 row in set (0.00 sec)
>>
>> The trick was to convert the columns to binary first. When I went
>> straight from latin1 to utf8 I got the utf8 equivalent of the latin1
>> characters. By telling it that the data was actually binary first, it
>> converted from binary to utf8 which appears to have worked. There were some
>> warnings, which I assume are invalid utf8 byte sequences somewhere.
>>
>> -Rasmus
>>
>
>

Re: [PHP-DEV] bugs.php.net downtime

[Rasmus Lerdorf]

Uh, ok, something obviously went wrong there. Checking.

On Sat, Jul 21, 2018 at 8:30 AM, Rasmus Lerdorf  wrote:

> For future reference, here is what I did to fix the encoding problem:
>
> MariaDB [phpbugsdb]> select sdesc from bugdb where id=76553;
> +---
> 
> -+
> | sdesc
>
>|
> +---
> 
> -+
> | Ð˜Ð¼Ñ Ð¿ÐµÑ€ÐµÐ¼ÐµÐ½Ð½Ð¾Ð¹ может Ñ Ð¾Ð´ÐµÑ€Ð¶Ð°Ñ‚ÑŒ управлÑ
> ющие
> |
> +---
> 
> -+
> 1 row in set (0.00 sec)
>
> MariaDB [phpbugsdb]> alter table bugdb drop index email;
> Query OK, 76298 rows affected (0.85 sec)
> Records: 76298  Duplicates: 0  Warnings: 0
>
> MariaDB [phpbugsdb]> alter table bugdb modify sdesc varbinary(80) NOT NULL
> DEFAULT '', modify ldesc binary NOT NULL, modify email varbinary(40) NOT
> NULL DEFAULT '';
> Query OK, 76298 rows affected, 65535 warnings (0.65 sec)
> Records: 76298  Duplicates: 0  Warnings: 76091
>
> MariaDB [phpbugsdb]> alter table bugdb modify sdesc varchar(80) CHARACTER
> SET utf8mb4 NOT NULL DEFAULT '', modify ldesc text CHARACTER SET utf8mb4
> NOT NULL, modify email varchar(40) CHARACTER SET utf8mb4 NOT NULL DEFAULT
> '';
> Query OK, 76298 rows affected, 127 warnings (0.57 sec)
> Records: 76298  Duplicates: 0  Warnings: 127
>
> MariaDB [phpbugsdb]> alter table bugdb add FULLTEXT INDEX `email`
> (`email`,`sdesc`,`ldesc`);
> Query OK, 76298 rows affected (1.56 sec)
> Records: 76298  Duplicates: 0  Warnings: 0
>
> MariaDB [phpbugsdb]> select sdesc from bugdb where id=76553;
> +---
> ---+
> | sdesc
>  |
> +---
> ---+
> | Имя переменной может содержать управляющие
> |
> +---
> ---+
> 1 row in set (0.00 sec)
>
> The trick was to convert the columns to binary first. When I went straight
> from latin1 to utf8 I got the utf8 equivalent of the latin1 characters. By
> telling it that the data was actually binary first, it converted from
> binary to utf8 which appears to have worked. There were some warnings,
> which I assume are invalid utf8 byte sequences somewhere.
>
> -Rasmus
>

Re: [PHP-DEV] bugs.php.net downtime

[Rasmus Lerdorf]

For future reference, here is what I did to fix the encoding problem:

MariaDB [phpbugsdb]> select sdesc from bugdb where id=76553;
++
| sdesc

 |
++
| Ð˜Ð¼Ñ Ð¿ÐµÑ€ÐµÐ¼ÐµÐ½Ð½Ð¾Ð¹ может Ñ Ð¾Ð´ÐµÑ€Ð¶Ð°Ñ‚ÑŒ управлÑ
ющие
|
++
1 row in set (0.00 sec)

MariaDB [phpbugsdb]> alter table bugdb drop index email;
Query OK, 76298 rows affected (0.85 sec)
Records: 76298  Duplicates: 0  Warnings: 0

MariaDB [phpbugsdb]> alter table bugdb modify sdesc varbinary(80) NOT NULL
DEFAULT '', modify ldesc binary NOT NULL, modify email varbinary(40) NOT
NULL DEFAULT '';
Query OK, 76298 rows affected, 65535 warnings (0.65 sec)
Records: 76298  Duplicates: 0  Warnings: 76091

MariaDB [phpbugsdb]> alter table bugdb modify sdesc varchar(80) CHARACTER
SET utf8mb4 NOT NULL DEFAULT '', modify ldesc text CHARACTER SET utf8mb4
NOT NULL, modify email varchar(40) CHARACTER SET utf8mb4 NOT NULL DEFAULT
'';
Query OK, 76298 rows affected, 127 warnings (0.57 sec)
Records: 76298  Duplicates: 0  Warnings: 127

MariaDB [phpbugsdb]> alter table bugdb add FULLTEXT INDEX `email`
(`email`,`sdesc`,`ldesc`);
Query OK, 76298 rows affected (1.56 sec)
Records: 76298  Duplicates: 0  Warnings: 0

MariaDB [phpbugsdb]> select sdesc from bugdb where id=76553;
+--+
| sdesc
   |
+--+
| Имя переменной может содержать управляющие
|
+--+
1 row in set (0.00 sec)

The trick was to convert the columns to binary first. When I went straight
from latin1 to utf8 I got the utf8 equivalent of the latin1 characters. By
telling it that the data was actually binary first, it converted from
binary to utf8 which appears to have worked. There were some warnings,
which I assume are invalid utf8 byte sequences somewhere.

-Rasmus

Re: [PHP-DEV] bugs.php.net downtime

[Rasmus Lerdorf]

By the way, the following users have ssh accounts on bugs.php.net:
bjori  derick  felipe  nikic  rasmus  sas  scottmac  tyrael

the error log is in /srv/bugs.php.net/logs/error.log
and the code is here: g...@git.php.net:/web/bugs.git

Feel free to log in and fix stuff as you find more issues. Right now the
patch handling is still broken along with the latin1 columns that need to
be converted to utf8.

-Rasmus

Re: [PHP-DEV] bugs.php.net downtime

[Rasmus Lerdorf]

Yeah, working on it. Amazingly it looks like it is an ipv6 issue. The old
bugs didn't have an ipv6 address, but the new one does and we store the ip
of the commenter using the MySQL function inet_aton() and not inet6_aton().
Need to change that, but also alter the table to make the column fit an
ipv6 addr.

On Sat, Jul 21, 2018 at 6:18 AM, Christoph M. Becker 
wrote:

> On 21.07.2018 at 12:10, Rasmus Lerdorf wrote:
>
> > Works fine for me on https://bugs.php.net/bug.php?id=76635=1
>
> I just commented “Testing”, but the comment isn't there.  Don't the
> error logs give some useful hints?
>
> > On Sat, Jul 21, 2018 at 6:06 AM, Christoph M. Becker 
> > wrote:
> >
> >> On 21.07.2018 at 11:51, Rasmus Lerdorf wrote:
> >>
> >>> That one should be fixed. It was actually posting the comments, but
> >> getting
> >>> an error after. If you reload the bug you see it.
> >>
> >> I've commented multiple times on bug 76637, but none of the comments are
> >> visible.  I also commented on bug 76642 and successfully changed a typo
> >> in the title (summary), but the “meta info changed” comment is not there
> >> either.
> >>
> >>> On Sat, Jul 21, 2018 at 5:41 AM, Christoph M. Becker <
> cmbecke...@gmx.de>
> >>> wrote:
> >>>
> >>>> On 21.07.2018 at 10:46, Nikita Popov wrote:
> >>>>
> >>>>> On Tue, Jul 17, 2018 at 10:38 PM, Rasmus Lerdorf  >
> >>>> wrote:
> >>>>>
> >>>>>> I need to move bugs.php.net to another server sometime today. I
> won't
> >>>> be
> >>>>>> able to do it without a little bit of downtime as I have to stop new
> >>>>>> activity on the existing box, copy the DB over and then point DNS to
> >> the
> >>>>>> new box. The DNS TTL is only 5 minutes, so it shouldn't be
> unavailable
> >>>> for
> >>>>>> much longer than that.
> >>>>>>
> >>>>>> Hopefully the new box will be a bit quicker too. It is moving from
> PHP
> >>>> 5.5
> >>>>>> to 7.2 on faster hardware.
> >>>>>
> >>>>> I'm getting a WSOD when trying to add a comment to a bug while logged
> >> in.
> >>>>> Not sure what's different for me, as it seems to work for other @
> >> php.net
> >>>>> users.
> >>>>
> >>>> Same for me; it doesn't matter whether I'm logged in as cmb@ or just
> >>>> commenting as user.  Interestingly, altough I get the 500, I can
> change
> >>>> the meta information (status, summary, etc.), but no comment is added.
>

Re: [PHP-DEV] bugs.php.net downtime

[Rasmus Lerdorf]

Works fine for me on https://bugs.php.net/bug.php?id=76635=1

On Sat, Jul 21, 2018 at 6:06 AM, Christoph M. Becker 
wrote:

> On 21.07.2018 at 11:51, Rasmus Lerdorf wrote:
>
> > That one should be fixed. It was actually posting the comments, but
> getting
> > an error after. If you reload the bug you see it.
>
> I've commented multiple times on bug 76637, but none of the comments are
> visible.  I also commented on bug 76642 and successfully changed a typo
> in the title (summary), but the “meta info changed” comment is not there
> either.
>
> > On Sat, Jul 21, 2018 at 5:41 AM, Christoph M. Becker 
> > wrote:
> >
> >> On 21.07.2018 at 10:46, Nikita Popov wrote:
> >>
> >>> On Tue, Jul 17, 2018 at 10:38 PM, Rasmus Lerdorf 
> >> wrote:
> >>>
> >>>> I need to move bugs.php.net to another server sometime today. I won't
> >> be
> >>>> able to do it without a little bit of downtime as I have to stop new
> >>>> activity on the existing box, copy the DB over and then point DNS to
> the
> >>>> new box. The DNS TTL is only 5 minutes, so it shouldn't be unavailable
> >> for
> >>>> much longer than that.
> >>>>
> >>>> Hopefully the new box will be a bit quicker too. It is moving from PHP
> >> 5.5
> >>>> to 7.2 on faster hardware.
> >>>
> >>> I'm getting a WSOD when trying to add a comment to a bug while logged
> in.
> >>> Not sure what's different for me, as it seems to work for other @
> php.net
> >>> users.
> >>
> >> Same for me; it doesn't matter whether I'm logged in as cmb@ or just
> >> commenting as user.  Interestingly, altough I get the 500, I can change
> >> the meta information (status, summary, etc.), but no comment is added.
> >>
> >> --
> >> Christoph M. Becker
> >>
> >
>
>

Re: [PHP-DEV] bugs.php.net downtime

[Rasmus Lerdorf]

That one should be fixed. It was actually posting the comments, but getting
an error after. If you reload the bug you see it.

On Sat, Jul 21, 2018 at 5:41 AM, Christoph M. Becker 
wrote:

> On 21.07.2018 at 10:46, Nikita Popov wrote:
>
> > On Tue, Jul 17, 2018 at 10:38 PM, Rasmus Lerdorf 
> wrote:
> >
> >> I need to move bugs.php.net to another server sometime today. I won't
> be
> >> able to do it without a little bit of downtime as I have to stop new
> >> activity on the existing box, copy the DB over and then point DNS to the
> >> new box. The DNS TTL is only 5 minutes, so it shouldn't be unavailable
> for
> >> much longer than that.
> >>
> >> Hopefully the new box will be a bit quicker too. It is moving from PHP
> 5.5
> >> to 7.2 on faster hardware.
> >
> > I'm getting a WSOD when trying to add a comment to a bug while logged in.
> > Not sure what's different for me, as it seems to work for other @php.net
> > users.
>
> Same for me; it doesn't matter whether I'm logged in as cmb@ or just
> commenting as user.  Interestingly, altough I get the 500, I can change
> the meta information (status, summary, etc.), but no comment is added.
>
> --
> Christoph M. Becker
>

Re: [PHP-DEV] bugs.php.net downtime

[Rasmus Lerdorf]

On Thu, Jul 19, 2018 at 4:45 PM, Hoffman, Zachary Robert 
wrote:

> On Thu, 2018-07-19 at 22:35 +0200, Niklas Keller wrote:
> > Hey Rasmus
> >
> > I just found this bug: https://bugs.php.net/bug.php?id=76553
> >
> > Has this bug been like that before the migration, too? Or did
> > something go wrong?
>
> No, those used to be Unicode characters from the cyrillic block.


 This appears to be database-related. Something got messed up with
encodings on the mysql dump/import from MySQL 5.1.73 into MariaDB 10.1.26:

mysql> select sdesc from bugdb where id=76553;
+--+
| sdesc
   |
+--+
| Имя переменной может содержать управляющие |
+--+
1 row in set (0.00 sec)

MariaDB [phpbugsdb]> select sdesc from bugdb where id=76553;
++
| sdesc

 |
++
| Ð˜Ð¼Ñ Ð¿ÐµÑ€ÐµÐ¼ÐµÐ½Ð½Ð¾Ð¹ может Ñ Ð¾Ð´ÐµÑ€Ð¶Ð°Ñ‚ÑŒ управлÑ
ющие
|
++
1 row in set (0.00 sec)

The dumped table schema from MySQL has:

DROP TABLE IF EXISTS `bugdb`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `bugdb` (
  `id` int(8) NOT NULL AUTO_INCREMENT,
  `package_name` varchar(80) CHARACTER SET latin1 DEFAULT NULL,
  `bug_type` varchar(32) CHARACTER SET latin1 NOT NULL DEFAULT 'Bug',
  `email` varchar(40) CHARACTER SET latin1 NOT NULL DEFAULT '',
  `reporter_name` varchar(80) CHARACTER SET latin1 DEFAULT '',
  `sdesc` varchar(80) CHARACTER SET latin1 NOT NULL DEFAULT '',
  `ldesc` text CHARACTER SET latin1 NOT NULL,
  `php_version` varchar(100) CHARACTER SET latin1 DEFAULT NULL,
  `php_os` varchar(32) CHARACTER SET latin1 DEFAULT NULL,
  `status` varchar(16) CHARACTER SET latin1 DEFAULT NULL,
  `ts1` datetime DEFAULT NULL,
  `ts2` datetime DEFAULT NULL,
  `assign` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  `passwd` varchar(64) CHARACTER SET latin1 DEFAULT NULL,
  `registered` tinyint(1) NOT NULL DEFAULT '0',
  `block_user_comment` char(1) DEFAULT 'N',
  `cve_id` varchar(15) DEFAULT NULL,
  `private` char(1) DEFAULT 'N',
  `visitor_ip` int(10) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  KEY `php_version` (`php_version`(1)),
  KEY `status` (`status`),
  KEY `package_name` (`package_name`),
  FULLTEXT KEY `email` (`email`,`sdesc`,`ldesc`)
) ENGINE=MyISAM AUTO_INCREMENT=76637 DEFAULT CHARSET=utf8 PACK_KEYS=1;
/*!40101 SET character_set_client = @saved_cs_client */;

When I dump it from MariaDB I see:

DROP TABLE IF EXISTS `bugdb`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `bugdb` (
  `id` int(8) NOT NULL AUTO_INCREMENT,
  `package_name` varchar(80) CHARACTER SET latin1 DEFAULT NULL,
  `bug_type` varchar(32) CHARACTER SET latin1 NOT NULL DEFAULT 'Bug',
  `email` varchar(40) CHARACTER SET latin1 NOT NULL DEFAULT '',
  `reporter_name` varchar(80) CHARACTER SET latin1 DEFAULT '',
  `sdesc` varchar(80) CHARACTER SET latin1 NOT NULL DEFAULT '',
  `ldesc` text CHARACTER SET latin1 NOT NULL,
  `php_version` varchar(100) CHARACTER SET latin1 DEFAULT NULL,
  `php_os` varchar(32) CHARACTER SET latin1 DEFAULT NULL,
  `status` varchar(16) CHARACTER SET latin1 DEFAULT NULL,
  `ts1` datetime DEFAULT NULL,
  `ts2` datetime DEFAULT NULL,
  `assign` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  `passwd` varchar(64) CHARACTER SET latin1 DEFAULT NULL,
  `registered` tinyint(1) NOT NULL DEFAULT '0',
  `block_user_comment` char(1) DEFAULT 'N',
  `cve_id` varchar(15) DEFAULT NULL,
  `private` char(1) DEFAULT 'N',
  `visitor_ip` int(10) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  KEY `php_version` (`php_version`(1)),
  KEY `status` (`status`),
  KEY `package_name` (`package_name`),
  FULLTEXT KEY `email` (`email`,`sdesc`,`ldesc`)
) ENGINE=MyISAM AUTO_INCREMENT=76650 DEFAULT CHARSET=utf8 PACK_KEYS=1;
/*!40101 SET character_set_client = @saved_cs_client */;

Other than the autoincrement they are identical. I normally use utf8mb4,
but I figured I would play it safe and copy it over verbatim. I guess it
wasn't safe.
I'll do some research, but ideas welcome.

-Rasmus

Re: [PHP-DEV] bugs.php.net downtime

[Rasmus Lerdorf]

It looks like the MDB2 -> PDO migration messed this up. There is a weird
MDB2 feature fetchAll() feature that returns the first field as the
associative key or something like that. Need to rewrite the code to not
rely on that. The MDB2 query returns:

array(2) {
  ["fix-71630.patch"]=>
  array(1) {
[0]=>
array(2) {
  [0]=>
  string(10) "1522170171"
  [1]=>
  string(11) "c...@php.net"
}
  }
  ["zero-data.patch"]=>
  array(1) {
[0]=>
array(2) {
  [0]=>
  string(10) "1521729404"
  [1]=>
  string(11) "c...@php.net"
}
  }
}

And the PDO query gives:

array(2) {
  [0]=>
  array(3) {
["patch"]=>
string(15) "fix-71630.patch"
["revision"]=>
int(1522170171)
["developer"]=>
string(11) "c...@php.net"
  }
  [1]=>
  array(3) {
["patch"]=>
string(15) "zero-data.patch"
["revision"]=>
int(1521729404)
["developer"]=>
string(11) "c...@php.net"
  }
}

I will find some time to fix this in the next day or two unless someone
beats me to it.

-Rasmus

On Thu, Jul 19, 2018 at 4:35 AM, marius adrian popa 
wrote:

> Hello Rasmus,
>
> I can't access previous patches
>
> https://bugs.php.net/patch-display.php?bug_id=62300;
> patch=0=latest
>
> On Tue, Jul 17, 2018 at 11:38 PM, Rasmus Lerdorf 
> wrote:
>
>> I need to move bugs.php.net to another server sometime today. I won't be
>> able to do it without a little bit of downtime as I have to stop new
>> activity on the existing box, copy the DB over and then point DNS to the
>> new box. The DNS TTL is only 5 minutes, so it shouldn't be unavailable for
>> much longer than that.
>>
>> Hopefully the new box will be a bit quicker too. It is moving from PHP 5.5
>> to 7.2 on faster hardware.
>>
>> -Rasmus
>>
>
>

[PHP-DEV] bugs.php.net downtime

[Rasmus Lerdorf]

I need to move bugs.php.net to another server sometime today. I won't be
able to do it without a little bit of downtime as I have to stop new
activity on the existing box, copy the DB over and then point DNS to the
new box. The DNS TTL is only 5 minutes, so it shouldn't be unavailable for
much longer than that.

Hopefully the new box will be a bit quicker too. It is moving from PHP 5.5
to 7.2 on faster hardware.

-Rasmus

Re: [PHP-DEV] Re: PHP 7.3 Release Manager Selection

[Rasmus Lerdorf]

On Tue, May 1, 2018 at 11:19 AM, Sara Golemon  wrote:

> On Tue, Apr 24, 2018 at 1:54 PM, Sara Golemon  wrote:
> > On Thu, Apr 12, 2018 at 5:56 PM, Sara Golemon  wrote:
> >> Please put your name forward here if you wish to be considered a
> candidate.
> >> An initial todo page has been added to the wiki and contains
> >> provisional dates for GA and pre-releases.
> >> https://wiki.php.net/todo/php73
> >>
> > With 7.3.0-alpha1's date on June 7th I'd like to have RMs confirmed by
> > mid-May.  To that end, I'm placing a deadline on nomination/acceptance
> > of April 30th and will be opening the vote (assuming we have more than
> > 2) on May 1st.
> >
> Whelp! It's May day, and cmb and stas are the only official volunteers
> (Derick has withdrawn his offer to step in since Stas is available).
> With only two candidates, there's no need for a vote.
>
> Ladies and gentlemen, I give you your PHP 7.3 Release Managers:
> Christoph M. Becker and Stanislav Malyshev


Sounds like a great team. Thanks for volunteering, guys.

-Rasmus

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Rasmus Lerdorf]

On Wed, Jan 10, 2018 at 10:48 AM, Michael Morris <tendo...@gmail.com> wrote:

> On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf <ras...@lerdorf.com>
> wrote:
>
> >  If you stay away from trying to change a 25-year old loosely typed
> > language into a strictly typed one, then the RFC becomes much simpler.
> >
> > -Rasmus
> >
>
> I have REPEATEDLY stated that is not the goal. I don't misrepresent what
> you say, please do not do that to me.
>
> I want to see strict typing as an option, not a requirement.
>

But the point is that whether it is an option or not, it still has to touch
the zval. Which means everything changes whether the option is enabled or
not. If you store this information elsewhere, that other location has to be
checked on every zval access. Basically the work is identical to the work
required to make PHP strictly typed. Making it optional might actually be
harder because we have to build both and add more checks in that case.

The only viable place I see to store this optionally is outside the runtime
in a static analyzer like Phan (which already does this) which matches how
HHVM solved it. Of course, there may be a cleaner way to do it. But that is
why an RFC on this topic has to give a clear plan towards this cleaner
implementation.

Now if the RFC was a plan for baking a compile-time static analysis engine
into PHP itself, that would be interesting. But that is a *massive* project.

-Rasmus

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Rasmus Lerdorf]

On Wed, Jan 10, 2018 at 10:11 AM, Ryan Jentzsch 
wrote:

> I agree with Michael (to a large degree) and I think I see clearly
> Michael's point:
> Under the current system I will NEVER create an RFC (or find someone with
> the Zend engine coding chops to help me) because the RISK vs. REWARD with
> the current RFC system is too likely to be a colossal waste of everyone's
> time.
> Currently the tail wags the dog (implementation details govern top level
> policy). The current process nearly insists I spend valuable time coding up
> front with a good chance that if/when the RFC goes up for a vote someone
> will still be bleating about syntax, or using tabs vs. spaces, or some
> other minor detail -- with a 2/3 vote needed it may shoot all my
> preliminary hard work to hell. No thanks.


There is a middle ground here. I agree that doing months of work on a
rock-solid implementation doesn't make sense if you don't know the RFC will
pass. On the other end of the spectrum, RFCs that are essentially feature
requests with no specifics on the actual implementation also don't make any
sense. A good RFC strikes a happy balance between the two. For many/most
things, the actual work in figuring out the implementation isn't that bad.
As Sara said, a full implementation isn't needed, but a rough sketch of
what changes are needed along with their potential impact on the existing
code definitely is. And yes, unfortunately, if your RFC touches the basic
building block of PHP, the zval, then that rough sketch becomes even more
important. If you stay away from trying to change a 25-year old loosely
typed language into a strictly typed one, then the RFC becomes much simpler.

-Rasmus

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Rasmus Lerdorf]

On Wed, Jan 10, 2018 at 5:27 AM, Michael Morris  wrote:
>
> Also, drawing the architectural drawings for a skyscraper is also like only
> 10% of the work, but it's a damn important 10%.
>

Wow, that's rather insulting to the amazing work Dmitry, Nikita, Xinchen
and others are doing working on the core of PHP. Describing the syntax/UI
for a feature like this is nothing like the architectural drawings for a
skyscraper. The architectural drawings for a skyscraper are extremely
detailed and describe exactly how to build it including all materials,
tolerances, etc. The analogy here is more like you saying you would like a
blue skyscraper with 30 windows and a door and then complaining that the
idiot constructions crew should stop complaining and just build the thing.

There are plenty of things where the UI/syntax description is all that is
needed because the implementation is trivial and flows straight from such a
description. This doesn't happen to be one of those.

 -Rasmus

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Rasmus Lerdorf]

On Tue, Jan 9, 2018 at 3:06 PM, Michael Morris  wrote:

> Before I begin, and without picking on anyone specific, I want to say that
> it is generally unhelpful to say that because I, or others, do not know how
> the engine is set up that it is impossible to make any meaningful
> contributions to the list or on this issue specifically.  My clients don't
> understand HTML.  If I told them they needed to study how HTML works before
> trying to give me input on the sites I'm building for them I'd likely be
> fired.  As a theater major I know quite a bit more than most of the people
> on this list about what makes a good play or movie actually work, but I
> don't pretend that knowledge is prerequisite to knowing if a play or movie
> is good.  It either works, or it doesn't.
>

The difference here is that the end syntax is something like 10% of the
problem. 90% of it is fitting it into the engine in an efficient manner
giving that it is affecting the very core of the engine. An RFC on this
issue that doesn't address the bulk of the problem isn't all that helpful.

-Rasmus

Re: [PHP-DEV] RE: High resolution timer function

[Rasmus Lerdorf]

Definitely. Small, uncontroversial changes have never required an RFC.
Let's not add process just for the sake of process.

-Rasmus

On Fri, Jan 5, 2018 at 3:47 AM, Rowan Collins 
wrote:

> On 5 January 2018 at 10:38, Dan Ackroyd  wrote:
>
> > On 2 January 2018 at 13:55, Peter Cowburn 
> wrote:
> > >
> > >
> > > Why is this bypassing the RFC process?
> >
> > That's a very good question.
> >
> > Although I'm pretty sure an RFC for this would pass unanimously, stuff
> > should have to go through voting rather than relying on no-one
> > shouting loudly enough.
> >
>
>
> Just as a counter-point to this, I understand that many (Westminster
> style?) parliaments have mechanisms to skip uncontroversial votes by first
> requiring a show of hands or voices, and only "dividing the house" (making
> everyone get up and register their formal votes) if there is dissent.
>
> I think Anatol's intent here is similar: if anyone says "Nay", we can
> proceed with an RFC and vote; but if it's already unanimous, why spend the
> time, when we could be moving onto other business?
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Rasmus Lerdorf]

> On Jan 4, 2018, at 13:09, Andreas Hennings  wrote:
> 
> A system where all variables are type-locked could in fact be faster
> than a system with dynamically typed variables.
> Depends on the implementation, of course. I imagine it would be a lot
> of work to get there.

I think you, and many others, commenting here, should start by looking at the 
engine implementation. Any successful RFC needs to have a strong implementation 
behind it, or at the very least a very detailed description of how the 
implementation would mesh with the existing engine code.

The reason we don’t have typed properties/variables is that it would require 
adding type checks on almost every access to the underlying zval. That is a 
huge perf hit compared to only doing it on method/function egress points as we 
do now.

-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Mailing list moderation

[Rasmus Lerdorf]

Ok, both have been added to the ezmlm deny list for internals

On Tue, Jan 2, 2018 at 2:49 AM, Nikita Popov  wrote:

> Hi,
>
> This mail is going to both the systems group and internals mailing list.
>
> I would like to request a mailing list suspension for the users
> tonymars...@hotmail.com and li...@rhsoft.net, who have recently been
> aggressively derailing the "Scalar Pseudo-type" thread, despite requests to
> moderate their participation both in that thread, and on a number of
> previous instances -- this is certainly not the first time these two users
> have converted an RFC discussion into a dick measuring contest.
>
> If these users cannot be suspended, I would like to request specific
> instructions under what circumstances users can be suspended from the
> internals list, and what procedures need to be followed to achieve this.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] The site bugs.php.net appears to be down

[Rasmus Lerdorf]

Yeah, we know. Martin contacted Servergrove about 12 hours ago and we
haven't heard back. The machine itself is unreachable.

-Rasmus

Re: [PHP-DEV] Re: PHP's mail servers suck

[Rasmus Lerdorf]

It isn't super-helpful to publicly shame our active volunteers.

On Wed, Nov 8, 2017 at 3:33 PM, Sara Golemon <poll...@php.net> wrote:

> On Wed, Nov 8, 2017 at 9:11 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> > So please report that directly to systems@ (that's what it is there
> for) and
> > cc sascha@ specifically since he maintains php-smtp2. And php-smtp2 has
> been
> > around less than a year, so if you haven't reported it since the
> changeover
> > they probably never saw a report.
> >
> Yes, I'm aware of the systems@ distribution list. As you well know
> I've emailed it many times about various concerns, MOST of which are
> promptly responded to.  This one has never been dealt with, hence the
> public shaming.  The email server got replaced recently? Great,
> doesn't mean it fixed anything.
>
> If being an asshole publicly gets me the same response as being polite
> privately, then I might as well be public about it.
>
> -Sara
>

Re: [PHP-DEV] Re: PHP's mail servers suck

[Rasmus Lerdorf]

So please report that directly to systems@ (that's what it is there for)
and cc sascha@ specifically since he maintains php-smtp2. And php-smtp2 has
been around less than a year, so if you haven't reported it since the
changeover they probably never saw a report.

-Rasmus

On Wed, Nov 8, 2017 at 3:01 PM, Sara Golemon <poll...@php.net> wrote:

> On Wed, Nov 8, 2017 at 8:03 AM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> > Our smtp servers are actually quite well maintained by Sascha and
> company.
> >
> This is a response from the mail server, with no mailing list software
> involved.
> This is a regular response covering years.
> This is response which has been reported to no effect.
>
> Action: failed
> Status: 5.7.1
> Remote-MTA: dns; php-smtp2.php.net. (2a02:cb41::8, the server for the
> domain php.net.)
> Diagnostic-Code: smtp; 550 5.7.1 Looks like spam to me.
> Last-Attempt-Date: Tue, 07 Nov 2017 04:49:54 -0800 (PST)
>
> Yay that Sacha dealt with a slew of spam, but that's irrelevant to the
> false-positives problem.  If a sender using a php.net address can't
> send an email containing a php.net URL through php.net servers without
> looking like spam, then the configuration is broken.
>
> -Sara
>

Re: [PHP-DEV] Re: PHP's mail servers suck

[Rasmus Lerdorf]

> Without any generally available information about the existing email
> infrastructure, it's hard to make targeted comments about how to fix
> what is obviously broken with this system which literally nobody with
> the ability to fix cares about.  That means a either a conversation
> (which should be a shared experience (therefore internals@) or an
> essentially open request for "I'd like to help, but I'll need the
> ability to poke around to figure out wtf is going on".


Our smtp servers are actually quite well maintained by Sascha and company.
Which is a somewhat new thing, so if you are saying this has been going on
for years, the mail servers changed completely in there somewhere. And they
are quick to respond to specific problems if you send a useful description
of the issue to systems@

For example, last week a specific @php.net address apparently pissed off
the Internet and our smtp servers were being hammered with thousands of
messages per minute for this one person. Sascha was on the ball and had the
attack filtered quickly. Nobody here even noticed, I am sure.
We could definitely need a volunteer who knows ezmlm-idx and perhaps
modernize the config there, but on the smtp servers front things are under
control. I am sure Sascha and his team would love to see concrete examples
(as in with full headers) of any messages rejected at the smtp level.

-Rasmus

Re: [PHP-DEV] Re: PHP's mail servers suck

[Rasmus Lerdorf]

On Tue, Nov 7, 2017 at 5:44 PM, Pedro Magalhães  wrote:

> I'm not sure if the people who have access to the machines follow this
> mailing list as well, so I would suggest reaching out directly to the
> people listed as having access to the mailing lists machine (you can find
> that list here: https://wiki.php.net/systems/pb1).
>
> Also, there seems to be a systems@ mailing list as well (mentioned here:
> https://externals.io/message/97214) which may yield some actual response
> from the people involved.
>

Just saw this thread today. Yes, Pedro is right, infrastructure discussion
belongs on systems@ not internals.

So please send your volunteer requests there, but not just a generic offer
to help. Please include a concrete description of what you plan on doing.
As in which software or configuration changes. If it is just replace ezmlm
with Mailman, then you are going to have to make a really really strong
case for why you think a sideways migration like that will make any
difference. It is also important to understand the difference between the
list server and the mail server responsibilities.

-Rasmus

[PHP-DEV] Re: [PHP-CVS] com php-src: Add line numbers to Opcache's zend_dump_op() debug output: ext/opcache/Optimizer/zend_dump.c ext/opcache/tests/opt/dce_001.phpt ext/opcache/tests/opt/dce_002.phpt

[Rasmus Lerdorf]

On Fri, Oct 6, 2017 at 12:04 PM, Sara Golemon <poll...@php.net> wrote:

> On Fri, Oct 6, 2017 at 10:18 AM, Rasmus Lerdorf <ras...@lerdorf.com>
> wrote:
> > Sara/Remi do you mind if I merge this into 7.2? This affects opcache
> debug
> > output only and I want to start playing with some DCE reporting from
> Phan.
> > Having the original line numbers available will make that more effective.
> >
> > http://git.php.net/?p=php-src.git;a=commitdiff;h=
> 9fe6b29356923c23fadf610a9fa421cff8b06d6d
> >
> Literally two low-risk lines of actual change to a debug-only path?
> Zero objections from me.


Correct, the zend_dump_op() call I tweaked is only ever called if
opcache.debug_level is set. The bulk of the patch is to add the resulting
line numbers to the tests that use this debug info to verify the output
from the optimizer.

-Rasmus

[PHP-DEV] Re: [PHP-CVS] com php-src: Add line numbers to Opcache's zend_dump_op() debug output: ext/opcache/Optimizer/zend_dump.c ext/opcache/tests/opt/dce_001.phpt ext/opcache/tests/opt/dce_002.phpt

[Rasmus Lerdorf]

Sara/Remi do you mind if I merge this into 7.2? This affects opcache debug
output only and I want to start playing with some DCE reporting from Phan.
Having the original line numbers available will make that more effective.

On Fri, Oct 6, 2017 at 11:03 AM, Rasmus Lerdorf <ras...@php.net> wrote:

> Commit:9fe6b29356923c23fadf610a9fa421cff8b06d6d
> Author:Rasmus Lerdorf <ras...@php.net> Fri, 6 Oct 2017
> 11:03:07 -0300
> Parents:   45ee78e0403b973e7df4cbcd2ce0c485efa590ea
> Branches:  master
>
> Link:   http://git.php.net/?p=php-src.git;a=commitdiff;h=
> 9fe6b29356923c23fadf610a9fa421cff8b06d6d
>
> Log:
> Add line numbers to Opcache's zend_dump_op() debug output
>
> Changed paths:
>   M  ext/opcache/Optimizer/zend_dump.c
>   M  ext/opcache/tests/opt/dce_001.phpt
>   M  ext/opcache/tests/opt/dce_002.phpt
>   M  ext/opcache/tests/opt/dce_003.phpt
>   M  ext/opcache/tests/opt/dce_004.phpt
>   M  ext/opcache/tests/opt/dce_005.phpt
>   M  ext/opcache/tests/opt/dce_006.phpt
>   M  ext/opcache/tests/opt/dce_007.phpt
>   M  ext/opcache/tests/opt/dce_008.phpt
>   M  ext/opcache/tests/opt/sccp_001.phpt
>   M  ext/opcache/tests/opt/sccp_002.phpt
>   M  ext/opcache/tests/opt/sccp_003.phpt
>   M  ext/opcache/tests/opt/sccp_004.phpt
>   M  ext/opcache/tests/opt/sccp_005.phpt
>   M  ext/opcache/tests/opt/sccp_006.phpt
>   M  ext/opcache/tests/opt/sccp_007.phpt
>   M  ext/opcache/tests/opt/sccp_008.phpt
>   M  ext/opcache/tests/opt/sccp_009.phpt
>   M  ext/opcache/tests/opt/sccp_010.phpt
>   M  ext/opcache/tests/opt/sccp_011.phpt
>   M  ext/opcache/tests/opt/sccp_012.phpt
>   M  ext/opcache/tests/opt/sccp_016.phpt
>   M  ext/opcache/tests/opt/sccp_017.phpt
>   M  ext/opcache/tests/opt/sccp_019.phpt
>   M  ext/opcache/tests/opt/sccp_022.phpt
>
>
> --
> PHP CVS Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Re: PHP 7.2.0 Beta 1 released

[Rasmus Lerdorf]

On Sat, Jul 22, 2017 at 8:21 AM, Jan Ehrhardt  wrote:

> I am sure I am running PHP 7, not sure it is E_STRICT in 7.0 & 7.1. Just
> misread
> your statement "Even in 5.6 and 5.5 it was an E_STRICT", I suppose.
>
> With the 80-character line-breaks:
>
> C:\phpdev\php72nts.x64>php ..\class.php
>
> C:\phpdev\php72nts.x64>tail -n1 \phpdev\php72nts.x64.log
> [22-Jul-2017 14:17:55 Europe/Paris] PHP Warning:  Declaration of
> C::form(&$form,
>  &$form_state, $options = Array) should be compatible with P::form(&$form,
> &$for
> m_state, $options = Array, $iterator = NULL) in C:\phpdev\class.php on
> line 7
>
> C:\phpdev\php72nts.x64>php -v
> PHP 7.2.0beta1 (cli) (built: Jul 21 2017 19:20:33) ( NTS MSVC15 (Visual
> C++ 2017
> ) x64 )
> Copyright (c) 1997-2017 The PHP Group
> Zend Engine v3.2.0-dev, Copyright (c) 1998-2017 Zend Technologies
> with Zend OPcache v7.2.0beta1, Copyright (c) 1999-2017, by Zend
> Technologies


Ok, so it is a normal E_WARNING and not the source of the fatal error you
hit. You must have something else going on. Perhaps a custom error handler
turning it into a fatal, although that also hasn't changed from 7.1.

-Rasmus

Re: [PHP-DEV] Re: PHP 7.2.0 Beta 1 released

[Rasmus Lerdorf]

On Sat, Jul 22, 2017 at 12:32 AM, Jan Ehrhardt  wrote:

> Your example issues an E_STRICT warning, in both PHP 7.2 nts x64 and PHP
> 7.1 nts x64, so it must be caused by something else.


Are you sure you are even running PHP 7? This type of code hasn't issued an
E_STRICT since PHP 5.
See:


https://github.com/php/php-src/blob/PHP-7.2/Zend/zend_inheritance.c#L619-L623

-Rasmus

Re: [PHP-DEV] Re: PHP 7.2.0 Beta 1 released

[Rasmus Lerdorf]

On Fri, Jul 21, 2017 at 9:50 PM, Jan Ehrhardt  wrote:
>
> I tried running Drupal7 with 7.2.0 Beta 1 and ran into a fatal error,
> that does not happen under PHP 7.1.x (Windows, NTS, x64). I do not know
> if it is a bug, an omission in UPGRADING or me looking with my nose.
> Therefore I did not file a bugreport yet.
>
> The case: class RulesActionContainerUI has a public function form:
> > public function form(&$form, &$form_state, $options = array(), $iterator
> = NULL) {
>
> class RulesRuleUI extends RulesActionContainerUI with a public function
> > public function form(&$form, &$form_state, $options = array()) {
>
> Bad programming, but no PHP ever stumbled over it. PHP 7.2.0 Beta 1
> issues a fatal error that RulesRuleUI::form must be compatible with
> RulesActionContainerUI::form. IMHO a valid remark, but still a BC break.
> Is this documented anywhere? Or should the Fatal Error become less
> fatal?
>

This sounds strange. This hasn't changed in 7.2. It was the same in 7.1 and
7.0. Even in 5.6 and 5.5 it was an E_STRICT. Unless the Windows version has
somehow drifted, but I don't see how that would be possible. Are you sure
it isn't caused by something else?

eg.

 10:10pm thinkpad:~/php-src> cat -n g
 1  php g

Warning: Declaration of C::form(&$form, &$form_state, $options = Array)
should be compatible with P::form(&$form, &$form_state, $options = Array,
$iterator = NULL) in /home/rasmus/php-src/g on line 8
10:10pm thinkpad:~/php-src> php -v
PHP 7.2.0-dev (cli) (built: Jul 21 2017 22:08:10) ( NTS )

10:10pm thinkpad:~/php-src> sudo newphp 71
Activating PHP 7.1.3-dev (cli) (built: Feb 11 2017 09:40:56) ( NTS ) and
restarting php-fpm
10:10pm thinkpad:~/php-src> php g

Warning: Declaration of C::form(&$form, &$form_state, $options = Array)
should be compatible with P::form(&$form, &$form_state, $options = Array,
$iterator = NULL) in /home/rasmus/php-src/g on line 8

10:10pm thinkpad:~/php-src> php -v
PHP 7.1.3-dev (cli) (built: Feb 11 2017 09:40:56) ( NTS )

-Rasmus

Re: [PHP-DEV] php.net website

[Rasmus Lerdorf]

On Thu, Jul 20, 2017 at 3:25 PM, Larry Garfield 
wrote:
>
> I figure this is a long-shot, but Platform.sh hosts a number of
> community sites for free.  (We recently became the home of
> https://externals.io/, for example.)  We have multiple data centers and
> SSL-all-the-things using Lets Encrypt.  We'd be happy to help on the
> hosting side of the equation for any *.php.net sites if there's
> interest, either full or partial.  We also offer PHP 7.1 and will have
> the just-released 7.2 beta up shortly. :-)
>

I like the current mirror system which spreads out the duties to many
different providers in more (around 60) countries than even someone as big
as AWS can have data centers in. It is just the geodns part on www.php.net
that makes https tricky. Nothing else about the current mirror system
prevents https.

-Rasmus

Re: [PHP-DEV] php.net website

[Rasmus Lerdorf]

On Thu, Jul 20, 2017 at 1:42 AM, Niklas Keller  wrote:
>
> They can also just request them themselves, but only for their mirror
> domain. If you allow them to issue for www.php.net, you can as well just
> put the current private key there.
>

I think there is a big difference between putting the private key there and
proxying validation for just a www.php.net CN alias. We already have a list
of known mirrors, so we would make sure to only validate www.php.net for
those. By validating www.php.net we allow any mirror to pretend they are
www.php.net and no other *.php.net domain, which is exactly what we want.

-Rasmus

Re: [PHP-DEV] php.net website

[Rasmus Lerdorf]

On Wed, Jul 19, 2017 at 11:59 PM, Stephen Reay 
wrote:
>
> Does it need to be geo-dns, or could it instead be "geo-http" - a small
> number of servers responding to (www.)?php.net, which then respond with
> http redirects based on client ip. This is similar to how Debians "new"
> mirror service works for apt repos.
>
>
> I know it would be very nice to have the URLs stay as php.net (no CCn.
> Prefix) but anything else simple is going to involve tls certs for the base
> domain on servers the project doesn't control.
>
> The only other option I can see, would be to use "keyless" tls. It's
> described pretty well by CF here: https://www.cloudflare.
> com/ssl/keyless-ssl/
>
> Unfortunately I don't know that cf have open sourced their nginx
> patches to make them talk to a remote key server.
>

I did look at the stuff from Cloudflare last year, but at the time they
hadn't opened enough of it to implement.

And it is really nice to have www.php.net be fast and low-latency from all
over the world. Even the initial request. We are quite spoiled in Europe
and North America with our fast peering. But in many other parts of the
world, even if the local connection is fast, getting to a server in
N.America is quite slow. but yes, eventually we may have to give up on
geo-dns if we can't find a decent way to layer https on top of it.

-Rasmus

Re: [PHP-DEV] php.net website

[Rasmus Lerdorf]

On Wed, Jul 19, 2017 at 1:50 PM, Sara Golemon  wrote:
>
> * Use docker hub as the distribution channel. (https out of the box)
>

Getting https support in the web server is not what prevents us from
getting https for www.php.net. It is key management across our geodns
www.php.net that is the limiting factor here. A Docker image doesn't do
anything to help with that.

-Rasmus

Re: [PHP-DEV] php.net website

[Rasmus Lerdorf]

On Wed, Jul 19, 2017 at 1:42 PM, Niklas Keller  wrote:

>
> We should really change that and fully move to HTTPS.
>

I have looked at various ways of doing this, but it isn't trivial and it
has absolutely nothing to do with the actual html and slapping in some
https links instead of http. The problem here is that we have external
volunteers running all our mirrors and we do geo-dns for www.php.net to
your geographically close mirror site. Putting the private key for
www.php.net on dozens of servers around the world we don't control is a
non-starter.

One way that I played with was to use letsencrypt and have each mirror
request an ssl cert for their local mirror, ca1.php.net, for example, and
include a CN alias for www.php.net in that request. Then we would run
domain a validation gateway/proxy on www.php.net which would validate these
requests on behalf of the mirrors. But there are some security issues with
this approach that I haven't quite thought through. I would love to hear
suggestions for perhaps a simpler solution to this problem that doesn't
require pasting our private key all over the internet.

-Rasmus

Re: [PHP-DEV] [RFC] [Vote] Doxygen

[Rasmus Lerdorf]

No from me as well. This is wagging the dog by the tail. Picking a
documentation format is the very least of the concerns here. It would be
wonderful to have better internal API documentation, but putting up any
sort of structural restriction like limiting it to a specific header-based
format, isn't going to make such documentation more likely. I couldn't care
less which format such documentation is in. If the folks who are capable of
writing decent API docs want to do it in Microsoft Word, LaTeX or some
weird SGML format, great! Whatever format it might appear in we can use and
convert to whatever makes sense at that point.

-Rasmus

On Mon, Jun 26, 2017 at 5:26 AM, Kalle Sommer Nielsen  wrote:

> HI Joe,
>
> 2017-06-26 8:43 GMT+02:00 Joe Watkins :
> > Morning,
> >
> > I also voted no for similar reasons to Anatol.
> >
> > This is not really a thing that needs a vote, this is a thing that
> requires
> > the handful of people who are actually able to document ZE to spend
> > considerable time doing so. In addition it requires a commitment from the
> > community of developers to continue to maintain, and introduce inline
> > documentation with new code.
> >
> > Additionally, I'm a little concerned that an RFC that has the potential
> to
> > touch every single source file has gone to vote with a simple majority.
> It
> > would seem that we are deciding that new code must be documented in this
> > specific way, to say nothing of the massive task of documenting existing
> > code. That would seem to be a decision that could effect everybody that
> > works on PHP in perpetuity and a simple majority is nothing like a strong
> > enough consensus.
>
> I'm in the same boat as you and Anatol here.
>
> I think it is important to note that all who actively work on the
> Core/Engine have no except for Stas, which also should be a good
> indicator that we should be concerned.
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Re: [PHP-CVS] com php-src: Exclude warm-up requests from callgrind profile.: acinclude.m4 configure.ac sapi/cgi/cgi_main.c

[Rasmus Lerdorf]

This looks interesting. So you build against Valgrind and run php-cgi -T
5,1000 or something like that? What is your normal command line to do one
of these callgrind runs?

Re: [PHP-DEV] Implement formal process for run-tests.php refactor

[Rasmus Lerdorf]

On Thu, May 25, 2017 at 3:52 PM, Nikita Popov  wrote:
>
>
> During normal development I usually only run either Zend/ tests, or the
> tests in the extension I'm modifying (the rest is what CI is for).
> Parallelizing by directory will speed up our CI builds (which is important,
> we're often suffering from timeouts), but probably not help much during
> development.
>

The best way to address that is probably to split some of those 1600
general Zend/tests into sub-directories to get better concurrency when
running all the Zend tests. I think we are in for a world of hurt if we try
to run adjacent tests in parallel. Anything that hits any sort of
datastore, even if it is just the filesystem, will break badly.

-Rasmus

Re: [PHP-DEV] Implement formal process for run-tests.php refactor

[Rasmus Lerdorf]

On Thu, May 25, 2017 at 3:09 AM, Andrea Faulds  wrote:
>
> It occurred to me a little while ago that if we ran the test suite in
> parallel, but only run one test from a given directory (or extension) at a
> time, it should probably avoid any such problems, and it would not be
> particularly difficult to implement.
>
> Is that worth a shot, do you think?


Yes, definitely. Some of the tests also have side-effects and don't work if
not run in the original order. They shouldn't have such side-effects, of
course, but auditing nearly 15k tests for this is not a fun task. Within
each directory there should only be one execution thread and the tests
should be run in their original order. That still leaves plenty of room for
concurrency, of course. We have 152 separate directories containing .phpt
files. And if we are smart about it, we sort the directories based on the
number of tests in each and start off with the larger ones to make sure we
don't end with a single process still working on a huge directory. The 152
directories sorted by the number of tests are:

[./Zend/tests] => 1613
[./ext/standard/tests/strings] => 924
[./ext/standard/tests/array] => 923
[./ext/standard/tests/file] => 800
[./ext/spl/tests] => 697
[./ext/date/tests] => 632
[./ext/intl/tests] => 474
[./ext/mysqli/tests] => 396
[./ext/oci8/tests] => 360
[./ext/reflection/tests] => 334
[./ext/gd/tests] => 329
[./ext/mbstring/tests] => 317
[./ext/phar/tests] => 300
[./tests/classes] => 277
[./ext/standard/tests/general_functions] => 272
[./ext/session/tests] => 228
[./ext/standard/tests/math] => 219
[./ext/dom/tests] => 219
[./tests/lang] => 216
[./ext/zlib/tests] => 170
[./ext/pcre/tests] => 118
[./ext/pdo_mysql/tests] => 116
[./ext/simplexml/tests] => 112
[./ext/openssl/tests] => 112
[./ext/ldap/tests] => 107
[./Zend/tests/traits] => 107
[./ext/curl/tests] => 107
[./ext/phar/tests/tar] => 102
[./ext/posix/tests] => 100
[./ext/standard/tests/serialize] => 99
[./ext/standard/tests/streams] => 96
[./ext/filter/tests] => 94
[./ext/phar/tests/zip] => 91
[./Zend/tests/generators] => 86
[./ext/soap/tests/schema] => 85
[./ext/soap/tests/bugs] => 85
[./ext/xml/tests] => 85
[./ext/sockets/tests] => 85
[./ext/sqlite3/tests] => 82
[./tests/basic] => 80
[./ext/iconv/tests] => 77
[./ext/imap/tests] => 77
[./ext/soap/tests/soap12] => 73
[./sapi/cli/tests] => 73
[./ext/soap/tests/interop/Round2/Base] => 72
[./ext/ctype/tests] => 70
[./ext/pgsql/tests] => 70
[./ext/pdo/tests] => 69
[./ext/standard/tests/class_object] => 68
[./tests/output] => 66
[./ext/soap/tests] => 65
[./ext/mcrypt/tests] => 64
[./ext/dba/tests] => 64
[./ext/gmp/tests] => 63
[./tests/lang/operators] => 62
[./ext/json/tests] => 62
[./ext/standard/tests/dir] => 61
[./ext/xsl/tests] => 61
[./ext/zip/tests] => 60
[./ext/phar/tests/cache_list] => 60
[./ext/soap/tests/interop/Round4/GroupH] => 58
[./ext/standard/tests/network] => 58
[./Zend/tests/type_declarations] => 56
[./ext/opcache/tests] => 56
[./Zend/tests/return_types] => 54
[./ext/hash/tests] => 49
[./ext/exif/tests] => 49
[./tests/security] => 48
[./ext/standard/tests/url] => 45
[./Zend/tests/try] => 43
[./ext/tidy/tests] => 39
[./ext/xmlwriter/tests] => 38
[./ext/fileinfo/tests] => 36
[./sapi/phpdbg/tests] => 36
[./ext/soap/tests/interop/Round4/GroupI] => 35
[./ext/wddx/tests] => 34
[./ext/pdo_pgsql/tests] => 34
[./ext/snmp/tests] => 33
[./ext/bcmath/tests] => 33
[./ext/xmlrpc/tests] => 32
[./ext/ftp/tests] => 32
[./ext/tokenizer/tests] => 32
[./ext/calendar/tests] => 32
[./ext/standard/tests/image] => 31
[./ext/pdo_sqlite/tests] => 28
[./ext/standard/tests/mail] => 27
[./ext/pdo_oci/tests] => 27
[./ext/enchant/tests] => 25
[./ext/gettext/tests] => 23
[./Zend/tests/grammar] => 23
[./ext/xmlreader/tests] => 22
[./Zend/tests/assert] => 22
[./sapi/fpm/tests] => 22
[./ext/interbase/tests] => 22
[./ext/soap/tests/interop/Round3/GroupD] => 21
[./ext/standard/tests/assert] => 20
[./ext/standard/tests/misc] => 20
[./ext/standard/tests/filters] => 18
[./ext/libxml/tests] => 18
[./ext/pcntl/tests] => 18
[./ext/readline/tests] => 16
[./Zend/tests/variadic] => 16
[./Zend/tests/use_function] => 16
[./ext/soap/tests/interop/Round2/GroupB] => 15
[./Zend/tests/varSyntax] => 15
[./ext/pdo_dblib/tests] => 14
[./ext/standard/tests/http] => 14
[./Zend/tests/traits/bugs] => 14
[./sapi/cgi/tests] => 14
[./tests/func] => 14
[./tests/run-test] => 14
[./ext/pdo_firebird/tests] => 14
[./ext/odbc/tests] => 14
[./ext/com_dotnet/tests] => 14
[./Zend/tests/arg_unpack] => 13
[./Zend/tests/anon] => 12

Re: [PHP-DEV] Snapping php

[Rasmus Lerdorf]

Also note that we don't do binary release outside of Windows. We leave it
up to the various distributions. If this Snap thing, which I have also
never heard of, has the equivalent of an rpm .spec file that you wish to
contribute and keep up to date we can add that, but anything beyond that is
out of scope for us (including helping you get the word out about Snap).
You are welcome to pull the latest branches and automatically build snaps
of whatever versions of PHP you like, of course. It doesn't sound like you
need our help for that.

-Rasmus

On Wed, May 10, 2017 at 8:42 AM, Johannes Schlüter 
wrote:

> Hey,
>
> On Mi, 2017-05-10 at 15:05 +0100, Alan Pope wrote:
> > A notable example would be NextCloud, in which the snap
> > contains Apache, MySql, PHP and NextCloud itself.
>
> To my understanding this is the right place for this - snap is for an
> "application" but aside from some developers PHP isn't the application
> people are looking for. They are maybe looking for "a webserver with
> PHP enabled" or NextCloud/Wordpress/moodle/whatever. It's a bit like
> snapping up stdlibc ;-)
>
>
> If somebody wants to add a snapfile or whatever might be needed we
> could certainly add it  Maybe it would see more maintenance than our
> rpm spec file, which apparently hasn't seen a real change since 1999 :-
> )
>
>
>
> johhannes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Re: Sorry folks, my last git push went a bit crazy

[Rasmus Lerdorf]

Ah, I see what I did now. I only messed up the old dstogov-foreach
experimental branch. We can probably kill that branch entirely.

On Fri, Apr 14, 2017 at 3:56 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:

> Oops, a misconfigured git setup ended up pushing to all branches on me. If
> someone could lend a hand cleaning this up I would appreciate it.
>
> -Rasmus
>

[PHP-DEV] Sorry folks, my last git push went a bit crazy

[Rasmus Lerdorf]

Oops, a misconfigured git setup ended up pushing to all branches on me. If
someone could lend a hand cleaning this up I would appreciate it.

-Rasmus

Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

[Rasmus Lerdorf]

On Wed, Feb 1, 2017 at 3:06 PM, Rowan Collins <rowan.coll...@gmail.com>
wrote:

> On 01/02/2017 20:17, Rasmus Lerdorf wrote:
>
>> You probably think of $var as being a local scope variable here,
>> but really it isn't. It is an imported variable that happened to not exist
>> in the outer scope and it was assigned a value in the inner scope, but
>> that
>> assignment can't leak back out so it is still unassigned in the outer
>> scope.
>>
>
> I'm very confused by your terminology here. You definitely talk about two
> distinct scopes, "the inner scope" and "the outer scope", but then you
> assert that there is no "local scope". Surely the "inner scope" is "local"
> to the closure?
>
> In actual fact, it's local to *each invocation* of the closure, because
> the function is initialised with the original values each time. For
> instance:
>
> $a = 1;
> $fn = fn() => ++$a;
> $a = 42;
> echo $fn(), ' ', $fn, ' ', $fn();
>
> This echoes 2 2 2, not 2 3 4, because the $a being incremented is new for
> each invocation. Nor does it echo 43 43 43, because it is only the value of
> $a that is captured, not its reference.
>
> I think the best description is this: the closure has its own scope, which
> is initialised on each invocation with a copy of another scope taken when
> it was defined.
>
>
> To go back to Bruce's question, the original statement was:
>
> you don't typically need a local scope at all for these short closures
>>
>
> The important point here is that within a single expression there is very
> little you can meaningfully do with a local scope other than read from it.
> It's generally a bad idea to alter the value of a variable and expect
> another part of the same expression to see the new value, because you can't
> always predict how the compiler will rewrite the expression (I think an
> example of this came up on the list a while back, but can't think how to
> search for it).
>
> So for most purposes you can consider all the automatically imported
> variables to be immutable values, which makes their scope much less
> relevant.


It is mostly a semantic thing. Of course you have a local scope, but
because of automatic import you don't have a clean local scope so it is not
like the function-local scope people are used to. Like you said, it is a
mostly immutable copy of the outer scope.

But people need to understand that the immutability doesn't apply to class
variables because there is no automatic clone done on outer scope objects.

class C {
static $var = 1;
}
$f = fn() => C::$var++;
echo $f().$f().$f();

will output 123 and the value of C::$var would be 4 after this.

-Rasmus

Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

[Rasmus Lerdorf]

On Wed, Feb 1, 2017 at 8:05 AM, Bruce Weirdan <weir...@gmail.com> wrote:

> On Wed, Feb 01, 2017 at 07:45:50AM -0800, Rasmus Lerdorf wrote:
> > The reason it is feasible to do this for single-expression closures in
> this
> > short form syntax is that you don't typically need a local scope at all
> for
> > these short closures and the syntax doesn't convey the idea that you
> would
> > have a local scope.
>
> Does this mean, in the context of this RFC, that short-form lambdas
> won't have their own scope though? I think it's not clear from RFC.
>
> Example:
> // would this create $ret in the outer scope assuming $ret was not
> // defined
> array_map(fn($elt) => $ret[] = $elt, [1]);
> var_dump($ret); // NULL or array(1) ?
>
> Current implementation (available on 3v4l.org) does create a local
> scope, but it should probably be explicitly stated in the RFC (and
> docs, should the RFC get accepted).
>

I actually tend to think of these short-form lambdas as not having a local
scope. That might sound a bit odd, but let me demonstrate:

$f = fn() => print($var=1);
$f();
echo $var;

This should output 1 and then give a notice about $var being undefined on
the echo. You probably think of $var as being a local scope variable here,
but really it isn't. It is an imported variable that happened to not exist
in the outer scope and it was assigned a value in the inner scope, but that
assignment can't leak back out so it is still unassigned in the outer
scope. I think of it this way, because if you do:

$var = 3;
$f = fn() => print(++$var);
$f();
echo $var;

You should see: 43

$var did not originate in the inner scope, it was imported from the outer
scope by-value and reassigned. To me, automatic import precludes the notion
of a local scope entirely. When a variable you use within the lambda isn't
defined in the outer scope it acts exactly like a locally scoped variable,
but it isn't, because defining it in the outer scope could potentially
affect it depending on how it is used within the lambda.

-Rasmus

Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

[Rasmus Lerdorf]

On Tue, Jan 31, 2017 at 12:41 PM, Andrea Faulds  wrote:
>
> That's the idea. I'd prefer it if auto-capture was not restricted to
> single-expression functions (“arrow functions”). Though arrow functions
> make most sense with auto-capture, it doesn't need to be stricted to them.


This goes against a very basic characteristic of PHP. The fact that you
have to be explicit about globals and outer scope variables leaves you with
a clean sandbox with no side effects inside your function. Changing that,
especially after the fact for existing closures, is a complete non-starter
and would subtly break a ton of code.

The reason it is feasible to do this for single-expression closures in this
short form syntax is that you don't typically need a local scope at all for
these short closures and the syntax doesn't convey the idea that you would
have a local scope.

-Rasmus

Re: [PHP-DEV] Re: PHP 7.0 and openssl 1.1

[Rasmus Lerdorf]

On Mon, Jan 23, 2017 at 12:52 PM, Alice Wonder  wrote:

> Actually I found that wasn't the case. To build php against an alternat
> openssl API - I did have to rebuild net-snmp but curl, for example, at
> least on CentOS uses NSS for it's TLS and so didn't need to be rebuild to
> build PHP against a different OpenSSL API.
>
> Building in mock, the only php dependency that had an OpenSSL API
> dependency was net-snmp. And if I kept the same API for net-snmp, I didn't
> have to replace the system net-snmp for php to work properly - only the
> net-snmp used in mock.
>
>
Well, you got lucky with your libcurl then. On Debian the default is
openssl. You can optionally choose either gnutls or nss instead if you
like. I am pretty sure Centos also has a libcurl-openssl variant that
people might be using:

libcurl3 - easy-to-use client-side URL transfer library (OpenSSL flavour)
libcurl3-gnutls - easy-to-use client-side URL transfer library (GnuTLS
flavour)
libcurl3-nss - easy-to-use client-side URL transfer library (NSS flavour)

libcurl having those alternatives is probably the easiest dependency. libpq
(PostgreSQL) and libc-client do not, as far as I know.

-Rasmus

Re: [PHP-DEV] Re: PHP 7.0 and openssl 1.1

[Rasmus Lerdorf]

On Mon, Jan 23, 2017 at 12:31 AM, Alice Wonder  wrote:

> If someone on such a distro really can't use PHP 7.1.x, LibreSSL can be
> installed in parallel to OpenSSL (I do on CentOS) and I suspect php 7.0
> will build against it (5.6.x does and 7.1.x does)
>
> Also, I suspect older OpenSSL shared libraries could probably be installed
> in parallel.
>
> So it can be done if really needed.


Yes, of course it can be done with a bit (or a lot depending on the distro)
fiddling.
And it is also rather tricky to build against libressl or a different
version of openssl
because we have things like libcurl, libpq, libc-client and probably a few
others as
well that are linked against the system openssl library. You will need to
built alternative
versions of those too.
And for libressl, even if you get it built, you are going to see quite a
few test failures.
This is the current state of make test TESTS=ext/openssl when PHP-7.0 is
built against
the latest version of libressl:

Number of tests :  10598
Tests skipped   :7 (  6.7%) 
Tests warned:0 (  0.0%) (  0.0%)
Tests failed:   32 ( 30.5%) ( 32.7%)
Expected fail   :0 (  0.0%) (  0.0%)
Tests passed:   66 ( 62.9%) ( 67.3%)
-
Time taken  :  446 seconds
=

=
FAILED TEST SUMMARY
-
#46127, openssl_sign/verify: accept different algos
[ext/openssl/tests/bug46127.phpt]
Bug #48182: ssl handshake fails during asynchronous socket connection
[ext/openssl/tests/bug48182.phpt]
Bug #54992: Stream not closed and error not returned when SSL CN_match
fails [ext/openssl/tests/bug54992.phpt]
Bug #65538: SSL context "cafile" supports stream wrappers
[ext/openssl/tests/bug65538_001.phpt]
Bug #65538: SSL context "cafile" disallows URL stream wrappers
[ext/openssl/tests/bug65538_002.phpt]
Bug #65538: SSL context "cafile" supports phar wrapper
[ext/openssl/tests/bug65538_003.phpt]
Bug #65729: CN_match gives false positive when wildcard is used
[ext/openssl/tests/bug65729.phpt]
Bug #68265: SAN match fails with trailing DNS dot
[ext/openssl/tests/bug68265.phpt]
Bug #68879: Match IP address fields in subjectAltName checks
[ext/openssl/tests/bug68879.phpt]
Bug #68920: peer_fingerprint input checks should be strict
[ext/openssl/tests/bug68920.phpt]
Bug #69215: Crypto servers should send client CA list
[ext/openssl/tests/bug69215.phpt]
Bug #72165 Null pointer dereference - openssl_csr_new
[ext/openssl/tests/bug72165.phpt]
Bug #73072: Invalid path SNI_server_certs causes segfault
[ext/openssl/tests/bug73072.phpt]
capture_peer_cert context captures on verify failure
[ext/openssl/tests/capture_peer_cert_001.phpt]
openssl_error_string() tests
[ext/openssl/tests/openssl_error_string_basic.phpt]
Testing peer fingerprint on connection
[ext/openssl/tests/openssl_peer_fingerprint_basic.phpt]
Peer verification enabled for client streams
[ext/openssl/tests/peer_verification.phpt]
Peer verification matches SAN names
[ext/openssl/tests/san_peer_matching.phpt]
Capture SSL session meta array in stream context
[ext/openssl/tests/session_meta_capture.phpt]
sni_server [ext/openssl/tests/sni_server.phpt]
Basic bitwise stream crypto context flag assignment
[ext/openssl/tests/stream_crypto_flags_001.phpt]
TLSv1.1 and TLSv1.2 bitwise stream crypto flag assignment
[ext/openssl/tests/stream_crypto_flags_002.phpt]
Server bitwise stream crypto flag assignment
[ext/openssl/tests/stream_crypto_flags_003.phpt]
Specific protocol method specification
[ext/openssl/tests/stream_crypto_flags_004.phpt]
TLS server rate-limits client-initiated renegotiation
[ext/openssl/tests/stream_server_reneg_limit.phpt]
Verify host name by default in client transfers
[ext/openssl/tests/stream_verify_peer_name_001.phpt]
Allow host name mismatch when "verify_host" disabled
[ext/openssl/tests/stream_verify_peer_name_002.phpt]
Host name mismatch triggers error
[ext/openssl/tests/stream_verify_peer_name_003.phpt]
Specific crypto method for ssl:// transports.
[ext/openssl/tests/streams_crypto_method.phpt]
tlsv1.0 stream wrapper [ext/openssl/tests/tlsv1.0_wrapper.phpt]
tlsv1.1 stream wrapper [ext/openssl/tests/tlsv1.1_wrapper.phpt]
tlsv1.2 stream wrapper [ext/openssl/tests/tlsv1.2_wrapper.phpt]
=

-Rasmus

[PHP-DEV] Re: PHP 7.0 and openssl 1.1

[Rasmus Lerdorf]

Ok, I thought perhaps the changes for just openssl-1.1 api compatibility
would be easier to separate out, but I guess not. I did have a look at it
and you are right, while some of the changes are trivial, others are more
involved. Fedora 26, and I would guess any Linux distro release that comes
out this year, will ship with openssl-1.1 so they will not be able to run
any version of PHP prior to 7.1.

-Rasmus

On Sun, Jan 22, 2017 at 11:33 AM, Jakub Zelenka <bu...@php.net> wrote:

> Hi Rasmus,
>
> On Sun, Jan 22, 2017 at 1:28 AM, Rasmus Lerdorf <ras...@lerdorf.com>
> wrote:
>
>> Jakub, what do you think about back-porting the openssl-1.1 supporting
>> changes to the PHP-7.0 branch? I think it is too early to have PHP-7.0 not
>> compile on new Linux versions and right now it doesn't compile on any Linux
>> that has openssl-1.1.
>>
>>
> The thing is that the patch required quite a lot of changes and it was
> based on the AEAD and OpenSSL error storing changes so the it changed quite
> a lot of code. So all changes together makes some difference between 7.0
> and 7.1:
>
> [jakub@localhost 71]$ git diff --stat PHP-7.0 ext/openssl/*.[c,h]
>  ext/openssl/openssl.c | 1991 ...
>  ext/openssl/php_openssl.h |   25 ...
>  ext/openssl/xp_ssl.c  |  199 ...
>  3 files changed, 1613 insertions(+), 602 deletions(-)
>
> This shows just openssl ext source files but there are some other changes
> for phar and some tweaks in tests.
>
> For that reason I decided that it will be better to target just 7.1 to
> have full QA cycle which was a good decision because I needed to fix few
> things in beta and rc.
>
> It means that the back-port would require some work to extract just the
> porting bits and all test it. It might be slightly trickier as 7.0 still
> support 0.9.8 which might complicate things a bit. Also there is still one
> failing SNI tests that needs some looking and couple of things needs a look
> as well so the port is still not 100% complete. In general I'm not so sure
> if it's really worth it to invest too much time into back-porting it as I'm
> not sure how many users would really appreciate it (meaning how many users
> are not able to update to PHP 7.1 and need to use OpenSSL 1.1.). It might
> be also quite a big patch for the point release but if RM is ok with that
> and someone wants to spend that time on porting it, I can do the review.
> Personally I have got some other stuff on my list (including finishing the
> port in 7.1 and some other OpenSSL fixes) so won't probably have time for
> anything else than review.
>
> Cheers
>
> Jakub
>

Re: [PHP-DEV] pdo_sqlite fd leak

[Rasmus Lerdorf]

On Sat, Jan 21, 2017 at 5:22 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:

> On Sat, Jan 21, 2017 at 4:47 PM, Christoph M. Becker <cmbecke...@gmx.de>
> wrote:
>>
>> Anyhow, the SQLite3 documentation states[1]:
>>
>> | The sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces are
>> | recommended for all new programs. The two older interfaces are
>> | retained for backwards compatibility, but their use is discouraged.
>>
>> Isn't that reason enough to switch to sqlite3_prepare_v2() ASAP?  Note
>> that this is documented at least for more than nine years[2]!
>>
>> [1] <https://sqlite.org/c3ref/prepare.html>
>> [2]
>> <http://web.archive.org/web/2007070100*/https://sqlite.
>> org/c3ref/prepare.html>
>
>
> Yes, but it also says that the behaviour is slightly different on an error
> condition which could potentially affect peoples' code. Although it seems
> like a subtle difference and only in the case of an error, so it should be
> ok to change for 7.2.
>

Ok, I have switched pdo_sqlite to use sqlite3_prepare_v2() and
sqlite3_close_v2() for PHP 7.2

[PHP-DEV] PHP 7.0 and openssl 1.1

[Rasmus Lerdorf]

Jakub, what do you think about back-porting the openssl-1.1 supporting
changes to the PHP-7.0 branch? I think it is too early to have PHP-7.0 not
compile on new Linux versions and right now it doesn't compile on any Linux
that has openssl-1.1.

-Rasmus

Re: [PHP-DEV] pdo_sqlite fd leak

[Rasmus Lerdorf]

On Sat, Jan 21, 2017 at 4:47 PM, Christoph M. Becker 
wrote:
>
> Anyhow, the SQLite3 documentation states[1]:
>
> | The sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces are
> | recommended for all new programs. The two older interfaces are
> | retained for backwards compatibility, but their use is discouraged.
>
> Isn't that reason enough to switch to sqlite3_prepare_v2() ASAP?  Note
> that this is documented at least for more than nine years[2]!
>
> [1] 
> [2]
>  sqlite.org/c3ref/prepare.html>


Yes, but it also says that the behaviour is slightly different on an error
condition which could potentially affect peoples' code. Although it seems
like a subtle difference and only in the case of an error, so it should be
ok to change for 7.2.

-Rasmus

Re: [PHP-DEV] pdo_sqlite fd leak

[Rasmus Lerdorf]

On Fri, Jan 20, 2017 at 1:08 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:

>
> On Fri, Jan 20, 2017 at 12:58 Nikita Popov <nikita@gmail.com> wrote:
>
>>
>> That sounds like it could be the source of the issue.
>>
> Ah, that makes more sense than it never hitting that close call because I
> couldn't find any scenario where we wouldn't get there eventually. So it
> sounds like we should be calling sqlite3_close_v2() there instead.
>

Of course, something must be causing the unfinalized prepared statement in
the first place so moving to the v2 close likely wouldn't fix it, just move
it from an unclosed db handle to an unclosed "unusable zombie" handle,
whatever that means. I also noticed that ext/sqlite3 uses
sqlite3_prepare_v2() while pdo_sqlite uses sqlite3_prepare(). The
differences in those two don't seem like they would affect whether the
prepare is finalized or not though. There still must be some path where on
a timeout we don't call pdo_sqlite_stmt_dtor() which does the finalize on
the statement.

-Rasmus

Re: [PHP-DEV] pdo_sqlite fd leak

[Rasmus Lerdorf]

On Fri, Jan 20, 2017 at 12:58 Nikita Popov  wrote:

>
> From the docs for sqlite3_close():
>
> > If the database connection is associated with unfinalized prepared
>
> statements or unfinished sqlite3_backup objects then sqlite3_close()
>
> will leave the database connection open and return SQLITE_BUSY
> .
>
> If sqlite3_close_v2() is called with unfinalized prepared statements
>
> and/or unfinished sqlite3_backups, then the database connection becomes
>
> an unusable "zombie" which will automatically be deallocated when the
>
> last prepared statement is finalized or the last sqlite3_backup is
>
> finished. The sqlite3_close_v2() interface is intended for use with
>
> host languages that are garbage collected, and where the order in which
>
> destructors are called is arbitrary.
>
>
>
>
> That sounds like it could be the source of the issue.
>
Ah, that makes more sense that it never hitting that close call because I
couldn't find any scenario where we wouldn't get there eventually. So it
sounds like we should be calling sqlite3_close_v2() there instead.

-Rasmus

[PHP-DEV] pdo_sqlite fd leak

[Rasmus Lerdorf]

I have been chasing a really odd fd leak which I haven't been able to
reproduce manually. The code involved is about as simple as you can get:

class C {
public static function fn($arg) {
$pdo = new PDO('sqlite:/var/dbs/file.db');
$query = $pdo->prepare("SELECT * FROM tb WHERE id = ?");
$query->execute([$arg]);
$result = $query->fetch(PDO::FETCH_ASSOC);

if (!$result) {
throw new RuntimeException("not found" );
}

return [
"a" => $result['a'],
"b" => $result['b']
];
}
}

The symptoms are:

   - It always starts with a max_execution timeout in the *$pdo->prepare()*
   call
   - Many hours after this timeout the httpd process runs out of FDs and
   lsof shows the httpd process with ~1000 fds open on */var/dbs/file.db*

The file.db itself is only read from PHP and isn't being updated in the
background by anything. mtime is months ago, but this happens sporadically
on a single server out of dozens about once every couple of days. These
servers are getting hit hard so it takes hundreds of millions of requests
to trigger whatever condition is causing this.

It feels like it should be something related to timeouts and the
*sqlite_handle_closer()
*call:

https://github.com/php/php-src/blob/PHP-7.0/ext/pdo_sqlite/sqlite_driver.c#L155-L175

but I have been staring at this code and comparing it to the other pdo
drivers and I don't see what makes *pdo_sqlite* special here.
This is on PHP 7.0.10 but this code hasn't changed significantly in 7.1 and
master. Anyone see anything in PDO that could possibly prevent the
*sqlite3_close()* call from being executed, especially in edge conditions
around an execution timeout?

-Rasmus

Re: [PHP-DEV] php.net mailing setup owner?

[Rasmus Lerdorf]

Ecelerity is on osu1php and it is still taking traffic even though the mx
for php.net doesn't point to it. So something somewhere is hardcoded to use
it. But this discussion is better suited for the systems@ list.

Re: [PHP-DEV] php.net mailing setup owner?

[Rasmus Lerdorf]

On Thu, Dec 1, 2016 at 8:00 AM, Derick Rethans  wrote:
>
> I think it's time to retire Ecelerity. Nobody knows how it works. if
> It'd be postfix, I would likely have checked one of these ghost mail
> reports out...
>

I don't think anyone disagrees with that, but at the same time it is a lot
of work to switch and get a secure and efficient anti-spam mail server
working well these days.

-Rasmus

Re: [PHP-DEV] php.net mailing setup owner?

[Rasmus Lerdorf]

The problem here is that it is not a standard mail setup so finding online
resources is tricky. It is Ecelerity from MessageSystems. I have been
poking the config trying to find where this subject keyword thing is
defined, but so far no luck. In the short term I think we need someone who
knows Ecelerity to help with this specific problem, but if you would like
to read up on it and be the mail server guy, that would be awesome and
perhaps you could help transition to a more standard setup that we have a
chance of maintaining. Or if not that, at least write up some dumbed down
docs on how this beast works.

-Rasmus

On Thu, Dec 1, 2016 at 7:46 AM, Andreas Heigl  wrote:

> Hi All.
>
> Looks like there should be someone that looks after the email-stuff.
>
> I hate "should" and "someone" so I'm stepping up to volunteer to handle
> that. Either alone or together with someone else (which would be my
> preffered solution!)
>
> Up to know I have set up and managed some very low volume mail-servers
> mainly for sending or relaying to different mail-addresses but I'm
> willing to learn. So should one of the current (or past) maintainers be
> willing to help me with questions I'm sure I can handle that.
>
> So who's the right person/group to address and - in case it's wnated
> that I do that - provide me with insight (and credentials)?
>
> Cheers
>
> Andreas
>
> Am 01.12.16 um 15:40 schrieb Eli:
> > Stas ... I think this falls under the whole "no-one really knows who
> > handles the mailing stuff".
> >
> > I myself have an issue that 'randomly' my emails will be bounced for an
> > incorrect blacklist error.  And there doesn't seem to be anyone who can
> > get in there and fix stuff since Wez stopped managing the email
> > servers.  They are kinda 'running on their own without anyone knowing
> > how they are running'.
> >
> > Eli
> >
> >
> > On 11/27/16 5:44 PM, Stanislav Malyshev wrote:
> >> Hi!
> >>
> >> Is there somebody around who knows what happens with configuration of
> >> mailer in php.net domain? I get my mails sent to @php.net addresses
> >> bouncing for months now, I get this every time I try it:
> >>
> >> 550 5.7.1 Please change the topic, and retry
> >>
> >> Needless to say, it's useless to have @php.net mailing addresses if
> >> nobody can actually mail anything there. And so far all my emails about
> >> this remain unanswered. Do we have no maintenance on our mail server at
> >> all?
> >>
> >> We once has systems list at https://wiki.php.net/systems but that seems
> >> to be last updated a year ago and php-smtp2 is not even there.
> >
> > --
> > |   Eli White   |   http://eliw.com/   |   Twitter: EliW   |
> >
>
>
> --
>   ,,,
>  (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl   |
> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
> | http://andreas.heigl.org   http://hei.gl/wiFKy7 |
> +-+
> | http://hei.gl/root-ca   |
> +-+
>
>

Re: [PHP-DEV] number_format() = "-0.00"

[Rasmus Lerdorf]

On Thu, Nov 24, 2016 at 11:54 PM, Craig Duncan  wrote:

> I've submit a PR (https://github.com/php/php-src/pull/2220) to fix a bug (
> https://bugs.php.net/bug.php?id=73581).
>
> Kalle suggested I run the change by here to see if there are any concerns
> or feedback about merging this?
>

This doesn't seem like a bug to me. Our floating point is all IEEE 754 and
as per IEEE 754 -0.00 is the correct and expected result here.

-Rasmus

Re: [PHP-DEV] Security issue handling

[Rasmus Lerdorf]

>
> > c. Get some specific people to volunteer to review patches in security
> > repo regularly - how? Any takers?
> >
> OFC it'd be ideal to have some karma holders to participate. And another
> option, which is IMHO eligible - we could invite several reporters. There
> is already a couple of people, who regularly report security issues and
> keep them confident until they're publicly disclosed. IMHO it is a good
> base for trust.
>

Yes, in the end this is about getting Stas some help here. He has been
doing an incredible job for years now handling all these annoying
off-by-one and >2gb string bugs. I occasionally read through the patches,
but I haven't been doing it consistently and even though there are a few
other people on security@ who occasionally look through the patches, it
obviously isn't enough.

As a first step perhaps we just need to expand security@ a bit with the
specific call for volunteers to help review security patches?

-Rasmus

Re: [PHP-DEV] Performance drops after some time, PHP7-FPM + Docker

[Rasmus Lerdorf]

>
> The output of the perf diff is quite poor I think, here's the mainline :
> 35.90%  +44.94%  php-fpm [.] 0x00042412
> 10.72%   -6.05%  libc-2.19.so[.] 0x00079030
>  9.71%   -9.34%  newrelic.so [.] 0x00030980
>  3.81%   -3.47%  [kernel.kallsyms]   [k] ipt_do_table
>  2.56%   -2.02%  [kernel.kallsyms]   [k] nf_iterate
>  2.32%   -1.99%  opcache.so  [.] 0x8cec
>  1.44%   [kernel.kallsyms]   [k] update_cfs_shares
>  1.42%   [kernel.kallsyms]   [k] __bpf_prog_run
>  1.28%   [vdso]  [.] __vdso_gettimeofday
>
> How could I provide more info ?
>

Yes, not much to go on there. But newrelic.so stands out to me. Can you try
removing newrelic and see if it still happens?

If it does, your next step is to look at the timing of a request. I usually
do that with something like this:

sudo strace -Ff -ttt -T -p  2>&1 | tee strace_output_file

Do that on a fast process and on a slow process and let it run for a little
while to the point where you think you have captured similar requests in
both runs, then have a look at the timing between syscalls in both and see
if you can spot if it is an isolated delay in a certain part of the request
or if it is just an overall slowdown.

I would also run:

vmstat 1

both before and after. This gives you a picture of the overall health of
your server. The si/so columns, for example, will tell you if you are
swapping. If something has eaten a ton of memory and your system has
started swapping more than before then that could also explain this.

-Rasmus

Re: [PHP-DEV] Performance drops after some time, PHP7-FPM + Docker

[Rasmus Lerdorf]

On Fri, Oct 14, 2016 at 9:15 PM, Jérémie BORDIER 
wrote:
>
> I don't really know how to investigate further. If you have any
> pointers on how to help figuring out what's wrong, I'd love to try.
>

I would breakout the Linux perf command for something like this.

Run it like this:

perf record -p  -g

Let that run for some arbitrary amount of time. Start with 10 seconds, or
so. Then:

perf report -n

That should give you a nice report of what your php-fpm process did for
those 10 seconds. Now do the same thing when you see the problem and
compare the reports.

-Rasmus

Re: [PHP-DEV] Missing reflection info about strict types?

[Rasmus Lerdorf]

On Sep 5, 2016, at 13:13, Nicolas Grekas  wrote:
> 
> It's not specifically me but Symfony's ClassCollectionLoader::load()
> method, which generates a single file with common classes inlined for
> faster bootstrapping (the perf gain is objectively measurable).

I have a hard time believing concatenating files is measurably faster with PHP 
7 and a well-configured opcache.

-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Enable Zend Signals by Default

[Rasmus Lerdorf]

On Mon, Jun 20, 2016 at 1:25 PM, Dmitry Stogov  wrote:
So, I propose to switch zend-signals on, and revert back if it makes 
problems to 7.1 release process.

Any objections?


No objections here. I have been hitting annoying segfaults in 7.0 that 
will likely be helped by this.


-Rasmus

Re: [PHP-DEV] Huge Pages

[Rasmus Lerdorf]

On 03/20/2016 01:58 PM, Anatol Belski wrote:
> Dmitry has already merged this patch into the 7.0 branch. I also know from 
> Remi that Fedora doesn't play well with the huge pages. Huge pages require 
> special system settings which are usually not enabled in OSes by default. 
> Having it off by default in PHP would therefore not cause any functional 
> disadvantage while addressing the stability concerns. Thus reversing the 
> default setting sounds feasible, it could be already done for the upcoming 
> 7.0.5 if there are no objections.

Yes, and since the special system settings, namely setting
vm.nr_hugepages is a system-wide shared setting and not PHP-specific it
makes even more sense to not enable huge pages by default. If you happen
to install PHP on a system that has vm.nr_hugepages set to non-zero for
some other service on that machine, PHP is going blow up as soon as it
runs out of huge pages.

And the 2nd reason to disable huge pages by default is that, as you say,
on most systems vm.nr_hugepages is going to be 0 but MAP_HUGETLB will be
defined because every modern OS supports huge pages even if they are not
actually enabled. But the allocator doesn't know that. It will try to do
a MAP_HUGETLB mmap every single time here:

  https://github.com/php/php-src/blob/master/Zend/zend_alloc.c#L470

which is going to fail with an ENOMEM error and fall back to a
non-HUGETLB mmap. So every alloc there incurs an extra syscall in the
default case.

So we have 3 things to do:

1. Default it to off
2. Provide a way to specify the huge page size as per bug 71355
3. Document the use of USE_ZEND_ALLOC_HUGE_PAGES and how to set
   vm.nr_hugepages appropriately along with a warning about what
   might happen if don't allocate enough

1 and 3 are trivial. 2 is a little trickier if we want to try to detect
the page size. We could just not try and let the user specify it.
Perhaps even use ZEND_ALLOC_HUGE_PAGES directly. As in:

  ZEND_ALLOC_HUGE_PAGES=2048

would turn on huge pages in the allocator with 2k pages.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] unpack()

[Rasmus Lerdorf]

Trivial things like adding a completely non-controversial optional 
argument to a function really does not require an RFC. Let's not get 
hung up on process just for the sake of process here.


-Rasmus

Re: [PHP-DEV] PCRE jit bug with UTF-8 and lookbehind assertion

[Rasmus Lerdorf]

On 02/17/2016 05:06 AM, Christian Schneider wrote:
> Hi there,
> we just ran into a version of the bug "JIT bug with lookbehind assertion":
>   https://bugs.exim.org/show_bug.cgi?id=1189
> 
> To reproduce it you can use
>   php -n -r 'ini_set("pcre.jit", 0); echo 
> preg_replace("/\b(11|21|41)\b/u", "z", "x°11\n");'
> vs.
>   php -n -r 'ini_set("pcre.jit", 1); echo 
> preg_replace("/\b(11|21|41)\b/u", "z", "x°11\n");'
> 
> Since the PCRE bug report dates from 2011-12-27 and is still marked NEW I 
> wonder if it would be safer for PHP to disable pcre.jit in the recommended 
> php.ini configuration files.
> 
> Also: Does anyone know who might be able/willing to look at the upstream bug?
> 
> Regards,
> - Chris

Just replying here since many people probably missed this since gmail
classified it as spam.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Segmentation fault in PHP 7.0.3 (and earlier versions)

[Rasmus Lerdorf]

On 02/06/2016 10:10 AM, Simon Svensson wrote:
> On 05/02/16 22:29, Rasmus Lerdorf wrote:
>> On 02/05/2016 11:39 AM, Simon Svensson wrote:
>>> I am unable to reproduce the error with this recompiled source, both
>>> with the /usr/local/php70/bin/php and /usr/local/php70-debug/bin/php.
>>> This is the same experience I had with earlier releases, where I have
>>> been unable to reproduce the segmentation faults when recompiling (but
>>> always have them occur from the ppa).
>>>
>>> Is there any guide for compiling the source? I could attempt to setup a
>>> new virtual machine with Ubuntu 14.04 (instead of php7dev's Debian) to
>>> reproduce the error, but I do know know the steps needed to compile
>>> everything.
>>>
>>> The newly build, and working, versions:
>>>
>>> /usr/local/php70/bin/php --version:
>>> PHP 7.0.4-dev (cli) (built: Feb  5 2016 19:14:08) ( NTS )
>>> Copyright (c) 1997-2016 The PHP Group
>>> Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
>>> with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
>>> Technologies
>>>
>>> /usr/local/php70-debug/bin/php --version:
>>> PHP 7.0.4-dev (cli) (built: Feb  5 2016 19:19:10) ( NTS DEBUG )
>>> Copyright (c) 1997-2016 The PHP Group
>>> Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
>>> with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
>>> Technologies
>>
>> "php -i" will show you the configure flags that were used to build it,
>> so you could try to match those to see if you can reproduce with sources
>> from php.net. Otherwise, if it is something that only happens with the
>> distro build then there isn't a while lot we can do to help you.
>>
>> -Rasmus
>>
>>
> 
> An update to avoid leaving the thread hanging in suspense.
> 
> I was in contact with Ondřej Surý, the author of the PPA I was using,
> and got help in grabbing build-logs so that I should be able to
> reproduce the compile locally, this time without all the optimization.
> However, since I still do not speak configure-ish I failed to resolve
> all packages/libraries needed for a complete build, but I managed to
> smash my keyboard enough to get a working configure & make.
> 
> My test-suite now terminates like this:
> 
> PHPUnit 4.8.21 by Sebastian Bergmann and contributors.
> 
> Runtime:PHP 7.0.3
> Configuration:  /root/web/phpunit.xml
> 
> ...   43 / 1229 (  3%)
> ...   86 / 1229 (  6%)
> ...  129 / 1229 ( 10%)
> ...  172 / 1229 ( 13%)
> ...  215 / 1229 ( 17%)
> ...R...  258 / 1229 ( 20%)
> ...  301 / 1229 ( 24%)
> ...  344 / 1229 ( 27%)
> .R.R.R.  387 / 1229 ( 31%)
> ...  430 / 1229 ( 34%)
> ...  473 / 1229 ( 38%)
> ...  516 / 1229 ( 41%)
> ...  559 / 1229 ( 45%)
> ...  602 / 1229 ( 48%)
> ...  645 / 1229 ( 52%)
> .php: /root/php-src/Zend/zend_execute.h:275:
> zend_vm_stack_free_call_frame_ex: Assertion
> `(executor_globals.vm_stack_top) > (zval *) (executor_globals.vm_stack)
> && (executor_globals.vm_stack_end) > (zval *)
> (executor_globals.vm_stack) && (executor_globals.vm_stack_top) <=
> (executor_globals.vm_stack_end)' failed.
> Aborted (core dumped)
> 
> The failed assertion and my backtrace matches exactly that of
> https://bugs.php.net/bug.php?id=71474 which was fixed a few days ago,
> and is not part of the 7.0.3 release. It's part of the PHP-7.0 branch,
> so I presume this will be fixed in the 7.0.4 release.
> 
> I've recompiled using the PHP-7.0 branch, and my test-suite works there.
> I look forward to the 7.0.4 release!

Thank you very much for your persistence on this. It is motivating for
us when people put a bit of effort into tracking down issues. And yes,
that fix will be in 7.0.4. It came in too late to be part of 7.0.3.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Segmentation fault in PHP 7.0.3 (and earlier versions)

[Rasmus Lerdorf]

On 02/05/2016 11:39 AM, Simon Svensson wrote:
> I am unable to reproduce the error with this recompiled source, both
> with the /usr/local/php70/bin/php and /usr/local/php70-debug/bin/php.
> This is the same experience I had with earlier releases, where I have
> been unable to reproduce the segmentation faults when recompiling (but
> always have them occur from the ppa).
> 
> Is there any guide for compiling the source? I could attempt to setup a
> new virtual machine with Ubuntu 14.04 (instead of php7dev's Debian) to
> reproduce the error, but I do know know the steps needed to compile
> everything.
> 
> The newly build, and working, versions:
> 
> /usr/local/php70/bin/php --version:
> PHP 7.0.4-dev (cli) (built: Feb  5 2016 19:14:08) ( NTS )
> Copyright (c) 1997-2016 The PHP Group
> Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
> with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
> Technologies
> 
> /usr/local/php70-debug/bin/php --version:
> PHP 7.0.4-dev (cli) (built: Feb  5 2016 19:19:10) ( NTS DEBUG )
> Copyright (c) 1997-2016 The PHP Group
> Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
> with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend
> Technologies

"php -i" will show you the configure flags that were used to build it,
so you could try to match those to see if you can reproduce with sources
from php.net. Otherwise, if it is something that only happens with the
distro build then there isn't a while lot we can do to help you.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Deprecation of the Error Control Operator (@ symbol)

[Rasmus Lerdorf]

On 01/04/2016 07:22 PM, Sara Golemon wrote:
> On Thu, Dec 31, 2015 at 1:10 PM, Stanislav Malyshev  
> wrote:
>> I don't think it is a good idea, currently, for the following reasons:
>>
> [::snip::]
> 
> It terrifies me to say this, but I completely agree with Stas. ;)
> 
> I can't personally remember the last time I used @ in any production
> code, but my one-offs are replete with them.  It's a quintessentially
> PHP feature in its pragmatism.
> 
> Okay, I'll put the thesaurus down.

I'd be quite sad to see @ disappear as well. It was one of PHP's
earliest features and its roots date back to mid-80's DOS batch files
(before 1/3 of this list were born I would guess)

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Practical comparisons on PHP7

[Rasmus Lerdorf]

On Dec 7, 2015, at 16:28, Lester Caine  wrote:
> 
> PHP7 is around 10% slower ... and given that half the time is taken
> in database lookup, the code performance is potentially worse. So what
> am I missing?

Then you have a config problem. The first and obvious thing to check is your 
opcache setup. Is it working? phpinfo() will show you some cache stats. If 
opcache is working, what does your opcache config look like? Did you compile 
with huge page support? If so, did you actually allocate some huge pages for it?

If those things look ok, an strace of a request might show something. Another 
really handy tool is perf. You can attach php-cgi to the socket nginx is 
sending requests to and perf record/perf report it. That will give you a nice 
report showing where it is spending it's time.

With a properly configured setup there is absolutely no way for PHP 7 to be 
slower than PHP 5.

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Practical comparisons on PHP7

[Rasmus Lerdorf]

On Dec 7, 2015, at 18:17, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> 
>> On Dec 7, 2015, at 16:28, Lester Caine <les...@lsces.co.uk> wrote:
>> 
>> PHP7 is around 10% slower ... and given that half the time is taken
>> in database lookup, the code performance is potentially worse. So what
>> am I missing?
> 
> Then you have a config problem. The first and obvious thing to check is your 
> opcache setup. Is it working? phpinfo() will show you some cache stats. If 
> opcache is working, what does your opcache config look like? Did you compile 
> with huge page support? If so, did you actually allocate some huge pages for 
> it?

Ah, I just checked. You have no opcache at all in your PHP 7 setup. And you 
have eaccelerator configured for PHP 5. So an opcode cached PHP 5 is only 10% 
faster than a completely unaccelerated PHP 7. That's pretty damn impressive!

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] PHP 7 ?! :)

[Rasmus Lerdorf]

On 12/03/2015 12:28 PM, Andi Gutmans wrote:
> What just happened? It was on php.net and now it's gone?

It's there. Did you get geo-dns'ed to a different www.php.net perhaps?
The mirrors are still updating.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

[Rasmus Lerdorf]

On 12/03/2015 09:39 AM, Niklas Keller wrote:
> Jan Ehrhardt  schrieb am Do., 3. Dez. 2015 17:04:
> 
> Ferenc Kovacs in php.internals (Thu, 3 Dec 2015 16:27:36 +0100):
>> On Thu, Dec 3, 2015 at 4:18 PM, Sebastian Bergmann 
>> wrote:
>>
>>> Am 03.12.2015 um 16:10 schrieb Julien Pauli:
 We, PHP, are not distros maintainers.
>>>
>>>  Well said. But why, then, do we provide Windows binaries?
>>
>> loaded question, I think it would worth splitting the discussion into a
>> separate thread.
>> my understanding is that at the time when we started distributing windows
>> binaries there were no binary distributions for php windows.
> 
> It might be less needed than before. I am compiling OpenSSL 1.0.2e for
> Windows at the moment. Guess that Anatol is doing the same.
> --
> Jan
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http:// www.php.net
> / unsub.php
> 
> 
> 
> Seems like a failed release, make test doesn't work for OpenSSL 1.0.2e.
> Heared other people have other issues on 1.0.1 as well.
> 
> Does it work for you?

The release tarball builds fine against openssl-1.0.1k on Debian-jessie
for me. I haven't tested 1.0.2e yet. Waiting on
https://launchpad.net/debian/+source/openssl/ to get 1.0.2e.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

[Rasmus Lerdorf]

On 12/03/2015 12:58 PM, Niklas Keller wrote:
> Yes, releases have been repackaged,
> see 
> https://mta.openssl.org/pipermail/openssl-announce/2015-December/51.html

Ah, I misread. I thought you meant our php-7.0.0 tarball was a failed
release.




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Rasmus Lerdorf]

On 11/23/2015 09:49 AM, Phil Sturgeon wrote:
> The "There will always be bugs" argument is a strawman, nobody is
> saying wait until it's perfect.
> 
> People in this thread are consistently conflating "there will always
> be bugs" with "lets just ignore this bug which is 'around critical'
> and crack on because yolo."

You seem to be confused Phil. Nobody is arguing that this bug shouldn't
be fixed. The question is all about how severe it is and whether it
should trigger another release candidate.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Rasmus Lerdorf]

On Nov 23, 2015, at 10:35, Derick Rethans <der...@php.net> wrote:
> 
>> On November 23, 2015 10:08:18 AM GMT+01:00, Rasmus Lerdorf 
>> <ras...@lerdorf.com> wrote:
>>> On 11/23/2015 09:49 AM, Phil Sturgeon wrote:
>>> The "There will always be bugs" argument is a strawman, nobody is
>>> saying wait until it's perfect.
>>> 
>>> People in this thread are consistently conflating "there will always
>>> be bugs" with "lets just ignore this bug which is 'around critical'
>>> and crack on because yolo."
>> 
>> You seem to be confused Phil. Nobody is arguing that this bug shouldn't
>> be fixed. The question is all about how severe it is and whether it
>> should trigger another release candidate.
> 
> Do I understand that you'd like to release 7.0.0 as 7.0.0RC7 + the count fix 
> on Thursday? 

Yes

> I don't think we should push out 7.0.0 without the count fix, but I also 
> don't think it warrants another RC. 
> 
> If people think it needs another RC, then perhaps do one on Thu 26th with 
> just RCA+ count fix, plus final on Thu Dec 3rd? 

I am ok with either. I don't think the count fix is destabilizing enough to 
warrant another RC. The fix seems simple and localized to me, but either people 
are confused, or they genuinely feel strongly enough that this is indicative of 
further problems and another RC will provide us with more time to find similar 
issues or perhaps just give everyone a sense of confidence in the release.

There is also the fact that a lot of us are in Paris this week and and at least 
some of us will be in transit on the 26th so a one-week delay might be a good 
idea for that reason alone.

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Rasmus Lerdorf]

On Nov 23, 2015, at 15:05, Zeev Suraski  wrote:
> 
>> On 23 בנוב׳ 2015, at 14:04, Joe Watkins  wrote:
>> 
>> 
>> No one is expecting 0.0 or any version to be bug free, but the simplicity of 
>> the fix says nothing about the seriousness of the bug. I think it quite 
>> serious _because_ we are a few days from GA, had this been found a month ago 
>> it wouldn't seem so serious.
>> 
> 
> No, but both the seriousness of the bug AND the simplicity of the fix sit 
> squarely outside any sort of "critical" definition.
> 
> The bug simply has the unfortunate connotation of being associated with 
> arrays, but is not - it's only about count()ing symbol tables.  The fix 
> itself is very localized too and was peer reviewed, so I don't feel as if 
> we'd be living on the edge of we'd be releasing without an extra RC.
> 
> My main concern is that of we're treating this issue as a semi blocker - it's 
> almost unthinkable we won't find something of similar (small) magnitude in 
> the next seven days.  That's my only concern with releasing next week,m.  
> Would people here again demand to delay, even if the impact is very limited - 
> as is the case with this count() issue?  If it wasn't for that concern, I'd 
> probably be in favor of delaying.

I think this was mostly a PR failure on my part actually. If I/we are a bit 
more careful about how we handle similar issues and the people lurking with 
itchy Twitter trigger fingers would spend a bit more time looking into the 
details we should all be able to get along and get a good launch with no 
controversy on Dec.3.

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Rasmus Lerdorf]

On Nov 23, 2015, at 15:21, Anthony Ferrara  wrote:
> 
> Rasmus,
> 
>> I think this was mostly a PR failure on my part actually. If I/we are a bit 
>> more careful about how we handle similar issues and the people lurking with 
>> itchy Twitter trigger fingers would spend a bit more time looking into the 
>> details we should all be able to get along and get a good launch with no 
>> controversy on Dec.3.
> 
> Sorry, but when you make a statement like:
> 
>> Nobody is going to take a .0.0 and push it straight to production.
> 
> THAT is more than a PR failure. That's a perspective failure.

I still don't see anyone going straight to production with 7.0.0 unless they 
have been extensively testing the RCs. And if they have been extensively 
testing the RCs then any issues in them must not be impacting them. 7.0.0 is 
the wake up call for all the people who haven't been testing the RCs and as 
such it will generate more issues, regardless of how long we wait. That's why I 
still wouldn't suggest anyone go straight to production with 7.0.0 even if we 
delay another full year. This has nothing to do with being cavalier nor having 
a perspective failure about anything, it has to do with being realistic and 
pragmatic about how things work based on years of experience doing this.

Every single release in the history of PHP has been a compromise. We have RCs 
until the set of fixes from one RC to the next is free of major issues. There 
will always be more issues, so we have to make a release decision at some point.

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Rasmus Lerdorf]

On Nov 23, 2015, at 00:48, Adam Harvey  wrote:
> 
> Here's an alternative suggestion: we've previously switched to one
> week RC cycles late in the piece when trying to get major releases
> stabilised and we're at the point of only fixing one or two things per
> RC. That's exactly where we are now. Why don't we do that again —
> release a fix for this bug as an RC 8 this week, and then do a release
> on December 3 if nothing else significant comes up?

Still not entirely convinced this bug is major enough to warrant the
delay. It seems right on the edge to me. But since it is on the edge
there will be enough people who think it is major that we probably
should wait on it. Doing a one-week RC8 this week and aiming for
a Dec.3 release seems like a good solution to me.

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Rasmus Lerdorf]

On 11/22/2015 06:18 AM, Anthony Ferrara wrote:
> Zeev,
> 
> On Sat, Nov 21, 2015 at 11:52 PM, Zeev Suraski  wrote:
>>
>>> On 22 בנוב׳ 2015, at 0:47, Anthony Ferrara  wrote:
>>>
>>> I think this is significant enough to be a blocker to gold and that we
>>> should fix it prior to release.
>>>
>>> Thoughts?
>>>
>>
>> IMHO, unless we think fixing this would require breaking binary 
>> compatibility (which I don't think is the case) - this shouldn't block 
>> 7.0.0.  7.0.0 is a lot more about getting people to start paying attention 
>> to 7.0 and start testing their codebase against it - finding both the 
>> incompatibilities in their code and, undoubtedly - the bugs we failed to 
>> find.  I wish we could say this would be the last issue we find in 7.0, but 
>> I think we can all agree it's wishful thinking...
> 
> Consider that Distros may very well pick whatever we call stable for
> LTS releases. Meaning that non-critical (crash/security) bugs that we
> miss may wind up living on for a VERY long time. If we don't intend .0
> to be stable, then what's the point of versioning in the first place?
> 
> Xinchen,
> 
> Very interesting on the fix. I do think it's important for this to
> land with 7, but at least we can have the discussion.

I agree with Zeev here and I had a chat with Anatol about this tonight.
This is a .0.0 release. Nobody is going to take a .0.0 and push it
straight to production. And it is not going to part of any sort of LTS
distro either. It's not like LTS distros don't pick up point releases.
There is no way we will go 2 weeks without finding something for quite a
while still which can drag things out indefinitely. The question is
whether this is significant enough to postpone further. Personally I
don't think it is. Let's get 7.0.0 out the door and get ourselves on
track for regular point releases without any of this "perfect-release"
stress.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Benchmark Results for PHP Master 2015-11-19

[Rasmus Lerdorf]

On Nov 20, 2015, at 15:51, Andone, Bogdan  wrote:
> 
> Please ignore the Mandelbrot result. It seems it was a measurement error, as
> we were unable to reproduce it on the same commit with additional runs.

Perhaps it would be possible to automatically trigger additional runs in case a 
result shows a drastic change like that? Just to eliminate false outliers. 
These benchmarks are a great sanity check which can catch small changes that 
have inadvertent performance hits, but we need to have confidence in the 
numbers otherwise  people will start ignoring them.

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Support for writing and executing compiled opcode Stephen Coakley <m...@stephencoakley.com>

[Rasmus Lerdorf]

On 11/16/2015 03:13 PM, Jefferson Gonzalez wrote:
> On 11/14/2015 08:03 PM, Rasmus Lerdorf wrote:
>> Beyond that I can't picture what possible use this could be.
> 
> I also think that the ability to have a .phpc and .php side by side
> would be nice, but not for hiding the source code. It would be useful
> especially for php-cgi and secondary for php-cli. In php-cgi case theres
> people who still host multiple sites on a single server and use the
> php-cgi method because it doesn't requires to have an always running
> instance like with php-fpm.
> 
> Lets say you are hosting 100 sites on a single server, imho it would be
> less resourceful to run php-cgi processes on demand than having more
> than 100 fpm processes idling for requests. So in this scenario, having
> the flexibility to load byte code for php-cgi process would be a nice
> performance boost.

But that is exactly what the file-based opcache does by itself. The only
speedup you achieve by trying to distribute the .bin files would be a
minor boost the first time a cli script is executed. All subsequent runs
of the script would hit the cache. The added complexity and potential
version conflicts of trying to distribute the .bin files doesn't seem
like it would be worth the trouble for such a minor one-time performance
benefit.

-Rasmus




signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Support for writing and executing compiled opcodeStephen Coakley <m...@stephencoakley.com>

[Rasmus Lerdorf]

On 11/16/2015 04:11 PM, Jefferson Gonzalez wrote:
> On 11/16/2015 04:22 PM, Rasmus Lerdorf wrote:
>> But that is exactly what the file-based opcache does by itself. The only
>> speedup you achieve by trying to distribute the .bin files would be a
>> minor boost the first time a cli script is executed. All subsequent runs
>> of the script would hit the cache. The added complexity and potential
>> version conflicts of trying to distribute the .bin files doesn't seem
>> like it would be worth the trouble for such a minor one-time performance
>> benefit.
>>
>> -Rasmus
>>
>>
> 
> But as far as I know thats only possible with php-cli and not with
> php-cgi, is it?

There is nothing cli-specific about this feature, so yes, it works fine
with php-cgi. You can set opcache.file_cache_only if you like to not
even try to create a shm cache and only use the file-based one for your
php-cgi setup.

-Rasmus



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Support for writing and executing compiled opcode

[Rasmus Lerdorf]

On Nov 13, 2015, at 21:32, Stephen Coakley <m...@stephencoakley.com> wrote:
> 
>> On 11/13/2015 05:46 PM, Rasmus Lerdorf wrote:
>>> On Nov 13, 2015, at 17:00, Stephen Coakley <m...@stephencoakley.com> wrote:
>>> 
>>>>> On 11/13/2015 03:45 PM, Sebastian Bergmann wrote:
>>>>> On 11/13/2015 04:35 PM, Stephen Coakley wrote:
>>>>> This is quite similar to Python's ability to execute Python scripts
>>>>> compiled to bytecode as *.pyc files. The feature has seen great
>>>>> success in
>>>>> Python, mostly for distributing releases of software or deploying to a
>>>>> server.
>>>> 
>>>>  Correct me if I'm wrong, but this should already be possible with OpCache
>>>>  and its filesystem backend in PHP 7.0.
>>>> 
>>>>  See http://talks.php.net/froscon15#/php7pcache1 and following for
>>>>  details.
>>> 
>>> That's great! That's about halfway toward what I'm looking for. That means 
>>> that the engine is likely already capable of doing these things -- the next 
>>> step is to be able to execute any given .php.bin file like in that talk. 
>>> The idea would be to be able to bypass the caching mentality by executing 
>>> an already compiled file, instead of checking if the original .php file has 
>>> a corresponding bin file in the cache
>> 
>> You could simply deploy both the .php and the .bin files to achieve this 
>> today.
>> 
>> -Rasmus
> 
> Would the bin files not have to be placed in the special OPcache file store 
> location though? That seems sub-optimal.

But that is just a matter of copying the .bin files into a configurable 
directory. However, as others have said, this is completely pointless. If you 
are worried about initial compile latency on initial requests after a deeply of 
new code then simply run a couple of warmup requests before flipping your 
symlink to the new code. Beyond that I can't picture what possible use this 
could be. Hiding source code? No chance, getting PHP code from bytecode is 
trivial.

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Is there documentation somewhere on public CMS/Framework/Libs that are PHP7 compat?

[Rasmus Lerdorf]

On Nov 14, 2015, at 10:13, Pascal Chevrel  wrote:
> 
> Hi guys,
> 
> I am very exceited about the imminent release of PHP 7 and that also
> corresponds to when my non-profit will get a new server sponsored by a
> local ISP, so we want to switch to 7 at this occasion, right in December ;)
> 
> Do you know of any public list of what CMS are working with PHP 7
> without a problem? I am starting to test by myself what we use. My own
> projects are of course PHP 7 compatible but we also have the usual tools
> that open source project use for their day to day activities (blog,
> wiki, forums...).
> 
> The nice news of the day for me is that the Dotclear blogging platform
> works fine with PHP 7 and flies :) (tested on a shared OVH hosting which
> allows activating PHP 7 via a config flag). Is there some wiki page
> somewhere where I could document what I know works and others would do
> the same so as to ease the migration of early adopters, especially those
> of us that are open source hacktivists and don't have IT department to
> check those things for us?

It is really up to individual projects to specify which PHP versions they 
support. However, I can tell you that after installing 20+ randomly chosen 
large applications the number of issues I ran across were insignificant. And 
for the couple I hit and filed issues on the fix was quick and easy, so I would 
say that you can assume that pretty much anything you need will either already 
work on PHP 7 and when/if you hit any issues the work involved in fixing them 
will be minor.

-Rasmus

smime.p7s
Description: S/MIME cryptographic signature