de some more
features, but it would be great to keep the divergence to the strict
minimum.
Cheers,
--
Raphael Geissert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Pierre Joye wrote:
> On Thu, Jul 29, 2010 at 11:44 PM, Raphael Geissert
> wrote:
>> As it seems, the best and maintainable solution is to switch to some
>> other alternative library (sadly, there's no such candidate atm.)
>
> What make you think that c-client is d
Raphael Geissert wrote:
> As it seems, the best and maintainable solution is to switch to some other
> alternative library (sadly, there's no such candidate atm.)
Actually, I wonder if the imap extension shouldn't be dropped altogether in
trunk. The libraries written in PHP a
ere was a discussion in 2004 for FC2 about the situation of
libc-client, but besides that: nothing.
As it seems, the best and maintainable solution is to switch to some other
alternative library (sadly, there's no such candidate atm.)
HTH
--
Raphael Geissert
--
PHP Internals - PHP Runti
Raphael Geissert wrote:
> Johannes Schlüter wrote:
>
> Although I would have preferred you wait for me to submit each patch
> individually with enough information (because I've only been like two
> years co-maintaining the packages and most patches were added by others,
> a
Johannes Schlüter wrote:
> On Thu, 2010-03-18 at 22:10 -0600, Raphael Geissert wrote:
>> At the moment dba is the best place to add support for tokyo cabinets
>> without introducing major features (or a pecl extension).
>
> "without introducing major features" do
ply it.
Cool.
Johannes, would it be ok to merge support for tokyo cabinets into PHP_5_3?
Cheers,
--
Raphael Geissert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sebastian Bergmann wrote:
> Am 18.03.2010 19:10, schrieb Raphael Geissert:
>> I was considering adding support for tokyo cabinets, would that still
>> be acceptable for 5.3.x?
>
> I think something like that should go into a PECL extension.
I would actually be happy if
that still be
acceptable for 5.3.x?
Cheers,
--
Raphael Geissert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
any patches (probably more than those
we included in 5.2.6 for lenny, because of our current work to get the
testsuite to pass).
Cheers,
--
Raphael Geissert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Raphael Geissert wrote:
> Pierre Joye wrote:
>>
>> What patch? Please do not commit anything there without first posting
>> to the list. There were enough breakage in this area, no need to
>> introduce new ones again.
>>
No objection then?
> Here it is:
Derick Rethans wrote:
> On Mon, 22 Feb 2010, Raphael Geissert wrote:
>>
>> gcc 4.4's optimiser removes the overflow check present in
>> php_filter_parse_int and ZEND_HANDLE_NUMERIC (but I can't touch that part
>> of the code anyway...) which prev
idate_int.patch;hb=3061d111de130df7388cc78e26b63cc105574775
Like Sean stated on his post to the list, the engine is also affected.
Somebody would need to apply the patch there.
Cheers,
--
Raphael Geissert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
Derick Rethans wrote:
> What exactly are you trying to fix here?
>
gcc 4.4's optimiser removes the overflow check present in
php_filter_parse_int and ZEND_HANDLE_NUMERIC (but I can't touch that part of
the code anyway...) which prevents the overflow from being detected.
Che
dea.
>
> Poratability was indeed the reason, as well as the locale issues that
> you mention (POSIX locales==useless). Please don't commit this.
>
Ok. Sean came up with a different patch which is being tested right now.
If all the tests pass then I'm going to commit it.
Cheer
is available).
>
Ah, I see, great.
>From a quick look at the code it looks like it also uses pcntl.
Is there any plan to switch to that other implementation?
No work has been done in something like the threads extension, has there?
Cheers,
--
Raphael Geissert
--
PHP Internals - PHP R
Raphael Geissert wrote:
>
> If there's no objection, I would like to remove them entirely and use
> strtol in php_filter_int.
>
By the way, I don't think that the fact that strtol is locale-aware should
be a reason to make the change. Since scripts are expected to use
Hi,
I've spent the last hours working on making run-tests.php be able to run
tests in parallel. The main reason being the time it takes to run the whole
testsuite even on multicore CPUs.
Attached is the first set of changes needed. It uses pcntl's fork and
sysvmsg to send some of the results b
ere's no objection, I would like to remove them entirely and use strtol
in php_filter_int.
Cheers,
--
Raphael Geissert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Squash bugs on the test suite and code
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ing to change PHP
> here, I'd be going after your problematic edge cases and bringing them
> up to speed so they can support per-app configuration.
>
That would be the ideal situation. Sadly it is not that easy to accomplish,
hence the need to support more configuration optio
sions and the various other attempts people have
>> made doesn't work.
>
> Oops, missed the thread link:
>
> http://lists.gnu.org/archive/html/autoconf/2009-11/msg00100.html
>
I see, thanks for the pointer.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.deb
6#10
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jani Taskinen wrote:
> On 01/17/2010 05:19 AM, Raphael Geissert wrote:
>> Jani Taskinen wrote:
>>
>>> 16.1.2010 20:10, Raphael Geissert wrote:
>>>> Some of the other patches include:
>>>> libdb_is_-ldb
>>>
>>> Why? Potentially br
Jani Taskinen wrote:
> 16.1.2010 20:10, Raphael Geissert wrote:
>> Some of the other patches include:
>> libdb_is_-ldb
>
> Why? Potentially breaks things when you assume db/ being correct place..
Do you have an example of any actual case?
>
>> 115-autoconf_ft
You should at least ad an "echo 'done';" or such to the expect
>section to make sure it really works ...
Could be added, yes, but in case it fails it would lead to a segfault.
>
> I skipped the patches related to build system and such and maybe skipped
&g
Patrick ALLAERT wrote:
> 2010/1/13 Derick Rethans :
>> On Tue, 12 Jan 2010, Raphael Geissert wrote:
>
> [snip]
>
>> Would it be possible to force short_open_tag to a specific value for
>> those applications alone? Perhaps through an .htaccess file? That way,
&g
Rasmus Lerdorf wrote:
> Raphael Geissert wrote:
>> I'm still looking for a way to warn about the use of open_short_tag not
>> being explicitly enabled on the PERDIR level. Otherwise the only thing I
>> see would make applications change would be when the default is Off a
, do you enable one of the php.ini-* files by default? Which?
> Perhaps with a few other changed values to meet the defaults, like with
> short_open_tag?
On 5.2 and older we use -dist. On 5.3 we will take -production as a base but
we have not yet decided what other changes we are going to mak
e would be when the default is Off and they
break.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
patch is Debian specific or just bringing in something done by
> the PHP team itself.
Only the debian-quirks and php.ini_securitynotes patches are really Debian-
specific. The rest should find its way to the upstream code (but some of the
patches were not accepted in the past).
Cheers,
--
Raphael Gei
Rasmus Lerdorf wrote:
> Raphael Geissert wrote:
>> However, we would like to contribute in the quest to make applications
>> stop using short_open_tag. To do so, we have decided to throw an
>> E_DEPRECATED warning when an application makes use of short_open_tag. The
>>
Daniel Convissor wrote:
> Hi Raphael:
>
> On Tue, Jan 12, 2010 at 02:48:38PM -0600, Raphael Geissert wrote:
>> As a first step I'll be trying to forward most of our
>> patches so that there's a minor divergence.
>
> Is there a document somewhere that expla
Johannes Schlüter wrote:
> Hi,
>
> On Tue, 2010-01-12 at 14:48 -0600, Raphael Geissert wrote:
>> Hello,
>>
>> At Debian we are planning to include PHP 5.3 in Squeeze, the next stable
>> release. As such, I would like to know for example when we could expect
so that it later migrates to testing.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
=blob;f=debian/patches/deprecate_short_open_tag;h=57a79c6215afdc8654c6d18e791a9b7c8f5e373b
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Derick Rethans wrote:
> On Tue, 12 Jan 2010, Raphael Geissert wrote:
>
>> At Debian we are planning to include PHP 5.3 in Squeeze, the next stable
>> release. As such, I would like to know for example when we could expect
>> 5.3.2 and 5.3.3 to be released.
>
> 5.3
en us (the package maintainers) and you (the
upstream developers). As a first step I'll be trying to forward most of our
patches so that there's a minor divergence.
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
--
PHP Internals - PHP Runtime Deve
Hannes Magnusson wrote:
[...]
> We really need to work on our relationship with other distros,
> starting with marking security fixes as security fixes.
Yes, please do mark them as such.
>
> -Hannes
>
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian
39 matches
Mail list logo
