Re: [PHP-DEV] [RFC] JSON number to string
24 мая 2015 г., в 19:02, Jakub Zelenka bu...@php.net написал(а): Hi, I would like to introduce my and Pasindu's RFC that proposes adding of new JSON options for converting number values to string when decoding and/or encoding: https://wiki.php.net/rfc/json_numeric_as_string Personally I'm not a big fun of these options because of their drawbacks (see RFC section about that) and because I think that Json Scheme is a better way to go. However I'm not sure when and if I have time for Json Schema implementation, so this could be useful for some users the meantime. That is especially case of JSON_FLOAT_TO_STRING for decoding (encoding is a bit weird at it requires usage ini precision to do something useful). That (decoding) seems like a sort of a variant of JSON_BIGINT_TO_STRING for floats. That will be probably the only option that I will be vote for. I'm not sure how JSON Schema would help here. The issue is about converting from json's huge numbers to limited PHP's numbers. Schema just doesn't have notion of native types Anyway, as I told in a previous thread, while approach of this rfc solves immediate problem, it is not future-proof flexible and exposing low-level type based parsing is a better idea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] JSON number to string
On 25 May 2015, at 18:40, Jakub Zelenka bu...@php.net wrote: Anyway, as I told in a previous thread, while approach of this rfc solves immediate problem, it is not future-proof flexible and exposing low-level type based parsing is a better idea IIRC your initial proposal was about converting everything to objects which is not flexible at all as it suffers exactly from the same problems as this RFC. The only difference is using object instead of string. I think that the above is much more flexible... However as I said before it is quite a big feature that could be done only in the minor version and requires considerably more time for implementation. The difference is, that object would preserve type information from the document. Source representation would always be the string, but you will be able to know if it was typed as a Number or as a literal String. After that, application’s logic can decide what it should do with it. But yeah, sure, that is a bigger feature А. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion
On 23 Apr 2015, at 14:26, Alexander Moskalev ir...@irker.net wrote: Because currently CURLFile have this constructor: public __construct http://php.net/manual/en/curlfile.construct.php ( string $filename [, string $mimetype [, string $postname ]] ) And we cannot replace this arguments to avoid BC break. (Do not top-post please.) Well… We can introduce another class, which would inherit from CURLFile. Similar to how SplTempFileObject extends SplFileObject. А. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion
On 23 Apr 2015, at 11:59, Michael Wallner m...@php.net wrote:
Why not a ctor as in:
function __construct ($filename, $buffer = null) {
if (isset ($ buffer)) {
// use $ buffer
} else {
// use file contents
}
}
The file name parameter can be of use anyway for posted file contents from
buffer.
Looks good! So, it work like this (+ error handling)
function __construct($filename, $buffer = null)
{
$this-filename = $filename;
if (is_null($buffer)) {
$this-data = file_get_contents($filename);
} else {
$this-data = buffer;
}
}
А.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JSON float number as string
On 14 Apr 2015, at 07:31, Alexey Zakhlestin indey...@gmail.com wrote:
Feels a bit hackish
I think it is possible to introduce an overall better solution
We can expose result of json-tokenizing as a tree of objects:
JSON\Object
JSON\Array
JSON\String
JSON\Number
JSON\False
JSON\True
JSON\Null
then, it would be possible to introduce any number of experimental userland
implementations like the one proposed here
I decided to elaborate
?php
namespace JSON;
abstract class Value
{
public function toJson();
public function toNative(); // this would do, whatever json_decode does
}
class Object extends Value implements \ArrayAccess, \IteratorAggregate
{
}
class Array extends Value implements \ArrayAccess, \IteratorAggregate
{
}
abstract class Literal extends Value
{
public function toString();
public function __toString()
{
return $this-toString();
}
}
class String extends Literal
{
}
class Number extends Literal
{
public function toInt();
public function toFloat();
}
class False extends Literal
{
}
class True extends Literal
{
}
class Null extends Literal
{
}
So, in case of Number, there would be a way to get the value the way it was
stored in document using toString(), use toInt() or toFloat() to get a value
with possible precision loss or use toNative(), which would be “smart” and
return int or float using the same logic, which json_decode() uses now.
It would work the other way round too. Object::toJson() would return
json-representation of the tree.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JSON float number as string
On 29 Mar 2015, at 22:33, Jakub Zelenka bu...@php.net wrote: I would like to add a new option to JSON for dealing with large floats. The use case is mainly for decoder but can be used for encoder as well. JSON_FLOAT_AS_STRING decode: all float values will be decoded as string - It's often an issue for very large float values with many fractional digits that are coming from platforms that support larger float representation than double. In that case the conversion is lost and there is no way how to get it back (see http://bugs.php.net/68456 [pls ignore my initial dump comments when I didn't get the issue :)] and an example of the lost precision here http://3v4l.org/80iCh ). Converting the value to string keep the precision and resolves the problem. encode: all float values will be encoded as string - re-using the constant for encoder makes sense if PHP creates JSON for platform that support lower float type (e.g. C float) and the precision loss is not acceptable I think that this is more a bugfix as the precision is lost without any way how to get it back (except pre-processing json string with regular expression). I would like to add it to 5.6.x if there are no objections? Feels a bit hackish I think it is possible to introduce an overall better solution We can expose result of json-tokenizing as a tree of objects: JSON\Object JSON\Array JSON\String JSON\Number JSON\False JSON\True JSON\Null then, it would be possible to introduce any number of experimental userland implementations like the one proposed here -- Alexey Zakhlestin https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] static constructor
On 12 Mar 2015, at 02:21, Johannes Ott m...@deroetzi.de wrote:
So now I want to do my first own proposal for a new function in PHP and
I hope doing it right with starting a discussion here first.
The purpose of this suggestion is to introduce a static constructor,
which is called before the first call to class either static or
non-static to initialize some static properties which are needed by the
class.
I think about two different possible syntax to realize that purpose:
Version 1 (similar to Java):
class A {
private static $var;
static {
//Do some code here to initialize self::$var;
}
}
Version 2 (a new magic method):
class B {
private static $var;
private static function __static() {
//Do some code here to initialize self::$var;
}
}
My prefered code would be version 2 at the moment.
Looking forward to your feedback,
What about inheritance?
I think dynamic class-constructor would make much more sense.
A function which can analyse real class and do initialisation.
class A
{
protected static function __class_construct()
{
echo get_called_class().” class is defined\n;
}
}
class B extends A
{
}
output
A class is defined
B class is defined
--
Alexey Zakhlestin
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] static constructor
On 12 Mar 2015, at 19:28, Larry Garfield la...@garfieldtech.com wrote: I thought it sounded familiar. Also check the list archive for A modest proposal: __constructStatic from a month ago. It was rejected then, too. Really, I cannot think of any cases where I want to have a static class self-initialize with global data (because all statics are just globals with a fancy dress) where I wouldn't slap myself for being stupid and not just making a proper object, factory, DI, or any number of other options are are 10x more testable and reusable and verifiable. Sure there's places you could use it; there's just much better options already available in the language and have been for a decade. I guess it’s just “dreaming” about classes, which are first-class citizens, like in smalltalk/ruby/python :-) But this is just an approximation, anyway. Real class-objects probably would never happen in PHP. -- Alexey Zakhlestin https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Exceptions in the engine
On 19 Feb 2015, at 12:54, Dmitry Stogov dmi...@zend.com wrote:
I think we may introduce the following hierarchy
abstarct class BaseException {
}
class Exception extends BaseException {
}
class EngineException extends BaseException {
}
the existing code that caught Exception is going to be unaffected.
New code may decide to catch engine exception in separate catch block
(using EngineException) or in single block (using BaseException)
If I remember it correctly, BaseException was used by some real code out there.
But we can use _BaseException instead
--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [PATCH] Remove useless tests
On 20 Jan 2015, at 21:00, Joshua Rogers g...@internot.info wrote:
Respective variables are unsigned and cannot be 0.
Did you mean to use “==“ in comparisons?
---
sapi/litespeed/lsapilib.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sapi/litespeed/lsapilib.c b/sapi/litespeed/lsapilib.c
index 2e60701..20279d1 100644
--- a/sapi/litespeed/lsapilib.c
+++ b/sapi/litespeed/lsapilib.c
@@ -1442,16 +1442,16 @@ int LSAPI_ReqBodyGetLine_r( LSAPI_Request * pReq,
char * pBuf, size_t bufLen, in
char * pBufCur = pBuf;
char * pCur;
char * p;
-if (!pReq || (pReq-m_fd ==-1) ||( !pBuf )||(bufLen 0 )|| !getLF )
+if (!pReq || (pReq-m_fd ==-1) ||( !pBuf )|| !getLF )
return -1;
*getLF = 0;
while( (left = pBufEnd - pBufCur ) 0 )
{
len = pReq-m_bufRead - pReq-m_bufProcessed;
-if ( len = 0 )
+if ( len = 0 )
{
-if ( (len = readBodyToReqBuf( pReq )) = 0 )
+if ( (len = readBodyToReqBuf( pReq )) = 0 )
{
*getLF = 1;
break;
@@ -1486,7 +1486,7 @@ ssize_t LSAPI_ReadReqBody_r( LSAPI_Request * pReq, char
* pBuf, size_t bufLen )
ssize_t len;
off_t total;
/* char *pOldBuf = pBuf; */
-if (!pReq || (pReq-m_fd ==-1) || ( !pBuf )||(bufLen 0 ))
+if (!pReq || (pReq-m_fd ==-1) || ( !pBuf ))
return -1;
total = pReq-m_reqBodyLen - pReq-m_reqBodyRead;
@@ -1517,7 +1517,7 @@ ssize_t LSAPI_ReadReqBody_r( LSAPI_Request * pReq, char
* pBuf, size_t bufLen )
pBuf += len;
bufLen -= len;
}
-else if ( len = 0 )
+else if ( len = 0 )
{
if ( !total)
return -1;
--
1.9.1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [PHP-CVS] com php-src: Faster sorting algo: UPGRADING Zend/Makefile.am Zend/tests/methods-on-non-objects-usort.phpt Zend/zend_API.c Zend/zend_hash.c Zend/zend_hash.h Zend/zend_ini.c Zend
On 19 Jan 2015, at 07:52, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 01/18/2015 02:08 PM, Rasmus Lerdorf wrote:
We have to be really really careful with this oh, that code is wrong,
so we can break it argument. This will break hundreds if not thousands
of sites in a hard-to-debug way. It took me less than a minute of
looking on Github to find a case that will break:
https://github.com/chenboking/service.downloadmanager.amule/blob/cda510415f9a58660e096a7de42b3ea6f39ee851/webserver/php-default/amuleweb-main-search.php#L121
It is extremely common to just do a less-than or a greater-than check in
a user comparison function. Of course it isn't textbook-correct, but
since it has always worked, people do it.
And just to further illustrate this, I just downloaded the current
Wordpress release and sure enough, Wordpress would also be broken by
this change.
In http://core.svn.wordpress.org/trunk/wp-includes/class-simplepie.php
look at the sort_items() method:
/**
* Sorting callback for items
*
* @access private
* @param SimplePie $a
* @param SimplePie $b
* @return boolean
*/
public static function sort_items($a, $b)
{
return $a-get_date('U') = $b-get_date('U');
}
I am not saying we should revert the change, but we need to be very
aware of the effect this change will have on PHP7 adoption. The really
nasty part is that even if a big codebase has unit tests covering the
code, unless the unit test actually tests an array with more than 16
elements, all tests will pass and the application will only fail in
production with production data. And there are no errors or warnings of
any sort either that will help people track this down.
This will need to be front and center in the UPGRADING doc with an
explanation about how to write a proper ordering function.
Should we add E_STRICT for cases when comparison-function returns non-integer
value?
Having it in stable version should help to fix such anti-patterns in a long-run
--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7
On 21 Dec 2014, at 16:53, Alain Williams a...@phcomp.co.uk wrote: On Sun, Dec 21, 2014 at 02:30:28PM +0100, Nikita Popov wrote: Please take a look at the WordPress version statistics: https://wordpress.org/about/stats/ According to these statistics 72% of the WordPress installations are running on either PHP 5.2 or PHP 5.3. This means that they do not benefit from the quite substantial performance and memory usage improvements that went into PHP 5.4. So, if people aren't willing to upgrade from PHP 5.2/5.3 to PHP 5.4, I don't see how they'd be more interested in PHP 7. I am running PHP 5.3.3 on my servers. Why ? Summary: running newer versions is a lot of effort. I run CentOS 6 so I run the PHP that is packaged for it. While it might be nice to have PHP 5.6 it would involve me in a lot of work (compile from source) and I would need to do that with each new release/patch. As it is I just go 'yum update' and security fixes, ..., are all installed - easy peasy. did you hear about RHSCL? http://developerblog.redhat.com/2014/06/04/red-hat-software-collections-rhscl-1-1-now-ga/ it solves this usecase nicely -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] setcookie() minor BC break - fixes issue #67736
On 03 Nov 2014, at 02:21, Dan Ackroyd dan...@basereality.com wrote: On 2 November 2014 15:10, Rowan Collins rowan.coll...@gmail.com wrote: Wait, what does session handling have to do with any of this? Sorry, I completely failed to write what I was trying to say there. I meant that like the session handling functions and setcookie are similar in that: * They don't feel that nice to use. * The exact behaviour of them is currently correct but doesn't cater for higher level logic e.g. making a script setting the same cookie be an error rather than accepting it. Both of them could probably do with being made nicer - but that can be done in user-land. There's no _need_ to fix them in the core libraries. well, one thing which could be done is decoupling building of cookie-header from adding this header to the response. setcookie(…) = header(build_cookie_header(…)) this would be much closer to what I would call a low-level API -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 14 Jul 2014, at 16:58, Andrea Faulds a...@ajf.me wrote:
One of the issues with the RFC as it stands is how to handle bool casting.
While int, float and string only allow lossless casting (with the exception
of objects, but we can’t really do anything about that), bool’s behaviour at
the moment is quite different. I don’t think it makes sense so I won’t
discuss the current behaviour, only possible new ones.
One option is simply to forget about being lossless and make the bool type
hint accept any value, meaning any truthy value or any falsey value would
yield what is expected without error. This would ensure that if some stupid
programmer (like myself ;) has passed in a non-boolean truthy/falsey value to
your function, it’ll be handled correctly. It would mean all your bit hacks
($foo FLAG etc.) would work, anything you got from $_GET (e.g. ?foobar=1).
However, this is unlikely to catch bugs in code, because literally any PHP
value would work. For that reason, I’m not sure this is the way forward.
I don’t think that scalar casts” should do any additional error-catching. they
target a very different usecase.
It shouldn’t guarantee correctness of the whole program. It should guarantee
that variable types are fixed inside of function.
In my opinion, this patch should act 100% similar to zpp.
And if, at some later point zpp-behaviour changes similar change should happen
to userland scalar casts
Some people talk about inconsistency, which is introduced by reusing same
syntax for strict parameter types and scalar parameter casts”. There’s some
truth there.
Let’s use different syntax.
This might work:
function foo((int) $a)
{
var_dump($a);
}
I would read it as declaration-level casting
--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 14 Jul 2014, at 18:57, Andrea Faulds a...@ajf.me wrote: On 14 Jul 2014, at 15:54, Derick Rethans der...@php.net wrote: A compromise by adding more inconsistencies. I can buy the cast of scalars vs hint--of-complex types, but definitely not the introduction of a new group of casting rules. Keep it simple. It doesn’t change the casting rules; write an error handler that ignores E_RECOVERABLE_ERROR and you get exactly the same result as a manual cast inside the function. Rather, it simply adds validation. The casting works like casting does everywhere else, but there’s strict lossless validation on the type hint, similar to the non-scalar type hints except more lenient as it allows equivalent values of other types. ok, it might work for me if formulated like this. now, the question is, would it be possible to port these rules to zpp in PHP-Next? if the answer is “yes, then I’m all for it. otherwise, I’m a bit skeptical as inconsistency between extension-land and user-land code worries me -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing PUT data)
On 02.10.2013, at 10:59, Michael Wallner m...@php.net wrote: Since ever people are confused by _GET and _POST superglobals, because, despite their name, they do not (really) depend on the request method. Therefor I propose to phase out $_GET and name it $_QUERY and I propose to phase out $_POST and name it $_FORM (I'm not 100% confident with the latter yet, though). Further, I propose to remove the POST method restriction for handling request bodies and solely rely on the content type to trigger the parser(s). (*) There are already parsers for application/x-www-form-urlencoded and multipart/form-data in the core. One could think of providing an API to add content type handlers from extensions, ext/json may be an example, like it is hacked into pecl_http-v2. Thoughts, objections, insults? (*) We'd probably have to revisit all *post* INI variables, though. So, that is not one, but three proposals: 1. _GET - _QUERY, _POST - _FORM I don't think this is really necessary. Names are there historically and changing them will break a lot of stuff. +0 on aliasing, and soft-deprecation (via documentation) though 2. ignore request-method, trigger body-processing solely on Content-type +1. makes sense 3. expose body-parsers via php-level API +1. Hell, yes! Something like +1000, actually ;) -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing PUT data)
On 02.10.2013, at 11:24, Michael Wallner m...@php.net wrote: On 2 October 2013 09:17, Alexey Zakhlestin indey...@gmail.com wrote: 3. expose body-parsers via php-level API +1. Hell, yes! Something like +1000, actually ;) Uhmmm... I actually meant an interal API not userland :) well, why not both? :) string/stream in, array out -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HTTP supergloblas and request body/query (was: Parsing PUT data)
On 02.10.2013, at 15:12, Leigh lei...@gmail.com wrote: On 2 October 2013 08:31, Michael Wallner m...@php.net wrote: I had it, but I'm not sure $_BODY fits either, because it should be an array. Currently only form data fits the purpose of de-serialisation of a request body. Not so sure about that. I don't think there is a rule that says a body _has_ to be in query string name=value format, or that multipart elements _have_ to have a name=something attribute. I could quite easily imagine PUT requests containing a textual body without an associated field name (the URI would contain the field name). (correct me if I'm wrong) In these cases, Content-type of body would different. And proposal mentions that interpretation should happen strictly basing on the content type -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [VOTE] Change crypt() behavior w/o salt
On 24.09.2013, at 5:41, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, It's been a whole from the discussion. I setup vote for RFC: Change crypt() behavior w/o salt. https://wiki.php.net/rfc/crypt_function_salt If I missed something, please let me know. strangely, this RFC is not shown in In voting phase section here: https://wiki.php.net/rfc is that done manually? -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] [RFC] Skipping parameters take 2
On Tue, Sep 3, 2013 at 11:47 AM, Lester Caine les...@lsces.co.uk wrote: Robert Williams wrote: PHPDoc doesn't support parameter blocks, which means that IDEs can't offer the same level of assistance with code-completion that they offer for both objects and straight parameters -- another huge downside. PHPDoc's does 'not' not support parameter blocks ... you just document them properly in the first place. Switching these to formalised objects introduces another level of complexity that detracts from their use rather than enhancing it, but again that is more to do with maintaining BC. Something that has become a second class citizen nowadays? PSR-5 (draft) does support them: https://github.com/phpDocumentor/fig-standards/blob/master/proposed/phpdoc.md#7-describing-hashes -- Alexey Zakhlestin, http://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Importing namespaced functions
On 19.07.2013, at 21:29, Igor Wiedler i...@wiedler.ch wrote: Hello internals, I posted the initial idea for a use_function RFC a few months back. I would like to make the proposal official now, and open it for discussion. I also did some work on a patch that probably still has some issues. Review on that is welcome as well. RFC: https://wiki.php.net/rfc/use_function Patch: https://github.com/php/php-src/pull/388 I don't see much space for discussion :) It's a very useful addition with nice explicit semantics and a small patch. +1 -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] execute compressed PHP command-line application
On 18.07.2013, at 12:38, crankypuss fullm...@newsguy.com wrote: I've been using PHP for linux command-line applications. Some are quite large. I've built the code to combine the mainline plus everything it calls into a single file to avoid portability issues with include libraries. I've built the code to compress the resulting file using gzdeflate after optionally stripping comments and excess whitespace. didn't you just reinvent the PHAR? http://docs.php.net/manual/en/intro.phar.php Phar archives are best characterized as a convenient way to group several files into a single file. As such, a phar archive provides a way to distribute a complete PHP application in a single file and run it from that file without the need to extract it to disk. Additionally, phar archives can be executed by PHP as easily as any other file, both on the commandline and from a web server. The Phar extension is built into PHP as of PHP version 5.3.0 so you don't need to explicitly install it. It's already present in PHP -- Alexey Zakhlestin CTO at Grids.by/you https://github.com/indeyets PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
On 21.02.2013, at 20:08, Levi Morrison morrison.l...@gmail.com wrote: Personally I would love to see more RFCs focusing on performance and less on syntax changes. Some recent tests I performed indicate that JavaScript and Dart are both significantly faster than PHP when working with just arrays and numbers. If anyone is interested I can provide the test code for more scrutiny. I'd like to see more performance enhancements but I am not against other enhancements as well. That is expected. Both of them use JIT-compilation, which is not present in PHP. There was some effort to implement PHP in PyPy/RPython, but it is not active http://morepypy.blogspot.ru/2012/07/hello-everyone.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On Thu, Feb 14, 2013 at 7:21 PM, Zeev Suraski z...@zend.com wrote: O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) Questions (I haven't dug through the code): - What do CLI processes share? IIRC nothing, presently it's not very useful for CLI except for testing (it'll only apply to a single run). I could be wrong though, Dmitry? Well, if it does block-level optimizations, that is already enough to make it useful for CLI-scripts, as even though caching is not relevant for long-running processes, optimizations should make things faster. Are optimizations documented? -- Alexey Zakhlestin, http://github.com/indeyets -- 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 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 -- Alexey Zakhlestin https://github.com/indeyets -- 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 07.02.2013, at 16:33, Leigh lei...@gmail.com wrote: 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. well, 2 reasons: 1. it needs to be injected into main() of php_cli.c 2. it can become a good start for official CLI extension. CLI SAPI has functionality, which is specific to it and exposing it to userland could be useful -- Alexey Zakhlestin https://github.com/indeyets -- 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 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); bool cli_title_set(string); string cli_title_get(); -- Alexey Zakhlestin https://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZTS - why are you using it?
On Tue, Jan 29, 2013 at 1:03 PM, Zeev Suraski z...@zend.com wrote: Which brings me to the subject of this mail – why are you using ZTS PHP instead of single threaded PHP? The reasons not to use it are few but fairly major – it’s significantly slower than the non-ZTS PHP, and it’s significantly less robust in the sense that a single bug somewhere can bring down an entire server (or at least a bunch of many different threads). What are your reasons to choose it over FastCGI? I use it for long-running processes, when I need something like http://pecl.php.net/package/pthreads But, those are scenarios, when I don't need bytecode cache, because everything is preloaded in real memory -- Alexey Zakhlestin, http://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_map() function modification
On 12.01.2013, at 21:34, Thomas Hruska thru...@cubiclesoft.com wrote:
This would allow developers to do things like:
$keys = array('key1', 'key2', ..., 'keyn');
$vals = array('val1', 'val2', ..., 'valn');
$somemap = array_map($keys, $vals);
Which would result in $somemap containing:
array('key1' = 'val1', 'key2' = 'val2', ..., 'keyn' = 'valn')
There is a function for this:
http://docs.php.net/array_combine
--
Alexey Zakhlestin
https://github.com/indeyets
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fixing insecure cURL file uploading
On 06.01.2013, at 6:38, Stas Malyshev smalys...@sugarcrm.com wrote: Following the recent discussion on the list, I've drafted an RFC describing the CurlFile solution for it here: https://wiki.php.net/rfc/curl-file-upload Please review and comment. If there's a general positive feedback, I'll try to implement a patch for it pretty soon. Looks elegant and extensible. Great work! -- Alexey Zakhlestin https://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release frequency?
On 02.01.2013, at 7:26, Stas Malyshev smalys...@sugarcrm.com wrote: I see that we do not have a lot of changes in 5.4 since last release. So I wonder if it may make sense to reduce release frequency now that we got less bugfixes coming in, say from monthly to 1.5 or 2 months between release. What do you think? Just to be clear, I have no problem (excepting unforeseen circumstances, of course) still doing monthly, just not sure it's worth it if we'd have less than 10 bugfixes per release… if there's at least one REAL bug fix in release it's worth it -- Alexey Zakhlestin https://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release frequency?
On 02.01.2013, at 16:33, Johannes Schlüter johan...@schlueters.de wrote: Alexey Zakhlestin indey...@gmail.com wrote: if there's at least one REAL bug fix in release it's worth it So, what is a real bugfix? Most things are responses on bug reports by users. Form them it is real. String typos are not real. Segfault fixes and inconsistent behaviour fixes are real. -- Alexey Zakhlestin https://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Git Access
On 06.12.2012, at 3:38, Sara Golemon poll...@php.net wrote: RTFMing is hard, thanks. :) remote: Welcome pollita. remote: Changesets accepted. Thank you for your contribution. remote: remote: Attempting to push to mirror g...@github.com:php/php-src.git remote: Write failed: Broken pipe remote: fatal: The remote end hung up unexpectedly To https://git.php.net/push/php-src.git c058ed5..5ac3577 master - master The push to git.php.net succeeded, but its push to github failed. Is there a process that deals with keeping the repos in sync in events like this? I believe it will eventually sync, as push propagates all changes, not just specific commit -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5
I voted no, (b) We should mention deprecation in manual as hard as possible, we should mention it in ext/mysql/config.m4 and any other place we can reach. Then, at some point (I'm fine with 5.6, but 6.0 would do also), we should just move it to PECL, without using E_DEPRECATED -- Alexey Zakhlestin, http://github.com/indeyets -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generics proposal
On 21.10.2012, at 0:59, Nikita inefe...@gmail.com wrote: Hello, list. I want to propose generics. skip So, what you think? I'm against having this in PHP. For IDEs, the better solution is to use generics-like syntax in docblocks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
On 16.08.2012, at 0:18, Rasmus Schultz ras...@mindplay.dk wrote: How come there is no straight-foward obvious way to simply remove a given value from an array? Well, this sounds like a reason for creating SplSet class -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions
On 24.07.2012, at 15:20, Laruence wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
Will it work without catch in your implementation?
try {
doSomethingDangerous();
} finally {
doCleanup();
}
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Regarding PHP6, string/array APIs
On 20.07.2012, at 4:09, Stas Malyshev wrote:
Hi!
2. It would be really useful to have 2 versions of each function: one
which mutates the variable and one which returns the new variable.
Example:
?php $src = 'SoUrCe'; $result = lowered($src); // $result ==
'source', $src == 'SoUrCe' $result = lower($srd); // $result ==
true, $src = 'source' ?
I'm not sure I understand why. What's wrong with $src = lowered($src);?
That's just convenience. matter of readability.
lower() can be implemented in userland and if we had standard userland
library that would be a good place for it :)
function lower($str)
{
$str = lowered($str);
}
Also, when lower() returns not true? If there's a legitimate situation
when it must return not true (I can't think of any, but maybe for more
complex functions there is) what lowered() is supposed to do in the same
situation? If there's none, why bother returning true?
As you said, it might be needed in more complex functions and it makes sense to
return true just for consistency.
Other option is to (implicitly) return null and use exceptions.
And I, personally, would prefer exceptions ;)
3. Speaking of implementation… Functions, which return slice of
string/array could be made to reference the same memory-areas as the
source strings/arrays. That is until the first modification, of
course. Kinda advanced copy-on-write semantics. I know something like
that is implemented in D http://dlang.org/d-array-article.html and
Go
Strings are not modified in PHP (IS_STRING zvals can be modified but the
actual string buffers aren't) so there's no actual write and thus no
copy needed. But having this would require separate refcounting on
string values, which may be a bit complicated to do.
much worse than that. refcounting on string-slices!
4. casting between strings and arrays of characters would be a great
thing to have too. this way, useful array-oriented functions could be
applied to strings
We already have it, it's str_split().
I know. But that is not casting. I can not pass string to the function which
expects array (thinking about array_map, array_filter, …). I have to call
str_split explicitly.
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Regarding PHP6, string/array APIs
Anthony, the whole concept is interesting. Can you probably write that as RFC. I believe that will make it easier to read/understand it. Right now, I have only one question: On 20.07.2012, at 4:33, Anthony Ferrara wrote: The benefit here, is that user types can implement the same core interface and be used polymorphically with the core types (for at least the base API). So then, countable() would disappear. what is this core interface? something magically assumed for internal types but explicitly defined as interface for user classes? or implicit case-by-case interface like in python? signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Make try/catch brackets optinal
On 20.07.2012, at 12:33, Ivan Enderlin @ Hoa wrote:
Making braces optional for try/catch does:
+ not break backward compatibility;
+ add consistency in the PHP syntax;
± offer a new way to write buggy programs but no more than with other control
structures (think about goto ;-)).
I see more + than - here. Am I wrong?
You are not wrong. This is the inconsistency and it makes sense to fix it.
We are definitely not going to unfix it for if/else, so I +1 your proposal
in advance
Moreover, in parallel, a new idea has been landing: introducing the “rescue”
keyword as a shortcut/replacement of try/catch, such as:
$foo = callThatCouldThrow() rescue 'oof';
Is it possible to chain it, such as:
$foo = callThatCouldThrow() rescue anotherCallThatCouldThrow() rescue 'oof?';
Maybe we should start another topic because it could be a nice idea.
I don't see value in this. finally would be much more valuable.
try {
doSomething();
} catch (\Exception $e) {
handleException();
} finally {
genericCleanup() // called if everything is good, if everything is bad or
even if exception is rethrown
}
signature.asc
Description: Message signed with OpenPGP using GPGMail
[PHP-DEV] Regarding PHP6, string/array APIs
Stas made a good point about need to start with new API, which then can be followed by syntactic sugar. So, we need some ideas to start with: 1. A lot of people told, that it would be a good idea to come with a written standard regarding arguments order. I don't care what it will be, as long as it will be documented. 2. It would be really useful to have 2 versions of each function: one which mutates the variable and one which returns the new variable. Example: ?php $src = 'SoUrCe'; $result = lowered($src); // $result == 'source', $src == 'SoUrCe' $result = lower($srd); // $result == true, $src = 'source' ? 3. Speaking of implementation… Functions, which return slice of string/array could be made to reference the same memory-areas as the source strings/arrays. That is until the first modification, of course. Kinda advanced copy-on-write semantics. I know something like that is implemented in D http://dlang.org/d-array-article.html and Go 4. casting between strings and arrays of characters would be a great thing to have too. this way, useful array-oriented functions could be applied to strings signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Make try/catch brackets optinal
On 19.07.2012, at 13:49, Paul Dragoonis wrote: 2) Try with only one line in it to throw an exception doesn't seem like a realistic situation. It could be something like this: try $object-method(); catch (\Exception $e) return false; and -method(), obviously, can have quite a long and complex structure signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On 17.07.2012, at 21:03, Stas Malyshev wrote:
Hi!
This idea has been proposed many times in the past and it is actually
a very good proposal, for array, string or other types.
If we have $array-foo(), we should also have class foo extends
array which allows to override foo() in array. This will require some
serious changes, which need to be RFCed and reviewed and seen if they
can really fit the language properly. Just saying let's bolt on method
calls on top of arrays is definitely not very good. Having OO Array
type may be good, if we will be able to figure out suitable design that
will allow the same flexibility and power as regular arrays - though I'm
not sure how to do it now.
The only reason why it is not yet implemented is the technical
complexity to do it. We need pseudo objects and the likes, and it is
really not something easy to do, in an efficient enough way.
I disagree - I do not think we need pseudo-objects. If the only point of
the exercise is to convert a call of array_pop to $array-pop, it's not
worth it. It'd just make the language more messy - you wouldn't know
what - means anymore.
+1
I am for making array a proper class with methods.
Legacy functions can be implemented as wrappers around it:
function array_push($array, $value)
{
$array-push($value);
}
There is absolutely no sense in creating new pseudo object entity. It would
just add tons of confusion.
p.s. in case of array, we already have http://docs.php.net/ArrayObject which is
a good starting point
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On 17.07.2012, at 21:50, Stas Malyshev wrote:
Hi!
I am for making array a proper class with methods.
Legacy functions can be implemented as wrappers around it:
function array_push($array, $value)
{
$array-push($value);
}
The problem there is that array has different semantics than object. Not
completely, but for example if you pass array to function, it is passed
by value and is not modified, but objects are always mutable when passed
to functions. Changing this semantics will break a lot of code.
Having special handling of Array objects doesn't sound good too. And I don't
see any nice solution.
Options are:
* 5-to-6 tool, similar to python's 2-to-3 converter, which will fix code.
* introduce some kind of per-file declare() option, which would enable
pass-by-reference semantics of arrays/strings/etc. in 5.5 which would let
people write the same code for 5.5 and 6.x
Well, actually, there's one more option: we can introduce Autocloned
interface (empty, without methods) and force cloning of objects, which
implement this interface, during parameter-fetching phase.
This would allow us to have 2 sets of classes: One set which implements this
interface (slower, but backwards-compatible) and another set which doesn't
(faster, but not compatible).
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On 17.07.2012, at 23:01, Stas Malyshev wrote: Hi! Options are: * 5-to-6 tool, similar to python's 2-to-3 converter, which will fix code. Do you know any practical way of how such tool could work? That would be: tokenizer + static analysis (with type inference) + replacing some of the tokens. Not a trivial task, but definitely doable. And a large amount of php code (popular tools, frameworks, …) for writing tests :) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
On 17.07.2012, at 23:20, Stas Malyshev wrote:
Hi!
That would be: tokenizer + static analysis (with type inference) + replacing
some of the tokens.
Not a trivial task, but definitely doable.
So what would this tool do with this code?
$a = getFirstArrayName();
$b = getSecondArrayName();
$$a = $$b;
$b[1] = 0;
Something like this:
$a = getFirstArrayName();
$b = getSecondArrayName();
if ($$b instanceof ArrayObject) {
$$a = clone $$b;
} else {
$$a = $$b;
}
$b[1] = 0;
Or this:
include 'a.inc';
$a = $b;
include 'b.inc';
where a.inc has array $a and b.inc has something like $b[1] = 0; but you
have no way of knowing it since by the time you run the tool a.inc and
b.inc are not available to it (think config files).
well, the same as above. not pretty, but that's a safe fallback when type
inference is not available.
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PHP-DEV] MYSQL_OPT_RECONNECT
On 09.07.2012, at 14:17, Johannes Schlüter wrote: an example like this: $pdo = new PDO(mysql:...); $select = $pdo-prepare(SELECT * FROM t WHERE id = ?); /* do something ... connection break in between */ $delete = $pdo-prepare(DELETE FROM t WHERE id = ?); $select-execute([1]); This will in fact do a DELETE, not a SELECT as the statement handle effectively is nothing but a per-connection counted unsigned long. Well, this sounds like a bug Prepared statements should become invalid once connection is lost and further attempts to execute them should lead to exception -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
On 18.06.2012, at 1:54, Pierre Joye wrote: I guess SCrypt binding could be implemented. http://www.tarsnap.com/scrypt.html Using yet another dependency for that? Not good. That's easier and safer than implementing this on our own. That's the best available option at the moment. http://stackoverflow.com/questions/1226513/whats-the-advantage-of-scrypt-over-bcrypt This post says the exact opposite, just saying :) The post says, that SCrypt is better, because it is way harder to solve. Bcrypt requires a lot of CPU, but SCrypt requires a lot of CPU + a lot of RAM It is BSD-licensed, so we can easily bundle it with PHP Maybe nice to have in pecl.' Sure, that's an option, but pecl won't help php to have default state-of-art password hashing toolset ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
On 18.06.2012, at 19:42, Pierre Joye wrote: It is BSD-licensed, so we can easily bundle it with PHP Maybe nice to have in pecl.' Sure, that's an option, but pecl won't help php to have default state-of-art password hashing toolset ;) There is sadly only state-of-art-right-now password hashing methods. We have to keep that in mind :) Sure. but SCrypt is tuneable. One can increase both CPU and RAM complexity and CPU complexity is set as function of time. Which means, that if one upgrades CPU in his server, while leaving settings the same complexity will increase automatically. This feature makes it future-proof to some degree. Well… until quantum computers become ubiquitous ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding a simple API for secure password hashing?
On 14.06.2012, at 1:31, Nikita Popov wrote: So, wouldn't it be better if PHP provided an easy to use API for secure password hashes natively? So you just have to call a single function, which magically handles everything for you (like salt generation). A simple sample API could be two functions password_hash($password) and password_hash_verify($password, $hash). But it could just as well be a fancy, extensible OOP API. I guess SCrypt binding could be implemented. http://www.tarsnap.com/scrypt.html That's the best available option at the moment. http://stackoverflow.com/questions/1226513/whats-the-advantage-of-scrypt-over-bcrypt It is BSD-licensed, so we can easily bundle it with PHP For the reference, here's the Python binding: https://bitbucket.org/mhallin/py-scrypt/src -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies with constructors in SPL
On Tue, May 17, 2011 at 4:22 AM, Benjamin Dubois benjamin.dub...@gmail.com wrote: Why not make all objects (maybe implicitly) extend a single root object, containing just skeleton ctor/dtor and implemented in the engine ? I don't know if it is actually possible in PHP, but that works for several other languages (java, objC - in that case, the root object is explicit-, C# AFAR) This would also bypass the error-level debate (no error would be thrown) +1 -- Alexey Zakhlestin, http://twitter.com/jimi_dini http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplFileObject Countable
On Tue, Mar 15, 2011 at 1:54 PM, Nick Pope p...@nickpope.me.uk wrote: Currently we have: SplFileInfo -- information/metadata about a file. | V SplFileObject -- modify/access contents of a file. It could make sense to subclass this to provide methods for accessing information about the contents of a file. As for a name, I'm not sure what would be best, but perhaps something like SplFileData. Maybe someone else can come up with a better name? probably SplTextFileObject, as these methods make sense for text files -- Alexey Zakhlestin, http://twitter.com/jimi_dini http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: built-in web server in CLI.
On Wed, Mar 2, 2011 at 11:55 PM, Moriyoshi Koizumi m...@mozo.jp wrote: Hi, Just to let you know that I wrote a RFC about built-in web server feature with which PHP can serve contents without a help of web servers. That would be handy for development purpose. If interested, have a look at http://wiki.php.net/rfc/builtinwebserver . Interesting, indeed. I noticed, that you hardcode mimetypes and index_files. Mimetypes can probably be obtained from the system — we even had some extension doing that. And index_files should be configurable, because there are some situations when people don't want any mime-types at all. Also, it would be good to be able to configure which files are actually parsed by php, not just served. Currently, these are only .php files -- Alexey Zakhlestin, http://twitter.com/jimi_dini http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Clarification on the Enum language structure
On Wed, Feb 23, 2011 at 4:35 PM, Martin Scotta martinsco...@gmail.com wrote: Martin Scotta On Wed, Feb 23, 2011 at 7:12 AM, Ben Schmidt mail_ben_schm...@yahoo.com.auwrote: Are you suggesting this as an enum member function, or just a regular function in any old class? Enum member funcion? How much it should be like a class before you call it a class? Exactly. It's crazy. If you want a 'member function' use a class, not an enum. why not supporting methods for enum values? developers will need that, and by providing type hinting, they will just create the logic somewhere else... why would developers need this? can you elaborate with some real-life scenario? I thought enums are just strong-typed constants -- Alexey Zakhlestin, http://twitter.com/jimi_dini http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Clarification on the Enum language structure
On Thu, Feb 24, 2011 at 5:00 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! You can do it like this. When an enum is defined: I'm not talking about implementation in the code of PHP engine. I'm talking about writing code with these things that wouldn't produce fatal errors in random places without you being able to prevent it and without checking before each function call. Compiled languages deal with it easily because they check these things on compile - if you try to send int variable where BlahBlah type is expected, the compiler bails out and you know it's a problem. Dynamic languages don't work that way. except, that it could be handled by thow new InvalidArgumentException() but we don't allow exceptions in core -- Alexey Zakhlestin, http://twitter.com/jimi_dini http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Clarification on the Enum language structure
On Wed, Feb 23, 2011 at 4:29 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! public function Killjoy(MyEnum $x) What would be the purpose of such code? What would it do if 5 is passed as $x? IMHO, it should fail (unless 5 is the value explicitly mentioned in MyEnum definition) -- Alexey Zakhlestin, http://twitter.com/jimi_dini http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP for embedded device: reduce size
On Sat, Feb 19, 2011 at 9:24 PM, Martin Herrman mar...@herrman.nl wrote: All, I have cross-compiled php-cgi for a MIPS device (mediaplayer), but the binary is quite large, more than 3MB. I'm using: ./configure --prefix=../result/php-5.3.5 --host=i686-pc-linux-gnu --target=mipsel-linux-gnu --build=mipsel-linux-gnu --enable-cgi --disable-all --without-pear --with-config-file-path=/etc/ Which options do I have to reduce size of the binary? E.g. can I remove the zend engine? what do you mean by remove the zend engine? zend engine is the core, upon which php is built. -- Alexey Zakhlestin, http://twitter.com/jimi_dini http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.6RC1 Released for Testing
On 17.02.2011, at 16:17, Johannes Schlüter wrote: The first release candidates of 5.3.6 was just released for testing and can be downloaded here: http://downloads.php.net/johannes/php-5.3.6RC1.tar.bz2 (md5sum: f78d7b47ddbfca42ebdfcdef2adfe859) The windows binaries are available at: http://windows.php.net/qa/ This is the first step in the release process of this versions and goal is having a 2nd RC two weeks from now. Majority of the changes are of the bug fix variety. To ensure that the release is solid, please test this RC against your code base and report any problems that you encounter. Here's the changelog: http://svn.php.net/viewvc/php/php-src/tags/php_5_3_6RC1/NEWS?revision=308400view=markup smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Lambdas assigned to constants. Was PHP Annotations RFC + Patch
On Thu, Sep 16, 2010 at 10:35 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
const foo = function () use ($globalVar) {
};
How would you call this thing? foo()? Then you have a problem - foo()
already has meaning, and it's call function named foo, not get constant
named foo and call function inside if it's there.
His idea is, that get constant named foo and call function inside if
it's there should be the only meaning
and function foo() {} should be syntactic sugar for defining
constant foo with closure inside.
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Earliest zend_eval_string can be called?
On Sat, Sep 18, 2010 at 1:37 AM, Matthew C. Rice mr...@rcs.us wrote: Hello, I was wondering how early a zend_eval_string call can be made. Currently it works fine in a PHP_FUNCTION(), but was hoping to put it in a PHP_MINIT() in hopes of it just executing once. It seems PHP_MINIT() is too early, and is causing failures. I came across PHP_GINIT_FUNCTION(), but can't seem to find when its called exactly, but the same situation as PHP_MINIT() seems to be the case, where its too early. In short, I am wondering if there is any place I can put the zend_eval_string() call in hopes of it running just once, so its result could be retained throughout the module execution. definitely, not earlier than PHP_RINIT(), which doesn't help you. all php's userland code is executed in the sandbox and sandbox exists between PHP_RINIT and PHP_RSHUTDOWN the only way to execute userland code before serving requests is to use long running process, which serves requests from userland. That's what I do in http://github.com/indeyets/appserver-in-php -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] #52563: Adding E_NONE and/or E_EVERYTHING constants
On Tue, Aug 24, 2010 at 10:14 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! use an E_ constant with error_reporting and not have the current situation where sometimes you use a constant (or constants) and sometimes you use a bare number, depending on what you want to achieve. What's wrong with using 0? 0 means nothing, how hard is that? ` The only downside is, that programmer will need to know, that E_* constants do mean numbers. With adding E_NONE this knowledge would be unnecessary and people would be able just to think in terms of abstract symbols -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Thu, Aug 12, 2010 at 10:59 AM, Lester Caine les...@lsces.co.uk wrote: Stas Malyshev wrote: 1. What's missing and should be added? First thing perhaps ... which IS Pierre's problem ... Windows snapshots But short of trawling the commit tree ... what HAS already been added? ( links to the CURRENT release notes from the windows site are broken by the way ) We have NEWS for this, don't we? If you are referring to the release notes, yes, I was just pointing out that people who are directed to windows.php.net do not get the same level of support as Linux users and currently those links are broken. But the main point was ... where is the NEWS for all the features added to trunk? We need the alpha to create the news to decide what needs changing before releasing. http://svn.php.net/viewvc/php/php-src/trunk/NEWS?view=markup -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Wed, Aug 11, 2010 at 11:41 PM, Lester Caine les...@lsces.co.uk wrote: Ilia Alshanetsky wrote: +1, I think that's the most sensible solution for now that would allow us to proceed with 5.4, something we all seem to be in agreement on. A slight aside here, as I have not be bothering about what HAS been implemented typing wise ... A large section of the code a work with passes a range of data to functions and classes. If the function gets an integer it looks up the record with that id, an array assumes the data is already loaded, and perhaps a string value defines that a new record of that name is to be created. So I don't want the parameters passed to be tied to a single type. Is THAT affected by any of the current typing actions? both suggested type-hinting strategies are optional. so, you, as developer, are free to not use type-hinting and accept any data you like -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Thu, Aug 12, 2010 at 12:01 AM, Zeev Suraski z...@zend.com wrote: At 22:50 11/08/2010, Alexey Zakhlestin wrote: On Wed, Aug 11, 2010 at 11:41 PM, Lester Caine les...@lsces.co.uk wrote: Ilia Alshanetsky wrote: +1, I think that's the most sensible solution for now that would allow us to proceed with 5.4, something we all seem to be in agreement on. A slight aside here, as I have not be bothering about what HAS been implemented typing wise ... A large section of the code a work with passes a range of data to functions and classes. If the function gets an integer it looks up the record with that id, an array assumes the data is already loaded, and perhaps a string value defines that a new record of that name is to be created. So I don't want the parameters passed to be tied to a single type. Is THAT affected by any of the current typing actions? both suggested type-hinting strategies are optional. so, you, as developer, are free to not use type-hinting and accept any data you like Alexey, It's been explained countless times why this is WRONG. Please read the archives. If you have and you disagree with it, please take it as an axiom - a feature being 'optional' does not take away from any confusion or complexity associated with it. It's been a design guideline in PHP from the get go, we're not going to give up on it now. You misunderstood my comment. Lester asked if he can still have his APIs without type-hinting and I told him that he can. That's all We're not talking about complexities of understanding -- Alexey Zakhlestin http://www.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] back to 5.4 alpha
On Thu, Aug 12, 2010 at 12:28 AM, Lester Caine les...@lsces.co.uk wrote:
Zeev Suraski wrote:
You're absolutely right, sorry about that!
Zeev
However if this is something controlled by php setup, it becomes another
'register_global'. If my users have to have it off for my projects and on
for others ... complexity in managing instead :(
Nothing is controlled by php setup.
It is perfectly ok to not specify type-hints in your functions.
both of these are fine:
function a($var) {}
function b(int $var) {}
you just keep using syntax of a and everything works. you CAN
specify typehint like in b but you don't have to.
p.s. if something is still not clear, let's take this talk away from list
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bugs assigned to cellog
On 01.07.2010, at 1:24, Gregory Beaver wrote: Hi, I will be unable to fix even the smallest bugs assigned to me, it would of great assistance if a developer who has both time and a reliable Internet connection would step in and fix them. The phar.phar bug should be easy. The tar/zip difference needs a sample zip that does not work and the others I don't know about. I would be happy to fix them under ordinary circumstances, but I have no free time (my daughter just started walking) and will only have Internet through my phone until mid-August. Php development on a phone is nor possible yet :) You just have a wrong phone :-P Anyway, my congratulations on your new project :) I'll take a look at that zip bug. Bumped into it myself, so have some personal interest. -- Alexey Zakhlestin http://www.milkfarmsoft.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Performance problem with php
On 20.06.2010, at 10:49, Vincenzo D'Amore wrote: Hello, to have a performance problem with apache/mod_php5 configuration under heavy load the website becomes too slow. Using strace I found what appears to me a strange behavior The strange behavior I want point out is related to a sequence of tentative httpd/mod_php5 does in order to read an php page. let's start with the basics. what version of php is this? what version of apache (and which mpm) is this? what OS is this? -- Alexey Zakhlestin http://www.milkfarmsoft.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
On 14.06.2010, at 11:28, Ferenc Kovacs wrote: quoting Denis: Actually all the methods are wrappers against the native PostgreSQL commands (connection status, copy to/from). I needed to develop them as methods because it is not possible to get the same results with a sql statement (in particular for connection status). It was not possible also for COPY TO/FROM because of the way PostgreSQL handle them ( special functions were developed also for the old pgsql driver). I don't know sqlite or IBM, but the MySQL SELECT INTO OUTFILE is a plain SQL statement, you don't need any special pdo function to use it, on the other hand, you can't use the postgresql's COPY TO/FROM with PDO without the patch above. Did I misunderstood something? well, even if it's possible to do as sql in mysql, it is still possible to implement as the method. p.s. actually, as we're talking about trunk it is still possible to implement these methods in generic fashion. I can provide implementation for pdo_mysql (unless anyone else will be faster). does anyone know enough about ibm's api to provide implementation for it? -- Alexey Zakhlestin http://www.milkfarmsoft.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
On 12.06.2010, at 15:54, Ilia Alshanetsky wrote: The concerns you raised about custom methods specific to database drivers were not reflective of the PDO's intent as was clarified by Wez and myself. The code that was introduced was specific to PostgreSQL, the common functionality was introduced in a way that allows each driver to implement. I agree with Ilia on this. Piece of functionality which is common was implemented in generic way. Piece of functionality which is not common was implemented as postgresql-specific extension. That's exactly how it should be and the fact of updates to PDO is awesome on it's own. On Sat, Jun 12, 2010 at 12:24 PM, Pierre Joye pierre@gmail.com wrote: hi Ilia, So you basically say that the worries and wishes raised here are simply irrelevant and at the end of the day you decide what PDO can or cannot be? I'm very disappointed by these two commits. I don't think it is the way we should develop PDO and it is clear that I'm not the only one to think that. As it is trunk, I won't battle too much to revert it but be sure that is not something I will let in for any of the upcoming releases as it is clearly bad design. Cheers, -- Pierre -- Alexey Zakhlestin http://www.milkfarmsoft.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Proper return after throwing exception
On 10.06.2010, at 23:41, Pieter de Zwart wrote: Hey guys, Another n00b question: What is the proper way to return from a function after throwing an exception? My code looks like: zend_throw_exception(amqp_connection_exception_class_entry, blah blah blah, 0 TSRMLS_CC); return; Should I instead RETURN_FALSE from there? It doesn't really matter, as return value will never be checked. return should be enough -- Alexey Zakhlestin http://www.milkfarmsoft.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] [PATCH] New PDO methods for PostgreSQL driver
On 24.05.2010, at 22:04, Pierre Joye wrote: hi Ilia, On Mon, May 24, 2010 at 7:53 PM, Ilia Alshanetsky i...@prohost.org wrote: since when? PDO was designed to allow drivers to provide their own functions, which many drivers do. We discussed that on the PDO list, and we try to avoid to add drivers specific methods. That's obviously makes sense given the goal of PDO. Well, if driver provides some unique functionality, which can't be implemented any other way, I'd say, that it should be implemented. If there is a way, to make this functionality generic, it should be generic. Limiting ourselves to Least Common Denominator is not the best idea. -- Alexey Zakhlestin http://www.milkfarmsoft.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] PHP 5 X PHP 6
On 18.05.2010, at 19:33, Mathias Grimm wrote: Is the http://wiki.php.net/rfc for both php5 and php6? there are differents developer teams for dev 5 and 6 ? When something new comes to php 5, php 6 must implement it to? At the moment, there is no such thing as php 5 there is php5.3 and there is trunk trunk includes all changes from php5.3 and some more -- Alexey Zakhlestin http://www.milkfarmsoft.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Re: Turkish/Azeri locale support
On 04.05.2010, at 16:44, Steven Van Poeck wrote: Adam Harvey wrote: Well, I'm going to assume that people have had whatever say they were going to. It seems that we have three options, so let's put it to a vote. (To be completely clear, this is purely for trunk. This certainly isn't a candidate for backporting to 5.3.) The options are: 1. Apply Tomas's patch to make case-insensitive lookups locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for case-insensitive function/method name lookups for high-bit characters in single-byte encodings. (Not that we've ever advertised or documented that.) 2. Make function/method names case-sensitive, per Stan's e-mail. Pros: fixes problem; brings PHP into line with most other languages; extra consistency with variables; possible performance improvement. Cons: BC break from current documented behaviour. 3. Do nothing. Pros: no BC breaks of any kind. Cons: continues to annoy Turkish and Azeri developers and those developing for those locales. If you'd care to reply with a vote for option 1, 2 or 3, I'll tally up the votes in a week or so. And yes, I am volunteering to deal with this should option 1 or 2 be picked. my vote: option 2 that's the most consistent solution -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debugging a PHP Extension via GDB
On 22.04.2010, at 17:51, Sebastian Kurfürst wrote: Hello everybody, [I hope this is the right list for this question, if not, it'd be great if you could point me to the right direction]. I'm currently developing a PHP Extension which is built as dynamic library, and not directly into PHP core. I'm trying to figure out how to set break-points inside the extension with GDB, so debugging is easier. So far, I started gdb with gdb /my/path/to/php (which has debug symbols enabled); and then tried to set a breakpoint into my extension via: break /path/to/php/extension/objectmonitor/objectmonitor.c:80 GDB then asks: No source file named /path/to/php/extension/objectmonitor/objectmonitor.c. Make breakpoint pending on future shared library load? (y or [n]) y When I run php with a script via run index.php, the system does not stop at the set break-point. Do you have any hints how to make this work? This really would help me tremendously. Do you use debug-build of PHP? There won't be symbols in regular build -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php 5.3, memory leak
I was doing some tests with long-running scripts recently and noticed that 5.3 is leaking memory in cases where 5.2 wasn't. Looks like there is bug report already: http://bugs.php.net/bug.php?id=48781 PHP 5.3 was announced as more suitable for long-running scripts than 5.2 was, because of circular-references garbage collector. But this bug undermines this. So, I believe this bug is a critical one. Should be a blocker for 5.3.3 Bug-report tells that this bug was assigned to Dmitry, but, as there were not comments from him, I am not even sure if he's actually aware of the problem. Did anyone try to investigate the issue? smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Supplying nothing at all for default parameters
On 06.04.2010, at 14:16, Richard Quadling wrote:
Hello.
A suggestion I would like to make is to allow for nothing to be
supplied for defaulted parameters.
I suppose the easiest way of describing this issue is with the
following code ...
?php
function foo($bar, $baz = 9, $buzz = 10) {
return $bar $baz $buzz;
}
// Whatever is supplied for $baz will be used for $baz.
// User has to know the default value of $baz rather than just
allowing the default value.
echo foo(1, 9, 20);
I don't know the stylics on using default parameters, but for the user
to have to know the default value would sort of make the default
redundant.
// Passing nothing at all could be one option.
echo foo(1, , 20);
but who would want to see ...
echo anotherfoo(1, , , , , , , 20);
for example.
Maybe a new keyword ... (ala SQL syntax).
echo foo(1, default, 20);
another solutions is to use named parameters as suggested in one of the recent
discussions.
named parameters allow you to specify only those parameters which you need and
not care about order of parameters
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] unsigned chars
On 05.04.2010, at 13:01, donald sullivan wrote: is it possible to return unsigned chars from an extension? I have looked and cant find anything on it, or maybe i am looking for the wrong keywords. Return to PHP-code? No. PHP doesn't have explicitly signed or unsigned chars. PHP has strings you can return: 1) string of chars 2) int (array of ints?) Also, see http://docs.php.net/ord ord() function converts first byte of byte-string to it's unsigned numeric representation -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unsigned chars
Use reply all when writing to mailing-list. On 05.04.2010, at 13:18, donald sullivan wrote: what i am trying to do is RSA encryption I have a working setup doing encryption and decryption at the same time. i want to store the encrypted value and be able to decrypted it later if i encrypt the data and send the data straight to the decrypt function it works fine int decryptRetVal = RSA_public_decrypt(512, Buffer, plainText, rsaPubKey, RSA_PKCS1_PADDING); if i try to send the output of the encryption to the php side for storage, or even write it to a file and then read that file for decryption it fails every time int decryptRetVal = RSA_public_decrypt(512, (unsigned char *)Z_STRVAL(zret), plainText, rsaPubKey, RSA_PKCS1_PADDING); how can i store the encrypted output for later use? well, it should work you don't give details, so I can't say what are you doing wrong. I can give you only generic debugging advices: make sure that the data you store on php-side is equivalent to the data you expect to get on C-level. If it is not — try to locate the step which corrupts the data, etc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php and multithreading (additional arguments)
On 05.04.2010, at 13:46, Moriyoshi Koizumi wrote: I used to play with TSRM days ago and successfully implemented userland threading support using GNU Pth. It's just a proof of concept and I did it for fun. So these are share-nothing worker-threads, which can send results to master-thread using messages. right? I am perfectly fine with such approach some stylistic moments: * I would use closures instead of callback-functions * Is extra language construct really needed? function-call would work just fine Is overhead of starting new thread large? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php and multithreading (additional arguments)
On 01.04.2010, at 22:38, Stanislav Malyshev wrote: Hi! processing, but then the state syncing of the forked background processing results with the main thread requires a whole new protocol / switching to interprocess communication, which makes such developments unnecessarily hard. Threads exist for a _reason_ not only because they sound cool. Interesting thing here threads would require (at least if they are implemented the way C, etc. threads usually work) whole new protocol of synchronization too. Just think about something: do you have shared classes/variables/etc.? If you do, how you control access to them? Hello locks and the whole can of worms! Most people that think they can program in threads actually are just pushing their luck until some complex interaction leaves their app malfunctioning in a bizarre way and them without any means to debug it. I mean, you can do it right, but it's usually harder than it looks. Share-nothing exists for a reason too :) Well, strictly speaking, there are [at least] 2 models which can be used: 1) Classical with shared resources and locking 2) STM Anyway, do we really have to tell people you don't need it when they believe that they do? Python has multithreading and it works reasonably good. People who know what they are doing can implement really brilliant solutions (think Tornado) And something like GIL feels like a reasonable compromise to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to trace a crash bug?
On 27.03.2010, at 9:05, Thomas Hruska wrote: One thought: Has a way to track call depth been considered (perhaps _execute())? If the number of calls exceeds a certain (reasonable) number, a warning or notice could be displayed and the output buffer flushed. That way, when it crashes, there is a log of some sort for the function. Then again, I don't know Zend well enough to make that sort of judgment call and such a thing could affect performance. XDebug can do this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DTrace RFC
On 25.03.2010, at 13:24, David Soria Parra wrote: Hi, I would like to backport the DTrace patches that were committet to the latest trunk. This is related to RFC http://wiki.php.net/rfc/dtrace . If there are no objections I'll commit this within the next weeks. As DTrace doesn't break BC I think it should be a big deal. objections? no objections from me. should be committed :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010, at 0:58, Antony Dovgal wrote: On 24.03.2010 00:05, Zeev Suraski wrote: How do you propose to describe the same set of options using php.ini syntax? Yes, simple things like value=Yes/No or value=DIR fit just fine into php.ini. But how would decribe a set of pools each with its own set of options? (taking into account that some of these options may override global options) option... anotheroption... [pool1] option... anotheroption... [pool2] option... anotheroption... Okay, here is XML based config quickly converted to php.ini-style syntax: skipped… I won't discuss how it looks to me, but there is only one problem: it doesn't work. That's because php.ini doesn't support nested sections and without them it turns into a real mess. looks almost like YAML ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] XML binding mapping library
On 16.03.2010, at 10:46, John wrote: Hello, people. I am looking for community feedback about my ideas for XML binding persistence library: skip… Are you thinking about implementing it as some kind of extension? or about php-code? or just reusable C-library with bindings for PHP? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
On 14.03.2010, at 17:43, dreamcat four wrote: You should implement UTF-8, with a view to still allow adding UTF-16 support later on. That is to say, the encoding should be wrapped, and switchable underneath. Of course all that is easier said than done with PHP. But thats the right way to do it. I think you misunderstand and probably there are others too… The discussion is not about which encodings should be supported and which should not. PHP6 in its current form supports pretty much all encodings there are. The discussion is about which encoding should be taken as internal representation. Currently, PHP6 uses UTF-16 for this purpose. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 12.03.2010, at 22:06, Pierre Joye wrote: Many tests fail because they are written for a given platform, or even worst (from a portability point of view), only for a given configuration (library version, system version,etc.). And that's not about windows vs other, tests can work on a Debian/ubuntu version and fail on another. Well, these tests should just be removed/rewritten. Php-tests should test php, not libraries -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 12.03.2010, at 22:20, Stanislav Malyshev wrote: Hi! Well, these tests should just be removed/rewritten. Php-tests should test php, not libraries That's easy to say - but how exactly you're going to test functionality of, say. ext/intl without testing the underlying ICU library? Well, here's the way I see it: Extensions (including ext/intl) declare their API and tests are made againt this API. No more and no less. If, for example, some error-text comes directly from underlying library and extension doesn't have control over it it shouldn't be part of API. In this case we can test that some error-text was returned but we shouldn't test for exact text-match -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tests repository
On 12.03.2010, at 22:23, Pierre Joye wrote: On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin indey...@gmail.com wrote: On 12.03.2010, at 22:06, Pierre Joye wrote: Many tests fail because they are written for a given platform, or even worst (from a portability point of view), only for a given configuration (library version, system version,etc.). And that's not about windows vs other, tests can work on a Debian/ubuntu version and fail on another. Well, these tests should just be removed/rewritten. Php-tests should test php, not libraries I would be interested to know how can we test the file API without testing libc, for example. see my reply to Stas. The idea is to test things which we can guarantee. If our documentation says, that function does this or that, then we should check for it and wrap system-calls in such way, that our file API always does these things or fails in strict predictable manner. And if we can't guarantee some behaviour then we should add corresponding note to documentation and we shouldn't add tests. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
On 31.01.2010, at 9:11, Richard Lynch wrote: I have taken the liberty of making an RFC for this: http://wiki.php.net/rfc/url_dots thanks. looks good to me -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/NEWS branches/PHP_5_2/ext/pcre/pcrelib/AUTHORS branches/PHP_5_2/ext/pcre/pcrelib/ChangeLog branches/PHP_5_2/ext/pcre/pcrelib/HACKING bra
On 29.01.2010, at 1:39, David Soria Parra wrote: On 2010-01-22, Johannes Schlüter johan...@php.net wrote: Hi, On Thu, 2010-01-21 at 17:49 +, Ilia Alshanetsky wrote: iliaaThu, 21 Jan 2010 17:49:38 + Revision: http://svn.php.net/viewvc?view=revisionrevision=293812 Log: Upgraded bundled PCRE to version 8.01 This seems to depend on some parts of C99, at least stdint.h, by that it breaks the build for some compilers. Yes I have the same opinion as johannes. We should decide if we want C99 or not, and then use the appropriate compiler flags. At the moment we depend on lazy compilers and libc's that allow you to include c99 stuff without telling the compiler to use c99. As Johannes already said, this breaks PHP for some compilers and some libc's. As far as I remember, it was decided that C99 is ok for php6. Anyway, we probably need to compose some table on what compilers have limited (and how limited) support for c99. Then we can objectively decide if we can leave those aside Probably we can decide on limited subset of C99, which is ok to use. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_2/NEWS branches/PHP_5_2/ext/pcre/pcrelib/AUTHORS branches/PHP_5_2/ext/pcre/pcrelib/ChangeLog branches/PHP_5_2/ext/pcre/pcrelib/HACKING bra
On 29.01.2010, at 13:32, Pierre Joye wrote: On Fri, Jan 29, 2010 at 9:36 AM, Alexey Zakhlestin indey...@gmail.com wrote: As far as I remember, it was decided that C99 is ok for php6. I can't remember any decision about C99. I remember some talk with andrei on irc… I guess we never wrote that down Anyway, we probably need to compose some table on what compilers have limited (and how limited) support for c99. Then we can objectively decide if we can leave those aside That's not a solution, or we kill solaris, HPUX, windows, etc. support. GCC does a very bad job here by enabling part of C99 by default and breaking the other half of the specs. Also C99 is pretty much a bastarized version of C++ in an incompatible way. The price to accept C99 is too high, especially when all we use (in 99.9% of what the usages) is stdint/stdbool. Simply detect and define them at configure time will kill the need to use c99 and keeps us on the good/right side (what I do on win for example,easy) :) you forgot about C++-style comments :) Does Visual Studio support none of C99? I thought recent versions had partial support -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
On 21.01.2010, at 18:21, Richard Lynch wrote: For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet another php.ini flag (sorry!) to choose the behaviour. -1 from me. I don't think we need to keep backward compatibility for this. PHP-6 is a major release, after all. It would be absolutely enough to add optional var-name conversion to extract() -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function call chaining
On 19.01.2010, at 13:47, Christian Schneider wrote: Alexey Zakhlestin wrote: Would be nice if something like this worked too: (new Class())-method(); If you *really* want to do this you can use a factory method: Class::create()-method(); I know. That's what I do if I need it. Or just create temporary variable But, still, I want consistent syntax, which doesn't put limitations on me this construct is an example of things, which many people take for granted and are shocked, when they discover, that they can't use it. I saw a lot of questions on forums regarding it -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function call chaining
On 19.01.2010, at 3:27, Stanislav Malyshev wrote:
Hi!
I wrote a small patch that enables this kind of syntax in PHP:
foo()();
What it means is that if foo() returns callable value (which probably should
be function name or closure) then it would be called. Parameters and more
than two sets of () work too.
Of course, this is mostly useful for doing closures, and that was primary
drive for implementing it - to make working with closures and especially
function returning closures easier.
What does not work currently is $foo-bar()() - since it is surprisingly hard
to tell parser it's not {$foo-bar}()() - which of course is not what I want
to do.
I like it!
regarding $foo-bar()()…
is it possible to use precedence rules here? something like:
($foo-bar())();
What do you think? If somebody has better idea btw - maybe make something
like {foo()}() - and make that work for any expression inside {} - that might
work too. So, what do you think?
why curly braces?
Parentheses would feel more natural here.
Would be nice if something like this worked too:
(new Class())-method();
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] about dl() in php6
On 17.01.2010, at 14:46, hack988 hack988 wrote: In Online document about dl function http://www.php.net/manual/en/function.dl.php This function has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged. It's mean we can't Loads a PHP extension at runtime sine version 5.3.0 and higher version or it has another way to load extension at runtime? it is disabled in mod_php and similar SAPIs. It is still available in CLI and CGI see http://www.php.net/manual/en/function.dl.php#function.dl.notes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debian PHP patches
On 17.01.2010, at 1:05, Gwynne Raskind wrote: On Jan 16, 2010, at 4:18 PM, Jani Taskinen wrote: 115-autoconf_ftbfs.patch Hell no. You're breaking the configure again with this crap. I already reverted the idiocy once, don't even think about doing this shit again. PHP configure works properly only with autoconf-2.13 which was the last working autoconf. Which autoconf was the last working one is a matter of opinion at this point. The Autoconf people would love for us to stop using 2.13 - the only reason it still exists is because we use it. (Or so I'm told, anyway, I don't know this for a fact firsthand.) Personally, I'd rather see PHP go to CMake. CMake does have its own host of problems, but they could be dealt with. And yes, I would volunteer to revive the CMake effort. strong +1 from me would be glad to help -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 release schedule and other bits
On 12.01.2010, at 23:48, Raphael Geissert wrote: Hello, At Debian we are planning to include PHP 5.3 in Squeeze, the next stable release. As such, I would like to know for example when we could expect 5.3.2 and 5.3.3 to be released. Great news! Does it mean, that 5.3 will move to unstable branch soon? (currently, Debian has 5.3 only in testing) On a slightly different topic, I'd like to express that I would like to improve the communication between us (the package maintainers) and you (the upstream developers). As a first step I'll be trying to forward most of our patches so that there's a minor divergence. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_array on objects with ArrayAccess or Iterator implementations
On Tue, Dec 29, 2009 at 3:01 AM, Etienne Kneuss col...@php.net wrote:
Hi,
On Tue, Dec 29, 2009 at 1:27 AM, Clint Priest cpri...@warpmail.net wrote:
Etienne Kneuss wrote:
On Tue, Dec 29, 2009 at 12:04 AM, Clint Priest cpri...@warpmail.net
wrote:
Unfortunately $x instanceOf ArrayAccess doesn't return true when $x is
indeed an array.
Making is_array return true for objects implementing ArrayAccess is a
bad idea, for two main reasons:
1) is_array is a type check, and we should still be able to
distinguish real arrays from objects
That's true of course, definitely would need to be able to distinguish.
2) ArrayAccess does not guarantee that an object will behave like an
array, (e.g. you won't be able to use sort() on an object implementing
ArrayAccess.
I wonder if this is something that users would be expecting, that any
function which took an array would also take an object that implements
certain interfaces (such as ArrayAccess and perhaps Countable).
If, in your case, you want to accept both arrays and ArrayAccess
objects, I guess if (is_array($v) || $v instanceof ArrayAccess) is a
sufficiently good way to check.
I'm finding myself implementing ArrayAccess more and more often because its
so transparent to the consumer. The reason this came up is because I was
considering returning all arrays from a certain section of my shared code
library always be an array object so that things like
$tblArray-pluck('Value') could be done, rather than array_pluck() type
functionality.
That got me to thinking about all of the is_array() calls I would need to
replace throughout the codebase.
Would it be terribly difficult to make objects with ArrayAccess completely
interchangable anywhere an array element would be required by a function?
Yes, definitely, it would be a quite big amount of work (basically
rewriting every functions dealing with arrays), and the interface that
ArrayAccess proposes isn't enough for most array tasks.
can we go other way round and allow to use array's in ArrayAccess
context? I'd love to use it as a type-hint.
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
Sent from Prague, Czech Republic
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] invalid params return value
On Thu, Dec 31, 2009 at 7:10 AM, Stanislav Malyshev s...@zend.com wrote: Hi! One of the many things that is chaotic in PHP is what internal function returns when invalid parameters are given (i.e. params parsing fails). Most of those functions do one of: 1a. just return - this happens with most standard ext code, which was converted from old params parsing to a new one. 1b. RETURN_NULL() - this is effectively the same as 1a, but the code is different. 2. RETURN_FALSE - some random set of functions does that, e.g. some of PDO functions (PDO::prepare, PDO::setAttribute, etc.). NB: I'm not singling out PDO here, it happens all over the code, it's just first thing that came to my mind. So, both of the values are kind of OK and both have the same flaw - function could legitimately return both NULL and false. I don't have good argument for either of these as opposed to another one. However, I think we should have ONE standard return value in this case - even better, some macro like RETURN_ARGS_FAIL() (if you have a better name, ok). So, what do you think of that? standard macro is a good idea. I also think, that NULL makes more sense in this case. NULL kinda means nothing was returned, which should be the case exactly (as function didn't start to work, actually) -- Alexey Zakhlestin http://www.milkfarmsoft.com/ Sent from Prague, Czech Republic -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this: Please vote!
On 15.12.2009, at 22:46, Christian Seiler wrote: Ok, so then I call for a vote. Again, here are the options: (0): No $this in closures, keep it that way. (keep PHP 5.3 behavior) I vote for (0) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
