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 p
>> 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 wi
>>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 stab
> 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 c
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 better,
After the updates it looks really good, very handy functionality to have.
On Tue, Oct 30, 2012 at 6:18 PM, Sara Golemon 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 to hear if an
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 subsequ
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 wrote:
> Hi!
>
>
>> I wanted to make this new version available in PHP5.4 but
>> unfortunately I did finish my work when it w
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 PM
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 wrote:
> Hey all,
>
> As promised, I've created a POC patch to im
Option #1 seems like a good way to go to me.
On Fri, Mar 2, 2012 at 7:34 AM, Pierre Joye 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 #1, as it giv
The change is inside 5.4 version which adjust breaks BC.
---
Ilia
On Dec 27, 2011 10:15 AM, "Patrick ALLAERT" wrote:
> 2011/12/27 Ilia Alshanetsky :
> > I think the REQUEST_TIME semantics of returning float should remain as
> is.
> >
> > -1 for adding fur
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 wrote:
> On Tue, 27 Dec 2011, Pierre Joye wrote:
>
>> On Tue, Dec 27, 2011 at 1:19 PM, Derick Rethans wrote:
>>
>> > Ah, that o
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 cos
Seems like a good change +1.
On Sun, Dec 4, 2011 at 7:55 AM, Alan Knowles wrote:
> This is ready for review now.
>
> https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323002696
>
> This resolves the worst behavior changes introduced by the dereferen
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
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 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 ternary operator
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, F
Seems like a fine solution, performance loss would occur only when
error happens...
On Tue, Oct 11, 2011 at 5:30 AM, Laruence 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 think this is
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 wrote:
> Hi!
>
> On 9/8/11 6:04 PM, Kalle Sommer Nielsen wrote:
>
Revert sounds find to me, the change was indeed to fix the test.
On Wed, Aug 31, 2011 at 6:58 AM, Christian Stocker
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 guess is he just f
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 wrote:
> Hi Internals,,
>
> after 3 weeks of discussion, I think we are ready to start v
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 wrote:
> 2011/8/22 Mads Lie Jensen :
>> On Mon, 22 Aug 2011 10:00:11 +0200, hannes.magnus...@gmail.com (Hannes
>> Magnusson) wrote:
>>
>>>I can reproduc
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
dows 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
of type 'struct zval *'
> /tmp/buildd/php5-5.3.99+5.4.0/ext/xsl/xsltprocessor.c:283: error: too
> many arguments to function 'php_dom_create_object'
>
> Full log: https://drupaltesting.org/jenkins/job/php5.4-build/237/consoleFull
>
> Damien
>
> On Mon, Aug 8,
Thanks, I've just applied a fix for this.
On Mon, Aug 8, 2011 at 10:45 AM, Damien Tournoud wrote:
> Just FYI, this commit broke the build:
>
> http://svn.php.net/viewvc?view=revision&revision=314515
>
> One occurrence as been missed in:
>
> ext/xsl/xsltprocessor.c: DOM_RE
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 wro
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 wrote:
> Thanks!
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Develo
the NEWS file found within the archive or on
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_7RC4/NEWS?revision=HEAD&view=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 Mailin
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 wrote:
> Hi!
>
> Here are the results of the votes. I've split th
within the archive or on
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_7RC3/NEWS?revision=HEAD&view=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, vi
?revision=HEAD&view=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 Al
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 wrote:
> foreach() has many functions, looping over arrays, objects and implementing
> the iterator interface. I think it's also quite in
+1, seems useful.
On Mon, Jun 20, 2011 at 8:02 AM, Robert Eisele 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 smarter if o
The crash is now fixed as well.
On Fri, Jun 3, 2011 at 2:41 AM, Felipe Pena wrote:
> 2011/6/2 Felipe Pena
>
>> Hi,
>>
>> 2011/6/2 Michael Maclean
>>
>>> On 02/06/11 18:20, Gustavo Lopes wrote:
>>>
>>>> Em Thu, 02 Jun 2011 18:10:5
Sounds fine to me.
On Thu, Jun 2, 2011 at 10:24 PM, Stas Malyshev 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 5.4
> being:
> St
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 ALLAER
easier for me :).
>
> Cheers,
>
> On Wed, Jun 1, 2011 at 12:30 AM, Ilia Alshanetsky 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
>>
>
On Wed, Jun 1, 2011 at 4:27 PM, Sean Coates 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 (which interfa
ug
fixes makes this very non-trivial and time consuming, which is why
Johannes' proposal is so appealing.
2011/6/1 Pierre Joye :
> hi,
>
>
> 2011/6/1 Johannes Schlüter :
>> On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
>>> > This variant is not workable,
Sounds reasonable.
2011/6/1 Johannes Schlüter :
> 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
>> >
> 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,
> wh
I do not believe so.
On Wed, Jun 1, 2011 at 12:35 AM, Stas Malyshev 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 don't kn
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 there
On Tue, May 31, 2011 at 11:59 PM, Rasmus 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?
&
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 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
>> seems to have ea
Stas,
Why would you use eval() as opposed to json_decode() ?
On Tue, May 31, 2011 at 11:25 PM, Stas Malyshev 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 something like:
>
>
t; and would like to be counted, that would be great too.
>
> PHP SVN account holder voters
> =
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf, Stanislav
> Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
>
> Contra: A
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 wrote:
>>-Original M
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 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 be pretty simple (se
+1
On Mon, Feb 7, 2011 at 8:26 PM, Gustavo Lopes 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 (normal) IEEE 754
net/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
age 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://www.php.net/unsub.php
On Thu, Dec 9, 2010 at 5:14 AM, Andrey Hristov 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 anyway.
I do no
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
To
-1
I don't think this is necessary.
On Wed, Nov 10, 2010 at 4:31 PM, Jonah H. Harris 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 sugar (0b1011010
As long as a modifier (public|private|protected) is still required, +1.
2010/11/27 Johannes Schlüter :
> Hi,
>
> every now and then while writing classes I forget to add the "function"
> keyword between my visibility modifier and the method name in a class
> declaration. I don't think it is requir
+1
Seems like a handy change and the patch is quite manageable.
On Fri, Nov 26, 2010 at 2:36 PM, Felipe Pena wrote:
> Hi all,
> I'm here again to presents another proposal, which adds support for
> instantiating a class and calling its methods and accessing its properties
> on same command.
>
>
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 6:
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 at
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 specif
> 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 P
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 :
> Hi,
>
> On Mon, 2010-11-22 at 23:21 -0200, Felipe
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 wrote:
> On 11/23/2010 10:57 AM
+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 wrote:
> without $var it would be possible to compile break/continue into
> ZEND_FREE/ZEND_SWITCH_FREE and ZEND_JMP.
>
> I also thought it would allow to r
+1 for removing it.
On Wed, Nov 17, 2010 at 11:08 AM, Kalle Sommer Nielsen wrote:
> Greetings
>
> I wanted to raise this topic before we go Alpha with trunk, regarding
> our beloved magic_quotes feature. There seems to be mixed opinions
> regarding it so I thought I would take it up for discussio
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 &
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 wrote:
> On Nov 01 15:33:59, Derick Rethans wrote:
>> Hi!
>>
>> Work has been done on rewriting the PHP parser to Lemon in a
+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 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 internal chang
Stas,
Having E_FORTY_TWO would be super-useful ;-)
On Tue, Aug 24, 2010 at 1:47 PM, Stas Malyshev 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
> between constant
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 fut
+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 wrote:
> Hi!
>
> I think by now, whatever you think on strict typing/typehints, it is clear
> to everybody tha
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 wrote:
> At 01:47 11/08/2010, Stas Malyshev wrote:
>>
>> Hi!
>>
>>> For the record: I consider the curre
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 wrote:
>> They aren't hints. It is strict typing and in its current form I would
>> ask you guys not to call
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 wrote:
> Hi!
>
>> Might be
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 wrote:
> Can I get an affirmation if the pdo dblib code will be accepted in 5.2
> and 5.3 branches?
>
> --
> PHP Internals - PHP Runtime Development M
Go ahead, if you have karma, more tests are always welcome.
On Sun, Jun 27, 2010 at 8:17 PM, Stanley Sufficool 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 tests to trunk?
>
>
I believe it is a *nix specific patch.
On Tue, Jun 22, 2010 at 6:49 PM, Kalle Sommer Nielsen wrote:
> 2010/6/22 Ilia Alshanetsky :
>> 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,
>
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,
which is pretty important for opcode caches such as PHP.
On Mon, Jun 21, 2010 at 6:21 PM, Derick Rethans wrote:
> On Tue, 22 Jun 2010, Kalle Sommer Nielsen wrote
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 te
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
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,
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 wrote:
> Hi!
>
>> Can you elaborate? What "average user"-facing features are non-obvious?
>>
se it do... "in
core" does not mean that you must use it.
On Sun, Jun 20, 2010 at 8:15 PM, jvlad wrote:
> "Ilia Alshanetsky" wrote in message
> news:86a0c51a-e6f7-48f2-a065-eabe74c6a...@prohost.org...
>> Several reasons:
>>
>> 1) APC is well maintained,
tives from existing...
Ilia Alshanetsky
CIO/CSO
Centah Inc.
On 2010-06-20, at 17:32, Lester Caine wrote:
Rasmus Lerdorf wrote:
On 6/20/10 2:05 PM, Lester Caine wrote:
Rasmus Lerdorf wrote:
On 6/20/10 1:21 PM, Lester Caine wrote:
( Foregot to change address again :( )
Ilia Alshanetsky wrote
Sure, but that's win32 only
Ilia Alshanetsky
CIO/CSO
Centah Inc.
On 2010-06-20, at 16:54, Derick Rethans 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 vie
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 wrote:
> Greetings
>
> As the process for trunk grows, I think we should consider whi
g fix" 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
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 wrote:
> On Wed, Jun 16, 2010 at 1:04 PM, Ilia Alshanetsky
> wrote:
> > Pierre,
> > If they are using PDO there are no issue, but wh
hould be
added boat-load of wrappers for SQLite3 extension...
On Tue, Jun 15, 2010 at 2:18 PM, Pierre Joye wrote:
> hi Ilia,
>
> On Tue, Jun 15, 2010 at 1:41 PM, Ilia Alshanetsky
> wrote:
> > After speaking to a few developers in DPC, I think it makes sense for us
> to
>
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 i
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 wrote:
> On 15 June 2010 19:41, Ilia Alshanetsky wrote:
> > After speaking to a few developers in DPC, I think it ma
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, I'
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
> On Thu, 2010-06-10 at 12:11 +0000, Ilia Alshanetsky wrote:
> > Modified: php/php-src/branches/PHP_5_3/ext/pdo/ph
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 wrote:
> On Sat, Jun 12, 2010 at 12:24 PM, Pierre Joye
> wrote:
>
n.
>
> Cheers,
> --
> Pierre
>
> On Thu, Jun 10, 2010 at 2:12 PM, Ilia Alshanetsky
> 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
s boolean.
>The format of the rows stored into the file is indicated in the
> $delimiter, $null and $fields parameters.
>Parameters:
> * (mandatory) $table: table to retrieve data from.
> * (mandatory) $filename: file where to store the contents of the
> table
&
andatory) $filename: file where to store the contents of the
> table
> * $delimiter: alternative delimiter to use in place of the standard
> postgres delimiter ("\t")
> * $null: alternative string to use as null value. Default is "\N"
>* $fields:
in advance,
> Denis
>
>
> - Messaggio originale -
> > Da: "Denis Gasparin"
> > A: "Ilia Alshanetsky" , "Matteo Beccati" <
> p...@beccati.com>
> > Cc: internals@lists.php.net, "pdo"
> > Inviato: Mercoledì,
1 - 100 of 1081 matches
Mail list logo
