://github.com/php/php-src/issues
PHP 8.2.24 should be expected in 2 weeks, i.e. on September 26th, 2024.
Hash values and PGP signatures can be found below or at
https://gist.github.com/adoy/bbd727508a78dd7496e092964673edfb
Thank you, and happy testing!
Regards,
Sergey Panteleev, Pierrick Charron &
Thanks Daniel for testing and Pierre for the fix :)
On 6 December 2011 10:53, Daniel Convissor wrote:
> Hi Pierre:
>
> Thanks for the quick fix. I did a make clean and vsclean then rebuilt,
> but there's a similar issue, still:
>
> /php/php-src/trunk/ext/curl/interface.c: In function
> ‘zif_cur
I added a patch to bug #60809. If it's ok I can commit it.
Pierrick
On 19 January 2012 20:55, Stas Malyshev wrote:
> Hi!
>
>
>> I would like to commit session adaption patch to 5.4, since it
>> does not change current session module behavior by default
>> and affected application can be protecte
I just open a new thread just for this bug.
If one of the RM could please confirm that I can commit the patch to
the PHP5.4 branch.
Thanks
Pierrick
Index: NEWS
===
--- NEWS(revision 322482)
+++ NEWS(working copy)
@@ -7
Hi Stas,
I did run the test of bug #55871 and got memory leaks. This patch
remove them. Could you please review the patch and if it is Ok i'll
commit it to 5.4
Thanks
Pierrick
Index: NEWS
===
--- NEWS(revision 322482)
+++ NEW
Ok i'll only commit it on trunk and 5.3 for right now and keep the
patch ready to apply. What about the other one I sent you (60809) ?
On 20 January 2012 02:10, Stas Malyshev wrote:
> Hi!
>
>
>> I did run the test of bug #55871 and got memory leaks. This patch
>> remove them. Could you please rev
Nevery mind. Apparently Dmitry committed a patch for this one.
P.
On 20 January 2012 08:04, Pierrick Charron wrote:
> Ok i'll only commit it on trunk and 5.3 for right now and keep the
> patch ready to apply. What about the other one I sent you (60809) ?
>
> On 20 January
Yes :) I sent you an other mail about this bug yesterday to confirm
that I can commit it.
P.
On 20 January 2012 13:05, Stas Malyshev wrote:
> Hi!
>
>
>> Nevery mind. Apparently Dmitry committed a patch for this one.
>
>
> I think what he committed was a patch for another problem - double free in
Hi all,
As you may know, the cURL PHP extension is currently not in sync
(featurewise) with the original libcurl. I started to work on it to
make it as close as possible from the original libcurl. I also did
some cleaning to make it easier to maintain (ordered all the
constants/features by their l
I thought about it but I think it may confuse people to have two
different extensions with the same name, same interface, but one in
pecl and one in the core package (the difference between the 2
versions are not that big). Also as ilia mentioned if someone already
have the original version, they w
We could add a flag to disable the @ usage but I'm against having the
'@' usage disabled by default. This BC break would be in my opinion
too big.
An other solution would be to have something like (We will also have
to add the type and filename support to this solution so this is just
a first prop
I like the idea. In fact I started to implement it some time ago, but your
patch is really cleaner than mine :)
Otherwise I would prefer to insert the default keyword to make the code
more readable. It might be hard to count when you have something like
function(true);
P.
On 17 April 2012 18
Hi the best way to submit a patch is to fork the project on
github.com/php/php-src and to send a pull request.
If your patch is related to a bug, you can also attach it to the bug report.
Thanks
Pierrick
On 26 May 2012 21:15, William Betts wrote:
> Hello,
>
> I've been looking around for a while
and canadian CTO, working in
> Paris.
> > I lead some PHP projects (mainly the Temma framework and FineFS data
> > replication system).
> > I begin to learn PHP's internal engine, backed by Pierrick Charron.
> >
> > I would like to do an RFC proposal (see below
But still, I think it's intellectually interesting, even if it's not a
> good concept for PHP. :-)
>
> Pierrick, I owe you a beer ;-)
> Le 29 juin 2012 19:06, "Pierrick Charron" a écrit :
>
I completely agree with Adam and others, we should not change the
behaviour to add any magic.
The ext/curl api was made to stay as close as possible from the
original libcurl api and it should stay the same (even if it's not
always implicit). A lot of people are often referring to the libcurl C
do
Hi all,
About 2 month ago, we had a discussion on this list about the fact
that CURLOPT_SSL_VERIFYHOST was most of the time used with a Boolean
value (true) instead of int values (0,1 or 2). This bad usage was
leading to some security issues. The result of this discussion was to
trigger a notice i
.1 (I just hope that people
will not be confused on what is libcurl and what's the version of it).
Pierrick
On 20 December 2012 08:59, jpauli wrote:
> On Wed, Dec 19, 2012 at 5:35 AM, Pierrick Charron
> wrote:
>>
>> Hi all,
>>
>> About 2 month ago, we had
57, jpauli wrote:
>
>
> On Thu, Dec 20, 2012 at 4:57 PM, Pierrick Charron
> wrote:
>>
>> Hi Julien,
>>
>> I think we need to trigger a notice to prevent users to write code
>> that may not work in future version even if it doesn't depend on our
>
The following solution was implemented :
https://github.com/php/php-src/commit/517f800277a11d6ce05b0e1afcd0e76dc544d452
Pierrick
On 18 December 2012 23:35, Pierrick Charron wrote:
> Hi all,
>
> About 2 month ago, we had a discussion on this list about the fact
> that CURLOPT_SSL_VE
Hi all,
Stas opened a discussion almost a year ago about
https://bugs.php.net/bug.php?id=46439 (I let you read details in the
bug) and I would like to reopen the subject since there was no end to
this discussion and nothing was made to fix this issue.
One solution proposed by Richard Lynch was to
Hi all,
I know this topic was opened a long time ago, but I would like to get
it resolved before 5.5 got released.
One solution proposed by Richard Lynch was to add a new
CURLOPT_FILEFIELDS that takes an array of the parameters that are
supposed to be files, so the ones that are expected to have
Hi,
You're right the proposed implementation did not removed the issue but
was just changing the way to produce it and I agree that the most
secure way to do it would be as you suggested to add a separate option
but I see some issues that we will have.
Usually libcurl doesn't allow to call curl_e
Hi Stas,
I think you're right using object is the safest way to do it safely.
It might look strange because there are no object at all in the
current extension and the procedural function will use in this
specific case an object but still we have to provide a safe way to do
it.
I also agree with
Hi Stas,
Everything looks good to me :) Great job.
About your optional section :
I like the procedural function that you proposed so that you don't
have to use an object if you don't want to.
cURL allow you to upload file from string buffer with CURLFORM_BUFFER
and we should be able to do all t
There is already a similar RFC here :) Maybe it could be good to start
from this one so that we don't have any duplicated RFC ?
https://wiki.php.net/rfc/annotations-in-docblock
Pierrick
On 6 January 2013 16:58, Yahav Gindi Bar wrote:
> Hi internals!
>
> In one of the discussions (about the "dep
Looks good to me, just it could be great to add a new cURL option at
the same time to disable the '@' usage so that someone working with
the new ext/curl version can disable it and therefore send values
starting by @
Pierrick
On 7 January 2013 01:40, Stas Malyshev wrote:
> Hi!
>
> I've added the
On 8 January 2013 03:55, Stas Malyshev wrote:
> On the contrary, plenty of implementations means there's a need in this
> functionality, and it might be a good idea to have one standard
> implementation if it can cover like 80% of use cases.
I agree, there is a need in this functionality, but all
I do use PHP Unit and also Doctrine which uses annotations. And I know
that today because there is no native annotations, the implementation
use docblocks so I can not remove them :) But still if I did not know
anything about PHP and that someone was talking to me about comments,
I would expect my
Unfortunately [] is still not usable because it will introduce syntax
ambiguity with short array syntax. The patch we've done for
annotations would require some small change to work on the new master
version but I can take some time to do it if I see some interest in
the proposal. If someone want t
Annotations can be nested so in this case [Foo([BAR])] there is a big
ambiguity and we can not determine if [BAR] is an array with the BAR
constant in it or an annotation.
Pierrick
On 9 January 2013 05:53, Clint Priest wrote:
> In none of those scopes would [ ] be a parsing issue I believe...
-
# is an alternative syntax for comments
On 9 January 2013 08:27, Nikita Nefedov wrote:
> #Foo(#Bar())
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
I agree with you on this point, we should not introduce any new
feature if there is no way to deal with largely used extensions like
apc, xdebug or maybe others. The provided implementation is not
supposed to be final (syntax or internal implementation) and I'm sure
there are many improvements
Hi Stas,
What's the status of this fix ?
Thanks
Pierrick
On 8 January 2013 04:23, Stas Malyshev wrote:
> Hi!
>
>> Looks good to me, just it could be great to add a new cURL option at
>> the same time to disable the '@' usage so that someone working with
>> the new ext/curl version can disable i
Great :) Thanks for the update
On 17 January 2013 15:35, Stas Malyshev wrote:
> Hi!
>
>> What's the status of this fix ?
>
> The pull is in the RFC, so I planned to do the vote on Monday and then
> get it merged if nobody objects.
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://w
Hi Stas,
I'm not against it but, just being curious, what are those security reasons
?
Thanks
Pierrick
On 28 January 2013 15:01, Stas Malyshev wrote:
> Hi!
>
> > I've started a vote on CURLFile RFC:
> > https://wiki.php.net/rfc/curl-file-upload#vote
> >
> > Please vote.
>
> Looks like the feat
Thanks for the example. Even if it's not frequent I agree that it doesn't
cost much to prevent this issue
Pierrick
On 1 February 2013 13:04, Stas Malyshev wrote:
> Hi!
>
> > I'm not against it but, just being curious, what are those security
> > reasons ?
>
> If you ever accepted serialized dat
That's a good idea :) I'm also in
On 13 February 2013 09:51, Zeev Suraski wrote:
>
> As per Derick’s idea, we can arrange a webinar for those interested in
> better understanding how it works.
>
>
Hi,
I tried to install the ZendOptimizer+ provided earlier today but wasn't
able to make it work. I compiled it with success but when I looked at the
phpinfo(); I had this :
Opcode Caching Disabled
Optimization Enabled
Startup Failed no value
I'm using the apache2handler (MPM Worker - multi-thre
+1
On 19 February 2013 07:06, Sara Golemon wrote:
> Opening RFC to allow trailing comma in function call argument lists
>
> https://wiki.php.net/rfc/trailing-comma-function-args
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> Protip: use an IDE.
>
The IDE that i'm using may search for something like function \w to find
all the functions of my code. So I may have to wait for a new update of the
IDE to be able to use the index, and I also may have to pay to get the
update of my IDE. So why would I want all this if I ca
Hi
I don't think we should remove curlwrappers from 5.5. I do agree that this
is not yet stable and ready to push as non experimental, but since we plan
to release 5.5 soon I don't think removing it right now is worth it.
I started some time ago to maintain the curl extension. I focused mainly on
If you decide to remove it for 5.5 RC, tell me and I'll merge this branch
https://github.com/adoy/php-src/tree/remove-curl-wrappers
Thanks
Pierrick
On 11 April 2013 04:03, Julien Pauli wrote:
> On Wed, Apr 10, 2013 at 6:52 PM, Pierre Joye wrote:
>
>> On Wed, Apr 10, 2013 at 6:46 PM, Julien Pau
Including 5.3 and 5.4 ??
Pierrick
On 11 April 2013 14:12, Pierre Joye wrote:
> On Thu, Apr 11, 2013 at 4:54 PM, Pierrick Charron
> wrote:
> > If you decide to remove it for 5.5 RC, tell me and I'll merge this branch
> > https://github.com/adoy/php-src/tree/remove-curl
+1
On 12 April 2013 04:07, Johannes Schlüter wrote:
> On Fri, 2013-04-12 at 10:00 +0200, Julien Pauli wrote:
> > On Fri, Apr 12, 2013 at 1:34 AM, Kalle Sommer Nielsen
> wrote:
> >
> > > Hi
> > >
> > > 2013/4/12 Pierre Joye :
> > > > On
I created a straightforward RFC that you can access here
https://wiki.php.net/rfc/curl-wrappers-removal-rfc .
If someone have something more to add in it, feel free. Otherwise I will
start the vote so that we could remove it in 5.5 ASAP.
Thanks
Pierrick
On 12 April 2013 11:09, Julien Pauli wrot
Hi,
Since we are in a tight schedule, I started the vote and it will end in a
week.
https://wiki.php.net/rfc/curl-wrappers-removal-rfc#vote
Pierrick
On 16 April 2013 09:17, Julien Pauli wrote:
> On Tue, Apr 16, 2013 at 3:01 PM, Pierrick Charron wrote:
>
>> I created a straigh
Oh sorry I'm gonna do it right now.
Thanks :)
On 17 April 2013 18:02, Hannes Magnusson wrote:
> I think by law you have to create a new thread and prefix the subject
> line with [VOTE] or something.
>
> -Hannes
>
> On Wed, Apr 17, 2013 at 2:59 PM, Pierrick C
Hi folks,
I just opened a vote for the curl-wrappers removal in 5.5. Since we are in
a tight schedule, the vote duration will only be a week and will end April
24th.
You can vote there : https://wiki.php.net/rfc/curl-wrappers-removal-rfc#vote
Regards,
Pierrick
Hi,
The vote is supposed to end on April 24th, but if there is no objection, I
will end it tomorrow and merge it if there is no change in the vote results.
Pierrick
On 22 April 2013 04:58, David Soria Parra wrote:
> On 2013-04-17, Pierrick Charron wrote:
> > --001a11c37cdc78c2e30
David, All,
I just committed the patch to remove curl-wrappers from PHP5.5. It 's one
day before schedule but we need to make sure the merge was done before the
new beta release.
Pierrick
On 22 April 2013 13:10, Pierrick Charron wrote:
> Hi,
>
> The vote is supposed to end on A
Hi,
I created a patch for the bug #49936.
The problem was due to the new way to manage references of stream context.
The patch increase the refcount of the context when it's assigned to a
stream (in the method php_stream_context_set).
A zend_list_delete is already called on the context when the s
Hi ,
Here are the patches and phpt for the following bugs :
#49521 (The patch move the call to the constructor before the mapping logic)
- http://www.adoy.net/php/49521.PHP_5_2.patch
- http://www.adoy.net/php/49521.PHP_5_3.patch
- http://www.adoy.net/php/49521.PHP_6_0.patch
- http
Hi,
Felipe suggested me to request Karma for php-src to do bug fixing. My
SVN username is pierrick.
For those of you don't know me I'm Pierrick a French PHP Developer who
live in Montreal.
You can reach me if needed (or not) on IRC #pecl.dev on EFNet, my
nickname is adoy.
Thanks
Pierrick
--
PH
I agree that for the PDO and mysqli, if I put my OO-puristic side
away, it can make some sense to call the constructor after
initialization of the object. I agree that those changes can be
reverted but this really have to be well documented.
About the Tidy one (Bug #50558), there I'm not sure... I
I've added the patch to remove magic quotes from trunk on the RFC.
Is there any comments/objection against this patch ?
Pierrick
2010/4/8 Kalle Sommer Nielsen :
> Hey Everyone
>
> I've put together a simple RFC[1] that lists features thats been
> deprecated in 5.3, someone of them which I propose
+1 to remove magic_quotes from trunk
Most of us want to get rid of this feature. I agree with you that some
people probably don't know php.ini and magic_quotes but i'm not sure
that even if we wait we'll find a better way to tell them about those.
People (not all) on shared hosting don't really pa
+1 For derick and Kalle
2010/4/27 Kalle Sommer Nielsen :
> Hi
>
> 2010/3/24 Lukas Kahwe Smith :
>> Yeah, lets get that clarified. Derick has stepped up and seems quite
>> committed and nobody seemed to oppose him RMing the next release. In case he
>> feels he needs support he can propose a co-RM
Following Richard's e-mail I created a patch and a RFC (
http://wiki.php.net/rfc/enum ) to introduce the enum language
structure.
Two patches are available on to create an enumeration as Richard's suggested
class foo {
const enum {
CASE_1,
CASE_2,
CASE_3,
CASE_4
};
}
And one other without
I agree that enum make more sense when it's a type but I disagree with
the fact that it make code less understandable. The goal of this patch
is to make it easy to create a list of constants when the value is not
necessarily important (For example when you create a lexer you don't
mind if the integ
Hello PHP Internals!
Recently a RFC was included on the PHP Wiki[1].
I know there've been a lot of buzz related to PHP 5.4, but this is not
the subject of this email.
I'm here to propose a new feature in PHP: Annotations.
A patch is already available with 54 tests for the moment[2].
I worked tog
add a layer in PHP that transforms this data into an object structure.
>
> greetings,
> Benjamin
>
> On Wed, 25 Aug 2010 08:56:53 -0400, Pierrick Charron
>
> wrote:
>> Hello PHP Internals!
>>
>> Recently a RFC was included on the PHP Wiki[1].
>> I
Hi Etienne,
2010/8/25 Etienne Kneuss :
> On Aug 25 8:56:53, Pierrick Charron wrote:
>> Hello PHP Internals!
>>
>> Recently a RFC was included on the PHP Wiki[1].
>> I know there've been a lot of buzz related to PHP 5.4, but this is not
>> the subject of t
implementation:
>>
>> namespace PHPUnit;
>>
>> class ExpectedException extends \ReflectionAnnotation {
>> public function __construct(\Reflector $instance, array $values)
>> {
>> if ( ! ($instance intanceof \ReflectionMethod) {
>>
t(array('value' => 'bar', 'baz' => 'hello world'));
So there is no overhead on the execution time even if you have
annotations in your code.
Pierrick
2010/8/25 Etienne Kneuss :
>
> - "Pierrick Charron" wrote:
>
Hi Stas :
I see many points to use classes instead of just arrays :
1) If you just use array, it is not possible to annotate an annotation
to do something like [Inherited] and other eventual annotations for
annotation.
As Guilherme mentioned in one of his previous mail, we are thinking
about addi
ter if you use them intensively.
> Also I would like to see an APC patch to check if the implementation works
> and doesn't lose performance.
I will try to work on an APC patch to store the Annotations HashTable
of every code element structure.
> Thanks. Dmitry.
Thanks again for
>
> [Validation(Email(checkMX=>true))] looks better.
>
> Thanks. Dmitry.
>
Hi Dmitry
The initial syntax proposed in the RFC/Patch is inspired by C#. If you
modify this syntax to remove brackets in nested annotations you will
have some conflicts like this one :
[Validation(Email)]
In this case t
Hi Stas,
Annotations is a new concept in PHP (even if some framework already
use an user space implementation of them) and I think it is normal
that people will have to read a little bit about this eventually new
feature before using it. This is the same thing for traits, if you
don't know what is
Hi,
Last year, I attended to a conference where you (Stas) told that the best
way to do a feature request/proposal was by writing a RFC and a patch even
if the patch is not perfect. The current implementation may not be perfect
but it was never said it was a final one. This is a proposal of a firs
+1 for Annotations
2010/9/16 Guilherme Blanco
> Hi Derick,
>
> Again, we should not consider docblock mainly because I think
> adding/removing comments of your code should NEVER modify the overall
> functionality of your application.
> That said, docblock is no option. Now PLEASE let's stop argu
+1
On 15 November 2010 21:27, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> @Zeev: That topic was related to an already built patch, which some
> where in favor, some against. That discussion lead to nowhere.
> So I opened a thread topic by topic for some democracy approval. As
+1 for removing it in trunk
Pierrick
On 17 November 2010 11:08, Kalle Sommer Nielsen wrote:
> Greetings
>
> I wanted to raise this topic before we go Alpha with trunk, regarding
> our beloved magic_quotes feature. There seems to be mixed opinions
> regarding it so I thought I would take it up f
+1
Good job felipe
On 26 November 2010 14:36, Felipe Pena wrote:
> Hi all,
> I'm here again to presents another proposal, which adds support for
> instantiating a class and calling its methods and accessing its properties
> on same command.
>
> Example:
>
>
> class bar {
> public $x = 'PHP';
>
+1
2010/11/27 Johannes Schlüter
> Hi,
>
> every now and then while writing classes I forget to add the "function"
> keyword between my visibility modifier and the method name in a class
> declaration. I don't think it is required for readability and it is not
> needed by the parser to prevent co
Hi Karsten,
On 24 March 2011 04:14, Karsten Dambekalns wrote:
> Hi Guilherme.
>
> On 14.03.11 19:02, guilhermebla...@gmail.com wrote:
> > @Etienne: That RFC is outdated.
> > Since the last feedback form internals list, a lot of changes have
> > been made to that RFC. Maybe I should update it ASA
Hi,
First, the actual patch is working but Implementation and behavior may
change following all comments. This is still a work in progress and all
comments/contributions from everybody are welcome :)
That said :
On 9 May 2011 21:23, Stas Malyshev wrote:
> Hi!
>
>
> Objects are only instantiat
Hi,
Annotations as proposed in the RFC can not (or hardly) be develop as an
extension (and so can not go into PECL). The proposed feature require
modifications directly into the Zend Engine like for the inclusion of a new
syntax which imply modification of the parser.
Regards,
Pierrick
On 9 May
+1
Regards
Pierrick
On 16 May 2011 08:15, Felipe Pena wrote:
> Hi all,
> As I have proposed previously in an old thread... What about we name all
> the
> tokens to have an improved parser error message? (i.e. anymore
> T_PAAMAYIM_NEKUDOTAYIM, T_DOLLAR_OPEN_CURLY_BRACES in the messages etc)
>
>
Hi,
The RFC was supposed to be a draft (i didn't really added it in the good
section) and was written more to introduce the idea and make people think
about it.
Feel free to update it with any idea, concern you may have.
Pierrick
On 3 June 2011 03:26, Dennis Haarbrink wrote:
> One thing I woul
Hi,
I have a more recent one on my laptop. I'll update it tonight or tomorrow to
make sure it work on 5.4 and send it in this thread.
Pierrick
On 20 July 2011 15:44, Pierre Joye wrote:
> hi,
>
> Please find as attachment the previous patch to remove the magic quotes.
>
> The log I was using ba
I tried to send the patch as a .txt file but it seems my mail was not
send to internals since i don't see it on news.php.net.
Anyway you'll find patch (code + tests) here :
- http://www.adoy.net/php/remove-magic-quotes.txt
- http://www.adoy.net/php/remove-magic-quotes-tests.txt
Pierrick
On 20 Ju
t; On Thu, Jul 21, 2011 at 2:18 AM, Pierrick Charron
> wrote:
>> I tried to send the patch as a .txt file but it seems my mail was not
>> send to internals since i don't see it on news.php.net.
>>
>> Anyway you'll find patch (code + tests) here :
>> - http:/
Hi,
I created a patch for the bug #55247 [1] to add the Test::{'method'}(); syntax.
I think it make sense to add this in 5.4+ to be consistent since we
have the same syntax for non static call.
If someone with Zend karma can review/commit it.
[1] https://bugs.php.net/bug.php?id=55247
Thanks
Pier
Hi,
I added a patch on #50816. I'm not sure the approach to fix this bug
is the best one so if someone can give me some feedback ?
Thanks
Pierrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
don't loop on the array for nothing.
The "optimised" patch can be found here : http://www.adoy.net/php/50816-2.diff
If someone has a better solution I'll be please to read it.
Thanks
Pierrick
On 28 July 2011 20:57, Pierrick Charron wrote:
> Hi,
>
> I added a patch on
I also worked on the patch and I agree this is just an error :) I can
do the change if you want.
Pierrick
On 15 November 2011 07:51, David Soria Parra wrote:
> On 2011-11-12, David Zülke wrote:
>> Had a few other tests failing, updated those accordingly and attached a
>> newer version.
>
> Acc
Hi all,
I started today to play with libcurl and went through documentation. I
noticed that there were a lot of features that were not exposed in the
curl PHP extension which made me wondering if someone is still
maintaining this extension to keep it as close as possible from the C
version. If nob
Hi internals,
Bronisław Białek and I would like to start a discussion about allowing
multiple exception types to be caught in a single catch statement.
https://wiki.php.net/rfc/multiple-catch
A working implementation and tests are available in the RFC.
We are waiting for your constructive feedb
e the implementation when needed (Behaviour
will stay the same, unless you see other behaviour that this syntax could
have in this same "catch" context).
Pierrick
On 8 March 2016 at 16:50, Sean DuBois wrote:
> On Tue, Mar 08, 2016 at 04:42:29PM -0500, Pierrick Charron wrote:
> >
)
} catch (AccessException $e) {
return false;
} catch (UnexpectedTypeException $e) {
return false;
}
And other piece of code using multiple libraries.
On 8 March 2016 at 18:06, Björn Larsson wrote:
> Den 2016-03-08 kl. 22:42, skrev Pierrick Charron:
>
>> Hi internals,
>>
>&
only possible when you control the exception hierarchy in
your own code, but not possible when you don't control the code."
On 9 March 2016 at 06:52, Derick Rethans wrote:
> Hi!
>
> On Tue, 8 Mar 2016, Pierrick Charron wrote:
>
> > Bronisław Białek and I would like to
On 9 March 2016 at 08:08, Marco Pivetta wrote:
> On 9 March 2016 at 14:03, Pierrick Charron wrote:
>
>> Hi Derick
>>
>> I agree that most of the time the best solution is to implement a clean
>> exception hierarchy but as stated in the RFC :
>>
>> &
On 9 March 2016 at 08:30, Marco Pivetta wrote:
> On 9 March 2016 at 14:24, Pierrick Charron wrote:
>>
>> The thing I don't like about this approach is that I have to read the
>> code and double check to make sure that the catch statement call the same
>> method
Hi Sara,
Just to let you know that I took the liberty to correct the title of your
RFC. It was still null coalesce equal operator :)
Otherwise I'm +1 for both RFC
Pierrick
On 10 March 2016 at 22:01, Sara Golemon wrote:
> On Wed, Mar 9, 2016 at 10:14 AM, Midori Kocak wrote:
> > Let me introdu
> function packeForMe(string $name) : Pack
>> {
>> try {
>> return (new Packer())->pack(new PackTemplate($name));
>> } catch (PackingFailed | ValidationException $e) {
>> throw new SomeException($e); // or return null in other cases
>
and I'll of course comply to the voters decision :-)
Pierrick
On 15 March 2016 at 12:23, Patrick ALLAERT wrote:
> Hi,
>
> Le mer. 9 mars 2016 à 14:08, Marco Pivetta a écrit :
>
>> On 9 March 2016 at 14:03, Pierrick Charron wrote:
>>
>> > Hi Derick
>&
On 22 April 2016 at 11:39, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote:
>
> >
> >
> > On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote:
> >
> > Hi Dmitry,
> >
> > As a previous suggester of metadata information built-
Hi internals,
I took some time to add some easy to implement new "features" that were
implemented in libcurl but missing in ext/curl. Most of them are just
exposing a new constant in ext/curl and dispatched in the curl_setopt
function. I created a branch over master but the patch is applicable
wit
; it's HTTP/2 support.
>
> I hope to eventually (7.2+) use libnghttp2 to add an ext/nghttp2 HTTP
> client and update the HTTP streams layer to support HTTP/2 also.
>
> I'd welcome your collaboration on any of this.
>
> - Davey
>
> On Sat, Apr 23, 2016 at
1 - 100 of 169 matches
Mail list logo
