[PHP-DEV] nntp 2 mail gateway for internals broken
I was always using nntp://news.php.net to reply to messages in the Internals list. Sad thing: the syncing from the newsserver to the mailinglist is currently broken. If that is a permanent situation the newsserver shuld be rejecting usenet posts, like AFAIK php.internals.win does. Otherwise could somebody fix the nntp 2 mail sync? -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
On 2019-10-23 07:01, Jan Ehrhardt wrote: On 2019-10-23 06:36, Helmut K. C. Tessarek wrote: On 2019-10-23 00:28, Jan Ehrhardt wrote: It worked in my PHP 7.2 when I added '-pthread' to CFLAGS: https://news-web.php.net/php.internals/107632 Hmm, CFLAGS shouldn't be used for linker flags. It should be added to LDFLAGS. In either case, it's possible that it works with those, but I was talking about OPENSSL_LIBS, which was suggested by Nikita and Rainer. I was just following Nikita's example by using '-pthread' in CFLAGS: https://news-web.php.net/php.internals/107632 Correct reference should be https://news-web.php.net/php.internals/107541 It gets confusing when one is following internals via various interfaces. -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
On 2019-10-23 06:36, Helmut K. C. Tessarek wrote: On 2019-10-23 00:28, Jan Ehrhardt wrote: It worked in my PHP 7.2 when I added '-pthread' to CFLAGS: https://news-web.php.net/php.internals/107632 Hmm, CFLAGS shouldn't be used for linker flags. It should be added to LDFLAGS. In either case, it's possible that it works with those, but I was talking about OPENSSL_LIBS, which was suggested by Nikita and Rainer. I was just following Nikita's example by using '-pthread' in CFLAGS: https://news-web.php.net/php.internals/107632 -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
On 2019-10-23 00:28, Jan Ehrhardt wrote: > It worked in my PHP 7.2 when I added '-pthread' to CFLAGS: > https://news-web.php.net/php.internals/107632 Hmm, CFLAGS shouldn't be used for linker flags. It should be added to LDFLAGS. In either case, it's possible that it works with those, but I was talking about OPENSSL_LIBS, which was suggested by Nikita and Rainer. Anyway, I'm very happy that it works now. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
On 2019-10-23 06:17, Helmut K. C. Tessarek wrote: On 2019-10-23 00:03, Jan Ehrhardt wrote: That is more or less the same answer I posted 13 hours earlier https://news-web.php.net/php.internals/107628 Darn, that would have saved me a lot of time... ;-) Yes. Really bad that nntp://news.php.net, https://external.io and the mailing list are not in sync anymore. First time I experienced that. BTW: should not that be '-pthread' in stead of '-lpthread'? It was stripped from OPENSSL_LIBS as found by Nikita: https://news-web.php.net/php.internals/107543 Yep, I tried that too. But it didn't work. At least not on 7.2. It worked in my PHP 7.2 when I added '-pthread' to CFLAGS: https://news-web.php.net/php.internals/107632 -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
On 2019-10-23 00:03, Jan Ehrhardt wrote: > That is more or less the same answer I posted 13 hours earlier > https://news-web.php.net/php.internals/107628 Darn, that would have saved me a lot of time... ;-) > BTW: should not that be '-pthread' in stead of '-lpthread'? It was > stripped from OPENSSL_LIBS as found by Nikita: > https://news-web.php.net/php.internals/107543 Yep, I tried that too. But it didn't work. At least not on 7.2. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
"Helmut K. C. Tessarek" in php.internals (Tue, 22 Oct 2019 22:33:39 -0400): >Eureka! > >After a few more hours of trial and error I managed to get it working. > >However, the `-lpthread` in OPENSSL_LIBS is ignored. I checked the config.log, > but it wasn't added to the linker command. But adding it to LIBS solved the >issue. > >This is the command that finally worked: > >./configure [snip] --with-openssl=/usr/local/ssl-1.1.1 [snip] >CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib LIBS="-lpthread" >OPENSSL_LIBS="-L/usr/local/ssl-1.1.1/lib -l:libssl.a -l:libcrypto.a -ldl >-lpthread" OPENSSL_CFLAGS="-I/usr/local/ssl-1.1.1/include" That is more or less the same answer I posted 13 hours earlier https://news-web.php.net/php.internals/107628 Too bad it did not bave seemed to reach the mailinglist and/or https://externals.io/message/103582 Frustrating that https://news-web.php.net/php.internals is not in sync with the mailinglist and/or https://externals.io/ BTW: should not that be '-pthread' in stead of '-lpthread'? It was stripped from OPENSSL_LIBS as found by Nikita: https://news-web.php.net/php.internals/107543 -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
Eureka! After a few more hours of trial and error I managed to get it working. However, the `-lpthread` in OPENSSL_LIBS is ignored. I checked the config.log, but it wasn't added to the linker command. But adding it to LIBS solved the issue. This is the command that finally worked: ./configure [snip] --with-openssl=/usr/local/ssl-1.1.1 [snip] CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib LIBS="-lpthread" OPENSSL_LIBS="-L/usr/local/ssl-1.1.1/lib -l:libssl.a -l:libcrypto.a -ldl -lpthread" OPENSSL_CFLAGS="-I/usr/local/ssl-1.1.1/include" I will also update the bug, so that people have this info on file as a reference. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
Jan Ehrhardt in php.internals (Tue, 22 Oct 2019 15:04:20 +0200): >With at least bison 3.0 and re2c 3.14.1 installed this seens to >work with PHP 7.4.0RC4: > >#!/bin/sh >./configure \ >--with-config-file-scan-dir=/usr/local/lib/php.conf.d \ >--disable-all \ >--with-openssl-dir=/usr/local/ssl-1.1.1 \ >--with-openssl=/usr/local/ssl-1.1.1 \ >CFLAGS=" -I/usr/local/ssl-1.1.1/include " \ >OPENSSL_LIBS="-ldl -pthread -L/usr/local/ssl-1.1.1/lib -l:libssl.a >-l:libcrypto.a" For PHP 7.2 and 7.3 you'll have to replace --with-openssl by --with-openssl=/usr/local/ssl-1.1.1 \ --with-openssl-dir=/usr/local/ssl-1.1.1 \ CFLAGS="-pthread -I/usr/local/ssl-1.1.1/include" \ OPENSSL_LIBS="-ldl -pthread -L/usr/local/ssl-1.1.1/lib -l:libssl.a -l:libcrypto.a" \ Note that the '-pthread' was added to the CFLAGS line as well, because it was stripped out of the OPENSSL_LIB definition. This was fixed by Nikita in PHP 7.4, but that fix was not backported to earlier versions. # /usr/local/php72/bin/php -i | grep OpenSSL SSL Version => OpenSSL/1.0.1e-fips OpenSSL support => enabled OpenSSL Library Version => OpenSSL 1.1.1d 10 Sep 2019 OpenSSL Header Version => OpenSSL 1.1.1d 10 Sep 2019 OpenSSL support => enabled The first line with 'OpenSSL/1.0.1e-fips' is what the curl extension reports. I will have to update that as well to OpenSSL 1.1.1 (static). -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions
On Tue, 22 Oct 2019 at 14:38, Benjamin Morel wrote: > > I used this one function as an example, but I'm happy to apply my point of > view to other examples if you wish. > You have phrased this as though your point of view is different from mine, but I think you've just misunderstood it. I said: > All of these are candidates for returning false, or an error code, or an object in a particular status. That's precisely what your examples show: the functions returning false. So we're in agreement, some errors should become exceptions, others should be handled a different way, and some cases need new functions. > This proposal would be as good under the form of a new API though, but in > this case the naming should be changed to clearly differentiate both APIs. > Yes, new names is almost entirely the point of "a new API". The idea is that you don't have to recalibrate people's expectations of what fopen() does, breaking thousands of lines of existing code, nor compromise the design to minimise that impact. Instead, you say "here's a new function, it has these nice features, and handles errors in this really smooth way, please use it" - and more importantly, "here's a consistent set of functions which all work in this same way, please use them". Finally, to reiterate what's been said several times, there are definitely functions where the error cases are so "exceptional", that just throwing an exception would be perfectly fine. It's the commonly used sets of functions with a variety of different error conditions and use cases, like file handling, where more careful redesign is prudent. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] Reclassifying some PHP functions warning as exceptions
@Mike,
> Then about a year ago I started using Go, and Go's approach to error
> handling just clicked for me. Go's philosophy is to handle the error as
> soon as you one is aware of it and to only ever handle it once. Since I
> have been using that strategy I have become very happy with my error
> handling, and I now (attempt) to use the same strategy in my PHP code.
> So what I am hoping for is that PHP recognizes there are two strategies
> for error handling — 1. Throwing exceptions vs. 2. Returning error values —
> and that PHP 8.0 and behind will respect programmers and allow them to
> embrace the strategy they feel is best for their use-case.
I do see some value in the way Go handles errors (i.e. forcing you to deal
with them), especially the *expected* ones; the issue, if I'm not mistaken,
is how you deal with *unexpected* errors. AFAICS, this forces you to either
return it to the caller (which may not expect this error), or wrap it in a
more specific error that's part of your function's contract, which is
pretty much what you do with exception chaining. I don't have a hands-on
experience with Go, though, so I may have missed something. Please do
correct me if/where needed.
@Rowan,
You've backed that up with exactly one example function, and immediately
> concede a case where you might want a non-exception flow. Here are a
> handful more examples off the top of my head:
> * Attempt to atomically lock and open file, returning either a file
> handle or a "could not lock" status.
> * Attempt to read from a file, terminate loop when the file handle
> reaches EOF.
> * Attempt to delete file, ignore if it doesn't exist.
> All of these are candidates for returning false, or an error code, or an
> object in a particular status. They could be handled with exceptions,
> but that would force common patterns to use exceptions for flow control,
> which is generally seen as a "bad smell".
I used this one function as an example, but I'm happy to apply my point of
view to other examples if you wish. I'll take yours above, in reverse order:
*- Attempt to delete file, ignore if it doesn't exist:*
unlink($file): bool; // true if the file was deleted, false if it didn't
exist; exception on other errors
As I see it, the only safe-to-ignore error is "the file does not exist"
(non-exceptional error), as the outcome is the same whatever the return
value: the file does not exist (anymore).
Any other error should, IMO, be treated as exceptional and throw.
*- Attempt to read from a file, terminate loop when the file handle reaches
EOF:*
I think the current API is already quite good at that, it just needs a bit
of polish in the way it handles errors:
while (! feof($fp)) $block = fread($fp, 4096);
feof($fp): bool; // true if EOF, false if not; exception on error
fread($fp): string; // the data, empty string if EOF (non-exceptional);
exception on error
I don't see much value in doing something like:
for (;;) {
$result = fread($fp, 4096);
if ($result->isEOF) break;
if ($result->error) {
// ...
}
$block = $result->data;
}
*- Attempt to atomically lock and open file, returning either a file handle
or a "could not lock" status:*
fopen_and_lock($fp); // true if lock was acquired, false if not; exception
on error
This one is trickier, as the outcome is roughly the same (the file was
open) but maybe the lock failed to acquire. I can't say if I would return
bool, or void and an exception on failure-to-acquire.
Don't get me wrong, I respect your points of view, they are perfectly
valid, and as such I'm not trying to push exceptions over anything else;
but I don't personally see them as bad at all, they're actually quite
convenient if used properly. I do see some value in returning errors, too,
but with the strong caveat expressed below, that may severely affect
inexperienced, or, should I say it, lazy developers. I like the exception
model, breaking the program flow by default if unhandled. This makes an app
much more reliable *by default* IMHO.
Therefore I do like the original proposal, even if I can hardly imagine it
overcome the usual resistance here.
This proposal would be as good under the form of a new API though, but in
this case the naming should be changed to clearly differentiate both APIs.
I wish you luck, @David, anyway.
— Benjamin
On Mon, 21 Oct 2019 at 23:59, Rowan Tommins wrote:
> On 21/10/2019 21:38, Benjamin Morel wrote:
> > Sure, you can do without exceptions. I think what you're suggesting is
> > similar to Go's error handling. But PHP at some point decided in
> > favour of exceptions, so it would be logical to pursue in that direction.
>
>
> I didn't say "do without exceptions", I said "use exceptions when
> they're the right tool, and other tools at other times".
>
>
> > I would classify most, if not all, filesystem-related functions as
> > mostly "yes, do stop execution by default when something fails". So
> > this is, as well, in favour of exceptions.
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
Jan Ehrhardt in php.internals (Tue, 22 Oct 2019 15:04:20 +0200): >With at least bison 3.0 and re2c 3.14.1 installed this seems to >work with PHP 7.4.0RC4: [snip] With some modules enabled: #!/bin/sh ./configure \ --disable-all \ --with-openssl-dir=/usr/local/ssl-1.1.1 \ --with-openssl=/usr/local/ssl-1.1.1 \ CFLAGS="-I/usr/local/ssl-1.1.1/include" \ OPENSSL_LIBS="-ldl -pthread -L/usr/local/ssl-1.1.1/lib -l:libssl.a -l:libcrypto.a" \ --with-apxs2 \ --enable-pdo \ --with-mhash \ --with-mysql-sock=/var/lib/mysql/mysql.sock \ --with-mysqli=mysqlnd \ --with-pcre-regex=/usr/local \ --with-pdo-mysql=mysqlnd \ --with-png-dir=/usr/local/lib \ --with-webp-dir=/usr/local/lib \ --with-zlib \ --enable-zip \ --enable-bcmath \ --enable-calendar \ --enable-ftp \ --enable-sockets \ --with-gd \ --with-gettext \ --with-jpeg-dir=/usr/local/lib \ --with-freetype-dir=/usr/local/lib -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
"Helmut K. C. Tessarek" in php.internals (Mon, 21 Oct 2019 23:34:58 -0400): >On 2019-10-14 05:46, Nikita Popov wrote: >> This should be fixed with >> https://github.com/php/php-src/commit/c518932c0326a938f0fd0254f2adb03b1cddfbca. >> Now using just >> >> ./configure --disable-all --with-openssl OPENSSL_LIBS="-l:libssl.a >> -l:libcrypto.a -ldl -pthread" >> >> works for me. > >Hmm, I can't get it to work. My ssl is in: /usr/local/ssl-1.1.1 With at least bison 3.0 and re2c 3.14.1 installed this seens to work with PHP 7.4.0RC4: #!/bin/sh ./configure \ --with-config-file-scan-dir=/usr/local/lib/php.conf.d \ --disable-all \ --with-openssl-dir=/usr/local/ssl-1.1.1 \ --with-openssl=/usr/local/ssl-1.1.1 \ CFLAGS=" -I/usr/local/ssl-1.1.1/include " \ OPENSSL_LIBS="-ldl -pthread -L/usr/local/ssl-1.1.1/lib -l:libssl.a -l:libcrypto.a" Tested on Centos 6: # sapi/cli/php -i | grep OpenSSL OpenSSL support => enabled OpenSSL Library Version => OpenSSL 1.1.1d 10 Sep 2019 OpenSSL Header Version => OpenSSL 1.1.1d 10 Sep 2019 # ldd sapi/cli/php linux-vdso.so.1 => (0x7ffee71a5000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f1341764000) libresolv.so.2 => /lib64/libresolv.so.2 (0x7f134154a000) librt.so.1 => /lib64/librt.so.1 (0x7f1341342000) libm.so.6 => /lib64/libm.so.6 (0x7f13410be000) libdl.so.2 => /lib64/libdl.so.2 (0x7f1340eba000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f1340c9d000) libz.so.1 => /usr/local/lib/libz.so.1 (0x7f1340a81000) libc.so.6 => /lib64/libc.so.6 (0x7f13406ed000) /lib64/ld-linux-x86-64.so.2 (0x7f134199b000) libfreebl3.so => /lib64/libfreebl3.so (0x7f13404ea000) -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Union Types v2
Hi Nikita, Can you please give me one/two days, before starting the voting, for implementation review (at least until October 25), Thanks. Dmitry. From: Nikita Popov Sent: Tuesday, October 22, 2019 12:36 To: PHP internals Subject: [PHP-DEV] Re: [RFC] Union Types v2 On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov wrote: > Hi internals, > > I'd like to start the discussion on union types again, with a new proposal: > > Pull Request: https://github.com/php/php-rfcs/pull/1 > Rendered Proposal: > https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md > > As an experiment, I'm submitting this RFC as a GitHub pull request, to > evaluate whether this might be a better medium for RFC proposals in the > future. It would be great if we could keep the discussion to the GitHub > pull request for the purpose of this experiment (keep in mind that you can > also create comments on specific lines in the proposal, not just the > overall discussion thread!) Of course, you can also reply to this mail > instead. The final vote will be held in the wiki as usual. > > Relatively to the previous proposal by Bob&Levi ( > https://wiki.php.net/rfc/union_types), I think the main differences in > this proposal are: > * Updated to specify interaction with new language features, like full > variance and property types. > * Updated for the use of the ?Type syntax rather than the Type|null > syntax. > * Only supports "false" as a pseudo-type, not "true". > * Slightly simplified semantics for the coercive typing mode. > > Regards, > Nikita > An implementation of this proposal is now available at https://github.com/php/php-src/pull/4838. As the implementation didn't turn up any new issues, I think it's time to move this RFC forward to voting. Nikita CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.
[PHP-DEV] Re: [RFC] Union Types v2
On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov wrote: > Hi internals, > > I'd like to start the discussion on union types again, with a new proposal: > > Pull Request: https://github.com/php/php-rfcs/pull/1 > Rendered Proposal: > https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md > > As an experiment, I'm submitting this RFC as a GitHub pull request, to > evaluate whether this might be a better medium for RFC proposals in the > future. It would be great if we could keep the discussion to the GitHub > pull request for the purpose of this experiment (keep in mind that you can > also create comments on specific lines in the proposal, not just the > overall discussion thread!) Of course, you can also reply to this mail > instead. The final vote will be held in the wiki as usual. > > Relatively to the previous proposal by Bob&Levi ( > https://wiki.php.net/rfc/union_types), I think the main differences in > this proposal are: > * Updated to specify interaction with new language features, like full > variance and property types. > * Updated for the use of the ?Type syntax rather than the Type|null > syntax. > * Only supports "false" as a pseudo-type, not "true". > * Slightly simplified semantics for the coercive typing mode. > > Regards, > Nikita > An implementation of this proposal is now available at https://github.com/php/php-src/pull/4838. As the implementation didn't turn up any new issues, I think it's time to move this RFC forward to voting. Nikita
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
On 2019-10-22 02:32, Rainer Jung wrote: > If you are willing for another round: > > # The next line only if configure.saved > # no longer exists from the previous try > cp -p configure configure.saved > > # The sed command here is three lines, > # the first two of them continued by a > # backslash at the end of line > sed -e 's/\(LIBS=.*\)-lssl \(.*\)/\1 -lssl -lcrypto \2/' \ > -e 's/\(LIBS=.*-lssl *-lcrypto\)\(.*\)/\1 `$PKG_CONFIG --libs --static > openssl` \2/' \ > configure.saved > configure > > If it doesn't work, then please again give us the config.log plus the "diff > configure.saved configure". It didn't work, but it can't work this way: LIBS=" -lssl -lcrypto `$PKG_CONFIG --libs --static openssl` $LIBS" This will find the system openssl and not my openssl 1.1.1. But if I set export PKG_CONFIG_PATH=/usr/local/ssl-1.1.1/lib/pkgconfig then other libraries are not found. I seriously don't understand why linking to 2 files in /usr/local/ssl-1.1.1/lib is so complicated. Apache httpd can do it. dovecot can do it. Every other software paxckage I compile can do it. PHP is the only one that fails. Once again, it does work with my other (non-system static openssl 1.0.2). I never link against the system openssl (my server has an uptime of more than 5 years), but unfortunately I can't remove it either. So if I change the path from /usr/local/ssl-1.1.1 to /usr/local/ssl (which holds my static 1.0.2 non-sysetm openssl) all works well. Anyway, here are the 2 files you requested: https://evermeet.cx/pub/logs/config.php72.2.log https://evermeet.cx/pub/logs/diff.2.patch I'm heading to bed now. Thanks for all your help so far. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
