Re: [PHP-DEV] Use zend_string* for op_array-arg_info[].name and class_name
Hi Levi,
I understood, that you don't see a big problems with the patch. :)
According to your suggestions, It's possible to do it in this way, but it's
going to be slower, because it would require additional memory allocation,
but I agree that duplicating logic in the code isn't good.
It must be better to write something like the following (I didn't test it,
but it'll work):
I'll update the patch.
Thanks. Dmitry.
char *class_name;
size_t class_name_len;
if (fe-type == ZEND_INTERNAL_FUNCTION) {
class_name = ((zend_internal_arg_info*)fe_
arg_info)-class_name;
class_name_len = strlen(class_name);
} else {
class_name = fe_arg_info-class_name-val;
class_name_len = fe_arg_info-
class_name-len;
}
if (class_name_len == sizeof(parent)-1
!zend_binary_strcasecmp(class_name, parent, sizeof(parent)-1,
sizeof(parent)-1)
proto-common.scope) {
fe_class_name = zend_string_copy(proto-common.scope-name);
} else if (class_name_len == sizeof(self)-1
!zend_binary_strcasecmp(class_name, self, sizeof(self)-1,
sizeof(self)-1)
fe-common.scope) {
fe_class_name = zend_string_copy(fe-common.scope-name);
} else {
fe_class_name = class_name;
}
On Fri, Nov 28, 2014 at 11:19 PM, Levi Morrison le...@php.net wrote:
Please review the patch
https://gist.github.com/dstogov/47a39aff37f0a6441ea0
Instead of duplicating logic in two places I'd rather grab the
relevant data first, then do the logic once:
zend_string *class_name;
if (fe-type == ZEND_INTERNAL_FUNCTION) {
class_name = zend_string_init(
((zend_internal_arg_info*)fe_arg_info)-class_name,
strlen(((zend_internal_arg_info*)fe_arg_info)-class_name), 0
);
} else {
class_name = zend_string_dup(fe_arg_info-class_name);
}
if (!zend_string_equals_literal_ci(class_name, parent)
proto-common.scope) {
fe_class_name = zend_string_copy(proto-common.scope-name);
} else if (!zend_string_equals_literal_ci(class_name, self)
fe-common.scope) {
fe_class_name = zend_string_copy(fe-common.scope-name);
} else {
fe_class_name = class_name;
}
zend_string_release(class_name);
Re: [PHP-DEV] Re: EX(scope) removing
thanks. phpdbg was excluded in my DEBUG build (I was sure I built it, may be it was enabled it default previously...) Anyway, I enabled it now, and won't miss at least build problems. According to make test, it would be great to make it run all the tests. For some reason ext/opcahce tests are excluded as well. Thanks. Dmitry. On Sun, Nov 30, 2014 at 7:25 PM, Ferenc Kovacs tyr...@gmail.com wrote: 2014.11.30. 11:14 ezt írta (Dmitry Stogov dmi...@zend.com): Sorry, I'll try to fix it on Monday. is it a compilation problem, or how can reproduce it? I've fixed it already. There were two references to scope in phpdbg, you probably missed it because phpdbg tests are not part of make test (but could be). Thanks. Dmitry. On Sat, Nov 29, 2014 at 1:01 AM, Ferenc Kovacs tyr...@gmail.com wrote: 2014.11.28. 9:24 ezt írta (Dmitry Stogov dmi...@zend.com): On Fri, Nov 28, 2014 at 7:33 AM, Xinchen Hui xinche...@zend.com wrote: Hey: On Fri, Nov 28, 2014 at 1:27 AM, Dmitry Stogov dmi...@zend.com wrote: Hi, I'm working on call/return sequence optimization. As part of this work I'm minimizing the size of call frame (zend_execute_data) and number of read/write operations on call/return. Could you please take a look into the patch that removes EX(scope) https://gist.github.com/dstogov/5ad50d582346385d587e committed. All phpt tests are passed, but I'm not completely sure about one line - https://gist.github.com/dstogov/5ad50d582346385d587e#file-ex_scope-05-diff-L193 On the other hand I can't imagine what it may break. neither do I. Matteo, can you please run your test suites with this patch. PS: I'm also going to: - pack EX(num_args) into reserved space of EX(This) done. - try to get rid of EX(frame_info) done. - try to merge EX(called_scope) and EX(This). Only one of them matters. - try to replace zval EX(This) with a pointer to zend_object EX(object) Hmm, EX(This) is not like EX(object), it will be accessed by vm handler: get_obj_zval_ptr_unused it suppores to return a zval * there. if EX(This) became a zend_object *, then we may face different handlers for IS_UNUSED and other types : Yes, I know. After the latest changes it doesn't make a lot of sense to replace ZVAL with ZEND_OBJECT*, because other data is already packed into the same ZVAL and it won't save any memory. Also zend_execute_data structure is aligned on zval boundary (16 bytes), so it makes sense to save another 16 bytes, but saving 8 bytes won't affect VM stack memory consumption. Thanks. Dmitry. Fyi this change broke phpdbg in master.
[PHP-DEV] Re: PowerPC64 patchs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 27/11/2014 13:39, Gustavo Frederico Temple Pedrosa a écrit : Hi, internals! There are some PRs for supports of PowerPC64 https://github.com/php/php-src/pull/737 https://github.com/php/php-src/pull/919 https://github.com/php/php-src/pull/920 https://github.com/php/php-src/pull/921 https://github.com/php/php-src/pull/922 I have run a build of master with each PR. Comments added on all. 922 merged. Notice: master on ppc64 seems in quite bad shape, we currently have 111 failed tests (with ./configure --disable-all). I will try to keep the ppc64 machine to run a few more tests. Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlR8PkUACgkQYUppBSnxahjBkQCg5MWGUVT/K/0XPogocxM8vTGA AOkAoNhnlvM0es5opW7Nh7Gu27Cbzi+9 =CkYT -END PGP SIGNATURE- Tests run on master on : Test on POWER8 (architected), altivec supported Linux foo 3.10.0-123.el7.ppc64 #1 SMP Mon May 5 11:18:37 EDT 2014 ppc64 ppc64 ppc64 GNU/Linux 111 failed tests: Bug #40770 (Apache child exits when PHP memory limit reached) [Zend/tests/bug40770.phpt] Bug #43128 (Very long class name causes segfault) [Zend/tests/bug43128.phpt] Bug #44069 (Huge memory usage with concatenation using . instead of .=) [Zend/tests/bug44069.phpt] Bug #55509 (segfault on x86_64 using more than 2G memory) [Zend/tests/bug55509.phpt] Stress test $x .= $x [Zend/tests/concat_002.phpt] SPL: SplFileObject::current basic [ext/spl/tests/SplFileObject_current_basic.phpt] SPL: SplFileObject::current variation error [ext/spl/tests/SplFileObject_current_error001.phpt] SPL: SplFileObject::current variation [ext/spl/tests/SplFileObject_current_variation001.phpt] SplFileObject::fflush function - basic test [ext/spl/tests/SplFileObject_fflush_basic_001.phpt] SplFileObject::fgetcsv default path [ext/spl/tests/SplFileObject_fgetcsv_basic.phpt] SplFileObject::fgetcsv with alternative delimiter [ext/spl/tests/SplFileObject_fgetcsv_delimiter_basic.phpt] SplFileObject::fgetcsv with alternative delimiter [ext/spl/tests/SplFileObject_fgetcsv_delimiter_error.phpt] SplFileObject::fgetcsv with alternative delimiter [ext/spl/tests/SplFileObject_fgetcsv_enclosure_basic.phpt] SplFileObject::fgetcsv with alternative delimiter [ext/spl/tests/SplFileObject_fgetcsv_enclosure_error.phpt] SplFileObject::fgetcsv with alternative delimiter [ext/spl/tests/SplFileObject_fgetcsv_escape_basic.phpt] SplFileObject::fgetcsv with default escape character [ext/spl/tests/SplFileObject_fgetcsv_escape_default.phpt] SplFileObject::fgetcsv with alternative delimiter [ext/spl/tests/SplFileObject_fgetcsv_escape_error.phpt] SplFileObject::fpassthru function - basic functionality test [ext/spl/tests/SplFileObject_fpassthru_basic.phpt] SplFileObject::fputcsv(): functionality tests [ext/spl/tests/SplFileObject_fputcsv.phpt] SplFileObject::fputcsv(): Checking data after calling the function [ext/spl/tests/SplFileObject_fputcsv_002.phpt] SplFileObject::fputcsv(): error conditions [ext/spl/tests/SplFileObject_fputcsv_error.phpt] Test fputcsv() : usage variations - with all parameters specified [ext/spl/tests/SplFileObject_fputcsv_variation1.phpt] SplFileObject::fputcsv(): Usage variations -- with line without any CSV fields [ext/spl/tests/SplFileObject_fputcsv_variation10.phpt] SplFileObject::fputcsv(): Usage variations -- with default enclosure value [ext/spl/tests/SplFileObject_fputcsv_variation11.phpt] SplFileObject::fputcsv(): Usage variations -- with default enclosure and different delimiter [ext/spl/tests/SplFileObject_fputcsv_variation12.phpt] Test fputcsv() : usage variations - with default enclosure delimiter of two chars [ext/spl/tests/SplFileObject_fputcsv_variation13.phpt] Test fputcsv() : usage variations - with enclosure delimiter of two chars [ext/spl/tests/SplFileObject_fputcsv_variation14.phpt] Test fputcsv() : usage variations - with default arguments value [ext/spl/tests/SplFileObject_fputcsv_variation5.phpt] Test fputcsv() : usage variations - with different delimiter and enclosure [ext/spl/tests/SplFileObject_fputcsv_variation6.phpt] Test fputcsv() : usage variations - with different delimiter and same enclosure [ext/spl/tests/SplFileObject_fputcsv_variation7.phpt] Test fputcsv() : usage variations - with same delimiter and different enclosure [ext/spl/tests/SplFileObject_fputcsv_variation8.phpt] SplFileObject::fscanf function - basic functionality test [ext/spl/tests/SplFileObject_fscanf_basic.phpt] SplFileObject::fseek function - parameters test [ext/spl/tests/SplFileObject_fseek_error_001.phpt] SplFileObject::ftruncate function - truncating with stream that does not support truncation [ext/spl/tests/SplFileObject_ftruncate_error_001.phpt] SplFileObject::fpassthru function - parameters test [ext/spl/tests/SplFileObject_fwrite_error_001.phpt] SplFileObject::fwrite function - writing with two parameters length
Re: [PHP-DEV] Use zend_string* for op_array-arg_info[].name and class_name
See the updated patch: https://gist.github.com/dstogov/08b545de6bf113113f58
it can be safely applied again and simplifies inheritance code (thanks to
Levi).
The patch saves 60K (0.5%) of code segment, and make very slight speed
improvement (visible with callgrind)
All tests are passed.
I think now the inheritance code is clear enough.
Thanks. Dmitry.
On Mon, Dec 1, 2014 at 11:02 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Levi,
I understood, that you don't see a big problems with the patch. :)
According to your suggestions, It's possible to do it in this way, but
it's going to be slower, because it would require additional memory
allocation, but I agree that duplicating logic in the code isn't good.
It must be better to write something like the following (I didn't test it,
but it'll work):
I'll update the patch.
Thanks. Dmitry.
char *class_name;
size_t class_name_len;
if (fe-type == ZEND_INTERNAL_FUNCTION) {
class_name = ((zend_internal_arg_info*)fe_
arg_info)-class_name;
class_name_len = strlen(class_name);
} else {
class_name = fe_arg_info-class_name-val;
class_name_len = fe_arg_info-
class_name-len;
}
if (class_name_len == sizeof(parent)-1
!zend_binary_strcasecmp(class_name, parent, sizeof(parent)-1,
sizeof(parent)-1)
proto-common.scope) {
fe_class_name = zend_string_copy(proto-common.scope-name);
} else if (class_name_len == sizeof(self)-1
!zend_binary_strcasecmp(class_name, self, sizeof(self)-1,
sizeof(self)-1)
fe-common.scope) {
fe_class_name = zend_string_copy(fe-common.scope-name);
} else {
fe_class_name = class_name;
}
On Fri, Nov 28, 2014 at 11:19 PM, Levi Morrison le...@php.net wrote:
Please review the patch
https://gist.github.com/dstogov/47a39aff37f0a6441ea0
Instead of duplicating logic in two places I'd rather grab the
relevant data first, then do the logic once:
zend_string *class_name;
if (fe-type == ZEND_INTERNAL_FUNCTION) {
class_name = zend_string_init(
((zend_internal_arg_info*)fe_arg_info)-class_name,
strlen(((zend_internal_arg_info*)fe_arg_info)-class_name), 0
);
} else {
class_name = zend_string_dup(fe_arg_info-class_name);
}
if (!zend_string_equals_literal_ci(class_name, parent)
proto-common.scope) {
fe_class_name = zend_string_copy(proto-common.scope-name);
} else if (!zend_string_equals_literal_ci(class_name, self)
fe-common.scope) {
fe_class_name = zend_string_copy(fe-common.scope-name);
} else {
fe_class_name = class_name;
}
zend_string_release(class_name);
Re: [PHP-DEV] Static functions Vs Nonstatic functions
Hi Stanislav.
Thank you for replying. I agree that PHP can be different from other
languages, but i think you agree that a code like this just feels wrong:
class Cube {
function weird() {
echo Duck::foo();
}
}
class Duck {
public function foo() {
echo 'My class is: ' . get_class($this);
}
}
$rubik = new Cube;
$rubik-weird(); // Output: My class is: Cube
One would never guess that $this inside a method of Duck could be an
instance of Cube. It might look silly as an example. But in the real world
someone could think a method is static when its not, and call it,
introducing a bug on the application.
I don't see any case where this behavior is useful. And even it there was
one, it could be achieved using magic methods __call() and __callStatic().
Thank you all,
*Carlos Rodrigues*
car...@jp7.com.br
2014-11-28 20:59 GMT-02:00 Stanislav Malyshev smalys...@gmail.com:
Hi!
It confuses programmers that came from other languages, prevent APIs from
having meaningful names on static methods and have no other benefit than
supporting PHP 4 code.
I think this notion of confuses programmers sometimes goes too far,
and this is one of the examples. PHP prides itself about having low
barrier to entry, but that doesn't mean you can refuse to learn anything
at all about it and PHP should change to match that.
There's nothing wrong in having static and non-static functions in the
same namespace, and many languages do the same. Some do not, so you
should just remember PHP is the one which does.
--
Stas Malyshev
smalys...@gmail.com
Re: [PHP-DEV] Feature: use Posix ACL for FPM socket
On Sun, Nov 30, 2014 at 8:33 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Nov 30, 2014 at 8:09 PM, Rowan Collins rowan.coll...@gmail.com wrote: On 30/11/2014 18:06, Remi Collet wrote: However, I think we should stop including features in our patch releases. I've heard a few others express similar sentiment, but it may have been more targeted at what we are allowing for bug fixes in patch releases. Anyway, that's my input. Yes, I'm one wanting to reduce new feature in stable branch... This is the reason why I propose this feature for 5.6 (not 5.5) and with a new option to not change default build. But that's still technically introducing a feature in a patch release. From a documentation point of view, it's a lot tidier if we only ever have to say since PHP x.y rather than since x.y.z, and as you say, there's always a risk. I don't know much about this case, but let's say a mistake allowed a misconfigured build to apply an inadvertently wide ACL; having that emerge in a patch release could mean downstream maintainers losing faith in the official releases, and make everyone's lives harder. Part of the stated aim of the release process RFC [1] was to reduce the time to get new features in a release, and the solution to that was to guarantee a release every year, so that there's never more than a few months to wait, while simultaneously having clean, safe, patch builds. The crucial paragraph is this: No feature addition after final x.y.0 release (or x.0.0). Self contained features or new SAPIs could be carefully considered on a case by case basis. That wording implies - in my opinion - that the burden of argument should be on the feature's sponsor for why an exception should be made, but there's a temptation to shoot for inclusion everywhere and see if the RM challenges it. [1] https://wiki.php.net/rfc/releaseprocess this is also my interpretation(that is should be of a case-by-case approval process instead of a RMs can veto if they really want), but I seem to be the minority on this side. having said that, I would be fine having this one in 5.6.x. For me, this feature is self contained, and even benefit from an activation switch (--with-fpm-acl) , saying it will not change the codebase if not activated. So it may be included in 5.6 However, I agree that it's bad to have : from 5.6.Z , you may use FooBar feature, better to have from 5.6. Having patches introducing new features in revision versions is hard to remember and bad for versionning Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Hi Guilherme, I read your updated RFC: https://wiki.php.net/rfc/abstract_final_class IMO the RFC as such makes sense now (abstract final confusion is eliminated. In addition to turn methods implicitly into static methods, the __construct of a static class should be implicitly private as well. I am not sure what makes more sense for PHP, but just as thought-provoking impulse, wouldn't it be better just to check that all methods are static and __construct private instead of turning methods magically into static methods and __construct private? And then there is one bit which I do not understand. What do you mean with: There's no way of adding static variables to a namespace. This would address this issue too. How does this RFC address this problem? Cheers, Robert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Hi all!
On 1 Dec 2014, at 13:58, Robert Stoll p...@tutteli.ch wrote:
I read your updated RFC:
https://wiki.php.net/rfc/abstract_final_class
Hmm, I don’t like this new RFC either. Static classes in languages like C#
exist because the language designers made the dogmatic decision to require
everything to be a class. Thus, to make collections of functions, your only
choice is to make a “utility class with a bunch of static methods. To make
this easier, the `static` keyword was added to make this easier in C# - Java
doesn’t have this keyword, but it has the same pattern of static method-only
classes. But PHP is not one of these dogmatic “everything must be a class”
languages: it has true global functions which can be namespaced.
So, why, then, does PHP need static classes? As I see it, there are two reasons:
(1) Functions currently cannot be autoloaded
(2) Encapsulation of state (private/protected static properties)
I think both of these can be solved without perpetuating what I feel is an
anti-pattern, the “utility class”. If they are solved, the need for utility
classes goes away.
To implement (1), someone just needs to go and finally implement function
autoloading. I think Joe Watkins (krakjoe) might’ve said he’d write a patch for
that, but I may be wrong. I’d certainly like to help with this effort.
Implementing (2) is more difficult. We currently don’t have file-local
variables like C has, we don’t even have namespaced variables. We do have
static variables within functions, however. I can think of a few possible
approaches to this:
(1) Say that global state is evil and refuse to implement it. Some people
(myself included, to an extent) would argue that global state is “spooky action
at a distance” and we shouldn’t be encouraging it. In this case we encourage
users to simply make normal, non-static/abstract classes and to pass an
instance around. This is generally good programming practise anyway.
(2) Add lexically-scoped variables, and allow normal global functions to be
closures. By this I mean we add something like JavaScript’s `let` keyword that
would make a variable that is unset when it falls out of scope (end of a {}
block, end of a file etc.). Then, we allow normal functions to use the `use
($var)` syntax and close over variables. That’d look something like this:
?php
let $x = 0;
function getCounter() use($x) {
return $x;
}
function incrementCounter() use($x) {
return $x++;
}
// since this is the end of the file, $x falls out of scope
I’d quite like this, as the introduction of lexically-scoped variables
would have other advantages, too. They would make foreach() by-reference much
less error-prone, for example:
?php
foreach ($array as let $item) {
// do stuff with $item
}
// $item is unset here, since it fell out of scope when we left the {}
block
(3) Add file-local variables using the `static` keyword (à la C). That’d work
something like this:
?php
static $x = 0;
function getCounter() {
global $x;
return $x;
}
// etc.
This would work similarly to `let`, I suppose, it’d just only be useful
for files.
(4) Add namespace-local variables. No idea quite how this’d work.
I’m not sure which of these is the best, though I’d leans towards (1) or (2).
But I definitely feel that adding a `static` modifier for classes is solving
the wrong problem. We don’t need to make utility classes easier to create.
Rather, we need to solve the long-standing problems which force people to
create utility classes in the first place.
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PowerPC64 - test suite
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 01/12/2014 11:09, Remi Collet a écrit : Notice: master on ppc64 seems in quite bad shape, we currently have 111 failed tests (with ./configure --disable-all). 82 fixed 29 to work on... Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlR8iPcACgkQYUppBSnxahgh5wCeOHM+skY4oEP2rc85wlma7jJQ tOoAoJEU9BVdQHkFmWsljB78Tud38K/L =gtvF -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Hi Andrea,
Thanks a lot for putting efforts thinking through this problem.
Indeed we have 3 problems that leads to static classes. You detailed 2 of
them.
The third is around encapsulation. I may want functions that are reused by
other functions at the namespace level, but that shouldn't be used outside
of it. By purely supporting (1), you still didn't address this issue. That
would be easily addressed by having private static functions inside of the
static class.
So, let me recap the 3 motivations:
(1) Function/Namespaced function autoloading
(2) State encapsulation
(3) Function scoping
Heading back to your drill down in (2), I feel that we're adding more
complexity to something that can and it is at some extent be easily
supported through classes.
I actually thought about having let originally and using as global, but
I gave up on the idea due to patch's complexity and also because it didn't
matter how far I was thinking through this, something was popping up my
head telling it was wrong. I decided to share my idea with a friend which
pointed me to HHVM's support and then I decided to work on that original
patch.
So, as you walk through your options, didn't it feel wrong to you? Static
classes are an easy addiction to the language and would have a negligent
performance impact, since it just adds 2 conditions in zend_vm and zend_api.
Again, I wouldn't necessarily use this concept I'm proposing right out the
bet, but I do see there are use cases.
I plan to redo my patch and get back for review once I finalize.
Cheers,
On Mon, Dec 1, 2014 at 9:32 AM, Andrea Faulds a...@ajf.me wrote:
Hi all!
On 1 Dec 2014, at 13:58, Robert Stoll p...@tutteli.ch wrote:
I read your updated RFC:
https://wiki.php.net/rfc/abstract_final_class
Hmm, I don’t like this new RFC either. Static classes in languages like C#
exist because the language designers made the dogmatic decision to require
everything to be a class. Thus, to make collections of functions, your only
choice is to make a “utility class with a bunch of static methods. To make
this easier, the `static` keyword was added to make this easier in C# -
Java doesn’t have this keyword, but it has the same pattern of static
method-only classes. But PHP is not one of these dogmatic “everything must
be a class” languages: it has true global functions which can be namespaced.
So, why, then, does PHP need static classes? As I see it, there are two
reasons:
(1) Functions currently cannot be autoloaded
(2) Encapsulation of state (private/protected static properties)
I think both of these can be solved without perpetuating what I feel is an
anti-pattern, the “utility class”. If they are solved, the need for utility
classes goes away.
To implement (1), someone just needs to go and finally implement function
autoloading. I think Joe Watkins (krakjoe) might’ve said he’d write a patch
for that, but I may be wrong. I’d certainly like to help with this effort.
Implementing (2) is more difficult. We currently don’t have file-local
variables like C has, we don’t even have namespaced variables. We do have
static variables within functions, however. I can think of a few possible
approaches to this:
(1) Say that global state is evil and refuse to implement it. Some
people (myself included, to an extent) would argue that global state is
“spooky action at a distance” and we shouldn’t be encouraging it. In this
case we encourage users to simply make normal, non-static/abstract classes
and to pass an instance around. This is generally good programming practise
anyway.
(2) Add lexically-scoped variables, and allow normal global functions to
be closures. By this I mean we add something like JavaScript’s `let`
keyword that would make a variable that is unset when it falls out of scope
(end of a {} block, end of a file etc.). Then, we allow normal functions to
use the `use ($var)` syntax and close over variables. That’d look something
like this:
?php
let $x = 0;
function getCounter() use($x) {
return $x;
}
function incrementCounter() use($x) {
return $x++;
}
// since this is the end of the file, $x falls out of scope
I’d quite like this, as the introduction of lexically-scoped
variables would have other advantages, too. They would make foreach()
by-reference much less error-prone, for example:
?php
foreach ($array as let $item) {
// do stuff with $item
}
// $item is unset here, since it fell out of scope when we left
the {} block
(3) Add file-local variables using the `static` keyword (à la C). That’d
work something like this:
?php
static $x = 0;
function getCounter() {
global $x;
return $x;
}
// etc.
This would work similarly to `let`, I suppose, it’d just only be
useful for files.
(4) Add
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Hi! On 1 Dec 2014, at 15:27, guilhermebla...@gmail.com wrote: Hi Andrea, Thanks a lot for putting efforts thinking through this problem. Indeed we have 3 problems that leads to static classes. You detailed 2 of them. The third is around encapsulation. I may want functions that are reused by other functions at the namespace level, but that shouldn't be used outside of it. By purely supporting (1), you still didn't address this issue. That would be easily addressed by having private static functions inside of the static class. Hmm. Well, having functions not to be used outside of the namespace/file isn’t a problem unique to classes. That would be useful for people writing normal functions. Having something like static functions would be great. So, as you walk through your options, didn't it feel wrong to you? Static classes are an easy addiction to the language and would have a negligent performance impact, since it just adds 2 conditions in zend_vm and zend_api. Yes, they’re a simple addition, but I still think they’re the wrong solution to the problem. We shouldn’t force people to use classes for simple collections of functions. People have wanted function autoloading for years. I say it’s high time we add that. Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Andrea Faulds wrote: Yes, they’re a simple addition, but I still think they’re the wrong solution to the problem. We shouldn’t force people to use classes for simple collections of functions. People have wanted function autoloading for years. I say it’s high time we add that. Maybe https://wiki.php.net/rfc/function_autoloading should be reopened? -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
On 1 Dec 2014, at 16:12, Christoph Becker cmbecke...@gmx.de wrote: Andrea Faulds wrote: Yes, they’re a simple addition, but I still think they’re the wrong solution to the problem. We shouldn’t force people to use classes for simple collections of functions. People have wanted function autoloading for years. I say it’s high time we add that. Maybe https://wiki.php.net/rfc/function_autoloading should be reopened? Perhaps. I did want to revive that RFC, but I disliked Anthony’s approach to implementing it (new set of functions, namespaced) and the patch wasn’t for phpng. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
guilhermebla...@gmail.com wrote on 01/12/2014 15:27: (1) Function/Namespaced function autoloading (2) State encapsulation (3) Function scoping I would add (4) static polymorphism, which Late Static Binding explicitly supports. But PHP is not one of these dogmatic “everything must be a class” languages: it has true global functions which can be namespaced. By the same token, PHP is not one of those dogmatic languages which says that every class must have at least one instance. There may be advantages to giving your Factory class a constructor, but there is nothing in the language itself to stop you making it entirely out of static methods, and even sub-classing it from an abstract base using LSB. The only thing missing is a standardised, enforced, annotation on the class to declare that you are using this ability and instances will never be created. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
The only thing missing is a standardised, enforced, annotation on the class to declare that you are using this ability and instances will never be created. Let's say a class has no members: what's the harm in instantiating it? Sure, it logically doesn't do anything useful, but is this user error such a big deal that we alter the language to disallow it? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Am 01.12.2014 17:37 schrieb Rowan Collins rowan.coll...@gmail.com:
guilhermebla...@gmail.com wrote on 01/12/2014 15:27:
(1) Function/Namespaced function autoloading
(2) State encapsulation
(3) Function scoping
I would add (4) static polymorphism, which Late Static Binding explicitly
supports.
Amen!
In several places in our codebase, I make use of per-request constants by
having an autoloaded baseclass file which uses class_alias for
specialization, like this:
// in some/class.inc
class some_class__base {
... common methods and default implementation
}
if (class_exists('some_class_'.SOME_CONSTANT)) {
class_alias('some_class', 'some_class_'.SOME_CONSTANT);
} else {
class_alias('some_class', 'some_class__base');
}
// in some/class/special.inc
class some_class_special extends some_class_base {
specialization ...
}
Calling code simply uses some_class::foo() without caring whether the
concrete script run then uses the specialized class, or the base class.
The only thing missing is a standardised, enforced, annotation on the
class to declare that you are using this ability and instances will never
be created.
I that regard, I'm quite happy with private function __construct, where
desired.
best regards
Patrick
Re: [PHP-DEV] Unable to subscribe to php.net website mailing list
I recently changed domains and email. I also had this issue for unsubscribing my previous email and signing up this one. Tried again a few hours later and both worked. Robert Parker *Full Stack Developer* Phone: 360-773-0963 Twitter: @yamiko_ninja On Sun, Nov 30, 2014 at 11:44 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Nov 12, 2014 at 3:49 PM, Thomas Hruska thru...@cubiclesoft.com wrote: Posting here because I'm unable to subscribe to the PHP php.net internal infrastructure discussion mailing list. http://php.net/mailing-lists.php I click the Normal radio button next to the list, enter my e-mail address, and click Subscribe. Next I get a message that says, We were unable to subscribe you due to some technical problems. Please try again later. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, sorry for the late response. I've tried reproducing your issue, first with my test email, then with yours (the one you used to send the mail I'm replying to) and for both of those, I've got the A request has been entered into the mailing list processing queue. You should receive an email at thru...@cubiclesoft.com shortly describing how to complete your request. message, and I got the confirmation mail to my test email. Tell me if you can somehow still reproduce the problem! -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Levi Morrison wrote on 01/12/2014 17:58:
The only thing missing is a standardised, enforced, annotation on the class
to declare that you are using this ability and instances will never be
created.
Let's say a class has no members: what's the harm in instantiating it?
Sure, it logically doesn't do anything useful, but is this user error
such a big deal that we alter the language to disallow it?
The same could be said of many function and class modifiers - they exist
as self-documenting, mostly compile-time, assertions. There may not be a
compelling reason to add one, but the user's self-discipline should be
good enough isn't a very compelling reason not to.
I do think the keyword should trigger simple enforcement, though, not
automagically change the behaviour.
static class Foo {
function bar() {
echo do_something_with($this);
}
}
Much nicer (and just as easy) for that to give a compile-time error of
Static class Foo cannot contain non-static function bar than for it to
autoload fine, and then give a less obvious error when Foo::bar() is run
(probably to do with a non-existent variable, since $this is always
undefined inside a static function).
Programmers, and automated tools, won't know about the static class
annotation immediately, but hopefully already know what static
function means.
Note that this is the same as with abstract function vs abstract
class, only the other way around - adding an abstract function doesn't
implicitly convert a class to be abstract, it refuses to compile if you
don't explicitly do so.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Static functions Vs Nonstatic functions
Hi!
class Cube {
function weird() {
echo Duck::foo();
}
}
class Duck {
public function foo() {
echo 'My class is: ' . get_class($this);
}
}
$rubik = new Cube;
$rubik-weird(); // Output: My class is: Cube
This code produces:
Deprecated: Non-static method Duck::foo() should not be called
statically, assuming $this from incompatible context
which informs you about the fact that what you're doing is wrong. This
capability is kept for BC reasons. There was a discussion about dropping
this from PHP 7 but it wasn't yet decided to remove the support. In any
case, this has little to do with static and non-static functions having
different namespaces.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Hi!
(2) Add lexically-scoped variables, and allow normal global functions
to be closures. By this I mean we add something like JavaScript’s
`let` keyword that would make a variable that is unset when it falls
out of scope (end of a {} block, end of a file etc.). Then, we allow
normal functions to use the `use ($var)` syntax and close over
variables. That’d look something like this:
?php
let $x = 0;
function getCounter() use($x) {
return $x;
}
function incrementCounter() use($x) {
return $x++;
}
// since this is the end of the file, $x falls out of scope
This looks like you're trying to create a class without calling it a
class. Now, I agree that not everything should be a class. But what
you're doing - set of functions linked by common behavior and sharing a
common state - is a perfect fit for something classes and objects are
used in PHP. So why not just use them instead of inventing creative ways
of doing the same but in more complicated way?
Moreover, since your example is clearly not a singleton - it is hard to
imagine any program that would have use for just one counter but never
any more - it is a classic example of something that should be an
object. It might be a wrong example, but I have hard time seeing any
example of something that has a group of functions, bound by common
functionality, has a shared state and still should not and can not be
expressed as a class/object. That's literally what they are made for.
Now, utility classes do suck, but they suck not because they do what you
described - on the contrary, they suck exactly because they are usually
a bag of random, unrelated functions bound by nothing but the common
trait of we don't have other places to put them in. But for that,
plain old functions work just fine in PHP.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Hi Guilherme, hi Robert. On 01 Dec 2014, at 14:58, Robert Stoll p...@tutteli.ch wrote: I am not sure what makes more sense for PHP, but just as thought-provoking impulse, wouldn't it be better just to check that all methods are static and __construct private instead of turning methods magically into static methods and __construct private? I very much like the RFC in its current state except for the implicit static. While we can preserve the behaviour of automatically turning methods into static methods, this should indeed trigger a warning. cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
I'm working on a patch right now and I removed the implicit configuration of static to methods. It's only missing reflection magic. Should be out of the oven in one hour or less. On Mon, Dec 1, 2014 at 2:44 PM, Lars Strojny l...@strojny.net wrote: Hi Guilherme, hi Robert. On 01 Dec 2014, at 14:58, Robert Stoll p...@tutteli.ch wrote: I am not sure what makes more sense for PHP, but just as thought-provoking impulse, wouldn't it be better just to check that all methods are static and __construct private instead of turning methods magically into static methods and __construct private? I very much like the RFC in its current state except for the implicit static. While we can preserve the behaviour of automatically turning methods into static methods, this should indeed trigger a warning. cu, Lars -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] Static functions Vs Nonstatic functions
Hi,
Glad to hear it was discussed. I understand you guys are busy and can't
just change things out of nowhere, but i wish it will be dropped in the
future.
It it gets dropped in the future i will come back and ask to make it
possible to call a static method and normal methods with the same name :P.
For now i will just wait.
Thx anyway,
*Carlos Rodrigues*
2014-12-01 15:25 GMT-02:00 Stanislav Malyshev smalys...@gmail.com:
Hi!
class Cube {
function weird() {
echo Duck::foo();
}
}
class Duck {
public function foo() {
echo 'My class is: ' . get_class($this);
}
}
$rubik = new Cube;
$rubik-weird(); // Output: My class is: Cube
This code produces:
Deprecated: Non-static method Duck::foo() should not be called
statically, assuming $this from incompatible context
which informs you about the fact that what you're doing is wrong. This
capability is kept for BC reasons. There was a discussion about dropping
this from PHP 7 but it wasn't yet decided to remove the support. In any
case, this has little to do with static and non-static functions having
different namespaces.
--
Stas Malyshev
smalys...@gmail.com
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Hi!
static class Foo {
function bar() {
echo do_something_with($this);
}
}
Much nicer (and just as easy) for that to give a compile-time error of
Static class Foo cannot contain non-static function bar than for it to
autoload fine, and then give a less obvious error when Foo::bar() is run
(probably to do with a non-existent variable, since $this is always
undefined inside a static function).
This example is fit the narrow purpose of being the example, but you
could have as easily written static function bar and be back to square
one. I'm not sure how language-enforced all methods must be static is
really useful - if you don't want to instantiate it, put a private ctor
or make it abstract. If you want static methods, just make them static.
It won't help you anyway if you use $this in static methods.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Static functions Vs Nonstatic functions
On 1 Dec 2014, at 19:48, Carlos Rodrigues car...@jp7.com.br wrote: It it gets dropped in the future i will come back and ask to make it possible to call a static method and normal methods with the same name :P. For now i will just wait. Can’t be done. It’s important for inheritance that you can call methods of the parent class, which your suggestion would prevent. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unable to subscribe to php.net website mailing list
I suspect this is a problem on certain mirrors. That explains intermittent failures, at least. On Mon, Dec 1, 2014 at 11:44 AM, Robert Parker rparker@yamiko.ninja wrote: I recently changed domains and email. I also had this issue for unsubscribing my previous email and signing up this one. Tried again a few hours later and both worked. Robert Parker *Full Stack Developer* Phone: 360-773-0963 Twitter: @yamiko_ninja On Sun, Nov 30, 2014 at 11:44 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Nov 12, 2014 at 3:49 PM, Thomas Hruska thru...@cubiclesoft.com wrote: Posting here because I'm unable to subscribe to the PHP php.net internal infrastructure discussion mailing list. http://php.net/mailing-lists.php I click the Normal radio button next to the list, enter my e-mail address, and click Subscribe. Next I get a message that says, We were unable to subscribe you due to some technical problems. Please try again later. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, sorry for the late response. I've tried reproducing your issue, first with my test email, then with yours (the one you used to send the mail I'm replying to) and for both of those, I've got the A request has been entered into the mailing list processing queue. You should receive an email at thru...@cubiclesoft.com shortly describing how to complete your request. message, and I got the confirmation mail to my test email. Tell me if you can somehow still reproduce the problem! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
On 1 December 2014 20:30:46 GMT, Andrea Faulds a...@ajf.me wrote: The problem is that, well, global state is rarely a good thing, I don’t think we should be encouraging it. To get a bit philosophical: Is it really the language's job to make that decision? Is there a difference between encouraging, allowing, and enabling? Purely static classes are a reality whether this feature is added or not. They do things namespaces can't (and probably shouldn't), but are simpler to work with than singletons (which they closely resemble) or full-blown Dependency Injection. Declaring a static class is just a way of acknowledging that this is a deliberate decision, and instance members should not be added. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] $http_response_header
Hi all, Many of you know from reading the subject line whats coming next! ;) In php, after we interact with HTTP streams (as a client), PHP conjures into local scope a variable with header information from the previous request $http_response_header. Is this behavior something we want to keep around into PHP 7? Or should we find a different/short-cut way to get the information. Currently, the same information can be ascertained, but only if there is an open file handle and only through stream_get_meta_data($fh). It would be nice if there were an as-easy approach to getting data without perhaps conjuring magic variables into the beloved local scope? Thoughts? Ralph Schindler PS Also, do we have any other local-scope variables like this? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
PR with this feature request: https://github.com/php/php-src/pull/929 On Mon, Dec 1, 2014 at 4:56 PM, Rowan Collins rowan.coll...@gmail.com wrote: On 1 December 2014 20:30:46 GMT, Andrea Faulds a...@ajf.me wrote: The problem is that, well, global state is rarely a good thing, I don’t think we should be encouraging it. To get a bit philosophical: Is it really the language's job to make that decision? Is there a difference between encouraging, allowing, and enabling? Purely static classes are a reality whether this feature is added or not. They do things namespaces can't (and probably shouldn't), but are simpler to work with than singletons (which they closely resemble) or full-blown Dependency Injection. Declaring a static class is just a way of acknowledging that this is a deliberate decision, and instance members should not be added. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Perhaps I have missed it in the noise, but have any other mainstream languages (or new hipster ones; I don't care) have something equivalent to the proposed static classes? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Yes, C# documented here: http://msdn.microsoft.com/en-us/library/79b3xss3.aspx On Mon, Dec 1, 2014 at 5:41 PM, Levi Morrison le...@php.net wrote: Perhaps I have missed it in the noise, but have any other mainstream languages (or new hipster ones; I don't care) have something equivalent to the proposed static classes? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] [RFC] Static classes (Was Abstract final classes)
Hi! To get a bit philosophical: Is it really the language's job to make that decision? Is there a difference between encouraging, allowing, and enabling? I think, yes on both. The PHP tradition is to allow doing stuff that may look weird (most languages won't allow you to do $$foo) but still there are practices that we encourage, especially in OO space, and some even that we enforce quite strictly (such as inheritance rules for methods). Purely static classes are a reality whether this feature is added or not. They do things namespaces can't (and probably shouldn't), but Of course, you can create class containing of only static members. The question is whether we need a language construct for ensuring that certain class has only static members. I'm not sure this requires a language-level construct. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
On 1 December 2014 22:28:04 GMT, Ralph Schindler ra...@ralphschindler.com wrote: Hi all, Many of you know from reading the subject line whats coming next! ;) In php, after we interact with HTTP streams (as a client), PHP conjures into local scope a variable with header information from the previous request $http_response_header. Is this behavior something we want to keep around into PHP 7? Or should we find a different/short-cut way to get the information. Currently, the same information can be ascertained, but only if there is an open file handle and only through stream_get_meta_data($fh). It would be nice if there were an as-easy approach to getting data without perhaps conjuring magic variables into the beloved local scope? Thoughts? Ralph Schindler PS Also, do we have any other local-scope variables like this? Wow, I had no idea that existed; what an incredibly ugly implementation. Even the name is weird (why header singular when it contains an array of headers?) The only other local-scope variable listed next to it in the manual [1] is $php_errormsg, which has to be enabled with an ini setting. If the information is useful at all, then I guess a get_last_http_response_headers() function would be less magic - although that would presumably mean the data had to be stashed indefinitely in an internal global just in case it was asked for, rather than it naturally falling out of scope. We could just say that if you're using a shortcut like file_get_contents, you can't have it both ways and access metadata afterwards. It's just a pity ext/curl is so faithful to the underlying lib, and therefore so awkward to use for simple cases. [1]: http://php.net/manual/en/reserved.variables.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] IntlChar class and intl_char_*() functions
On Thu, Nov 27, 2014 at 12:22 AM, Stanislav Malyshev
smalys...@gmail.com wrote:
Looking into this and also reading the \u{} proposal, I also thought -
do we have a programmatic way of doing what \u would do? I.e. if we
assume $x holds an Unicode codepoint value (i.e., an integer) do we have
a good built-in way to generate the corresponding utf8 sequence?
If not, then I think this class may be a good place to put such a
function in.
Yeah, that's some of what this class and/or set of functions would
expose. Numeric codepoint to utf8 sequence, codepoint name (e.g.
LATIN CAPITAL LETTER P) to utf8 sequence, numeric codepoint to
codepoint name, utf8 sequence to numeric codepoint, etc...
At this point I haven't heard any major directions so I'm going to
start work on implementing it so that we have a more firm base to
discuss and we can continue once I have that up for review.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unable to subscribe to php.net website mailing list
On 12/1/2014 2:19 PM, Levi Morrison wrote: I suspect this is a problem on certain mirrors. That explains intermittent failures, at least. I agree that this is possibly the issue. I did eventually get signed up. I just used the subscribe via e-mail to ezmlm method that someone here pointed out to me. Later tests seemed to work fine via the website too. Although, the first success happened after about 24 hours and trying again several times during that period. It eventually started working. If I was on a bad mirror, that would explain the issue. Sorry to drop this on internals. On Mon, Dec 1, 2014 at 11:44 AM, Robert Parker rparker@yamiko.ninja wrote: I recently changed domains and email. I also had this issue for unsubscribing my previous email and signing up this one. Tried again a few hours later and both worked. Robert Parker *Full Stack Developer* Phone: 360-773-0963 Twitter: @yamiko_ninja On Sun, Nov 30, 2014 at 11:44 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Nov 12, 2014 at 3:49 PM, Thomas Hruska thru...@cubiclesoft.com wrote: Posting here because I'm unable to subscribe to the PHP php.net internal infrastructure discussion mailing list. http://php.net/mailing-lists.php I click the Normal radio button next to the list, enter my e-mail address, and click Subscribe. Next I get a message that says, We were unable to subscribe you due to some technical problems. Please try again later. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php hi, sorry for the late response. I've tried reproducing your issue, first with my test email, then with yours (the one you used to send the mail I'm replying to) and for both of those, I've got the A request has been entered into the mailing list processing queue. You should receive an email at thru...@cubiclesoft.com shortly describing how to complete your request. message, and I got the confirmation mail to my test email. Tell me if you can somehow still reproduce the problem! -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
I think that usage may have originated in PHP, actually. Eh, dunno about that... http://lists.w3.org/Archives/Public/ietf-http-wg-old/1995SepDec/0277.html for example. Even some W3C specs use header instead of the more accurate header field so it's kind of a done deal. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Test suite results on bigendian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mostly for Dmitry After some work, I can reduce the failed tests number from 111 to 5 :) (configure --disable-all) Those seems related to new mm. = munmap() failed: [22] Invalid argument Any idea on how to debug / fix them ? Thanks, Remi P.S. I have a temporary ppc64 machine, but ono a very slow connection, very hard to debug on it :( = FAILED TEST SUMMARY - - Bug #40770 (Apache child exits when PHP memory limit reached) [Zend/tests/bug40770.phpt] Bug #43128 (Very long class name causes segfault) [Zend/tests/bug43128.phpt] Bug #44069 (Huge memory usage with concatenation using . instead of .=) [Zend/tests/bug44069.phpt] Bug #55509 (segfault on x86_64 using more than 2G memory) [Zend/tests/bug55509.phpt] Stress test $x .= $x [Zend/tests/concat_002.phpt] = $ cat Zend/tests/bug40770.out munmap() failed: [22] Invalid argument Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 3145760 bytes) in /home/remi/php-src/Zend/tests/bug40770.php on line 6 $ cat Zend/tests/bug43128.out munmap() failed: [22] Invalid argument munmap() failed: [22] Invalid argument munmap() failed: [22] Invalid argument munmap() failed: [22] Invalid argument ok $ cat Zend/tests/bug44069.out munmap() failed: [22] Invalid argument munmap() failed: [22] Invalid argument ok $ cat Zend/tests/bug55509.out 1 munmap() failed: [22] Invalid argument 2 munmap() failed: [22] Invalid argument 3 munmap() failed: [22] Invalid argument 4 Fatal error: Allowed memory size of 2202009600 bytes exhausted (tried to allocate 536870944 bytes) in /home/remi/php-src/Zend/tests/bug55509.php on line 10 $ cat Zend/tests/concat_002.out munmap() failed: [22] Invalid argument munmap() failed: [22] Invalid argument munmap() failed: [22] Invalid argument munmap() failed: [22] Invalid argument int(33554432) Done - -- rcol...@redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlR9cUIACgkQYUppBSnxahg/JgCgpBOKBPklJhjbgL+fSO2/9Fv4 DDoAoL5Mwy7/vdvoS/T9BDKMYFgNESQG =QgZg -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
