Hi,
s...@geleia.net wrote:
On Tue, May 18, 2010 8:22 am, Dmitry Stogov wrote:
I'm proposing another optimisation technique implementation for PHP
which makes up to 20% speed up on synthetic tests and up to 8% speed up on
real-life applications.
The technique is similar to "inline caches" which
On Tue, May 18, 2010 8:22 am, Dmitry Stogov wrote:
> I'm proposing another optimisation technique implementation for PHP
> which makes up to 20% speed up on synthetic tests and up to 8% speed up on
> real-life applications.
>
> The technique is similar to "inline caches" which is very popular in JI
On May 24, 2010, at 12:42 PM, Stas Malyshev wrote:
> Hi!
>
> The patch below seems to fix ext/intl (and maybe others) compile problems on
> Mac OS X. The problem seems to be because C++ needs libstdc++ and for some
> reason it doesn't get added on Mac.
>
> Could people having build problems o
On Mon, 2010-05-24 at 14:56 -0400, Ilia Alshanetsky wrote:
> As one of the original authors of PDO that is news to me. PDO was designed
> to allow common functionality to be provided via a common interface, however
> it was also designed to recognize that not all database interfaces are the
> same.
The copy to/from sql statements accept both as main parameter a filename or
stdout/stdin respectively.
The filename represents a file in the database filesystem (apache/php and
postgresql must reside on the same machine or share the file via shared
filesystem). I quote from the postgresql man
On Mon, May 24, 2010 at 10:46 PM, Christopher Jones
wrote:
>
> Thanks Dmitry - that's great.
I second that, useful info for people with time issues like us :)
> Also thanks to Stas for his reply.
>
> Chris
>
> Dmitry Stogov wrote:
>>
>> Hi Chris,
>>
>> I've added notes for extension maintainers.
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
wrote:
I'll provide the patches in a single file as soon as possible.
Actually all the methods ar
Pierre Joye wrote:
On Mon, May 24, 2010 at 8:56 PM, Ilia Alshanetsky wrote:
Pierre,
As one of the original authors of PDO that is news to me. PDO was designed
to allow common functionality to be provided via a common interface, however
it was also designed to recognize that not all database int
Thanks Dmitry - that's great.
Also thanks to Stas for his reply.
Chris
Dmitry Stogov wrote:
Hi Chris,
I've added notes for extension maintainers.
I hope they will answer all your questions.
Thanks. Dmitry.
Christopher Jones wrote:
Dmitry Stogov wrote:
>> > http://wiki.php.net/rfc/runt
I attached the patch as a single file.
There are currently no tests written for the new methods.
I'll provide them if needed to integrate the patch in the pdo_pgsql driver.
Denis
- Messaggio originale -
> Da: "Denis Gasparin"
> A: "Ilia Alshanetsky"
> Cc: internals@lists.php.net
> I
I'll provide the patches in a single file as soon as possible.
Actually all the methods are wrappers against the native PostgreSQL commands
(connection status, copy to/from).
I needed to develop them as methods because it is not possible to get the same
results with a sql statement (in particu
Hi!
The patch below seems to fix ext/intl (and maybe others) compile
problems on Mac OS X. The problem seems to be because C++ needs
libstdc++ and for some reason it doesn't get added on Mac.
Could people having build problems on Mac see if this fixes the problem
for them (buildconf/re-confi
On 24.05.2010 21:54, Ilia Alshanetsky wrote:
> Denis,
>
> Could you merge the patches into a single for easier code review.
Hint: `diff -u` produces a bit more human-readable patch.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime Develo
hi,
On Mon, May 24, 2010 at 8:58 PM, Ilia Alshanetsky wrote:
> I think Kalle's patch is a really good solution for the trunk. +1
Same here, with a couple of changes like killing the warning (and the
related flag) as well as removing the duplicated code. I will do that
before applying it.
Cheers
On Mon, May 24, 2010 at 8:56 PM, Ilia Alshanetsky wrote:
> Pierre,
> As one of the original authors of PDO that is news to me. PDO was designed
> to allow common functionality to be provided via a common interface, however
> it was also designed to recognize that not all database interfaces are th
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 wrote:
> Hey Ralph
>
> 2010/5/21 Ralph Schindler :
> >
> > Hey all,
> >
> > The first patch is against trunk. I think we should at least get this
> done
> > even if the group
Pierre,
As one of the original authors of PDO that is news to me. PDO was designed
to allow common functionality to be provided via a common interface, however
it was also designed to recognize that not all database interfaces are the
same. And as such allowed driver authors to provide custom func
On Mon, May 24, 2010 at 8:10 PM, Alexey Zakhlestin wrote:
> Limiting ourselves to Least Common Denominator is not the best idea.
And adding vendors specific stuff all around is a very bad idea. See
the ones we have now in PDO::
I think it is time to figure how we can do it in the most clean and
On 24.05.2010, at 22:04, Pierre Joye wrote:
> hi Ilia,
>
> On Mon, May 24, 2010 at 7:53 PM, Ilia Alshanetsky 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 to add drive
hi Ilia,
On Mon, May 24, 2010 at 7:53 PM, Ilia Alshanetsky 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 to add drivers
specific methods. That's obviously makes sense given th
Hi Chris,
I've added notes for extension maintainers.
I hope they will answer all your questions.
Thanks. Dmitry.
Christopher Jones wrote:
Dmitry Stogov wrote:
>> > http://wiki.php.net/rfc/runtimecache
>> >
>> > The patch breaks binary and source compatibility but it's not
hard to
>
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
wrote:
> Hi.
>
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 wrote:
> Denis Gasparin wrote:
>
>> Hi.
>>
>> I developed some patches for PDO/Postgresql driver in order to add some
>> useful methods that were ava
Hi!
If I understand what you implied later in your email, calls to
zend_hash_copy should be replaced with calls to
object_properties_init. Is this always true? Is this the only
That's probably not so. As I understand, the patch changes the way the
object properties are accessed. So if your
Dmitry Stogov wrote:
>> > http://wiki.php.net/rfc/runtimecache
>> >
>> > The patch breaks binary and source compatibility but it's not hard to
>> > adopt extensions to use it.
>>
>> Hi Dmitry,
>>
>> Can update the RFC to explain the breakage and
>
> It's clear from the patch. The same is ex
Hi!
In case we remove 'Array->scalar' and others everywhere, #3 would be the
same as #2. I'm for that.
AFAIK parse_parameters already rejects Array->scalar, so if we can tweak
it so that it would make sense for all cases, even better.
As for implicit/explicit casts, I'm not sure - it might mak
Stas Malyshev wrote:
Hi!
I see three key options going forward:
1. Implement the table along the lines of what it looks like now,
perhaps with minor changes.
2. Implement identical conversion rules to the ones that exist in
PHP; That effectively turns type hinting into scalar casting
operat
At 18:39 24/05/2010, Daniel Convissor wrote:
On a side note, I hope the hinting will allow the ability to do something
something like "int|null" for graceful handling of optional parameters.
There was an idea to allow null if you use 'int foo = null' - but
only that particular use case (e.g.,
Hi Zeev:
On Mon, May 24, 2010 at 08:09:30AM +0300, Zeev Suraski wrote:
>
> 1. Implement the table along the lines of what it looks like now,
> perhaps with minor changes.
> 2. Implement identical conversion rules to the ones that exist in PHP;
> That effectively turns type hinting into scalar
Hey Ralph
2010/5/21 Ralph Schindler :
>
> Hey all,
>
> The first patch is against trunk. I think we should at least get this done
> even if the group decides that down the line we want the why portion
> explained as well (I actually don't care about the why part). That feature
> would require tha
On Mon, May 24, 2010 1:12 pm, Zeev Suraski wrote:
>
> Sounds acceptable to me, that's along the lines of the 3rd option
> which appears to be getting the most traction. I'd also no conversion of
> arrays to scalars to that list.
>
Arrays to scalars already fail. See
http://wiki.php.net/rfc/typech
At 14:48 24/05/2010, s...@geleia.net wrote:
Adding strict typing would be the largest
> inconsistency in PHP's core syntax, ever.
I disagree. The === operator already checks the type of the variables.
We can agree to disagree regarding the level of understanding the
average PHP developer has
On Mon, May 24, 2010 at 1:48 PM, wrote:
> I think the best option is to align the type checking with
> zend_parse_parameters (this is not the same as an implicit cast) and make
> it stricter. This includes:
> * disallow string to float/int when it contains non-numeric characters
> (includes "123a
On Mon, May 24, 2010 6:09 am, Zeev Suraski wrote:
> At 03:53 24/05/2010, s...@geleia.net wrote:
>> On Sun, May 23, 2010 9:33 pm, Etienne Kneuss wrote:
>>> On Sat, May 22, 2010 at 17:04, Zeev Suraski wrote:
>>>
As one of the key people who designed PHP's type system I consider
strict type
hi,
I will apply the patch to trunk later today as it seems that we have
no objection for the patch itself. The proposal to add more
information on failure can be implemented later, if someone fills
motivated enough to do it.
Cheers,
--
Pierre
On Sat, May 22, 2010 at 5:28 PM, Pierre Joye wrot
Denis Gasparin wrote:
I developed some patches for PDO/Postgresql driver in order to add some useful \
methods that were available in the original pgsql driver.
p...@lists.php.net is the right place for PDO development ;)
Ops sorry :-) I will post the patches also to that list.
But more im
Denis Gasparin wrote:
>> Hi.
>>
>> I developed some patches for PDO/Postgresql driver in order to add some
>> useful \
>> methods that were available in the original pgsql driver.
>p...@lists.php.net is the right place for PDO development ;)
Ops sorry :-) I will post the patches also to that
Denis Gasparin wrote:
Hi.
I developed some patches for PDO/Postgresql driver in order to add some useful
methods that were available in the original pgsql driver.
p...@lists.php.net is the right place for PDO development ;)
But more important, any NEW functions should be generic. Otherwise w
Hi.
I developed some patches for PDO/Postgresql driver in order to add some useful
methods that were available in the original pgsql driver.
The attached patches apply on 5.3.2 and svn 5.3.x.
If needed, i have patches also for 5.2.x.
Please comment and tell me improvements or tips.
Thank you
On Mon, May 24, 2010 at 2:12 PM, Brian Moon wrote:
> Because that is, IMO, a bad precedent to start for PHP internal functions.
> Too many functions already produce warnings (fopen) and return a status that
> can be checked. The solution right now is @ and that has so much baggage
> with it that y
40 matches
Mail list logo
