Zeev has an excellent point here, my own research shows that 5.4, a
year after release had somewhere in the 2% adoption rate. The major
reason being is the lack of a stable, production ready op-code cache.
To release 5.5 without a good solution for that problem, would not
make the situation
To be fair, the 5.5 situation without pulling in ZO+ is NOT the same as 5.4
was. Today, right now, there exists at least one stable open source opcode
cache. 5.4 had none for many months after release. So I'm not sure if the
same pressures exist.
If you are referring to APC as the stable
Well the question around the delay, is what is the negative
consequence of the delay, versus the advantage of having a built-in
opcode cache shipped as part of 5.5 which is likely to give many
people an impetuous to upgrade from their current 5.2/5.3 install.
If we get to get it stable in a
If you are referring to APC as the stable cache, that unfortunately is
not entirely correct, it is still relatively easy to crash APC unless
some work-arounds are applied. I was speaking to a several people at
the conference just yesterday and they were indicating frequent
crashes with APC,
The APC issues are somewhat APC specific in most cases, they often
revolve around memory utilization issues and garbage collection. Some
of the work-arounds involve ensuring APC always has extra memory to
prevent fragmentation. When fragmentation goes about 35-40% clearing
out the entire cache to
After the updates it looks really good, very handy functionality to have.
On Tue, Oct 30, 2012 at 6:18 PM, Sara Golemon poll...@php.net wrote:
With the exception of renaming the UConverter::UCNV_* constants to
remove the UCNV_ prefix, I believe I've addressed the concerns thus
far. ((Waiting
Sounds like a least dangerous way of solving the problem to me. The
only issue I can see with this fix is what would happen is if after
the PG(max_input_vars) = max_vars;
call the request got interrupted in persistent environment such as
Apache (mod_php). Wouldn't that means that for
The oop interface to cURl is already available, take a look at
http://pecl.php.net/package/pecl_http extension. It provides OOP
interface and takes care of many of the input preparation or output
parsing tasks normally you need to do in PHP when working with cURL.
On Sat, Mar 10, 2012 at 12:49
Stas,
That could work for people who don't have cURL built-in to their PHP
version, but otherwise create a symbol conflict.
On Sun, Mar 11, 2012 at 3:33 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I wanted to make this new version available in PHP5.4 but
unfortunately I did finish
Anthony,
My concern with this type of patch is that what you are proposing are
not really hints, they are forced casts. As such they modify the data
potentially leading to data loss.
On Thu, Mar 8, 2012 at 9:32 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
As promised, I've created
Option #1 seems like a good way to go to me.
On Fri, Mar 2, 2012 at 7:34 AM, Pierre Joye pierre@gmail.com wrote:
hi,
It should have been done before 5.4.0 was out, but better late than never.
I put together four options here:
https://wiki.php.net/rfc/php53eol
I'm in favor of option
The change is inside 5.4 version which adjust breaks BC.
---
Ilia
On Dec 27, 2011 10:15 AM, Patrick ALLAERT patrickalla...@php.net wrote:
2011/12/27 Ilia Alshanetsky i...@ilia.ws:
I think the REQUEST_TIME semantics of returning float should remain as
is.
-1 for adding further environment
I think the REQUEST_TIME semantics of returning float should remain as is.
-1 for adding further environment variables.
On Tue, Dec 27, 2011 at 7:52 AM, Derick Rethans der...@php.net wrote:
On Tue, 27 Dec 2011, Pierre Joye wrote:
On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans der...@php.net
In most instances integers and floats can be used interchangeably,
which is why the patch was written in the way that it was. In the few
rare cases (int) cast takes care of the trick, there is a substantial
benefit for timings etc... to have higher precision timestamp
available at no additional
I agree with Stas' point there is really no need to force people do
the while (ob_get_level()) ob_end_clean(); loop or force people to
use the @ob_end_clean(); to avoid notices. If there are no buffers to
clear it should be a noop, without any notices being raised.
On Fri, Nov 18, 2011 at 12:04
Unless you are deleting thousands of files in a tight loop, the
overhead involved won't make any difference for your application.
In general your application is throwing many errors, even benign
E_STRICT or E_NOTICE you are already incurring a performance hit.
On Mon, Oct 17, 2011 at 3:49 AM,
Seems like a good patch, +1 from me on inclusion into 5.4/HEAD.
On Fri, Oct 14, 2011 at 2:08 PM, Arnaud Le Blanc arnaud...@gmail.com wrote:
Hi,
I've already posted this patch and it has since been reviewed and improved.
I'm re-posting it for discussion before eventually commiting it.
The
Seems like a fine solution, performance loss would occur only when
error happens...
On Tue, Oct 11, 2011 at 5:30 AM, Laruence larue...@php.net wrote:
Hi:
I filed a bug about SIGALRM(or SIGPROF) has chance to cause
segfault in php_error_cb. https://bugs.php.net/bug.php?id=60038
do you
The agreement to include apc in 5.4 is an old one, unfortunately the
action of doing was just missed. Also, inclusion of the extension
won't break any code since it is self contained...
On Thu, Sep 8, 2011 at 9:07 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
On 9/8/11 6:04 PM, Kalle
Revert sounds find to me, the change was indeed to fix the test.
On Wed, Aug 31, 2011 at 6:58 AM, Christian Stocker
christian.stoc...@liip.ch wrote:
On 31.08.11 12:25, Laruence wrote:
Hi:
I think you should not commit untill ask ilia for the reason of
previous change,
sure, but my
If we do decide to make a VCS change the vote should be fairly one
sided for option of choice as this has a fairly broad impact on our
development process.
On Wed, Aug 24, 2011 at 5:03 PM, David Soria Parra d...@php.net wrote:
Hi Internals,,
after 3 weeks of discussion, I think we are ready to
The fix looks good, Dmitry can you please review it, if it is good
let's get it into 5.3.8
On Mon, Aug 22, 2011 at 6:33 AM, Kalle Sommer Nielsen ka...@php.net wrote:
2011/8/22 Mads Lie Jensen m...@gartneriet.dk:
On Mon, 22 Aug 2011 10:00:11 +0200, hannes.magnus...@gmail.com (Hannes
Magnusson)
The PHP development team would like to announce the immediate
availability of PHP 5.3.7. This release focuses on improving the
stability of the PHP 5.3.x branch with over 90 bug fixes, some of
which are security related.
Security Enhancements and Fixes in PHP 5.3.7:
* Updated crypt_blowfish to
users please mind that we don't provide VS6 builds anymore
since PHP 5.3.6.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Scott,
I've looked through most of the changes (some are even mine ;-) ) and
they seem to be fairly harmless initialization tweaks etc... As it
stands I think we should be in good shape to package 5.3.7 on Wed and
finally get it out of the door.
On Mon, Aug 8, 2011 at 3:18 AM, Scott MacVicar
Thanks, I've just applied a fix for this.
On Mon, Aug 8, 2011 at 10:45 AM, Damien Tournoud d...@damz.org wrote:
Just FYI, this commit broke the build:
http://svn.php.net/viewvc?view=revisionrevision=314515
One occurrence as been missed in:
ext/xsl/xsltprocessor.c:
Damien
On Mon, Aug 8, 2011 at 6:06 PM, Ilia Alshanetsky i...@prohost.org wrote:
Thanks, I've just applied a fix for this.
On Mon, Aug 8, 2011 at 10:45 AM, Damien Tournoud d...@damz.org wrote:
Just FYI, this commit broke the build:
http://svn.php.net/viewvc?view=revisionrevision=314515
Unless something changes, I think we are going to go from RC4 to final release.
On Wed, Aug 3, 2011 at 8:29 PM, James Yu jym2...@gmail.com wrote:
Thanks!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP
to
the NEWS file found within the archive or on
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_7RC4/NEWS?revision=HEADview=markup
Windows users please mind that we don't provide VS6 builds anymore
since PHP 5.3.6.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
Stas,
On the Remove magic quotes there seems to be an overwhelming support
from PHP Core and the community for removing it. Any reason there is
no definitive decision on the topic?
On Sun, Jul 17, 2011 at 5:08 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Here are the results of the
within the archive or on
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_7RC3/NEWS?revision=HEADview=markup
Windows users please mind that we don't provide VS6 builds anymore
since PHP 5.3.6.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
?revision=HEADview=markup
Windows users please mind that we don't provide VS6 builds anymore since
PHP 5.3.6. When using the openssl extension please mind a known
regression which might lead to a performance degression. This regression
will be fixed with RC2 and the final release.
Ilia Alshanetsky
+1, seems useful.
On Mon, Jun 20, 2011 at 8:02 AM, Robert Eisele rob...@xarg.org wrote:
Negative string offsets is a wish and also an implementation of my running
PHP version for long. It operates in the same fashion like substr() with
negative offsets, but avoids the function call and is much
As long as it works on a premise that a string is a byte array and
each element represents 1 byte, +1 from me.
On Mon, Jun 20, 2011 at 7:27 AM, Robert Eisele rob...@xarg.org wrote:
foreach() has many functions, looping over arrays, objects and implementing
the iterator interface. I think it's
The crash is now fixed as well.
On Fri, Jun 3, 2011 at 2:41 AM, Felipe Pena felipe...@gmail.com wrote:
2011/6/2 Felipe Pena felipe...@gmail.com
Hi,
2011/6/2 Michael Maclean mich...@no-surprises.co.uk
On 02/06/11 18:20, Gustavo Lopes wrote:
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia
,
On Wed, Jun 1, 2011 at 12:30 AM, Ilia Alshanetsky i...@prohost.org wrote:
Since we are on the topic of reviewing past RFCs for 5.4, can we take
another look at the Zend Signals RFC:
https://wiki.php.net/rfc/zendsignals
The patch is solid (have been using it in production for quite some
I like the idea of an error message when this happens, but as few
other people in the thread had mentioned, I think it should be a
warning (E_WARNING) because the conversion results in data loss
(content of the array is replaced with Array string).
On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERT
Sounds fine to me.
On Thu, Jun 2, 2011 at 10:24 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
We're having pretty lively discussion on the list, twitter and other places,
but let's not forget the big goal of 5.4 :)
1. First of all, the official business. Any objections to the RMs for
This variant is not workable, because there are (in the example) in 2014
*five* branches. Merging between those, manually and automatically is
going to be a major pain. I'd say we all rather want to focus our time
on fixes and new features; and not spend more time doing branch merging,
Sounds reasonable.
2011/6/1 Johannes Schlüter johan...@schlueters.de:
On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
This variant is not workable, because there are (in the example) in 2014
*five* branches. Merging between those, manually and automatically is
going
this very non-trivial and time consuming, which is why
Johannes' proposal is so appealing.
2011/6/1 Pierre Joye pierre@gmail.com:
hi,
2011/6/1 Johannes Schlüter johan...@schlueters.de:
On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
This variant is not workable, because
On Wed, Jun 1, 2011 at 4:27 PM, Sean Coates s...@seancoates.com wrote:
This discussion seems to lack real-world examples…
Derick wrote:
I'm still -1 on it. It makes absolutely unreadable code (yes, also in
JavaScript with f.e. MongoDB).
Here's an actual snippet from my production code
, Rasmus Lerdorf, Stanislav
Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
Contra: Antony Dovgal, Derick Rethans, Jani Taskinen, Lokrain, Felipe Pena,
Lukas Kahwe Smith, Marcus Boerger, David Soria Parra, Johannes Schlüter,
Maciek Sokolewicz, Philip Olson, Ilia Alshanetsky, Daniel Brown
Stas,
Why would you use eval() as opposed to json_decode() ?
On Tue, May 31, 2011 at 11:25 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Stas, I didn't understand your point about eval() and security. What did
you mean?
I meant if PHP has JSON syntax as native, e.g. you can say
Rasmus,
Don't you think having support for both ['a':1, 'b':2] and {'a':1,
'b':2} would create confusion?
On Tue, May 31, 2011 at 11:16 PM, Rasmus ras...@lerdorf.com wrote:
On 05/31/2011 11:52 AM, Sean Coates wrote:
I'm one of the people who've brought it up on Twitter. Today's discussion
On Tue, May 31, 2011 at 11:59 PM, Rasmus ras...@lerdorf.com wrote:
On 05/31/2011 02:45 PM, Ilia Alshanetsky wrote:
Rasmus,
Don't you think having support for both ['a':1, 'b':2] and {'a':1,
'b':2} would create confusion?
Not if we present this as native json support in PHP. Then we have
Since we are on the topic of reviewing past RFCs for 5.4, can we take
another look at the Zend Signals RFC:
https://wiki.php.net/rfc/zendsignals
The patch is solid (have been using it in production for quite some
time) and improvement is quite helpful, especially when APC is being
used. Are
I do not believe so.
On Wed, Jun 1, 2011 at 12:35 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
The patch is solid (have been using it in production for quite some
time) and improvement is quite helpful, especially when APC is being
used. Are there any reasons not to apply this to 5.4?
I think an idea of an alpha right away is a good one. I feel we
definitely have enough stuff in HEAD branch right now for 5.4 +/-
few minor changes. It should also be a good boost to getting people on
track that 5.4 is a go.
On Wed, May 11, 2011 at 2:03 PM, Andi Gutmans a...@zend.com wrote:
Seems like a good plan to me. Hopefully as per schedule it gets us 5.4
this year.
On Sun, May 8, 2011 at 7:40 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I has been almost a month since we did our routine talk about 5.4, so here
it goes again. The patch for the scalar hints seems to
+1
On Mon, Feb 7, 2011 at 8:26 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
The default serialize precision is currently [1] set at 100. A little code
inspection shows precision, in this case, takes the usual meaning of number
of significant digits.
Given that the implicit precision of a
/ChangeLog-5.php#5.2.16. For source downloads please
visit our downloads page on http://php.net/downloads.php, Windows
binaries can be found on http://windows.php.net/download/.
Ilia Alshanetsky
5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On Thu, Dec 9, 2010 at 5:14 AM, Andrey Hristov p...@hristov.com wrote:
Hi guys,
the topic says most of it. What do you think about deprecating the global
keyword and $GLOBALS with it? Together with this making $_REQUEST, $_GET and
$_POST read-only as they should be used only to read-only
://php.net/downloads.php,
Windows binaries can be found on http://windows.php.net/download/.
Ilia Alshanetsky
5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
. This way we can avoid
last minute regressions, especially so for the 5.2.15 release, which
is the final one in that series.
Ilia Alshanetsky Johannes Schlüter
PHP 5.2 Release Master PHP 5.3 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
-1
I don't think this is necessary.
On Wed, Nov 10, 2010 at 4:31 PM, Jonah H. Harris jonah.har...@gmail.com wrote:
Hey all,
I was recently working on some code which made use of bit arrays and I came
across feature request 50648: Format for binary numbers. While it's just
more syntactic
As long as a modifier (public|private|protected) is still required, +1.
2010/11/27 Johannes Schlüter johan...@schlueters.de:
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
+1
Seems like a handy change and the patch is quite manageable.
On Fri, Nov 26, 2010 at 2:36 PM, Felipe Pena felipe...@gmail.com 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
Looking through trunk I think we are in pretty good shape. I don't
think cherry-picking and branch merging is an issue at this point. A
5.4 with the performance improvements, Traits, minus the type hinting
breakage is something we can get out pretty quickly without causing any
sort of PHP 6
I think there is much to gain by improving the serialization speed in
PHP. It is used everywhere from caches like memcache, to sessions or
manual data input into DB. I would say that there are very few
non-trivial apps that would not benefit from a more compact and faster
serializer.
In our
Just read over the BSON spec, looks fairly interesting, the only bit
that appears to be missing for PHP purposes is object support. We
would need to introduce custom type on top of standard BSON. However
from compactness and consistency standpoint it looks fairly appealing.
On Thu, Nov 25, 2010
I don't think the version # makes that much of a difference, but
rather what is in it. That said, people have made a good point that
jumping to something like 7, would allow us to skip the baggage
associated with PHP6, which seems like a fairly compelling argument to
me.
On Thu, Nov 25, 2010 at
I too must second Mike's comments about pecl_http not being quite
ready for bundling. The extension provides some useful functionality,
no doubt (I use it ;-)). But I don't think there is a good case for
bundling it.
On Tue, Nov 23, 2010 at 7:40 AM, Michael Wallner m...@php.net wrote:
On
I think support 5 or even 3 parallel versions will be highly
impractical and extra-ordinarily challenging. I think we need a plan
that limits us to 2 versions and perhaps a 3rd one for critical
security fixes only.
2010/11/23 Johannes Schlüter johan...@schlueters.de:
Hi,
On Mon, 2010-11-22 at
+1 for removing it.
On Wed, Nov 17, 2010 at 11:08 AM, Kalle Sommer Nielsen ka...@php.net 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 for
+1 to removing it. I think now that we have goto, this functionality
does not make much sense.
On Fri, Nov 19, 2010 at 9:06 AM, Dmitry Stogov dmi...@zend.com wrote:
without $var it would be possible to compile break/continue into
ZEND_FREE/ZEND_SWITCH_FREE and ZEND_JMP.
I also thought it
is the last release before EOL
that was announced this summer, the goal of this release is to
finalize the various key and security fixes that were made since the
last release. When it comes to 5.3.4, this is just a regularly
scheduled bug-fix release.
Ilia Alshanetsky
Johannes Schlüter
5.2 5.3
+1 to adding APC to trunk, it does compile fine (at least at the moment).
On Mon, Nov 1, 2010 at 3:34 PM, Derick Rethans der...@php.net wrote:
Hi!
I understand that the general idea is to bundle APC with a future
version of PHP. Right now, APC doesn't really compile for trunk because
of
We should probably stick with the bison parser for now, at least until
the lemon matches the speed of the existing solution.
On Mon, Nov 1, 2010 at 3:41 PM, Etienne Kneuss col...@php.net wrote:
On Nov 01 15:33:59, Derick Rethans wrote:
Hi!
Work has been done on rewriting the PHP parser to
Stas,
Having E_FORTY_TWO would be super-useful ;-)
On Tue, Aug 24, 2010 at 1:47 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Rhetorical question: Why do we need constants when the values never
change? :)
You seriously don't know why one needs constants or don't see a difference
I think that weak type-hinting defeats the whole purpose of the
feature and I would rather not have it than have a non-obvious
implementation.
-1
On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski z...@zend.com wrote:
At 01:47 11/08/2010, Stas Malyshev wrote:
Hi!
For the record: I consider the
+1, I think that's the most sensible solution for now that would allow
us to proceed with 5.4, something we all seem to be in agreement on.
On Wed, Aug 11, 2010 at 2:30 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I think by now, whatever you think on strict typing/typehints, it is
Pierre,
With all due respect, there are plenty of things already in trunk to
make it a worth while effort to start planning the 5.4 release. Just
because you disagree, an opinion you are entitled to (like everyone
else), does not mean it is a no go, last I checked no one had veto
powers on the
Sounds like a reasonable name change. PHP never really had
type-hinting since even array or Object type hints would throw out
any value that didn't precisely match the requested type by the
method/function declaration.
On Tue, Aug 10, 2010 at 8:53 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Sascha,
Does this mean @group authorizes use of NoPHP as a name for a
derivative PHP version (gotta ask according to the license) ? ;-)
On Tue, Aug 10, 2010 at 7:04 PM, Sascha Schumann sas...@schumann.net wrote:
They aren't hints. It is strict typing and in its current form I would
ask you
PHP 5.2 branch is really for bug fixes only, so new functionality
should be introduced into it.
On Fri, Jul 2, 2010 at 10:11 AM, Stanley Sufficool ssuffic...@gmail.com wrote:
Can I get an affirmation if the pdo dblib code will be accepted in 5.2
and 5.3 branches?
--
PHP Internals - PHP
Go ahead, if you have karma, more tests are always welcome.
On Sun, Jun 27, 2010 at 8:17 PM, Stanley Sufficool ssuffic...@gmail.com wrote:
I have several tests to submit for ext/pdo_dblib.
I have karma to submit patches for ext/pdo_dblib, do I need a blessing
to submit ext/pdo_dblib/tests
I believe it is a *nix specific patch.
On Tue, Jun 22, 2010 at 6:49 PM, Kalle Sommer Nielsen ka...@php.net wrote:
2010/6/22 Ilia Alshanetsky i...@prohost.org:
We may also want to include the signals patch as part of the commit,
as that both enhances speed and makes critical sections more safe
...@lsces.co.uk wrote:
Ilia Alshanetsky wrote:
The test was done on Windows... I never said it was IIS only, it is
however
win32 only.
Sorry - Most people using it will no have bought win64 yet was the point and
the
test was done on win32 as far as I can tell. Anyway Pierre keeps saying that
64
I for one think it is a really good idea, there is no compelling
reason not to include APC, I would even go as far as say we should
enable it by default.
+1
On Sat, Jun 19, 2010 at 9:23 AM, Kalle Sommer Nielsen ka...@php.net wrote:
Greetings
As the process for trunk grows, I think we should
Sure, but that's win32 only
Ilia Alshanetsky
CIO/CSO
Centah Inc.
On 2010-06-20, at 16:54, Derick Rethans der...@php.net wrote:
On Sun, 20 Jun 2010, Rasmus Lerdorf wrote:
On 6/20/10 1:21 PM, Lester Caine wrote:
( Foregot to change address again :( )
Ilia Alshanetsky wrote:
What are your
it do... in
core does not mean that you must use it.
On Sun, Jun 20, 2010 at 8:15 PM, jvlad d...@yandex.ru wrote:
Ilia Alshanetsky i...@prohost.org wrote in message
news:86a0c51a-e6f7-48f2-a065-eabe74c6a...@prohost.org...
Several reasons:
1) APC is well maintained, by the same people who work
Stas,
Even if the extension is compiled by default, we can (and probably
should) leave apc.enabled at Off, recognizing some the things you are
mentioning.
On Sun, Jun 20, 2010 at 10:44 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Can you elaborate? What average user-facing features are
The point is that it would be there for people to use, with as little
effort as possible, which would be changing 1 byte inside the INI
file. The issues APC is having with certain code is not specific to
APC, and does happen with other open source caches. Perhaps we need to
examine the validity of
Stas,
If there is a better alternative to APC we can bundle with PHP, I am
definitely open to exploring that idea. However the alternatives I am
familiar either are closed source or have licences incompatible with
PHP, and that's without getting into the better argument.
On Sun, Jun 20, 2010 at
variety. To ensure that the release is solid,
please test this RC against your code base and report any problems
that you encounter.
Ilia Alshanetsky
PHP 5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
be
added boat-load of wrappers for SQLite3 extension...
On Tue, Jun 15, 2010 at 2:18 PM, Pierre Joye pierre@gmail.com wrote:
hi Ilia,
On Tue, Jun 15, 2010 at 1:41 PM, Ilia Alshanetsky i...@prohost.org
wrote:
After speaking to a few developers in DPC, I think it makes sense for us
Why not just have a PHP based wrapper that would extend SQLite3 class as
SQLite2 equivalent...
On Wed, Jun 16, 2010 at 7:17 AM, Pierre Joye pierre@gmail.com wrote:
On Wed, Jun 16, 2010 at 1:04 PM, Ilia Alshanetsky i...@prohost.org
wrote:
Pierre,
If they are using PDO there are no issue
Pierre,
That is not your decision, since when do you decide what goes into PDO,
that's a decision between the extension maintainer and the release master
and since you are neither...
On Mon, Jun 14, 2010 at 12:06 PM, Pierre Joye pierre@gmail.com wrote:
On Sat, Jun 12, 2010 at 12:24 PM,
I'll adjust the code to simply use in_txn flag for the moment to avoid the
structure change.
2010/6/14 Johannes Schlüter johan...@schlueters.de
On Thu, 2010-06-10 at 12:11 +, Ilia Alshanetsky wrote:
Modified: php/php-src/branches/PHP_5_3/ext/pdo/php_pdo_driver.h
After speaking to a few developers in DPC, I think it makes sense for us to
drop the Sqlite2 extensions from Trunk as they are superseded by the Sqlite3
extensions. The sqlite2 library is no longer maintainer and the migration
path from version 2 to 3 is very simple. Unless there any objections,
Just to clarify, removal does not mean deletion, it would simply become a
PECL extension people who need it can still use.
On Tue, Jun 15, 2010 at 9:30 AM, Adam Harvey ahar...@php.net wrote:
On 15 June 2010 19:41, Ilia Alshanetsky i...@prohost.org wrote:
After speaking to a few developers
There is way too much code that uses ext/mysql and ext/mysql does not depend
on a legacy library, I don't think we can remove it. As far as mssql, it is
the one way to talk to Microsoft SQL from *nix systems, until there are good
alternatives for a direct interface, I don't think we should remove
at 2:12 PM, Ilia Alshanetsky i...@prohost.org
wrote:
I've added the transaction code as a generic method inTransaction(), by
default it'll just use in_txn internal parameter, but allows the driver
to
extend this (as was done in PostgreSQL) and provide a detailed status
code.
On Wed, May
of the standard
postgres delimiter (\t)
* $null: alternative string to use as null value. Default is \N
* $fields: string with table fields to include in the row of the
array. Fields are separated by comma
- Messaggio originale -
Da: Ilia Alshanetsky i...@prohost.org
A: Denis
as null value. Default is \N
* $fields: string with table fields to include in the row of the
array. Fields are separated by comma
- Messaggio originale -
Da: Ilia Alshanetsky i...@prohost.org
A: Denis Gasparin denis.gaspa...@edistar.com
Cc: internals@lists.php.net
Inviato
in advance,
Denis
- Messaggio originale -
Da: Denis Gasparin denis.gaspa...@edistar.com
A: Ilia Alshanetsky i...@prohost.org, Matteo Beccati
p...@beccati.com
Cc: internals@lists.php.net, pdo p...@lists.php.net
Inviato: Mercoledì, 26 maggio 2010 13:11:17
Oggetto: Re: [PHP-DEV
Zeev,
Auto-conversion does not validate input to the function/method, it merely
obfuscates the wrong input by converting it to desired type resulting in a
potentially un-expected value. I must say I am completely against the
auto-conversion hint idea.
As far as your example goes consider a
Brian,
What we are talking about here is an **optional** feature for user-land
function that allow the author to implement really cheap input-validation to
facilitate ensuring that the correct input is supplied. Additionally it also
allows for better language interrogation for auto-generation of
27, 2010 at 7:03 AM, Arvids Godjuks arvids.godj...@gmail.comwrote:
Why not do the check and let auto converting for int = float, int =
string, string = int, string = float when it doesn't loose any
precision.
2010/5/27 Ilia Alshanetsky i...@prohost.org:
Zeev,
Auto-conversion does
1 - 100 of 978 matches
Mail list logo
