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:
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
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 the
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
Subversion
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
ZendEngine2
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 Rethans
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 server.
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 download the
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
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 expanded
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
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 Internals -
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
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 hard
This is
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 we
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.
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 may as
well do
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 fast as
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 can make
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
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 implementations of
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 them)
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 that
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
performance over
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
--
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 that
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 correct TZ, you
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
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 course.
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
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 a
35 matches
Mail list logo
