Re: [PHP-DEV] Patch for HTTP successful status codes
David Zülke wrote: So... who's gonna commit it? :) I'll commit in the next few hours if nobody objects. Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7- dropping the $ from the variable name - rfc
mike wrote: ... Would you mind using your full name or something else? Thanks :) Not that I'd have a (tm) on mike, but anyway... Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Fwd: [PATCH] Backport of HEADs output API]
In case the original with patches attached doesn't get through: http://dev.iworks.at/PATCHES/php53-backport_output.txt http://dev.iworks.at/PATCHES/pecl-backport_output.txt Original Message Subject: [PATCH] Backport of HEADs output API Date: Thu, 18 Sep 2008 20:51:45 +0200 From: Michael Wallner [EMAIL PROTECTED] Newsgroups: php.internals Hi, as some people including RM have asked me to backport HEAD's output API (main/output.c) I prepared a patch wich does that--what else... There's one for current PHP-5.3 source and a tiny one for PECL. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Adding pecl/http to core
Hi, I wonder what the general opinion is on adding pecl/http to the main PHP distribution? Many people have poked me in the past, so I guessed it's time to ask me and you that question once for all. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Adding pecl/http to core
Jani Taskinen wrote: So pecl/http is actually ext/curl with OO API? Not really. libcurl is not HTTP only, pecl/http utilizes libcurl for it's HTTP request functionality. pecl/http also provides much improved HTTP response and zlib functionality besides an swizz-army-knife for URLs. Why not merge the two then..? Or rather, replace ext/curl with pecl/http once latter has BC API for us non-oo folks out there.. You don't have to write OO code to use pecl/http, neither do you have the possibility to query any protocol other than HTTP with pecl/http. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PATCH] Backport of HEADs output API]
Lukas Kahwe Smith wrote: well the question is does it fix some real world bugs? this late in the game i would not want to include these changes if they just add features .. Huh? :) The question to me is, why did you ask me to do it, when you're not sure what it's about? Not to be anally at all... ;) The greatest plus to me are: - getting rid of monolithic php_end_ob_buffer() - getting rid of output handler specific code in SAPI.c - being able to hook from the running output handler to change it's behavior - being able to clearly configure conflicts and reverse conflicts between output handlers Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Adding pecl/http to core
Ralph Schindler wrote: Mike, I have a few questions about the API and target use cases. What is the best medium to ask these questions and document them? This thread certainly is not the best place im sure of. I'm moving this to php.pecl.dev then. That should be the right place. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding pecl/http to core
Johannes Schlüter wrote: I think it's fine to have settings for limitations on pconnects, but stuff like http.request.methods.allowed or http.only_exceptions should http.request.methods.allowed is handled at RINIT. http.only_exceptions is PHP_INI_ALL, though introducing it at all might have been a bad idea. In fact pretty all settings are PHP_INI_ALL except auto_start for inflate/deflate output handler (PHP_INI_PERDIR), maximum count of persistent handles and what the global request data share should cache. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding pecl/http to core
Lars Strojny wrote: I've not seen plenty of Class::singleton() myself, getInstance is an accepted standard in all languages, including the PHP code I wrote, and I've had experience with. That's my point, yes. pecl_http uses ::singleton() instead of getInstance(). Well, sure--that depends. PEAR for example defined ::singleton() as the standard name and most of the code I've dealt with at that time used ::singleton() either. I guess this is merely a matter of taste, respectively what's PHP going to use in the future. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3 (sorry missed a couple votes, but they did not affect the results)
Lukas Kahwe Smith wrote: 7) should Output buffering rewrite MFH? this one comes with some baggage, we need enough people to actually have a look at how things are in HEAD and make it clear that they will be available for bug fixing and BC issues resolving. the risk here is obviously that any BC issues will be hard to isolate for end users. -1 Lukas -1 David +1 Hannes +0 Matt Wilson +0 Greg +0 Derick +1 Elizabeth +0 Lars -1 Stas for now Need more explanation why we need rewrite, what the rewrite does, etc. If there's a good reason and maintainer, then maybe +1. -1 Ilia +0.5 Steph I'd really like to see it in 5.3 because it was supposed to fix several OB issues, but it's probably too late in the cycle now +0 Scott +1 Kalle -1 David S.P. for now Need more explanation why we need rewrite, what the rewrite does, etc. If there's a good reason and maintainer, then maybe +1. -1 Rob +1 Pierre (if it creates non fixable issues during the alpha/RC phases, it can always be reverted. However the code is much cleaner and easier to maintain, if I can use the word easy for the OB code) +0 Arnaud Le Blanc +0 Larry Garfield +0 Lester Caine +0 Konstantin Leboev +1 Jani +0 Jonathan Bond-Caron +0 George Antoniadis +1 Felipe +1 Moriyoshi +0 Karsten Dambekalns +0 Alexey Zakhlestin +1 Guilherme Blanco +1 Marcus = no MFH, very unclear vote result and nobody that raised their hand to take responsibility (yes Pierre I know that you raised your hand on IRC) Hm... I'm still alive, but I feel blamed for not reading a mailing list which has become unmanageable to read. I wrote the code, so I'm probably responsible for it, too. And again, I was asked several times to back port it, so it can be included in 5.3--which doesn't mean I'm insisting on that matter, just to make it clear. I've still got some email addresses which--despite of spam--I am able to read and respond in a reasonable time span. Usually you can even hit me on IRC. Feel free to ask me any questions per mail or on IRC, but don't expect me to read a quadrillion of mails on [EMAIL PROTECTED] Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src /main output.c /tests/output bug46900.phpt bug46903.phpt ob_014.phpt ob_015.phpt ob_start_basic_002.phpt ob_start_basic_004.phpt
Robin Fernandes wrote:
robinf Sun Dec 28 19:50:58 2008 UTC
Added files:
/php-src/tests/output bug46903.phpt bug46900.phpt
Modified files:
/php-src/tests/output ob_start_basic_004.phpt
ob_start_basic_002.phpt ob_015.phpt
ob_014.phpt
/php-src/main output.c
Log:
Fix bugs #46900 and #46903.
http://cvs.php.net/viewvc.cgi/php-src/main/output.c?r1=1.214r2=1.215diff_format=u
Index: php-src/main/output.c
diff -u php-src/main/output.c:1.214 php-src/main/output.c:1.215
--- php-src/main/output.c:1.214 Mon Aug 18 07:45:59 2008
+++ php-src/main/output.c Sun Dec 28 19:50:58 2008
@@ -19,7 +19,7 @@
+--+
*/
-/* $Id: output.c,v 1.214 2008/08/18 07:45:59 tony2001 Exp $ */
+/* $Id: output.c,v 1.215 2008/12/28 19:50:58 robinf Exp $ */
#ifndef PHP_OUTPUT_DEBUG
# define PHP_OUTPUT_DEBUG 0
@@ -1342,6 +1342,8 @@
}
if (chunk_size 0) {
chunk_size = 0;
+ } else if (chunk_size == 1) {
+ chunk_size = 4096;
}
if (SUCCESS != php_output_start_user(output_handler, chunk_size, flags
TSRMLS_CC)) {
The documentation stated IMHO silly magic behavior of the old output
layer. Why start sprinkling the new code with useless magic meanings?
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS /ext/standard php_string.h string.c /ext/standard/tests/strings bug47546.phpt
Matt Wilmas wrote: Hi Dmitry, Antony, Fixed, thanks. Matt Wilmas wrote: mattwil Wed Apr 1 17:05:37 2009 UTC Removed files: (Branch: PHP_5_3) /php-src/ext/standard/tests/strings bug47546.phpt Modified files: /php-src NEWS /php-src/ext/standard php_string.h string.c Log: MFH: explode() stuff: - Fixed bug #47560 (explode()'s limit parameter odd behaviour) by reverting change for bug #47546 In what state is this now? php_explode() does not work as expected with limit=-1 and php_explode_negative_limit() is not exported in php_string.h Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: function call chaining
On 01/19/2010 01:27 AM, Stanislav Malyshev wrote: Hi! I wrote a small patch that enables this kind of syntax in PHP: foo()(); I'd rather see two other things that are missing, support for dynamic object and array de-referencing like (new class)-method() and get_array()[index]. I honestly don't see func()()()() make anything better in the world of a PHP programmer. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] fix zend_llist_remove_tail
The attached patch fixes zend_llist_remove_tail() which didn't reset
zend_llist-head properly.
The diff was generated against 5_2.
Regards,
--
Michael
Index: Zend/zend_llist.c
===
RCS file: /repository/ZendEngine2/zend_llist.c,v
retrieving revision 1.35.2.1.2.1
diff -u -p -d -r1.35.2.1.2.1 zend_llist.c
--- Zend/zend_llist.c 1 Jan 2007 09:35:46 - 1.35.2.1.2.1
+++ Zend/zend_llist.c 27 Jan 2007 17:31:36 -
@@ -130,28 +130,17 @@ ZEND_API void zend_llist_clean(zend_llis
ZEND_API void *zend_llist_remove_tail(zend_llist *l)
{
- zend_llist_element *old_tail;
+ zend_llist_element *current = l-tail;
void *data;
-
- if ((old_tail = l-tail)) {
- if (l-tail-prev) {
- l-tail-prev-next = NULL;
- }
-
- data = old_tail-data;
-
- l-tail = l-tail-prev;
- if (l-dtor) {
- l-dtor(data);
- }
- pefree(old_tail, l-persistent);
-
- --l-count;
-
- return data;
+
+ if (current) {
+ data = current-data;
+ DEL_LLIST_ELEMENT(current, l);
+ } else {
+ data = NULL;
}
-
- return NULL;
+
+ return data;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] fix zend_llist_remove_tail
*If* anybody's wondering... I don't have karma.
Michael Wallner wrote:
The attached patch fixes zend_llist_remove_tail() which didn't reset
zend_llist-head properly.
The diff was generated against 5_2.
Regards,
Index: Zend/zend_llist.c
===
RCS file: /repository/ZendEngine2/zend_llist.c,v
retrieving revision 1.35.2.1.2.1
diff -u -p -d -r1.35.2.1.2.1 zend_llist.c
--- Zend/zend_llist.c 1 Jan 2007 09:35:46 - 1.35.2.1.2.1
+++ Zend/zend_llist.c 27 Jan 2007 17:31:36 -
@@ -130,28 +130,17 @@ ZEND_API void zend_llist_clean(zend_llis
ZEND_API void *zend_llist_remove_tail(zend_llist *l)
{
- zend_llist_element *old_tail;
+ zend_llist_element *current = l-tail;
void *data;
-
- if ((old_tail = l-tail)) {
- if (l-tail-prev) {
- l-tail-prev-next = NULL;
- }
-
- data = old_tail-data;
-
- l-tail = l-tail-prev;
- if (l-dtor) {
- l-dtor(data);
- }
- pefree(old_tail, l-persistent);
-
- --l-count;
-
- return data;
+
+ if (current) {
+ data = current-data;
+ DEL_LLIST_ELEMENT(current, l);
+ } else {
+ data = NULL;
}
-
- return NULL;
+
+ return data;
}
--
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] persistence for zend_stack
Patch is against CVS HEAD.
Regards,
--
Michael
Index: Zend/zend_stack.c
===
RCS file: /repository/ZendEngine2/zend_stack.c,v
retrieving revision 1.19
diff -u -p -d -r1.19 zend_stack.c
--- Zend/zend_stack.c 1 Jan 2007 09:29:21 - 1.19
+++ Zend/zend_stack.c 6 Feb 2007 12:55:41 -
@@ -24,8 +24,13 @@
ZEND_API int zend_stack_init(zend_stack *stack)
{
+ return zend_stack_init_ex(stack, 0);
+}
+
+ZEND_API int zend_stack_init_ex(zend_stack *stack, int persistent)
+{
stack-top = 0;
- stack-elements = (void **) emalloc(sizeof(void **) * STACK_BLOCK_SIZE);
+ stack-elements = (void **) pemalloc(sizeof(void **) *
STACK_BLOCK_SIZE, stack-persistent = persistent);
if (!stack-elements) {
return FAILURE;
} else {
@@ -37,11 +42,11 @@ ZEND_API int zend_stack_init(zend_stack
ZEND_API int zend_stack_push(zend_stack *stack, void *element, int size)
{
if (stack-top = stack-max) { /* we need to allocate more
memory */
- stack-elements = (void **) erealloc(stack-elements,
- (sizeof(void **) * (stack-max +=
STACK_BLOCK_SIZE)));
- if (!stack-elements) {
+ void *elements = perealloc(stack-elements, (sizeof(void **) *
(stack-max += STACK_BLOCK_SIZE)), stack-persistent);
+ if (!elements) {
return FAILURE;
}
+ stack-elements = elements;
}
stack-elements[stack-top] = (void *) emalloc(size);
memcpy(stack-elements[stack-top], element, size);
@@ -64,7 +69,7 @@ ZEND_API int zend_stack_top(zend_stack *
ZEND_API int zend_stack_del_top(zend_stack *stack)
{
if (stack-top 0) {
- efree(stack-elements[--stack-top]);
+ pefree(stack-elements[--stack-top], stack-persistent);
}
return SUCCESS;
}
@@ -97,11 +102,11 @@ ZEND_API int zend_stack_destroy(zend_sta
register int i;
for (i = 0; i stack-top; i++) {
- efree(stack-elements[i]);
+ pefree(stack-elements[i], stack-persistent);
}
if (stack-elements) {
- efree(stack-elements);
+ pefree(stack-elements, stack-persistent);
}
return SUCCESS;
}
Index: Zend/zend_stack.h
===
RCS file: /repository/ZendEngine2/zend_stack.h,v
retrieving revision 1.22
diff -u -p -d -r1.22 zend_stack.h
--- Zend/zend_stack.h 1 Jan 2007 09:29:21 - 1.22
+++ Zend/zend_stack.h 6 Feb 2007 12:55:42 -
@@ -25,6 +25,7 @@
typedef struct _zend_stack {
int top, max;
void **elements;
+ unsigned persistent:1;
} zend_stack;
@@ -32,6 +33,7 @@ typedef struct _zend_stack {
BEGIN_EXTERN_C()
ZEND_API int zend_stack_init(zend_stack *stack);
+ZEND_API int zend_stack_init_ex(zend_stack *stack, int persistent);
ZEND_API int zend_stack_push(zend_stack *stack, void *element, int size);
ZEND_API int zend_stack_top(zend_stack *stack, void **element);
ZEND_API int zend_stack_del_top(zend_stack *stack);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: todo items
Lukas Kahwe Smith wrote: 1. on-the-fly static properties (mike) I didn't request these, I just posted something that looked like a patch. Yet, I wouldn't mind removing another unreasonable fatalism. 2. 'strict class' to disable dynamic member variable addition (marcus) IIRC that doesn't describe the whole problem, re: [EMAIL PROTECTED] etc. 2. add support for files 2GB (wez) That would really be nice! Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RC announcements at php.net
Antony Dovgal wrote: Now that the conference ads are gone, I think we should add release candidates announcements to the first page of php.net. Any objections? I hope none. I actually think this is a pretty good idea, and thanks to Hannes for the cleanup. -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PROPOSAL] Change (just slightly) read/write_property() and get_property_ptr_ptr() usage
Hi, I'd like to suggest a change to how the read_property object handler operates. Wouldn't it be reasonable for the engine to use get_property_ptr_ptr() whenever it wants to modify a property and get rid of using read_property() for write access? That would make rather simple ops like concatenation, in-/decrementation etc work again with overloaded internal classes. Just make the engine use read_property() followed by a write_property() when there's no get_property_ptr_ptr(). Punish me if I'm really that far off. Thoughts? -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PROPOSAL] Change (just slightly) read/write_property() and get_property_ptr_ptr() usage
Peter Hodge wrote: Hello, Does that fix the problem where: $object-theArray[] = (...); is invalid when 'theArray' is implemented using __get()? No. It's about internal classes and information stored in C structures. Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Z_BVAL (lvalue casts)
Oliver Block wrote: Hello internals, I don't know if you are aware of that. I just tried to compile some pecl code. I get an error message using this with gcc 4.x if it is used like Z_BVAL(myval) = ...; That should be ZVAL_BOOL(z, ...); So, what's been some pecl code? -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: DateTime object equality
Michael Wallner wrote:
Hans Lellelid wrote:
Is this DateTime comparison behavior actually intended to be different
from everything else? If there's some reason that DateTime object
properties cannot be compared to each other, wouldn't it be more
appropriate for them to always return FALSE ?
In my POV this is easily solvable with a custom comparison object handler.
See attached patch. I also think that comparing to Datetime instances should
give a reasonable result.
Regards,
--
Michael
Index: ext/date/php_date.c
===
RCS file: /repository/php-src/ext/date/php_date.c,v
retrieving revision 1.43.2.45.2.41
diff -u -p -d -r1.43.2.45.2.41 php_date.c
--- ext/date/php_date.c 27 Feb 2007 03:04:39 - 1.43.2.45.2.41
+++ ext/date/php_date.c 5 Mar 2007 13:19:28 -
@@ -297,6 +297,7 @@ static void date_object_free_storage_tim
static zend_object_value date_object_new_date(zend_class_entry *class_type
TSRMLS_DC);
static zend_object_value date_object_new_timezone(zend_class_entry *class_type
TSRMLS_DC);
static zend_object_value date_object_clone_date(zval *this_ptr TSRMLS_DC);
+static int date_object_compare_date(zval *d1, zval *d2 TSRMLS_DC);
static zend_object_value date_object_clone_timezone(zval *this_ptr TSRMLS_DC);
/* This is need to ensure that session extension request shutdown occurs 1st,
because it uses the date extension */
@@ -1459,6 +1460,7 @@ static void date_register_classes(TSRMLS
date_ce_date = zend_register_internal_class_ex(ce_date, NULL, NULL
TSRMLS_CC);
memcpy(date_object_handlers_date, zend_get_std_object_handlers(),
sizeof(zend_object_handlers));
date_object_handlers_date.clone_obj = date_object_clone_date;
+ date_object_handlers_date.compare_objects = date_object_compare_date;
#define REGISTER_DATE_CLASS_CONST_STRING(const_name, value) \
zend_declare_class_constant_stringl(date_ce_date, const_name,
sizeof(const_name)-1, value, sizeof(value)-1 TSRMLS_CC);
@@ -1530,6 +1532,27 @@ static zend_object_value date_object_clo
return new_ov;
}
+static int date_object_compare_date(zval *d1, zval *d2 TSRMLS_DC)
+{
+ if (Z_TYPE_P(d1) == IS_OBJECT Z_TYPE_P(d2) == IS_OBJECT
+ instanceof_function(Z_OBJCE_P(d1), date_ce_date
TSRMLS_CC)
+ instanceof_function(Z_OBJCE_P(d2), date_ce_date
TSRMLS_CC)) {
+ php_date_obj *o1 = zend_object_store_get_object(d1 TSRMLS_CC);
+ php_date_obj *o2 = zend_object_store_get_object(d2 TSRMLS_CC);
+
+ if (!o1-time-sse_uptodate) {
+ timelib_update_ts(o1-time, o1-time-tz_info);
+ }
+ if (!o2-time-sse_uptodate) {
+ timelib_update_ts(o1-time, o1-time-tz_info);
+ }
+
+ return o1-time-sse == o2-time-sse ? 0 : o1-time-sse
o2-time-sse ? -1 : 1;
+ }
+
+ return 1;
+}
+
static inline zend_object_value date_object_new_timezone_ex(zend_class_entry
*class_type, php_timezone_obj **ptr TSRMLS_DC)
{
php_timezone_obj *intern;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: DateTime object equality
Michael Wallner wrote:
+ if (!o2-time-sse_uptodate) {
+ timelib_update_ts(o1-time, o1-time-tz_info);
+ }
Oh my, typo warning.
--
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: DateTime object equality
Hans Lellelid wrote: Is this DateTime comparison behavior actually intended to be different from everything else? If there's some reason that DateTime object properties cannot be compared to each other, wouldn't it be more appropriate for them to always return FALSE ? In my POV this is easily solvable with a custom comparison object handler. See attached patch. I also think that comparing to Datetime instances should give a reasonable result. Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP version and Zend API Number
Michael B Allen wrote: The get_zend_version function returns a string like 'Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies\n'. It would be nice to be able to get the ZEND_MODULE_API_NO (e.g. 20060613) the standard module was compiled under. basic_function_module.zend_api might be what you're looking for. I'm still confused about how many versions of extensions I need to provide with my product. Currently I just compile it against late versions of 4, 5.0, 5.1 and 5.2 and hope for the best. But looking at ZEND_MODULE_API_NO changes in webcvs shows it changes more frequently than that. But so far I haven't ran into major problems with ZEND_MODULE_API_NO so maybe I'm just being paranoid. From looking at zend.c it looks like it will print diagnostic info if some tries to load an incompatible extension. It looks like that: [EMAIL PROTECTED]:~$ php -n -dextension_dir=/usr/local/lib/php/extensions/no-debug-non-zts-20050922/ -dextension=ffi.so -v PHP Warning: PHP Startup: ffi: Unable to initialize module Module compiled with module API=20050922, debug=0, thread-safety=0 PHPcompiled with module API=20060613, debug=0, thread-safety=1 These options need to match -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
Stanislav Malyshev wrote: Fine, let's step back for a bit. What I want to be able to do is have objects/arrays as internal properties and constants. Can we make that possible? Last time I looked it required having persistent zvals. I think to better understand what would be required a use case would help a lot. Could you bring forward 1-2 scenarios how one would use it? Initializing a static class resp. default instance variable with f.e. an array is an obvious use case. Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
Stanislav Malyshev wrote:
Initializing a static class resp. default instance variable with f.e.
an array is an obvious use case.
Err, I'm afraid I don't understand neither your abbreviations nor what
the actual use case is. Can you describe real use case - i.e. module X
has functionality A and B, and to make A work with B I would use
persistent zvals so that when Foo is called Bar happens.
Sorry for the cryptic reply. I think that initializing a static class
property as well as initializing a default property with for example
an array is an obvious use case. Try to do the following in an extension:
class c {
static $prop1 = array(foo, bar);
var $prop2 = array(1,2,3);
}
Regards,
--
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP6 Feature Testing Debugging
David Coallier wrote: So here I go, what are the features and tests that YOU would like to see reported ? I am currently building a list of things that we have to test and I am wondering which are the parts you consider the most important and the most bogus/untested perhaps. There's absolutely new code for output handlers, torture it. Text processing incl. compression, DB access, XML handling might be good candidates to test, too. Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] http arrays
Jochem Maas wrote:
$args = array('foo' = array('bar' = array(1,2,3), 'quz' = array(1,2,3)));
echo '/foo.php?'.http_build_query($args);
foo.php --- 8 ---
var_dump($_GET['foo']);
the var_dump() output used to be a neat nested array, but since 5.1.3
[although I remember
it as 5.1.6] http_build_query() makes htmlentities of the square brackets so
therefore
the var_dump() gives you a string.
Works as expected here with v5.2
Regards,
--
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] http arrays
Jochem Maas wrote:
I'll take your word on it (although I can't be sure exactly what it is that
you expected),
which means the change has been reverted, or the input parsing stuff has been
changed to
recognize escaped square brackets as if they were not escaped - I know for
sure
that http_build_query() did escape quare brackets in 5.1.6 and that url query
strings
that included escaped square brackets were not parsed into [nested] arrays.
expected means that I get
array(1) {
[a]=
array(1) {
[0]=
string(1) 1
}
}
for get.php?a%5B%5D=1
--
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Setting HTTP results code vs. HTTP type
Uwe Schindler wrote: What we need is: 2) a function to simply set the status code without changing anything other. There's a (external) function: http://php.net/manual/en/function.http-send-status.php ...and for the unlucky: header(Dummy:, true, $status_code); But if your patch makes sense, I'm all for it! ;) Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src(PHP_4_4) / NEWS /ext/mcrypt mcrypt.c /ext/mcrypt/tests bug41252.phpt
Derick Rethans wrote:
derickTue May 1 16:07:37 2007 UTC
http://cvs.php.net/viewvc.cgi/php-src/ext/mcrypt/mcrypt.c?r1=1.77.4.7.4.2r2=1.77.4.7.4.3diff_format=u
Index: php-src/ext/mcrypt/mcrypt.c
diff -u php-src/ext/mcrypt/mcrypt.c:1.77.4.7.4.2
php-src/ext/mcrypt/mcrypt.c:1.77.4.7.4.3
--- php-src/ext/mcrypt/mcrypt.c:1.77.4.7.4.2 Mon Jan 1 09:46:44 2007
+++ php-src/ext/mcrypt/mcrypt.c Tue May 1 16:07:37 2007
@@ -16,7 +16,7 @@
| Derick Rethans [EMAIL PROTECTED]|
+--+
*/
-/* $Id: mcrypt.c,v 1.77.4.7.4.2 2007/01/01 09:46:44 sebastian Exp $ */
+/* $Id: mcrypt.c,v 1.77.4.7.4.3 2007/05/01 16:07:37 derick Exp $ */
#ifdef HAVE_CONFIG_H
#include config.h
@@ -38,6 +38,10 @@
static int le_mcrypt;
+typedef struct _php_mcrypt {
+ MCRYPT td;
+ zend_bool init;
+} php_mcrypt;
function_entry mcrypt_functions[] = {
PHP_FE(mcrypt_ecb, NULL)
@@ -208,10 +212,12 @@
}
#define MCRYPT_GET_TD_ARG
\
+ zval **mcryptind;
\
+ php_mcrypt *pm;
\
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, mcryptind) ==
FAILURE) { \
WRONG_PARAM_COUNT
\
}
\
- ZEND_FETCH_RESOURCE (td, MCRYPT, mcryptind, -1, MCrypt, le_mcrypt);
+ ZEND_FETCH_RESOURCE (pm, php_mcrypt *, mcryptind, -1, MCrypt,
le_mcrypt);
#define MCRYPT_GET_MODE_DIR_ARGS(DIRECTORY)
\
char *dir = NULL; \
@@ -240,6 +246,12 @@
#define MCRYPT_ENTRY2_4(a) MCRYPT_ENTRY_NAMED(a, a)
#endif
+#define PHP_MCRYPT_INIT_CHECK\
+ if (!pm-init) {\
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, Operation
disallowed prior to mcrypt_generic_init().);\
+ RETURN_FALSE; \
+ } \
+
Please don't add error messages with periods!
Thanks,
--
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
Richard Quadling wrote: How about something along these lines ... (Not pretty as I'm crap at the design - sorry). http://rquadling.php1h.com/snap.html Eeek! ;) -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Userspace stream wrappers and Unicode.
Richard Quadling wrote: Not being obtuse or antagonistic, just not understanding the implications of unicode, but why will unicode kill off userspace stream wrappers? It's not about unicode. It's just been argued that each userspace stream wrapper will be marked as remote stream. Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #41401 [Opn-Bgs]: Order of Operations error on divide by negative
[EMAIL PROTECTED] wrote: ID: 41401 Updated by: [EMAIL PROTECTED] Reported By: drlippman at yahoo dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: Windows, Linux PHP Version: 4.4.7 New Comment: [2007-05-15 15:44:07] drlippman at yahoo dot com Description: Left-to-right order of operations does not appear to be honored when dividing by a negative Reproduce code: --- 1/-2*5 Expected result: -2.5 Actual result: -- -.1 Should all these three examples give the same result? $ php -r 'var_dump(-1/2*5, 1/-2*5, 1/2*-5);' float(-2.5) float(-0.1) float(-2.5) Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 Preview
Stanislav Malyshev wrote: There's also some work to be done on supporting more of the icu functionality. It's in progress now. Where? Will it be eat it or die when you're done? There've been no replies from core developers to my postings on php-i18n about providing ResourceBundle API except a single notice from Andrei. Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #41401 [Opn-Bgs]: Order of Operations error on divide by negative
Michael Wallner wrote: Should all these three examples give the same result? ^ n't $ php -r 'var_dump(-1/2*5, 1/-2*5, 1/2*-5);' float(-2.5) float(-0.1) float(-2.5) Sorry, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 Preview
l0t3k wrote: Michael Wallner [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Where? Will it be eat it or die when you're done? There've been no replies from core developers to my postings on php-i18n about providing ResourceBundle API except a single notice from Andrei. i think i chimed in as well... You did, but you didn't come back. there is a post over in i18n from Norbert Lindenberg on the same issue.. I know, I replied that I didn't understand why he wants to create a new file format. No response--so, it's probably me... Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Help with the snaps site
John Mertic wrote: Hi Chris, I can see where you are coming from. I put together another version of this that entirely uses the PHP CSS templates: http://files.edin.dk/php/installer/snaps-html/index-phptemplate.html I like it, but how about using BZip2 Tarball and Zip Package etc instead of php5 (...)? -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] Callbacks bug/change request
Stanislav Malyshev wrote: the feature actually exists because we need array($obj, 'parent::func') Why/when do you need that? You'd probably do something along those lines if it were possible: ((ParentClass) $child)-virtualMethod(); If you prefer, s/You/One/ Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5.3 Suggested Feature List
Ilia Alshanetsky wrote: 1) Backport the namespaces patch for PHP 6 +1 2) Symlink the intl extension from PECL, but leave it disabled by default as is the case with all extensions dependent on external libs 0 (didn't see anything relevant of it yet) 3) Apply the Late Static Binding Patch +1 4) Implement David's Circular Garbage collection patch 0 (is this really something for a minor version?) 5) Implement Sqlite3 support via the ext/sqlite extension (patch is already available) 0 6) Remove safe_mode, register_globals and magic_quotes -1 (never used any, but I'd say leave that items up for the next major) 7) Introduce mysqlind library into core and use it as a backend for PDO and mysqli extensions (possibly enabling them by default) +1 (if it's considered stable enough) 8) OpenID enabling patch for OpenSSL and PHP 5 +1 9) Add array_replace[_recursive] functions (patch is already available) 0 10) Split off deprecation from E_STRICT into E_DEPRECATED +1 11) Merge the zend_arg_info const'ify patch +1 12) Merge the GCC 4 -fvisibility patch -1 (eventually make it a configure option first? PHP is a API mess) 13) Switch for disabling/enabling materialized cursors in mysqli 0 14) Link phar extension from PECL into core (possibly enabling it by default) +1 15) Merge Matt's ZEND_SIGNED_MULTIPLY_LONG() optimization patch +1 16) Introduce new php.ini files parser/scanner + CGI/FastCGI? htaccess style ini file support +1 17) Merge __callStatic patch from PHP 6 +1 18) Introduce concept of strict classes that do not permit dynamic property creation +1 Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Suggested Feature List
Steph Fox wrote:
18) Introduce concept of strict classes that do not permit dynamic
property creation
-1, this whole idea just sounds so weird for PHP.
Sure, but how PHPish is this fatal error?
[EMAIL PROTECTED]:~/build/php-5.2-debug$ cli -r 'class c{} c::$x=1;'
Fatal error: Access to undeclared static property: c::$x in Command
line code on line 1
The idea, as far as I understood, was to allow this things with
non-strict classes once we have strict classes.
Regards,
--
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_5_3 Branched
Ilia Alshanetsky wrote: I am a biased party here, so take this with a grain of salt ;-) First of all, I definitely think we need 2 release masters, for 5.X tree given that there will be two active branches, at least for the next few months, there is simply too much work for one person to do. My suggestion was going to be (Lukas beat me to the punch with his proposal) that I RM 5.3 release and ask someone new to take over the 5.2 branch and within 1-2 releases of 5.3.0 have that person take over 5.3 branch, once they are a bit more familiar with the process. I do agree that having more people try their hand at being RM is a very good idea and historically every minor/major release had a new RM. I like that idea, too... but I don't think that Johannes would have big problems starting with 5.3.0. Anyway, I'd like to see Johannes as RM for 5.3--now or a bit later. -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src(PHP_5_2) / run-tests.php /ext/bz2/tests 005.phpt /ext/standard/tests/general_functions phpcredits.phpt phpinfo.phpt /ext/standard/tests/strings sha1.phpt /ext/zlib/tests
Nuno Lopes wrote: nlopess Fri Sep 14 15:28:04 2007 UTC Log: changes to run-tests.php: - change %s to %a - make %s = [^\r\n]+ - fix tests accordingly I think this is a very bad change. While tests of bundled extensions can be updated accordingly, pecl extension tests have no way to be version agnostic in this regard. -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: using zend_parse_parameters to get an object of an externally defined class
alon wrote: A newbie question: How can I use zend_parse_parameters to accept object of an external class as parametr. I want for example to build a method that accepts 'DateTime' objects. But how do I initiate the zend_class_entry to specify an object of the DateTime class? The class entry pointer or a function which returns it needs to be exported by the datetime API. IIRC that's not the case ATM. -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how declare protected array property at internal class properly
Denis Gabaidulin wrote: How can i do subj ? at constructor: zval *prop; /* init */ prop = zend_read_property(Z_OBJCE_P(getThis()), getThis(), prop, strlen(prop,), 1 TSRMLS_CC); array_init(prop); zval *prop; MAKE_STD_ZVAL(prop); array_init(prop); zend_update_property(Z_OBJCE_P(getThis()), getThis(), ZEND_STRS(prop)-1, prop TSRMLS_CC); zval_ptr_dtor(prop); IIRC complex types for internal zvals was on some engine todo or--at least--wish list... Regards, -- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug 61272
On 25 November 2012 11:58, Casper Langemeijer langemei...@php.net wrote: Hi all, Somewhere in May this year I discovered that our software would not run on PHP 5.4 because of changed behaviour of ob_start(). I discovered a bugreport that was marked 'Not a bug', but valuable info was already added to it. I contacted Michael Wallner (mike) directly because he marked the bug 'not a bug'. No response. I'm sorry that the new output control layer causes you such headaches. IIRC, 6 years back, when I implemented the new output control functionality, I kindly asked the list, whether to rather implement what's documented, or what the old code did, but I have yet been unable to find according mails. It pretty well may have been the case that the old code passed the output buffer contents through the handler prior discarding, but as it had not been documented (and I obviously failed to figure out a use case) I apparently implemented the more efficient way it currently is. No offense, no excuse, just a try to figure out what happened... -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug 61272
On 26 November 2012 15:46, Casper Langemeijer langemei...@php.net wrote: Hmm.. I suppose It's up to me to make a strong (if possible watertight) plea for the old way. I will try: 1. I don't think my patch impacts the efficiency of php_output_clean(). It adds a single if with a binary compare. True: this causes output to get piped through the output handler, but the output handler callback function could be smart enough to back off when the PHP_OUTPUT_HANDLER_CLEAN bit is set in the second parameter of the callback. 2. Current behaviour is *not* according the documentation. ob_start() documentation states: An optional output_callback function may be specified. This function takes a string as a parameter and should return a string. The function will be called when the output buffer is flushed (sent) or **cleaned** (with ob_flush(), ob_clean() or similar function) or when the output buffer is flushed to the browser at the end of the request. When output_callback is called, it will receive the contents of the output buffer as its parameter and is expected to return a new output buffer as a result, which will be sent to the browser. (*-emphasis mine) Which emphasizes the fact, that implementation and documentation differed quite a bit. The ob_clean note was obviously added in 2008 [1] [2], when the new output code was sleeping in the PHP6 branch. Current behaviour differs: On calling ob_end_clean() or ob_clean(), output_callback is called, but *without* the contents of the output buffer as its parameter. 3. Implementing my patch will never break anything. The output will be passed to the callback, but anything returned by it *will* be discarded. 4. If you are not going to pass the contents of the output buffer on ob_end_clean() or ob_clean() to the callback function, Why would you call the callback anyway? I guess I got your argument now :) I'll have a look. Thanks for spending your time to make PHP better. [1] http://svn.php.net/viewvc/phpdoc/en/trunk/reference/outcontrol/functions/ob-start.xml?r1=246628r2=268496 [2] https://bugs.php.net/bug.php?id=44150 -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug 61272
On 29 November 2012 08:00, Yasuo Ohgaki yohg...@ohgaki.net wrote: I recently looked into new output code in PHP 5.4. It's MUCH nicer than older code. Good job! Appreciated! However, new code encapsulate output globals. (I mean internally) It would be nice for my extension if output globals are exposed. This was changed intentionally, why would you need OG what the API does not provide? Exposing output global is not mandatory, though. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 for Final Review before Vote
On 3 January 2013 17:41, Clint Priest cpri...@zerocue.com wrote: I like the idea of an init function, but that would have to wait for a further release I think, or delay this whole project a year. We have constructors, shouldn't those be sufficient for that task? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Improved Linux process title support in the CLI SAPI
On 7 February 2013 09:37, Christoph Rosse cro...@2bepublished.at wrote: Am 2013-02-07 08:45, schrieb Alexey Zakhlestin: On 07.02.2013, at 9:40, Keyur Govande keyurgova...@gmail.com wrote: Hello, I've created a new RFC to improve support for setting a CLI process' title on Linux. It is based off of the PostgreSQL implementation and is more robust than the proctitle extension. More details and patch here: https://wiki.php.net/rfc/cli_process_title This would be useful for some of my tasks! I don't like names of functions, but I like functionality and API approach how about: bool cli_title_settable(void); This function name is ambiguous, does it mean set table or is settable, I guess it means the latter, so it should also be named like that. bool cli_title_set(string); string cli_title_get(); Greate feature and +1 to Alexeys function names. But what is the point in checking if I'm able to set a title with is_cli_ps_title_available() if set_cli_ps_title() can fail and return false anyway? I'm just asking because I don't see the benefit of the function is_cli_ps_title_available for the user. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] operator-0.3 extension update
great, that someone is updating this extension. will you also offer an updated version for php-5.5 later (if it does not already work)? i just wanted to give it a try, but there seems to be a problem with the uploaded package: it seems to only contain the package.xml? % tar -i -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Improved Linux process title support in the CLI SAPI
On 7 February 2013 13:33, Leigh lei...@gmail.com wrote: On 7 February 2013 12:22, Alexey Zakhlestin indey...@gmail.com wrote: On 07.02.2013, at 13:54, Leigh lei...@gmail.com wrote: There is a PECL extension that already does something similar. You may want to take a look at that. http://pecl.php.net/package/proctitle Did you read RFC? Keyur mentions it and its limitations there I only skimmed it very quickly if I'm honest. Why does this need to be in core? This could just be done as a set of improvements to the existing PECL extension instead. I'd guess that the number of people who require (and would use) this functionality is very very small indeed. Then read it again, not so quick. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
On 19 February 2013 13:57, Marcello Duarte mdua...@inviqa.com wrote:
Inspired by Sara, here is another RFC, I finally got around to draft:
https://wiki.php.net/rfc/short-syntax-for-anonymous-function
Please feedback,
Duh, I don't think function(){} is long.
--
Regards,
Mike
Re: [PHP-DEV] Include XDebug and Suhosin Patch in Core for 5.5
[...] Sorry, but I hope you are in some funny sort of mood... Mike
Re: [PHP-DEV] PHP5.5 beta 1 is ready - Fedora RPM
On 23 March 2013 11:14, Remi Collet r...@fedoraproject.org wrote: Le 21/03/2013 14:10, Julien Pauli a écrit : Hi Internals, PHP 5.5.0 Beta 1 has been released for testing. A few months ago, PHP 5.5 have been approved as a Fedora 19 feature [1] Despite the delay due to Zend OPcache merge, I still think (and hope) PHP and Fedora roadmap [2][3] are still compatible. I just finish the mass rebuild of PHP and most extensions, so PHP 5.5.0beta1 is already part of Fedora 19. To allow more people to test this new great version, I also build backport RPM for Fedora 17, 18, Enterprise Linux 5 and 6 (RHEL, CentOS, ...) [4] Don't know if a 5.5.0 finale will be available for Fedora 19 release (end of June), but I really hope it will be possible, or at least some Release Candidate. Awesome work Remi! Thank you. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
On Mar 6, 2013 4:51 PM, Nikita Popov nikita@gmail.com wrote: I'd prefer to have nothing over having something bad. +1 Can we fix this issue, please? Nikita Mike
[PHP-DEV] DateTimeImmutable
Hi all! I am concerned by the introduction of DateTimeImmutable extending DateTime, and despite not being the talking guy, I'll try to outline the reasons why I and obviously a lot of other people think so. I can understand the frustration with a DateTime that should not have been modifiable in the first place and the wish to improve upon things and to lead users to the proper way. But, this is not the right way. If interoperability was in mind, it will not be given, because every single API which has been written in the last seven years and has DateTime in it's signature is potentially broken. The code may and should be able to expect a modifiable instance of DateTime, which is no longer guaranteed. The argument, that it was implemented this way, so that method signatures do not have to be changed, is weak, because every method has to be reviewed, and a method signature change would actually be the right thing to accept a DateTimeImmutable, because it does not act like a DateTime. It will lead to lots of boilerplate typechecking code with instanceof because it actually is not the same type. DateTimeImmutable extending DateTime will instantly create BC issues, which we will suffer from a long time. The toughtful developer, which already cloned the DateTimes in his methods won't benefit either, because now he's cloning DateTimeImmutables. In my opinion, the only way to solve this issue is through documentation, advocation, publication and providing DateTimeImmutable as a sibling to DateTime. DateTime is here, and we cannot go back in time, but we might deprecate DateTime* and introduce a date namespace in PHP-next to clean up this front, but this already goes beyond the issue with DateTimeImmutable. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Chasing an SSL stream segfault
On 2 April 2013 08:50, Rasmus Lerdorf ras...@lerdorf.com wrote: Looks like these ASN1_STRING_to_UTF8 ones are normal for libcrypto. Really hard to debug openssl stuff with all these Valgrind false positives. Still trying to track down the core on Centos 6.2. Looks like a weird build issue at this point. Might not be related, but looks like we call SSL_CTX_use_certificate_chain_file with too less arguments: http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html (note the type parameter, apparently since 0.9.8). -- Regards, Mike
Re: [PHP-DEV] Re: Chasing an SSL stream segfault
On 2 April 2013 11:36, Michael Wallner m...@php.net wrote: On 2 April 2013 08:50, Rasmus Lerdorf ras...@lerdorf.com wrote: Looks like these ASN1_STRING_to_UTF8 ones are normal for libcrypto. Really hard to debug openssl stuff with all these Valgrind false positives. Still trying to track down the core on Centos 6.2. Looks like a weird build issue at this point. Might not be related, but looks like we call SSL_CTX_use_certificate_chain_file with too less arguments: http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html (note the type parameter, apparently since 0.9.8). The openssl extension might need some refreshing review in general then... -- Regards, Mike
Re: [PHP-DEV] Re: Chasing an SSL stream segfault
On 2 April 2013 11:36, Michael Wallner m...@php.net wrote: On 2 April 2013 08:50, Rasmus Lerdorf ras...@lerdorf.com wrote: Looks like these ASN1_STRING_to_UTF8 ones are normal for libcrypto. Really hard to debug openssl stuff with all these Valgrind false positives. Still trying to track down the core on Centos 6.2. Looks like a weird build issue at this point. Might not be related, but looks like we call SSL_CTX_use_certificate_chain_file with too less arguments: http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html (note the type parameter, apparently since 0.9.8). Nevermind, I actually confused *_chain_file with *_file ... -- Regards, Mike
Re: [PHP-DEV] property de-referencing
On 30 April 2013 01:45, Rasmus Schultz ras...@mindplay.dk wrote: The characters was an arbitrary choice, just for the sake of argument. I'm not a C programmer, so I don't have a patch - there is also no RFC, but there is general interest, I'd be happy to write one. On Mon, Apr 29, 2013 at 5:22 AM, Lars Strojny l...@strojny.net wrote: Hi Rasmus, Am 25.04.2013 um 14:47 schrieb Rasmus Schultz ras...@mindplay.dk: [...] What do you think? I'm not sure about the operator character but the general idea is a good one. Do you have a patch as a POC? Do you mean something yucky like http://pecl.php.net/propro? It's actually been meant to be used by extensions for internal properties, but it might do the evil you're looking for. -- Regards, Mike
Re: [PHP-DEV] Maintaining Phar
On 25 May 2013 20:48, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, May 25, 2013 at 7:40 PM, Ralph Schindler ra...@ralphschindler.comwrote: I've asked previously (http://marc.info/?l=php-** internalsm=132096254304189w=**2http://marc.info/?l=php-internalsm=132096254304189w=2), but have not given commit karma for the phar extension. I've fixed a couple of bugs, and the last one has been sitting in the PR queue for months. ... Hi Ralph, For the record I'm still vouching for him. All previous MAINtainers are gone and there does not seem to be a lot of objection, so I'll start the +1s for a new willing contributor: +1 -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.NEXT Integer and String type modifications
On 2 June 2013 11:11, Johannes Schlüter johan...@schlueters.de wrote: On Jun 2, 2013, at 8:34, Pierre Joye pierre@gmail.com wrote: Obviously there's a pretty significant ABI break here. I propose a tweak of the Z_* macros to fix that. Basically, Z_STRLEN() will cast the result to an int. This is the same behavior as today, and will mean that existing extensions continue to function exactly as today. But new extensions (and elsewhere in core) can use a new macro Z_STRSIZE() which will return the native size_t. A new macro will be a good solution, but I would name it what it actually is, Z_SIZE_T. That's not what it is. It is the length of the string aka. var.value.str.length as such it should indicate its relation to a string. So something like Z_STRSIZE is correct (and the name is nice thinking about Unicode strings where length (characters) != size (bytes)) +1 for the idea +1 for Z_STRSIZE +1 for volunteering, as far as time permits! -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internal object orientation documentation available!
On 10 June 2013 20:33, Nikita Popov nikita@gmail.com wrote: Hi internals! We just published some rather extensive documentation on internal object orientation: http://www.phpinternalsbook.com/classes_objects.html This is part of a larger project aimed at documenting the engine and making it accessible to new contributors. Any feedback is appreciated! That looks awesome; just asking: why didn't it go into http://php.net/internals? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Protocol Type Hinting
On 25 June 2013 18:32, Laruence larue...@php.net wrote:
On Tue, Jun 25, 2013 at 11:57 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
https://wiki.php.net/rfc/protocol_type_hinting
What do you think?
Hey:
Just one question, usage? why we need this? (run-time check is
slow and I can not think out of a case then we must need it)
I'd rather see a proposal for:
$foo-setLogger(new Logger() {
function log($message) {
fprintf(STDERR, %s\n, $message);
}
});
Just sayin...
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On 25 June 2013 20:17, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I don't think we need to change the language because Netbeans can't
figure out how catch blocks work. This change doesn't provide any
functionality that wasn't available before it, and does not make the
code clearer - on the contrary, IMO it makes debugging harder and people
IMO actually it *makes* the code clearer, because $ignoredException is
not used, though a variable name like $ignored is self-explanatory,
too.
reading the code more confused. In PHP, we always valued clarity over
brevity, and I think we should keep it this way.
Duh, I find that statement a bit brave, though ;)
.oO(__{get,set,call,etc…}, object operators)
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Announcing RFC 'Anonymous Catches'
On 25 June 2013 17:07, Nikita Popov nikita@gmail.com wrote:
No opinion on leaving off $e, but I'm against the generic catch{} statement.
I second the concerns about empty catch{}.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Announcing RFC 'Anonymous Catches'
On 25 June 2013 22:23, Johannes Schlüter johan...@schlueters.de wrote: On Tue, 2013-06-25 at 13:19 -0700, Stas Malyshev wrote: Hi! If I'm to understand this RFC correctly, it is nothing more than a random suggestion someone posed in the form of a tweet and the author is saying why not add it since it's not hard to implement. So in summation Well, here we go - this is why not add it, because it makes working with such code harder without actually benefiting anybody. +1 Right now I set a breakpoint in my editor and look at an exception even if it is not used, in future I'd have to change the code for that. Hrm, this is a very good point! So this entire discussion can be summed up nicely with Let's make the variable optional because... why not?. Why not is usually not a very good principle of language design, IMO. Nothing more to add. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pgsql: Binary data support improvement
Sorry, missed the list... On 26 June 2013 09:54, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Make, 2013/6/26 Michael Wallner m...@php.net I didn't look at the code yet, but how do you know about binary format conventions of all possible types returned? Users can only specify if the result is returned as text or binary. i.e. If a user set $binary_result to TRUE, then all results(fields) are returned as binary. pgsql module does not care what binary is returned and users are responsible for correct handling. Therefore, it's only useful for bytea data type for almost all users. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] String Size Refactor Progress
On Jul 3, 2013 4:12 PM, Anthony Ferrara ircmax...@gmail.com wrote: If you want to help out, please let me know and let's try to coordinate so we don't step on each other's toes... I'm with you from August 1st, at the latest! Thanks! Anthony
Re: [PHP-DEV] New handler for retrieving properties when object is serialized
On 27 July 2013 15:58, Jakub Zelenka bu...@php.net wrote: Alternatively, could the problem perhaps be mitigated by making available some utility functions for serializing native types? We could definitely make some parts of serializer API-accessible, or even make serializer as a whole to be more API-friendly, I think it'd be a nice idea if making implementing Serializable would be made easy by reusing serializer code and combining pieces. If now it's hard making it easier definitely a good idea, much better than creating one more API IMHO. I was thinking about that and it could actually be done in a way that would resolve the problem. I have just created RFC that specify the API. https://wiki.php.net/rfc/internal_serialize_api It's backward compatible and allow portable object generation in more abstract way. What's about unserialization? Where does the state come from when recursively calling serialize? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] The day has come
Hi all! Tomorrow, August 1st 2013, is the day, it is *my* day. Some of you might already know [1] that I've been hired as a full-time PHP core developer by SmugMug. I'll officially start tomorrow. I hope that I can do a great job for all of us who need and love to use PHP. I hope that you will bear with me while I get used to all that stuff again I missed all the years busy with other things. I hope that I can contribute to existing, prospective and yet unknown projects within the PHP community in a meaningful and constructive way. Talk to me if something about me or PHP bugs you. Talk to me if you need help with your endeavour making PHP better. Talk to me even if you can't stand my attitude. Thank you and apologize my huge excitement! [1] http://m6w6.blogspot.com/2013/06/hear-hear.html -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phar bug #65028
On 24 July 2013 18:46, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! As Ferenc pointed out, Ralph volunteered for it. PHAR is too vital a part of PHP, IMHO, to be without a maintainer. Well, if he's still up to it I think we should list him as a maintainer. Ralph? So are we finally ready to give karma?! Ralph are you ready? :) -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RESEND] sapi/apache2*: USe the correct API at·server startup
On 31 July 2013 03:39, Cristian Rodríguez crrodrig...@opensuse.org wrote: To proceed with startup at the second load only ap_query_state() must be used in newish versions of apache Hi Chrisitian! Chris Jones already mentioned a year ago, that patches on the mailing list are likely to get lost, and it indeed happened! Sorry. I would really like to apply your patches but please send them complying with our coding standards, please (in your case it's mostly about indentation and trailing whitespace)! Thank you! PS: Please consider using our bug tracker http://bugs.php.net in the future. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
On 3 July 2013 19:38, Ralf Lang l...@b1-systems.de wrote: Any additional action required from my side or is it just waiting for a review timeslot? I'll soon be able to merge/align it with a solution that's been running in production for years, just give me a few days. Thank you for your patience! -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
I have added a simple test case for Linux to verify it's basic functionality via the CLI server, and think it's ready to be merged to master to be able to test it within a wider audience. Objections, anyone? https://github.com/m6w6/php-src/compare/2Guploads Thank you Ralf! -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
On 5 August 2013 14:05, Michael Wallner m...@php.net wrote: I have added a simple test case for Linux to verify it's basic functionality via the CLI server, and think it's ready to be merged to master to be able to test it within a wider audience. Objections, anyone? https://github.com/m6w6/php-src/compare/2Guploads Johannes reminded me, that we don't have C99 stdint portable typedefs in a central PHP header file available yet. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
On 5 August 2013 16:19, Pierre Joye pierre@gmail.com wrote: Hi Mike, On Aug 5, 2013 3:58 PM, Michael Wallner m...@php.net wrote: On 5 August 2013 14:05, Michael Wallner m...@php.net wrote: I have added a simple test case for Linux to verify it's basic functionality via the CLI server, and think it's ready to be merged to master to be able to test it within a wider audience. Objections, anyone? https://github.com/m6w6/php-src/compare/2Guploads Johannes reminded me, that we don't have C99 stdint portable typedefs in a central PHP header file available yet. In 5.3+ it is easier. Other parts of php deals with that. M4 Macros are there for unices, on windows you have php_stdint (which transparently includes stdint with vc11 and up). Yes, Anatol gave quite a few comments on the PR, so I knew about win32/php_stdint.h, but I was tricked by my memory about a globally (PHP-wide) available portability header :) Thanks for the heads up though! -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
On 5 August 2013 20:34, Michael Wallner m...@php.net wrote: On 5 August 2013 16:19, Pierre Joye pierre@gmail.com wrote: Hi Mike, On Aug 5, 2013 3:58 PM, Michael Wallner m...@php.net wrote: Johannes reminded me, that we don't have C99 stdint portable typedefs in a central PHP header file available yet. In 5.3+ it is easier. Other parts of php deals with that. M4 Macros are there for unices, on windows you have php_stdint (which transparently includes stdint with vc11 and up). Yes, Anatol gave quite a few comments on the PR, so I knew about win32/php_stdint.h, but I was tricked by my memory about a globally (PHP-wide) available portability header :) Alright, I rebased the 2Gupload branch against stdint: https://github.com/m6w6/php-src/compare/2Guploads https://github.com/m6w6/php-src/compare/stdint A test build on more exotic platforms would be appreciated -- I'm working on setting some up for me. Thank you. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
On 6 August 2013 23:00, Michael Wallner m...@php.net wrote: Alright, I rebased the 2Gupload branch against stdint: https://github.com/m6w6/php-src/compare/2Guploads https://github.com/m6w6/php-src/compare/stdint So, is everyone fine with it so far? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Importing namespaced functions
On 8 August 2013 14:29, Igor Wiedler i...@wiedler.ch wrote: Hi everyone, I just wanted to bump this topic, since there's not been much feedback during the last few weeks. Comments on the patch are also welcome. RFC: https://wiki.php.net/rfc/use_function Patch: https://github.com/php/php-src/pull/388 I like it. It improves the state for non-OOP in PHP. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: constructor argument promotion
On 8 August 2013 17:16, Leigh lei...@gmail.com wrote:
On 8 August 2013 14:12, Matthieu Napoli matth...@mnapoli.fr wrote:
class MyClass {
public $foo;
protected $bar;
public function __construct($this-foo, $this-bar, $baz) {
// $this-foo and $this-bar are now set
This actually feels _way_ more intuitive to me, it feels like you are
passing the parameter directly into that property.
With that style, why even limit it to the ctor?
function mySetter(array $this-items) {}
Awww. No :-/
Sorry, I have no more words on that topic.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
On 8 August 2013 14:44, Kalle Sommer Nielsen ka...@php.net wrote: Hi Michael 2013/8/8 Michael Wallner m...@php.net: On 6 August 2013 23:00, Michael Wallner m...@php.net wrote: Alright, I rebased the 2Gupload branch against stdint: https://github.com/m6w6/php-src/compare/2Guploads https://github.com/m6w6/php-src/compare/stdint So, is everyone fine with it so far? I think it is a long overdue that we have not have had this patch or similar committed, so I would say go a head and commit it to master. Thought so. I'll merge tomorrow. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zend bison check
As I have no Zend karma, is anybody kind enough to merge the bison blacklist patch? https://github.com/php/php-src/pull/402 -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5.2 RC1 is tagged
On 5 August 2013 17:46, Christopher Jones christopher.jo...@oracle.com wrote: On 8/5/13 8:12 AM, Jan Ehrhardt wrote: Julien Pauli in php.internals (Fri, 2 Aug 2013 10:05:00 +0200): Please test the release carefully and report any bugs. What is the best way to report things that are so small that opening an issue would be overkill? I have got some tiny remarks: - Typo in NEWS: OPcahce should be OPcache - Remove the reference to php_zip.dll in both php.ini-*'s - Add 'case 90' in ext/gd/libgd/gd_jpeg.c to avoid unknown for jpeg lib 9 Compiled all 4 variants with VC11 flawlessly. Jan Submit pull requests with patches, then nag until someone applies them. Then nag to get karma to make changes yourself. The OPCache typo is already fixed, I believe. http://git.php.net/?p=php-src.git;a=blob;f=NEWS;h=c01b43ed7bcda9d3c846df439cf32ead01c098d6;hb=refs/heads/PHP-5.5 The gd change might qualify for a bug report, so any background can be discussed. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.5.2 RC1 is tagged
On 8 August 2013 21:04, Michael Wallner m...@php.net wrote: On 5 August 2013 17:46, Christopher Jones christopher.jo...@oracle.com wrote: On 8/5/13 8:12 AM, Jan Ehrhardt wrote: What is the best way to report things that are so small that opening an issue would be overkill? Submit pull requests with patches, then nag until someone applies them. Then nag to get karma to make changes yourself. ++1000 PS: sorry, the send button was too tasty (re previous post) -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend bison check
On 9 August 2013 02:48, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi, I proposed that specify any bison as developer wants. It seems it is not merged, yet. Usage: YACC=/usr/local/bin/mybison ./configure diff --git a/Zend/acinclude.m4 b/Zend/acinclude.m4 index 454513f..1440a2a 100644 --- a/Zend/acinclude.m4 +++ b/Zend/acinclude.m4 @@ -12,7 +12,7 @@ AC_DEFUN([LIBZEND_BISON_CHECK],[ bison_version=none if test $YACC; then AC_CACHE_CHECK([for bison version], php_cv_bison_version, [ - bison_version_vars=`bison --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | $SED -e 's/\./ + bison_version_vars=`$YACC --version 2 /dev/null | grep 'GNU Bison' | cut -d ' ' -f 4 | $SED -e 's/\./ php_cv_bison_version=invalid if test -n $bison_version_vars; then set $bison_version_vars On Fri, Aug 9, 2013 at 8:05 AM, Ángel González keis...@gmail.com wrote: On 08/08/13 20:56, Michael Wallner wrote: As I have no Zend karma, is anybody kind enough to merge the bison blacklist patch? https://github.com/php/php-src/pull/402 Maybe it should be bison_version_exclude=none so that the error message is nicer? Thank you, I incorporated all your suggestions -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Patch for https://bugs.php.net/bug.php?id=44522 to allow uploading files above 2G.: main/SAPI.h main/rfc1867.c sapi/cgi/cgi_main.c
On Aug 11, 2013 4:42 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Hi Mike, I got test failures on session module. I guess it's related to your change. Could you take a look? For me (64-bit linux) test upload_2G.phpt also fails with this output: Test PHP 5.6.0-dev Development Server started at Sun Aug 11 02:43:04 2013 Listening on http://localhost:8964 Document root is /home/smalyshev/php-src/sapi/cli/tests Press Ctrl-C to quit. Quite strange... Why is the server's output shown here? Notice: fwrite(): send of 8192 bytes failed with errno=104 Connection reset by peer in /home/smalyshev/php-src/sapi/cli/tests/upload_2G.php on line 38 Notice: fwrite(): send of 8192 bytes failed with errno=32 Broken pipe in /home/smalyshev/php-src/sapi/cli/tests/upload_2G.php on line 38 write failed @ (30) I had this once when I filled up my tmpfs /tmp... aynthing else really no clue yet.
[PHP-DEV] Re: [PHP-CVS] com php-src: Patch for https://bugs.php.net/bug.php?id=44522 to allow uploading files above 2G.: main/SAPI.h main/rfc1867.c sapi/cgi/cgi_main.c
On a side note: all these tests pass for me on Linux/gcc and FreeBSD/clang, yet I'm still working on a Solaris/SunC build environment. On 11 August 2013 21:07, Michael Wallner m...@php.net wrote: On Aug 11, 2013 4:42 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Hi Mike, I got test failures on session module. I guess it's related to your change. Could you take a look? For me (64-bit linux) test upload_2G.phpt also fails with this output: Test PHP 5.6.0-dev Development Server started at Sun Aug 11 02:43:04 2013 Listening on http://localhost:8964 Document root is /home/smalyshev/php-src/sapi/cli/tests Press Ctrl-C to quit. Quite strange... Why is the server's output shown here? Notice: fwrite(): send of 8192 bytes failed with errno=104 Connection reset by peer in /home/smalyshev/php-src/sapi/cli/tests/upload_2G.php on line 38 Notice: fwrite(): send of 8192 bytes failed with errno=32 Broken pipe in /home/smalyshev/php-src/sapi/cli/tests/upload_2G.php on line 38 write failed @ (30) I had this once when I filled up my tmpfs /tmp... aynthing else really no clue yet. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Constant Scalar Expressions
On 14 August 2013 11:01, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! https://wiki.php.net/rfc/const_scalar_expressions I like the idea, but absence of constant support makes this thing much less useful, as you can't do things like: public $angle = M_PI/2; I think this is one of the reasons this idea was never implemented - because without constant support you're limited to doing things that are quite obvious and trivial. Yeah, I'm generally +1 on the idea; constant support would be awesome though! -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interest in a null SAPI for embedding?
On 19 August 2013 20:12, J David j.david.li...@gmail.com wrote: The big preliminary question for me would be, Is there a specific design reason why it isn't currently done this way? PHP already requires shlib's that depend on shlib's, so that functionality is probably universally available, but I can't shake the suspicion that maybe there is some has-to-be-supported platform or use case hiding at the periphery that requires static linking. I think it all was about to be as standalone as possible, e.g. you could have a CLI with builtin readline/pcntl/whatelse extensions, while mod_php could be kept lean of that and include an opcache/whatelse instead. So, I'm not sure if a libphp.so is actually something we want unconditionally... maybe if it wasn't --enable-null but something like --enable-libphp, which would create a libphp.so which would be used to link all of the specified SAPIs. Examples: Creates three static SAPIs, all with the same configure options, though: ./configure --with-apxs --enable-cli --enable-cgi ... Create each SAPI with their own configure options: ./configure --with-apxs ... ./configure --disable-cgi --enable-cli ... ... Create SAPIs which link against a libphp.so: ./configure --enable-libphp --enable-cli --enable-cgi --with-apxs ... Now that example actually points to a problem, what if I mix case 2 and 3? ./configure --enable-libphp --enable-cli --disable-cgi ... ./configure --enable-libphp --with-apxs ... Where ... could be f.e. enable-maintainer-zts or enable-debug? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Patch for https://bugs.php.net/bug.php?id=44522 to allow uploading files above 2G.: main/SAPI.h main/rfc1867.c sapi/cgi/cgi_main.c
On 19 August 2013 00:01, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Listening on http://localhost:8964 Document root is /home/smalyshev/php-src/sapi/cli/tests Press Ctrl-C to quit. Quite strange... Why is the server's output shown here? I don't know, but this is what happens with this test, so it needs to be fixed. Yeah, well, for you, but not for me, so I'm not sure what to fix. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Importing namespaced functions
On 20 August 2013 23:29, Igor Wiedler i...@wiedler.ch wrote: Hi Stas, Thanks for the notes. I will address these issues, hopefully during the next few days. Nay news on that? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Patch for https://bugs.php.net/bug.php?id=44522 to allow uploading files above 2G.: main/SAPI.h main/rfc1867.c sapi/cgi/cgi_main.c
Stas, does this problem still persist for you? On 19 August 2013 22:05, Michael Wallner m...@php.net wrote: On 19 August 2013 00:01, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Listening on http://localhost:8964 Document root is /home/smalyshev/php-src/sapi/cli/tests Press Ctrl-C to quit. Quite strange... Why is the server's output shown here? I don't know, but this is what happens with this test, so it needs to be fixed. Yeah, well, for you, but not for me, so I'm not sure what to fix. -- Regards, Mike -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PROPOSAL: temp stream for post_data
Hi, I prepared a patch to replace sapi_globals' request_info post_data and raw_post_data with a temp stream and remove support for HTTP_RAW_POST_DATA. [1] PROS: * save up to 300% on post_data_len memory (on non-form POSTs) * a local siege (c=512/512, 2.4k form/2.2k json) showed no (negative) performance impact; see attached logs * reusable php://input stream * ... CONS: * no more $HTTP_RAW_POST_DATA, where BC could easily provided with a one-liner: $GLOBALS[HTTP_RAW_POST_DATA]=file_get_contents(php://input); * memory is cheap * ??? [1] https://github.com/m6w6/php-src/compare/slim-postdata-merge -- Regards, Mike logs.json Description: application/json -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PROPOSAL: temp stream for post_data
Hi Gustavo, thank you for your review! On 27 August 2013 23:17, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On 27-08-2013 14:08, Michael Wallner wrote: Hi, I prepared a patch to replace sapi_globals' request_info post_data and raw_post_data with a temp stream and remove support for HTTP_RAW_POST_DATA. [1] PROS: * save up to 300% on post_data_len memory (on non-form POSTs) * a local siege (c=512/512, 2.4k form/2.2k json) showed no (negative) performance impact; see attached logs * reusable php://input stream * ... CONS: * no more $HTTP_RAW_POST_DATA, where BC could easily provided with a one-liner: $GLOBALS[HTTP_RAW_POST_DATA]=file_get_contents(php://input); * memory is cheap * ??? I think it's generally a good idea, but I have some concerns: * The whole point of PG(enable_post_data_reading) is to be able to read the input of the fly. If I read your patch correctly, the data is completely gobbled when you open php://input and then the temp file is reminded. This will result in a serious performance degradation on large inputs, as processing can only start after everything has been read. The behavior should be different if PG(enable_post_data_reading) is false. Ok, *I* thought the whole point of enable_post_data_reading is not to swamp your memory :) We can have that behaviour of course, but then the input stream is not reusable. * I don't see SG(request_info).request_body being closed anywhere. Is this relying just on auto-cleanup? I recall that being problematic in debug mode unless you use php_stream_auto_cleanup(). Yes, list destructors take care of that (I wrote that patch in debug mode). * The php://input streams simply forward the calls to SG(request_info).request_body, so if you open two, the per-stream cursor position may not match the position of the wrapped stream (even if it matched, we wouldn't want one stream to affect the position of the other). I True! So my input stream handles concurrency as bad as the current implementation... 8) don't see any easy way out here; all I can think of is is duping the file descriptor for the temporary file in these situations. But then the book keeping for php://input would be more complicated. I think that shouldn't be too hard to fix. But it depends on concern no.1 :) * The cast added php_stream_get_resource_id() seems unnecessary; may hide bugs. If you just want to be able to pass void* values, better to put an inline function there with a php_stream* parameter, that way you would have a compiler warning if you passed anything but a php_stream* or a void* (though this would break taking a pointer). Thanks, that's a left-over, because I had `void *request_body` in the first place. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RM decision on BUG #55801 / FR #36424
Hi, could the release manager(s) please take a decision on mentioned bug/feature request? Thanks a lot, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RM decision on BUG #55801 / FR #36424
Hi Stas, On Thu, 06 Oct 2011 17:26:49 +0200, Stas Malyshev wrote: Could you give a quick summary of what the decision point is just so I won't miss anything scanning through the discussion and these bugs? In r299770 [1] I introduced a global var_hash to serialize() so that recursive calls to serialize()/unserialize() can know about the same objects/variable references. This was IMO a good thing to do (tm), but it obviously broke serializ behaviour when called in __sleep/__wakeup, because of the order of calls: serialize(obj) - obj-__sleep does serialize() (in user code) - then internally serialize(obj-prop) happens unserialize(obj) - internally unserialize(obj-prop) is done - obj-__wakeup is called which does unserialize() (user code) As one can see the IDs of the referenced objects when unserializing cannot match the IDs at serialization time, because of the mixed up call order. So I can only see two solutions: - either disallow serialize/unserialize in __sleep/__wakeup - or revert r299770 ... unless someone else has a better idea. [1] http://svn.php.net/viewvc/?view=revisionrevision=299770 Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RM decision on BUG #55801 / FR #36424
On Sat, 15 Oct 2011 17:06:19 -0700, Stas Malyshev wrote: Hi! So, what is the status of this? I think we better revert it for 5.4 and look for solution that does not mess up existing code. Hi there! Yes, I received your mails, sorry for being quiet! I cooked up a patch which uses clean var_hashs or (un)serialize within __wakeup and __sleep. Tests pass, my test case in the bug produces a stack overflow, which is IMO expected. I'm just waiting for feedback of the bug reporter. Thanks, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
