Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

Den søn. 24. mar. 2019 kl. 03.11 skrev Lester Caine :
>
> (Neely forgot to fix reply address!)
>
> On 24/03/2019 00:22, Kalle Sommer Nielsen wrote:
> > mysql_connect('localhost', 'user', 'password');
> > mysql_select_db('test'); // The last created connection is implicitly added 
> > here
>
> This situation never exists in Firebird or Interbase. The ONLY way to
> connect is to a database, you can not connect to the server without
> using a database in the connection string. Each database is it's own
> file or set of files if spread across multiple disks. There is no way of
> asking a server what databases are available, you have to know
> beforehand. Although some newcomers call it a bug it's an original
> design feature.

Really Lester, really. It was a pseudo example, do I really need to be
EXPLICIT and spell everything out very specifically for you?

ibase_connect('localhost:/path/to/some/db.gdb', 'user', 'password');
ibase_query('UPDATE a_table SET a_column = 1'); // The last created
connection is implicitly added here

What happens here is that PHP retain the last connection created by
ibase_connect() and uses it as a "default" link, meaning you do not
pass a connection resource to ibase_query() afterwards.

Compare the example to:

$link = ibase_connect('localhost:/path/to/some/db.gdb', 'user', 'password');
ibase_query($link, 'UPDATE a_table SET a_column = 1'); // Explicit, as
the first parameter is a connection resource

Besides this, it has further magic behavior if the multiple
connections are created with the same credentials as one in the same
process, I'm not sure if this is fixed with Nikita's patch.

> I'll add BOOLEAN to https://phpsurgery.org/tests/ibtest.php tomorrow,
> but there are bugs in your link that don't show in the link I have been
> using :( But some of them are not bugs ...

Then use the link from the statistics page on bugs.php.net? There is
probably a fair few for PDO_Firebird too you can find on that page

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Lester Caine]

(Neely forgot to fix reply address!)

On 24/03/2019 00:22, Kalle Sommer Nielsen wrote:

mysql_connect('localhost', 'user', 'password');
mysql_select_db('test'); // The last created connection is implicitly added here


This situation never exists in Firebird or Interbase. The ONLY way to 
connect is to a database, you can not connect to the server without 
using a database in the connection string. Each database is it's own 
file or set of files if spread across multiple disks. There is no way of 
asking a server what databases are available, you have to know 
beforehand. Although some newcomers call it a bug it's an original 
design feature.


I'll add BOOLEAN to https://phpsurgery.org/tests/ibtest.php tomorrow, 
but there are bugs in your link that don't show in the link I have been 
using :( But some of them are not bugs ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

Hi Lester

Den lør. 23. mar. 2019 kl. 23.41 skrev Lester Caine :
> Thread safety is one area where the way the extension was structured
> originally may now be wrong, but the main problem with multiple
> connections is confined completely to multiple connections to a single
> database. In particular the 'default link' is actually the default
> transaction handle and additional links are simply multiple transactions
> on the one connection which I think is where some of the confusion has
> come from :( A more established Firebird user would simply start a new
> transaction, while a newbie may try to start a new connection. And in
> the past the extension has hidden that and quietly picked up the
> existing one ...

The default link should not be related to thread safety, it should be
related to the design of how database extensions used to be working.
The design was as follows (using the old ext/mysql as an example
here).

mysql_connect('localhost', 'user', 'password');
mysql_select_db('test'); // The last created connection is implicitly added here

This is the "default" link. This is some magical behavior which made
the API very easy to use, however it also created some hard to debug
situations with multiple connections. ext/interbase seems to still go
by this design which is most likely the reason to why some of the
weirdness of the extension behavior after the blind updates to
somewhat work on PHP7.

Regarding the connection and fork(), is this a problem in other
database extensions, if not, then it may be worth it for whoever ends
up picking up the extension to look at how others do this. The design
of this extension is fairly old and prone to unforeseen errors.

> "A small subset of field types are supported, anything else crashes"
> This is news to me ... is there any bug report to back it up? All the
> current data types provided by Firebird are working in the extension,
> but you may well be right that we may be better off cloning the existing
> code and building a Firebird only port going forward. The concern is the
> same one we had with windows in the past, where adding extra extensions
> does not always work reliably ... one has to provide a wrapped package
> with all the edge cases addressed. But all my use in production is using
> ADOdb to wrap the database SQL problems ...

I count 13 open bugs[1] in regards to ext/interbase thats been
reported, there are probably a ton more. Bug#74946 talks about a crash
with a type, leading me to believe that if one type can crash, then
more are very likely too.


[1] 
https://bugs.php.net/search.php?cmd=display_type=All=Open_name%5B%5D=InterBase+related=Any=30


regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] [RFC] [VOTE] JIT

[Rowan Collins]

On 23 March 2019 19:46:16 GMT+00:00, Peter Kokot  wrote:
> I'm sure very little people will compile PHP 8.0-dev on
>their own and install it to test that before the release.

I suggested before that a series of official PHP 8 preview builds could be 
released so that people didn't need to compile their own, and I believe 
somebody offered to do so.

The trade-off then is between testing an up to date JIT (as opposed to one 
snapshotted when 7.4 ships, with limited updates) and being able to test the 
JIT without fixing deprecation notices (but possibly encountering bugs already 
fixed for 8.0).

Regards,

-- 
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Rowan Collins]

On 23 March 2019 21:09:35 GMT+00:00, Kalle Sommer Nielsen  wrote:
> the extension can be taken over by anyone who
>wants to from the relevant community, it just will not be distributed
>by default with PHP. In fact if the extension is released on PECL, it
>gives the relevant community more freedom to deal with the extension
>as they deem fit and does not have the strict requirements as
>extensions in the Core has. Sources and binaries are still available
>with the PECL interface.


It's probably worth noting the example of Microsoft SQL Server here: the 
previous PHP extensions were dropped from the core in 7.0, and Microsoft now 
manages an open-source, cross-platform extension, and is able to release it as 
often as they want, and bring in features and bug fixes to encourage its use: 
https://github.com/Microsoft/msphpsql

For an extension connecting to any actively developed third-party system, this 
is probably actually the best model, with PHP Internals experts providing 
advice where necessary, and third-party experts tracking innovations in the 
particular system.

Regards,

-- 
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Lester Caine]

On 23/03/2019 21:09, Kalle Sommer Nielsen wrote:

I updated the RFC with a section earlier to list some of the issues
the extension currently has.


Thread safety is one area where the way the extension was structured 
originally may now be wrong, but the main problem with multiple 
connections is confined completely to multiple connections to a single 
database. In particular the 'default link' is actually the default 
transaction handle and additional links are simply multiple transactions 
on the one connection which I think is where some of the confusion has 
come from :( A more established Firebird user would simply start a new 
transaction, while a newbie may try to start a new connection. And in 
the past the extension has hidden that and quietly picked up the 
existing one ...


"A small subset of field types are supported, anything else crashes"
This is news to me ... is there any bug report to back it up? All the 
current data types provided by Firebird are working in the extension, 
but you may well be right that we may be better off cloning the existing 
code and building a Firebird only port going forward. The concern is the 
same one we had with windows in the past, where adding extra extensions 
does not always work reliably ... one has to provide a wrapped package 
with all the edge cases addressed. But all my use in production is using 
ADOdb to wrap the database SQL problems ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Kalle Sommer Nielsen]

Den lør. 23. mar. 2019 kl. 22.59 skrev Lester Caine :
> So is there anything else which is required to bring the extension up to
> date? There is nothing above that prevents the extension doing it's job
> for the vast majority of users and even the suggestion that it is
> unusable due to Bug 72175 does not stand up to scrutiny and can now be
> fixed in 7.3 and 7.2 anyway ...

I updated the RFC with a section earlier to list some of the issues
the extension currently has. Like Joe said in the other thread, it
does bad bad things in ZTS among some of the serious issues. Even if
these things are fixed, we do not have a guarantee to have someone who
is capable of dealing with the issues at hand in the future, nor do I
see fixing bug#72175 as a reason to halt this RFC.

Like I have expressed to people who has mailed me off list (which is
inappropriate) that the extension can be taken over by anyone who
wants to from the relevant community, it just will not be distributed
by default with PHP. In fact if the extension is released on PECL, it
gives the relevant community more freedom to deal with the extension
as they deem fit and does not have the strict requirements as
extensions in the Core has. Sources and binaries are still available
with the PECL interface.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] New syntax proposal (type hinting)

[Robert Hickman]

On Sat, 23 Mar 2019 at 20:17, dj.drezyna  wrote:
>
> I wish have opportunity to set types not only like:   function a(): string {} 
>  or  function b(): ?string {}
> but also as:  function c(): string | int {}  or  function d(): ?string | 
> ?array {}// all of them should mark
> that null is accepted.

Looks like you're asking for union types. There was an RFC about this
before but it didn't pass, I don't know why.

https://wiki.php.net/rfc/union_types

I would also like to see union types added, as I can't type hint most
of my code in absence of them.

Regarding the type coalescing problem noted in that RFC, my solution
to that would be to do noting. If a function accepts float or int, it
should just pass either through unchanged. Passing any other type
should be an error without an explicit cast IMO.

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

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Lester Caine]

On 22/03/2019 13:26, Kalle Sommer Nielsen wrote:

I'd like to start the discussion for the future of the ext/interbase extension:
https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase


Currently I am seeing 6 open bugs against ext/interbase going back to 
2009 ...

48447 - 2009
The oldest bug relates I think to threading and I think the problem here 
is trying to use the same connection opened in one thread in the child 
thread. Close the connection then fork and I am presuming it will work, 
but I don't have pcntl loaded in production and had to add it to the 
test setup ... but don't know what I would use it for, but it may be 
appropriate to use with Firebird's events interface.

62300 - 2012
Tomorrows job ... have the files downloaded now, but I don't recognise 
the problem as we use null all the time to trigger the database 
generator code.

71650 - 2016
We do have it documented 
http://www.janus-software.com/fbmanual/man.php?book=php and it may be 
necessary to separate it out from the interbase extension to cope with 
Firebird 4 which adds new data types!

72175 - 2016
The patch nikita has proposed works nicely now I've got it running on 
7.2.16 ... the WAY duplicate connections to the same database are 
handled may be part of the problem with Bug 48447 ...

74076 - 2017
The reported bug is not repeatable, but using the wrong resource id will 
trigger a seg fault. Not sure if it's possible to detect the mistake and 
error instead.

74104 - 2017
Again not able to duplicate, but it looks like it's a matter of 
replacing strptime which should be something I can address in isolation. 
Getting dates in is the biggest problem everywhere.


So is there anything else which is required to bring the extension up to 
date? There is nothing above that prevents the extension doing it's job 
for the vast majority of users and even the suggestion that it is 
unusable due to Bug 72175 does not stand up to scrutiny and can now be 
fixed in 7.3 and 7.2 anyway ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Dan Ackroyd]

On Fri, 22 Mar 2019 at 13:26, Kalle Sommer Nielsen  wrote:

> G'day internals
>

To everyone reading this thread please note:

Although people are free to discuss RFCs amongst themselves off-list, it is
not appropriate behaviour to contact people discussing an RFC on this list
through other communication channels.

Any communication about the topic that you want to send to someone in this
thread should be sent via the PHP internals list.

cheers
Dan
Ack














* unless of course you know the person yourself off-list.

[PHP-DEV] New syntax proposal (type hinting)

[dj . drezyna]

I wish have opportunity to set types not only like:   function a(): string {}  
or  function b(): ?string {}   but also as:  function c(): string | int {}  or  
function d(): ?string | ?array {}// all of them should mark that null is 
accepted.   Similar thing is I suppose is in catch{} clause.   Of course not 
only return types can affected but also types in args.   And sometime we can 
think about types of properties and variables however this is rather long 
distance future.   So the first part of this message is could be done in the 
near future?  Dnia 23 marca 2019 20:56 Peter Kokot peterko...@gmail.com 
napisał(a):  Hello,   On Sat, 23 Mar 2019 at 19:45, dj.drezyna 
dj_drez...@wp.pl wrote:   I wish have opportunity to set types not only 
like:   function a(): string {}  or  function b(): ?string {}   but also as:  
function c(): string | int {}  or  function d(): ?string | ?array {}// all of 
them should mark that null is accepted.   Similar thing is I suppose is in 
catch{} clause.   Of course not only return types can affected but also types 
in args.   And sometime we can think about types of properties and variables 
however this is rather long distance future.   So the first part of this 
message is could be done in the near future?   Can you please forward this 
email to the internals mailing list  instead:   internals@lists.php.net   
Thanks... This mailing list is about *.php.net websites.   --  Peter Kokot

Re: [PHP-DEV] [RFC] [VOTE] JIT

[Peter Kokot]

Hello,

On Thu, 21 Mar 2019 at 12:58, Dmitry Stogov  wrote:
>
> Hey,
>
> I'm starting the vote on JIT RFC.
>
>
>  https://wiki.php.net/rfc/jit
>
>
> The voting period is one week, until Thursday 28-03-2019 GMT.
>
>
> Since the initial announcement and following discussions, RFC was imprved and 
> implementation extended with support for Clang, Windows and ZTS builds.
> Please reread RFC carefully.
>
>
> Thanks. Dmitry.

+1 to both options. Having such feature in the PHP-7.4 is also good to
be able to check it out sooner (and to have some test base). With
having this in PHP 8.0 we will need to wait for more than a year to
check it out. I'm sure very little people will compile PHP 8.0-dev on
their own and install it to test that before the release. PHP 8.0.0
release could be also about removing deprecated functionality. This
approach is actually following semver https://semver.org, so that's
all good I think.

In any case if we will need to wait more than another year or not,
thank you for your great work. Thumbs up. :)

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] Abolish Short Votes

[Joe Watkins]

> A compromise between the two positions could be to allow voting to be
extended ONCE, and only within the first X% of the voting period. So, if
someone calls for a 14 day voting period, within the first 7 days they can
extend it at most one time, and it can never be extended after the first 7
days.

It's tempting to try and encode "requirements" into rules, but we're not
looking to make complicated rules and the only requirement we have is that
votes should last at least two weeks for everything. The simpler the rules
are, the better for everyone.

> Also, if you are going to be updating the language anyway, why not
specify that an exact date and time be given for when voting will end. I
think most people already do this - but this would codify it and prevent
the possibility of ambiguity in the future.

We have to deal with real life, and the fact is that hardly anyone can
schedule their lives around their contributions to PHP: Days seem to be an
exact enough measure, and as you say, some people do give a time when the
vote will close anyway. However, declaring they must isn't very realistic -
if they miss closing the vote by 15 minutes, does it invalidate the vote ?
Are we going to invent a set of criteria that would invalidate the vote ?
This seems like a rabbit hole we need not get stuck in.

Cheers
Joe

On Fri, 22 Mar 2019 at 17:01, Chase Peeler  wrote:

>
> On Fri, Mar 22, 2019 at 3:41 AM Joe Watkins  wrote:
>
>> Morning Niklas,
>>
>> Allowing the extension of voting leaves us open to someone extending the
>> voting period simply because they don't feel like they have the result
>> they
>> wanted.
>>
>> The problem we're trying to solve is votes that are too short, while
>> providing the flexibility to have longer votes, but we need to know at the
>> start of voting what the voting period is going to be. Take for example
>> the
>> case where a third party to an RFC is planning some work based on the
>> results of the voting, it doesn't seem fair that their schedule could be
>> interfered with by the first party after voting starts.
>>
>> In the vast majority of cases where someone forgets or isn't aware of a
>> holiday period, they are going to be told on day one of voting (if not
>> before, during discussion), and can simply adjust the voting period, and
>> restart the vote (if there has been any votes at the first interjection)
>> without having lost any time.
>>
>> First, I don't even have a vote. Second, I'd be ambivalent about the
> ability to extend voting even if I did. A compromise between the two
> positions could be to allow voting to be extended ONCE, and only within the
> first X% of the voting period. So, if someone calls for a 14 day voting
> period, within the first 7 days they can extend it at most one time, and it
> can never be extended after the first 7 days.
>
> Also, if you are going to be updating the language anyway, why not specify
> that an exact date and time be given for when voting will end. I think most
> people already do this - but this would codify it and prevent the
> possibility of ambiguity in the future.
>
>
>> Cheers
>> Joe
>>
>> On Fri, 22 Mar 2019 at 08:19, Niklas Keller  wrote:
>>
>> > Resend, because sent from the wrong address previously.
>> >
>> > +1, but it should probably be possible to extend the voting period once
>> > started, but not shorten it. This allows for extension during holidays
>> in
>> > case the author didn't think about that when starting the vote.
>> >
>> > Regards, Niklas
>> >
>> > Joe Watkins  schrieb am Do., 21. März 2019, 19:20:
>> >
>> > > Evening internals,
>> > >
>> > > I'd like to raise for discussion another minor, self contained change
>> to
>> > > the voting RFC:
>> > >
>> > > https://wiki.php.net/rfc/abolish-short-votes
>> > >
>> > > This seems like another no-brainer to improve and clarify the voting
>> > > process. As with abolishing narrow margins, I'm focused on this one
>> > detail
>> > > and wider discussion of how we may improve other parts of the voting
>> RFC
>> > is
>> > > not appropriate in this thread: We either have a consensus that this
>> > detail
>> > > should be changed or we don't, we do not need to discuss any other
>> > details
>> > > here.
>> > >
>> > > Cheers
>> > > Joe
>> > >
>> >
>>
> --
> -- Chase
> chasepee...@gmail.com
>

Re: [PHP-DEV] Offset-only results from preg_match

[C. Scott Ananian]

Yup, testing via CLI but Wikimedia will (eventually) be running PHP 7.x
with opcache ( https://phabricator.wikimedia.org/T176370 /
https://phabricator.wikimedia.org/T211964 ).  It would be nice to fix the
CLI to behave more like the server wrt interned strings.  It certainly
would make benchmarking easier/more representative, but we also have a
bunch of testing/CI stuff running in CLI mode so speedups there are
definitely useful, even if they don't "speed up Wikipedia" per se.

Ignoring the zend_hash_find costs for the moment, php_pcre_match_impl costs
492,077,935 cycles in this benchmark, of which only 211,626,095 are spent
doing the actual php_pcre2_jit_match.  140,000,069 cycles are spent in
populate_subpat_array and 108,742,309 are spent in the zval_ptr_dtor call
on the penultimate line -- basically freeing the $matches array from the
previous call to pcre_match (and this is with PREG_LENGTH_CAPTURE).  So
there's still (in theory) a >2x speedup in preg matching available by
tuning how the subpat_array works and making it less costly to
allocate/free $matches.
  --scott

On Sat, Mar 23, 2019 at 6:13 AM Nikita Popov  wrote:

> On Sat, Mar 23, 2019 at 6:32 AM C. Scott Ananian 
> wrote:
>
>> So...
>>
>> In microbenchmarks you can clearly see the improvement:
>> ```
>> >>> timeit -n500 preg_match_all('/(.{65535})/s', $html100, $m,
>> PREG_OFFSET_CAPTURE);
>> => 39
>> Command took 0.001709 seconds on average (0.001654 median; 0.854503
>> total) to complete.
>> >>> timeit -n500 preg_match_all('/(.{65535})/s', $html100, $m,
>> PREG_OFFSET_CAPTURE|PREG_LENGTH_CAPTURE);
>> => 39
>> Command took 0.000991 seconds on average (0.000965 median; 0.495287
>> total) to complete.
>> ```
>> $html100 is my usual 2,592,386 byte HTML of [[en:Barack Obama]].
>>
>> But unless you're matching 64k strings like this, it's hard to see a
>> practical improvement.  In my remex-html html parsing benchmark, although
>> LENGTH_CAPTURE doesn't make things slower, it doesn't make a significant
>> performance improvement.  I built php statically and ran it through
>> cachegrind to try to figure out why, and found:
>>
>> 2,567,559,670 cycles: total spent executing the tokenizer benchmark
>> (including reading the file from disk)
>> 1,018,845,290 cycles in zif_preg_match.  Optimizing regexps is important
>> for tokenizers! Of these, we spend
>>   575,478,637 doing the actual match (preg_pcre_match_impl) and
>>   435,162,131 getting the regexp from the cache (!)
>> (pcre_get_compiled_regex_cache)
>>
>> This is for 128,794 total regexp matches performed by the tokenizer on
>> this input.
>>
>> Of those cycles getting the regex from cache, only 24,116,319 are spent
>> on cache misses where we are actually compiling regexps (sum of
>> php_pcre2_jit_compile and php_pcre2_compile).
>> Instead, 406,007,383 cycles are spent in zend_hash_find().  That's 40% of
>> the total time spent executing preg_match.
>>
>> The LENGTH_CAPTURE optimization does reduce the total time spent in
>> populate_subpat_array from 160,951,690 cycles to 140,042,331 cycles in the
>> remex-html tokenizer on this benchmark, but that difference is overwhelmed
>> by (for example) the time spent in zend_hash_find().
>>
>> The slowdown in zend_hash_find() appears to be due to
>> https://bugs.php.net/bug.php?id=63180 which disabled interned keys in
>> the pcre_cache table.  Because of this, even if the regexs are interned, we
>> must pay for a complete zend_string_equal_content() on each match, which
>> takes time proportional to the length of the regex.  This can be quite
>> large -- for example, for the HTML5 character reference regex in
>> remex-html, which contains every valid entity name and is 26,137 bytes
>> long, and we need to do a zend_string_equal_content() on the 26,137 byte
>> regexp for every ~5 byte entity in the parsed HTML.
>>   --scott
>>
>
> Thanks for testing! That's an interesting result. We should be able to do
> something about this. There are basically three cases:
>
> 1. CLI (presumably what you're testing). Strings are interned per-request,
> but there is only one request.
> 2. Server w/o opcache. Strings are interned per-request and there may be
> multiple requests.
> 3. Server with opcache. Strings are interned permanently in opcache.
>
> Case 3 should already be fast, because permanent interned strings are
> allowed into the regex cache. We can optimize case 1 by simply allowing
> arbitrary cache keys and discarding the cache in RSHUTDOWN -- it will not
> be needed anymore anyway. Case 2 would remain slow, but it's slow anyway...
>
> Nikita
>
>
>> On Thu, Mar 21, 2019 at 7:35 AM Nikita Popov 
>> wrote:
>>
>>> On Wed, Mar 20, 2019 at 4:35 PM C. Scott Ananian 
>>> wrote:
>>>
 On Tue, Mar 19, 2019 at 10:58 AM Nikita Popov 
 wrote:

> After thinking about this some more, while this may be a minor
> performance improvement, it still does more work than necessary. In
> particular the use of OFFSET_CAPTURE (which would be pretty much 

Re: [PHP-DEV] Firebird - Who are WE ...

[Kalle Sommer Nielsen]

Den lør. 23. mar. 2019 kl. 15.59 skrev Lester Caine :
> It's lunch time here and I've just had a phone call from a client
> complaining that their site is down ... just a white screen ...
> Actually it was only a small area inside the site and I'd not picked it
> up in the several hundred pages that make up the site :( Nothing in fpm7
> log to hint at the problem - again - so I AM in something of a bad mood.
> Turned out to be part of the upgrade to get these sites working on
> PHP7.2/FB3 was missed so suggestions that something I've been using for
> 20 years does not work does not go down well!

Again this is NOT relevant to the thousands of people you are
literally spamming. This stuff belongs on Twitter, your blog or some
other kind of social media, it is NOT relevant to the development of
the PHP runtime, so keep this off the list.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] Firebird - Who are WE ...

[Lester Caine]

On 23/03/2019 13:30, Kalle Sommer Nielsen wrote:


This kind of behavior does not belong here in any possible way, and it 
does not win you any points in favor. Take the rest of the evening off 
the computer if you cannot handle the reality and issues that is present 
here in the ext/interbase debate.


It's lunch time here and I've just had a phone call from a client 
complaining that their site is down ... just a white screen ...
Actually it was only a small area inside the site and I'd not picked it 
up in the several hundred pages that make up the site :( Nothing in fpm7 
log to hint at the problem - again - so I AM in something of a bad mood. 
Turned out to be part of the upgrade to get these sites working on 
PHP7.2/FB3 was missed so suggestions that something I've been using for 
20 years does not work does not go down well!


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Firebird - Who are WE ...

[Kalle Sommer Nielsen]

lør. 23. mar. 2019 kl. 15.22 skrev Lester Caine :

> On 23/03/2019 12:46, Kalle Sommer Nielsen wrote:
> >> Now to get back to working out why Nikita's patch does not work in
> >> 7.2.16 ...
> > Obviously because the patch was made for PHP 7.3. Hint: If a
> > macro/function is not available in 7.2, then look at how it is
> > implemented in 7.3 and migrate it or see how other functions who do
> > similar functionality works and port it.
>
> When merging the patch with the older code I was fairly sure that it did
> exist already in 7.2 ... but until I can get php-src synced I'm having
> to manually scan for this stuff ... at the current rate hg-git will take
> 24 days so now I need another plan of attack :(


I don’t know what kind of infrastructure you have going (and frankly I do
not care, even less after what I just read from your part in the past day
or so). But you seem to be the only one with this issue and convoluted
infrastructure, but again irrelevant to the debate currently on going.

Pleased keep these rants of irrelevance off the list.

> --
regards,

Kalle Sommer Nielsen
ka...@php.net

Re: [PHP-DEV] Firebird - Who are WE ...

[Benjamin Eberlei]

On Sat, Mar 23, 2019 at 2:22 PM Lester Caine  wrote:

> On 23/03/2019 12:46, Kalle Sommer Nielsen wrote:
> >> Now to get back to working out why Nikita's patch does not work in
> >> 7.2.16 ...
> > Obviously because the patch was made for PHP 7.3. Hint: If a
> > macro/function is not available in 7.2, then look at how it is
> > implemented in 7.3 and migrate it or see how other functions who do
> > similar functionality works and port it.
>
> When merging the patch with the older code I was fairly sure that it did
> exist already in 7.2 ... but until I can get php-src synced I'm having
> to manually scan for this stuff ... at the current rate hg-git will take
> 24 days so now I need another plan of attack :(
>

Why are you making it so complicated? php-src has a definition of the
macros, its easy to look up on github.com/php/php-src, just copy this into
the file that uses GC_ADDREF/DELREF above the usage:

#ifndef GC_ADDREF
#define GC_ADDREF(p) (GC_REFCOUNT(p)++)
#endif
#ifndef GC_DELREF
#define GC_DELREF(p) (GC_REFCOUNT(p)--)
#endif


> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - https://lsces.co.uk
> EnquirySolve - https://enquirysolve.com/
> Model Engineers Digital Workshop - https://medw.co.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Firebird - Who are WE ...

[Kalle Sommer Nielsen]

Lester

lør. 23. mar. 2019 kl. 15.16 skrev Lester Caine :

> On 23/03/2019 12:47, Joe Watkins wrote:
> > The thing is broken
>
> The BLOODY THING IS WORKING PERFECTLY ... what is broken is something
> that simply currently necessitates using the resource that has already
> been created rather than trying to connect again. The correct response
> to someone complaining about it is as with many other things in PHP
> simply to explain they are doing it wrong anyway.


This kind of behavior does not belong here in any possible way, and it does
not win you any points in favor. Take the rest of the evening off the
computer if you cannot handle the reality and issues that is present here
in the ext/interbase debate.
-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

Re: [PHP-DEV] Firebird - Who are WE ...

[Lester Caine]

On 23/03/2019 12:46, Kalle Sommer Nielsen wrote:

Now to get back to working out why Nikita's patch does not work in
7.2.16 ...

Obviously because the patch was made for PHP 7.3. Hint: If a
macro/function is not available in 7.2, then look at how it is
implemented in 7.3 and migrate it or see how other functions who do
similar functionality works and port it.


When merging the patch with the older code I was fairly sure that it did 
exist already in 7.2 ... but until I can get php-src synced I'm having 
to manually scan for this stuff ... at the current rate hg-git will take 
24 days so now I need another plan of attack :(


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Firebird - Who are WE ...

[Joe Watkins]

No it is not, if it were, it would not need patching, it would not be doing
illegal things in ZTS mode and I wouldn't be getting shouted at by someone
not qualified to say if it works or not.

Consider me out of this conversation.

On Sat, 23 Mar 2019, 14:16 Lester Caine,  wrote:

> On 23/03/2019 12:47, Joe Watkins wrote:
> > The thing is broken
>
> The BLOODY THING IS WORKING PERFECTLY ... what is broken is something
> that simply currently necessitates using the resource that has already
> been created rather than trying to connect again. The correct response
> to someone complaining about it is as with many other things in PHP
> simply to explain they are doing it wrong anyway.
>
> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - https://lsces.co.uk
> EnquirySolve - https://enquirysolve.com/
> Model Engineers Digital Workshop - https://medw.co.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
>

Re: [PHP-DEV] Firebird - Who are WE ...

[Lester Caine]

On 23/03/2019 12:47, Joe Watkins wrote:

The thing is broken


The BLOODY THING IS WORKING PERFECTLY ... what is broken is something 
that simply currently necessitates using the resource that has already 
been created rather than trying to connect again. The correct response 
to someone complaining about it is as with many other things in PHP 
simply to explain they are doing it wrong anyway.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Firebird - Who are WE ...

[Joe Watkins]

You say lots of people are relying on it, but it is only you who speaks in
support of it. The thing is broken, it does bad things, there is no
maintainer, and not a huge userbase.

It's not the case that we are just kicking it out for convenience, it is
the case that we cannot keep it in phpsrc with no maintainer and no
userbase, and no good reason for it to be in phpsrc.

The thing is more or less abandoned, and at this point, since it needs work
and a maintainer, the best thing to do is move it to PECL to free it from
the release cycle of PHP so that anyone may work on it and start creating
releases at their own pace, one that suits the community you say are using
it.

Cheers
Joe

On Sat, 23 Mar 2019, 13:36 Lester Caine,  wrote:

> On 23/03/2019 12:05, Kalle Sommer Nielsen wrote:
> > 80% of this posting is more a personal blog of how you (not "we") have
> > been interacting with the PHP community (as in the PHP.net community
> > specifically). What you should have done was to reply to either me or
> > Dan in the RFC thread with a one liner: "I mean 'We' as in X", that
> > would have been it.
>
> We as in the people who rally around when we need to to protect the
> things we think are important. There are more people today reliant on
> elements like Firebird than there were 20+ years ago and to be honest if
> you kick the interbase driver into PECL we will carry on using it
> anyway, but YES it needs some love - from someone who can navigate
> around just how resources have been changed in PHP7. The sort of
> cooperation we had while keeping several extensions available on windows
> in the past. I'm perfectly happy that I am not the only person using PHP
> with Firebird  and reliant on it continuing to be available!
>
> Now to get back to working out why Nikita's patch does not work in
> 7.2.16 ...
>
> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - https://lsces.co.uk
> EnquirySolve - https://enquirysolve.com/
> Model Engineers Digital Workshop - https://medw.co.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Firebird - Who are WE ...

[Kalle Sommer Nielsen]

Hi

Den lør. 23. mar. 2019 kl. 14.36 skrev Lester Caine :
> We as in the people who rally around when we need to to protect the
> things we think are important. There are more people today reliant on
> elements like Firebird than there were 20+ years ago and to be honest if
> you kick the interbase driver into PECL we will carry on using it
> anyway, but YES it needs some love - from someone who can navigate
> around just how resources have been changed in PHP7. The sort of
> cooperation we had while keeping several extensions available on windows
> in the past. I'm perfectly happy that I am not the only person using PHP
> with Firebird  and reliant on it continuing to be available!

The point of putting it in PECL is for you to keep using it, if we (We
as in the PHP Development Team) did not care, it would have probably
have been removed entirely, which I personally do not believe is fair.

It is fine that you rally together, however it does not mean that we
(We as in the PHP Development Team) will change our stance unless you
bring someone to take over the extension.

To me personally, I will not halt the start of the vote unless there
is someone who stands up to take over the extension and posts some
relevant patches for it within the next 2 weeks (ish) to get it
working. We (we as in the PHP Development Team), will gladly do what
we can to welcome that aid, but after all this back and fourth and
lack of extension maintainer, I do not want to take the risk of
repeating the same loop once more, there has to be a limit.

> Now to get back to working out why Nikita's patch does not work in
> 7.2.16 ...

Obviously because the patch was made for PHP 7.3. Hint: If a
macro/function is not available in 7.2, then look at how it is
implemented in 7.3 and migrate it or see how other functions who do
similar functionality works and port it.


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] Firebird - Who are WE ...

[Lester Caine]

On 23/03/2019 12:05, Kalle Sommer Nielsen wrote:

80% of this posting is more a personal blog of how you (not "we") have
been interacting with the PHP community (as in the PHP.net community
specifically). What you should have done was to reply to either me or
Dan in the RFC thread with a one liner: "I mean 'We' as in X", that
would have been it.


We as in the people who rally around when we need to to protect the 
things we think are important. There are more people today reliant on 
elements like Firebird than there were 20+ years ago and to be honest if 
you kick the interbase driver into PECL we will carry on using it 
anyway, but YES it needs some love - from someone who can navigate 
around just how resources have been changed in PHP7. The sort of 
cooperation we had while keeping several extensions available on windows 
in the past. I'm perfectly happy that I am not the only person using PHP 
with Firebird  and reliant on it continuing to be available!


Now to get back to working out why Nikita's patch does not work in 
7.2.16 ...


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Firebird - Who are WE ...

[Kalle Sommer Nielsen]

Hi

Den lør. 23. mar. 2019 kl. 11.28 skrev Lester Caine :
>
> Over twenty years ago Borland took over Ashton Tate to bring dBase into
> the Borland tool set. What they did not appreciate at the time was that
> Ashton Tate had taken over Interbase to provide a proper multi-user
> database engine to augment dbase. The bean counters at Borland decided
> there was no margin in the Interbase part of Ashton Tate and announced
> it would be end of lifed! They did not appreciate at the time just how
> many people had moved from dbase over to Interbase and how many
> businesses were then reliant on it. In a knee jerk reaction to calm
> things down they offered to open source the code ... and long story
> short Firebird came into existence. The bean counters THEN began to
> realise what a cash cow Interbase could become or rather could have
> become so the end of life was rescinded, but the the cat was already out
> of the bag.
>
> Roll forward 10 or so years and PHP drops the Interbase driver from the
> windows builds. Well actually there were no official windows builds so
> we had to rally around and provide them, but the drive to sort out
> building PHP on the newer windows compile stacks saw the interbase
> driver pushed to the side "because Firebird did not support compatible
> builds!". So we just carried on providing them outside the PHP project
> along with other key elements like imagick!
>
> The key reason for not allowing Firebird into windows builds was that
> it's client library was no compatible with the build set and that
> Firebird needed to be compiled with the same version of windows
> compiler. This did not make sense then just as it does not now. A
> database engine is a stand alone section of code and may well be running
> on a completely different machine so why should the version of windows
> used make any difference ... if the server is on Linux? The important
> bit is that the LOCAL client program can be linked to the local user -
> in this case PHP. With the windows setup the interbase extension paired
> with the firebird client and all that needed to be done to access a
> newer Firebird server was to load the newer client onto the machine. The
> link between the interbase extension and the firebird client has not
> changed in many years. So today to switch from PHP connecting to a
> production FB2.1 or FB2.5 to an FB3 machine we simply install the
> correct client and do nothing with the interbase extension.
>
> Today there are problems IN the interbase extension caused by the way
> PHP now handles a 'resource' such as a database connection. Firebird
> (and Interbase) has the ability to create transactions between two or
> more active connections and commit or roll back all as required. PDO
> does not allow multiple connections at all so there is no way to action
> it via PDO so the interbase extension is the only way to access it. I
> think that part of the problem of the way the resource handling has been
> updated in the extension is down to not understanding this element and
> yes someone who understands firebird needs to maintain this but it's the
> way that PHP has changed the API which also needs to be understood.
>
> *I* have tried to keep up to speed with the PHP side of things, but
> having submitted fixes in the past, trying to decipher what Nikita is
> trying to do in this latest patch is difficult looking at the code in
> isolation since there are lots of 'system' calls that I don't follow.
> Personally I don't need more than a single link to a single database so
> everything still works for me anyway, but with persistent connections I
> presume the resource links should be managed at a higher level anyway?
>
> On my own development platform I think using hg-git to access the
> php-src repository is now impossible. Since yesterday afternoon I've
> downloaded 896 commits of the 24601 I'm behind, so while THG works
> perfectly for all the key components such as ADOdb, smarty and ckeditor,
> if I'm going to work with php code I'm going to have to bypass that!
> Which is yet another learning curve when the one I am on works well to
> provide the input that I do provide.
>
> ADOdb has been kept up to date with the changes in questions and results
> passed over the link but to date nothing major has changed in 20+ years
> in the process of sending a query to the database and getting a result
> set back ... although handing the new authentication methods added in
> FB3 may benefit from a major rebuild of the extension, which WOULD
> require that the fbird_ aliases are moved to their own build of the
> extension, being completely incompatible with current builds of Interbase.

I read this 800+ novel of words, and I still do not understand who
"we" are. Like are you kidding me, honestly. Can't you just say
whether it is "we" as in:

- The Firebird community
- The Interbase community
- or a combination?
- Borland?
- Aston Tate?
- The dBase developers?

80% of this posting is more a 

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Lester Caine]

On 22/03/2019 16:25, Nikita Popov wrote:

I've created a patch forhttps://bugs.php.net/bug.php?id=72175  (last
comment), which seems to be the biggest open problem in the interbase
extension. I'd appreciate it if you or someone else who uses firebird could
test this.


OK now got a test framework on the development machine where I can check 
things out. As expected, starting two connections to two different 
databases just works and simply copying $link to $link1 works as one 
would expect. But trying to create a second connection to the same 
database is currently giving me a crash and 'undefined symbol: 
GC_ADDREF' So I need to tidy up the patch to work with 7.2.16 :(


The other part of the jigsaw is working out the significance of the 
'default_link' in the code. And I'm taking this back to the firebird 
developers to check something out. As far as I am aware the firebird 
CLIENT will reuse an active connection to the database, but if one 
creates several connections in PHP and a couple end up linking to the 
same database where does a default one come into the picture. I think 
the code is basing decisions on the first connection made? Rather than 
the poll of active connections ...


As stated in the bug report, there is no need to reconnect to the same 
database, but there will be a default transaction for the connection 
which requires explicit transactions to be handled and this may be why 
there is thought to be a need to open new connections when one simply 
manages extra transactions on the same link. Working of a singleton link 
just works and so in that case the bug is irrelevant rather than a show 
stopper.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Offset-only results from preg_match

[Nikita Popov]

On Sat, Mar 23, 2019 at 6:32 AM C. Scott Ananian 
wrote:

> So...
>
> In microbenchmarks you can clearly see the improvement:
> ```
> >>> timeit -n500 preg_match_all('/(.{65535})/s', $html100, $m,
> PREG_OFFSET_CAPTURE);
> => 39
> Command took 0.001709 seconds on average (0.001654 median; 0.854503 total)
> to complete.
> >>> timeit -n500 preg_match_all('/(.{65535})/s', $html100, $m,
> PREG_OFFSET_CAPTURE|PREG_LENGTH_CAPTURE);
> => 39
> Command took 0.000991 seconds on average (0.000965 median; 0.495287 total)
> to complete.
> ```
> $html100 is my usual 2,592,386 byte HTML of [[en:Barack Obama]].
>
> But unless you're matching 64k strings like this, it's hard to see a
> practical improvement.  In my remex-html html parsing benchmark, although
> LENGTH_CAPTURE doesn't make things slower, it doesn't make a significant
> performance improvement.  I built php statically and ran it through
> cachegrind to try to figure out why, and found:
>
> 2,567,559,670 cycles: total spent executing the tokenizer benchmark
> (including reading the file from disk)
> 1,018,845,290 cycles in zif_preg_match.  Optimizing regexps is important
> for tokenizers! Of these, we spend
>   575,478,637 doing the actual match (preg_pcre_match_impl) and
>   435,162,131 getting the regexp from the cache (!)
> (pcre_get_compiled_regex_cache)
>
> This is for 128,794 total regexp matches performed by the tokenizer on
> this input.
>
> Of those cycles getting the regex from cache, only 24,116,319 are spent on
> cache misses where we are actually compiling regexps (sum of
> php_pcre2_jit_compile and php_pcre2_compile).
> Instead, 406,007,383 cycles are spent in zend_hash_find().  That's 40% of
> the total time spent executing preg_match.
>
> The LENGTH_CAPTURE optimization does reduce the total time spent in
> populate_subpat_array from 160,951,690 cycles to 140,042,331 cycles in the
> remex-html tokenizer on this benchmark, but that difference is overwhelmed
> by (for example) the time spent in zend_hash_find().
>
> The slowdown in zend_hash_find() appears to be due to
> https://bugs.php.net/bug.php?id=63180 which disabled interned keys in the
> pcre_cache table.  Because of this, even if the regexs are interned, we
> must pay for a complete zend_string_equal_content() on each match, which
> takes time proportional to the length of the regex.  This can be quite
> large -- for example, for the HTML5 character reference regex in
> remex-html, which contains every valid entity name and is 26,137 bytes
> long, and we need to do a zend_string_equal_content() on the 26,137 byte
> regexp for every ~5 byte entity in the parsed HTML.
>   --scott
>

Thanks for testing! That's an interesting result. We should be able to do
something about this. There are basically three cases:

1. CLI (presumably what you're testing). Strings are interned per-request,
but there is only one request.
2. Server w/o opcache. Strings are interned per-request and there may be
multiple requests.
3. Server with opcache. Strings are interned permanently in opcache.

Case 3 should already be fast, because permanent interned strings are
allowed into the regex cache. We can optimize case 1 by simply allowing
arbitrary cache keys and discarding the cache in RSHUTDOWN -- it will not
be needed anymore anyway. Case 2 would remain slow, but it's slow anyway...

Nikita


> On Thu, Mar 21, 2019 at 7:35 AM Nikita Popov  wrote:
>
>> On Wed, Mar 20, 2019 at 4:35 PM C. Scott Ananian 
>> wrote:
>>
>>> On Tue, Mar 19, 2019 at 10:58 AM Nikita Popov 
>>> wrote:
>>>
 After thinking about this some more, while this may be a minor
 performance improvement, it still does more work than necessary. In
 particular the use of OFFSET_CAPTURE (which would be pretty much required
 here) needs one new two-element array for each subpattern. If the captured
 strings are short, this is where the main cost is going to be.

>>>
>>> The primary use of this feature is when the captured strings are *long*,
>>> as that's when we most want to avoid copying a substring.
>>>
>>>
 I'm wondering if we shouldn't consider a new object oriented API for
 PCRE which can return a match object where subpattern positions and
 contents can be queried via method calls, so you only pay for the parts
 that you do access.

>>>
>>> Seems like this is letting the perfect be the enemy of the good.  The
>>> LENGTH_CAPTURE significantly reduces allocation for long match strings, and
>>> it allocates the same two-element arrays that OFFSET_CAPTURE would -- it
>>> just stores an integer where there would otherwise be an expensive
>>> substring.  Furthermore, since the array structure is left mostly alone, it
>>> would be not-too-hard to support earlier-PHP versions, with something like:
>>>
>>> $hasLengthCapture = defined('PREG_LENGTH_CAPTURE') ? PREG_LENGTH_CAPTURE
>>> : 0;
>>> $r = preg_match($pat, $sub, $m, PREG_OFFSET_CAPTURE | $hasLengthCapture);
>>> $matchOneLength = $hasLengthCapture ? $m[1][0] 

Re: [PHP-DEV] [RFC] DOM Living Standard API

[Benjamin Eberlei]

On Fri, Mar 22, 2019 at 11:26 PM Claude Pache 
wrote:

> Beware that behaviour of some methods should differ between HTML and
> non-HTML documents. For instance, the RFC says:
>
> > DOMElement→nodeName casing was previously undefined, it is now changed
> to always uppercase.
>
> However, the DOM Living Standard says it is uppercase (even,
> ASCII-uppercased) only in the HTML namespace. For XML documents, the casing
> is not modified.
>

You are absolutely right, i missed that in the convoluted description of
the behavior :-) I need to rethink how this would fit with the
compatibility flags, it might cause a problem given that loadHTML for
example doesn't automatically put the elements into HTML namespace. I
updated the RFC to reflect this.

To be honest, the compatibility thing is what i am least sure in,
especially if this should be combined with the new methods + removal of
unused code or should be handled separately.


> —Claude
>
>

[PHP-DEV] Firebird - Who are WE ...

[Lester Caine]

Over twenty years ago Borland took over Ashton Tate to bring dBase into 
the Borland tool set. What they did not appreciate at the time was that 
Ashton Tate had taken over Interbase to provide a proper multi-user 
database engine to augment dbase. The bean counters at Borland decided 
there was no margin in the Interbase part of Ashton Tate and announced 
it would be end of lifed! They did not appreciate at the time just how 
many people had moved from dbase over to Interbase and how many 
businesses were then reliant on it. In a knee jerk reaction to calm 
things down they offered to open source the code ... and long story 
short Firebird came into existence. The bean counters THEN began to 
realise what a cash cow Interbase could become or rather could have 
become so the end of life was rescinded, but the the cat was already out 
of the bag.


Roll forward 10 or so years and PHP drops the Interbase driver from the 
windows builds. Well actually there were no official windows builds so 
we had to rally around and provide them, but the drive to sort out 
building PHP on the newer windows compile stacks saw the interbase 
driver pushed to the side "because Firebird did not support compatible 
builds!". So we just carried on providing them outside the PHP project 
along with other key elements like imagick!


The key reason for not allowing Firebird into windows builds was that 
it's client library was no compatible with the build set and that 
Firebird needed to be compiled with the same version of windows 
compiler. This did not make sense then just as it does not now. A 
database engine is a stand alone section of code and may well be running 
on a completely different machine so why should the version of windows 
used make any difference ... if the server is on Linux? The important 
bit is that the LOCAL client program can be linked to the local user - 
in this case PHP. With the windows setup the interbase extension paired 
with the firebird client and all that needed to be done to access a 
newer Firebird server was to load the newer client onto the machine. The 
link between the interbase extension and the firebird client has not 
changed in many years. So today to switch from PHP connecting to a 
production FB2.1 or FB2.5 to an FB3 machine we simply install the 
correct client and do nothing with the interbase extension.


Today there are problems IN the interbase extension caused by the way 
PHP now handles a 'resource' such as a database connection. Firebird 
(and Interbase) has the ability to create transactions between two or 
more active connections and commit or roll back all as required. PDO 
does not allow multiple connections at all so there is no way to action 
it via PDO so the interbase extension is the only way to access it. I 
think that part of the problem of the way the resource handling has been 
updated in the extension is down to not understanding this element and 
yes someone who understands firebird needs to maintain this but it's the 
way that PHP has changed the API which also needs to be understood.


*I* have tried to keep up to speed with the PHP side of things, but 
having submitted fixes in the past, trying to decipher what Nikita is 
trying to do in this latest patch is difficult looking at the code in 
isolation since there are lots of 'system' calls that I don't follow. 
Personally I don't need more than a single link to a single database so 
everything still works for me anyway, but with persistent connections I 
presume the resource links should be managed at a higher level anyway?


On my own development platform I think using hg-git to access the 
php-src repository is now impossible. Since yesterday afternoon I've 
downloaded 896 commits of the 24601 I'm behind, so while THG works 
perfectly for all the key components such as ADOdb, smarty and ckeditor, 
if I'm going to work with php code I'm going to have to bypass that! 
Which is yet another learning curve when the one I am on works well to 
provide the input that I do provide.


ADOdb has been kept up to date with the changes in questions and results 
passed over the link but to date nothing major has changed in 20+ years 
in the process of sending a query to the database and getting a result 
set back ... although handing the new authentication methods added in 
FB3 may benefit from a major rebuild of the extension, which WOULD 
require that the fbird_ aliases are moved to their own build of the 
extension, being completely incompatible with current builds of Interbase.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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