/libpq-copy.html
http://www.postgresql.org/docs/8.2/interactive/sql-copy.html
Denis
Denis could you elaborate on what makes use of the COPY code via Sql
behave differently then a PHP method call?
Ilia Alshanetsky
CIO/CSO Centah Inc.
On 2010-05-24, at 15:45, Denis Gasparin denis.gaspa
since when? PDO was designed to allow drivers to provide their own
functions, which many drivers do.
On Mon, May 24, 2010 at 5:16 AM, Lester Caine les...@lsces.co.uk wrote:
Denis Gasparin wrote:
Hi.
I developed some patches for PDO/Postgresql driver in order to add some
useful methods that
Denis,
Could you merge the patches into a single for easier code review. Also, the
copy to/from file seems like it would just be a wrapper against the native
COPY PostgreSQL command, is there really a need to provide a method for it?
On Mon, May 24, 2010 at 4:57 AM, Denis Gasparin
at 2:04 PM, Pierre Joye pierre@gmail.com wrote:
hi Ilia,
On Mon, May 24, 2010 at 7:53 PM, Ilia Alshanetsky i...@prohost.org
wrote:
since when? PDO was designed to allow drivers to provide their own
functions, which many drivers do.
We discussed that on the PDO list, and we try to avoid
I think Kalle's patch is a really good solution for the trunk. +1
On Mon, May 24, 2010 at 8:51 AM, Kalle Sommer Nielsen ka...@php.net wrote:
Hey Ralph
2010/5/21 Ralph Schindler ra...@smashlabs.com:
Hey all,
The first patch is against trunk. I think we should at least get this
done
Denis could you elaborate on what makes use of the COPY code via Sql
behave differently then a PHP method call?
Ilia Alshanetsky
CIO/CSO
Centah Inc.
On 2010-05-24, at 15:45, Denis Gasparin denis.gaspa...@edistar.com
wrote:
I'll provide the patches in a single file as soon as possible
Instead of removing a warning, why not add an additional parameter to the
function that would instruct it to silence warning messages on parse
failure?
On Fri, May 21, 2010 at 11:55 AM, Brian Moon br...@moonspot.net wrote:
+1
Brian.
http://brian.moonspot.net/
On 5/21/10 10:38
Zeev,
There was a comprehensive discussion on this functionality a few months back
on the mailing list and the overall consensus was that the functionality
made sense (as was committed) but was to late in the game to be part of the
5.3 branch. So, now that the trunk has been established it went
Zeev,
First of all as far as I can tell majority of the changes relate to 2 new
type hints you are suggesting to introduce which are numeric and scalar. I
don't see any issue with adding those two hints, predominantly for people
who don't want to be specific with their type requirements. So, +1
Andi,
The existing functionality is very simple (no RFC) needed. It allows for
scalar type hints and ensures that the Z_TYPE of the parameter matches the
indicated type in the declaration, any mistmatch results in an error.
On Sat, May 22, 2010 at 5:46 PM, Andi Gutmans a...@zend.com wrote:
So
Sara,
Could you not treat a very large integer as a double? We do that in a few
areas of the code already.
On Thu, May 20, 2010 at 3:50 PM, Sara Golemon poll...@php.net wrote:
I know this issue has been seen before, but I hope to do something about
it.
$json = '1234567890123456789';
$x =
+1 for a co-RM of Derick and Kalle
On Tue, Apr 27, 2010 at 12:33 AM, Kalle Sommer Nielsen ka...@php.netwrote:
Hi
2010/3/24 Lukas Kahwe Smith m...@pooteeweet.org:
Yeah, lets get that clarified. Derick has stepped up and seems quite
committed and nobody seemed to oppose him RMing the next
+1. I think we need we need to make HEAD a common use branch where
most of the developers trees are at and current HEAD iteration is just
not it.
On 10-03-11 12:22 PM, Rasmus Lerdorf wrote:
Ah, Jani went a little crazy today in his typical style to force a
decision. The real decision is not
Even though the 5.2 code base is fairly mature, it is far from being bug
free. Unit tests are often a good way to identify corner cases that may
not be handled properly even in the stable branches, so more tests IMHO
is a good thing. Until the decision is made to discontinue the 5.2
branch, which
, which is only a month old, so I am
hoping for a really quick release cycle. The next RC will be out two
weeks from now and if all is well, it'll be the final RC. To make this
possible, please test this RC against your code base and report any
problems that you encounter.
Ilia Alshanetsky
PHP 5.2
Each distribution can definitely apply different patches, but in the
case of at least one, improper application or adjustement of the patch
can lead to security holes by itself.
On 10-01-13 12:00 PM, Raphael Geissert wrote:
Daniel Convissor wrote:
Hi Raphael:
On Tue, Jan 12, 2010 at
The change is specific to :: since that is used for classes and causes
confusion as people may think foo::bar will allow definition or
re-definition of a class constant which it does not.
On 09-12-30 2:42 PM, Johannes Schlüter wrote:
Hi,
On Wed, 2009-12-30 at 19:15 +, Ilia Alshanetsky
)
- Fixed bug #50005 (Throwing through Reflection modified Exception
object makes segmentation fault). (Felipe)
- Fixed bug #49174 (crash when extending PDOStatement and trying to set
queryString property). (Felipe)
- Fixed bug #49098 (mysqli segfault on error). (Rasmus)
- Over 50 other bug fixes.
Ilia
Johannes,
While the separate branch release for 5.3.1 was a worthwhile experiment, I
think it creates too much opportunity for missed patches and quite frankly
makes the whole release process confusing and complicated. My personal
preference would be that 5.3.2, not be released from a separate
indication as to why they didn't.
On 2009-12-07, at 8:46 AM, Pierre Joye wrote:
2009/12/7 Ilia Alshanetsky i...@prohost.org:
Johannes,
While the separate branch release for 5.3.1 was a worthwhile experiment, I
think it creates too much opportunity for missed patches and quite frankly
makes
On 2009-12-07, at 8:54 AM, Pierre Joye wrote:
Ilia,
2009/12/7 Ilia Alshanetsky i...@prohost.org:
Pierre,
Actually patches were indeed missed, in fact we almost missed a security fix.
Which? We did review *all* 5.3 commits before going final.
The max # of file uploads was almost
On 2009-12-07, at 9:19 AM, Pierre Joye wrote:
Which? We did review *all* 5.3 commits before going final.
The max # of file uploads was almost missed.
It was not, and we did not forget it because of the automatic TODOs in
the wiki (it shows all commits in a list with their states,
On 2009-12-07, at 9:27 AM, Pierre Joye wrote:
2009/12/7 Ilia Alshanetsky i...@prohost.org:
On 2009-12-07, at 9:19 AM, Pierre Joye wrote:
Which? We did review *all* 5.3 commits before going final.
The max # of file uploads was almost missed.
It was not, and we did not forget
On 2009-12-07, at 9:42 AM, Pierre Joye wrote:
2009/12/7 Ilia Alshanetsky i...@prohost.org:
If anything it shows the system had failed and aside from yourself and
Johannes most developers have no idea what is and isn't part of the release.
More over there is a whole pile patches
. This also makes it confusing for
the users, since the dev fixing the bug indicates on the bug tracker the issue
was resolved, and will be part of the next release. And then the next release
comes out and the bug/issue is still there...
On 2009-12-07, at 9:55 AM, Pierre Joye wrote:
2009/12/7 Ilia
On 2009-12-07, at 10:10 AM, Pierre Joye wrote:
hi,
On Mon, Dec 7, 2009 at 4:05 PM, Larry Adams larryjad...@comcast.net wrote:
What's the status of the SNMP fixes? I see that SNMP is still not in the
5.3.x code.
Don't hijack threads with off topic questions, thanks (and use text email
Rasmus,
Do you think this is an easy fix, or do we need to go back pre-patch code for
5.2.12? The other option is to generate the build on a machine with the later
autoconf, 2.59 seems to work fine.
On 2009-11-27, at 7:30 AM, Rasmus Lerdorf wrote:
Jani Taskinen wrote:
This is caused by the
, that addresses a build problem introduced
by autoconf updates performed in RC2. If you've had issues building RC2, the
RC3 should address the problem. If no other problems creep up we should still
be on track with the final release next week.
Ilia Alshanetsky
PHP 5.2 Release Master
--
PHP
Yes, it would be ;-)
On 2009-11-27, at 10:56 AM, Daniel Brown wrote:
On Fri, Nov 27, 2009 at 10:40, Pierre Joye pierre@gmail.com wrote:
On behalf of Ilia (so the subject typo won't hide the RC3 from testers):
The second release candidate of 5.2.12 was just released for testing
and can
small number of changes since RC1, so I think we are in good
shape for a final release. If nothing major comes up, I anticipate the final
being released next week. To ensure that the release is solid, please test this
RC against your code base and report any problems that you encounter.
Ilia
scheduled
2 weeks from now.
If you do come across any issues, please make them known via a bug
report or a reply to this e-mail.
Ilia Alshanetsky
PHP 5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
please submit any fixes that you have for this branch as
soon as possible.
Thanks,
Ilia Alshanetsky
5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Thanks for the patch, a patch closely based on your was just applied
to SVN.
On 2009-10-03, at 12:40 PM, Florian Anderiasch wrote:
Hello,
I've tried to fix http://bugs.php.net/bug.php?id=49757
As it's my first patch in c, any reviews and suggestions would be very
welcome.
Greetings,
).
Fixed bug #48400 (imap crashes when closing stream opened with
OP_PROTOTYPE flag).
Fixed bug #47351 (Memory leak in DateTime).
Over 60 other bug fixes.
Ilia Alshanetsky
5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
before the final release next week, so I
would like to ask all developers to refrain making commits to the 5.2
branch in the meantime.
Ilia Alshanetsky
PHP 5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
release, which is only a few months old, so
I am hoping for a real quick release cycle. The next RC will be out
two weeks from now and if all is well, it'll be the final RC. To make
this possible, please test this RC against your code base and report
any problems that you encounter.
Ilia
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's
Stas,
While the patch is certainly interesting, I think masking errors is a
really really bad idea.
On 24-Aug-09, at 2:17 PM, Stanislav Malyshev wrote:
Hi!
I've implemented a patch that allows to mask certain types of
errors - i.e. make PHP engine completely ignore them. Now even if
Well, couple of reasons:
1) Once you completely hide an error there is absolutely no trace what
so ever that it has even occurred, even if its the slowdown of the
native error handler being.
2) Debugging code becomes that much more trickier, since a single
option effectively turns off
On 24-Aug-09, at 3:30 PM, Stanislav Malyshev wrote:
Hi!
1) Once you completely hide an error there is absolutely no trace
what so ever that it has even occurred, even if its the slowdown of
the native error handler being.
That's the point. And how the slowdown would be useful?
Because
On 24-Aug-09, at 3:59 PM, Stanislav Malyshev wrote:
There is very little modern code that is @ ridden like the stuff
written
If we discard emotional terms like ridden - there is such code in
almost every major app out there. Just search for @fopen or @include
or @xml or @eval - tons
On 24-Aug-09, at 6:54 PM, Greg Beaver wrote:
2) as long as the patch does not break any backwards compatibility
(error logging still works as it always did independent of error_mask,
user error handlers still get the same stuff), why would we care?
There
is a time and place for being
, which if understand Stas' original message correctly would
equate its value to whatever the error reporting is set to.
On 24-Aug-09, at 10:04 PM, Greg Beaver wrote:
Ilia Alshanetsky wrote:
On 24-Aug-09, at 6:54 PM, Greg Beaver wrote:
2) as long as the patch does not break any backwards
release, which is only a few months old, so
I am hoping for a real quick release cycle. The next RC will be out
two weeks from now and if all is well, it'll be the final RC. To make
this possible, please test this RC against your code base and report
any problems that you encounter.
Ilia
Johannes,
While I am a big believer in release quickly, release often, I think
there are still a fair number of important if not critical bugs and
regressions in 5.3 that should be addressed before 5.3.1 is released.
On 6-Aug-09, at 5:46 PM, Johannes Schlüter wrote:
Hi,
following
of August.
Ilia Alshanetsky
5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Very cool.
Ilia Alshanetsky
On 2009-07-13, at 3:38 PM, David Soria Parra s...@gmx.net wrote:
Hi List,
Quite a few people mentioned that they want to use git as a frontend
to
the svn server. Therefore most of them need an initial import of the
svn.php.net repository using git-svn
execution a bit because of addition checks. I hope, it'll
be possible to use these hints in the future to generate more
optimal code.
+1 for php6 after improvements
Thanks. Dmitry.
Ilia Alshanetsky wrote:
Last week or so there was a fairly detailed discussion on the
internals list
Greg,
the T_CLASS fix you've suggested in your e-mail to me could work, but
calling a type hint class rather then object seems a little
awkward to me. Plus to your point and earlier Stas' e-mail the patch
would reserve the a whole bunch of type based keywords, personally I
feel that this
On 7-Jul-09, at 1:35 PM, Jeff Griffiths wrote:
On 07/07/09 10:17 AM, Andrei Zmievski wrote:
Andrei Zmievski wrote:
I would like to ask all developers to voice their opinions of
whether
it makes sense to add this to 5.3 or to throw it away (either one
is
fine btw). To keep the process
-06 at 20:52 -0400, Ilia Alshanetsky wrote:
Last week or so there was a fairly detailed discussion on the
internals list regarding type hinting based on my original patch.
Having an old 5.3 extension with a typehint expecting an array
arg_info.array_type_hint will be set to 1.
The newly compiled
Rasmus,
Well, 5.3 has been in feature lock for quite some time, its not like
its been a week or two since we went from features in phase to
stabilization phase.
On 7-Jul-09, at 7:14 PM, Rasmus Lerdorf wrote:
Paul Biggar wrote:
- the RFC process has been wilfully ignored (despite
, Andrei Zmievski wrote:
Ilia Alshanetsky wrote:
PHP 6 is too far off in a practical sense (sorry Andrei) from the
time where I can see myself using it in production or other people
benefiting from this function. The (simpler) variant of provided
patch is what is currently being used
On 7-Jul-09, at 8:43 PM, Rasmus Lerdorf wrote:
That doesn't really change the timing, especially since you said you
have been using it for 2 years. Why pick the week after the 5.3
release
to propose it for 5.3? It makes very little sense to me, and I think
consensus is building that we
Last week or so there was a fairly detailed discussion on the
internals list regarding type hinting based on my original patch.
Since then the patch has been revised to address the major concerns
that were identified (breakage of binary compatibility) as well
extended with additional
It should be fine
Ilia Alshanetsky
On 2009-07-04, at 2:49 PM, Paul Biggar paul.big...@gmail.com wrote:
Hi Ilia,
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org
wrote:
There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about
Good point, this way API could remain the same.
On 3-Jul-09, at 9:31 AM, Paul Biggar wrote:
Hi Ilia,
On Wed, Jul 1, 2009 at 7:07 PM, Stanislav Malyshevs...@zend.com
wrote:
The patch is available here: http://ia.gd/patch/type_hint_53.txt
Technical comment: as this patch changes binary API
On 2-Jul-09, at 3:28 AM, Stanislav Malyshev wrote:
Hi!
2) Type hinting will not create a mess of cast to the right types
in the code as Stas had suggested, in close to a million lines of
PHP code we have, I've been able to find less then 1000 (just did a
grep) instances of casts. There
On 2-Jul-09, at 4:45 AM, Paul Biggar wrote:
On Thu, Jul 2, 2009 at 5:26 AM, Ilia Alshanetskyi...@ilia.ws wrote:
1) Strict type hinting helps to solve bugs, both the ones made out of
careless/missing validation as well as subtle logic bugs that often
take
hours to resolve. I can tell you
On 2-Jul-09, at 4:56 AM, Lukas Kahwe Smith wrote:
On 02.07.2009, at 10:45, Paul Biggar wrote:
to work in a future with a library/framework that is strict about
its input
or some far fetched idea that it will change the very nature of PHP.
I don't think we are worried about it changing
Personally, I am uncertain about +int or -int in general, IMO that
compromise will eventually be identical to numeric an cause endless
confusion for the users between (+/-)int and int. The reason I used a
completely different name is to prevent confusion.
On 2-Jul-09, at 8:53 AM, Paul
On 2-Jul-09, at 9:04 AM, Robert Cummings wrote:
Ilia Alshanetsky wrote:
Paul's proposal is some part does not make sense because it allows
weak type hinting, which should not be used if you need type
hinting. The whole idea about type hinting is definition of strict
interfaces
On 2-Jul-09, at 9:23 AM, Robert Cummings wrote:
Ilia Alshanetsky wrote:
On 2-Jul-09, at 9:04 AM, Robert Cummings wrote:
Ilia Alshanetsky wrote:
Paul's proposal is some part does not make sense because it
allows weak type hinting, which should not be used if you need
type hinting
On 2-Jul-09, at 10:02 AM, Paul Biggar wrote:
On Thu, Jul 2, 2009 at 1:53 PM, Ilia Alshanetskyi...@ilia.ws wrote:
Paul's proposal is some part does not make sense because it allows
weak type
hinting, which should not be used if you need type hinting. The
whole idea
about type hinting is
and and requires no changes on the part of an opcode cache such
as APC to work.
My hope is that the latest changes will allow this to become a
standard part of PHP.
Ilia Alshanetsky
P.S.
It should be noted that this is not the first idea for type hints,
that credit goes to Hannes Magnusson who
As far as your point goes, numeric hint addresses it.
Ilia Alshanetsky
CIO/CSO
Centah Inc.
On 2009-07-01, at 2:07 PM, Stanislav Malyshev s...@zend.com wrote:
Hi!
The patch is available here: http://ia.gd/patch/type_hint_53.txt
Technical comment: as this patch changes binary API
Tom,
Type hinting is optional you don't have to use it. However, the
numeric type I've added specifically addresses that point.
Ilia Alshanetsky
CIO/CSO
Centah Inc.
On 2009-07-01, at 1:22 PM, Tom Boutell t...@punkave.com wrote:
I expect this would be a problem for folks who are relying
If you use int type hit 1 will be rejected, but if use numeric type
hint it will be accepted.
Ilia Alshanetsky
On 2009-07-01, at 1:23 PM, Paul Biggar paul.big...@gmail.com wrote:
Hi Ilia,
This is great.
On Wed, Jul 1, 2009 at 5:59 PM, Ilia Alshanetskyi...@prohost.org
wrote:
I've taken
C does not have booleans, they are emulated via smallint/tinyint. As
far as your other message goes, this patch does nothing to affect how
native functions handle args.
Ilia Alshanetsky
On 2009-07-01, at 2:44 PM, Stanislav Malyshev s...@zend.com wrote:
Hi!
As far as your point goes
On 1-Jul-09, at 10:35 PM, Paul Biggar wrote:
- A strong argument against (C) is that this currently has no
parallel with how scalars are handled in PHP currently.
It does not need to have a parallel. PHP as a rule is a type flexible
language, my intention is not to change that, simply
Chris,
I've been using APC with PHP 5.3 on my dev box for sometime now and it
works no worse then it did with 5.2.
Ilia Alshanetsky
On 30-Jun-09, at 10:09 AM, Christian Schneider wrote:
Lukas Kahwe Smith wrote:
The PHP Development Team would like to announce the immediate
release
On 26-Jun-09, at 1:30 PM, Scott MacVicar wrote:
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote:
Aloha,
So the last fix is just being prepared for a commit and so we will
be tagging 5.3.0 soon.
We would like to up hold the commit freeze until 5.3.0 is announced
next Tuesday.
This
= PHP_CURL_FILE
ch-handlers-write-fp) {
+ fflush(ch-handlers-write-fp);
+ }
+
efree(ch-handlers-write);
efree(ch-handlers-write_header);
efree(ch-handlers-read);
Ilia Alshanetsky
On 26-Jun-09, at 6:02 PM, Rasmus Lerdorf wrote:
Pierre Joye wrote
Thanks Scott, it helps to save files before quitting ;-)
Here is the updated patch.
Ilia Alshanetsky
Index: ext/curl/interface.c
===
RCS file: /repository/php-src/ext/curl/interface.c,v
retrieving revision 1.62.2.14.2.57
diff -u
contained to curl so no
external elements are affected by the patch.
Ilia Alshanetsky
On 26-Jun-09, at 8:24 PM, Rasmus Lerdorf wrote:
Just to keep the list in synch with the irc discussion. I pointed out
that this is only half of the fix. The refcount still prevents fclose
from flushing
The patch looks fine to me.
Ilia Alshanetsky
On 17-Jun-09, at 11:43 AM, Scott MacVicar wrote:
Hey,
Bug 48215 was a BC break from the previous 5.2 behaviour, it stemmed
from a change for bug #39127.
class a { function a($arg='') { echo $arg; } }
class b extends a {}
$b = new b;
$b-b
wrong result).
Fixed bug #47365 (ip2long() may allow some invalid values on certain
64bit systems).
Over 100 bug fixes.
Ilia Alshanetsky
5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
your apps to
make sure everything is working properly.
Ilia Alshanetsky
PHP 5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
maintainable. (compare
for example
with the simple constant folder I implemented some years ago:
http://web.ist.utl.pt/nuno.lopes/zend_constant_folding.txt).
This is certainly a much better demonstration of how the optimizer
should work.
The existing optimizer already does constant folding...
Ilia
release, which is only a few months old, so
I am hoping for a real quick release cycle. The next RC will be out a
week from now and if all is well, it'll be the final RC. To make this
possible, please test this RC against your code base and report any
problems that you encounter.
Ilia
Neat idea. Why not open the sqlite db at MINIT rather then RINIT and
add a whole pile of overhead to every request.
Ilia Alshanetsky
On 25-May-09, at 4:57 AM, Patrick ALLAERT wrote:
Hi list,
First, I'd like to apologize if the subject of this mail is somewhat
off-topic.
Davide
the patch looks good.
Ilia Alshanetsky
On 15-May-09, at 11:36 AM, Tjerk Anne Meesters wrote:
Hi Arnaud,
Thanks for the tip, please find patch attached.
Best,
Tjerk
On Fri, May 15, 2009 at 10:58 PM, Arnaud Le Blanc lbarn...@php.net
wrote:
Hi,
On Fri, 2009-05-15 at 22:16 +0800
to roll an RC1 by May 28th, so please get your fixes in.
Thanks,
Ilia Alshanetsky
5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
processing in a safe manner. We can even take it a step further and
make it secondary to ext/filter processing, for some security bits.
Ilia Alshanetsky
On 14-May-09, at 12:57 PM, Andrei Zmievski wrote:
Request decoding is one of a few remaining pieces of the Unicode
puzzle. The proposed
This is a new feature, so it would be more appropriate for 5.3/6 more
so then for 5.2 IMHO.
Ilia Alshanetsky
On 14-May-09, at 1:39 PM, Andrei Zmievski wrote:
Ilia Alshanetsky wrote:
We have a fair number of fixes in the 5.2 branch already and while
5.3 is making very good progress I
Maybe only allow people who ran make test and submitted the results
during the RC phase to submit bugs, eh? ;-)
Ilia Alshanetsky
On 14-May-09, at 2:49 PM, Jani Taskinen wrote:
Ilia Alshanetsky kirjoitti:
We have a fair number of fixes in the 5.2 branch already and while
5.3 is making
Andrei,
I think Moriyoshi has a point here there are several reports by people
who are affected by this, I think it makes sense to leave the
introduced functionality as is in 5.3/6, but for PHP 5.2 it probably
should be rolled back.
Ilia Alshanetsky
On 14-May-09, at 2:21 PM, Moriyoshi
Andrei,
There is no question about functionality being useful for some people.
But what is the point of different branches if we put whatever we want
into each branch? We may as well stick to one branch and commit
features, bug fixes, etc... into it.
Ilia Alshanetsky
On 14-May-09, at 2
Should be fine
Ilia Alshanetsky
On 14-May-09, at 3:14 PM, Moriyoshi Koizumi wrote:
Ilia, do you still see any problem merging this to 5.2?
Moriyoshi
On Sat, Apr 11, 2009 at 6:16 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
Ilia?
I guess the chances of getting this merged
If we are simply changing the declaration that should be fine, is
there a patch available for review?
Ilia Alshanetsky
On 14-May-09, at 4:04 PM, Pierre Joye wrote:
hi Ilia,
On Thu, May 14, 2009 at 8:54 PM, Andrei Zmievski and...@gravitonic.com
wrote:
Jani Taskinen wrote:
It's
Last I checked it was working properly, are you sure you are using the
latest version? I think we even have a test case around this bug.
Ilia Alshanetsky
On 19-Apr-09, at 7:09 AM, Hannes Magnusson wrote:
On Sat, Apr 18, 2009 at 23:48, Nuno Lopes nlop...@php.net wrote:
The original code
Are you using CGI or CLI sapi?
Ilia Alshanetsky
On 19-Apr-09, at 12:16 PM, Hannes Magnusson wrote:
I'm pretty sure yes.
Try copying the run-tests.php from 5_2 to 5_3 and run the PDO tests
with it.
Then diff the run-tests to see the workaround in 5.3.
-Hannes
On Sun, Apr 19, 2009 at 17
The initial type change does the trick for the formula itself. And
yes, the code relies on an integer being 64bit
Ilia Alshanetsky
On 15-Apr-09, at 2:05 PM, Matt Wilmas wrote:
Hi Ilia,
- Original Message -
From: Ilia Alshanetsky
Sent: Wednesday, April 15, 2009
iliaa Wed
IMHO any extension name should be reserved as a namespace.
Ilia Alshanetsky
On 30-Mar-09, at 7:56 PM, Paul Biggar wrote:
On Tue, Mar 31, 2009 at 12:28 AM, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
If nobody proposes something, this will just slide by ..
It seems simple enough to add
I believe that this is a feature, so it would not go into 5.2, sorry.
Ilia Alshanetsky
On 2-Mar-09, at 11:21 AM, Richard Quadling wrote:
Hi.
Regarding http://bugs.php.net/bug.php?id=47493, I've supplied a patch
to the unit tests too.
Any chance this could get committed to 5.2+
Index
or not. Andrei's patch broke the
backwards compatibility that affects real-world applications and thus
cannot be regarded as an improvement.
Moriyoshi
On Thu, Feb 26, 2009 at 11:51 AM, Ilia Alshanetsky
i...@prohost.org wrote:
Moriyoshi,
My opinion is that the current implementation is valid, which is why
and if your
comments are validated via user feedback we can adjust the values with
5.2.10 that can be repackaged fairly rapidly. IMHO the current
functionality is desired and is acceptable.
Ilia Alshanetsky
On 26-Feb-09, at 1:58 PM, Moriyoshi Koizumi wrote:
Robin Burchell wrote:
On Thu, Feb 26
While a very useful feature, I think people who need it definitely
will have the ability to run 2-3 commands that it takes to install a
PECL extension.
Ilia Alshanetsky
On 26-Feb-09, at 6:28 PM, Pierre Joye wrote:
Hi,
What's about adding what screan (http://pecl.php.net/scream
on your argument we may as well drop PECL and put all extensions
into core.
Ilia Alshanetsky
On 26-Feb-09, at 6:40 PM, Richard Quadling wrote:
Ilia, but us poor, useless, can't compile a shopping list, windows
users need binaries. So making it core would be nice.
--
-
Richard Quadling
incorrect results
on 64 bit linux). (Matt)
Over 50 bug fixes.
Ilia Alshanetsky
5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
101 - 200 of 978 matches
Mail list logo
