Re: [PHP-DEV] Re: Namespaces in PHP 6 - ++$take
Hi! If the namespace-approach only covers classes it is implemented half-heartedly, IMO. I see a lot of classes that are just really collections of static functions, that's what namespaces should cover, too. And disallowing constants only so that : works is a bad tradeoff... Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespaces in PHP 6 - ++$take
Hello Jessie,
we already have consts in our classes, if you look close then you will see
that the table does not conatain 'namespace:const' but only 'namespace:class'
and still there are conflicts already.
best regards
marcus
Sunday, November 12, 2006, 1:48:22 AM, you wrote:
Hi Marcus,
As I said, I wanted to only enable classes inside namespaces, and NOT
allow functions or constants. class::const would stay the same, so there
are no conflicts.
Marcus Boerger wrote:
Hello Jessie,
sorry to say this but look at the following, keeping in mind that the
whitespace is optional.
$x = $foo ? class:const : $var// 1, 0
$x = $foo ? class:const : const; // 1, 0
$x = $foo ? class:const : class:const;// 1, 1
$x = $foo ? class:const : namespace:class:const; // 1, 2
$x = $foo ? namespace:class:const : $var; // 2, 0
$x = $foo ? namespace:class:const : const; // 2, 0
$x = $foo ? namespace:class:const : class:const;// 2, 1
$x = $foo ? namespace:class:const : namespace:class:const; // 2, 2
Feel free to continue that list, it has conflicts whatever you do.
Saturday, November 11, 2006, 5:13:22 AM, you wrote:
Hello,
I haven't had time to work on my patch, but thinking about this some
more, I'm convinced namespaces should only contain classes. The only
problem that was present when permitting functions/constants to be
inside namespaces was the ambiguity in ternary expressions. By just
supporting classes inside namespaces, this issue would go away. Besides,
I'll dare say that most, if not all, the developers who want namespaces
will only group classes with it anyways,
Also, by only supporting classes, we can use : instead of the long
::: separator and everyone would be happy.
Last I checked, the only things that were pending on my patch were some
scoping issues which I had to fix. These are listed below. Once these
are done, the patch can be formally proposed. If anyone wants to take a
look at the patch so far and/or work on the remaining issues below, let
me know and I'll either post the patch or email it.
Pending:
1) The extends clause should resolve imported class names.
import class ns:DateBase;
namespace ns{ class Date extends DateBase{} }
2) To access a global symbol, use global:class_name syntax.
I would prefer ':::'class_name or '\'class_name but that doesn't really
matter as we have 'global' as a keyword already.
3) Type hints should also consider imported classes.
4) When an import is done (with alias or not), and a global class with
that same name exists, what is the desired behavior? Error? Global takes
precedence?
Maybe this new discussion gave one hint. Aliases could be solved with a
flag. Just copy the classwith a new name into the classlist again and flagit
as copy. Maybe the original class gets a list of the copies of the copies a
pointer to the original but that would be an implementation detail. As soon
as that is done importdoes nothingelse then copying classes on a single
class table. That said namespaces would, if after all, simply contain other
copies to the original classes. In the extremecase we can start with
namespaces only being a 'stupid' list. Reflection could then travers all
classes to see in which namespaces it was registered.
This btw would also fix 3) as the namespace seperator would be a normal
sign in class lookup, it would simply be disallowed in definitions of
class/interface/namespaces.
Best regards,
Marcus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.4.5
Will there be an upcoming release (I don't mean ever, but soon) that incorporates this fix: http://cvs.php.net/viewvc.cgi/php-src/ext/standard/html.c?r1=1.63.2.23.2.2r2=1.63.2.23.2.3view=patch I do my own compilation, but I see that vendors have been pushing out their own versions lately... -s -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] memory manager panic
Mike, please make sure you didn't forget to do `cvs up Zend` and `./cvsclean` to get a clean build. I can't reproduce it with your test case, though. On 11/11/2006 11:57 PM, Michael Wallner wrote: Hi, There's a problem with the memory manager (HEAD): [EMAIL PROTECTED]:~/build/php-unicode-debug$ cli -dmemory_limit=500k -r 'leak(212930);' [Sat Nov 11 21:39:42 2006] Script: '-' /home/mike/cvs/php-src/Zend/zend_builtin_functions.c(1181) : Freeing 0xB6E73000 (212930 bytes), script=- zend_mm_heap corrupted Segmentation fault [EMAIL PROTECTED]:~/build/php-unicode-debug$ gdb --args sapi/cli/php -dmemory_limit=500k -r 'leak(212800);' Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (gdb) r Starting program: /home/mike/build/php-unicode-debug/sapi/cli/php -dmemory_limit=500k -r leak\(212800\)\; [Thread debugging using libthread_db enabled] [New Thread -1225652560 (LWP 9328)] [Sat Nov 11 21:40:04 2006] Script: '-' /home/mike/cvs/php-src/Zend/zend_builtin_functions.c(1181) : Freeing 0xB6EEB0A0 (212800 bytes), script=- zend_mm_heap corrupted Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1225652560 (LWP 9328)] 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7035ba6 in kill () from /lib/tls/i686/cmov/libc.so.6 #2 0x08298639 in zend_mm_panic (message=0x83e9a2b zend_mm_heap corrupted) at /home/mike/cvs/php-src/Zend/zend_alloc.c:61 #3 0x08298f14 in zend_mm_find_leaks (segment=0xb6edf008, b=0xb6eeb07c) at /home/mike/cvs/php-src/Zend/zend_alloc.c:673 #4 0x082990dd in zend_mm_check_leaks (heap=0x841b4b0) at /home/mike/cvs/php-src/Zend/zend_alloc.c:735 #5 0x08299b2a in zend_mm_shutdown (heap=0x841b4b0, full_shutdown=0, silent=0) at /home/mike/cvs/php-src/Zend/zend_alloc.c:997 #6 0x0829b940 in shutdown_memory_manager (silent=0, full_shutdown=0, tsrm_ls=0x841a018) at /home/mike/cvs/php-src/Zend/zend_alloc.c:1875 #7 0x0824a439 in php_request_shutdown (dummy=0x0) at /home/mike/cvs/php-src/main/main.c:1435 #8 0x08360230 in main (argc=4, argv=0xbfd39c94) at /home/mike/cvs/php-src/sapi/cli/php_cli.c:1270 [EMAIL PROTECTED]:~/build/php-unicode-debug$ valgrind sapi/cli/php -dmemory_limit=500k -r 'leak(211800);' ==9345== Memcheck, a memory error detector. ==9345== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==9345== Using LibVEX rev 1606, a library for dynamic binary translation. ==9345== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==9345== Using valgrind-3.2.0-Debian, a dynamic binary instrumentation framework. ==9345== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==9345== For more details, rerun with: -v ==9345== [Sat Nov 11 21:44:38 2006] Script: '-' /home/mike/cvs/php-src/Zend/zend_builtin_functions.c(1181) : Freeing 0x052AF490 (211800 bytes), script=- ==9345== Invalid read of size 4 ==9345==at 0x8298F01: zend_mm_find_leaks (zend_alloc.c:670) ==9345==by 0x82990DC: zend_mm_check_leaks (zend_alloc.c:735) ==9345==by 0x8299B29: zend_mm_shutdown (zend_alloc.c:997) ==9345==by 0x829B93F: shutdown_memory_manager (zend_alloc.c:1875) ==9345==by 0x824A438: php_request_shutdown (main.c:1435) ==9345==by 0x836022F: main (php_cli.c:1270) ==9345== Address 0x52E302C is 4 bytes after a block of size 262,144 alloc'd ==9345==at 0x4021396: malloc (vg_replace_malloc.c:149) ==9345==by 0x8298843: zend_mm_mem_malloc_alloc (zend_alloc.c:230) ==9345==by 0x829A243: _zend_mm_alloc_int (zend_alloc.c:1208) ==9345==by 0x829B194: _emalloc (zend_alloc.c:1646) ==9345==by 0x8263991: php_output_activate (output.c:116) ==9345==by 0x8249481: php_request_startup (main.c:1195) ==9345==by 0x835F714: main (php_cli.c:1015) zend_mm_heap corrupted ==9345== ==9345== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 47 from 1) ==9345== malloc/free: in use at exit: 1,104,886 bytes in 14,284 blocks. ==9345== malloc/free: 15,049 allocs, 765 frees, 1,463,471 bytes allocated. ==9345== For counts of detected errors, rerun with: -v ==9345== searching for pointers to 14,284 not-freed blocks. ==9345== checked 1,236,528 bytes. ==9345== ==9345== LEAK SUMMARY: ==9345==definitely lost: 0 bytes in 0 blocks. ==9345== possibly lost: 0 bytes in 0 blocks. ==9345==still reachable: 1,104,886 bytes in 14,284 blocks. ==9345== suppressed: 0 bytes in 0 blocks. ==9345== Reachable blocks (those to which a pointer was found) are not shown. ==9345== To see them, rerun with: --show-reachable=yes Segmentation fault Bytes to leak may differ as you can see. The problem doesn't seem to be tied to leaks though, because I can replicate with code that doesn't leak and that generates a different backtrace: [EMAIL PROTECTED]:~/build/php-unicode-debug$ gdb --quiet sapi/cli/php Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (gdb) r -dmemory_limit=500k -doutput_buffering=1 -r 'while(true) echo foo;' /dev/null Starting program:
Re: [PHP-DEV] 4.4.5
On Sun, 12 Nov 2006, steve wrote: Will there be an upcoming release (I don't mean ever, but soon) that incorporates this fix: http://cvs.php.net/viewvc.cgi/php-src/ext/standard/html.c?r1=1.63.2.23.2.2r2=1.63.2.23.2.3view=patch I do my own compilation, but I see that vendors have been pushing out their own versions lately... Yes, I plan to release rc1 this week. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
