On Mon, Oct 14, 2019 at 9:21 AM Matteo Beccati wrote:
> Hi Stas,
> > Maybe we should just change the error message to this?> > must be an
> instance of the class "resource", but resource type is
> given> > OTOH, since there are actually no resource type hints, and
> naming your> class "resource"
I am current maintainer of gcov server, I planned this kind of integration
with azure, so once again, thanks.
+1 to ditching gcov.php.net, we are terrible at infra ...
On Mon, 14 Oct 2019, 16:13 Nikita Popov, wrote:
> On Mon, Sep 30, 2019 at 2:30 PM Gerard Roche
> wrote:
>
> > > gcov.php.net u
On Mon, Sep 30, 2019 at 2:30 PM Gerard Roche
wrote:
> > gcov.php.net used to provide valgrind reports and code coverage for
> > php-src. It no longer works with 7.4/8.0, because the OS is very old, and
> > building new versions of PHP there gets very hard. The valgrind reports
> > have essentiall
Nikita Popov in php.internals (Mon, 14 Oct 2019 11:46:57 +0200):
>On Mon, Oct 14, 2019 at 11:30 AM Nikita Popov wrote:
>
>> On Mon, Oct 14, 2019 at 11:22 AM Nikita Popov
>> wrote:
>>
>>> The fact that "-pthread" gets stripped from LIBS might be a bug.
>>
>> Looks like the -pthread stripping happe
Am 14.10.2019 um 11:06 schrieb Helmut K. C. Tessarek:
Hello,
On 2019-10-14 04:12, Rainer Jung wrote:
I think what he means is doing:
Yep, I remember I had tried that as well, but I just went through it again to
get the info you requested:
export PKG_CONFIG_PATH=/usr/local/ssl-1.1.1/lib/pkgco
On Mon, Oct 14, 2019 at 11:30 AM Nikita Popov wrote:
> On Mon, Oct 14, 2019 at 11:22 AM Nikita Popov
> wrote:
>
>> On Sun, Oct 13, 2019 at 11:04 PM Helmut K. C. Tessarek <
>> tessa...@evermeet.cx> wrote:
>>
>>> On 2019-10-13 17:00, Nikita Popov wrote:
>>> > Don't know about previous versions, bu
On Mon, Oct 14, 2019 at 11:22 AM Nikita Popov wrote:
> On Sun, Oct 13, 2019 at 11:04 PM Helmut K. C. Tessarek <
> tessa...@evermeet.cx> wrote:
>
>> On 2019-10-13 17:00, Nikita Popov wrote:
>> > Don't know about previous versions, but at least on 7.4 setting
>> > OPENSSL_CFLAGS and OPENSSL_LIBS ap
On Sun, Oct 13, 2019 at 11:04 PM Helmut K. C. Tessarek
wrote:
> On 2019-10-13 17:00, Nikita Popov wrote:
> > Don't know about previous versions, but at least on 7.4 setting
> > OPENSSL_CFLAGS and OPENSSL_LIBS appropriately (e.g. using pkg-config
> > --static --cflags/--libs return values) should
Hello,
On 2019-10-14 04:12, Rainer Jung wrote:
> I think what he means is doing:
Yep, I remember I had tried that as well, but I just went through it again to
get the info you requested:
export PKG_CONFIG_PATH=/usr/local/ssl-1.1.1/lib/pkgconfig
export OPENSSL_CFLAGS="-I/usr/local/ssl-1.1.1/inclu
On that note, since traits aren't possible as a return type. Would it
be possible to determine that the given return type is a trait? In
that case a more specific error message could also be possible.
I don't know much of the internals, so i don't know if that is even
possible atm, but it would be
Am 14.10.2019 um 10:12 schrieb Rainer Jung:
Am 13.10.2019 um 23:04 schrieb Helmut K. C. Tessarek:
On 2019-10-13 17:00, Nikita Popov wrote:
Don't know about previous versions, but at least on 7.4 setting
OPENSSL_CFLAGS and OPENSSL_LIBS appropriately (e.g. using pkg-config
--static --cflags/--lib
Am 13.10.2019 um 23:04 schrieb Helmut K. C. Tessarek:
On 2019-10-13 17:00, Nikita Popov wrote:
Don't know about previous versions, but at least on 7.4 setting
OPENSSL_CFLAGS and OPENSSL_LIBS appropriately (e.g. using pkg-config
--static --cflags/--libs return values) should work. These environme
Hi!
> I was about to give my +1 on the more generic approach, but type hints
> could also be interfaces and "instance of the class X" is not a good fit.
We could use "class or interface" if that's important.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Maili
Hi!
> Recently we voted on classification criteria for security bugs [1], we
> include under "not an issue" any issue that "requires invocation of
> specific code, which may be valid but is obviously malicious".
>
> I would like to add an explicit clause under the "not an issue" section for
> any
Morning all,
Recently we voted on classification criteria for security bugs [1], we
include under "not an issue" any issue that "requires invocation of
specific code, which may be valid but is obviously malicious".
I would like to add an explicit clause under the "not an issue" section for
anythi
Hi Stas,
> Maybe we should just change the error message to this?> > must be an instance
> of the class "resource", but resource type is
given> > OTOH, since there are actually no resource type hints, and
naming your> class "resource" is an extremely bad idea, having a warning
there> wouldn't hurt
16 matches
Mail list logo
