Ferenc Kovacs wrote:
On Mon, Oct 12, 2009 at 11:53 PM, Ferenc Kovacs wrote:
btw. I hate php 5.3 for the following change:
# The use of {} to access string offsets is deprecated. Use [] instead.
I always used the {} because the [] was deprecated for a long time,
and I corrected everybody, to us
Mark Krenz wrote:
> On Mon, Oct 12, 2009 at 05:55:25PM GMT, Carl P.
Corliss [rabb...@gmail.com] said the following:
>
>> Code Search of: "eregi?(_replace)?\( lang:php"
shows ~123,000 results
>> Code Search of:
"preg_(filter|grep|last_error|match_all|match|quote|replace_callback|replace|split)\(
l
Mark,
You contradict yourself. You say that putting a warning in 5.3 isn't soon
enough, since most people are a few versions behind. Yet you think it is an
absolute outrage that something is being dropped in 6, which is a couple of
years away anyway. The people that won't be on 5.3 in time to be n
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
On Mon, Oct 12, 2009 at 11:53 PM, Ferenc Kovacs wrote:
> On Mon, Oct 12, 2009 at 10:51 PM, Mark Krenz wrote:
>> On Mon, Oct 12, 2009 at 07:22:10PM GMT, Robert Cummings
>> [rob...@interjinn.com] said the following:
>>>
>>> You are obviously right of course... the PHP world is NOT ready for the
>>
On Mon, Oct 12, 2009 at 10:51 PM, Mark Krenz wrote:
> On Mon, Oct 12, 2009 at 07:22:10PM GMT, Robert Cummings
> [rob...@interjinn.com] said the following:
>>
>> You are obviously right of course... the PHP world is NOT ready for the
>> POSIX regex library to be dropped. That's why it's "deprecate
On Mon, Oct 12, 2009 at 07:22:10PM GMT, Robert Cummings [rob...@interjinn.com]
said the following:
>
> You are obviously right of course... the PHP world is NOT ready for the
> POSIX regex library to be dropped. That's why it's "deprecated" in PHP
> 5.3 and not removed. In a year or 3, when PHP
> Feel free to collaborate with the authors of PHP_Compat [1].
>
> regards,
> Lukas Kahwe Smith
> m...@pooteeweet.org
>
> [1] http://pear.php.net/package/PHP_Compat
An excellent pointer, Lukas, thank you. I had forgotten PHP_Compat
existed.
--
PHP Internals - PHP Runtime Development Mailing List
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
Ooops:
On Mon, Oct 12, 2009 at 01:48:28PM -0600, Joey Smith wrote:
> $delimiters =
> array(chr(1),chr(1),chr(1),chr(1),chr(1),chr(1),'/', '@', '#', '%', '_');
should have been
$delimiters =
array(chr(1),chr(2),chr(3),chr(4),chr(5),chr(6),'/', '@', '#', '%', '_');
I
On 12.10.2009, at 21:48, Joey Smith wrote:
Write yourself a bit of code that replaces ereg which could be
installed in an
auto_prepend location server-wide. Here's an example you could start
with,
although I should point out that I spent all of about 30 seconds
thinking about
it, so you mi
Write yourself a bit of code that replaces ereg which could be installed in an
auto_prepend location server-wide. Here's an example you could start with,
although I should point out that I spent all of about 30 seconds thinking about
it, so you might want to give it more thought than that - I'm sur
Hello everyone,
Let's create a guide for people wanting to convert code from ereg to
preg. Please post a few items that belong like:
1. Delimiters are needed with PCRE
2. /i versus eregi
3. Something needed to be said about named classes?
What else?
Regards,
Philip
--
PHP Internals - PHP
On Mon, Oct 12, 2009 at 8:14 PM, Mark Krenz wrote:
> So there is my proof. Does anyone still want to dispute me that ereg is
> still heavily used and you'll make a lot of users angry if you don't
> give them the proper amount of time to make this transition?
>
Hello Mark Krenz,
please take the
On Mon, Oct 12, 2009 at 3:14 PM, Mark Krenz wrote:
> On Mon, Oct 12, 2009 at 05:55:25PM GMT, Carl P. Corliss [rabb...@gmail.com]
> said the following:
> >
> > Code Search of: "eregi?(_replace)?\( lang:php" shows ~123,000 results
> > Code Search of:
> >
> "preg_(filter|grep|last_error|match_all|ma
On Mon, Oct 12, 2009 at 06:34:02PM GMT, Tomas Kuliavas
[to...@users.sourceforge.net] said the following:
>
> preg_quote() and preg_last_error() are support functions. They are used
> together with other pcre functions. You double some search results.
>
> If you have to support something, it is n
hi,
Can you add the link to the bug itself please? We won't loose it thebn :)
Thanks for your work,
On Mon, Oct 12, 2009 at 8:55 PM, Vincent NEGRIER wrote:
> Hi everyone,
>
> I have made a patch to fix this bug: http://bugs.php.net/bug.php?id=45808
>
> Diff against 5.3.0 is here: http://si.kz/p
Mark Krenz wrote:
On Mon, Oct 12, 2009 at 05:55:25PM GMT, Carl P. Corliss [rabb...@gmail.com]
said the following:
Code Search of: "eregi?(_replace)?\( lang:php" shows ~123,000 results
Code Search of:
"preg_(filter|grep|last_error|match_all|match|quote|replace_callback|replace|split)\(
lang:ph
On Mon, Oct 12, 2009 at 05:55:25PM GMT, Carl P. Corliss [rabb...@gmail.com]
said the following:
>
> Code Search of: "eregi?(_replace)?\( lang:php" shows ~123,000 results
> Code Search of:
> "preg_(filter|grep|last_error|match_all|match|quote|replace_callback|replace|split)\(
>
> lang:php" show
Hi everyone,
I have made a patch to fix this bug: http://bugs.php.net/bug.php?id=45808
Diff against 5.3.0 is here: http://si.kz/php-bug-45808.diff.txt
As far as I have tested, everything works as expected with this patch
applied. Can someone with karma please review it and apply to HEAD
and/o
Tomas Kuliavas wrote:
[snip]
Looks like preg_* functions are used more often than ereg* functions to
me...
preg_quote() and preg_last_error() are support functions. They are used
together with other pcre functions. You double some search results.
Actually, searching for those by themselves
[Please stop feeding the troll.]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Oct 12, 2009 at 19:08, Lukas Kahwe Smith wrote:
> Well again an assumption .. no we do not have enough developers to do all
> the cool things we can think up and still fix bugs, document stuff etc. Feel
Shameless plug; http://joind.in/talk/view/971 !
Now, go vote for it so I can do some
On 12.10.2009, at 20:34, Tomas Kuliavas wrote:
2009.10.12 20:55 Carl P. Corliss rašė:
Lukas Kahwe Smith wrote:
[snip]
On 12.10.2009, at 18:57, Mark Krenz wrote:
On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye
[pierre@gmail.com] said the following:
[snip]
But I'm willing to bet th
On Mon, Oct 12, 2009 at 05:08:33PM GMT, Lukas Kahwe Smith [...@pooteeweet.org]
said the following:
> Wow, you sure do assume a lot of things about PHP and its development
> community. I have never seen your name on this list before and (now I
> am assuming) do not know the state of development
On 12.10.2009, at 19:47, Mark Krenz wrote:
If ereg isn't ready yet then 6.0 should be delayed until it is
ready.
It probably never will be...
That's bullshit. Its not like Duke Nukem or something. I've never
seen a major version of PHP take more than a couple years to release
and
PHP
2009.10.12 20:55 Carl P. Corliss rašė:
> Lukas Kahwe Smith wrote:
> [snip]
>
>> On 12.10.2009, at 18:57, Mark Krenz wrote:
>>
>>> On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye
>>> [pierre@gmail.com] said the following:
> [snip]
>
>>> But I'm willing to bet that the majority of people are
2009.10.12 19:22 Mark Krenz rašė:
>
> Just to clarify. You mean that with the changes you've made for
> Unicode support in PHP 6, that current POSIX based ereg expressions will
> not work the same?
Expressions didn't work 1,5 year ago.
http://bugs.php.net/bug.php?id=44923
Maybe current PHP6-de
On Mon, Oct 12, 2009 at 05:34:08PM GMT, Olivier B. [php-dev.l...@daevel.fr]
said the following:
> And as far as I know, using ereg_* function is discouraged in the
> documentation since PHP 4, 10 years ago, no ?
>
Discouraged, no. From looking at archive.org, it looks like there has
been thi
Hello,
On Mon, Oct 12, 2009 at 10:36 AM, Mark Krenz wrote:
> Whenever I bring up an issue like this with the PHP devs, I feel like
> you guys never experience having to support PHP. Among other things, I
> am the main sysadmin for my web hosting company and have been supporting
> PHP since versi
Lukas Kahwe Smith wrote:
[snip]
On 12.10.2009, at 18:57, Mark Krenz wrote:
On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye
[pierre@gmail.com] said the following:
[snip]
But I'm willing to bet that the majority of people are using ereg, not
PCRE. I've known about PCRE in PHP for a
On Mon, Oct 12, 2009 at 05:12:43PM GMT, Christian Schneider
[cschn...@cschneid.com] said the following:
> Mark Krenz wrote:
> > But I'm willing to bet that the majority of people are using ereg, not
> > PCRE. I've known about PCRE in PHP for a while now, but I continue to
> > use ereg because I
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 with queries so it is not needed for
them but only
On Mon, Oct 12, 2009 at 05:12:47PM GMT, Pierre Joye [pierre@gmail.com] said
the following:
>
> Let me use another example to make you understand the situation.
>
> I bought a car, which is great, I can repair it myself, can drive
Car analogies are seldomly an accurate portrayal to the sit
Christian Schneider a écrit :
Mark Krenz wrote:
But I'm willing to bet that the majority of people are using ereg, not
PCRE. I've known about PCRE in PHP for a while now, but I continue to
use ereg because I thought it had better support in PHP and that it was
the more "official" function.
On Mon, Oct 12, 2009 at 1:28 PM, Derick Rethans wrote:
> On Mon, 12 Oct 2009, Mark Krenz wrote:
>
> > Again, this isn't a debate on which is better, I only want to STRONGLY
> > stress that I think its a big mistake to remove it in 6.0.
>
> The ereg library doesn't handle unicode so it can simpl
On Mon, 12 Oct 2009, Mark Krenz wrote:
> Again, this isn't a debate on which is better, I only want to STRONGLY
> stress that I think its a big mistake to remove it in 6.0.
The ereg library doesn't handle unicode so it can simply not work.
> If nobody simply wants to do the work to make sure
This thread inspired me to google for a POSIX to PCRE converter.
I found a thread from this list from 2002:
http://marc.info/?l=php-internals&m=103625548402350&w=2
Ilia proposed a patch that would replace the ereg library
with code that would allow an ereg userland call to be
processed with the P
On 12.10.2009, at 19:12, Pierre Joye wrote:
Shorter version: Topics have been discussed to death, move on,
nothing to see.
actually in the spirit of how i documented the decision about
ifsetor() [1] and the fact that contrary to "popular" opinion, the
time of core devs is limited, it wo
On Mon, Oct 12, 2009 at 6:57 PM, Mark Krenz wrote:
> On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye [pierre@gmail.com]
> said the following:
>>
>> The ereg functions cannot work with Unicode and can't be fixed without
>> rewriting them. Nobody likes to do it as pcre works just fine and h
Mark Krenz wrote:
> But I'm willing to bet that the majority of people are using ereg, not
> PCRE. I've known about PCRE in PHP for a while now, but I continue to
> use ereg because I thought it had better support in PHP and that it was
> the more "official" function. Guess I was wrong. I'm sur
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
Wow, you sure do assume a lot of things about PHP and its development
community. I have never seen your name on this list before and (now I
am assuming) do not know the state of development of PHP6 (as in that
its more or less on halt until someone gets things going again).
On 12.10.2009, a
On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye [pierre@gmail.com] said
the following:
>
> The ereg functions cannot work with Unicode and can't be fixed without
> rewriting them. Nobody likes to do it as pcre works just fine and has
> many active maintainers (inside and outside php).
>
2009/10/12 Samuel ROZE :
> Sorry but what is ABI ?
http://en.wikipedia.org/wiki/Application_binary_interface
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry but what is ABI ?
Le lundi 12 octobre 2009 à 12:50 +0200, Johannes Schlüter a écrit :
> Hi,
>
> On Thu, 2009-10-08 at 23:51 +0200, Samuel ROZE wrote:
> > There is a patch to implements this function into PDO:
> > http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managmen
hi,
On Mon, Oct 12, 2009 at 6:22 PM, Mark Krenz wrote:
>
> Just to clarify. You mean that with the changes you've made for
> Unicode support in PHP 6, that current POSIX based ereg expressions will
> not work the same?
The ereg functions cannot work with Unicode and can't be fixed without
rewri
Just to clarify. You mean that with the changes you've made for
Unicode support in PHP 6, that current POSIX based ereg expressions will
not work the same?
On Mon, Oct 12, 2009 at 04:18:29PM GMT, Rasmus Lerdorf [ras...@lerdorf.com]
said the following:
> Lack of Unicode support is enough of a p
Lack of Unicode support is enough of a problem in that PHP6 will be all
Unicode all the time, so these functions simply won't work as they are
today. It would take someone sitting down and figuring out how to
emulate this stuff in a way that makes sense in a Unicode world for them
to come back, an
Ok, let me first say that I have no problem with deprecating it in
favor of PCRE. Being a heavy Perl developer too, I'm more used to PCRE
syntax anyways so it will be easier to only remember one syntax between
languages.
Secondly, I've been using PHP since version 2 and as far as I can
remem
Guilherme Blanco wrote:
It was fat, slow and everything that you can do with POSIX regex you
can easily do with PCRE regex, which is faster.
It is a decision forever. Do not expect it to come on PHP 5.4 (?) or PHP 6.
Cheers,
On Mon, Oct 12, 2009 at 12:46 PM, Mark Krenz wrote:
I just found t
The real answer is that there is no Unicode support in the ereg
functions, and like it or not, the world is going Unicode.
-Rasmus
Guilherme Blanco wrote:
> It was fat, slow and everything that you can do with POSIX regex you
> can easily do with PCRE regex, which is faster.
>
> It is a decision
It was fat, slow and everything that you can do with POSIX regex you
can easily do with PCRE regex, which is faster.
It is a decision forever. Do not expect it to come on PHP 5.4 (?) or PHP 6.
Cheers,
On Mon, Oct 12, 2009 at 12:46 PM, Mark Krenz wrote:
>
> I just found this out a couple days a
I just found this out a couple days ago when I checked the ereg manual
page for something and was shocked. I searched around a bit but
couldn't find a straight answer on why this function is being removed?
Did the deprecation notice just get made in 5.3 or has it been there
longer than that?
T
Jille Timmermans schrieb:
I have 'implemented' MySQL's mysql_warning_count() function. (
http://dev.mysql.com/doc/refman/5.1/en/mysql-warning-count.html )
mysql_warning_count() is available in MySQL's C-api in >3.23, >4.1 and >5
I am not a big fan of adding anything to ext/mysql that is not sec
Hello all,
Not sure whether this is the right place to post; but it seemed a little bit
better than php...@.
I have 'implemented' MySQL's mysql_warning_count() function. (
http://dev.mysql.com/doc/refman/5.1/en/mysql-warning-count.html )
mysql_warning_count() is available in MySQL's C-api in >3.
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
Dear Internals
Ok... So i figured out that the way to make a scala style multi line
function declaration was simply to do this:
### zend_language_parser.y ###
unticked_function_declaration_statement:
function is_reference T_STRING {
zend_do_begin_function_declaration(&$1, &$3, 0, $
Hi,
On Thu, 2009-10-08 at 23:51 +0200, Samuel ROZE wrote:
> There is a patch to implements this function into PDO:
> http://www.d-sites.com/wp-content/uploads/2009/10/php-5_3-pdo-notices-managment.patch
Just a quick note: This changes the ABI so it can't be done in 5.3.
johannes
--
PHP Intern
Hi,
On Wed, 2009-10-07 at 15:55 +0200, Lukas Kahwe Smith wrote:
> yeah .. its certainly a valid question.
> we have stuff like lastInsertId(), which depending on the driver
> either gets the current value of a sequence or the last id generated
> for the connection.
> so going by that example u
Hi,
On Fri, 2009-10-09 at 15:21 +0200, Samuel ROZE wrote:
> I wanted to change a parameter in my PDO class, with the fourth
> PDO::_construct arg. But, I've many projects, which uses PDO, with one
> "new PDO" per project. The problem is that I have to change the source
> of every projects...
>
>
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
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (101 total -- which includes 44 feature requests)
===[*Compile Issues]==
49270 Open configure fails if PHP source folder path contains spaces
===
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
PHP 5 Bug Database summary - http://bugs.php.net/
Num Status Summary (1513 total -- which includes 967 feature requests)
===[*Compression related]=
49831 Open zlib.output_compression
===[*Di
65 matches
Mail list logo
