At 19:47 25.08.2003 -0400, you wrote:
4.3.3 is essentially RC4 with a small interbase fix that resolves a bug
introduced in RC3 into the interbase extension.
Ilia
And you reintroduced the rand() bug with ZTS builds on solaris :(
I sent you the test report.
Uwe
--
PHP Internals - PHP Runtime Develo
It would also have to be a new 4.4 branch as it breaks binary
compatibility for extensions.
-Rasmus
On Tue, 26 Aug 2003, Jani Taskinen wrote:
>
> That diff seems to revert some fixes made in the branch..
>
> --Jani
>
>
> On Mon, 25 Aug 2003, Sebastian Bergmann wrote:
>
> > Since nobod
On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:
> It would also have to be a new 4.4 branch as it breaks binary
> compatibility for extensions.
It is far from being usable in mainstream as it relies on various
GCC features in many places. Of course, using portable C is
a requirement for b
On Tue, 26 Aug 2003, Sascha Schumann wrote:
> On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:
>
> > It would also have to be a new 4.4 branch as it breaks binary
> > compatibility for extensions.
>
> It is far from being usable in mainstream as it relies on various
> GCC features in many places
> As long as there are appropriate checks and fallbacks, I see no problem
> using compiler-specific hacks. Especially in cases where it would benefit
> a large percentage of users.
Run-time execution time is not everything, otherwise the
whole world would still be using Assembler for all
On Monday, August 25, 2003, at 09:51 PM, Sascha Schumann wrote:
As long as there are appropriate checks and fallbacks, I see no
problem
using compiler-specific hacks. Especially in cases where it would
benefit
a large percentage of users.
Run-time execution time is not everything, otherwis
On Tue, 26 Aug 2003, Sascha Schumann wrote:
> > As long as there are appropriate checks and fallbacks, I see no problem
> > using compiler-specific hacks. Especially in cases where it would benefit
> > a large percentage of users.
>
> Run-time execution time is not everything, otherwise the
>
> >> As long as there are appropriate checks and fallbacks, I see no
> >> problem
> >> using compiler-specific hacks. Especially in cases where it would
> >> benefit
> >> a large percentage of users.
> >
> > Run-time execution time is not everything, otherwise the
> > whole world would sti
On Monday, August 25, 2003, at 10:15 PM, Sascha Schumann wrote:
Anyway, George, don't turn this into an off-topic thread.
The patch is not ready for primetime yet and no amount of
arguing will change that.
How is pointing out the bogusness of your arguments going off-topic?
George
--
> > Hacks often adversely affect maintainability of any given
> > system. For example, the computed goto hack relies on
> > separate definitions of all opcodes. Failing to keep this
> > list up to date can result in subtle, hard to diagnose
> > failures which is undesirable fo
On Mon, 25 Aug 2003, George Schlossnagle wrote:
>
> On Monday, August 25, 2003, at 10:15 PM, Sascha Schumann wrote:
> > Anyway, George, don't turn this into an off-topic thread.
> > The patch is not ready for primetime yet and no amount of
> > arguing will change that.
>
> How is poin
On Tue, 26 Aug 2003, Sascha Schumann wrote:
> > > Hacks often adversely affect maintainability of any given
> > > system. For example, the computed goto hack relies on
> > > separate definitions of all opcodes. Failing to keep this
> > > list up to date can result in subtle, hard
Hi there.
People using Debian GNU/Linux boxes can use the unofficial=20
php4-4.3.3 debian packages, that I just released.
They are compiled from the official 4.3.3 sources, with debian packaging
scripts (expected to be compatible with future official debian
releases).
Notice that they are optimi
> In a stable codebase, where features are not being added
> anymore, performance-oriented hacks are quite appropriate.
are we a bit obsessed with the hacks? :-)
the patch contains some optimizations which don't rely on gcc
features and some fixes. it is prudent to consider these
At 06:41 PM 8/25/2003 -0700, Rasmus Lerdorf wrote:
On Tue, 26 Aug 2003, Sascha Schumann wrote:
> On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:
>
> > It would also have to be a new 4.4 branch as it breaks binary
> > compatibility for extensions.
>
> It is far from being usable in mainstream as it
Hello,
I have a question about imap_append function.
Why don't you (or php developers) use this patch in new php release? :
http://www.zend.com/lists/php-dev/200303/msg00843.html
We must patch every php source code, if we want to use the append function
with date argument.
Thanks, by
Zsozso
--
On Tue, 26 Aug 2003, Sascha Schumann wrote:
> On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:
>
> > It would also have to be a new 4.4 branch as it breaks binary
> > compatibility for extensions.
>
> It is far from being usable in mainstream as it relies on various
> GCC features in many plac
> On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:
>
> > It would also have to be a new 4.4 branch as it breaks binary
> > compatibility for extensions.
>
> It is far from being usable in mainstream as it relies on various
> GCC features in many places. Of course, using portable C is
> a r
On Tue, 2003-08-26 at 05:15, Guillaume Plessis wrote:
> They are compiled from the official 4.3.3 sources, with debian packaging
> scripts (expected to be compatible with future official debian
> releases).
Here is an idea: how about integrating the Debian packaging script with
the main PHP CVS co
This one time, at band camp, Per Lundberg <[EMAIL PROTECTED]> wrote:
> Here is an idea: how about integrating the Debian packaging script with
> the main PHP CVS code? This is done with some other Debian packages,
> and it helps a lot for people who want to build a package from CVS...
How about
Le Tue, Aug 26, 2003 at 19:29:35 +1000, Kevin Waterson a écrit:
> This one time, at band camp, Per Lundberg <[EMAIL PROTECTED]> wrote:
>
>
> > Here is an idea: how about integrating the Debian packaging script with
> > the main PHP CVS code? This is done with some other Debian packages,
> > and
On 2003-08-25 14:54:48, Ard Biesheuvel wrote:
> Casting to void* instead of void** cures the problem. As the cast
Yes, but why?
> I would consider it a justified change. I don't think there will be
> consequences for the validity of the optimization.
I don't know if with some optimizations void*
On Tue, 2003-08-26 at 11:29, Kevin Waterson wrote:
> > Here is an idea: how about integrating the Debian packaging script with
> > the main PHP CVS code? This is done with some other Debian packages,
> > and it helps a lot for people who want to build a package from CVS...
> How about including pa
On Tue, 2003-08-26 at 10:58, Guillaume Plessis wrote:
> We should not bypass the work of the debian maintainers. They are free
> to work the (debian-)way they want.
Sure -- I took for granted that you had been working in cooperation with
them. You do as you wish. I just would find it very conven
At 10:48 26/08/2003, Sterling Hughes wrote:
> On Mon, 25 Aug 2003, Rasmus Lerdorf wrote:
>
> > It would also have to be a new 4.4 branch as it breaks binary
> > compatibility for extensions.
>
> It is far from being usable in mainstream as it relies on various
> GCC features in many places.
On Tue, 26 Aug 2003, Kevin Waterson wrote:
> This one time, at band camp, Per Lundberg <[EMAIL PROTECTED]> wrote:
>
>
> > Here is an idea: how about integrating the Debian packaging script with
> > the main PHP CVS code? This is done with some other Debian packages,
> > and it helps a lot for p
Stefan Roehrich wrote:
> On 2003-08-25 14:54:48, Ard Biesheuvel wrote:
>> Casting to void* instead of void** cures the problem. As the cast
>
> Yes, but why?
Because a pointer to a pointer isn't untyped (because you know where it
points to: to an untyped pointer)
> I don't know if with some op
Zeev Suraski wrote:
> We'll look into each of the changes and decide whether to incorporate
> it into ZE2.
That was the whole purpose of my posting -- not raising popcorn sales,
like someone on IRC suggested ;-)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://php
Kevin Waterson wrote:
How about including packaging for rpm and windows and any other
packaging system out there?
I think this would add too much.
AFAICS, the spec file for RPM is already on CVS:
http://cvs.php.net/annotate.php/php-src/php4.spec.in?login=2&rev=1.2
Or maybe I am mistaken, but it
Olivier Hill wrote:
Kevin Waterson wrote:
How about including packaging for rpm and windows and any other
packaging system out there?
I think this would add too much.
AFAICS, the spec file for RPM is already on CVS:
http://cvs.php.net/annotate.php/php-src/php4.spec.in?login=2&rev=1.2
Or may
Le Tue, Aug 26, 2003 at 11:33:40 -0400, Ken Tossell a écrit:
> >Anyway, if having a spec file, we could also have a deb file (if
> >someone is interested in maintaining it of course).
>
> Maybe the Debian maintainers? :-)
I did contact them. I'm waiting for their answer.
--
Guillaume Plessis
On 2003-08-26 11:57:36, Ard Biesheuvel wrote:
> but for other (extension-specific) types as well. Maintaining a union with
> all these types would be ludicrous.
These unions would only be in the calling code, where they can be type
specific, but I don't like this solution, too.
But what's the bes
32 matches
Mail list logo
