memory.c
c:\home\php\php-5.1\main\streams\memory.c(316) : error C2275: 'size_t' :
illegal
use of this type as an expression
c:\Programme\Microsoft Visual Studio .NET
2003\Vc7\include\stdio.h(70) :
see declaration of 'size_t'
c:\home\php\php-5.1\main\streams\memory.c(316) : error C2146: sy
Hello Sebastian,
fixed, how about committing such a change yourself? I bet that takes much
less time than grabbing all that input and writing such mails? Thanks
anyway.
marcus
Friday, October 7, 2005, 9:19:59 AM, you wrote:
> memory.c
> c:\home\php\php-5.1\main\streams\memory.c(316) : error C
Hi.
I'm looking for CVS tarball with RCS files inside of php-src and ZendEngine2
repositories. It would be possible to convert it to Subversion repository
with cvs2svn or VCP so browsing the repositories would be much easier.
Where can I find it?
--
.''`.Piotr Roszatycki, Netia SA
: :' :
On Fri, 7 Oct 2005, Piotr Roszatycki wrote:
> I'm looking for CVS tarball with RCS files inside of php-src and ZendEngine2
> repositories. It would be possible to convert it to Subversion repository
> with cvs2svn or VCP so browsing the repositories would be much easier.
>
> Where can I find it
On Friday 07 of October 2005 10:26, Derick Rethans wrote:
> On Fri, 7 Oct 2005, Piotr Roszatycki wrote:
> > I'm looking for CVS tarball with RCS files inside of php-src and
> > ZendEngine2 repositories. It would be possible to convert it to
> > Subversion repository with cvs2svn or VCP so browsing
On Fri, 7 Oct 2005, Piotr Roszatycki wrote:
> On Friday 07 of October 2005 10:26, Derick Rethans wrote:
> > On Fri, 7 Oct 2005, Piotr Roszatycki wrote:
> > > I'm looking for CVS tarball with RCS files inside of php-src and
> > > ZendEngine2 repositories. It would be possible to convert it to
> > >
On Friday 07 of October 2005 10:52, Derick Rethans wrote:
> On Fri, 7 Oct 2005, Piotr Roszatycki wrote:
> > On Friday 07 of October 2005 10:26, Derick Rethans wrote:
> > > On Fri, 7 Oct 2005, Piotr Roszatycki wrote:
> > > > I'm looking for CVS tarball with RCS files inside of php-src and
> > > > Ze
Let's turn the question on its head and ask why *you* need to mirror it.
--Wez.
On 10/7/05, Piotr Roszatycki <[EMAIL PROTECTED]> wrote:
> On Friday 07 of October 2005 10:52, Derick Rethans wrote:
> > On Fri, 7 Oct 2005, Piotr Roszatycki wrote:
> > > On Friday 07 of October 2005 10:26, Derick Reth
On Friday 07 of October 2005 14:33, Wez Furlong wrote:
> Let's turn the question on its head and ask why *you* need to mirror it.
> > Why don't you provide alternative access to CVS? Is it technical or
> > political reason? Allowing to download the tarball could help to lower
> > the load on CVS s
On Fri, 7 Oct 2005, Piotr Roszatycki wrote:
> On Friday 07 of October 2005 14:33, Wez Furlong wrote:
> > Let's turn the question on its head and ask why *you* need to mirror it.
>
> > > Why don't you provide alternative access to CVS? Is it technical or
> > > political reason? Allowing to downloa
Hi Derick,
>From Yesterday(06/10/2005) onwards NetWare php-5.1 autotests were
failing because of a segfault from tests/lang/023.phpt which makes one
mktime call.
When delved for the cause it seems that In NetWare LibC SDK's time.h
tzname is expanded to ___tzname() this cause the C preprocessor to
c
On Friday 07 of October 2005 15:15, Derick Rethans wrote:
> On Fri, 7 Oct 2005, Piotr Roszatycki wrote:
> > On Friday 07 of October 2005 14:33, Wez Furlong wrote:
> > > Let's turn the question on its head and ask why *you* need to mirror
> > > it.
> > >
> > > > Why don't you provide alternative acc
Hello,
On Fri, 7 Oct 2005, Kamesh Jayachandran wrote:
> From Yesterday(06/10/2005) onwards NetWare php-5.1 autotests were
> failing because of a segfault from tests/lang/023.phpt which makes one
> mktime call.
> When delved for the cause it seems that In NetWare LibC SDK's time.h
> tzname is expa
I honestly don't see how it will be any better than CVS, if the data
comes from CVS in the first place.
Since we've generally got our plates full, we don't have the resources
to support third parties maintaining their own forks. We'd much
rather have those third parties working directly with us s
On Friday 07 of October 2005 16:23, Wez Furlong wrote:
> I honestly don't see how it will be any better than CVS, if the data
> comes from CVS in the first place.
>
> Since we've generally got our plates full, we don't have the resources
> to support third parties maintaining their own forks. We'd
Piotr Roszatycki wrote:
> On Friday 07 of October 2005 16:23, Wez Furlong wrote:
>
>>I honestly don't see how it will be any better than CVS, if the data
>>comes from CVS in the first place.
>>
>>Since we've generally got our plates full, we don't have the resources
>>to support third parties main
Rasmus Lerdorf wrote:
Just use cvsup: http://www.php.net/cvsup.php
I belive that the access to this service was restricted due to the
performance problems it was creating.
Edin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Edin Kadribasic wrote:
> Rasmus Lerdorf wrote:
>
>>
>> Just use cvsup: http://www.php.net/cvsup.php
>>
>
> I belive that the access to this service was restricted due to the
> performance problems it was creating.
We have a new server on the way. We'll get it back up then.
-Rasmus
--
PHP Int
Ron,
I agree that a bug report should be filed against zlib, but
unfortunately I don't know enough about the underlying issues to file
that report myself I do have enough context to file a new bug
against PHP but feel that bug #30153 does a great job of describing the
issue and believe it
Hello,
attached is a patch (by Markus) that allows you to make typehints
optionally take NULL as default value too, f.e.:
class P { }
class T {
function f(P $p = NULL) {
var_dump($p);
}
}
$o=new T();
$o->f(new P);
$o->f(NULL);
$o->f();
I would like to commit this patch to HEAD
On Thu, 6 Oct 2005, Andrei Zmievski wrote:
> On Oct 6, 2005, at 10:56 AM, Derick Rethans wrote:
> >
> > I think I would prefer an IS_UNICODE/unicode=on only PHP.
> >
> > This would mean that:
> > - no duplicate functionality for tons of functions that will make
> > maintaining the thing very har
Lovely.
- David
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 07, 2005 10:30 PM
> To: PHP Developers Mailing List
> Subject: [PHP-DEV] Type Hints with Null
>
> Hello,
>
> attached is a patch (by Markus) that allows you to make typehints
>
Andrei Zmievski wrote:
>> - we have a bit less BC.
>
>
> "A bit less"? I'd say it would break BC in a major way. People who want
> to upgrade to PHP 6 would need to rewrite a lot of their scripts.
I think most large applications will be in this boat anyway, we may as
well do it properly once, so
Hello!
I packed PHP 4.4.1RC1 today, which you can find here:
http://downloads.php.net/derick/
Please test it carefully, and report any bugs in the bug system, but
only if you have a short reproducable test case.
If everything goes well, we can release it somewhere at the end of next
week.
reg
Ilia Alshanetsky wrote:
> Andrei Zmievski wrote:
>
>>>- we have a bit less BC.
>>
>>
>>"A bit less"? I'd say it would break BC in a major way. People who want
>>to upgrade to PHP 6 would need to rewrite a lot of their scripts.
>
>
> I think most large applications will be in this boat anyway, we
On Fri, 7 Oct 2005, Rasmus Lerdorf wrote:
> > We definitely need to look at that since if upgrading to 6.0 means a 3x
> > slower operation very few people will even consider upgrading.
>
> Which is why we need the unicode=off switch. I don't think there is any
> way we can make Unicode PHP as fa
Derick Rethans wrote:
> On Fri, 7 Oct 2005, Rasmus Lerdorf wrote:
>
>
>>>We definitely need to look at that since if upgrading to 6.0 means a 3x
>>>slower operation very few people will even consider upgrading.
>>
>>Which is why we need the unicode=off switch. I don't think there is any
>>way we
On Oct 7, 2005, at 5:05 PM, Derick Rethans wrote:
On Fri, 7 Oct 2005, Rasmus Lerdorf wrote:
Which is why we need the unicode=off switch. I don't think there
is any
way we can make Unicode PHP as fast as non-Unicode PHP. For
people who
need Unicode support, Unicode PHP will be faster an
On Fri, 7 Oct 2005, Rasmus Lerdorf wrote:
> > What is wrong with PHP 5.1? People don't *have* to upgrade to the
> > unicode enabled PHP if they don't want to. And it would probably be
> > "nice" to have that mode for some users, but should that be over our own
> > back with multiple implementat
George Schlossnagle wrote:
>> What is wrong with PHP 5.1? People don't *have* to upgrade to the
>> unicode enabled PHP if they don't want to. And it would probably be
>> "nice" to have that mode for some users, but should that be over our own
>> back with multiple implementations of everything?
>
Ilia Alshanetsky wrote:
> George Schlossnagle wrote:
>
>>>What is wrong with PHP 5.1? People don't *have* to upgrade to the
>>>unicode enabled PHP if they don't want to. And it would probably be
>>>"nice" to have that mode for some users, but should that be over our own
>>>back with multiple impl
On Fri, 7 Oct 2005, Rasmus Lerdorf wrote:
> > Assuming that 5.1 would be actively maintained and not just for bug
> > fixes, I'd say that is a viable approach. There are plenty of sites that
> > have no use for Unicode as nice as it may be, and much rather retain
> > performance over useless (for
On Oct 7, 2005, at 5:41 PM, Rasmus Lerdorf wrote:
Ilia Alshanetsky wrote:
George Schlossnagle wrote:
What is wrong with PHP 5.1? People don't *have* to upgrade to the
unicode enabled PHP if they don't want to. And it would probably be
"nice" to have that mode for some users, but should tha
Derick Rethans wrote:
> On Fri, 7 Oct 2005, Rasmus Lerdorf wrote:
>
>
>>>Assuming that 5.1 would be actively maintained and not just for bug
>>>fixes, I'd say that is a viable approach. There are plenty of sites that
>>> have no use for Unicode as nice as it may be, and much rather retain
>>>perf
George Schlossnagle wrote:
> Perhaps we need a separate version fork for the unicode support. I'm
> thinking one of those nifty unicode glyphs. It could be called 'the
> language formerly known as PHP'.
The Phillipine currency is called PHP. Do they perhaps have a currency
symbol?
-Rasmus
-
Rasmus Lerdorf wrote:
>>Assuming that 5.1 would be actively maintained and not just for bug
>>fixes, I'd say that is a viable approach. There are plenty of sites that
>> have no use for Unicode as nice as it may be, and much rather retain
>>performance over useless (for them) functionality.
>
>
>
On Fri, 2005-10-07 at 22:09 +0100, Rasmus Lerdorf wrote:
> The "don't upgrade" argument doesn't work. Unless we commit to having
> two major versions forever where we will add new features. That is a
> possibility as well of course. Have 2 trees. Unicode-PHP and
> non-Unicode-PHP and everything
On Fri, 7 Oct 2005, Nuno Lopes wrote:
> > derick Wed Oct 5 07:06:57 2005 EDT
> >
> > Modified files: (Branch: PHP_5_1)
> > /php-src/ext/date php_date.c
> > Log:
> > - Implement correct Windows timezone guessing.
>
> Thanks for you work, Derick!
> However after checking the cor
On Fri, 7 Oct 2005, Nuno Lopes wrote:
> Uhm, sorry but it doesn't work well when I choose a timezone which has
> no DST. For an unknown reason, windows returns TIME_ZONE_ID_UNKOWN in
> that case, so PHP always returns UTC.
Can you check if in that case the elements in the struct that
GetTimeZo
On Fri, 7 Oct 2005, Nuno Lopes wrote:
Uhm, sorry but it doesn't work well when I choose a timezone which has
no DST. For an unknown reason, windows returns TIME_ZONE_ID_UNKOWN in
that case, so PHP always returns UTC.
Can you check if in that case the elements in the struct that
GetTimeZoneInfo
Hello John,
Friday, October 7, 2005, 11:47:14 PM, you wrote:
> On Fri, 2005-10-07 at 22:09 +0100, Rasmus Lerdorf wrote:
>> The "don't upgrade" argument doesn't work. Unless we commit to having
>> two major versions forever where we will add new features. That is a
>> possibility as well of cour
On Fri, 7 Oct 2005, Ilia Alshanetsky wrote:
George Schlossnagle wrote:
What is wrong with PHP 5.1? People don't *have* to upgrade to the
unicode enabled PHP if they don't want to. And it would probably be
"nice" to have that mode for some users, but should that be over our own
back with multi
Hi all,
The source of the E_STRICT warnings when running "make install-pear" is
a Zend Engine bug. If we can clear this up, then PEAR will no longer
hold up PHP 5.1
http://bugs.php.net/bug.php?id=34786
Cheers,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Rasmus Lerdorf wrote:
> George Schlossnagle wrote:
>> Perhaps we need a separate version fork for the unicode support. I'm
>> thinking one of those nifty unicode glyphs. It could be called 'the
>> language formerly known as PHP'.
>
> The Phillipine currency is called PHP. Do they perhaps have
44 matches
Mail list logo
