Re: [PHP-DEV] RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_compile.c
Marcus Boerger wrote: That said I can only repeat here what I said earlier on IRC. Lets do things right and make the more complex OO rules as E_STRICT and create new severity level E_DEPRECATED. E_STRICT will then only be used for 'pedantic' OO rules while E_DEPRECATED will be used for stuff that is considered bad practize and that might be removed in later versions. For me later would best be a rule like earliest two minor versions later. If we do so we create a situation wher I hope everyonecan get happy. All users can be informed about upcoming changes using E_DEPRECATED and the OO supporters enable E_STRICT while the dynamic fraction disables it. Last but not least i would like to I would be very happy with this solution. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 todos
Hi, Its been a while since I or anyone else has done any updates on the PHP 6 todo page [1]. I know that some of the todo items are big enough that even with the many commits being made to HEAD they will take a bit before they will be finished. Anyways I just wanted to ask if someone who has followed recent commits, especially on the Zend Engine list which I do not read, could go through the current list of todo items and mark the ones that are done as such. Also if I missed any decisions about todo items to drop/add/reconsider please also update them. Many of you already have an account on the wiki, those that do not, but who feel that they should please let me know. Otherwise people can also just send me things to change and I will take care of things. regards, Lukas [1] http://oss.backendmedia.com/PhP60 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is mktime(0,0,0,0,0,0) E_STRICT?
Derick Rethans wrote: On Sun, 22 Oct 2006, Richard Quadling wrote: With the recent discussion on E_STRICT and the waste of cpu cycles ... Why is mktime(0, 0, 0, 0, 0, 0) generating E_STRICT? What is unstrict about this? Why is important to use time() instead? It's quicker. as I just said on IRC: i think an e_strict in that place is wrong .. for example the parameters could have been user supplied and you simply check that the parameters are integers if e_strict is our way of telling users about back practices, we should really have a consensus on this list about what constitutes a bad practice. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is mktime(0,0,0,0,0,0) E_STRICT?
Pierre wrote:
On 10/23/06, Pierre <[EMAIL PROTECTED]> wrote:
Hello,
On 10/23/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> Use of mktime(0) and alike is improper use of the function, more over
> generally it can be traced to an undesired code behavior.
Which is? mktime(0) is just like mktime(24); if it is not the case,
there is a bug (it is the case). But I suppose you mean mktime(0,0,0,
0,0,0);?
However and for the clarity/sanitiy of this discussion mktime(0,0,0,
0,0,0) does not raise any error, mktime(); does.
To solve the only argument in favour of this error message, Derick
should simply remove the notice and add these three little line before
the arguments parsing:
if (ZEND_NUM_ARGS() == 0) {
RETURN_LONG((long)time(NULL));
}
To be exact:
if (NUM_ARGS()==0 && !gmt) { RETURN_LONG((long)time(NULL)); }
as gmmktime uses php_mktime as well, but in GMT mode.
Yes, I see no point in pushing this responsibility into the userland,
especially since its a BC break appearently.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is mktime(0,0,0,0,0,0) E_STRICT?
Derick Rethans wrote:
On Mon, 23 Oct 2006, Lukas Kahwe Smith wrote:
Pierre wrote:
On 10/23/06, Pierre <[EMAIL PROTECTED]> wrote:
Hello,
On 10/23/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
Use of mktime(0) and alike is improper use of the function, more over
generally it can be traced to an undesired code behavior.
Which is? mktime(0) is just like mktime(24); if it is not the case,
there is a bug (it is the case). But I suppose you mean mktime(0,0,0,
0,0,0);?
However and for the clarity/sanitiy of this discussion mktime(0,0,0,
0,0,0) does not raise any error, mktime(); does.
To solve the only argument in favour of this error message, Derick
should simply remove the notice and add these three little line before
the arguments parsing:
if (ZEND_NUM_ARGS() == 0) {
RETURN_LONG((long)time(NULL));
}
To be exact:
if (NUM_ARGS()==0 && !gmt) { RETURN_LONG((long)time(NULL)); }
as gmmktime uses php_mktime as well, but in GMT mode.
Yes, I see no point in pushing this responsibility into the userland,
especially since its a BC break appearently.
There is no BC break:
I meant, there would be a BC break if this feature gets dropped, which
is the point of the message, right?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is mktime(0,0,0,0,0,0) E_STRICT?
Ilia Alshanetsky wrote: Actually it is no break at all, take PHP4 code move it to PHP and you won't even see the warning because E_STRICT is not even shown by default. haha regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why 5.2 should not be delayed for E_DEPRECATED
Zeev Suraski wrote: Ilia, I think Wez's suggestion is the most practical one. Let's make sure we haven't introduced any fatal errors into 5.2 (and demote them to E_STRICT for now), and handle the rest of the suggestions afterwards. +1 I guess this is the best we can go. It might cause some trouble for people developing in E_STRICT, but I also think that 5.2.0 really needs to be in the hands of users. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] E_DEPRECATED
Wez Furlong wrote: I don't think we need to set any firm ground rules for the deprecation timeline but should consider each change individually. A reasonable rule of thumb is to remove deprecated features no sooner than 1 minor release after the deprecation notice was added. Ideally, it should be in a major release. I think we should have a firm rule, such as: At every major version we grep through the code base for stuff marked as deprecated and if there is not a really really good reason someone comes up with its out. Any rule should be superseded by common sense anyways. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] E_DEPRECATED
Richard Quadling wrote:
+1 - As an aside, it would be extremely useful to have the PEAR
classes marked as NON strict (in some way) until they are. I know this
is outside of the core, but using E_STRICT already means you have to
toggle off E_STRICT for PEAR. MAYBE STRICT (e.g. strict class PEAR
{...}) as a new keyword for a class, just so that you know that it IS
strict (or at least expecting to be).
heh .. no that would not be useful .. it would be lying. PEAR already
has decided on an RFC that will mandate PHP5 only for new packages soon.
Also PEAR mandates E_STRICT compliance for PHP5 only packages. So time
will fix this issue.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP user session handlers
Glenn Richmond wrote: Hi guys, Just wondering what the status of the user-defined session handlers is? I've tested with 5.2rc4 and there is an issue that the references to the user functions get erased when the user calls session_write_close or session_destroy. This means that the system reverts to an alternative handler. Any idea if this issue has been resolved or if not, how it could be resolved? It basically makes large-scale user-defined session handlers impossible (for general website handling). It has been discussed previously, but no solution has been proposed as of yet. I am quite sure we had this behaviour since forever. Did you verify that this is not old? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP user session handlers
Glenn Richmond wrote: i.e. It still knows that it's a custom defined handler, but the references to the functions are gone. If I make a call to session_set_save_handler after the first session_write_close, the problem goes away. Of course, this isn't practical for a large number of sites. And this worked in previous releases? I am very certain that this was the bahviour on PHP4, not sure about 5.x though. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP user session handlers
Glenn Richmond wrote: No, it's never worked as far as I know, but it doesn't mean it's not a bug. The session functions shouldn't have to be reset every time session_write_close or session_destroy is called. It's been logged previously at: http://bugs.php.net/bug.php?id=32330. It's also a consistent issue in varoius forums of major PHP projects. Ah ok, it sounded to me like you were reporting a BC break. I agree this should be fixed if possible, but its not something that will get addressed in 5.2.0 simply due to release management concerns. Hopefully for 5.2.1 someone comes up with a fix. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP user session handlers
Glenn Richmond wrote: look and see if I can come up with a fix in the mean time. Should it be re-logged as a bug to get it some more attention in the future? more bug reports are not going to help .. just append the existing one with a patch. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: go-pear Broken on 5.2 on Windows
Greg Beaver wrote: Adam Maccabee Trachtenberg wrote: I am trying to use go-pear under 5.2 (latest snap) on Windows XP. The script loads correctly, but when it tries to do the install, I get a number of errors. (See below.) Since 5.2 is about to go out the door, I thought I should post an message. Let me know if I can help debug -- I am not a big Windows person, but I can install snaps and let you know what I get. :) Hi Adam, I think that in general a formal bug report is better, but in this case, I happened to catch your message and have just committed a fixed go-pear.phar. Thanks so much for reporting this, the changes to PHP 5.2 that caused this failure seem to have slipped in under the radar. Unfortunately, I can't reproduce the changes with any small file, so I don't fully understand what changed. Something to do with uninitialized deep associative arrays is not working right inside the phar, but works fine outside in my testing. Hmm anyone have an idea on this one? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Datetime class problem
Ron Korving wrote: - First of all, people use their classes a lot more than PHP core classes, and so prefixing application classes is a big burden compared to prefixing PHP core classes. Its quite trivial .. all people need to do is stick a single underscore into their class name [1]. Thats all. They only need to really prefix with anything a bit longer if they want to avoid name clashes with other third party code. - Second, with the active record design pattern becoming more popular, database table-names are starting to dictate class names. Err, where is the problem applying a default prefix in that scenario? And sure if there is a sensible implementation for namespaces I am sure we will get the feature. I have not yet heared any core people say that they are against the feature in general. regards, Lukas [1] http://www.php.net/manual/en/userlandnaming.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces in PHP 6 - ++$take
Patrick Mueller wrote: There would typically be a one time 'hit' in your code for a long, prefixed named used as a constructor, or possibly a static method called on a factory. After that, if you're dealing with object instances, then instead of function names (which would need to also use a longish prefix, because they are scoped globally), you can use plain old short method names. Remember the point Sebastian made earlier. Its also a hassle during development of the library code itself, where you have to deal with endlessly long class names. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespaces in PHP 6 - ++$take
Marcus Boerger wrote:
Hello Richard,
The "#" is needed for CLI mode - thus we won't remove it. In fact we
will not do anything that would cause BC problems. Also there is no
escaping issue with "\". If there is than it is outside of PHP. In
other words:
- "\" is the only single character reachable from 'western' keyboards
- $foo = "{mynamespace\myclass::myconst}"; // will be possible without
escaping
Please people read the archives before posting here, we have discussed
all this long enough.
Jessie, Sean,
would you guys be interested in writing up an overview of the namespace
decisions on my todo wiki?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Ilia Alshanetsky wrote: In theory, you need to consider that many ISPs and users will interpret taint mode == secure and enable it causing much grief to distributable application writers who need to accommodate every environment. actually i dont think this is a valid argument. people will quickly figure out what is going on from the error messages. and isp's will be quick to learn this lesson. as a result it will more likely be disabled everywhere. but its an important tool for all the people that manage their own servers. as a result it will probably not educate the masses (well they can use it on their dev boxes), but more provide yet another tool for those of us who are working on larger projects. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Hi, To me some of Ilia's arguements do not make sense. Ext/filter has the same danger of creating a false sense of security. The arguements that did make sense to me are about the issue of (un)tainting being directly tied to the context in which the variable is being used. This is a problem that many escaping frameworks face. The classic is defining a javascript variable versus html inside a template. Johannes mentioned the database versus logging etc. The only "solution" I was able to think about quickly was to define a best practice so to teach people to do the untainting as close to the variable use as possible. Actually it might even be wise to not even store the untainted version of the variable at all. $query = "select * FROM foo where bar ='".mysqli_real_escape_string($lala)."'" echo magic_escaper($lala); However I guess a lot of people love an ultra layered approach, which does tend to result in black box code, where nobody knows what is actually being escaped or not. So I guess this development style is likely dangerous anyways. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ext/soap ctor errors
Hi,
why do I get warnings when I have failures in my ext/soap ctor?
try {
$client = new SoapClient('http://i_dont_exist.com/some.wsdl',
array('exceptions' => true));
} catch (Exception $e) { }
I guess even without the 'exceptions' => true it should always return
all issues as an exception. I think this was agreed upon for constructor
errors in PHP5, no?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Alain Williams wrote: I propose to give a partially working tool that helps in the majority of cases. I am aware that it will not be a panacea but that it is preferable to nothing. A non context aware taint will fail in the majority of use cases. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Ilia Alshanetsky wrote: Wrong again, different contexts have different validation criteria, unless you consider that tainting in PHP wont work. What's safe to print on screen may not be safe to execute or pass to the database etc... Ilia is right here, this is the key concern with this proposal for me at least. Every PHP app beyond hello world will likely at least work in 2 different context, as such I think a black and white approach is not a useful intermediate step for this. As long as we don't overreach (try to stop every problem) and oversell (promise it will stop every problem) then we should be fine, if 17 years of past experience can be applied to PHP. If you base everything on experience there is no need to use PHP period. Stick to predictable C, Fortran, etc... Just because a person is a great train engineer does not make him a great car mechanic. I am not following you here Ilia. Your comparison does not make sense to me at least. The goal must be to make to create a tool to make it easier to write more secure code. No more, no less. It is something you will run in development in order to pick up a subset of security issues. It will of course fail if there are security measures, which turn out to be insufficient. So no it will not magically make your security filtering regexp more secure, but it will catch the cases where you missed security checking entirely. Again handling different context seems critical to me. So if we have that, then it will also help in finding the slightly more tricky to find issue of where a variable has been filtered/sanitized but for the wrong context. However if we do have context sensitive taint, it seems like it will increase the development/maintenance scope even more. And it will also have a bigger performance overhead. As such I am beginning to realize that at least from my current understanding the Ruby taint model is simply insufficient. While it has different taint levels, they are not concerned with the context, but only with the scope of the limits applied. I do not know how things are in Perl's taint model. Does anyone have context sensitive tainting implemented yet? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Jeff Moore wrote: On Dec 19, 2006, at 10:53 AM, Ilia Alshanetsky wrote: Bottom line is that does not, there are plenty of Perl application supposedly safe from XSS due to tainting while in reality are trivially exploitable via XSS due to the fact validation regex which does the un-tainting of data is sub-par. If you incorrectly untaint data, how is that worse than not knowing that there was a tainted data path in your code in the first place? The perfect is the enemy of the good. I think we can all agree that tainting can never be perfect. The question is it better than what we have now? It does not need to be perfect to be useful. But without it being context aware it will simply fail in too many cases imho to be really useful. However it will add code to php that needs to be maintained, documented, it will potentially have a performance impact. Some people are also concerned about a false sense of security. While I think we are all aware that perfect security is not attainable in a realistic IT environment, I at least partially agree with the sentiment a taint without context will find you some issues, but is likely to overlook so many cases, that the benefit comes quite limited compared to what people would expect. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Stanislav Malyshev wrote: Then I see little need for having in PHP. All it means that developers now need to write a untaint wrapper around all incoming input to shut PHP annoyances up. I can guarantee you a tons and tons of code that No, they need to use recommended ways to work with variables - like filters and other untainters. If a frequent use case is to accept some input, store it in a database and output it in HTML, then you will only get the benefit of taint once, and more importantly you will potentially be less alert to catch the potential security issues for the second. If only return values of functions could be untainted, then you would not need the context, but then it would be unpractical. The other option is to establish the best practice of always using the original untainted value when dealing with a new context. This means you would use the $_REQUEST values in order to build up the query and then when you build up the HTML. But again this may be unpractical, as you may need to massage/sanitize the input slightly. Now its not only having to escape the data for the given context, but you also have to reapply some custom business logic as to how the massaging of the data is to work. I am less concerned about the performance impact, but more about the fact that this then opens up a new class of errors, where data displayed in one context does not match the data stored in another. So by solving the security issue, you jeopardize the functionality. So my conclusion at this point is, that very frequently taint will not improve the security significantly because any given input will still be usable in an unfiltered/incorrectly filtered way for at least one context. As such it just adds code at the very core of php that provides too little of a benefit to be worthwhile. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Hi, I assume its not possible to implement this as a PECL extension. As an extension it would make sense though even in this b&w approach as it would then truly be an optional tool you can use like a debugger without cluttering the core. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Run-time taint support proposal
Stanislav Malyshev wrote: I disagree - you describe scenario where the user chooses to insufficiently or wrongly sanitize the data, and since tainting can not protect from it you say tainting is not useful. However, as I already said, tainting is not supposed to do that. It's like blaming computer OS for not preventing somebody from stealing the laptop with it :) Tainting IS NOT supposed to cure all your security problems. It is supposed to help YOU deal with some of them. No I describe an approach to work around the lack of context aware tainting in which you always work with the initial input in each of the context. However as I describe it means you need to apply any data massaing twice in this case. This is just as error prone as forgetting about escaping user input without taint. As a result you simply trade one error class with another one, while introducing additional complexity. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.1RC2 Released
Hi, while on the train I tried to strat up 5.2.0RC2 on windows and ended up with Apache complaining about the pdo, pdo_mysql, pdo_sqlite and sqlite extensions during the load process. I will try to investigate further tomorrow. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows build
Andi Gutmans wrote: Btw, today I never recommend running mod_php on Windows and always point people to CGI or existing FastCGI implementations. Well a lot of people develop on windows and deploy on Linux with mod_php. For these people it probably makes more sense using mod_php on windows still. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comments on PHP security
Stefan Esser wrote: While it is true that the PHP script is not subject to SQL injection when the application does not build parts of the query based on untrusted userinput it is not true that you are not at risk. Ever heard of stored procedures? And precisely of SQL injection in stored procedures? Prepared statements can do nothing about SQL Injection in Stored Procedures. And if you teach people that they only should use prepared statements they will NEVER know that it is dangerous to put userinput into the query. And aside from that they have never learned how to do it correctly if there is ever a situation where they have to do it. Maybe I am missing something. If you are talking about dynamic query generation in stored routines, then I would think that people who read the advice over dynamic query generation for PHP, that they would hopefully also apply those practices to when they are writing/using stored routines. Also DBA's in general are not all that fond of dynamic query generation in stored routines. Someone also mentioned that LIMIT parameters cannot be prepared: "As of MySQL 5.0.7, placeholders can be used for the arguments of the LIMIT clause when using prepared statements." So at least in MySQL this works. I dont know about PostgreSQL or Firebird. SQLite does not natively support prepared statements anyways. Furthermore there is currently no good way in PHP to really reuse prepared statements across requests in PHP, as such they help you very little in terms of improving performance, unless you reuse the query multiple times in a request. As a matter of fact they may even reduce performance, because they may generate query plans that are inefficient for the given placeholder values. This is because the query plan is either optimized for the most general case or the first set of placeholder values Anyways .. we are moving away from PHP here. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comments on PHP security
Stefan Esser wrote: Hello Lukas, Maybe I am missing something. If you are talking about dynamic query generation in stored routines, then I would think that people who read the advice over dynamic query generation for PHP, that they would hopefully also apply those practices to when they are writing/using stored routines. Also DBA's in general are not all that fond of dynamic query generation in stored routines. Well in a team it is quite likely that people writing PHP applications are not those writing Stored Procedures for the SQL Databases. At least all big projects I have seen have their own team for complicated SQL Queries. Additionally your statement assumes that people are reading documentation ;) Well if the people on your team writing the stored procedures do not know about how to protect against SQL injection how is that a PHP issue? Its a common issue that all types of programmers have to learn. The key lesson here is that again you need to remember that switching context means that you need to take care about the security implications of this and its best if both sides are aware of this and alert eachother of potential issues. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comments on PHP security
Stefan Esser wrote: SELECT xyz FROM abc WHERE product_id IN ( 1,2,3,4,5) <- the list having dynamic lenght They have worked in PEAR::DB and some other DBAL's, as a result a lot of people have come to think of prepared statements as a sprintf() replacement. By the nature of prepared statements they only work with single literals, which a list of values isnt. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comments on PHP security
Wez Furlong wrote: On 1/13/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: SQLite does not natively support prepared statements anyways. Yes it does :) Ah, I got thrown off by the use of the word "precompile" which they also used to describe dumps of the byte code generated by the SQL compiler. The later was useful to be able to ship the SQLite binary with the SQL compiler stripped out to make the binary lean and safe on the compilation process. I guess they now have true prepared statements though he calls them precompiled. Thanks for the correction. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php6 todo list ..
Hi, I just wanted to ask everybody working on PHP6 to take the time to look over the PHP6 todo list [1] and note any items that need to be updated. As always either let me know if you need a login or simply send me what you think needs changed. I am sure that a few items can probably be marked done, others have become obsolete and yet others need to be added. One thing to maybe also look at are the comments at the bottom. People have been abusing them to add feature requests. I can clean them up after someone has ensured that no sensible request is lost. This will make it a lot easier to plan releases once we are ready to do so and so I am sure whoever becomes RM for PHP6 will much appreciate an uptodate todo list. As always, I am very willing to invest time if people point me in the right directions in order to keep the work load as low as possible for core contributors. regards, Lukas PS: Ilia, let me know if you require any effort on the PHP 5.2.x todo list. [1] http://oss.backendmedia.com/PhP60 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactic improvement to array
Marcus Boerger wrote: Hello Andi, it is a bit harder to read and not the php way imo. I agree with Marcus. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
Steph wrote: On 2/4/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote: I personally find array extremely clear, in recent weeks I had to do A LOT of JavaScript work where the array syntax works in a manner you suggest for PHP and its a massive pain. It does not make for a very clear code. I think the syntax you propose is extremely confusing and we should stick to what we have right now. If someone does not like this new syntax, he can stick to array(). It is in no way an argument to refuse the new syntax addition. And what about maintenance? And what about the confusion for beginners? Yes, you will come across it if its added. I find the Javascript syntax confusing to read as well. However more importantly I do not see the point in adding this sugar to save 5 chars. @Andi: I dont quite understand your formatting argument really. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactic improvement to array
Ilia Alshanetsky wrote: On 4-Feb-07, at 1:14 PM, Pierre wrote: On 2/4/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote: I personally find array extremely clear, in recent weeks I had to do A LOT of JavaScript work where the array syntax works in a manner you suggest for PHP and its a massive pain. It does not make for a very clear code. I think the syntax you propose is extremely confusing and we should stick to what we have right now. If someone does not like this new syntax, he can stick to array(). It is in no way an argument to refuse the new syntax addition. If you want to make PHP into Perl that's a fine goal I suppose, however that's not something I want to participate in. For what its worth, I dont really see a good reason for this addition. But its also not something I feel so strongly about that I really think its critical. I am much more concerned about adding fatal errors for OO strictness violations (ups .. i am about to high jack the thread to bring up E_DEPRECATED again). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Syntactic improvement to array
Christian Schneider wrote: My personal summary of this thread is: We won't have syntactic sugar for common things like arrays, named parameter emulation and the like ever because it will be killed by the "we already have a way of doing this" and the "you cannot look it up" argument. Shame, that would be the tiny language development I'd personally benefit from. Named parameters is not just syntax sugar, as they would make it possible to get compiler errors and phpoc support automatically over having to implement some array based solution to trigger errors and some other formatting standard for phpdoc. Then again we had this discussion before as well, and unfortunately it was shot down (IIRC mainly because people to think that named parameters should then be implemented for all existing functions as well, which would be too much work .. then again unicode conversion might (have been) the perfect time to do this). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
Christopher Jones wrote: steve wrote: > Oh, and allow persistent connections in db apis again (like mysqli). It might happen. Wez Furlong was contemplating a persistent connection implementation for the generic PDO interface following on from the persistent connection model in the oci8 extension for Oracle. I guess MySQL folks are also looking into Java like connection pooling: http://krow.livejournal.com/487174.html regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] todo items
Hello, On the heels of the 5.2.1 release I just wanted to bring up the following todo items that have been on the 5.x todo lists since ages. Are these still alive? Have they been done? What would be a sensible target version? Especially the "on-the-fly static properties" is much requested. Open for discussion 1. on-the-fly static properties (mike) 2. 'strict class' to disable dynamic member variable addition (marcus) 3. add a function that returns tsrm_thread_id() - already covererd by zend_thread_id() but only in debug ZTS mode (Wez) 4. userspace streams filter that acts as a default filter through which require/include read their files (Sebastian, Sara) 5. pat3 "OpenLDAP C API cleanup patch" and pat44 "LDAP control support" Todo items for future 5.Y.Z releases 1. Switch for disabling/enabling materialized cursors in mysqli (georg) 2. add support for files >2GB (wez) 3. add array_replace[_recursive] (diff, phpt) (matt) 4. PDO 1. allow the DSN to be passed as array, proposal phase. An initial proposal was done here (pierre, lukas) 5. XMLWriter: 1. Add writeNode([xmlreader obj]), allow to create a push/pull parser regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: todo items
Michael Wallner wrote: 1. on-the-fly static properties (mike) I didn't request these FYI, the names in parenthesis are the person I figured was most likely to implement the given feature and not who requested it necessarily. Anyways, a lot of people "abuse" the comment system on the todo wiki for feature requests, and the above item has been by far the most requested one. Personally I would really like to see it as well. It would open up a lot of possibilities, for example in DOA/ActiveRecord implementations. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] todo items
Ilia Alshanetsky wrote: On 9-Feb-07, at 1:49 AM, Lukas Kahwe Smith wrote: 1. on-the-fly static properties (mike) It was already discussed on the mailing list in the past and declined. Hmm I will search the archives, but I am not aware that this was declined. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] todo items
Ilia Alshanetsky wrote: 5. pat3 "OpenLDAP C API cleanup patch" and pat44 "LDAP control support" The patch is where? http://marc.theaimsgroup.com/?l=php-dev&m=115635520414869&w=2 I should have mentioned that many of the items have links that are listed on the PHP 5.2 todo page: http://oss.backendmedia.com/PhP52 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] todo items
Lukas Kahwe Smith wrote: Ilia Alshanetsky wrote: On 9-Feb-07, at 1:49 AM, Lukas Kahwe Smith wrote: 1. on-the-fly static properties (mike) It was already discussed on the mailing list in the past and declined. Hmm I will search the archives, but I am not aware that this was declined. Err .. sorry .. I got confused. I misread on-the-fly static properties to be late static binding. So forget all about what I said regarding on-the-fly static properties. But do note that late static binding would be greatly appreciated. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / run-tests.php
Jim Wilson wrote: Is there a PHP/Zend bug-tracking system that can be used to record and moderate these requests (like a Bugzilla server somewhere)? Or is there a wiki or forum that that can be devoted to the change-process? (Sorry for these n00b questions - I'm a long time PHP hacker - but I've only recently became interested in PHP/Zend development). you can always file a feature request in a bug report. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / run-tests.php
Antony Dovgal wrote: As far as I understand, the point is that ereg does/can not support Unicode, therefore we cannot keep it PHP6, which major feature is Unicode support. _BUT_ it is possible to use PCRE to "emulate" ereg, so yes, the existing code should continue working. Well I remember that Andrei once brought up the idea of an ereg wrapper around pcre, but IIRC the idea was dropped because there would be tons of subtle issues from edge cases. So the decision was made to simply turn it into a pecl extension to be installed by the user as needed without shiny new unicode support. Not sure if that means that ereg would not be made to work with PHP6 at all ... Overall I would say, while painful I do not really see the point in investing development resources into keeping ereg alive, since its just a duplication of efforts. Then again I have avoided ereg since PHP4 days. The ereg userbase will be the determining factor if ereg makes the jump to PHP6 I guess .. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / run-tests.php
Olivier Hill wrote: On 2/9/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: Overall I would say, while painful I do not really see the point in investing development resources into keeping ereg alive, since its just a duplication of efforts. Then again I have avoided ereg since PHP4 days. The ereg userbase will be the determining factor if ereg makes the jump to PHP6 I guess .. Should it be deprecated then? Adding notes in the manual right now should buy some time to get users to switch to preg. Personnaly, like you Lukas, I haven't use ereg for years in favor of pcre. Good point. So if the decision is indeed to deprecate ereg, its time to mark it deprecated. And while we are at it .. lets introduce E_DEPRECATED as well :) regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] todo items
Derick Rethans wrote: But do note that late static binding would be greatly appreciated. Yes, but that'd be something for 6 i think. I just nocticed its already on the php6 todo list as: re-use the "static::" keyword to do runtime evaluation of statics. http://oss.backendmedia.com/PhP60 For the rest of the points I have updated the PHP5.2 and PHP 5.3 todo lists according to Ilia's comments: http://oss.backendmedia.com/PhP52 http://oss.backendmedia.com/PhP53 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] Improving the documentation
Rasmus Lerdorf wrote: Perhaps we can do more though. Maybe you guys could periodically update internals on problem areas in the docs. Places where you feel things are vague and really could use the guy who wrote the code to get off his ass and explain how it works. Or maybe we could get everyone who reads internals to pick a page or two in the manual on something they are intimately familiar with and go over it in detail and feed suggestions back to phpdoc@ If deemed useful, we can of course devote a section for this in the unofficial phptodo wiki: http://oss.backendmedia.com/PHPTODO/ regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Re: [PHP-DOC] Improving the documentation
Philip Olson wrote: There are 137 open documentation bugs and many of these require PHP internals intervention. I don't know the best way to help that happen aside from maybe going through them all and updating the summaries (and appending categories to those summaries) but then what? A question: What would be a productive way to help get 'er done? Side note: Is it time to completely overhaul php-bugs-web? (I'm not volunteering!) Maybe once you have a clean summary post one bug per day either here or ask in #php.pecl. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] Improving the documentation
Mehdi Achour wrote: Thank you all for your replies, I'm happy to see that the snowball effect started! Just make sure that you take this momentum and directly contact people who's offers you want to take up so that real world effect can be derived from all of the offers. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / run-tests.php
LAUPRETRE François (P) wrote: The other reason why I want a dedicated RFC space is history. Every day, you see messages saying 'I don't remember...', 'what did we decide... ?'. There is no place with decision history. So, the same subject is regularly discussed again and again. @Steph: Could we maybe add some tag to weeklies to document actual decisions more transparently? So we would get a linked list pointing to weeklies for every decision. The weeklies themselves should of course include a link to the conclusion on the mls. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] sequence handling in ext/soap
Hello, This is turning into a major headache for me. The handling of sequences in ext/soap seems somewhat problemematic. I have come across the following bug report which I have reopened: http://bugs.php.net/bug.php?id=36226 Essentially I see 3 cases: 1) sequence is empty 2) sequence has one element 3) sequence has multiple elements I would hope to get an array in all 3 cases. 1) empty array 2) array with one element 3) array with multiple elements. Am I missing something? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC announcements at php.net
Antony Dovgal wrote: On 02/15/2007 06:24 PM, Ilia Alshanetsky wrote: I think it makes sense for RC1 and few of the first level releases but not the very closely spaces RC4+ where there are virtually no changes between the releases. I believe it doesn't matter which RC is that, it helps to detect problems on the early stage anyway. I wouldn't like to miss a bug just because someone missed an RC announcement. Also it will be too untransparent for users what RC's get published and which dont .. Whatever the decision please add it to the release check list on the wiki :) regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fileinfo for 5.2.2
Derick Rethans wrote: On Tue, 20 Feb 2007, Arnold Daniels wrote: I'm also very in favor of this, though I like it much better if it would use the same config file as `file` uses. Otherwise it's quite confusion where to config magic and hard to understand why the result differs. The idea is to embed the database so that you don't have to configure it - that's currently the big problem with the current (deprecated) solution. I have added fileinfo as a to be discussed item on the 5.3 todo list: http://oss.backendmedia.com/PhP53 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] setters in the Exception class?
Hello, I am consuming some Java provide webservices. In some cases we get SOAPFault instances, that I would like to massage a bit, since I do not like the structure or format in the generated SOAPFault (for example it does not set the error code properly). However since there are no setters, I have to create a new Exception instance. So I am wondering if it makes sense to add some setters to the default Exception class to make this sort of thing possible without creating a new Exception instance ..? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [GSoC07] Support for Mutation Testing in PHPUnit
Hannes Magnusson wrote: On 2/25/07, Sebastian Bergmann <[EMAIL PROTECTED]> wrote: Hannes Magnusson wrote: > I am not really a politics fan, but if we are going to list project > not under "the php.net umbrella" (PHPUnit isn't a php.net project > anymore, is it?) don't we then have to list _all_ PHP related project > ideas? I understand and will remove the idea in question if you want. I am not running the show, but I do think if its kept there we should give the same treatment to all other projects. I think we should allow non php.net project ideas as long as they are relevant to PHP. I have actually encourage the php doctrine author to consider proposing an SoC idea. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Fwd: Fwd: Google Summer of Code idea: Doctrine]
Hello, Konsta asked me to forward this email, as he is having issues posting to internals. Anyways I should also add that I would be willing to mentor this proposal. Obviously Doctrine is not part of an official (sub)project of php.net. He did try to get the package into PEAR, though there were some none code related issues that made it not feasible. That being said I still believe that this package is indeed the most powerful DBAL/ORM for PHP available today. The SoC project would help further the scope of what is possible. Few, if any, of the items listed below are available in other DBAL/ORM's for PHP. So this project would expand the scope of what is doable, rather than mainly just adding features already available elsewhere. BTW: The license is LGPL. regards, Lukas PS: As Konsta is not subscribed to internals, please include him in any replies. Original Message Subject: Fwd: Google Summer of Code idea: Doctrine Date: Tue, 6 Mar 2007 14:03:54 +0200 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] - Edelleenvälitetty viesti lähettäjältä [EMAIL PROTECTED] - Päiväys: Tue, 6 Mar 2007 10:36:16 +0200 Lähettäjä: [EMAIL PROTECTED] Vastausosoite: [EMAIL PROTECTED] Otsikko: Google Summer of Code idea: Doctrine Vastaanottaja: [EMAIL PROTECTED] PHP.NET Google Summer of Code idea: DOCTRINE (PHP Object Relational Mapping solution) Doctrine is a PHP Object Relational Mapping and database abstraction framework. The DBAL part of Doctrine derives from MDB2. The key idea was to provide very intuitive and easy-to-use persistency solution (RoR ActiveRecord) with all the advanced features from the more heavy-weight solutions (eg. Hibernate). Currently Doctrine already is propably the most advanced PHP DBAL / ORM availible (http://www.phpdoctrine.net/doctrine/manual/features.php). However there is still a lot of work I'm planning to do: DBAL planned features: - EXPLAIN abstraction - Foreign key schema reading abstraction - More adapters: Sqlrelay, Mysqli, Oracle etc. ORM planned features: - SET datatype emulation - Migration tools (using Doctrine_Export::alterTable()) - Extend DQL syntax to support portable triggers - Doctrine_Query_Builder for building safe DQL queries from user-defined parameters - Add support for cross-database queries - Doctrine_AuditLog (implemented with portable triggers) - Support for CHECK constraints (automatically and optionally generated from validator definitions) - DQL: Support for portable SIMILAR TO operator - Better support for hierarchical data handling In general, the codebase should be stabilized and all the undocumented features should be documented. Project Schedule: I've worked for this project for more than a year now, hence I would simply continue working as I were. Currently I have only couple of hours max to spend on Doctrine each day (sports and studying take a lot of time). However if Doctrine gets itself into SoC I would be working on it 6-8 hours a day almost the whole summer. Bio: My name is Konsta Vesterinen. I'm studying at the University of Technologies, Espoo Finland. I've been the lead developer of Doctrine from the day of its beginning. I'm truly enthusiastic towards anything Database, PHP and ORM related. Also I've got huge respect for Lukas Smith (the author of MDB2), who suggested to act as my mentor. I think I could learn a lot from Lukas, who has an immense knowledge in the field of database abstraction. - Välitetty viesti päättyy - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [GSoC07] Support for Mutation Testing in PHPUnit
Nuno Lopes wrote: I think that's a good idea. I would say you should go ahead and add the idea to our SoC page (http://php.net/ideas.php). BTW, we should start gathering ideas because the summer is not far away. Indeed. Actually Students have to submit their proposals by March 24. So now is the time to compile the ideas page. I assume we are already registered as a mentoring organization with Google for this year? Here is the full timeline taken from the FAQ: What is the program timeline? March 5: Mentoring organizations can begin submitting applications to Google March 12: Mentoring organization application deadline March 13: Google program administrators review organization applications March 14: List of accepted mentoring organizations published on code.google.com; student application period opens March 24: Student application deadline Interim Period: Mentoring organizations review and rank student proposals; where necessary, mentoring organizations may request further proposal detail from the student applicant April 9: List of accepted student applications published on code.google.com Interim Period: Students learn more about their project communities May 28: Students begin coding for their GSoC projects; Google begins issuing initial student payments Interim Period: Mentors give students a helping hand and guidance on their projects July 9: Students upload code to code.google.com/hosting; mentors begin mid-term evaluations July 16: Mid-term evaluation deadline; Google begins issuing mid-term student payments August 20: Students upload code to code.google.com/hosting; mentors begin final evaluations; students begin final program evaluations August 31: Final evaluation deadline; Google begins issuing student and mentoring organization payments regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Fwd: Google Summer of Code idea: Doctrine]
Marcus Boerger wrote: Hello Lukas, for now simply add the project here: http://de.php.net/ideas.php Once the selection process startswe will discuss it in detail. I do not have karma for this. I guess for "ideas" that already have a student and mentor, we do not really need them on the ideas page anyways? Lets discuss in March then, once the proposal has been filed with SoC. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC
Derick Rethans wrote: On Thu, 15 Mar 2007, Antony Dovgal wrote: Hannes also has some ideas on improving our bug tracker as a GSoC project. And I am thinking about this: http://derickrethans.nl/wanted_dbgp_xdebug_client.php Do you guys think that would qualify as php project as well? Hell yeah! regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC
Marcus Boerger wrote: Hello Ilia, of course we can. The question is how do we find a student for ideas we have? one we have a fairly complete overview of ideas .. we can have a few of us blog the world :) regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] google SoC - dbobj
Bankó Ádám wrote: I'm an interested student with a project idea for the PHP.net Google Summer of Code. I'm thinking about a native ( compiled from C ) ORM extension for PHP. I don't need to explain how useful and important it is in modern web applications / frameworks. IMHO a full ORM belongs into user space and not into C code. I kind of like the approach that ADODB did, which was taking an existing DBAL and moving selected items that where bottlenecks into C space. Thereby providing a drop in speed improvement, while keeping the C code to a minimum. As such I would prefer that this would be done in collaboration with an existing or in development PHP ORM. I recently opened a mailing list on exactly the top of database abstraction in PHP that already has well over 30 subscribers and pretty much all of the key ORM developers in the PHP space: http://pooteeweet.org/blog/611 Might be a good idea to bring up your thoughts there as well and see if there is a chance for collaboration with an existing userland ORM project. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] google SoC - dbobj
Bankó Ádám wrote: Pure C code has access to PHP5's low level object API, so it can produce a really intuitive interface (object persistence), that you can't do from PHP code. C code uses a bit less memory and a lot less CPU time I would hope that the solution for "low level object API" would be that we expose more and more of that to user space. Stuff like being able to force the calling of the parent constructor come to mind, I am sure there are other things more relevant to the topic at hand as well. But yes, its a valid point. The other issue is performance. For the ORM field I didn't find operation that could be moved out to native code efficiently. Most complex operations need a lot of data, and passing this data to a native function, doing decoding and after it's processed the time needed for recoding would eliminate the performance benefit. For example ADODB could implement the resultset_to_array method in C, because there's minimal overhead on fetching a row from a database resource (negative compared to it's PHP equivalent). Yeah, you are right .. it might be hard to find things that can be moved to C space and vice versa. I do not know where to draw the line this very second either. I just want to make sure that this option is explored. I remember that Thies once said, the ultimate goal of the PHP language would be to make everything fast enough in PHP so that everything can be done in user space. All the extension should do is expose third party libs. Of course this might only be a dream, but I think its one of those dreams worth purseing .. even if you never make it. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] google SoC - dbobj
Hi, just to clarify .. from your comments I am quite hopeful in your proposal. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] google SoC - dbobj
Tony Bibbs wrote: I agree. I'm a user of Propel (http://propel.phpdb.org) which is in the user space as you suggest and I think it works fine. The current beta version of Propel uses PDO so execution speed isn't really a huge FYI: You are mistaken if you think that moving from the old extensions to PDO provides a speed improvement (there is rather decrease unless you are using fetchAll()). problem. I think the only thing worth considering adding to the C-code is something to compliment PDO that can collect all the database metadata that ORM's require. Propel currently does this using Creole And this imho is the thing that should definitely stay in userland. Its a giant hackery to get it to work. This is something people need to be able to adapt quickly. Putting this in C would be a maintenance nightmare. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] google SoC - dbobj
Tony Bibbs wrote: Sorry, I wasn't clear on this. Creole is the DB abstraction layer on top of the "old extensions". The older versions of Propel were implemented that way. The new beta version uses PDO dicrectly (i.e. minus Creole) and that showed significant speed improvements over prior versions. Ah, that must be a Creole issue then .. because there is no technical reason for this. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: anonymous functions in PHP
Stanislav Malyshev wrote: Thoughts? This might work, still not sure if we really want that in PHP. On one side, it's cool, on other side closures can develop into a very messy code :) Yeah well .. for the single task of callbacks they are great and prevent a lot of messiness .. I think its messy to pollute the namespace for something which is not intended for reuse .. maybe we need to artificially limit its uses just like for "goto". regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] google SoC - dbobj
Guilherme Blanco wrote: As I mentioned before, the best ORM tool I've notice is Doctrine, but it has some issues that I can list if necessary. The point is not to BTW: the lead author of Doctrine aready submitted an SoC project idea for php.net on googles website. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] google SoC - dbobj
Robin Ericsson wrote: On 3/21/07, Bankó Ádám <[EMAIL PROTECTED]> wrote: The project is existing, I'm doing it for about a year and a half, and SoC is way I can spend more time on it in the summer. If there is someone willing to something, and someone else is paying for it, let him do it. Why should it bother whether it's C or PHP? The community will benefit from it either way. Its a question of maintainability. Stuff like reverse engineering schema's from a database is simply not sensible to be done by C code. It requires a low barrier to entry, the ability to quickly fix things if you encounter a newer or very old obscure RDBMS version etc. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] google SoC - dbobj
Andrey Hristov wrote: Hi, Lukas Kahwe Smith wrote: Robin Ericsson wrote: On 3/21/07, Bankó Ádám <[EMAIL PROTECTED]> wrote: The project is existing, I'm doing it for about a year and a half, and SoC is way I can spend more time on it in the summer. If there is someone willing to something, and someone else is paying for it, let him do it. Why should it bother whether it's C or PHP? The community will benefit from it either way. Its a question of maintainability. Stuff like reverse engineering schema's from a database is simply not sensible to be done by C code. It requires a low barrier to entry, the ability to quickly fix things if you encounter a newer or very old obscure RDBMS version etc. Then make a mix of PHP and C code. C call call PHP userland, so it shouldn't be a problem. And as I see it, it is always good to have reference implementation in PHP and port it to C. I think Marcus did it while implementing SPL. Yes .. so for the proposal .. step 1) would be defining interfaces and abstract classes to represent things. this could go into C regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC, Mutation Testing, Ineligible
Mark Wiesemann wrote: The most important sentence of this paragraph is: | Use the "Ineligible" link only for applications that are spam. Sorry about that. You have to realize that the SoC Mentor interface is utter crap. So we are trying to make the best of the available features in order to come to the optimal list of applications. Do not take this personally. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC, Mutation Testing, Ineligible
Mark Wiesemann wrote: This was just a friendly note for Sebastian and other mentors, e.g. to avoid that maybe Google itself ranks people like Thomas Koch next year down because their 2007 application was marked as "spam" (<= in Google's interpretation). Good point. We will provide feedback to Google on this issue. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is this a bug in SoapServer?
Ron Korving wrote:
Hi,
returning array('5' => 'Foo', '10' => 'Bar') from a SoapServer handler class
ends up as array(0 => 'Foo', 1 => 'Bar') at the client end. I can hardly
imagine this being a feature, but maybe someone can tell me if this is
somehow wanted or inevitable behavior.
I assume its because there is no such thing as an associative array, so
the thing ends up being a simple ordered sequence.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC, Mutation Testing, Ineligible
Lukas Kahwe Smith wrote: Mark Wiesemann wrote: This was just a friendly note for Sebastian and other mentors, e.g. to avoid that maybe Google itself ranks people like Thomas Koch next year down because their 2007 application was marked as "spam" (<= in Google's interpretation). Good point. We will provide feedback to Google on this issue. FYI: I noticed that Google finally implemented a feature to undo marking things ineligible and so I went in and "fixed" everything. Now only real spam and absolutely bogus requests are marked ineligible. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP6 todo list
Hi, Going over the todo list I wanted to bring up a few topics once again for review/discussion (not flaming): http://oss.backendmedia.com/PhP60 # Unicode 3. remove old parameter parsing API and replace with one that supports unicode related functionality I just want to remind that when we made some changes to the parameter parsing API's last time it created some BC issues (like with array_merge() ..) 5. add unicode to pdo (wez) Maybe one place where IBM could step up, seeing that they are putting a lot of resources into their PDO drivers. # cleanups 4. safe_mode/open_basedir 1. remove safe mode and throw E_CORE_ERROR when set 2. unbundle safe_mode_exec_dir from safe_mode and keep it (rasmus) (take a look at this patch too) 3. new ini option: open_basedir_for_include which would allow using include/require(_once) on an expanded set of directories (sara) Whats the state here. I remember that there was still a fair bit of back and forth on this point. 9. remove zend.ze1_compatibility mode and throw E_CORE_ERROR when set DONE (dmitry) Same here. Gone for good? # PECL 3. regexp 1. make ereg an extension 2. PCRE extension will not be allowed to be disabled. 3. core of PHP should be made to work with PCRE so that we can safely disable ereg 4. unbundle the regex library We had a short discussion on this one not too long ago. 5. move mime_magic from the core to PECL 6. fileinfo 1. move the Fileinfo extension to the core, and enable it by default. 2. Fileinfo extension should be updated to only load its database once on MINIT. Didn't we fast track these two to 5.x? 7. ext/soap 1. ext/soap will be turned on by default 2. implement some of the security extensions to ext/soap 3. watch axis2 based implementation development I am guessing the security stuff could take a bit to implement. Does anyone feel "responsible" for this item? Engine additions 2. add a new 64bit integer that is always 64bits regardless of platform with the cast name for this new type is (int64) and internally we use IS_INT64 and RETURN_INT64 etc.. Are we still on track with this one? 4. add an ifsetor() construct with the middle value for the ?: ternary operator dropped Kinda scared to mention this one. Me want very much though :) 6. speed up @-operator and ask andi for approval (ilia, marcus) 7. add ability to allocate persistent zvals in PHP. 8. add ZEND_ACC_READONLY (marcus) Just bringing those 3 up as a reminder. It sounds like 6. is done and just needs a nod? 7. needs someone breaking some brain cycles over and 8. is probably trivial to do ..? # OO changes 3. object casting to primitive types BC mess (derick) Derick could you elaborate on this one? 5. fix __toString() DONE (marcus) Didn't we fix this one in 5.x already? 6. add internal flag only to force calling of the parent constructor I guess we have something like this in PDO already. Personally I think we should have rather promoted the "factories" pattern for extensions as well. But if we have it for internals stuff, why not also for userland? 7. re-use the "static::" keyword to do runtime evaluation of statics. This is one of the most wanted features going from user feedback. 8. add namespace support (marcus, jessie) This topic still alive? 9. add support for type-hinted return values. Seems like quite a big feature in terms of changing PHP, but could be quite a nice feature for stuff like soap wsdl generation (though here we can always fallback on phpdoc parsing). # Other Additions/Changes 2. APC 1. include APC in the core distributions (turned off by default) and switch to mmap as default shared memory storage. 2. ability to move autoloaded main classes in apc's class lookup preventing the overhead of doing the inheritance process all the time. (marcus) Are we still on track with this one? I remember that Zeev said he was generally ok with this one, but wanted to ponder it some more. 3. include the patch' real-path fix from hardended php Wasn't this done already in 5.x? 4. include the protection against HTTP Response Splitting attacks (header() shouldn't accept multiple headers in one call) from hardended php Wasn't this done already in 5.x? 5. split allow_url_fopen into two distinct settings: allow_url_fopen and allow_url_include. If allow_url_fopen is off, then allow_url_include will be off too. 6. enable allow_url_fopen by default 7. disable allow_url_include by default Is this still going to happen? 8. add sand boxing if we have a rock solid implementation (sara) Sara, just making sure you are allocating brain cycles for this on a daily basis ;) 9. go over the engine and extensions and make sure only E_ERROR is used where the engine is in an unrecoverable state. Hmm, this so
Re: [PHP-DEV] Re: [fw-general] Re: [PHP-DEV] ZF 0.8.0 Unit Tests behaving different on PHP 5.2.1 and PHP 5.2.2-dev
Dmitry Stogov wrote: It is bad practice to use echo $float or var_dump($float) because they depends on php.ini settings. You should use printf() of number_format() for deterministic result. The float formatting algorithms were changed because of licensing issues and new ones are not 100% compatible with previous ones. Was this documented in the upgrading guide? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 todo list
Hi, FYI I have updated the todo list according to the recent discussions: http://oss.backendmedia.com/index.php?area=PHPTODO&page=PhP60&view=diff&to=2007-04-17+10%3A47%3A32&from=2007-04-12+16%3A32%3A02 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
On 15.02.2009, at 17:18, Marcus Boerger wrote: Hello Stanislav, Friday, February 13, 2009, 7:03:30 AM, you wrote: Hi! it should actually be a hard error. As we always claim PHP follows pure IS-A relation ships. I feel very uneasy with hard errors on something that is not indeed an error preventing engine from continuing. I.e. my (personal) opinion is that if the engine can move forward, even with some assumption, it should. IMHO it's like having undefined variables, etc. It makes PHP less strict, but I'd say it's not necessarily a bad thing. Hard as in E_RECOVERABLE_ERROR of course, since you are right that the engine indeed can continue. Thats almost as useless. If you make it E_RECOVERABLE_ERROR .. it essentially prevents people from modifying the method signatures in a non academic OO manner, which I think is not the point of PHP. E_STRICT reminds people that they are doing the wrong thing in academic terms, which however might very well make sense in business terms non the less. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.3 items
Hello All, I am back from my vacation in Tanzania. I will be in Innsbruck over the weekend for some Frisbee action, but I hope to get back into the RM business Sunday evening or Monday. I went through all my emails yesterday and marked several for reading, which I will do on the train ride if all goes well. That being said, it would also be useful if anyone who is looking after issues that are still open and that should be addressed before the next release (beta2 or RC1) can send Johannes and myself a quick email. If anything needs discussion raise it on internals ASAP. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
On 22.02.2009, at 01:10, shire wrote: I've just checked into APC CVS preliminary support for Lazy Loading classes and functions. This means that rather than copying function entries into EG(function_table) and EG(class_table) when an include happen it will mark the functions/classes as available and only actually insert them into the tables when they are called. This is done via hooks added into the various hash table lookups in PHP. I've placed a patch for PHP_5_3 at: http://tekrat.com/downloads/bits/apc_lazy_php53.patch I did not read through the entire thread. As things are close to RC state in 5.3, I would prefer to not do any non bug fixes at this stage. Then again if the benefits are huge and the risk is low it can be considered of course .. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
On 11.03.2009, at 17:10, Rasmus Lerdorf wrote: Anyway, it's very good job and 20-30% speedup on some real-life applications makes sense to include it into 5.3 (from my point of view). Makes sense to me as well, especially since I don't see any drawbacks for non-accelerated scripts. I also think some of those applications that didn't show any gains could be trivially modified to make use of it. Moving from conditionally loaded stuff to lazy-loaded is likely to speed things up. Depending of course on how granular the conditional loading is. Can we get this patch to release quality by this weekend? So that people can test it on Monday/Tuesday ahead of RC1? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
On 11.03.2009, at 19:55, Marcus Boerger wrote: Last but not least, Lukas, what happened, to putting APC into core? That was planned for PHP 6.0. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
On 11.03.2009, at 20:58, shire wrote: Lukas Kahwe Smith wrote: Can we get this patch to release quality by this weekend? So that people can test it on Monday/Tuesday ahead of RC1? I don't see this being a problem, I do have a few items I'd like to point out for feedback/suggestions: 1) Currently it doesn't support method level lazy loading, it's probably advisable to wait and include this later, but if everyone thinks it's significant enough we could probably add support for that. I'm not sure on all the details this involves, perhaps someone familiar with method calls could suggest difficulty and/or optimized ways to do the lookups. 2) Currently I've inserted these hook calls into everywhere we call/ lookup classes. This has the downside that any extension wanting to mess with the function table, lookup entries, etc will need to be aware of the callback hooks. I think a better architecture is to create an API for function table and class table operations. Perhaps this could be done later if we want this likely more stable version in 5.3, and perhaps I'm overstating the significance of other functions doing these sort of things and not being aware of this new feature. (I believe dmitry mentions several extenions that need changes to support this). On the upside not creating an API means existing code will still work if they don't use lazy loading. ;-) 3) The largest portion of time currently is simply adding dummy entries to the lazy hash tables so we can detect name collisions and availability, my next goal is to improve the performance of this by either creating a faster copy of the entries or determine some better method of performing lookups/marking functions as available (something like lookups directly into the APC shared memory segment). Just putting this out there in case anyone has some interesting suggestions. I think all the above 3 items don't necessarily need to be done to have this work in 5.3 (and #3 is pretty much APC/opcode cache centric) and might cause unecessary complication for an initial support of this, but what does everyone else think? Hmm, thanks for your open assessment here. What you are saying does make me wonder if we really should push this into 5.3. Even if any changes we need to do can eventually be handled by APC, I do think that there will be other extension authors that would also suffer from us messing around with these internals all too much in every release. So maybe we should wait until the next bigger step before introducing this. Other people can apply the patch themselves if they really need the performance in the mean time .. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserved namespaces
On 13.03.2009, at 00:39, Andrei Zmievski wrote: Christian Schneider wrote: Things gettings reserved at a later stage (like originally keywords, now namespaces) can lead to a big deal of frustration. Therefore I think it is crucial to have a clear naming guide now. And these guidelines have to be noticed by everybody who starts to use namespaces so they have to be placed prominently. Personally I'd even prefer them to be enforced in code so they can't be missed. Removing restrictions later on causes less trouble so I wouldn't mind too much if a couple of namespaces (or namespace prefixes) are reserved but never used. Just a gentle reminder to make sure we don't miss this.. Well cant we just use the class naming guide? As in put a prefix in your namespace names, do not use an extension name (or something that could likely become an extension name) as your prefix. Then again for classes we say that the prefix should be prepended with an underscore as the separator as the ultimate protection. That of course does not seem feasible for namespaces. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3 RC
On 10.03.2009, at 17:04, Johannes Schlüter wrote: Hi, I wrote a mail last Friday about this but it seems like it got lost. I wanted to go RC on Thursday, as this now would be a rather short-time announcement (while quite a few devs already knew) this plan has changed by a week: PHP 5.3.0 RC 1 is now scheduled for Thursday 2009/03/19. This means we'll enter the pre-build commit-freeze for build fixes only on Wednesday 2009/03/18. Just a reminder. This means today is the day to get your fixes in. Is anyone looking over Matt's patches? Also on the wiki are several open todo items: http://wiki.php.net/todo/php53#rc1 Please let me know if any items on there are already done. Also let Johannes and myself know of any show stoppers that will not get completed today. Remember this is an RC, so we should be quite serious about the quality we are releasing. This is the time for bug fixes and _not_ for features. I know there is a certain tendency to put features first, since important open bug fixes delay a release, while feature additions at this point will not. I ask everybody to pay "fair" and focus on getting PHP 5.3 out the door, rather than rushing features in now, that take away the focus from bug fixing and worse yet could add new bugs. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3 RC
On 17.03.2009, at 10:59, Lukas Kahwe Smith wrote: On 10.03.2009, at 17:04, Johannes Schlüter wrote: Hi, I wrote a mail last Friday about this but it seems like it got lost. I wanted to go RC on Thursday, as this now would be a rather short-time announcement (while quite a few devs already knew) this plan has changed by a week: PHP 5.3.0 RC 1 is now scheduled for Thursday 2009/03/19. This means we'll enter the pre-build commit-freeze for build fixes only on Wednesday 2009/03/18. Just a reminder. This means today is the day to get your fixes in. Is anyone looking over Matt's patches? Also on the wiki are several open todo items: http://wiki.php.net/todo/php53#rc1 Please let me know if any items on there are already done. Also let Johannes and myself know of any show stoppers that will not get completed today. Remember this is an RC, so we should be quite serious about the quality we are releasing. This is the time for bug fixes and _not_ for features. I know there is a certain tendency to put features first, since important open bug fixes delay a release, while feature additions at this point will not. I ask everybody to pay "fair" and focus on getting PHP 5.3 out the door, rather than rushing features in now, that take away the focus from bug fixing and worse yet could add new bugs. Ok, since there is too much last minute stuff going on and we are aiming for a release quality RC1, we have decided to move the release date to next Tuesday, the 24th. Bug fixing until this Friday. Any other bug fixing over the weekend needs the nod of one of the RMs. Build fixing Monday. Release Tuesday. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Towards 5.3 RC
On 18.03.2009, at 11:06, Lukas Kahwe Smith wrote: On 17.03.2009, at 10:59, Lukas Kahwe Smith wrote: On 10.03.2009, at 17:04, Johannes Schlüter wrote: Hi, I wrote a mail last Friday about this but it seems like it got lost. I wanted to go RC on Thursday, as this now would be a rather short- time announcement (while quite a few devs already knew) this plan has changed by a week: PHP 5.3.0 RC 1 is now scheduled for Thursday 2009/03/19. This means we'll enter the pre-build commit-freeze for build fixes only on Wednesday 2009/03/18. Just a reminder. This means today is the day to get your fixes in. Is anyone looking over Matt's patches? Also on the wiki are several open todo items: http://wiki.php.net/todo/php53#rc1 Please let me know if any items on there are already done. Also let Johannes and myself know of any show stoppers that will not get completed today. Remember this is an RC, so we should be quite serious about the quality we are releasing. This is the time for bug fixes and _not_ for features. I know there is a certain tendency to put features first, since important open bug fixes delay a release, while feature additions at this point will not. I ask everybody to pay "fair" and focus on getting PHP 5.3 out the door, rather than rushing features in now, that take away the focus from bug fixing and worse yet could add new bugs. Ok, since there is too much last minute stuff going on and we are aiming for a release quality RC1, we have decided to move the release date to next Tuesday, the 24th. Bug fixing until this Friday. Any other bug fixing over the weekend needs the nod of one of the RMs. Build fixing Monday. Release Tuesday. At the request of Pierre, I am tightening the commit window. Please finish all bug fix commits by Thursday. If there are any last minute discoveries, you can ask Johannes and myself to be allowed to commit on Friday. The later in the day the request comes, the less likely we are to approve the commit. Anything after that (including commits to the test suite) will need to be reverted unless its a build fix. Please do not waste time doing reverts. Release candidates need proper QAing ahead of time. In the future we will try to stick with Thursday releases with a commit freeze starting the Tuesday before, to give two full week days of build fixing. As such it would be appreciated if people can spend some time on the weekend to do as much build fixing as possible to ensure that we can get done on Monday in order to release on Tuesday. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] cvs commit freeze for the 5.3 branch
Hello, We are not in a commit freeze on the 5_3 branch. For today for any commit not just affecting README's (as in anything affecting buolding or build testing), please get a nod from Johannes or myself. On the weekend and Monday only build related fixes are allowed in the 5_3 branch. Please keep track of any HEAD commits that need merging or let me know about them so I can keep track of them (dunno if it makes sense to just write a note in the HEAD commit that this changes needs merging into 5_3). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] cvs commit freeze for the 5.3 branch
On 20.03.2009, at 12:37, Ferenc Kovacs wrote: On Fri, Mar 20, 2009 at 12:01 PM, Lukas Kahwe Smith >wrote: Hello, We are not in a commit freeze on the 5_3 branch. For today for any commit not just affecting README's (as in anything affecting buolding or build testing), please get a nod from Johannes or myself. On the weekend and Monday only build related fixes are allowed in the 5_3 branch. Please keep track of any HEAD commits that need merging or let me know about them so I can keep track of them (dunno if it makes sense to just write a note in the HEAD commit that this changes needs merging into 5_3). regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php you mean "We are noW in a commit freeze on the 5_3 branch." Right .. we are NOW in a commit freeze period. We will let everybody know on Monday or Tuesday when commits are allowed again. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] array kindex overflow issue Re: [PHP-DEV] Re: [PATCH] Bug #45877: LONG_MAX/MIN array key as string/int
On 19.03.2009, at 20:37, Rasmus Lerdorf wrote: So, what is the final conclusion on this one? Are we at a combination of Matt's and Dmitry's patches here? I think we definitely need to fix this even in the 5.2 branch and get it back to 5.1.x and earlier behavior. I consider it a bug that: $arr[35] = 'blah'; print_r($arr); results in: [-2147483648] => blah if someone has written brand new 5.2-specific code that relies on this weird behavior, then we will just have to bite the bullet and break that code. It is way more likely that people are relying on the earlier behavior and will end up with subtle problems in 5.2. I just had someone at Yahoo get bitten by this when they upgraded from 5.1.x to 5.2.x. If I understood it properly, the issue Matt/Dmitry are working on is something else. So where do we stand on the issue Rasmus's notes (is there a ticket for this one already)? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RC1 tagged
Aloha, This is just a heads up to all developers who waited during the commit freeze, RC1 has been tagged. So bug fixing may continue :) There were a couple commits during this freeze. I realize that people tend to work on stuff and commit without necessarily looking at the mailinglist before hand. So for the during of the 5.3.0 release process we will try to go with the following procedures: 1) We will always aim for a release on Thursday, which means Tuesday and Wednesday before the given date while have a commit freeze on all build related files for anything but build fix commits 2) In case we are slipping we might do another Tuesday release, which again will mean Friday commits only with the RM's specific permission [1], weekend and Monday commit freeze on all build related files for anything but build fix commits. Until 5.3.0 is out, please do make it a habit to try and stay in the loop about eminent releases and their commit freezes. I will keep posting any dates to internals as soon as a date is set. I will also update the wiki page [2] asap. Finally I will post to internals and php-cvs 1-2 days before a commit freeze as a reminder. The next RC will likely hit in about 2-3 weeks. Then again, hopefully there will be less and less changes before the next RC's. And yes there will obviously be more RC's after this one, since we still have some issues to fix. This however does not mean that for the most part people can now rely on things being fixed, which is why this is an RC and not a beta2 after all [3]. regards, Lukas Kahwe Smith m...@pooteeweet.org [1] This Friday thing is an attempt to keep the commit freeze periods as small as possible, while still ensuring that those testing less used platforms and SAPI's (and as a result do not have other shoulders to rely on), have more or less 2 days to do their build testing [2] http://wiki.php.net/todo/php53 [3] This is just a disclaimer for the end users on this list wondering if its worth it to actually test this RC1 .. yes it is! :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] pdo bug fixing
Hey Matteo, Based on the feedback I got there is no reason why your PDO patches have to be applied by anyone but yourself. So if you are still interested go ahead and submit a cvs account request. Thx for looking after PDO bugs .. we dearly need your help! regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati
On 16.03.2009, at 16:49, Pierre Joye wrote:
2009/3/16 Johannes Schlüter :
Hi,
On Mon, 2009-03-16 at 09:52 +, "Dmitry Stogov" wrote:
Log:
Fixed bug #47664 (get_class returns NULL instead of FALSE)
[...]
@@ -716,7 +716,7 @@
int dup;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|o",
&obj) == FAILURE) {
- return;
+ RETURN_FALSE;
}
Usually we return NULL in case parameter parsing fails, this is
documented like this:
Hi Johannes,
Please read the bug report. In this case I think that we should not
break it only to follow this (arguable :) rule. See the documentation
of get_class as well: http://de.php.net/get_class
I did not follow this closely. So where do we stand here? Should we do
a quick vote? Or is this decided already? In this case did it get
documented (in case we decided to change the behavior).
If someone can summarize the current state of things I would
appreciate it.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.0RC1
Hello! Johannes has packaged PHP 5.3.0RC1, which you can find here: http://downloads.php.net/johannes/ Windows binaries are available here: http://windows.php.net/qa/ This release candidate makes us feature complete and we hope to only require minimal changes ahead of the next release. Many, but not all, of the new features are already integrated in the official documentation on php.net. Please not that we are aware of minor issues with integer handling that we still want to fix (though most of them have also affected PHP 5.2) and a crash bug in NSAPI. Expect an RC2 in 2-3 weeks time, though for most users there will not be a noticeable change meaning that now is the time to start doing the final testing of PHP 5.3.0 before it gets released with any unnecessary incompatibilities with your project. Some additional links to get started: http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=markup&pathrev=PHP_5_3 http://wiki.php.net/doc/scratchpad/upgrade/53 Best Regards, Johannes and Lukas PHP 5.3 Release Managers
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) / UPGRADING
On 25.03.2009, at 15:09, Pierre Joye wrote:
On Wed, Mar 25, 2009 at 3:07 PM, Steph wrote:
Hannes Magnusson wrote:
And now to the list too *sigh*, sorry Steph :)
I did wonder :)
On Wed, Mar 25, 2009 at 13:49, Steph wrote:
Hannes Magnusson wrote:
2009/1/28 Steph Fox :
sfoxWed Jan 28 17:23:28 2009 UTC
Modified files: (Branch: PHP_5_3)
/php-srcUPGRADING
Log:
- Skeleton version taken directly from the scratchpad and
tidied.
@Lukas, Johannes: This is nowhere near complete, and may contain
entries
that would be happier in NEWS, but it's OK for the beta IMHO.
So.. is someone working on completing this?
-Hannes
Yes. And the RMs are kept up to date :)
Could phpdoc@ be kept in the loop too?
I'd like to know when I can start converting it to DocBook...
You aren't going to be converting it to DocBook, see previous
discussion.
The version of the file that ends up in the manual is far too long
and
complex to be useful as part of php-src.
Sorry, but the last discussion had different conclusions.
Well the last thread on the topic ("5.3 todos") stopped with Steph
explaining that there are 2 different documents, one the UPGRADING
guide in php-src and one being the manual and that she intends to
focus the UPGRADING guide to be short and to the point for sysadmins
wanting to get some idea on if the update will affect their users and
the manual being the place to check for end users.
There wasn't any disagreement after that ..
I do not know if this is the perfect plan, but it doesn't sound like
its totally crazy either and since she is doing the work I guess its
her call. This does however mean that someone needs to write the
detailed content for the manual (something that Steph afaik also
raised her hand).
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory Leak in ob_get_clean() / ob_get_flush ()
Hi,
Did this get addressed yet?
regards,
Lukas
On 18.03.2009, at 03:15, Christian Seiler wrote:
Hi,
When running 'make test' on my system I discovered that
tests/output/ob_start_basic_unerasable_003.phpt and
tests/output/ob_start_basic_unerasable_004.phpt produced memory
leaks -
due to the fact that they first fetch the buffer into return_value but
then do RETURN_FALSE if they detect an error and thus leak the copied
buffer.
I attached a patch that fixes that to this mail.
Any objections to me applying this for 5.3 and HEAD? (after 5.3 RC1
when
commits are allowed again of course) Any side-effects I didn't think
about?
Regards,
Christian
Index: main/output.c
===
RCS file: /repository/php-src/main/output.c,v
retrieving revision 1.167.2.3.2.4.2.12
diff -u -p -r1.167.2.3.2.4.2.12 output.c
--- main/output.c 13 Feb 2009 11:48:17 - 1.167.2.3.2.4.2.12
+++ main/output.c 18 Mar 2009 02:09:13 -
@@ -867,10 +867,12 @@ PHP_FUNCTION(ob_get_flush)
/* error checks */
if (!OG(ob_nesting_level)) {
php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed to
delete and flush buffer. No buffer to delete or flush.");
+ zval_dtor(return_value);
RETURN_FALSE;
}
if (OG(ob_nesting_level) && !OG(active_ob_buffer).status && !
OG(active_ob_buffer).erase) {
php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed to
delete buffer %s.", OG(active_ob_buffer).handler_name);
+ zval_dtor(return_value);
RETURN_FALSE;
}
/* flush */
@@ -892,10 +894,12 @@ PHP_FUNCTION(ob_get_clean)
/* error checks */
if (!OG(ob_nesting_level)) {
php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed to
delete buffer. No buffer to delete.");
+ zval_dtor(return_value);
RETURN_FALSE;
}
if (OG(ob_nesting_level) && !OG(active_ob_buffer).status && !
OG(active_ob_buffer).erase) {
php_error_docref("ref.outcontrol" TSRMLS_CC, E_NOTICE, "failed to
delete buffer %s.", OG(active_ob_buffer).handler_name);
+ zval_dtor(return_value);
RETURN_FALSE;
}
/* delete buffer */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lukas Kahwe Smith
m...@pooteeweet.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] Netlink sockets support for Linux
Hi, Whats the status here? I would say it does not sound like something we need to add now, but maybe for 5.3.1? So in that light I would say please file a feature request with the patch attached or linked .. regards, Lukas On 10.03.2009, at 18:55, Oleg A. Arkhangelsky wrote: Hello, This patch adds ability to send or receive data using Netlink [1] sockets in Linux OS using Socket Functions in PHP. If you're going to commit this patch, some additions to documentation will be needed. Just let me know. I would very appreciate your comments! [1] http://en.wikipedia.org/wiki/Netlink New version: http://www.progtech.ru/~oleg/php-netlinkV2.txt Some more changes. Fixed socket_getpeername and socket_getsockname functions to understand AF_NETLINK sockets. Patch made for PHP_5_3 branch. Any thoughts or opinions? -- wbr, Oleg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] un-deprecating ticks ?
On 19.03.2009, at 14:32, Arnaud Le Blanc wrote: Hi, After having seen some complaints about ticks being deprecated I'm wondering if they could be un-deprecated for now. Ticks are used by the pcntl extension to call signal handlers when signals are triggered. I added some functions as an alternative, but this does not covers all use cases (and forces a code change). When searching bug reports about ticks, one can feel the ticks to be broken (and this is why they have been deprecated). However, looking in depth at these bugs and viewing what caused them and how they have been fixed does not show really bad things about ticks. Actually one thing is broken (and is marked as such in the documentation), tick functions do not work in ZTS, this looks fixable. Any thoughts on removing the deprecation warning for now ? (at least until a replacement is found). Sorry for posting this so close to the freeze. So what is it going to be? I remember everybody was happy when it was deprecated. But I think everybody ran under the impression that ticks is evil. Indeed the only open ticket is #47198, which is the doc bug. Or did we close tons of ticks bugs because it was deprecated? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] un-deprecating ticks ?
On 26.03.2009, at 01:30, Arnaud Le Blanc wrote: On Wed, 2009-03-25 at 20:05 +0100, Lukas Kahwe Smith wrote: On 19.03.2009, at 14:32, Arnaud Le Blanc wrote: Hi, After having seen some complaints about ticks being deprecated I'm wondering if they could be un-deprecated for now. Ticks are used by the pcntl extension to call signal handlers when signals are triggered. I added some functions as an alternative, but this does not covers all use cases (and forces a code change). When searching bug reports about ticks, one can feel the ticks to be broken (and this is why they have been deprecated). However, looking in depth at these bugs and viewing what caused them and how they have been fixed does not show really bad things about ticks. Actually one thing is broken (and is marked as such in the documentation), tick functions do not work in ZTS, this looks fixable. Any thoughts on removing the deprecation warning for now ? (at least until a replacement is found). Sorry for posting this so close to the freeze. So what is it going to be? I remember everybody was happy when it was deprecated. The only thread I found about that is here: http://marc.info/?l=php-internals&m=121442930703916&w=2 Indeed the only open ticket is #47198, which is the doc bug. Or did we close tons of ticks bugs because it was deprecated? I've seen one bug marked as wont fix for this reason. I've searched for "ticks" and looked at the last few pages of bugs, many was really bogus, or documentation issues. Some was related to register_tick_function() and are fixed. I seen nothing really bad or related to the engine. The ZTS issue looks fixable, this is a crash when using register_tick_function() due to the list of functions not being initialized in the threads. It seems to me like at this point its your call. You are the one that has dug into this. If you feel you can fix things then I guess its your call to undeprecate ticks. As for the bogus bugs, this maybe indicate that we need to do some more work on the documentation. Could you look into this as well? Overall we should do our dearest to prevent that even stupid users can crash PHP and if something can too easily be made to still crash PHP, maybe its something we shouldnt have. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/standard/tests/strings highlight_file.phpt ZendEngine2 zend_language_scanner.c zend_language_scanner.l zend_language_scanner_defs.h zend_stream.h
Bringing this back to the list since its still relevant apparently. On 26.03.2009, at 19:43, shire wrote: Lukas Kahwe Smith wrote: Also Marcus had some comments about your "ZendEngine2/zend_language_scanner.c" change: " thanks for looking into this. The patch looks pretty good for the most part. But you effectively create a BC issue here becuase you no longer allow \0 inside a php file or string. You might want to test whether a length check in your NULL rules fixes that. That check would either return the \0 if inside the code or return 0 if in the lookahead block." Did the above things get fixed yet? Yes, these where both the same issue and have been fixed (allowing nulls in the code). I think we could probably make better changes here but it will be fine for the time being Ok. There was another bug here http://bugs.php.net/bug.php?id=47596 that is slightly related, I made an update in the comments. Dmitry just put in a temporary fix so that we can release this way if needed, however we should make a longer term fix for the actual problem at some point. Dmitry? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
