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
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
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
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
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
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
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
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, 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
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 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*
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
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
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
> 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, 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
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
--
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
> 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
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
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
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
> > 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 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
--
> >> 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 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
>
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
> 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 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
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
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
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
32 matches
Mail list logo
