This isn't planned for Engine 2 but you could use:
list($year) = localtime($time);
Andi
At 03:17 20/04/2002 +0200, Markus Fischer wrote:
I've brought this up on the Zend Engine2 list a while ago.
The result was that it is not planned to support
dereferencing of arrays from
These warnings helped me to fix 2 bugs :)
I'm glad to hear that. Now I have a new problem:
c:\php4build\HEAD\ext\pgsql\pgsql.c(1505) : fatal error C1057: unexpected
end of
file in macro expansion
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
The way _GET and friends are implemented is the most efficient way of doing
it as it is taken care at compile-time.
For the same reason in Engine 2 you can't indirectly reference $this (which
shouldn't bother anyone).
Over time people won't have to support versions below 4.1.0 anymore.
In the
At 18:17 19/04/2002 +0200, Marcus Börger wrote:
At 15:46 19.04.2002, you wrote:
Any objection for changing -O2 - -O3 when
--enable-inline-optimization is used? (when GCC is used)
--
Yasuo Ohgaki
What about leaving -O2 but adding -finline-functions
-O2 will inline the functions marked as
Shall we remove --enable-inline-optimization option?
Since it does not do anything for a long time, AFAIK.
(Or does it actually work under some systems?)
Any comments?
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Andi Gutmans wrote:
What about leaving -O2 but adding -finline-functions
-O2 will inline the functions marked as inline. That should be good
enough because we inline where it's important.
I wouldn't go with -O3 nor with -finline-functions.
Andi
Sounds good to me.
How about -O0
Edin Kadribasic wrote:
These warnings helped me to fix 2 bugs :)
I'm glad to hear that. Now I have a new problem:
c:\php4build\HEAD\ext\pgsql\pgsql.c(1505) : fatal error C1057: unexpected
end of
file in macro expansion
Could you tell me line number for current source?
I've committed
c:\php4build\HEAD\ext\pgsql\pgsql.c(1505) : fatal error C1057:
unexpected
end of
file in macro expansion
Could you tell me line number for current source?
I've committed sevral patches today, so I cannot tell
which one was it.
Line 1505 in the latest CVS.
Edin
--
PHP Development
Andi,
does this also apply to the $GLOBALS variable?
If so, I think we can then add an apropriate Note: to the
http://www.php.net/manual/en/language.variables.predefined.php
page.
- Markus
On Sat, Apr 20, 2002 at 04:23:03PM +0300, Andi Gutmans wrote :
The way _GET
I would like to know if we can modify the build process to build and
install a PHP library, without any SAPI modules, so that libphp.a and
libphp.so get installed in the appropriate locations. I need this in
order to develop PHP support for some applications, since they will need
to link against
It applies, to a degree. If you directly reference $GLOBALS anywhere in
your function, you can also reference it indirectly. If you don't,
however, indirect reference won't work.
E.g.,
function foo()
{
$foo = GLOBALS;
print $$foo[bar]; // won't work
}
With Apache 2.0.36-dev, newest PHP cvs..
Starting program: /usr/local/www/httpd2/bin/httpd
[New Thread 1024 (LWP 9606)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 9606)]
0x40406e41 in zm_startup_recode (type=1, module_number=9, tsrm_ls=0x8196898) at
Hello,
it's clear why this crashes... the globals are not initialized. And from:
php_recode.h:
/* Checking for thread safety and issue warning if necessary. */
#ifdef ZTS
#warning Recode module has not been tested for thread-safety.
#endif
It looks as it just needs some work (but not that
Hello,
I can make a quick patch, but not test it. Are you waillin to try my
patch?
Derick
On Sat, 20 Apr 2002 [EMAIL PROTECTED] wrote:
Hello,
it's clear why this crashes... the globals are not initialized. And from:
php_recode.h:
/* Checking for thread safety and issue warning if
[This is quite long, so grab a cup/can/bottle/glass of your favourite
beverage and get comfortable]
Following on from the recent talk about streams and filters, I've been
thinking about how useful it would be for extension authors to have some
kind of lightweight interface mechanism.
I'm not
Hello again,
I comitted a patch to the CVS, can you retest?
Derick
On Sat, 20 Apr 2002, Magnus Määttä wrote:
With Apache 2.0.36-dev, newest PHP cvs..
Starting program: /usr/local/www/httpd2/bin/httpd
[New Thread 1024 (LWP 9606)]
Program received signal SIGSEGV, Segmentation fault.
On Sat, 20 Apr 2002 20:32:22 +0200 (CEST)
[EMAIL PROTECTED] wrote:
Yes, ill test it now..
Hello again,
I comitted a patch to the CVS, can you retest?
Derick
On Sat, 20 Apr 2002, Magnus Määttä wrote:
With Apache 2.0.36-dev, newest PHP cvs..
Starting program:
On Sat, 20 Apr 2002 20:32:22 +0200 (CEST)
[EMAIL PROTECTED] wrote:
Hello again,
I comitted a patch to the CVS, can you retest?
It worked now..
Derick
On Sat, 20 Apr 2002, Magnus Määttä wrote:
With Apache 2.0.36-dev, newest PHP cvs..
Starting program:
At 20:33 20/04/2002 +0300, Zeev Suraski wrote:
It applies, to a degree. If you directly reference $GLOBALS anywhere in
your function, you can also reference it indirectly. If you don't,
however, indirect reference won't work.
E.g.,
function foo()
{
$foo = GLOBALS;
print
At 23:15 20/04/2002 +0900, Yasuo Ohgaki wrote:
Shall we remove --enable-inline-optimization option?
Since it does not do anything for a long time, AFAIK.
(Or does it actually work under some systems?)
Any comments?
Does removing mean that if someone specifies it configure will continue
Following on from my RFC about an interface mechanism, what we really
need is some brainstorming on what interfaces we need or would like to
have in PHP. I'm aiming at PHP 5.
The following concepts have already been mentioned either by myself or
others as being something we'd like to see in
Following on from my RFC about an interface mechanism, what we really
need is some brainstorming on what interfaces we need or would like to
have in PHP. I'm aiming at PHP 5.
The following concepts have already been mentioned either by myself or
others as being something we'd like to see
On Sat, 2002-04-20 at 21:55, Andi Gutmans wrote:
At 23:15 20/04/2002 +0900, Yasuo Ohgaki wrote:
Shall we remove --enable-inline-optimization option?
Since it does not do anything for a long time, AFAIK.
(Or does it actually work under some systems?)
Any comments?
Does removing mean that
On Sat, 2002-04-20 at 17:53, Andrei Zmievski wrote:
I would like to know if we can modify the build process to build and
install a PHP library, without any SAPI modules, so that libphp.a and
libphp.so get installed in the appropriate locations. I need this in
order to develop PHP support for
It ought not to be removed.
Reason? The GCC optimizer easily takes a couple of hundred
mega bytes of memory to compile zend_execute.c depending on
the optimization level and the architecture. That is pretty
bad, especially when administrators have not set up process
Sascha Schumann wrote:
Here is a patch which aims at reducing the redundant code in
pgsql.c (-685, +211 lines).
http://apache.org/~sascha/pgsql.diff
It also significantly reduces the number of memcpy's,
sprintf's and so on and immensily improves readability of the
Sascha Schumann wrote:
It ought not to be removed.
Reason? The GCC optimizer easily takes a couple of hundred
mega bytes of memory to compile zend_execute.c depending on
the optimization level and the architecture. That is pretty
bad, especially when administrators
27 matches
Mail list logo
