Evening all,
I've prepared an alternative: https://github.com/php/php-src/pull/4282
Hiding the arguments seems sensible enough, not as a hardcoded default
(default behaviour should be retained), but as a documented recommended
default for production.
I think, this needs to go through the RFC pro
Encrypting logs could potentially impact performance alot. My opinion is that
core dumps and full stack traces should be disabled by default and activated
only when needed to minimize the risk of data leaks. However, logging is
needed. You need to get information about what went wrong.
Maybe t
On Fri, Feb 1, 2019 at 11:45 AM Jan Schneider wrote:
>
> Zitat von Bishop Bettini :
>
> > On Wed, Nov 21, 2018 at 7:27 PM Stanislav Malyshev
> > wrote:
> >
> >> Hi!
> >>
> >> > Anyhow, this is water under the bridge now, and I think we should
> issue
> >> > a call for maintainership[4] for ext/i
Zitat von Bishop Bettini :
On Wed, Nov 21, 2018 at 7:27 PM Stanislav Malyshev
wrote:
Hi!
> Anyhow, this is water under the bridge now, and I think we should issue
> a call for maintainership[4] for ext/imap as soon as possible, since
> this is not the only issue[5] of this unmaintained[6]
Hi!
> Hi!
>
> > Anyhow, this is water under the bridge now, and I think we should
> issue
> > a call for maintainership[4] for ext/imap as soon as possible, since
> > this is not the only issue[5] of this unmaintained[6] extension.
>
> Pierre is listed as maintainer. But
On Wed, Nov 21, 2018 at 7:27 PM Stanislav Malyshev
wrote:
> Hi!
>
> > Anyhow, this is water under the bridge now, and I think we should issue
> > a call for maintainership[4] for ext/imap as soon as possible, since
> > this is not the only issue[5] of this unmaintained[6] extension.
>
> Pierre is
Hi!
> Import the library into core and maintain it or write an alternate from
> scratch - IF the functions it provides truly has market demand.
Nice suggestion if we had a line of volunteers at our doors asking us to
give them something to maintain. We don't. So this is not an option,
it's a happ
On 21.11.2018 at 08:38, Kalle Sommer Nielsen wrote:
> Den ons. 21. nov. 2018 kl. 06.13 skrev Pierre Joye :
>
>> Btw, is imap on the list to deprecate in 7.x + kill in 8.x? It is really
>> not maintained well, both c-client and the ext. Would it be possible to
>> consider it?
>
> I remember we hav
On 11/20/2018 11:38 PM, Kalle Sommer Nielsen wrote:
Den ons. 21. nov. 2018 kl. 06.13 skrev Pierre Joye :
Btw, is imap on the list to deprecate in 7.x + kill in 8.x? It is really
not maintained well, both c-client and the ext. Would it be possible to
consider it?
I remember we have spoken about
Am 21.11.2018 um 06:13 schrieb Pierre Joye:
On Wed, Nov 21, 2018, 6:02 AM Stanislav Malyshev
actually the PHP wrapper should not have allowed to pass the mailbox
name verbatim, which would only be reasonable in my opinion, if we were
supporting arbitrary drivers (which we don't). And of course,
Den ons. 21. nov. 2018 kl. 06.13 skrev Pierre Joye :
> Btw, is imap on the list to deprecate in 7.x + kill in 8.x? It is really
> not maintained well, both c-client and the ext. Would it be possible to
> consider it?
I remember we have spoken about this in the past and it seems that
everytime it c
On Wed, Nov 21, 2018, 6:02 AM Stanislav Malyshev Hi!
>
> > actually the PHP wrapper should not have allowed to pass the mailbox
> > name verbatim, which would only be reasonable in my opinion, if we were
> > supporting arbitrary drivers (which we don't). And of course, userland
>
> PHP does not d
I do not disagree, just want to make an observation.
If multiple properties or array keys reference the same instance of
\stdClass, there will be multiple instances with identical values after a
round-trip with var_export() + eval().
This is not necessarily a problem, just something to be aware of
x27;Nikita Popov' ; 'Julien
Pauli'
> ; 'Joe Watkins'
> Subject: Re: [PHP-DEV] Re: [PATCH] opcache bug #69090, prepend user
> identifier to keys
>
> I've just committed the fix into PHP-5.6 and above.
>
> Unfortunately, I can't create phpt tests,
are.net
Cc: ras...@lerdorf.com; internals@lists.php.net; 'Anatol Belski'; Zeev Suraski;
'Nikita Popov'; 'Julien Pauli'; 'Joe Watkins'
Subject: RE: [PHP-DEV] Re: [PATCH] opcache bug #69090, prepend user identifier
to keys
Hi Dmitry,
> -Original Messa
Hi Dmitry,
> -Original Message-
> From: Dmitry Stogov [mailto:dmi...@zend.com]
> Sent: Tuesday, November 15, 2016 4:20 PM
> To: php-...@coydogsoftware.net
> Cc: ras...@lerdorf.com; internals@lists.php.net; Anatol Belski
(a...@php.net)
> ; Zeev Suraski ; Nikita Popov ;
> Julien Pauli ; Joe
On 21 Dec 2014 13:25, "Andrea Faulds" wrote:
>
>
> > On 20 Dec 2014, at 15:50, Andrea Faulds wrote:
> >
> >
> >> On 14 Dec 2014, at 18:35, Andrea Faulds wrote:
> >>
> >> I’ve made a patch which makes zend_parse_parameters and userland type
hints consistently show “integer” and “float” rather tha
On Fri, Dec 7, 2012 at 8:54 PM, Paul Taulborg wrote:
> Sorry for the double message, still getting used to doing patches
> instead of applying changes directly. I accidentally attached an old
> patch file, not the latest. The previous had a bug in
> php_date_initialize() which I caught in my test
Hi Stas,
Thanks for the response!
Usually it helps to talk to extension maintainer (list of them in in
> EXTENSIONS file).
>
In the original message of this thread I CCed the extension maintainer
listed in EXTENSIONS (per the instructions in the README.SUBMITTING_PATCH)
and I did not hear anythin
Hi!
> Can someone please let me know if I'm doing something wrong in trying to
> get this committed?
>
> Am I doing something procedurally wrong or is it normal for nobody to
> respond?
Usually it helps to talk to extension maintainer (list of them in in
EXTENSIONS file).
Speaking of the patch,
The implementation specifically didn't introduce T_GET/T_SET on the
lexer side and instead checks for T_STRINGs with content "get" or
"set".
Nikita
On Wed, Dec 7, 2011 at 3:29 AM, Stas Malyshev wrote:
> Hi!
>
>
>> I believe the attempt with the RFC was to mimic the syntax that C#
>> went with, t
Hi!
I believe the attempt with the RFC was to mimic the syntax that C#
went with, the RFC is here:
https://wiki.php.net/rfc/propertygetsetsyntax
Reading this RFC I notice it makes get/set keywords. This would lead to
huge amount of breakage in existing code, so I strongly suggest to look
for a
Hi
2011/12/6 Rasmus Schultz
> On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps >wrote:
>
> > Hi,
> >
> > I also find this syntax confusing and I think it has a huge WTF factor.
> >
> > Some thoughts about the syntax:
> > - At the first glance, it isn't clear which visibility the getter or
> > set
rnals@lists.php.net
Subject: Re: [PHP-DEV] Re: Patch: getters/setters syntax Implementation
On Tue, Dec 6, 2011 at 4:23 AM, Clint M Priest wrote:
> I believe the attempt with the RFC was to mimic the syntax that C#
> went with, the RFC is here:
> https://wiki.php.net/rfc/propertygetsets
On Tue, Dec 6, 2011 at 3:45 AM, Christian Kaps wrote:
> Hi,
>
> I also find this syntax confusing and I think it has a huge WTF factor.
>
> Some thoughts about the syntax:
> - At the first glance, it isn't clear which visibility the getter or
> setter has
> - The extra indentation level makes the
On Tue, Dec 6, 2011 at 4:23 AM, Clint M Priest wrote:
> I believe the attempt with the RFC was to mimic the syntax that C# went with,
> the RFC is here: https://wiki.php.net/rfc/propertygetsetsyntax
C# like setter/getter is definitely what I would like to have in PHP,
it is a very clear and know
Hi,
I also find this syntax confusing and I think it has a huge WTF factor.
Some thoughts about the syntax:
- At the first glance, it isn't clear which visibility the getter or
setter has
- The extra indentation level makes the code more unreadable
class Foo {
/**
*
*/
priv
I believe the attempt with the RFC was to mimic the syntax that C# went with,
the RFC is here: https://wiki.php.net/rfc/propertygetsetsyntax
The first public would apply to either of the get/set which did not have it
further defined, for example:
public $Hours {
get { ... }
priv
hi,
we should only warn the un-intenional convertion .
So , give third to send make printable zavl. Sppress all the
intentional ones.
Thanks
Sent from my iPhone
在 2011-11-3，4:23，Patrick ALLAERT 写道：
> 2011/11/2 Etienne Kneuss :
>> Hi,
>>
>> On Wed, Nov 2, 2011 at 17:27, Stas Malyshev wr
2011/11/2 Etienne Kneuss :
> Hi,
>
> On Wed, Nov 2, 2011 at 17:27, Stas Malyshev wrote:
>> Hi!
>>
>>> What about array_diff(array("Array"), array(array()))? To me the sole
>>> act of having an array in it is an almost sure indication that the code
>>> is wrong somewhere... IMO it deserves a notice
Hi,
On Wed, Nov 2, 2011 at 17:27, Stas Malyshev wrote:
> Hi!
>
>> What about array_diff(array("Array"), array(array()))? To me the sole
>> act of having an array in it is an almost sure indication that the code
>> is wrong somewhere... IMO it deserves a notice.
>
> That one would have the arrays
Hi!
What about array_diff(array("Array"), array(array()))? To me the sole
act of having an array in it is an almost sure indication that the code
is wrong somewhere... IMO it deserves a notice.
That one would have the arrays different. Having multi-dimensonal arrays
is not an error, comparing
On Nov 2, 2011 4:05 PM, "Stas Malyshev" wrote:
>
> Hi!
>
>
>> In such cases, the notice actually seems fine to me. This is typically
>> the cases where you want to inform the user that he probably did
>> something wrong...
>
>
> In this specific case, I would say notice is not needed - it is obvio
Hi!
In such cases, the notice actually seems fine to me. This is typically
the cases where you want to inform the user that he probably did
something wrong...
In this specific case, I would say notice is not needed - it is obvious
that a string is not equal to any array, so there's no need to
Hi,
On Wed, Nov 2, 2011 at 09:55, Laruence wrote:
> On Mon, Oct 31, 2011 at 10:55 AM, Stas Malyshev
> wrote:
>> Hi!
>>
>>> Hi:
>>> like the following script:
>>> >> $str = (string)array();
>>> echo $str;
>>>
>>> it is obviously intentionally convert a array to string , but the
>>> warni
On Mon, Oct 31, 2011 at 10:55 AM, Stas Malyshev wrote:
> Hi!
>
>> Hi:
>> like the following script:
>> > $str = (string)array();
>> echo $str;
>>
>> it is obviously intentionally convert a array to string , but the
>> warning is coming:
>
> I think it's the correct way to react for PHP. Th
Hi:
Actually, I only know two ,
one is in ext/reflection and another is 60174
I just fixed 60174 , but if there comes a new argument to
zend_make_printable_zval , I will re-fix this .
thanks
2011/10/31 Stas Malyshev :
> Hi!
>
>> Hi:
>> like the following script:
>> > $str = (string)array(
Hi!
Hi:
like the following script:
I think it's the correct way to react for PHP. This code is an extremely
convoluted way to write "echo 'Array';" and as such doesn't seem to do
anything useful. I have yet to see one single instance where converting
array to string made any sense. Of
On Mon, Oct 31, 2011 at 2:36 AM, Laruence wrote:
> Paul:
> sure, there is some usage in ext/reflection and what was said in
> the bug report.
>
> so if there is no a argument to suppress it, these codes have to
> change to something like:
understood. indeed doesn't seem quite right.
On
Paul:
sure, there is some usage in ext/reflection and what was said in
the bug report.
so if there is no a argument to suppress it, these codes have to
change to something like:
if (Z_TYPE_P(val) == IS_ARRAY) {
} else {
zend_make_printable_zval..
}
which is ugly.
On Sun, Oct 30, 2011 at 1:23 PM, Laruence wrote:
> s /second/third/
Laurence,
What Jordi was saying was that in a production environment is there
any justified reason why you'd want to convert an array into a string,
otherwise it's a good thing that it reports you "Array to string" as
you've pro
s /second/third/
2011/10/30 Laruence :
> Hi:
> I don't think this(you think there is no use) can used for the
> reason to do such a change.
>
> actully I ask for a sencond argument for zend_make_printable_zval
> to suppress the warning *intentionally*.
>
> thanks
>
> 2011/10/30 Jordi Boggi
Hi:
I don't think this(you think there is no use) can used for the
reason to do such a change.
actully I ask for a sencond argument for zend_make_printable_zval
to suppress the warning *intentionally*.
thanks
2011/10/30 Jordi Boggiano :
> On 30.10.2011 13:19, Laruence wrote:
>> Hi:
>>
On 30.10.2011 13:19, Laruence wrote:
> Hi:
> like the following script:
>$str = (string)array();
> echo $str;
>
>it is obviously intentionally convert a array to string , but the
> warning is coming:
It is obviously intentional but also obviously pointless. You might as
well just echo
Hi:
like the following script:
:
> here is the report #60174
>
> thanks
>
> 2011/10/30 Laruence :
>> Hi:
>> there is a bug report about this new change.
>>
>> I found that there has added a notice to zend_make_printable_zval
>> and without any parameter to suppress the warning.
>>
>> I
here is the report #60174
thanks
2011/10/30 Laruence :
> Hi:
> there is a bug report about this new change.
>
> I found that there has added a notice to zend_make_printable_zval
> and without any parameter to suppress the warning.
>
> I think this is very bad, since zend_make_printable_zv
Hi:
there is a bug report about this new change.
I found that there has added a notice to zend_make_printable_zval
and without any parameter to suppress the warning.
I think this is very bad, since zend_make_printable_zval is used
in internal when need to print some infos.
so mayb
On Mon, 2011-06-06 at 12:32 -0400, Matthew Weier O'Phinney wrote:
> On 2011-06-06, Ferenc Kovacs wrote:
> > --00261883a59c62fbe404a50bd89c
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Mon, Jun 6, 2011 at 3:36 PM, Matthew Weier O'Phinney <
> > weierophin...@php.net> wrote:
> >
> > > On 20
On 2011-06-06, Ferenc Kovacs wrote:
> --00261883a59c62fbe404a50bd89c
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Jun 6, 2011 at 3:36 PM, Matthew Weier O'Phinney <
> weierophin...@php.net> wrote:
>
> > On 2011-06-02, Patrick ALLAERT wrote:
> > > I would like to introduce an E_NOTICE when
On Mon, Jun 6, 2011 at 3:36 PM, Matthew Weier O'Phinney <
weierophin...@php.net> wrote:
> On 2011-06-02, Patrick ALLAERT wrote:
> > I would like to introduce an E_NOTICE when an array is silently
> > converted to a string.
> > This isn't very useful as it constantly produces the following string:
Do you use lowercase paths and have capitals in your class names?
That is really where this goes into. Much of PEAR and just about all
of the frameworks are following a specific area. The main key item
here is that \My\Class is generally in a folder like My/Class.php.
Right now spl_autoload would
On 09/03/11 13:34, Mike Willbanks wrote:
It seems like the only potential BC break is on linux if people were
using all lowercase paths. To me it would seem like this is really
not the case or would happen only sometimes.
I'd have trouble finding a single one of my apps that had a path with
I was just thinking about this again and have a working patch for this.
It seems like the only potential BC break is on linux if people were
using all lowercase paths. To me it would seem like this is really
not the case or would happen only sometimes. The quick solution is to
utilize the follow
I think it would be better just to fix the issue in the code. If you
run include 'My/Path/To/File.php' does it lowercase it? It does not.
The expected behavior would to not lowercase it. There are ways that
this could be fixed directly in the code. The only real requirement
that it looks like t
Wouldn't it be better to join forces with the SplClassLoader proposal[1]?
A C implementation of PSR-0 has been prpoposed [2] as well, and would be
nice to get something like that into 5.next
However for your imminent performance needs, you should be aware that an
hash map based autoloaders can be
On Mon, 20 Dec 2010 19:41:29 -, Matthew Turland
wrote:
Thanks to comments from Gustavo Lopes, I've removed the removeCommon
method from my patch. I honestly wish I could say why I didn't realize
his point before I submitted the patch in the first place, but I
appreciate the feedback. I've
hi,
Applied, thanks for your work (and patience).
On Tue, Apr 13, 2010 at 8:51 PM, Charles Duffy wrote:
> This patch has been awaiting review for over a month. Is there anything I
> can do to help hurry things along?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe,
Hi,
Which feature request is it? Please add this patch there as well if
you did not do it already.
Cheers,
On Tue, Apr 13, 2010 at 8:51 PM, Charles Duffy wrote:
> This patch has been awaiting review for over a month. Is there anything I
> can do to help hurry things along?
>
> --
> PHP Internal
> >> @@ -3602,7 +3602,7 @@
> >>}
> >>}
> >>zend_throw_exception_ex(reflection_exception_ptr, 0 TSRMLS_CC,
> >> - "Property %s does not exist", name);
> >> + "Property %s::%s does not exist", ce->name, name);
> >> }
> >> /* }}}
On Fri, Apr 9, 2010 at 9:26 AM, Lukas Kahwe Smith wrote:
>> looks good for me. if there are no objections from someone else I'll
>> commit it tomorrow.
>
>
> @David: seems like you forgot to commit this?
David will be back in 10 days.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net |
On 28.03.2010, at 17:59, David Soria Parra wrote:
> On 2010-03-28, Benjamin Eberlei wrote:
>> Index: ext/reflection/php_reflection.c
>> ===
>> --- ext/reflection/php_reflection.c (revision 296963)
>> +++ ext/reflection/php_reflecti
Hi Christopher,
2009/10/19 Christopher Jones :
> The new interface combines system generated error messages with user
> generated messages.
I think you're talking about Oracle.
> The original PostgreSQL example I saw seemed to use arbitrary text
> messages, similar to Oracle's DBMS_OUTPUT (page
Folks:
> http://tinyurl.com/UGPOM
The actual URI for that is
http://www.oracle.com/technology/tech/php/pdf
/underground-php-oracle-manual.pdf.
I encourage people to reconsider widespread use of URI shortening
services. They lose any clues readers may want as to what the resource
is and reduc
Samuel ROZE wrote:
> http://wiki.php.net/rfc/pdonotices
>
> Samuel.
The new interface combines system generated error messages with user
generated messages.
The original PostgreSQL example I saw seemed to use arbitrary text
messages, similar to Oracle's DBMS_OUTPUT (page 181 of
http://tinyurl.
On 15.10.2009, at 19:40, Samuel ROZE wrote:
Le jeudi 15 octobre 2009 à 11:08 +0200, Lukas Kahwe Smith a écrit :
On 13.10.2009, at 10:34, Samuel ROZE wrote:
http://wiki.php.net/rfc/pdonotices
I assume that calling noticeInfo() will also purge all currently
stored notices (maybe controllabl
Le jeudi 15 octobre 2009 à 11:08 +0200, Lukas Kahwe Smith a écrit :
> On 13.10.2009, at 10:34, Samuel ROZE wrote:
>
> > http://wiki.php.net/rfc/pdonotices
>
>
> I assume that calling noticeInfo() will also purge all currently
> stored notices (maybe controllable via some parameter)?
If purge
On 13.10.2009, at 10:34, Samuel ROZE wrote:
http://wiki.php.net/rfc/pdonotices
I assume that calling noticeInfo() will also purge all currently
stored notices (maybe controllable via some parameter)?
For MySQL we would have to throw an error/exception in case there is a
result set open
http://wiki.php.net/rfc/pdonotices
Samuel.
2009/10/12 Samuel ROZE :
> Here is what I expect for the notices fetching in PDO:
> http://www.d-sites.com/wp-content/uploads/2009/10/RFC-PDO-Notices.pdf
>
> Samuel.
>
> Le lundi 12 octobre 2009 à 19:11 +0200, Lukas Kahwe Smith a écrit :
> [...]
>>
>> we
hi Samuel,
May I ask you to do it in the wiki? We have a dedicated section there:
http://wiki.php.net/RFC
Cheers,
On Mon, Oct 12, 2009 at 10:13 PM, Samuel ROZE wrote:
> Here is what I expect for the notices fetching in PDO:
> http://www.d-sites.com/wp-content/uploads/2009/10/RFC-PDO-Notices.pd
Here is what I expect for the notices fetching in PDO:
http://www.d-sites.com/wp-content/uploads/2009/10/RFC-PDO-Notices.pdf
Samuel.
Le lundi 12 octobre 2009 à 19:11 +0200, Lukas Kahwe Smith a écrit :
[...]
>
> well .. what Pierre (and me supporting him) was asking for is to
> create an RFC pa
On 12.10.2009, at 19:00, Samuel ROZE wrote:
Hi,
I'm writing here to take a point about the discussion. On one side,
you
want to turn this functionality to a global function, like it is
describe into this patch and on the other side, you said that on MySQL
and Oracle we can get this notices
On 12.10.2009, at 12:07, Pierre Joye wrote:
hi,
On Mon, Oct 12, 2009 at 11:58 AM, Matteo Beccati
wrote:
Given the recent posts, I'd vote to only add whatever is needed for
the
drivers to access the extra data. That means to only add the specific
pgsql code to gather notices as the mysq
hi,
On Mon, Oct 12, 2009 at 11:58 AM, Matteo Beccati wrote:
> Given the recent posts, I'd vote to only add whatever is needed for the
> drivers to access the extra data. That means to only add the specific
> pgsql code to gather notices as the mysql and oracle drivers are already
> capable of fe
Hi,
>> hmm why do you think that PDO would need to take special care about
>> this? seems like this is the job of the PDO using code ..
>
> Depending on how PDO's code is written, it could inadvertently blow away
> metadata without a user knowing it.
>
>> but it does raise one concern that i
Hi Lukas:
> hmm why do you think that PDO would need to take special care about
> this? seems like this is the job of the PDO using code ..
Depending on how PDO's code is written, it could inadvertently blow away
metadata without a user knowing it.
> but it does raise one concern that i did
Lukas Kahwe Smith wrote:
On 11.10.2009, at 17:55, Daniel Convissor wrote:
If the notice/warning gathering abstraction is going to be sending
queries to the DBMS in the background, one needs to be careful about
maintaining both the results and metadata from the original query that
caused the wa
On 11.10.2009, at 17:55, Daniel Convissor wrote:
If the notice/warning gathering abstraction is going to be sending
queries to the DBMS in the background, one needs to be careful about
maintaining both the results and metadata from the original query that
caused the warnings.
hmm why do you
Hi,
Le dimanche 11 octobre 2009 à 11:55 -0400, Daniel Convissor a écrit :
> Hi:
>
> If the notice/warning gathering abstraction is going to be sending
> queries to the DBMS in the background, one needs to be careful about
> maintaining both the results and metadata from the original query that
Hi:
If the notice/warning gathering abstraction is going to be sending
queries to the DBMS in the background, one needs to be careful about
maintaining both the results and metadata from the original query that
caused the warnings.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N
Le samedi 10 octobre 2009 à 19:43 +0100, Lester Caine a écrit :
[...]
> > It is the case for MySQL and Oracle...so for your mind, we don't have to
> > make this option available ? I disagree because PDO want make that PHP
> > codes support many Databases and if I want to get this notices on MySQL,
Samuel ROZE wrote:
Le samedi 10 octobre 2009 à 15:51 +0100, Lester Caine a écrit :
Ferenc Kovacs wrote:
Then see how we can do it for the other drivers at the same time.
I'm looking for Oracle.
Is somebody know how we can do for MySQL (and how raise notices with
it) ?
http://dev.mysql.com/do
On 10.10.2009, at 19:32, Samuel ROZE wrote:
Le samedi 10 octobre 2009 à 15:51 +0100, Lester Caine a écrit :
Ferenc Kovacs wrote:
Then see how we can do it for the other drivers at the same time.
I'm looking for Oracle.
Is somebody know how we can do for MySQL (and how raise notices
with
i
Le samedi 10 octobre 2009 à 15:51 +0100, Lester Caine a écrit :
> Ferenc Kovacs wrote:
> >>> Then see how we can do it for the other drivers at the same time.
> >> I'm looking for Oracle.
> >> Is somebody know how we can do for MySQL (and how raise notices with
> >> it) ?
> >>
> > http://dev.mysql.
Ferenc Kovacs wrote:
Then see how we can do it for the other drivers at the same time.
I'm looking for Oracle.
Is somebody know how we can do for MySQL (and how raise notices with
it) ?
http://dev.mysql.com/doc/refman/5.1/en/show-warnings.html
Something to consider here is that, like MySQL i
On Fri, Oct 9, 2009 at 11:12 PM, Samuel ROZE wrote:
> Le vendredi 09 octobre 2009 à 23:05 +0200, Pierre Joye a écrit :
>> About applying it, we should wait a bit more until we get more
>> feedbacks (say until the middle of next week).
>
> Oh yeah of course ! It was just a question to know how it h
Le vendredi 09 octobre 2009 à 23:05 +0200, Pierre Joye a écrit :
> About applying it, we should wait a bit more until we get more
> feedbacks (say until the middle of next week).
Oh yeah of course ! It was just a question to know how it happened. ;-)
> Then see how we can do it for the other dr
Hi,
First thanks to have updated the patch according to our last feedback :)
About applying it, we should wait a bit more until we get more
feedbacks (say until the middle of next week). Then see how we can do
it for the other drivers at the same time.
Cheers,
--
Pierre
On Fri, Oct 9, 2009 at 1
On Wed, 26 Aug 2009, Greg Beaver wrote:
> Derick Rethans wrote:
> > And the suggestion? Yet another ini setting (some even advocate making
> > it INI_SYSTEM, which is obviously totally wacko)... This idea is an
> > ostrich method.
>
> I'm only trying to suggest ways of fixing problems, calling
Hi!
I don't find it useful, and obviously not everybody agreed with all the
things in Chicago either. I didn't find this back in the notes either
(http://wiki.php.net/summits/pdmnotesmay09).
I got that _you_ don't find it useful. I wish people could get outside
of the box and consider what o
On Wed, Aug 26, 2009 at 16:52, Greg Beaver wrote:
> performance hit when an error is completely hidden either by
> error_reporting or by @ (i.e. no track_errors, no user error handler, no
> other things that would expect to see the errors). That's all that
error_get_last()...
You can't know, at
Derick Rethans wrote:
> And the suggestion? Yet another ini setting (some even advocate making
> it INI_SYSTEM, which is obviously totally wacko)... This idea is an
> ostrich method.
Derick,
I'm only trying to suggest ways of fixing problems, calling them
"obviously wacko" is useless. I don't g
Derick Rethans wrote:
> On Tue, 25 Aug 2009, Stanislav Malyshev wrote:
>
>>> Considering that there shouldn't be any errors in the first place, this
>> You must be kidding me. Any fopen of non-existing file, and loading of
>> non-perfect XML from third party produces errors.
>
> You can test for
On Tue, 25 Aug 2009, Stanislav Malyshev wrote:
> > Considering that there shouldn't be any errors in the first place, this
>
> You must be kidding me. Any fopen of non-existing file, and loading of
> non-perfect XML from third party produces errors.
You can test for the first case, and the seco
Hi!
You're the one asking "What do you think?" :) People seem to think
that this feature is another invitation to bad practice in 95% of the
cases, and only useful to the last 5% of the people who know what
they're doing... (like goto?)
It's useful to 100% people since these practices are bein
Hello,
On Tue, Aug 25, 2009 at 6:36 PM, Stanislav Malyshev wrote:
> Hi!
>
>> Considering that there shouldn't be any errors in the first place, this
>
> You must be kidding me. Any fopen of non-existing file, and loading of
> non-perfect XML from third party produces errors. There is absolutely no
Hi!
Considering that there shouldn't be any errors in the first place, this
You must be kidding me. Any fopen of non-existing file, and loading of
non-perfect XML from third party produces errors. There is absolutely no
way you can write code that does anything useful that would guaranteedly
On Mon, 24 Aug 2009, Stanislav Malyshev wrote:
> > If you enable error log you would be able to identify errors, even
> > in legacy code fairly quickly and address them as needed. The speed
> > increase, by Stas' own admission is very minimal here, I would wager
>
> It's not "very minimal". It'
On 25-Aug-09, at 2:39 AM, Stanislav Malyshev wrote:
Hi!
If you enable error log you would be able to identify errors, even
in legacy code fairly quickly and address them as needed. The speed
increase, by Stas' own admission is very minimal here, I would wager
It's not "very minimal". It'
Hi!
If you enable error log you would be able to identify errors, even in
legacy code fairly quickly and address them as needed. The speed
increase, by Stas' own admission is very minimal here, I would wager
It's not "very minimal". It's not big overall, but it speeds up
operations affected
Hi!
That's also easily solved by making it INI_SYSTEM.
Note here that fatal errors can not be masked, for obvious reasons.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailin
1 - 100 of 297 matches
Mail list logo
