Re: [PHP-DEV] Re: Namespaces in PHP 6 - ++$take
Marcus Boerger wrote: Hello Jessie, [snip] 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. Did not notice these further comments until now. Anyways, I originally implemented imports in this way (making copies in class_table and updating the reference count), but then I used another approach because then imports would be request-wide, and I wanted them to be file-specific only (yeah, I know the PHP6 meeting notes said they should be request-wide, but I see this causing many problems to the point where they cannot be used in order to guarantee safe code). Also, yes, ':' are not be allowed in either class or interface definitions, but they are included in the full name in class_table (e.g. "namespace_name:class_name"). This is how it is currently in my patch. Regards, Jessie Hernandez -- 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
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: syntax.
I would prefer ':::' or '\' 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] memory manager panic
Hi, There's a problem with the memory manager (HEAD): [EMAIL PROTECTED]:~/build/php-unicode-debug$ cli -d"memory_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 -d"memory_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 -d"memory_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 -d"memory_limit=500k" -d"output_buffering=1" -r 'while(true) echo "foo";' > /dev/null Starting program: /home/mike/build/php-unicode-debug/sapi/cli/php -d"memory_limit=500k" -d"output_buffering=1" -r 'while(true) echo "foo";' > /dev/null [Thread debugging using libthread_db enabled] [New Thre
Re: [PHP-DEV] Namespaces in PHP 6 - ++$take
Am 10.11.2006 um 19:47 schrieb Hans Lellelid: I think there is far more demand for a fast & stable PHP then for syntatic sugar features which seem extremely useful, but in the end prove to carry too much baggage. Nothing has been proven either way.. at least not publicly.. unless I just missed it. I haven't talked to a single developer a large-scale PHP tool, application, etc. that wouldn't switch their trunk to using namespaces tomorrow if they were adopted in the engine. We [in] PHP developers who are building "enterprise" open-source components and frameworks really will use this feature -- and I think we'd all argue that we really need this feature. I hope that namespaces would be more than syntactic sugar -- e.g. providing an import/using keyword that would declare namespace context -- but even if they were only "syntactic sugar" they would at minimum provide a naming standard for PHP packages to avoid collisions. Namespaces certainly got a lot of mention at Int'l PHP Conference (in form of request and, during the panel, applause from audience when mentioned); it was clear that this is a very anticipated PHP6 feature. None of us non-C developers are trying to say we think this should be easy, or trying to otherwise minimize the problems that have been presented in the past or the reasons why it hasn't been implemented so far, but let there be no confusion that this is a really, really important feature for us. Very wall said, Hans, and I totally agree. It's much needed, and I believe any FOSS project that is OO based would applaud the introduction of namespaces. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces in PHP 6 - ++$take
Am 11.11.2006 um 14:37 schrieb Rasmus Lerdorf: I am not sure why this thread was revived. We decided long ago that we would have namespaces in PHP 6 barring any nasty technical problems and assuming a good way to implement it could be found. I'm not sure if that was made clear. The meeting notes much rather say "mmmh okay we'll think about it, and if we like the idea, Marcus is gonna implement it". I'm glad that was clarified now, thanks :) David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces in PHP 6 - ++$take
What? I suppose if you always want to name your latest class
foobar, then yes, but then you have other problems... If you
properly pick a classname you almost never need to rename it let
alone the methods contained with the class. Plus namespaces are
going to introduce their own sets of problems where extension X
adds namespace X, which some lib already decided to use and we are
back to where we are at today.
import('org.phpdb.propel.runtime'); or whatever. How could that
possibly collide. Come on, "people might use namespaces in a wrong
way" really is not an argument against them.
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strange php_stream_from_zval requires return_value
You probably want php_stream_from_zval_no_verify which doesn't
auto-return if there is an invalid stream passed in.
--Wez.
On 11/10/06, Antony Dovgal <[EMAIL PROTECTED]> wrote:
On 11/11/2006 04:13 AM, Arnold Daniels wrote:
> Hi,
>
> I've noticed that building an extension will fail when using macro
> php_stream_from_zval and there is not return_value variable within the
> scope.
Well, looks like it's time to install cscope or ctags and use it to see which
code actually stands behind a particular macro.
#define php_stream_from_zval(xstr, ppzval) ZEND_FETCH_RESOURCE2((xstr), php_stream *,
(ppzval), -1, "stream", php_file_le_stream(), php_file_le_pstream())
#define ZEND_FETCH_RESOURCE2(rsrc, rsrc_type, passed_id, default_id,
resource_type_name, resource_type1, resource_type2)\
rsrc = (rsrc_type) zend_fetch_resource(passed_id TSRMLS_CC, default_id,
resource_type_name, NULL, 2, resource_type1, resource_type2); \
ZEND_VERIFY_RESOURCE(rsrc);
#define ZEND_VERIFY_RESOURCE(rsrc) \
if (!rsrc) {\
RETURN_FALSE; \ < nb
}
Obviously this macro is not what you need.
I guess you need zend_fetch_resource(), which is the function actually used in
ZEND_FETCH_RESOURCE2().
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces in PHP 6 - ++$take
I am not sure why this thread was revived. We decided long ago that we would have namespaces in PHP 6 barring any nasty technical problems and assuming a good way to implement it could be found. And I'll second Tony here and mention that we really could use more eyeballs on the bug database. I am sure everyone reading internals has at least one part of PHP they know really well and it would be extremely helpful if you could all pick a topic and watch for bugs related to that topic. It's not hard to see just the bugs you care about. For all the open Postgresql Related bugs, for example: http://bugs.php.net/search.php?limit=50&order_by=id&direction=DESC&cmd=display&bug_type%5B%5D=PostgreSQL+related&status=Open Or if you prefer to have them show up in your RSS reader, just put rss in front of the search.php script there: http://bugs.php.net/rss/search.php?limit=50&order_by=id&direction=DESC&cmd=display&bug_type%5B%5D=PostgreSQL+related&status=Open Go to http://bugs.php.net/search.php for a list of all the available categories or even better, just watch for all bugs coming in and attack the ones you think you might have a clue on. http://bugs.php.net/rss/search.php?direction=DESC&status=Open&cmd=display You don't necessarily have to be able to fix them in the C code, just helping to get rid of bogus reports or translating the really bad reports into a simple reproducable test case is often the part that takes the most time. Once we have a 3-5 line reproducing script, the fix is usually easy. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces in PHP 6 - ++$take
Zitat von Hans Lellelid <[EMAIL PROTECTED]>: I think there is far more demand for a fast & stable PHP then for syntatic sugar features which seem extremely useful, but in the end prove to carry too much baggage. Nothing has been proven either way.. at least not publicly.. unless I just missed it. I haven't talked to a single developer a large-scale PHP tool, application, etc. that wouldn't switch their trunk to using namespaces tomorrow if they were adopted in the engine. We [in] PHP developers who are building "enterprise" open-source components and frameworks really will use this feature -- and I think we'd all argue that we really need this feature. I hope that namespaces would be more than syntactic sugar -- e.g. providing an import/using keyword that would declare namespace context -- but even if they were only "syntactic sugar" they would at minimum provide a naming standard for PHP packages to avoid collisions. Namespaces certainly got a lot of mention at Int'l PHP Conference (in form of request and, during the panel, applause from audience when mentioned); it was clear that this is a very anticipated PHP6 feature. None of us non-C developers are trying to say we think this should be easy, or trying to otherwise minimize the problems that have been presented in the past or the reasons why it hasn't been implemented so far, but let there be no confusion that this is a really, really important feature for us. I couldn't agree more. There really wasn't an appealing reason to switch to PHP5 too quickly for me, and force the users of our code to do the same. There are a few reasons to switch to 5.2 probably, but that's a different story. But if there wasn't already Unicode support in PHP 6, having namespaces was definitely a good reason to force our user to that version. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ -- 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,
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: syntax.
I would prefer ':::' or '\' 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
